SRE культура и инженерные принципы

1) Что такое SRE-культура

SRE-культура — это набор ценностей и практик, делающих надежность управляемой: SLO-цели → ошибка-бюджет → осознанные риски изменений → быстрая стабилизация → обучение на инцидентах.
Ключевая парадигма: скорость ≠ враг надежности. Скорость релизов возможна, когда риски дозируются и автоматизируются.

• User-centric: обозначаем надежность так, как ее видит пользователь (SLI/SLO).
• Automation-first: любое повторяемое действие → скрипт/политика/контроллер.
• Blamelessness: ошибки — системные, расследуем причины, а не людей.
• Data-driven: решения на основе метрик и бюджетов ошибок.
• Simplicity: простые, проверяемые механизмы > «магические» решения.

2) Базовые инженерные принципы SRE

1. SLO/SLI и бюджет ошибок — основа приоритетов и алертинга.
2. Инцидент → стабилизация → RCA — сначала симптомы, затем причины.
3. Снижение ручного труда (toil) — цель ≤ 50% времени SRE, со временем ниже.
4. Прод-готовность — «production readiness» обязательна до внешнего трафика.
5. Простота и изоляция — меньше взаимосвязей, больше ограничений blast radius.
6. Наблюдаемость по умолчанию — метрики/логи/трассы, SLO-виджеты, синтетика.
7. Изменения управляются — progressive delivery, канареечные выкладки, auto-rollback.
8. Security by design — секреты, доступы, аудит, минимальные привилегии.
9. Учебные циклы — дрили, игры хаоса, постмортемы, ретроспективы.
10. ФинОпс-осознанность — «цена девяток», cost-to-serve, эффективные SLO.

3) Ритуалы и процессы

3.1 Production Readiness Review (PRR)

• SLI/SLO, дашборд и алерты (fast/slow burn).
• Health-эндпоинты `/healthz`, `/readyz`, `/startupz`.
• Runbook/плейбук инцидентов, owner/on-call, escalation chain.
• Backups/DR-план, лимиты ресурсов, бюджетные расчеты.
• Тесты отказоустойчивости (фича-флаги, rollback сценарии).

3.2 Еженедельный SLO-брифинг

Статус error-budget по сервисам.
Инциденты за неделю, CAPA-прогресс.
Релизный риск: где разрешен/ограничен деплой (по бюджету).

3.3 Постмортем без обвинений

Факты и таймлайн, пользовательское влияние, что помогло/помешало.
Системные причины (процессы/инструменты), а не «виновный».
Конкретные CAPA с владельцами и сроками, публичность внутри компании.

3.4 Игры хаоса и дрили

Плановые инъекции сбоев (сеть, БД, кэш, ноды) + целевой SLO.
«Game day»: время на стабилизацию, измерение MTTR, корректировка плейбуков.

4) Алертинг и шум

• Alert only on symptoms: нарушен SLO или путь пользователя.
• Multi-window, multi-burn: быстрый и медленный каналы.
• Quorum/анти-флаппинг: задержки `for`, подавление при maintenance.
• Долой «CPU>80%» — такие сигналы в дэшборды, не в пейджер.

• Доля actionable ≥ 80%.
• Median time-to-ack ≤ 5 минут (по P1).
• Снижение «Pager fatigue»: ≤ 1 ночного пейджа в неделю на инженера.

5) Управление изменениями

Progressive delivery: canary → 10% → 25% → 50% → 100%.
Auto-rollback по SLO-сигналам (ошибки/латентность).
Feature-flags и kill-switch вместо глобального отката.
Change policy by risk: fast lane для low-risk; CAB — только high-risk.

yaml steps:
- setWeight: 10
- analysis: { template: "slo-check" } # fail ⇒ rollback
- setWeight: 25
- analysis: { template: "slo-check" }

6) Снижение toil (рутинного ручного труда)

Примеры источников toil: ручные деплои, перезапуски, тикеты «дай доступ», чистка очередей.

• Инвентаризация повторяемых задач → автоматизация/самосервис.
• KPI: % времени на toil, «автоматизированные шаги/инцидент», «минуты до self-service».
• Каталог услуг платформы (namespaces, БД, очереди, дашборды, алерты).

7) Наблюдаемость и SLO-первый дизайн

Golden Signals (latency, traffic, errors, saturation).
SLO-карточки в каждой команде: цель, окно, бюджет, burn-алерты.
Drilldown: из метрик в логи/трассы; `trace_id` в логах по умолчанию.
Синтетика: blackbox + headless сценарии (login/deposit/checkout).

8) Управление мощностями и устойчивость

