Шаблоны и чек-листы

1. Шаблон Runbook

Runbook — это инструкция для дежурного на случай алерта. Его задача — провести инженера от уведомления до восстановления сервиса без лишних размышлений.

# Runbook: [Название алерта/ситуации]

## Описание
Что произошло? Когда срабатывает этот runbook?
Пример: «PagerDuty алерт HighLatency на сервисе billing-api».

## Приоритет
P1 / P2 / P3

## Симптомы
Как понять, что проблема именно эта?
- Метрики (ссылка на дашборд)
- Логи (запрос в Kibana/Grafana)
- Ожидаемое vs реальное поведение

## Быстрая диагностика
Что проверить в первую очередь (занимает < 2 минут):
1. [ ] Статус сервиса: `curl -f http://service/health`
2. [ ] Лог ошибок за последние 5 минут: `kubectl logs --since=5m -l app=billing-api | grep ERROR`
3. [ ] Нагрузка на БД: дашборд [ссылка]

## Действия по восстановлению

### Шаг 1: [Название шага]
Команда для выполнения:

kubectl rollout restart deployment/billing-api

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

deployment.apps/billing-api restarted

Как проверить:

kubectl get pods -l app=billing-api

Все поды должны быть в статусе Running.

### Шаг 2: [Название шага]
...

## Критерии успеха
Как понять, что инцидент исчерпан:
- [ ] healthcheck возвращает 200
- [ ] Латентность p95 < 200 мс
- [ ] Ошибки 5xx < 0.1%
- [ ] Алерт погас

## Эскалация
Если шаги 1-3 не помогли:
- Дежурный SRE: @sre-oncall
- Тимлид сервиса: @ivan.ivanov
- Канал в Slack: #billing-incidents

## Дата последней проверки
[Дата, когда runbook актуален]

2. Шаблон Blameless Postmortem

Postmortem — это системный разбор инцидента без поиска виноватых. Подробнее — в главе «Культура blameless postmortem».

# Postmortem: [Название инцидента]

## Метаданные
- **Дата инцидента:** YYYY-MM-DD
- **Автор postmortem:** [Имя]
- **Участники:** [список]
- **Продолжительность:** [MTTR]
- **Влияние:** [количество пользователей, потерянный доход, иное]
- **Severity:** P0 / P1 / P2

## Хронология
| Время (UTC) | Событие |
|-------------|---------|
| 14:02 | Первый алерт (latency p99 > 1s) |
| 14:05 | Дежурный подтвердил инцидент |
| 14:12 | Выявлена причина: утечка соединений с БД |
| 14:18 | Применён фикс: рестарт пула соединений |
| 14:22 | Метрики вернулись в норму |
| 14:25 | Инцидент закрыт |

## Событие
Что произошло? (2-3 предложения сути)

## Причины

### Триггер
Непосредственное событие, вызвавшее сбой.

### Коренная причина
Почему это стало возможным? Что в системе/процессах позволило триггеру привести к сбою?

### Внесённые факторы
- [ ] Отсутствие мониторинга
- [ ] Нет runbook'а
- [ ] Нет алерта на предшествующее условие
- [ ] Человеческая ошибка (описать условия, которые к ней привели)

## «Пять почему»
1. Почему упал сервис? — Закончились соединения с БД.
2. Почему закончились? — Новый код не закрывал соединения.
3. Почему код попал в прод? — Не было code review на эту часть.
4. Почему этого не заметили? — Нет метрики на количество открытых соединений.
5. Почему нет метрики? — Никто не считал её важной. → **Action item: добавить метрику и алерт.**

## Действия

| Действие | Ответственный | Срок | Статус |
|----------|---------------|------|--------|
| Добавить метрику connection_pool_size | @dev_team | 1 неделя | [ ] |
| Настроить алерт при > 80% пула | @sre_team | 1 неделя | [ ] |
| Добавить проверку соединений в код-ревью | @tech_lead | Постоянно | [ ] |

## Выводы
- Что сделали хорошо?
- Что сделали плохо?
- Что будем делать иначе в следующий раз?

## Ретроспектива (через месяц)
- [ ] Все action items выполнены?
- [ ] Метрики не вернулись к старому паттерну?

3. Чек-лист Production Readiness Review (PRR)

Перед тем как новый сервис или крупное изменение попадает в продакшен, нужно проверить, что он соответствует минимальным стандартам SRE.

Мониторинг и наблюдаемость

  • Настроен healthcheck endpoint (GET /health возвращает 200)
  • Метрики отдаются в систему мониторинга (латентность, ошибки, нагрузка)
  • Настроен дашборд с ключевыми SLI (не менее 3 метрик)
  • Настроены логи (структурированные, с correlation ID)
  • Настроены алерты на критичные метрики (нет silent failure)
  • Каждый алерт имеет runbook

Надёжность и отказоустойчивость

  • Нет единых точек отказа (SPOF) в критическом пути
  • Сервис работает минимум в 2 инстансах (репликация)
  • Настроены timeout'ы для всех внешних вызовов
  • Реализован circuit breaker для критических зависимостей
  • Graceful degradation (сервис работает без зависимости, пусть и хуже)
  • Автомасштабирование настроено (HPA, если Kubernetes)

Развёртывание

  • CI/CD пайплайн полностью автоматизирован
  • Есть стратегия progressive delivery (ramped / canary)
  • Возможен быстрый откат (rollback за < 10 минут)
  • Feature flags для критических изменений
  • Миграции БД обратно совместимы с предыдущей версией

Безопасность

  • Секреты не в коде (Vault, sealed secrets, внешний secret store)
  • Минимальные сетевые доступы (не открыты все порты всем)
  • Зависимости проверены на уязвимости (SBOM, сканирование образов)
  • Аутентификация и авторизация между сервисами (mTLS или аналоги)

Процессы

  • Написан runbook для типовых сбоев (минимум 2 сценария)
  • Определён владелец сервиса (кто отвечает за инциденты)
  • Вписаны контакты для эскалации в runbook
  • Согласованы SLO с командой продукта
  • Протестировано восстановление (disaster recovery drill хотя бы раз)

Что делать с результатами

  • Все пункты «зелёные» — сервис готов к продакшену.
  • Есть жёлтые — можно катить с условием исправить в течение N дней.
  • Есть красные — нельзя катить до исправления. Это gates.

Чек-лист не должен быть бюрократией. Его задача — поймать очевидные проблемы до того, как они превратятся в ночной инцидент. Если какой-то пункт кажется избыточным именно для вашего сервиса — обсудите и снимите осознанно, а не потому что «лень заполнять».

4. Чек-лист для On-Call инженера

Перед заступлением на дежурство:

  • Ноутбук заряжен, VPN работает, доступ к кластеру есть
  • Телефон/пейджер получает уведомления (проверить тестовым алертом)
  • Я знаю, какие сервисы под моим контролем
  • Я прочитал runbook'и для типовых алертов (если обновились)
  • Я знаю, кого будить в случае эскалации (контакты под рукой)
  • Настроен доступ к дашбордам и логам

Во время инцидента:

  • Подтвердил алерт в течение MTTA
  • Открыл runbook
  • Пишу хронологию в чат инцидента (не надеюсь на память)
  • Если не могу решить за 15 минут — эскалирую
  • Не делаю рискованных изменений без второго мнения

После инцидента:

  • Обновил runbook, если инструкция устарела
  • Завёл задачу на action items из postmortem
  • Отошёл от компа на 15 минут и выпил чаю