Ваш сервіс зростає, але кожна п'ятниця приносить падіння — то навантаження, то витік пам'яті, то помилка конфігурації. Один інцидент тягне за собою інший, розробники втрачають фокус, а ops нескінченно лагодять одне й те саме. Знайома картина? SRE практики (Site Reliability Engineering) створені, щоб розірвати це коло.
Ми впроваджуємо підхід Site Reliability Engineering (SRE) — не призначаємо "інженера надійності" з новим титулом, а будуємо інженерну систему контролю надійності на основі даних. Починаємо з вимірювання: SLI, SLO, Error Budget. Це фундамент, який перетворює "треба бути надійніше" на конкретні метрики та дії. Замість інтуїтивних рішень — кількісні цілі. Замість героїчних деплоїв — баланс швидкості та стабільності через Error Budget. Замість рутини — автоматизація toil. Ми впроваджуємо ці практики ітеративно, від 2 тижнів до 3 місяців, з гарантованими прозорими результатами на кожному етапі. Наш досвід показує, що навіть без повної трансформації перші результати — зниження MTTR на 30-50% (в 2-3 рази краще, ніж реактивний підхід) та економія операційного бюджету — помітні вже через місяць.
Детальніше див. Wikipedia
Фундамент: SLI, SLO, Error Budget
SLI (Service Level Indicator) — конкретна метрика, яку ми вимірюємо. Не «сервіс працює», а «відсоток успішних HTTP-запитів за 5-хвилинне вікно».
# SLI для availability: ratio успішних відповідей
sum(rate(http_requests_total{status!~"5.."}[5m])) / sum(rate(http_requests_total[5m]))SLO (Service Level Objective) — цільове значення SLI. «99.9% запитів завершуються успішно» — це SLO. Це внутрішня ціль, не обіцянка клієнтам.
Error Budget — скільки «помилок» допустимо за період. При SLO 99.9% за 30 днів error budget = 0.1% * 30 * 24 * 60 хвилин = 43.2 хвилини простою або еквівалентної кількості помилок. Це ключова концепція: error budget — це ресурс, яким володіє продуктова команда для ризикованих деплоїв.
Якщо error budget вичерпано — деплої зупиняються до наступного періоду або до покращення reliability.
Приклад розрахунку Error Budget для e-commerce
Для інтернет-магазину з SLO 99.9% та місячним періодом error budget становить 43 хвилини. Кожен деплой «споживає» частину цього бюджету: якщо реліз викликає 5 хвилин помилок, то при залишку < 5 хвилин деплой блокується. Це дозволяє балансувати швидкість розробки та надійність.Як визначити правильний SLO?
Головна помилка — брати SLO з повітря («давайте 99.99%»). SLO визначається через три кроки:
Крок 1. Виміряйте поточний стан. Який у вас реальний availability за останні 90 днів? Prometheus + recording rules дадуть відповідь. Не можна ставити SLO вище поточного рівня без плану інвестицій у reliability.
Крок 2. Проаналізуйте досвід користувачів. Який рівень помилок користувачі помічають? Для веб-сервісів — зазвичай 1% помилок за 1 хвилину стає помітним. Для платіжних систем поріг нижче.
Крок 3. Врахуйте бізнес-контекст. Яка вартість downtime? Для e-commerce кожна хвилина простою — прямі втрати виручки. Для внутрішніх інструментів поріг інший.
Типовий набір SLO для backend API:
- Availability: 99.9% успішних запитів (5xx не вважаються успішними)
- Latency: 95-й перцентиль < 200ms, 99-й < 500ms
- Error rate: < 0.1% для критичних ендпоінтів
Чому toil — головний ворог reliability?
Toil — це ручна, повторювана операційна робота, яка не покращує систему, а просто підтримує її роботу. Перезапуск сервісу раз на тиждень, ручне очищення логів, регулярні тікети на одне й те саме.
Правило SRE: не більше 50% робочого часу має йти на toil. Решта — engineering work: усунення причини витоку пам'яті, автоматизація очищення логів, усунення причини повторюваних тікетів.
Вимірюємо toil: tracking категорій завдань протягом 2-3 тижнів дає картину. Типово виявляється, що 3-4 повторювані завдання займають 60-70% операційного часу. Автоматизація toil знижує operational load в 2-3 рази та зменшує вартість експлуатації. Типова економія від автоматизації toil становить $50,000–100,000 на рік для команд з 5-10 інженерів.
Capacity planning
Проактивне планування потужності — SRE практика, що запобігає інцидентам через вичерпання ресурсів. Це не «додати ресурсів коли гальмує».
Метрики для capacity planning: CPU/memory utilization trends, request rate growth, storage growth rate. Прогноз на 3-6 місяців вперед на основі історичних даних. Karpenter в Kubernetes автоматизує scaling нод, але не замінює розуміння, чи вистачить лімітів хмарного акаунта.
Reliability testing
Chaos Engineering — не для всіх і не одразу. Chaos Monkey, Litmus Chaos або просто kubectl delete pod на production pod має сенс лише після того, як у вас є SLO, вимірювання error budget та впевненість, що система відновлюється автоматично.
Починати має сенс з gameday: контрольована симуляція збою в staging за участю всієї команди. Це перевіряє runbooks, комунікацію та реальну швидкість відновлення.
Як проходить впровадження
SRE-практики впроваджуються ітеративно, від 2 тижнів до 3 місяців. Процес складається з чотирьох кроків: (1) Baseline, (2) Toil audit, (3) Reliability engineering, (4) Chaos/Gameday.
| Фаза | Що робимо | Результат |
|---|---|---|
| Baseline | Визначаємо SLI/SLO, налаштовуємо вимірювання error budget | Знаємо поточний рівень надійності |
| Toil audit | Ідентифікуємо та починаємо автоматизувати toil | Вивільняємо інженерний час |
| Reliability engineering | Усуваємо системні причини інцидентів | Зниження MTTR та Change Failure Rate |
| Chaos / Gameday | Перевіряємо стійкість контрольованими збоями | Підтверджена надійність |
Що входить в роботу
| Deliverable | Опис | Формат | Срок |
|---|---|---|---|
| Аудит стану | Вимірювання SLI, SLO, error budget, toil | Звіт з метриками | 1-2 тижні |
| План автоматизації | Пріоритезація toil та roadmap | Документ з етапами | 1 тиждень |
| Налаштування observability | Дашборди, алерти, recording rules | Prometheus/Grafana | 2-3 тижні |
| Впровадження SLO та error budget | Процеси та інструментарій | Runbook, код | 2-4 тижні |
| Навчання команди | Тренінг з SRE-практик | Воркшоп, документація | 1 день |
Вартість впровадження SRE-практик окупається за рахунок скорочення простоїв та toil. Мінімальний горизонт для видимих результатів — 4-6 тижнів. Оцініть ваш проект — напишіть нам для аудиту. Отримайте консультацію з SRE-практик. Наша команда має 5+ років досвіду в SRE та провела більше 30 впроваджень. Зниження operational cost на 40-60% за рахунок автоматизації — типовий результат.
