Жизненный цикл инцидента: от алерта до постмортема¶

Представьте, что вы капитан пассажирского лайнера. Ночью, в шторм, в машинном отделении случается пожар. ВашУ вас одна задача - спасти корабль и людей, понять, почему это произошло, и сделать всё, чтобы такое не повторилось. Примерно так выглядит работа SRE во время инцидента, только вместо корабля - ИТ-система, а вместо шторма миллионы пользователей.

Инцидент в сложной IT-системе — это не просто, когда "что-то или всё сломалось". Это предсказуемый, повторяющийся процесс, который можно и нужно структурировать. У него есть начало, середина, конец и, что важнее всего, есть последствия. Понимание жизненного цикла инцидента превращает хаос в управляемый процесс, а эмоции в инженерные решения.

Когда срабатывает алерт, первое, что чувствует дежурный инженер - страх и желание немедленно что-то сделать. С этим нужно бороться. Первые минуты инцидента самые опасные не столько для системы, сколько для качества решений. Руки тянутся к клавиатуре, мозг пытается угадать причину, в чате начинается хаотичное перекладывание ответственности.

Поэтому жизненный цикл инцидента начинается задолго до самого инцидента. Он начинается с документа, в котором написано: что считается инцидентом, у кого какая роль и задачи во время инцидента, где находится общий чат, каков эскалационный путь. Когда алерт приходит в подготовленную систему, это просто сигнал к запуску отлаженного процесса. Когда алерт приходит в неподготовленную - это начало паники.

Обнаружение инцидента может происходить по-разному. Идеальный сценарий: автоматический мониторинг фиксирует нарушение SLO и отправляет алерт дежурному. Хороший сценарий: пользователь пишет в поддержку, и оттуда информация доходит до инженеров. Плохой сценарий: об инциденте узнают из новостей. Чем раньше обнаружение, тем дешевле обходится инцидент. Это аксиома, которая работает и в IT, и в авиации, и в медицине.

Подтверждение инцидента: это момент, когда дежурный инженер говорит: "Да, это не ложное срабатывание, система действительно работает некорректно". С этого момента начинается отсчет времени восстановления и включаются все остальные механизмы. В хороших командах подтверждение инцидента автоматически создает временный канал связи (чатик), приглашает в него нужных людей и блокирует релизы.

Следующая фаза: реагирование и координация. Самая распространенная ошибка на этом этапе это иллюзия того, что все инженеры должны немедленно броситься решать проблему. На практике одновременная работа десяти человек над одной проблемой редко дает положительный результат. Чаще это создает информационный шум, конфликты правок и потерю контекста.

Поэтому в зрелых SRE-организациях существует четкое разделение ролей. Инцидент-командер не пишет код и не копается в логах. Его задачи - смотреть на часы, управлять коммуникацией, решать, кого еще подключить, принимать решения, и главное - защищать команду от внешнего давления. Инженер непосредственно занимается диагностикой и восстановлением. Связной (communicaton lead) отвечает за внешнюю коммуникацию - с руководством, поддержкой, клиентами: пишет апдейты в чатики, отвечает на вопросы "ну когда почините?" и т.п.. Секретарь ведет хронологию событий в реальном времени, чтобы потом, при создании постмортема, не вспоминать, что происходило.

Эта структура кажется бюрократичной, но это до тех пор, пока вы не попадете в настоящий пожар. В огне дисциплина спасает жизни. В IT-инциденте она спасает доступность сервиса.

Диагностика это самая творческая и самая непредсказуемая часть жизненного цикла. Можно потратить пять минут на поиск проблемы, которую уже кто-то решал и описал в runbook. А можно потратить пять часов, перебирая десятки гипотез, и в итоге обнаружить, что причина в обновлении библиотеки, которое сделали три месяца назад без тестирования сразу со своего ноута на прод.

Искусство диагностики в SRE это искусство быстрого исключения гипотез. Хороший инженер не спрашивает "что могло сломаться?", он спрашивает "что и где изменилось за последнее время?". Изменения - это главный источник и катализатор инцидентов. Поэтому первым делом смотрят на дашборд релизов (если он, конечно, есть), конфигураций, включенных фичей. Чаще всего ответ находится там.

