SLI vs SLO vs SLA: відмінності та як їх налаштувати

Коротко: SLI - це що ви вимірюєте, SLO - якої мети хочете досягти, SLA - контрактне зобов'язання. Ці терміни з книги Google SRE - одні з найбільш вживаних словосполучень в експлуатації веб-сервісів, і їх часто плутають.

SLI - Service Level Indicator

Конкретна метрика, якою ви кількісно оцінюєте надійність сервісу. Приклади:

• % запитів, що завершилися HTTP 2xx або 3xx за останні 30 днів
• % запитів з response time менше 500 мс
• % правильно доставлених email (delivered, не bounced)
• Співвідношення успішних платіжних транзакцій до всіх спроб

Ключові властивості доброго SLI:

• Вимірюваний - існує конкретний метод збору даних
• Релевантний користувачу - відображає реальний досвід клієнта, не внутрішню технічну метрику
• Специфічний - «uptime» занадто розпливчатий; «% успішних запитів на /api/v1/orders за 5-хвилинне вікно» - це SLI

SLO - Service Level Objective

Внутрішня мета, яке значення повинен досягати SLI. Виражається у відсотках за часове вікно.

Приклади:

• «99,9 % запитів на /api/orders мають завершитися HTTP 2xx за 30 днів»
• «95 % запитів мають мати response time менше 200 мс за 7 днів»
• «99,5 % платіжних транзакцій пройдуть успішно за календарний місяць»

SLO вищий за SLA, щоб у вас був буфер. Якщо SLA каже 99,9 %, внутрішній SLO має бути, наприклад, 99,95 % - щоб був резерв на несподівані інциденти.

SLA - Service Level Agreement

Контрактне зобов'язання перед клієнтами. Визначає, що відбудеться, якщо ви не виконаєте SLO - типово:

• Service credits - повертаєте частину місячної плати (10-50% залежно від розміру порушення)
• Termination rights - клієнт може розірвати контракт без санкцій
• Обов'язок reporting - мусите публікувати postmortem та звіти uptime

SLA має юридичні наслідки. SLO - внутрішня мета.

Error budget

Ключова концепція SRE: downtime, який ви можете дозволити собі без порушення SLO.

Приклад: SLO = 99,9 % uptime за 30 днів. Це 0,1 % допустимого downtime. 0,1 % з 30 днів = 43 хвилини на місяць. Це ваш error budget.

Практичні наслідки:

• Якщо у вас уже 35 хв downtime у місяці, залишається 8 хв до «порушення SLO». Команда має бути консервативною при наступних деплоях.
• Якщо у вас 5 хв downtime, у вас 38 хв budget на ризики - можете робити агресивніші зміни, A/B тести, експерименти.
• Error budget вирішує конфлікт між швидкістю інновації (dev team) і стабільністю (ops team). Обидва стежать за одним числом.

Практичний приклад: API e-commerce

SLI: % HTTP запитів на POST /api/checkout, що завершилися 2xx, виміряних у 1-хвилинних bucket'ах за останні 30 днів.

SLO: ≥ 99,9 % успішних запитів у rolling 30-day вікні.

SLA (для Enterprise клієнтів):

• ≥ 99,5 % uptime за календарний місяць
• При 99,0-99,5 % = 10% credit з місячної плати
• При 95,0-99,0 % = 25% credit
• При < 95,0 % = 50% credit + право розірвати контракт

Error budget: 99,9 % SLO означає 43 хв downtime / місяць у budget. SLA дає ще більший буфер перед економічним покаранням.

Підсумок: таблиця

Практичні помилки

• Занадто амбіційний SLO. 99,99 % вимагає active-active redundancy у кількох регіонах. Для маленької компанії нереально.
• Тільки uptime SLO. Web може бути «up» і все одно непридатний до використання. Додайте latency SLO та error rate SLO.
• SLA без автоматичного вимірювання. Вручну розрахований SLA-звіт ненадійний. Інвестуйте в автоматизований uptime tracking.
• SLO без наслідків. Якщо порушення SLO нікого не цікавить, ніхто ним не займається. Зв'яжіть з deploy freeze, on-call escalation тощо.

Висновок

Framework SLI/SLO/SLA - не паперова бюрократія, це мова, якою engineering команда спілкується з business stakeholders про надійність. Без цих термінів дискусія про стабільність стає суб'єктивною («наш веб нестабільний»). З ними - числовою («за останні 30 днів ми досягли 99,87 % SLI, що нижче нашого 99,9 % SLO - ось план дій»).

Вимірюйте SLI в реальному часі

ePulz.io надає історичний запис uptime з rollup 30/90/365 днів. Основа для SLO reporting.

Запустити моніторинг →