Инциденты и постмортемы

Аварии будут всегда

Сколько ни вкладывайся в надёжность, сервисы всё равно иногда падают. Из урока про SLO мы знаем, что 100% не бывает, и error budget это прямое признание этого. Аварии надо и предотвращать, и уметь из них восстанавливаться: быстро реагировать и потом извлекать урок. Этим занимаются управление инцидентами и постмортемы.

Жизненный цикл инцидента

Инцидент это незапланированное нарушение работы сервиса. У него есть понятные стадии:

1. Обнаружение. Алерт сработал или пользователи сообщили. Чем раньше, тем лучше, и для этого нужны алерты из прошлого трека.
2. Реакция. Кто-то берёт инцидент на себя (incident commander), собирает нужных людей, координирует.
3. Смягчение. Сначала вернуть сервис, потом разбираться. Откатить релиз, перевести трафик, увеличить ресурсы. Главная цель на этой стадии это остановить ущерб, а не найти корневую причину.
4. Разрешение. Сервис снова в норме.
5. Постмортем. Спокойный разбор после.

Важный принцип: во время инцидента чинят, а не расследуют. Откат сначала, анализ потом.

Blameless-постмортем

Постмортем это письменный разбор инцидента после его закрытия. Ключевое слово — blameless (без обвинений). Цель постмортема не найти виноватого, а понять, как система позволила аварии случиться, и что поменять, чтобы она не повторилась.

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

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

Работа над причинами, а не симптомами

Хороший постмортем доходит до корневой причины, а не останавливается на поверхности. Приём «пять почему»: спрашивать «почему» несколько раз подряд.

Сервис упал. Почему?
→ Кончилась память. Почему?
→ Утечка в новом релизе. Почему?
→ Не было лимита памяти и алерта на рост. Почему?
→ Шаблон сервиса не включал их по умолчанию.

Действие из такого разбора — не «уволить автора релиза», а «добавить лимит памяти и алерт в шаблон сервиса». Так одна авария чинит целый класс будущих аварий.

Что важно запомнить

Аварии неизбежны, поэтому важно уметь их проживать. Инцидент проходит стадии от обнаружения до постмортема; во время инцидента сначала останавливают ущерб (откат, переключение), а расследуют после.

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

Этим закрывается трек ops-basics: бэкапы, секреты и разбор инцидентов.