Содержание слайдов

1. 1. Постмортемы или как мы учимся на факапах

   Опыт построения культуры разбора инцидентов в крупном финтехе

2. 2. О чём поговорим

   Зачем нужны постмортемы

   Как это делают Etsy и Google

   Наш шаблон и процесс

   Примеры факапов и выводы

3. 3. 01. Зачем нужны постмортемы

   Когда команда растёт, факапы становятся cross-team

4. 4. Команды растут — факапы усложняются

   От простых инцидентов в одной команде к cross-team фейлам

   Late 2016 — 3 команды, простые факапы внутри

   Рост команд — больше команд — cross-team фейлы

   Сегодня — cross-department инциденты

5. 5. Что хотели от процесса

   Задачи, которые должен закрывать постмортем

   Зафиксировать факт инцидента

   Оценить эффект на бизнес и людей

   Описать, как тушили пожар

   Действия и ответственные, чтобы не повторилось

6. 6. 02. Как другие работают с постмортемами

   Etsy и Google как ключевые источники

7. 7. Откуда мы учились

   Открытые материалы по культуре blameless postmortems

   Etsy — Just Culture

   Google SRE Book и SRE Workbook

   Публичный шаблон постмортема Google

   Опыт PagerDuty, Atlassian, GitLab

8. 8. Etsy: разбор без обвинений

   Blameless даёт честные данные

   Цель — узнать факты

   Без обвинений рассказывают детали

   Страх рождает CYA-engineering

   Just Culture: error ≠ at-risk

9. 9. Постмортем — артефакт обучения

   Google SRE Book: разбор, а не наказание

   Безобвинительно и конструктивно

   Все постмортемы проходят ревью

   Нет ревью — лучше не писать

   Action items: конкретные и с владельцем

10. 10. Хороший постмортем vs плохой

    Workbook разбирает оба на примерах

    Плохой

    Размытое summary

    Нет конкретных действий

    Поиск виноватого

    Хороший

    Ясная хронология

    Action items с владельцами

    Безобвинительный тон

    Критерии: ясность, конкретика, безобвинительность

11. 11. 03. Наш шаблон постмортема

    Что мы взяли и как адаптировали под себя

12. 12. Структура постмортема

    Одинаково удобно писать и читать

    Summary — одно предложение

    Эффект — пользователи, бизнес, метрики

    Timeline — что и когда

    Root cause + action items с владельцем

13. 13. Жизненный цикл постмортема

    От инцидента до закрытия action items

    Инцидент → дежурный фиксирует факт

    48 часов — черновик постмортема

    Ревью команды и cross-team

    Action items → очередь задач с дедлайнами

    Раз в квартал — ретроспектива по всем постмортемам

14. 14. 04. Примеры факапов «моего друга»

    Реальные кейсы и что мы из них вынесли

15. 15. Релизный факап

    Хорошо подготовили, плохо выкатили

    Большой релиз без flag и canary

    Тест на ограниченных данных

    Прод: деградация за 5 минут

    Откат 25 минут — ручной процесс

    Выводы: feature flags, canary, runbook отката

16. 16. Cross-team факап

    Критичность общего сервиса неявна

    Команда A: breaking change в общем API

    Команда B не знала зависимость

    Каскад на 3 сервиса вниз

    Причина — коммуникация, не код

    Выводы: контракт-тесты, единый каталог сервисов

17. 17. Инфраструктурный факап

    Виноват не код, а конфиг сети

    Изменение DNS в одном ЦОД

    Частичный резолв — серый отказ

    Мониторинг не поймал — всё зелёное

    Узнали по жалобам пользователей

    Выводы: synthetic monitoring, multi-region health checks

18. 18. 05. Выводы

    Что мы поняли за 3 года работы с постмортемами

19. 19. Что важно

    Правила, которые работают у нас

    Blameless — иначе не скажут правду

    Шаблон обязателен — иначе несравнимы

    Action items без владельцев не делаются

    Ретроспектива — раз в квартал

    метрики процесса: % action items и время до закрытия

20. 20. Спасибо!

    polomodov.tech

    Все слайды и ссылки — в Telegram-канале

    Александр Поломодов, Технический директор и Fellow, Т-Технологии

    @book_cube