Capacity planning: целевые RPS/конкурентность, запас по AZ/региону.
Bulkhead/шеддинг: изоляция пулов, отказ второстепенных функций сначала.
Backpressure и очереди: лаг-контроль, DLQ, адаптивная конкуррентность.
Failover и DR: RPO/RTO, регулярные DR-дрили.

9) Безопасность как часть надежности

Secrets: менеджер секретов, JIT-доступы, аудит.
WAF/DDoS-guard на периметре, лимиты на клиента/тенанта.
PII-минимизация, DSAR/Legal Hold в инцидентах.
Supply chain security: подпись артефактов, политика базовых образов.

10) Здоровье он-колла

Ротации без «одиночек», четкие окна отдыха.
Порог «будить ночью» — только P1/P2 по SLO.
Психогигиена: дефицит сна фиксируется как операционный риск.
Метрики: пейджи/нед, ночные пейджи/инженер, время восстановления.

11) Метрики зрелости SRE

SLO coverage: доля критичных путей с SLO/алертами ≥ 90%.
Error-budget governance: есть freeze-правила и применяются.
Toil: ≤ 30–40% времени, тренд к снижению.
MTTD/MTTR: медианы в квартальной динамике.
Auto-mitigation rate: % инцидентов с автоматическим действием.
PRR pass-rate: доля релизов, прошедших прод-готовность.
Postmortem SLA: SEV-1 — постмортем ≤ 48 часов.

12) Документация и знания

• Runbooks/плейбуки (топ-сценарии: 5xx spike, DB lag, Kafka lag, NodeNotReady, TLS).
• SLO-карточки и дашборды.
• PRR-чек-листы и шаблоны релизов.
• Каталог услуг платформы и OLAs/SLAs.
• Учебные материалы: SRE 101, Chaos 101, On-call 101.

13) Анти-паттерны

Hero-culture: «спасатели» вместо системных фиксов.
Шумный алертинг: CPU/диски в пейджер, сотни ненужных сигналов.
«DevOps — это человек»: размазанная ответственность, нет владельцев.
Отсутствие SLO: «держим зеленым все» → хаос приоритета.
Отложенные постмортемы и «охота на ведьм».
Глобальные откаты без канареек.
Секреты в конфиге/репо; нет аудита действий.
Observability как «красивые графики» без actionable-сигналов.

14) Шаблоны артефактов

14.1 SRE-Хартия (фрагмент)

yaml mission: "Make reliability manageable and economical"
tenets:
- "User - SLI/SLO Center"
- "Automation-first, minimizing toil"
- "Blameless & learning"
governance:
error_budget:
freeze_threshold: 0. 8 # 80% of the budget burned ⇒ release frieze review_cadence: "weekly"
oncall:
paging_policy: "SLO-only, P1/P2 at night"
health_metrics: ["pages_per_week", "night_pages_per_engineer"]

14.2 Мини-PRR чек-лист

• SLI/SLO и burn-алерты настроены
• Health-эндпоинты и синтетика
• Runbook/плейбук + владелец/on-call
• Роллбэк/фича-флаги/канарейка
• Дашборды latency/errors/traffic/saturation
• Лимиты/квоты/guardrails безопасности
• DR-план и бэкапы протестированы

15) Внедрение по этапам (4 спринта)

Спринт 1 — Фундамент

Определить критичные пользовательские пути и SLI.
Сформулировать SLO и запустить burn-алерты.
Ввести PRR и минимальные плейбуки.

Спринт 2 — Управление изменениями

Канареечные выкладки, auto-rollback по SLO.
Self-service операций, каталог услуг.
Инвентаризация toil и план автоматизации.

Спринт 3 — Учебные циклы

Постмортем-ритуал, календарь игр хаоса.
Дашборды SLO+инциденты, отчетность error-budget.

Спринт 4 — Оптимизация и масштаб

Портфель SLO, FinOps «cost per 9».
Внедрение DR-дисциплины, аудит безопасности.
KPI он-колла, профилактика выгорания.

16) Мини-FAQ

SRE = «починить все»?
Нет. SRE управляет системой надежности: SLO, алертинг, процессы, автоматизация и обучение.

Как убедить бизнес инвестировать в надежность?
Покажите ROI: снижение MTTR, рост конверсии, меньше кредитов по SLA, ниже cost-to-serve, стабильные релизы.

Нужны ли отдельные SRE-команды?
Гибридная модель: стратегический SRE в платформе + embedded-SRE в критичных продуктах.

Итог

SRE-культура — это не должность, а способ работать с риском: SLO → бюджет ошибок → управляемые изменения → автоматизация → обучение. Зафиксируйте принципы, заведите ритуалы (PRR, постмортемы, игры хаоса), снимайте toil, строьте наблюдаемость «по умолчанию» и берегите он-колл. Так вы получите устойчивую скорость разработки, предсказуемые релизы и надежную, экономную платформу.