Інженерія надійності
1) Що таке SRE і навіщо він потрібен
Інженерія надійності (Site Reliability Engineering, SRE) - дисципліна на стику розробки та експлуатації, яка перетворює надійність у вимірюваний продуктовий атрибут. SRE з'єднує метрики досвіду користувача (SLI), цілі якості (SLO), бюджети помилок, автоматизацію і керовані зміни, щоб швидше поставляти цінність без втрати стійкості.
Ключові цілі: передбачуваний UX, швидкі релізи, мінімальні простої і контрольована вартість володіння.
2) Принципи SRE
Надійність як фіча. Пріоритетна до меж, заданих SLO і бізнес-цілями.
Бюджет помилок управляє швидкістю змін. Якщо бюджет спалюється - фокус на стабільності.
Автоматизація> ручні операції. Будь-яка повторювана задача - скрипт/оператор/пайплайн.
Вимірюваність. Тільки те, що виміряно (SLI/SLO), можна покращувати.
Just Culture. Пост-мортеми без звинувачень, фокус на системних причинах.
Shift-left. Якість, безпека, тести і спостережуваність - частиною девелоперського циклу.
3) Організація і ролі
SRE-команда платформи: загальні інструменти, політики, пайплайни, GitOps, каталоги сервісів.
Вбудовані SRE (embedded): працюють поруч з продуктовою командою, спільні цілі по SLO.
Чергування (on-call): ротації, межі навантаження, компенсація, тренування.
RACI: власник сервісу, власник SLO, IC при інцидентах, Comms Lead, Scribe.
4) SLI/SLO і бюджет помилок (зв'язка з продуктом)
SLI: доступність, латентність, успіх бізнес-операцій, актуальність даних.
SLO: цілі на вікна 28-30 днів + винятки.
Error Budget = 1 − SLO. Політики: релізи, експерименти, канарки і фічі регулюються фактичним burn-rate.
Дизайн по когортах: регіони, провайдери, VIP-сегменти - окремі SLO, щоб не втрачати аномалії.
5) Спостережуваність за замовчуванням
Метрики: успіх/помилка, перцентили p50/p95/p99, saturation (CPU/mem/IO/conn).
Логи: структуровані, з кореляцією запитів/релізів/прапорів.
Трейсинг: наскрізна карта затримок і помилок, hot-paths.
Синтетика + RUM: зовнішні проби і реальна клієнтська телеметрія.
Дашборди SLO: burn-down бюджету, релізні анотації, канарка, провайдери.
6) Управління змінами та випуском
Пайплайн CI/CD: детерміновані збірки, підпис артефактів, скани безпеки, тести контрактів.
Прогресивні стратегії: canary/blue-green/shadow; фіча-прапори з життєвим циклом.
Gate'и якості: policy-as-code, SLO-guardrails, авто-відкат при деградації.
GitOps: конфігурації/політики як код, промоція по середах, аудит.
7) Інциденти і пост-мортеми
Декларація по SEV/P-рівнях, IC призначається негайно, реліз-freeze при SEV-1 +.
Burn-rate алерти: коротке і довге вікна, кворум по регіонах і типах проб.
Плейбуки: відкати, деградації, фейловер провайдерів, ліміти/ретраї.
RCA и CAPA: фактологія, причинність, вимірювані дії, контрольні точки (D + 14/D + 30).
Каталог знань: перевикористаємо шаблони та уроки.
8) Тестування надійності
Контрактні тести і consumer-driven contracts для мікросервісів.
Навантажувальні профілі по реальних патернах, тест р99/паузи GC/хвости черг.
Chaos/Resilience-кейси: вимикання залежностей, мережі, затримки; game-days і DR-навчання.
Міграції БД: expand→migrate→contract, оборотність, тести сумісності двох версій.
9) Управління ємністю і вартістю (FinOps)
Capacity Units і headroom на критичних шляхах.
HPA/VPA/KEDA за призначеними для користувача метриками і лагами черг.
Мульти-провайдери: квоти, маршрутизація по SLO/латентності, авто-фейловер.
Unit-economics: $/1k запитів, $/успішну транзакцію; оптимізація кешів, логів, egress.
10) Безпека як частина надійності
SAST/DAST/SCA, пошук секретів, SBOM, підпис образів.
mTLS і політики доступу (OPA/ABAC); Мінімальні привілеї.
Ротація ключів/сертифікатів, контроль термінів, тестові сценарії закінчення.
Інциденти безпеки - окремі плейбуки, форензика, повідомлення регуляторів.
11) Культура і процеси
SLO-огляди: щотижня/щомісяця, пріоритизація боргів над «фіолетовими фічами».
Навчання та симуляції: on-call тренінги, інцидентні репетиції, chaos-days.
Єдині стандарти: чек-листи готовності до прод, SLA комунікацій, формат пост-мортема.
Індикатори втоми алертів: шум ≤ цільового порогу, регулярний тюнінг.
12) Метрики зрілості SRE-функції
DORA-метрики: частота деплоїв, lead time, MTTR, change-failure-rate.
SLO-виконання: частка сервісів в зеленій зоні, тренд burn-rate.
Алерт-гігієна: % дій по пейджах, медіана алертів/зміну, частка помилкових.
RCA/CAPA: виконання в строк, частка системних (не персональних) причин, reopen-rate.
Вартість: $/SLO-пункт, $/1k запитів, ефективність автоскейлу.
13) Чек-лист «Готовність сервісу до прод»
- Визначені SLI/SLO, власник SLO і вікно спостереження.
- Дашборди і burn-rate алерти налаштовані, є зовнішня синтетика.
- Пайплайн: підписи/скани, контрактні/інтеграційні тести, канарка/прапори, авто-роллбек.
- Міграції БД оборотні, навантажувальні профілі покривають піки.
- Плейбуки інцидентів і контакти провайдерів; статус-сторінка.
- Capacity headroom підтверджений; HPA/KEDA і квоти провайдерів перевірені.
- Конфіги і політики - в Git, промоція по середах, аудит включений.
- Security: секрети поза кодом, mTLS/ротація, терміни TLS під контролем.
14) Анти-патерни
«99. 999% або нічого" - недосяжні цілі → вічний червоний burn-rate.
Релізи без канарок і фіч-прапорів → великі вибухи.
Одна точка моніторингу → помилкові тривоги і пропуски.
Ручні зміни конфігів у проді → дрейф і неаудованість.
Пост-мортеми без CAPA → повторювані інциденти.
SRE як «пожежні» без права змінювати архітектуру → борг не закривається.
15) Дорожня карта впровадження SRE (приклад на 3-6 місяців)
1. Місяць 1: інвентаризація сервісів і критичних шляхів; чернетки SLI/SLO; базові дашборди і burn-rate алерти; старт on-call.
2. Місяць 2: канарки/фіч-прапори, авто-відкати; GitOps конфігів; каталог плейбуків інцидентів; статус-сторінка.
3. Місяць 3: контрактні тести, навантажувальні профілі, міграції БД за схемою expand/contract; перші game-days.
4. Місяць 4-6: мульти-провайдерські маршрути, DR-навчання, оптимізація вартості, метрики зрілості, KPI для команд.
16) Підсумок
SRE - це операційна система розробки: прозорі цілі якості (SLO), керована швидкість змін (бюджет помилок), автоматизація і дисципліна інцидентів, тестування стійкості і усвідомлена вартість. При такому підході релізи стають рутиною, а надійність - конкурентною перевагою.