SLA-моніторинг: як вимірювати й довести аптайм за SLA
SLA-моніторинг - це практика незалежно перевіряти доступність сервісу, щоб у вас були позначені часом докази того, чи дотримався сервіс відсотка аптайму, обіцяного угодою про рівень обслуговування. Ці докази важать найбільше в спорі, адже власний дашборд провайдера не є неупередженим свідком власних простоїв.
Що таке SLA-моніторинг?
SLA (угода про рівень обслуговування) - це контракт, що називає конкретну ціль доступності, зазвичай місячний відсоток аптайму на кшталт 99,9%, і визначає, що станеться, якщо провайдер її не досягне: типово сервісний кредит, іноді право розірвати угоду. SLA-моніторинг - поточна вимірювальна робота під цим контрактом: перевірка обіцяного endpoint-у ззовні мережі самого провайдера, журналювання кожного простою з позначкою часу і зведення результату у відсоток, важливий для контракту. Без цього незалежного запису питання, чи виконано SLA, зводиться до того, чиїм цифрам ви довіряєте.
У кожної зі сторін є причина вести такий облік. Клієнт хоче доказ перед тим, як подавати заявку на кредит. Провайдер хоче власну чесну цифру до того, як моніторинг клієнта першим упіймає проблему.
SLA проти SLO проти SLI
Ці три терміни вживають нестрого, але вони описують три різні речі, по порядку: вимір, ціль, обіцянка.
| Термін | Що це | Приклад |
|---|---|---|
| SLI (Service Level Indicator) | Фактичний вимір, число, обчислене з реальних перевірок | Аптайм, виміряний із зовнішніх контрольних точок за останні 30 днів |
| SLO (Service Level Objective) | Внутрішня ціль для цього показника, без прив’язаних контрактних наслідків | «Ми прагнемо аптайму 99,95% цього кварталу» |
| SLA (Service Level Agreement) | Контрактна обіцянка, побудована на одній чи кількох SLO, із заявленими наслідками в разі недосягнення | «99,9% місячного аптайму, або пропорційний сервісний кредит» |
Практичний тест: якщо недосягнення числа ніде не має записаних наслідків, це SLO, а не SLA.
Що насправді дозволяє SLA на аптайм
Кожна десята частка відсотка важить більше, ніж здається на перший погляд. Ось скільки дозволяє кожен поширений рівень SLA, перш ніж його буде порушено, для суцільного 30-денного місяця й 365-денного року:
| Ціль SLA | Дозволений простій за 30-денний місяць | Дозволений простій за рік |
|---|---|---|
| 99% | 7 год 12 хв | 3 дні 15 год 36 хв |
| 99,5% | 3 год 36 хв | 1 день 19 год 48 хв |
| 99,9% | 43 хв 12 с | 8 год 45 хв 36 с |
| 99,95% | 21 хв 36 с | 4 год 22 хв 48 с |
| 99,99% | ~4 хв 19 с | ~52 хв 34 с |
Стрибок від 99,9% до 99,99% зрізає дозволений простій на 90%, приблизно з 43 хвилин на місяць до приблизно 4 хвилин. Дивіться як розрахувати аптайм про формулу, що лежить в основі, і логіку кожного рівня.
Що вимірювати, щоб число витримало суперечку
- Перевіряйте ззовні мережі провайдера, і не з однієї локації. Перевірка, що починається й закінчується на тій самій інфраструктурі, яку тестує, не здатна побачити збій на рівні мережі, що ізолює цю інфраструктуру від інтернету.
- Узгодьте інтервал перевірки з рівнем SLA. Інтервал у 5 хвилин не може надійно довести чи спростувати ціль 99,99%, бо вся місячна допустима норма менша за один цикл перевірки.
- Вимагайте підтвердження з другої локації, перш ніж рахувати простій. Власний мережевий збій однієї локації - ще не простій провайдера; інцидент, що відкривається лише коли погоджуються кілька локацій, не пускає цей шум у число.
- Виключайте лише ті вікна обслуговування, що справді задокументовані в SLA. Незаявлене обслуговування все одно рахується як простій; вікно, узгоджене заздалегідь обома сторонами, ні.
- Вимірюйте саме той endpoint, що названий у контракті, а не шлях health-check-у, що відповідає 200 незалежно від того, чи працює реальний сервіс.
- Застосовуйте поріг часу відповіді з SLA, якщо він там є. Деякі угоди визначають «недоступний» як повільніше за заявлений час відповіді, а не лише як недосяжний.
- Зберігайте сирий журнал перевірок, а не лише зведений відсоток. Для спору потрібні позначки часу, коди відповіді й тривалості, а не одне число, витягнуте з таблиці.
Як налаштувати SLA-моніторинг крок за кроком
- Запишіть точний endpoint, метрику (аптайм, час відповіді або обидва) і вимірювальне вікно, задане в SLA. Перевірка проти неправильної URL-адреси чи неправильного часового поясу дає число, яким ніхто не зможе скористатися.
- Встановіть інтервал перевірки достатньо коротким для рівня, який доводите. Як загальне правило, тримайте його добре нижче найменшого простою, дозволеного ціллю, тож ціль 99,9% потребує інтервалу в хвилинах, а не в десятках хвилин.
- Запускайте перевірки з кількох незалежних локацій, що не належать самій інфраструктурі провайдера, розкиданих по регіонах, де це важливо. HostTracker перевіряє з понад 300 контрольних точок у 158 містах, тож ви можете обрати локації, близькі до того, де сидять ваші реальні користувачі.
- Увімкніть повторну перевірку чи правило підтвердження, щоб відмову однієї локації мали підтвердити інші, перш ніж вона зарахується як простій.
- Якщо SLA встановлює поріг часу відповіді, налаштуйте його як умову відмови, а не просто повільний, але прийнятний результат.
- Додайте вікна обслуговування, узгоджені обома сторонами, до конфігурації моніторингу, щоб вони автоматично виключалися з показника аптайму замість вручну на момент звіту.
- Заплануйте регулярний звіт про аптайм із тим самим періодом, за яким вимірюють SLA, щотижня чи щомісяця, щоб число ніколи не збиралося вперше посеред спору.
Як звітувати про SLA
Запланований звіт замикає коло між вимірюванням і доведенням. Щотижневий чи щомісячний звіт про аптайм, надісланий автоматично тому, хто відповідає за стосунки з обох боків, перетворює сирий журнал перевірок на число, під яке написано SLA, ще до того, як комусь доведеться про це питати. Публічна сторінка статусу виконує ту саму роботу для будь-кого поза цим списком розсилки: спільний, позначений часом запис аптайму й інцидентів, у якому жодній зі сторін не доводиться вірити іншій на слово. Дивіться що насправді показує сторінка статусу, якщо ви ще не налаштували її. Коли у вас уже є результати перевірок за період, прогін їх через калькулятор аптайму дає відсоток без ручної арифметики.
Поширені помилки
- Вимірювання із власної мережі. Перевірка, що починається й закінчується на контрольованій вами інфраструктурі, не здатна побачити збій, що впливає лише на те, як до вас дістається зовнішній світ.
- Усереднення аптайму по кількох сервісах чи регіонах. Одне змішане число може приховати сервіс, що порушив свій SLA, поки інші підтягнули середнє назад угору.
- Рахування лише повних простоїв. Якщо в SLA є пункт про час відповіді, сервіс, що відповідає, але набагато повільніше за поріг, теж порушує угоду, навіть якщо ніколи не падав повністю.
- Запуск 5-хвилинного інтервалу перевірки проти цілі 99,99%. Арифметика не сходиться: 99,99% дозволяє близько 4 хвилин простою на місяць, менше за один цикл перевірки, тож інтервал не здатен розв’язати, чи досягнуто ціль.
Часті запитання
Як розраховується аптайм за SLA?
Так само, як розраховують будь-який відсоток аптайму: (загальний час мінус простій), поділене на загальний час, помножене на 100. Специфічна для SLA частина - який саме простій рахується: лише збої проти точного endpoint-у й вікна, названих у контракті, з виключеним узгодженим обслуговуванням. Дивіться як розрахувати аптайм про повну формулу й розібрані приклади.
Чи рахується обслуговування проти SLA?
Лише якщо його не узгодили заздалегідь. Більшість SLA виключають заплановане обслуговування, задокументоване обома сторонами наперед, але простій через незаявлену зміну чи екстрене виправлення, назване «обслуговуванням» заднім числом, усе одно рахується. Виключення стосується заявленого вікна, а не самого слова.
Який аптайм SLA вважається добрим?
99,9% - поширений базовий рівень для комерційного сервісу, що дозволяє близько 43 хвилин простою на місяць. 99,95% - розумне зобов’язання середнього рівня, а 99,99% - серйозне зобов’язання, що лишає лише кілька хвилин на місяць, і його важко досягти без надлишкової інфраструктури й дисциплінованого обслуговування. Ставтеся до будь-якої обіцянки 100% як до маркетингового твердження, а не інженерного; таблиця вище показує чому.
Як подати заявку на кредити SLA?
Загальна форма подібна в різних провайдерів: зберіть власні докази моніторингу за постраждалий період (позначки часу, перевірений endpoint, підтверджений простій), звірте їх із власною сторінкою статусу чи записом інциденту провайдера і подайте заявку через канал підтримки провайдера у вікні, встановленому їхнім контрактом, часто це задана кількість днів після інциденту. Перевірте конкретний документ SLA цього провайдера щодо точного дедлайну й потрібних доказів, оскільки ці деталі різняться й можуть швидко втрачати чинність.
Чи може одна локація моніторингу самостійно довести дотримання SLA?
Ненадійно. Одна локація не здатна відрізнити справжній простій від проблеми у власному мережевому шляху до провайдера, а це якраз той тип хибного спрацювання, який не переживе спору за SLA. Саме підтвердження з більш ніж однієї незалежної локації перед тим, як зарахувати простій, робить отримане число надійним.