Що для користувача означає успіх
Процес живий, ендпоінт повертає HTTP 200, а замовлення не створилось. Або створилось із неправильною сумою. Спочатку визначаємо успішну операцію для продукту: коректне підтвердження, знайдений товар, доступний файл, готовий фоновий звіт.
SLI вимірює якість, SLO задає ціль. Для прикладу оберемо не менше 99,9% коректних підтверджень за 30 днів. Домовляємося, які спроби входять у розрахунок і який результат є поганим. Інакше зелений графік легко отримати, виключивши зі знаменника проблемні запити.
Поруч тримаємо RPS, помилки, latency та насичення ресурсів. Вони пояснюють потік і наближення до межі. CPU корисний для діагностики, але його високий рівень ще не привід будити чергового. Терміновість залежить від впливу на продукт і часу до погіршення.
Для замовлення приймання й завершення різні. Відповідь 202 із задачею в черзі не є оформленим замовленням. SLI може рахувати правильне завершення в потрібний час. Визначення йде за обіцянкою клієнту, а не лише за відсутністю серверної помилки в швидкому HTTP-виклику.
Місце вимірювання змінює покриття. Внутрішній сервіс не бачить відмову входу, клієнтський сигнал не завжди доставить телеметрію. Джерело обираємо під ціль і записуємо пропущену ділянку. Одне вимірювання не описує весь досвід автоматично, навіть якщо його легко показати одним зеленим графіком.
Виключення мають зміст. Невірний ввід може не бути збоєм, наша помилкова валідація є. Виключення всіх 4xx приховає авторизацію чи доступ. Класифікація відповідає відповідальності й поведінці продукту. Її зміна теж впливає на порівняння періодів, тому не робимо цього непомітно.
Критичні шляхи видимі окремо. Каталог може домінувати в доступності та сховати неробочу оплату. Межу обираємо за важливістю, не робимо SLO кожному ендпоінту. Головні обіцянки не розчиняються, а моніторинг не стає некерованим каталогом сотень майже однакових цілей.
Ціль погоджуємо з потребою й ціною. Додаткова дев'ятка вимагає ресурсу, часу та процесу. Робочі години відрізняються від цілодобової оплати. SLO є домовленістю про якість і реакцію, а не відсотком для презентації. Він має впливати на рішення щодо розвитку й підтримки.
Графік теж може вводити в оману
Успішні операції й помилки дивимося окремо. Під час аварії швидкі відмови можуть навіть покращити середню latency. Перцентилі показують хвіст, але p99 на малій вибірці сильно коливається. Поруч потрібні трафік і розріз за важливими ендпоінтами.
Середнє p99 кількох інстансів не стає p99 сервісу. Потрібно об'єднати спостереження відповідним способом, наприклад сумісними гістограмами. Межі бакетів обираємо під ціль. Якщо SLO стосується секунди, грубі бакети навколо неї зроблять перевірку неточною.
Для черги мало довжини. Потрібні швидкість надходження й обробки та вік найстарішої задачі. Сто задач можуть зникнути за секунду або висіти годинами. Для періодичної джоби потрібен останній успішний запуск: нуль помилок може означати, що вона взагалі не стартує.
Лічильник накопичує події, тому приріст враховує вікно й рестарти. Перезапуск не має показувати від'ємний потік. Зміна графіка після деплою спершу потребує перевірки семантики, а не висновку про поведінку клієнтів. Інструмент міг змінитися раніше, ніж система стала іншою.
Бакети приблизно описують розподіл. Межі під рішення роблять оцінку корисною, нескінченна точність множить ряди й зберігання. Поріг секунди потребує іншого набору, ніж широкий діагностичний діапазон. Точність визначається питанням, яке команда хоче вирішити за цим графіком.
SQL займає 30 мс, замовлення чекає п'ять хвилин. Обробник швидкий, результат користувача повільний. Для фону рахуємо очікування, виконання й шлях до завершення окремо. Правильна межа не дозволить видати прискорення маленького кроку за покращення всього продуктового сценарію.
Відсутність даних не є нулем. Збирач може зламатися без нового значення помилки. Потрібні виявлення відсутності й очікуваний інтервал. Добова джоба та постійний трафік різні. Інакше найспокійніший дашборд може належати інциденту, який саме зараз перестав бути видимим.
Коротке вікно реагує й шумить, довге згладжує початок. Для релізів потрібне порівнянне навантаження. p99 без числа спостережень, маршруту й періоду не доводить покращення для людей. Контекст поруч із числом потрібен для рішення, а не лише для повноти звіту.
Корисні метрики без вибуху кардинальності
Для причин додаємо очікування пулу, блокування, час апстриму, пам'ять і диск. У метрики мають бути зрозуміла одиниця й точка вимірювання. Тоді за повільним замовленням можна побачити, де запит витратив час.
Кардинальність росте з поєднаннями лейблів. 20 маршрутів, п'ять статусів і десять інстансів дають до 1000 комбінацій. User ID змусить кількість рядів рости з аудиторією. Гістограма створює кілька рядів на набір лейблів, тому ціна помилки буде ще вищою.
Для маршруту залишаємо шаблон, наприклад /orders/:id. Конкретний ID і контекст шукаємо в логах або трейсах. Збираємо те, що допомагає розбору: тіло запиту та секрети не стають кориснішими через простоту запису. У моніторингу теж є бюджет зберігання й обробки.
Пулу потрібні зайнятість, очікувачі й час. Апстриму затримка, результат і таймаути. Пам'яті розділення корисного стану, кешу й витоку. Сигнали підказують наступну перевірку, не готовий діагноз. Панель має допомагати дослідженню, замість автоматично назвати причиною перший показник, який змінився.
Лейбли є контрактом з обмеженими значеннями. URL, назва клієнта й текст помилки ростуть без контролю. Малий трафік зараз не гарантує дешевий ріст. Перевіряємо можливий набір до широкого використання. Потім змінити метрику буде складніше, бо на неї вже спиратимуться правила й дашборди.
Логи й трейси теж мають бюджет. Тіло кожного запиту дорого й ризиковано для даних. Семплінг економить, але може пропустити рідкісне. Правила для важливих помилок зберігають контекст без копіювання всього. Строк і спосіб доступу відповідають задачі розбору, а не зручності збирача.
Кореляційний ID зв'язує одну історію, метрика показує масштаб. Алерт має вести до прикладів, на яких перевіряється причина. Дашборд та інструмент розслідування з'єднуються. Окремий трейс не замінює частоту, загальний графік не пояснює послідовність подій конкретного збою.
Перевіряємо вплив інструментування. Часті оновлення, синхронні логи й обчислення в обробнику можуть сповільнити шлях. Спостереження має передбачувано деградувати під тиском. Інакше під час аварії команда рятуватиме ще одну залежність, яка створена допомагати саме в цій ситуації.
SLO та error budget: коли час реагувати
SLO 99,9% залишає 0,1% поганих операцій за вікно. На мільйон запитів це 1000 помилок. Якщо поточна частка виросла до 1%, бюджет витрачається вдесятеро швидше допустимого темпу. Burn rate дорівнює 10.
За рівномірного потоку й вікна 30 днів цей темп витратив би повний бюджет приблизно за три дні. У житті трафік змінюється й частина бюджету вже витрачена. Зіставляємо орієнтир із залишком, масштабом збою та часом на виправлення.
Поєднуємо довге й коротке вікна: перше показує значну витрату, друге перевіряє, чи проблема триває. На малому трафіку потрібні інші умови. Один збій із десяти запитів дає 10%. Враховуємо вибірку, важливість операції та додаткові перевірки, щоб кожна випадковість не стала викликом.
Burn rate співвідносить погане з допустимим. Один відсоток для 99% є допустимим темпом, для 99,9% вдесятеро вищим. Тривалість і масштаб все одно важливі. Відношення дає основу реакції, не повну класифікацію інциденту. Воно не скасовує зміст операції та залишок бюджету.
Місячне вікно перевіряє обіцянку, короткі шукають поточне. Умова має показувати значну витрату й продовження збою. Інакше сплеск викличе людину вже після самостійного відновлення. Два вікна допомагають відділити історичний слід від проблеми, яка ще потребує втручання.
Малий трафік доповнюємо синтетичною перевіркою. Вона не замінює користувацький SLI, але бачить повністю зламаний шлях за відсутності запитів. Дані безпечні, без справжніх списань та небажаних бізнес-дій. Покриття перевірки описуємо, щоб не приписати їй весь реальний досвід клієнта.
Бюджет впливає на релізи. За сталої поганої якості ризикові фічі можуть погіршити стан. Можна направити час на причини та змінити rollout. Бізнес має знати домовленість заздалегідь. Інакше показник стане звітом, який лише констатує проблему й не впливає на роботу.
Бюджет не дозволяє будь-який неправильний результат. Фінансова помилка, витік і пошкодження можуть вимагати реакції за малого відсотка. SLO описує окрему якість, інші гарантії лишаються. Моніторинг повинен бачити критичні інваріанти, а не тільки агреговану частку доступних операцій.
Алерт має допомагати діяти
Будимо чергового, коли очікування збільшує шкоду й людина може втрутитися. Повільний ріст диска можна спершу розібрати як задачу. Якщо часу до заповнення менше, ніж треба на розширення чи очищення, реакція термінова. Одного відсотка заповнення мало.
В алерті потрібні сценарій, масштаб, початок, відповідальний і runbook. У ньому пишемо перевірку причини, обмеження шкоди та підтвердження відновлення. Порада перезапустити сервіс без пояснення наслідків ризикована: рестарт може обірвати роботу або посилити навантаження на залежності.
Пов'язані симптоми групуємо. Якщо апстрим упав, повідомлення від кожного інстансу не додасть інформації. Приглушення перевіряємо, щоб окрема проблема не зникла за спільним інцидентом. Повтори й ескалація потрібні, якщо перший виклик залишився без відповіді.
Розділяємо терміновий виклик, робоче повідомлення й задачу. Один канал втрачає увагу. Рівень має строк і власника, здатного діяти. Загальний чат не призначає відповідальність. Потрібно знати, хто прийме контекст і виконає корисну дію в потрібний час, а не лише прочитає повідомлення.
Runbook починається з перевірки: графіки, масштаб, недавні зміни. Далі безпечне зниження шкоди й обмеження дій. Потрібний уночі недоступний дозвіл є ризиком до інциденту. Інструкція повинна відповідати реальному доступу чергового, а не можливостям автора документа в робочий день.
Сервіс і середовище прибирають плутанину. Хост, код і загальний дашборд змушують будувати контекст з нуля. Виклик пояснює вплив і дає вхід у діагностику. Внутрішня умова без користувацького наслідку додає роботу саме тоді, коли швидкість розуміння найважливіша.
Ескалація враховує і відсутність відповіді, і відсутність прогресу. Людина підтвердила, але не має доступу або застрягла в гіпотезі. Правила залучення та передачі контексту не дозволяють вважати підтвердження доказом виправлення. Власник інциденту має розуміти, коли потрібна допомога.
Групування тестуємо кейсами. Спільні симптоми об'єднуються, незалежні відмови не зникають за тишею. Відновлення теж має правильний сигнал. Закритий виклик не доводить, що результат знову коректний. Перевіряємо саме ту гарантію, порушення якої стало причиною реакції.
Тестуємо моніторинг як окремий шлях
У тестовому середовищі створюємо відомий збій і проходимо ланцюжок: метрика, правило, доставка, runbook, виявлення відновлення. Окремо перевіряємо зникнення даних і відмову моніторингу. Зламаний збирач може зробити дашборд спокійнішим саме під час аварії.
Після інциденту розбираємо пропущені сигнали, шум і час до корисної дії. З'ясовуємо причину зайвих алертів: поріг, вимірювання або вже непотрібна умова. Просто підняти поріг означає ризик пропустити наступний збій. Оцінюємо моніторинг за тим, чи допоміг він зрозуміти проблему й відновити продукт.
Тест має очікуваний час. Вносимо збій, відмічаємо початок, вимірювання, правило й доставку. Так відділяємо збір від каналу. Сам прихід алерта не пояснює втрачений час. Повна послідовність показує, чи людина отримає можливість діяти до важливої межі шкоди.
Доставку перевіряємо поза зручним робочим столом. Ноутбук закритий, дозволи повідомлень неправильні, телефон мовчить. Потрібні погоджений канал і резерв. Це перевірка узгодженого чергування, не некерований тестовий шум. Після вправи фіксуємо, який шлях працював і що треба виправити.
Розбір зіставляє сигнали з використаними. Десятки графіків можуть не відповісти на головне. Прибираємо зайве й додаємо контекст. Дашборд росте навколо задач діагностики, не всіх доступних метрик. Корисність вимірюється здатністю скоротити шлях до рішення, а не кількістю віджетів.
Поріг перевіряємо історією й потрібним збоєм. Менше шуму не має прибрати початкову мету. Нова робота потребує нового пояснення. Правила без власника стають фоном, особливо коли ніхто вже не пам'ятає очікувану дію. Видалення такого правила теж повинно бути свідомим рішенням.
Моніторинг має цикл підтримки: власник, тести, користь і зміни системи. Ростуть шляхи й межі. Налаштування запуску не гарантує видимість наступного року. Регулярний перегляд пов'язує вимірювання з поточним продуктом, щоб команда помічала ті відмови, на які справді може й повинна реагувати.
Збираємо моніторинг оформлення замовлення
Успіх є правильним замовленням у погоджений час, не швидким входом. Розділяємо помилку вводу й нашу, обираємо джерело та відмови, яких воно не бачить. Оплата видима за великої кількості читань. Визначення має бути однаковим у метриці, SLO й очікуванні бізнесу, інакше зелений показник не описує користувацький результат.
Для причин додаємо чергу, пул, апстрим і завершення. Метрики мають обмежені шаблони, історії ID у логах і трейсах. Бакети біля цілі й відсутність даних перевірені. Дашборд з'єднує масштаб із прикладами. Так черговий переходить від сигналу до перевірки гіпотези, не збираючи весь контекст із нуля.
Виклик потребує суттєвого бюджету й поточного збою. Малий потік має безпечну синтетику, інваріанти окремі сигнали. Повідомлення містить вплив, власника та runbook з доступними діями. Доставка й ескалація перевірені. Спільний канал не замінює відповідальність, а підтвердження не означає відновлення правильних замовлень.
Створюємо тестову відмову апстриму, відмічаємо показник, правило, доставку й дію. Відновлення перевіряє результат, не закриття повідомлення. Вправа знаходить затримку й відсутній контекст. Моніторинг стає робочим через цей шлях, а не кількість графіків. Історія тесту пояснює, які частини справді перевірені та що ще лишилось припущенням.
Після вправи кожна знайдена проблема має власника. Одній потрібен інший поріг, другій додатковий контекст, третій доступ у runbook. Не всі проблеми лікуються більшою кількістю алертів. Перевіряємо, чи зміна скорочує час до корисної дії й не приховує важливий збій. Це конкретний критерій якості налаштування.
Коли продукт змінюється, повторюємо визначення успіху та покриття. Нова черга, залежність або тип оплати змінює місця відмови. Старий алерт може лишитися корисним для свого кроку, але вже не описувати весь шлях. Підтримка моніторингу йде разом із реалізацією, щоб потрібний результат залишався видимим після кожного значного релізу.