💀 Искусство Post-Mortem: Как писать отчеты об авариях, чтобы тебя повысили, а не уволили

В Google это называют Blameless Post-Mortem (разбор полетов без поиска виноватых). В российских реалиях это часто называют «объяснительная». Разница в том, что объяснительную пишут, чтобы прикрыть свою спину, а Post-Mortem пишут, чтобы прикрыть спину компании.
Вот структура идеального отчета, после которого директор скажет:
«Да, нам нужно купить это железо», а не «Вы уволены».

1️⃣ Правило «Без вины» (No Blame Policy)

Первая строчка любого отчета. Мы ищем причину в системе, а не человека.
❌ Плохо:
«Администратор Иванов случайно удалил таблицу в базе данных».
✅ Хорошо:
«Отсутствие защиты от случайного удаления (подтверждения команды) и наличие прав на DROP TABLE у дежурного инженера в продуктивной среде привело к потере данных».
Почему это работает:
если обвинить Иванова — в следующий раз Иванов скроет ошибку.
Если обвинить процесс — становится понятно, что увольнение одного человека проблему не решит.

2️⃣ Хронология — это твой щит

Менеджеры всегда спрашивают: «Почему так долго чинили?»
В отчете должна быть поминутная хронология:
• 14:00 — мониторинг Zabbix зафиксировал рост latency
• 14:05 — дежурный инженер получил алерт и начал диагностику
• 14:15 — выявлена проблема с дисковым массивом
• 14:20 — принято решение переключить трафик на резервный ЦОД
Зачем это нужно:
показывает, что команда работала, а время уходило, например, на согласования с бизнесом. Часто именно здесь рождаются аргументы для пересмотра SLA.

3️⃣ Метод «5 Почему» (5 Whys) — путь к бюджету

Главная цель — найти Root Cause.
Пример: упал сайт.
Почему? — закончилось место на диске.
Почему? — логи заняли всё пространство.
Почему? — ротация логов не сработала.
Почему? — конфиг изменили вручную с ошибкой.
Почему? — нет CI/CD для конфигов и автоматической проверки.
Вывод:
нужно не «чистить диск», а внедрять Ansible, GitLab CI и закладывать ресурсы на DevOps и тестовую инфраструктуру.

4️⃣ Переводи с «эльфийского» на деньги

Директору не важны OOM-killer и race condition.
Ему важны потери бизнеса.
Раздел Impact:
• Downtime: сервис недоступен 45 минут
• Losses: потеряно ~1500 транзакций
• Risks: высокие репутационные риски (жалобы VIP-клиентов)
Когда появляется цифра потерь, просьба купить сервер уже выглядит как инвестиция, а не расход.

5️⃣ Action Items: как мы потратим ваши деньги

Что делаем, чтобы это не повторилось.
Сейчас (без затрат):
• исправлен конфиг
• добавлен алерт
Среднесрочно:
• переработка скриптов деплоя
Долгосрочно (бюджет):
Проблема: текущий сервер БД не справляется с пиками нагрузки.
Риск: повтор аварии в ближайшие 2 месяца.
Решение: кластер из двух серверов + лицензия Enterprise-backup.

Итог
Никогда не упускай хороший кризис.
Пока всё работает — IT выглядит как статья расходов.
Когда всё ломается — ты становишься человеком, которому дают ресурсы.
Пиши Post-Mortem честно, сухо и с цифрами — и вместо увольнения получишь доверие, уважение и бюджет на апгрейд.
Стабильного прода и мудрых руководителей 🤝

#лонгрид #карьера #postmortem #management #money #sysadmin #admin_future