Управление инцидентами: что делать, когда всё сломалось

Управление инцидентами — это заранее договорённый порядок действий на случай сбоя: кто узнаёт о проблеме, кто координирует работу, как сообщить пользователям, как восстановить сервис и как после этого сделать так, чтобы проблема не повторилась. Главный принцип — сначала восстановить работу, потом искать первопричину. Второй — разбирать инциденты без поиска виноватых.

Разберём уровни критичности, роли во время инцидента, коммуникацию и постмортемы.

Что считать инцидентом?

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

Уровень	Пример	Реакция
SEV1 — критический	Сайт недоступен, не проходят оплаты, утечка данных	Немедленно, в любое время, все нужные люди
SEV2 — высокий	Не работает важная функция у части пользователей	В течение часа, дежурный и ответственная команда
SEV3 — средний	Ошибка с обходным путём, замедление	В рабочее время
SEV4 — низкий	Косметические проблемы	В обычном порядке, задачей в бэклог

О том, как вовремя узнавать о сбоях, — статья мониторинг и логирование.

Какие роли нужны во время инцидента?

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

• координатор — принимает решения, распределяет задачи, следит за временем, сам не чинит;
• технические исполнители — диагностируют и устраняют проблему;
• ответственный за коммуникацию — пишет пользователям, поддержке и руководству;
• летописец — записывает хронологию действий и решений для будущего разбора.

В небольшой команде один человек может совмещать роли координатора и коммуникации, но технические исполнители должны быть сосредоточены на проблеме.

Фото: Unsplash

Как действовать во время инцидента?

Первая цель — восстановить работу как можно быстрее, даже временным способом: откатить релиз, выключить проблемную функцию, переключиться на резервный сервер. Поиск первопричины подождёт до разбора.

Порядок действий:

1. Подтвердить и оценить. Что сломалось, у кого, насколько серьёзно — назначить уровень.
2. Собрать людей. Открыть отдельный канал инцидента и назначить координатора.
3. Сообщить. Короткое первое сообщение пользователям и поддержке: знаем о проблеме, работаем.
4. Стабилизировать. Откат, отключение функции через флаг, переключение на резерв — подробнее в статьях feature flags и релизы без простоя.
5. Обновлять статус. Регулярно, даже если новостей нет.
6. Подтвердить восстановление. По метрикам и проверке ключевых сценариев, а не по ощущениям.

Что такое постмортем без поиска виноватых?

Постмортем — это разбор инцидента после восстановления: что произошло, почему, как мы реагировали и что изменить. «Без поиска виноватых» означает, что ищут слабые места в системе и процессах, а не человека, которого можно наказать. Иначе люди начинают скрывать ошибки, и следующий инцидент повторится.

Что входит в постмортем:

• краткое описание и влияние: сколько пользователей, как долго, какие потери;
• хронология: когда началось, когда заметили, что делали, когда восстановили;
• причины — обычно их несколько, а не одна;
• что сработало хорошо и что помешало;
• конкретные действия с владельцами и сроками.

Как сделать так, чтобы инциденты не повторялись?

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

• добавить мониторинг и алерты, которые заметили бы проблему раньше;
• автоматизировать ручные шаги, которые замедлили восстановление;
• добавить тесты и проверки в CI — статья какие автотесты нужны продукту;
• обновить инструкции восстановления и проверить их на учениях;
• отслеживать время обнаружения и восстановления и следить за их снижением.

Об обязательствах по доступности — статья SLA, SLO и SLI.

Коротко

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