Error budget моніторинг: де ламається зворотний зв'язок
Помилки в сервісі є завжди — питання в тому, скільки їх допустимо. Якщо межу не вимірюють, надійність сервісу обговорюють на відчуттях: один інженер вважає нормою збій на кожну десяту сотню запитів, інший — одиничні падіння. Суперечка про якість релізу перетворюється на суперечку про смаки.
Ліміт помилок сервісу закриває саме цю діру. Він задає частку запитів, яку за період допустимо втратити або зіпсувати, і перетворює її на залишок: поки бюджет не витрачено, релізи йдуть з високою швидкістю; коли залишок на нулі, зміни зупиняють і розбираються з причинами відмов. Рішення перестає залежати від переговорної ваги учасників.
Ламається це на розрізнених метриках. Частота помилок живе в одному дашборді, затримки — у другому, недоступність — у третьому, і загальний облік ніхто не веде.
Error budget моніторинг передбачає зведення цих джерел в одну величину — інакше бюджет виглядає здоровим, а користувачі йдуть з повільних сторінок, де формально відмов не було.
Другий збій — порогові тривоги, виставлені за старою інтуїцією. Поріг, який спрацьовує на кожне коливання, знецінює чергування: інженер звикає закривати повідомлення не дивлячись, і справжній інцидент губиться в шумі. Тривога має спиратися на швидкість вигорання бюджету, а не на статичне число.
Розбираємо, як побудувати такий зворотний зв'язок на Prometheus і Grafana: від узгодження цільового рівня до правил, які самі зупиняють реліз.
Що дає керований ліміт помилок на сервісі
Ліміт помилок виводиться з цільового рівня доступності: сервісу дозволено витратити певну частку невдалих запитів за вікно спостереження, і цей залишок стає спільним лічильником для розробки та експлуатації.
Поки запас додатний, релізи йдуть звичайним ритмом; коли він тане, зміни починають конкурувати за право на розгортання.
Тривоги прив'язуються не до одиничних сплесків, а до швидкості вичерпання залишку, тому короткий збій не піднімає чергового, а стійка деградація сигналить до того, як сервіс опуститься нижче цільового рівня.
Частка хибних тривог падає, а час реакції на відмову перестає бути відчуттям і стає величиною: видно, скільки минає від першого відхилення до втручання і на якому кроці втрачається найбільше.
Черга релізів теж підпорядковується правилу: коли ліміт вичерпано, спочатку відновлюють надійність і лише потім розгортають функціональність.
Так зникає клас відмов, який раніше виникав через накопичення дрібних непомічених деградацій — кожна окремо нижче порога, а разом вони виводять сервіс за цільовий рівень.
Результат обчислюється у частках: зниження частки невдалих запитів, скорочення ручних розборів, менше тривог, які закривають без дій.
Розрахунок залишку та швидкості його вигорання живе в Prometheus і виводиться на спільну дошку — інженери бачать запас у годинах і обговорюють рішення, а не те, «чи погано зараз».
Режими розрахунку: вікно, швидкість і строгість
Режим розрахунку визначає, наскільки швидко система помічає деградацію і як тлумачиться залишок бюджету.
У Prometheus бюджет обчислюється правилом запису поверх лічильників успішних і помилкових відповідей, а панель у Grafana лише відображає вже пораховане значення — тому строгість сигналу задається тут, а не в дашборді.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Ковзне вікно | Безперервний потік запитів, потрібно ловити деградацію за хвилини | Короткий сплеск спалює бюджет; результат залежить від глибини зберігання метрик |
| Календарний період | Звітність і планування: місяць або квартал з обнуленням | На початку періоду бюджет завжди повний, помилки перших годин забуваються |
| Бюджет за запитами | Сервіси, де важлива частка успішних відповідей | Не бачить повільні відповіді, якщо вони формально завершилися успішно |
| Бюджет за часом | Користувацькі сесії, доступність за хвилинними інтервалами | Потребує акуратної агрегації інтервалів, чутливий до коротких обривів |
| Зведений ліміт на кілька сервісів | Спільний бюджет платформи та пріоритизація між командами | Один сервіс здатен з'їсти бюджет сусідів — потрібні правила розщеплення й квоти |
На практиці режими комбінують: ковзне вікно дає оперативний сигнал черговому, календарний період — основу для розбору підсумків, а зведений ліміт утримує загальні витрати.
Розбіжність між бюджетом за запитами й за часом — добрий індикатор: частка помилок у нормі, а користувачі скаржаться на недоступність, отже, проблема в таймаутах і ретраях, а не в кодах відповіді.
Впровадження: від аудиту метрик до регламенту моніторингу
Робота триває в шість етапів і починається не з графіків, а з інвентаризації того, що вже збирається.
Порядок принциповий: бюджет помилок обчислюється з тих самих даних, за якими спрацьовують оповіщення, інакше черговий бачить розбіжність між панеллю і сигналом і перестає довіряти обом цифрам.
- Аудит метрик. Розбираємо джерела: які показники вже є, де прогалини, які дублюють одне одного, де кардинальність зростає швидше, ніж користь. На виході — список робочих SLI для кожного сервісу та перелік того, що доведеться додати.
- Схема розрахунку. Фіксуємо вікно (ковзні 30 днів), цільовий рівень доступності, визначення «поганої» події та правила агрегації за сервісами. Агрегати обчислюються заздалегідь, а не на кожен запит панелі, — інакше дашборд із десятком сервісів починає гальмувати й брехати щодо часу.
- Правила та пороги. Налаштовуємо багаторівневі оповіщення: попередження при вигоранні чверті бюджету, тривога — при половині, зупинка релізів — при вичерпанні. Поріг на швидкість вигорання ловить швидкий провал раніше, ніж його покаже добовий графік.
- Перевірка на історичних даних. Проганяємо схему на минулих інцидентах: чи зловили б сигнали, скільки було хибних, чи збіглися пороги з реальною деградацією. Пороги калібруємо за фактом, а не за інтуїцією.
- Регламент чергування. Описуємо дії на кожному рівні: кого будити, що дивитися в першу чергу, коли заморожувати розгортання. Регламент узгоджуємо з тими, хто ходить у чергування, — документ, написаний без них, не працює.
- Передача та навчання. Розбираємо з командою живі сценарії, домовляємося про розбір кожного спрацьовування. Після цього схема живе сама: правила та пороги переглядаються за підсумками кварталу.
Що залишається в репозиторії після здачі робіт
Після здачі робіт у вас залишається робочий контур контролю надійності, а не набір розрізнених налаштувань.
Усі артефакти лежать у вашому репозиторії та вашому контурі: команда може відкрити будь-який із них, побачити, звідки береться кожна цифра, і змінити поведінку системи без нас.
- Конфігурації правил — джерела запису метрик і обчислюваних виразів для бюджету помилок, розкладені за сервісами й середовищами, з версіонуванням та осмисленими іменами.
- Схема розрахунку — документ, де зафіксовано, які події вважаються збоєм, як вони нормуються на загальний обсяг запитів і на якому вікні усереднюються. Під час розбору інциденту логіку не доводиться вгадувати.
- Політики оповіщень — пороги, групування та маршрути: що йде черговому одразу, що чекає підтвердження, що потрапляє лише у звіт.
- Інструкція черговому — покроковий розбір: як читати графік вигорання бюджету, які рішення ухвалювати за різної швидкості витрат, куди ескалювати і що фіксувати після.
- Регламент перегляду рівнів — періодичність і критерії: коли мету щодо надійності посилюють, коли послаблюють, хто ухвалює рішення і як воно фіксується в історії.
- Шаблони дашбордів — панелі для окремого сервісу та зведення за всіма, з однаковою логікою розрахунку, щоб нова команда не малювала свій варіант з нуля.
- Перевірки правил — набір тестів, які ловлять зламані вирази та порожні вибірки до розгортання, а не в момент інциденту.
Кейс: сервіс платежів, тривоги та час реакції
Платіжний сервіс з безперервним потоком транзакцій: кілька чергових у зміні, усі тривоги падають в один спільний канал, error budget ніхто не рахував. Правила тривог налаштовувалися за порогами «на око» і не переглядалися — сигналів ставало більше, а довіри до них менше.
Що було
Понад половину спрацьовувань закривалися як хибні: короткий сплеск затримки, одиничні помилки на одному екземплярі, шум від фонових завдань. Чергова зміна витрачалася на ручні розбори — 5-6 за зміну, з них корисних одиниці.
Час виявлення вимірювався десятками хвилин: справжня відмова тонула в потоці хибних, а частина відмов спливала вже за зверненням клієнтів.
Що змінили
Прив'язали тривоги до бюджету помилок: для платіжного API зафіксували цілі щодо доступності та часу відповіді, і сигнал тепер обчислюється за швидкістю витрат бюджету у вікні, а не за одиничним сплеском.
Розділили повідомлення на два класи — ті, що будять чергового, і ті, що розбираються в робочий час. Збір метрик і правила тривог перенесли в Prometheus і Grafana, кожен нічний сигнал розбирається на черговій зміні.
| Показник | До | Після |
|---|---|---|
| Частка хибних тривог | ~70% | ~15% |
| Час виявлення | десятки хвилин | 2-4 хвилини |
| Пропущені відмови | знаходили за скаргами | одиниці за квартал |
| Ручні розбори за чергування | 5-6 | 1-2 |
Окремий ефект — передбачуваність зміни: черговий знає, що нічний сигнал означає реальні витрати бюджету, а не шум. Відмови почали знаходити до звернень клієнтів, а розбір спрацьовування перетворився на коротку процедуру замість розслідування.
Чим SLO відрізняється від SLA і що налаштовувати першим?
Різниця проста, але плутають її найчастіше за все інше. SLA — зобов'язання перед замовником: зафіксовано в договорі, має вимірюване формулювання та прописані наслідки порушення. SLO — внутрішній цільовий рівень, за яким команда ухвалює рішення про релізи та пріоритети.
Порядок налаштування один: спочатку внутрішні цілі, потім договірні. SLO задають суворіше за SLA, щоб між ними залишився запас — відхилення гасяться всередині команди й не перетворюються на порушення зобов'язань.
Зворотний порядок дає обіцянку без даних: незрозуміло, який запас реально є і чи витримає його інфраструктура.
Error budget — кількісний вираз SLO: скільки недоступності або частки неуспішних запитів допустимо витратити за вікно. Поки бюджет цілий, релізи йдуть звичайним темпом; бюджет підійшов до межі — пріоритет зміщується на надійність.
У Prometheus це правила підрахунку успішних запитів і залишку бюджету, у Grafana — панель витрат і алерти на швидкість вигорання, а не на одиничний збій.
Наслідки порушення теж різні, і змішувати їх не можна. Порушення SLO — подія внутрішня: зупинка релізів, повернення зусиль у надійність, перегляд нереалістичної мети. Порушення SLA — зовнішнє: зобов'язання та все, що за ними закріплено. Тому спочатку вимірюють себе, а вже потім обіцяють.
Часті технічні сумніви перед впровадженням
Сумніви перед впровадженням бюджету помилок зазвичай стосуються не інструмента, а того, наскільки чесно дані відображають реальність сервісу. Нижче — ситуації, які трапляються найчастіше, і те, як ми закриваємо їх під час налаштування контролю в Prometheus і Grafana.
Частина метрик надходить із перебоями — розрахунок буде занижений?
Бюджет рахуємо за тими вікнами, де дані є, а пропуски позначаємо окремою ознакою і не згортаємо в «нуль помилок». Якщо інтервал випав повністю, він виключається зі знаменника — інакше доступність у звіті виглядає кращою, ніж її бачили користувачі.
Показник шумить: сплески не пов'язані з реальними збоями?
Шум давимо не порогом «на око», а на рівні визначення показника: прибираємо службові перевірки, технічні відповіді та внутрішні запити між сервісами, а агрегуємо на вікні, яке переживає одиничний сплеск. Тоді витрати бюджету відображають втрати користувачів, а не фонову активність.
Сервісом користуються кілька команд — чий це бюджет?
Бюджет прив'язуємо до власника сервісу, але витрати розмічаємо за споживачами: кожна команда бачить свою частку згоряння. Суперечка «хто просадив доступність» вирішується за даними, а не на загальній зустрічі.
Пороги задали формально — контроль перетвориться на звітність?
Рівні беремо від фактичної поведінки сервісу за минулий період, а не від бажаного. Переглядаємо їх за розкладом — після великих змін в архітектурі або коли бюджет стабільно не витрачається взагалі.
Обговоримо вашу задачу й повернемося з планом робіт
Щоб оцінка була предметною, а не «на око», нам потрібен короткий розбір вашої інфраструктури: як збираються метрики, де зберігаються, хто і як реагує на спрацьовування. Опишіть задачу у вільній формі — повернемося з оцінкою обсягу та планом робіт, розбитим за етапами.
Що уточнюємо на дзвінку:
- джерела метрик і поточна схема збору — Prometheus, експортери, агенти на вузлах;
- перелік сервісів та їхні власники: для кого рахуємо error budget і за якими SLI;
- вікна та політика розрахунку: ковзне вікно, пороги вигорання, що вважаємо недоступністю;
- поточні алерти й чергування — які спрацьовування шумлять, які пропускаються;
- доступи та обмеження: контури, закриті мережі, права на зміну правил і дашбордів;
- вимоги до звітності — зведення для керівництва, періодичність, глибина історії;
- формат передачі: репозиторій з конфігурацією, runbook, навчання чергової зміни.
За підсумками фіксуємо склад команди під задачу — хто відповідає за правила запису, хто за дашборди та алерти, хто за передачу знань. План узгоджуємо до старту, щоб ви бачили проміжні результати на кожному етапі, а не лише фінальний звіт.
Розкажіть, що зараз болить: шумні алерти, відсутність бюджету на надійність або розрізнені дашборди. Цього достатньо, щоб ми повернулися з планом та оцінкою.
