Когда прод лежит, от тимлида ждут не героического дебага, а порядка: кто чинит, кто общается, кто принимает решения. После инцидента от него ждут разбора, который делает систему надёжнее, а не ищет виноватого.
Роли в инциденте
- Руководитель инцидента (incident commander): координирует, принимает решения, следит за временем, не чинит сам. Им может быть дежурный, не обязательно самый старший.
- Технические специалисты: диагностируют и чинят.
- Ответственный за коммуникацию: обновляет статус для бизнеса, поддержки, клиентов.
- Летописец: записывает хронологию и решения, это потом основа разбора.
В маленькой команде роли совмещают, но правило важное: тот, кто глубоко копает в логах, не может одновременно отвечать руководству в чате.
Порядок действий
- Объявить инцидент и уровень серьёзности: лучше объявить и отменить, чем поздно.
- Собрать людей в одном канале.
- Смягчить влияние в первую очередь: откат, отключение фичи, переключение трафика. Поиск корневой причины потом.
- Регулярный статус с указанием времени следующего обновления, даже если новостей нет.
- Закрыть инцидент по явному критерию (метрики вернулись в норму).
- Разбор в течение нескольких дней.
Blameless-постмортем
Безобвинительный разбор исходит из того, что люди действовали разумно с той информацией, что у них была. Вопрос не «кто виноват», а «что в системе позволило этой ошибке дойти до прода и не было замечено раньше».
Структура документа:
- Влияние: сколько длилось, кого затронуло, в цифрах.
- Хронология: когда началось, когда заметили, когда смягчили, когда устранили.
- Причины: корневая и способствующие (часто несколько).
- Что сработало хорошо, что плохо, где повезло.
- Действия: конкретные задачи с ответственными и сроками.
Метод «5 почему» помогает дойти от симптома до системной причины: «Почему упал сервис? Закончилась память. Почему? Утечка в новом релизе. Почему не поймали? Нет нагрузочного теста. Почему?…». Важно не останавливаться на «человек ошибся»: людям свойственно ошибаться, система должна это выдерживать.
Почему без обвинений: если за ошибку наказывают, люди скрывают ошибки и сигналы, и следующий инцидент будет хуже.
SLO и бюджет ошибок
SLO задаёт цель надёжности, например доступность 99,9% за 30 дней. Бюджет ошибок это допустимый простой: 0,1% от 30 дней = 43,2 минуты. Пока бюджет есть, команда выкатывает фичи. Когда бюджет исчерпан, приоритет переходит на надёжность. Это снимает вечный спор «фичи или стабильность» договорённостью заранее.
Время до обнаружения и восстановления
Полезно разделять: время до обнаружения (MTTD), время до смягчения и время до полного устранения. Часто самые большие потери в обнаружении: о проблеме узнают от клиентов. Это повод для алертов по симптомам, а не по причинам.
Кризисы команды
- Уход ключевого человека: сразу план передачи знаний на период отработки, пересмотр рисков и сроков, поговорить с командой. Профилактика: bus factor больше одного.
- Аврал перед запуском: ограничить по времени, честно назвать его временным, урезать объём, защитить людей от выгорания, потом разобрать, как к нему пришли.
- Массовый уход или сокращение: прозрачность, 1:1 со всеми оставшимися, пересобрать приоритеты под новую ёмкость.
Частые ошибки
- Тимлид сам лезет чинить и пропадает для всех.
- Искать виноватого в разгар инцидента.
- Постмортем без конкретных задач или задачи без сроков.
- Молчание в статус-канале «пока нечего сказать».
Что спросят на собесе
- Расскажите про крупный инцидент: ваша роль, что сделали, что поменяли.
- Как вы проводите постмортем.
- Разработчик уронил прод. Что вы ему скажете.
- Что такое бюджет ошибок и как он помогает договариваться с бизнесом.
- Ключевой разработчик уходит через две недели. Ваши действия.