Анатомия инцидента, или как работать над уменьшением downtime
Рано или поздно в любом проекте настает время работать над стабильность/доступностью вашего сервиса. Для каких-то сервисов на начальном этапе важнее скорость разработки фич, в этот момент и команда не сформирована полностью, и технологии выбираются не особо тщательно. Для других сервисов (чаще технологические b2b) для завоевания доверия клиентов необходимость обеспечения высокого uptime возникает с первым публичным релизом. Но допустим, что момент X все-таки настал и вас начало волновать, сколько времени в отчетный период "лежит" ваш сервис. Под катом я предлагаю посмотреть, из чего складывается время простоя, и как эффективнее всего работать над его уменьшением.
Очевидно, что прежде чем что-то улучшать, нужно понять текущее состояние. Следовательно, если мы начали уменьшать downtime, его в первую очередь и нужно начать измерять.
Мы не будем здесь подробно говорить о том, как конкретно это делать, плюсы и минусы разных подходов, но тезисно процесс выглядит как-то так:
- опираемся на около-бизнесовые метрики (ошибки в работе сервиса, время отклика сервиса, $/second, signups/second итп)
- определяем, что такое хорошо, а что такое плохо
- переход хорошо->плохо является началом инцидента
- переход плохо->хорошо — конец инцидента
- время от начало до конца — длительность инцидента (кэп с нами)
- сумма длительностей инцидентов за период (месяц/квартал/год) — время простоя (downtime)
- (100 — <время простоя>/<длительность периода> * 100) = процент доступности за период
Когда говорят об uptime/downtime, часто упоминают еще один показатель:
MTTR (mean time to repair) — среднее время от начала инцидента до его окончания.
Проблемы с ним начинаются прямо с первого слова в аббревиатуре. Учитывая, что все инциденты разные, усреднение длительности ни о чем в системном плане нам сказать не может.
В этот раз мы не будем ничего усреднять, а просто посмотрим, что происходит в ходе инцидента.