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

SLI - Service Level Indicator

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

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

Добрий SLI має три ключові властивості:

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

SLO - Service Level Objective

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

Приклади:

• «99,9 % запитів на /api/orders мають завершитися HTTP 2xx за 30 днів»
• «95 % запитів мають мати час відповіді менше 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: SLO 99,9 % означає 43 хв downtime на місяць. 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.

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