Задача
Ночью упал сервис, утром его подняли, к обеду все вернулись к работе — а осадок остался. Нужно восстановить цепочку событий, понять, где система дала сбой, и написать постмортем, из которого команда вынесет меры, а не список виноватых.
Подход
Шаг 1. Соберите факты. Хронологию инцидента: тикеты, сообщения из чата на время аварии, обезличенные фрагменты логов, записи о том, кто и что предпринимал. Токены, адреса и личные данные замените или удалите.
Шаг 2. Попросите восстановить картину:
Ты инженер, разбирающий инцидент. Ниже хронология
и фрагменты логов.
1. Восстанови цепочку событий по шагам: что произошло,
когда и что на это повлияло.
2. Отметь узкие места: где не сработала защита, где о проблеме
узнали позже, чем могли.
3. Составь черновик постмортема по разделам: что случилось,
влияние на пользователей, причины, что сделали,
что сделаем.
Опирайся только на предоставленные материалы и не додумывай
события, которых в них нет.Шаг 3. Отделите системные меры. Попросите разбить будущие действия на две группы: «закрыть симптом» и «предотвратить целый класс проблем». Вторая группа самая ценная: алерты, лимиты, автотесты на этот сценарий, обходной путь в документации.
Шаг 4. Отправьте на вычитку команде. Черновик прочтут участники инцидента: модель могла неверно восстановить последовательность или пропустить событие, известное только им. Публикация — после общей проверки.
Результат
Структурированный черновик постмортема и список системных мер с приоритетами вместо долгого «давайте вспомним, как всё было».
Советы
- Не публикуйте документ без проверки участниками: ошибка в постмортеме подрывает доверие ко всему разбору.
- Пишите о процессе, а не о людях — культура без поиска виноватых делает следующие разборы честнее.
- Сохраните шаблон запроса: по нему следующий инцидент разберёте вдвое быстрее.