Но бывает и так, что ничего не менялось, а система упала. Тогда в ход идут метрики, логи, трейсы. Здесь критически важна качественная наблюдаемость (не мониторинг). Если у вас есть только мониторинг "зеленый/красный", диагностика превращается в гадание. Если у вас есть структурированные логи и распределенные трассировки, вы можете буквально пройти по следу запроса и увидеть, на каком этапе он споткнулся.

Восстановление это не обязательно исправление причины. Часто на первом этапе достаточно восстановить работоспособность системы обходным путем: откатить релиз или переключить трафик на резервный дата-центр или перезапустить сбойный сервис или временно увеличить ресурсы или вернуть старую версию конфигурации или ...

Это называется митигация, а не исправление. Важно понимать разницу. Митигация возвращает пользователей к работе. Исправление устраняет коренную причину. Митигация должна быть быстрой. Исправление может занять дни или недели. И это нормально.

Граница между митигацией и исправлением часто размывается в пылу инцидента. Инженер видит проблему, находит её корень и вместо того, чтобы быстро переключить трафик, начинает писать фикс. Это фатальная ошибка. Время простоя тикает. Пользователи страдают. Задача сейчас - остановить кровотечение, а не делать сложную операцию. Сделайте откат, остановите инцидент, а потом уже разбирайтесь.

Когда система снова работает, инцидент еще не закончен. Завершающая фаза инцидента это передача ответственности. Дежурный инженер, который провел четыре часа в стрессе, должен иметь право уйти домой и отдохнуть. Эстафета передается дневной команде, которая будет заниматься уже не реагированием, а расследованием.

И вот здесь наступает самый важный, самый недооцененный этап жизненного цикла инцидента. Конечно же, это постмортем. Вскрытие. Разбор полетов. Анализ без поиска виноватых.

Постмортем начинается с фиксации хронологии. Часто к этому моменту в чатах и документах уже накопилось множество сообщений, версий, догадок. Задача координатора собрать это в единую временную шкалу: во сколько упал первый сервер, во сколько сработал алерт, во сколько поключился первый инженер, во сколько было принято решение об откате. Каждая минута должна быть восстановлена и зафиксирована.

Затем наступает время вопросов. Не "кто это сделал?", а "почему наша крутая система позволила этому случиться?". Почему мониторинг сработал через десять минут, а не мгновенно? Почему runbook не описывал этот сценарий? Почему у инженера не было доступа к нужной консоли? Почему откат занял сорок минут вместо пяти?

Культура blameless postmortem держится на одном фундаментальном допущении: большинство инженеров приходят на работу, чтобы делать хорошо, а не плохо. Если кто-то ошибся, значит, условия работы, инструменты или процессы подвели его. Человеческая ошибка это симптом, а не диагноз. Человек хотел сделать хорошо, но почему-то не смог. Нужно разбираться.

Из каждого постмортема должны рождаться конкретные, измеримые действия (action items): создать дашборд, написать или исправить runbook, настроить алерт, пересмотреть SLO, изменить процесс... Эти действия становятся конкретными задачами, у которых есть владелец и дедлайн. Без этого этапа постмортем превращается в пустую говорильню, а следующий инцидент будет лишь вопросом времени.

Важно понимать, что жизненный цикл инцидента это не линейный процесс. Он цикличен. Постмортем одного инцидента улучшает систему, и эти улучшения становятся частью подготовки к следующему инциденту. Новый дашборд помогает быстрее диагностировать похожую проблему. Дописанный runbook сокращает время реагирования. Измененный процесс предотвращает целый класс ошибок.

Это и есть зрелость. Но зрелость не в том, чтобы инциденты никогда не случались - они будут случаться всегда. Зрелость в том, чтобы каждый инцидент делал систему надежнее, а команду немного опытнее.

В конечном счете, жизненный цикл инцидента это история про то, как организация учится на своих ошибках. Алерт это сигнал. Диагностика это понимание. Митигация это действие. Постмортем это рефлексия. И если вы пропускаете хотя бы один из этих этапов, вы не управляете инцидентами. Вы просто тушите пожары, пока однажды не сгорите сами.

Именно поэтому опытные SRE говорят: хороший инцидент - это не тот, которого не было. Хороший инцидент - это тот, из которого сделали правильные выводы.