DevOps Culture

Искусство Postmortem:
Как превратить сбой в победу

Прозрачность вашего кода в реальном времени — это только половина дела. Вторая половина — это то, как ваша команда реагирует, когда индикаторы становятся красными.

Безобидный подход (Blameless)

В Statusly мы убеждены: вине не место в инженерии. Если вы ищете виноватого, вы останавливаете расследование на первом же человеке, чья ошибка стала триггером. Это ошибка.

Культура Blameless Postmortem фокусируется не на том, кто нажал кнопку, а на том, почему система позволила нажать эту кнопку без подтверждения или защиты. Сбой — это симптом того, что процесс дал трещину.

Фокус на процессах, а не людях
Команда разработчиков обсуждает инцидент в переговорной
Структура отчета

Анатомия идеального Postmortem

Отчет должен быть документом, который можно показать инвесторам, клиентам и новичкам. Он должен отвечать на вопросы: Что случилось? Почему? Как мы это починили?

01

Исполнительная сводка (Executive Summary)

Краткое описание инцидента для не-технических стейкхолдеров. Включает время простоя, затронутые сервисы и бизнес-потери (например, "Потеряно 15 транзакций за 20 минут").

02

Хронология (Timeline)

Минутная разбивка событий. Когда сработал алерт Statusly? Когда инженер взял инцидент в работу? Когда был применен фикс? Это помогает найти узкие места в реагировании.

03

Корневая причина (Root Cause)

Техническое объяснение. Не "Олег удалил базу", а "Отсутствовала защита от DROP TABLE для пользователей уровня 'writer'".

# actions.md
[ ] Увеличить лимиты памяти для Redis
[ ] Добавить алерт на рост очереди задач
[x] Обновить документацию для новых сотрудников

// Assignee: @backend-lead
// Due: 2023-11-15

statusly run postmortem-check
● PASS All action items assigned.

Шаги по предотвращению рецидивов

Postmortem без Action Items — это просто жалоба. Чтобы инцидент имел ценность, он должен привести к изменениям в коде или инфраструктуре.

  • 1
    Ограничение ущерба Автоматическое отключение сервиса при аномалиях (Circuit Breaker).
  • 2
    Улучшение наблюдаемости Добавление новых метрик в Statusly, которые сработали бы раньше.
  • 3
    Тестирование хаоса Намеренное повторение сбоя в тестовом окружении для проверки защиты.

Шаблон Postmortem

Стандартизированный подход, который мы рекомендуем использовать с Statusly.

Инцидент: Падение API шлюза (2023-10-24)

Severity: S1 Duration: 45m Author: @sysadmin_alex

Влияние на пользователей

Пользователи не могли авторизоваться через OAuth. Мобильное приложение возвращало ошибку 503.

Что мы узнали

Наши алерты на загрузку CPU были настроены неправильно. Мы увидели проблему только когда упал сервис, а не когда началась нагрузка.

Скачать Markdown-шаблон