SLI (service level indicator) - вимірювана характеристика якості сервісу з погляду користувача:
- доступність: частка успішних запитів (не
5xx); - затримка: частка запитів, швидших за 300 мс;
- свіжість даних: частка оновлень, що з'явилися протягом хвилини.
SLO (service level objective) - цільове значення SLI за період:
- «99,9% запитів до API успішні за 30 днів»;
- «95% сторінок відкриваються швидше за 500 мс».
SLA (agreement) - договірне зобов'язання перед клієнтами з наслідками (компенсаціями). SLA зазвичай м'якший за внутрішній SLO, щоб мати запас.
Бюджет помилок - допустима «ненадійність», що випливає з SLO:
SLO 99,9% за 30 днів → 0,1% невдалих запитів
→ ~43 хвилини повної недоступності на місяць
Як бюджет помилок керує рішеннями:
- бюджет є - команда може ризикувати: часті релізи, експерименти, міграції;
- бюджет вичерпано - пріоритет на стабільність: заморожування ризикованих змін, виправлення причин збоїв, автоматизація відкатів.
Це прибирає вічну суперечку «розробка хоче швидше, експлуатація хоче стабільніше» - є об'єктивне число.
Чому не 100%:
- кожна наступна «дев'ятка» коштує в рази дорожче (резервування, кілька регіонів, черговість);
- користувач не помітить різниці між 99,99% і 100%, бо його мережа, провайдер і пристрій надійні менше;
- 100% означає «ніколи нічого не змінювати».
Практичні поради:
- SLI - з погляду користувача, а не серверів: «процесор на 40%» - не SLI, «90% запитів швидші за 200 мс» - SLI;
- перцентилі, а не середні: середня затримка ховає повільний «хвіст», який бачать реальні користувачі;
- кілька SLO на ключові сценарії (вхід, оформлення замовлення, пошук), а не один на весь сервіс;
- сповіщення за швидкістю витрачання бюджету (burn rate), а не за кожен окремий збій - менше хибних тривог.
Для невеликого проєкту досить почати з одного SLO доступності й одного затримки для головних сторінок - і вимірювати їх (Pulse, APM, uptime-моніторинг).
Докладніше в документації: Google SRE Book: Service Level Objectives