SLI, SLO і SLA – що це і в чому різниця?

Вступ

Навіщо розбиратися в SLI, SLO і SLA?

Якщо ти працюєш в IT, особливо в DevOps або SRE, то, напевно, чув про ці три літери: SLI це індикатор рівня сервісу, SLO – мета рівня сервісу, а SLA – угода про рівень сервісу. Розуміння їхньої різниці критичне, якщо хочеш будувати надійні системи або підвищувати свій рівень як розробника, наприклад, на курсах FoxmindEd.

Як ці метрики пов’язані з DevOps та IT-інфраструктурою?

У світі DevOps SLA – це домовленість із замовником, SLO – це цільові показники, яких має дотримуватися команда. А SLI – це конкретні дані, які дають змогу виміряти те, наскільки добре сервіс відповідає цим цілям. Без чіткого розуміння цих метрик складно керувати надійністю сервісів. Чому? Тому що просто “робити добре” – не стратегія.

Що таке SLI (Service Level Indicator)?

Визначення SLI

Отже, SLI – це найнижча точка в нашому ланцюжку. Це конкретний вимірюваний показник, який говорить, наскільки добре працює система. Наприклад:

• Частка успішних HTTP-запитів за останні 30 хвилин.
• Час відгуку API.
• Рівень доступності сервісу.

Якщо зовсім по-простому – це як FPS в іграх. Мало? Лагає. Нормально? Граєш далі. Ось і sli service level потрібен, щоб моніторити “здоров’я” твоєї системи.

Як вимірюються SLI?

Зазвичай service level indicators рахуються у відсотках. Наприклад, якщо з 10 000 запитів 9 980 були успішними – твій SLI за успішними відповідями = 99,8%. Джерело даних може бути будь-яким – Prometheus, Grafana, ELK, або навіть кастомні логи (якщо ти хардкорщик).

Важливо пам’ятати, що SLI – не про “все підряд”. Це має бути щось, що реально важливо користувачеві. Якщо фронт вантажиться 5 секунд, користувачеві все одно, що у тебе база відпрацьовує за 10 мс.

Приклади SLI в IT-системах

• API відповідає за ≤ 300 мс у 95% випадків.
• Успішна авторизація в 99,9% сесій.
• Доступність бази даних на рівні 99,95% за місяць.

Кожен проєкт має свій набір метрик. Головне – не зібрати все підряд, а вибрати ключові показники, що впливають на UX.

Що таке SLO (Service Level Objective)?

Визначення SLO

SLO – це мета, яку команда ставить перед собою на основі SLI. Якщо SLI – це факт, то SLO – це “що ми хочемо, щоб було”. Приклад:

• “Доступність вебсайту має бути не нижче 99,9% на місяць”.
• “API має відповідати швидше за 200 мс у 95% випадків”.

По суті, це рівень, до якого ти готовий дотягувати. Він допомагає уникати перфекціонізму і фокусуватися на реально важливих речах.

Як SLO допомагає керувати надійністю?

SLO – це якір. Він допомагає зрозуміти, коли система не вкладається в рамки. Наприклад, якщо SLA обіцяє клієнту аптайм 99,5%, а твій SLO – 99,9%, у тебе є буфер. Ти можеш встигнути все полагодити, не отримавши по шапці.

Ще SLO дає змогу виміряти “бюджет помилок”. Так, ти можеш дозволити собі пару фейлів – і це нормально. Головне – не вийти за межі.

Приклади SLO в DevOps

• “99,95% успішних запитів до API”.
• “Не більше ніж 0,1% помилок під час логіна користувачів”.
• “5 хвилин максимального даунтайму на місяць”.

Хочеш, щоб прод не горів по п’ятницях? Налаштуй SLO і живи спокійно.

Що таке SLA (Service Level Agreement)?

Визначення SLA

Тепер переходимо до важкої артилерії. SLA – що це? Це формальний договір між провайдером сервісу та його клієнтом. У ньому прописані:

• Обіцянки щодо доступності.
• Рівні підтримки.
• Компенсації за порушення умов.

Якщо SLI і SLO – про інженерію, то SLA – про бізнес. Це те, що ти підписуєш із клієнтом і за що потім несеш відповідальність.

Чим SLA відрізняється від SLO?

Дивись: SLO – це внутрішній таргет, SLA – публічне зобов’язання. Ти можеш тримати SLO на рівні 99,95%, а в devops sla з клієнтом прописати 99,5% – щоб мати запас на налагодження, даунтайм і експерименти.

SLO – це твій KPI. SLA – це юридичне зобов’язання. Плутаєш їх – отримуєш штраф.

Роль SLA у бізнесі та взаємовідносинах із клієнтами

SLA – це твій щит і меч. Він встановлює правила гри і знижує ризики: для тебе – що клієнт не вимагатиме неможливого, для клієнта – що ти не зіллєшся в критичний момент. Прозорі sla devops = довіра + гроші.

Різниця між SLI, SLO і SLA

Основні відмінності та взаємозв’язок

Ось короткий breakdown:

• SLI – вимірювання. Типу “зараз у нас аптайм 99,87%”.
• SLO – мета. Наприклад, “має бути не нижче 99,9%”.
• SLA – контракт. “Якщо буде менше 99,5% – платимо неустойку”.

Усі три пов’язані, як тести, деплой і реліз – окремо працюють, але разом дають результат.

Як застосовувати SLI, SLO і SLA в DevOps?

У нормальному DevOps-циклі ти:

1. Спочатку визначаєш sli service level.
2. Потім ставиш цілі через SLO.
3. І, якщо працюєш із зовнішніми замовниками, оформляєш усе в SLA.

Це основа Site Reliability Engineering. Без цього ти просто “сподіваєшся на краще”, а не керуєш системою.

Помилки під час роботи з цими показниками

• Вибирають непотрібні метрики, які не впливають на UX.
• Роблять SLA жорсткішими, ніж реально можуть забезпечити.
• Не моніторять дотримання SLO – а потім дивуються даунтайму.

Знайомо? Ну ось.

Підпишіться на наш Ютуб-канал! Корисні відео для програмістів чекають на вас! YouTube

Оберіть свій курс програмування! Шлях до кар’єри програміста починається тут! Подивитись

Висновок

Чому важливо розуміти SLI, SLO і SLA?

Якщо ти девелопер, девопс або тімлід, розуміння цих понять – must-have. Це допомагає будувати стійкі системи, вибудовувати довіру з бізнесом і просто не гасити пожежі кожен спринт. Без них ти як капітан без карти.

Як впровадити ці метрики в роботу команди?

Почни з простого:

1. Визнач, які sli service level важливі для твого продукту.
2. Сформуй адекватні SLO – не з повітря, а за даними.
3. І, якщо потрібно – зафіксуй SLA із замовником або командою підтримки.

А головне – не перетворюй це на бюрократію. Ці штуки потрібні, щоб працювати краще, а не для звітності в Excel.