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, будуйте спостережуваність «за замовчуванням» і бережіть он-колл. Так ви отримаєте стійку швидкість розробки, передбачувані релізи і надійну, економну платформу.