ТЕХНИЧЕСКОЕ ЗАДАНИЕ: Создать blameless postmortem template

1. Цель задачи

Спроектировать и написать шаблон blameless postmortem (безобвинительного посмертного анализа) для команды AI/ML инженеров. Шаблон должен систематизировать разбор инцидентов, смещая фокус с поиска виноватого на поиск системных причин и улучшений. В результате команда получит готовый документ, который снижает страх перед написанием postmortem и ускоряет обучение на инцидентах.

Ключевой результат Markdown-файл blameless-postmortem-template.md, готовый к использованию в репозитории команды, который любой инженер сможет заполнить за <30 минут.

2. Исходные данные

Если нет реального доступа к документам — симулируем:

1. Изучим открытый шаблон GitLab (https://about.gitlab.com/handbook/engineering/postmortem-template/)
2. Почитаем статью Google SRE: https://sre.google/sre-book/postmortem-culture/
3. Соберём 5-10 требований к шаблону на основе этих материалов

3. Технологический стек

4. Этапы выполнения

Этап 1: Исследование лучших практик (1–2 часа)

Действия

1. Найти и законспектировать 3–5 источников по blameless postmortem:

   • Книга SRE Google (глава про postmortem)
   • Статья Atlassian «Blameless Postmortem Culture»
   • Шаблон GitLab (открытый)
   • Пост Honeycomb Charity Majors «Ops Lessons Learned»
   • Рекомендации из книг «The Phoenix Project» / «DevOps Handbook»

2. Выделить ключевые принципы blameless

   • Инцидент — результат системных, а не человеческих ошибок
   • Основной вопрос: «Что в системе позволило ошибке произойти?»
   • Разделы: факты, таймлайн, влияние, root cause, action items, learning

3. Зафиксировать «анти-паттерны»

   • Упоминание имён в негативном контексте
   • Раздел «Виновник»
   • Фразы «должен был знать», «не проверил»

Ожидаемый результат этапа Документ «research-notes.md» с конспектами и выводами.

Этап 2: Проектирование структуры шаблона (1 час)

Действия

1. Определить обязательные разделы (минимум 7):

   • Executive Summary (1–2 предложения)
   • Влияние на пользователей и бизнес
   • Таймлайн (таблица времени)
   • Root cause (с методикой «5 Why»)
   • Действия по исправлению и предотвращению (Action Items)
   • Культурные уроки (что узнали о своей системе)
   • Приложение (метрики, скриншоты, логи)

2. Разработать тональность текста в шаблоне

   • Использовать нейтральные формулировки («было развёрнуто», «метрика упала»)
   • Включить заметки-подсказки для заполняющего (например, «Какие системные факторы способствовали?»)
   • Избегать императива «напиши», использовать «укажите»

3. Выбрать формат: Markdown + optional YAML frontmatter для автоматизации

Ожидаемый результат этапа Схема шаблона (оглавление) с кратким описанием каждого раздела.

Этап 3: Написание шаблона (2–3 часа)

Действия

1. Создать файл blameless-postmortem-template.md со следующей структурой:

---
title: "Postmortem: <название инцидента>"
date: YYYY-MM-DD
severity: P0/P1/P2
duration: <часы:минуты>
author: <ник>
tags: [postmortem, <тип инцидента>]
---

# Postmortem: <название инцидента>

## Краткое резюме (Executive Summary)
*Почему это важно для менеджера? Что произошло за 30 секунд?*

- Влияние <число пользователей, падение метрик>
- Что вызвало <корневая причина в двух словах>
- Статус Решено / В процессе / Требует дальнейшего анализа

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

| Метрика | Baseline | Во время инцидента | После восстановления |
|---------|----------|---------------------|-----------------------|
| Время ответа (p95) | 200 ms | 2000 ms | 210 ms |
| Процент ошибок 5xx | 0.1% | 5% | 0.1% |
| ... | ... | ... | ... |

*Опишите ощутимое воздействие: сколько пользователей затронуто, какие бизнес-процессы нарушены.*

## Таймлайн (хронология)

| Время (UTC) | Событие | Кто/что обнаружил? |
|-------------|---------|---------------------|
| 2025-XX-XX 10:00 | Baseline — все метрики в норме | — |
| 10:05 | Начало роста времени ответа | Дашборд Grafana |
| ... | ... | ... |
| 12:30 | Фикс применён на production | Инженер N (дежурный) |
| 13:00 | Метрики вернулись к baseline | — |

## Анализ корневой причины (Root Cause)

Метод: «5 Почему»

1. Почему упала производительность? → Утечка памяти в embedding сервисе.
2. Почему произошла утечка? → Неправильное освобождение кеша после обновления модели.
3. Почему это не заметили на staging? → На staging нагрузка в 10 раз ниже.
4. Почему нагрузочное тестирование не выявило? → Сценарий теста не включал долгие сессии.
5. Почему не было алерта на утечку? → Метрика `memory_usage` не мониторилась с агрегацией по хосту.

Системные факторы (перечислить инфраструктурные, процессные, культурные аспекты)

## Действия по исправлению и предотвращению (Action Items)

| # | Что сделано/будет сделано | Ответственный | Дедлайн | Тип (fix/prevent/process) |
|---|---------------------------|---------------|---------|---------------------------|
| 1 | Откатить версию embedding сервиса | team-llm | 2025-XX-XX | fix |
| 2 | Добавить мониторинг `memory_usage` с p99 | devops | 2025-XX-XX | prevent |
| 3 | Обновить сценарий load test (длинные сессии) | qa | 2025-XX-XX | process |

## Культурные уроки (What did we learn about our system?)

- *Продолжить практику: быстрая откатываемость через feature flags.*
- *Улучшить: автоматический runbook для выявления утечки памяти.*
- *Прекратить: полагаться только на staging для оценки производительности.*

## Приложение

- Ссылка на дашборд Grafana во время инцидента: ...
- Логи затронутого сервиса (релевантные строки): ...
- Связанные изменения кода (merge request): ...

2. Добавить подсказки для заполняющего (в виде html-комментариев или курсива)

3. Включить пример заполненного шаблона (optional — можно сделать отдельный файл example-postmortem.md)

Ожидаемый результат этапа Готовый Markdown-файл шаблона.

Этап 4: Тестирование шаблона на смоделированном инциденте (1–2 часа)

Действия

1. Придумать реалистичный сценарий инцидента (например, ошибка в RAG-пайплайне из-за неправильного чанкинга)
2. Попросить одного из коллег (или себя) заполнить шаблон по этому сценарию, засекая время
3. Собрать обратную связь
   • Сколько времени заняло заполнение?
   • Были ли непонятные разделы?
   • Не возникло ли чувства вины?
   • Хотели бы вы использовать этот шаблон для реального инцидента?
4. Задокументировать узкие места

Ожидаемый результат этапа Список улучшений (не менее 5 пунктов).

Этап 5: Итерация и финализация (1 час)

Действия

1. Внести правки по результатам тестирования
   • Упростить формулировки
   • Добавить/убрать разделы
   • Снабдить более понятными примерами в подсказках
2. Добавить чек-лист для самопроверки внутрь шаблона (например, после заполнения автор должен пройтись по пунктам)
3. Причесать markdown: единообразный стиль, заголовки, списки, таблицы
4. Зафиксировать версию 1.0 и положить в репозиторий

Ожидаемый результат этапа Финальная версия blameless-postmortem-template.md версии 1.0.

5. Критерии приемки (Definition of Done)

• Шаблон содержит не менее 7 обязательных разделов (Executive Summary, Impact, Timeline, Root Cause, Action Items, Cultural Lessons, Appendix).
• В шаблоне явно указано, что это blameless документ (например, в преамбуле или комментариях).
• Шаблон не содержит разделов или формулировок, возлагающих вину на конкретного человека.
• Все разделы снабжены пояснениями (italic или комментарии) о том, что писать.
• Шаблон протестирован на одном смоделированном инциденте, время заполнения не превысило 40 минут.
• Создан файл README.md с инструкцией по использованию шаблона (команда, workflow, примеры).
• Шаблон прошёл ревью как минимум одного инженера, не участвующего в разработке.

6. Ожидаемый результат

• Основной артефакт blameless-postmortem-template.md — готовый шаблон postmortem в формате Markdown.
• Дополнительные артефакты
  • research-notes.md (конспекты лучших практик)
  • example-postmortem.md (пример заполнения шаблона для смоделированного инцидента)
  • README.md (инструкция по внедрению и использованию в команде)
• Содержание шаблона полная структура, включая YAML frontmatter, все разделы с подсказками, пустые таблицы и места для данных.

7. Возможные сложности и их решение

8. Бюджет времени (оценка)

Примечание Для первого раза выполнение может занять до 10 часов. Рекомендуется разбить на 2 сессии.

9. Связанные вопросы из базы знаний

10. Чек-лист самопроверки

• Я изучил(а) не менее 3 источников по blameless postmortem и законспектировал(а) ключевые принципы.
• Разработанный шаблон не содержит обвинительных формулировок и имён в негативном контексте.
• Каждый раздел шаблона имеет пояснение или пример, чтобы его мог заполнить даже новый член команды.
• Я протестировал(а) шаблон на вымышленном инциденте и получил(а) обратную связь от коллеги.
• Финальный шаблон сохранён в Markdown с корректным frontmatter, и к нему приложен README с инструкцией.