Налаштування SLA-моніторингу: де відмовляє веб-застосунок
SLA моніторинг налаштування починається не з дашборду, а з розбору ланцюжка запиту: розв'язання імені, встановлення захищеного з'єднання, балансувальник, процес застосунку, пул з'єднань до бази, синхронні виклики зовнішніх сервісів.
Простій веб-застосунку рідко настає цілком — спочатку відвалюється одна ланка, а інші шари продовжують відповідати. Завдання першого етапу — зрозуміти, на якій ділянці губиться користувацький запит і яким сигналом це видно ззовні.
Далі розділяємо моніторинг доступності на зовнішній і внутрішній. Проби з кількох точок бачать лише крайній шар: чи відповідає сторінка, чи вкладається відповідь у відведений час, чи проходить ключовий сценарій — вхід, пошук, оформлення.
Метрики самого застосунку знають те, що ззовні не видно: насичення пулу з'єднань, зростання черги обробки, частку відповідей з помилкою на конкретному маршруті.
Склеюємо обидва контури по одному шляху запиту і знімаємо збір у Prometheus, інакше перевірка живості віддає успіх, поки сценарій користувача вже лежить.
Хибні спрацьовування — не дрібниця, а пряма ціна налаштування. Поодинока проба з однієї точки, поріг без утримання за часом, відсутність групування однотипних сигналів: черговий отримує шквал повідомлень, звикає їх ігнорувати, і справжня відмова тоне в шумі.
Затримка складається з періоду опитування, вікна оцінки умови і маршруту доставки — секунди на кожному кроці перетворюються в десятки хвилин до того, як інженер взагалі дізнається про проблему.
Для експлуатації це обертається тим, що інцидент не можна ні довести, ні розібрати: немає розділення симптому і причини, немає історії деградації, а зобов'язання щодо доступності нічим підтвердити.
Розбираємо, як це закривається: від карти точок відмови і узгоджених порогів до правил ескалації, які не будять нікого дарма.
Що дає контроль: вікна обслуговування і класи відмов
Поки контроль не розмічено, будь-яке зростання часу відповіді виглядає однаково: черговий отримує повідомлення, йде дивитися логи і тільки потім розуміє, плановий це перезапуск чи відмова бази.
Розмітка знімає цю невизначеність — планові роботи йдуть в окремі вікна обслуговування, а збої отримують клас за наслідками.
Що змінюється в експлуатації
Вікна обслуговування перестають бути усним договором. Регламентні роботи і міграції публікуються як інтервали з явним виключенням з розрахунку доступності — графік не просідає через планові дії, а сам факт робіт видно і замовнику, і черговому.
Класи відмов розведені за порогами спрацьовування. Деградація, часткова відмова і повна недоступність отримують різні умови і різні канали оповіщення: зростання часу відповіді піднімає чергового за розкладом, недоступність зовнішнього контуру — відразу і з ескалацією.
Межі вікон і самі класи взяті з практики управління послугами (ITIL), тому їх не доводиться винаходити заново.
Як рахуємо ефект
Основна метрика — час відновлення. До розмітки воно рахувалося «від дзвінка до дзвінка» і включало діагностику: типовий інцидент займав 40-60 хвилин.
Після точка відліку зсувається на перше спрацьовування порогу, а маршрут до відповідального відомий заздалегідь — 8-15 хвилин на більшість сценаріїв.
Друга метрика — частка спрацьовувань, що призвели до реальних дій. Якщо черговий відкриває повідомлення і нічого не робить, поріг виставлено невірно. Тримаємо цю частку вище 80% і переглядаємо правила після кожного розбору.
Формати контролю: зовнішній сервіс, свій сервіс, гібрид
Формат контролю вибирають за двома питаннями: чи потрібно бачити сервіс зсередини і чи допустимо, що система моніторингу впаде разом із сервером. Зовнішній сервіс перевіряє те, що бачить користувач, але про стан процесів, черг і вільного місця на диску він не знає. Самостійний моніторинг дає повну картину, зате живе на тому ж контурі, що й застосунок.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Зовнішній сервіс моніторингу | Потрібна незалежна перевірка доступності з різних регіонів | Не бачить процесів, черг і ресурсів сервера |
| Самостійний моніторинг | Свій контур, повний контроль над даними і правилами | Падіння сервера гасить і моніторинг — перевіряти нікому |
| Гібридний моніторинг | Критичний сервіс, де потрібні обидві картини відразу | Складніше в налаштуванні, потрібна узгоджена модель оповіщень |
На практиці чисті варіанти зустрічаються рідко. Зовнішні перевірки ловлять недоступність і прострочений сертифікат, але не показують, що сервіс відповідає повільно через переповнену чергу.
Агент на сервері бачить внутрішній стан, однак при відмові заліза він мовчить — і без незалежної перевірки збій залишається непоміченим.
Коли гібридний формат виправданий
Гібридний моніторинг потрібен там, де простій обходиться дорожче налаштування: агент на сервері збирає метрики за процесами і ресурсами, зовнішні перевірки незалежно фіксують доступність, коди відповіді і час відгуку з різних точок.
Умова одна — заздалегідь домовитися, яка система вважає інцидент відкритим, інакше черговий отримує два оповіщення про один збій і з часом перестає реагувати на обидва.
Етапи впровадження: від інвентаризації до передачі регламентів
Інвентаризація сервісів — не формальність: поки немає списку компонентів і їхніх власників, будь-яка метрика висить у повітрі. Тому починаємо з аудиту — звіряємо те, що реально працює, з документацією і фіксуємо розбіжності.
Потім будуємо карту залежностей: без неї незрозуміло, падіння якого вузла вважати інцидентом, а яке — фоновим шумом.
- Аудит інфраструктури і застосунків: перелік сервісів, власників, зовнішніх інтеграцій, режимів роботи.
- Карта залежностей: зв'язки «клієнт — сервіс — база — черга», критичні шляхи, точки відмови.
- План впровадження: які показники знімаємо першими, пороги спрацьовування, вікна оповіщень, порядок розкатки за середовищами.
- Налаштування збору і оповіщень: перевірки доступності, часу відгуку і коректності відповідей, маршрутизація повідомлень за черговими.
- Перевірка на реальних збоях: імітуємо відмову вузла, затримку відповіді, недоступність бази — правимо хибні спрацьовування і пороги.
- Передача регламентів: опис метрик, інструкції черговим, порядок ескалації і розбору інцидентів.
Ролі та зони відповідальності на кожному кроці
Аудит і карту залежностей ведемо спільно з вашою командою — без знання бізнес-логіки частина критичних шляхів не видна. Пороги і правила ескалації узгоджуємо з тими, хто буде чергувати: регламент, написаний «ззовні», не дотримуються.
Перевірка перед передачею
Проганяємо контрольний сценарій: зупиняємо сервіс, вносимо затримку, відключаємо залежність — і звіряємо, що повідомлення прийшло потрібному черговому за очікуваний час. Регламенти вважаємо прийнятими, коли черговий самостійно відтворює розбір інциденту за інструкцією.
Що залишається у вас: конфігурації, схеми і регламенти
Усі налаштування після впровадження залишаються у вас: конфігурація моніторингу, схема оповіщень, регламент реагування і робоча документація. Комплект зібрано так, щоб підтримку вела ваша команда або інший підрядник — без відновлення логіки за дзвінками.
- Конфігурація моніторингу: перелік перевірок — доступність, час відповіді, ключові сценарії користувача; пороги спрацьовування і вікна придушення хибних спрацьовувань.
- Схема оповіщень: маршрути за рівнями критичності, канали доставки, чергові групи, правила ескалації і час очікування на кожному кроці.
- Регламент реагування: рівні інцидентів, цільовий час реакції і відновлення, порядок дій чергового, точки передачі відповідальності.
- Інструкції для чергових: первинні перевірки, типові причини збою, шаблони повідомлень для внутрішніх і зовнішніх отримувачів.
- Схема інфраструктури: сервіси, залежності між ними, зовнішні точки присутності — з позначкою, де стоять перевірки.
- Доступи і порядок правок: ролі спостерігачів, журнал змін, версіонування конфігурацій у вашому сховищі.
Як виглядає комплект документації
Комплект — три шари: технічний (конфігурації і схеми), експлуатаційний (регламент, інструкції, панелі стану) і передавальний (карта доступів, контакти відповідальних, порядок правок).
Усе зберігається у вашому репозиторії і вашій хмарі, в текстових форматах, які читаються без нашого інструменту. На передачі проходимо за пунктами з черговим: як додати перевірку, як відключити шумне оповіщення, як відкотити правку.
Кейс: прибрали хибні спрацьовування і скоротили простій удвічі
Розбираємо впровадження на сервісі з високим навантаженням: каталог з оформленням і оплатою замовлень, пік припадає на вечірні години, чергування цілодобове. До робіт моніторинг тримався на одному порозі і не розрізняв «сторінка відповідає» і «замовлення реально оформлюється».
Що було до
Перевірка раз на хвилину била по головній: будь-який сплеск часу відповіді породжував потік повідомлень — близько 120 за тиждень, з яких реальними були одиниці. Черговий звик до шуму і розбирав сигнали вибірково.
Справжню відмову оплати виявили через 40 хвилин за зверненнями покупців. Доступність сервісу трималася на 99,4%, час простою — близько 4 годин на місяць, час відновлення — до 50 хвилин: діагностика щоразу починалася з нуля.
Що стало після
Моніторинг розклали на рівні: синтетичні сценарії повного шляху замовлення, метрики застосунку і лічильники бізнес-подій — число успішних оплат за хвилину.
Сигнал іде черговому тільки коли підтверджуються мінімум два рівні, а на період регламентних робіт і випуску релізу відкривається вікно придушення. Повідомлення й ескалації зібрані в PagerDuty, тому черговий бачить один інцидент, а не десять.
Хибні спрацьовування впали до 15 на тиждень, час виявлення — з 40 до 4 хвилин. Час відновлення скоротився вдвічі, до 20 хвилин: на момент розбору вже є графіки та історія запитів за проблемним шляхом. Доступність сервісу зросла до 99,95%, простій — з 4 годин до 40 хвилин на місяць.
Чим відрізняється моніторинг доступності від контролю рівня сервісу?
Моніторинг доступності відповідає на одне питання: чи відповідає сервіс на запит. Це бінарний сигнал — код відповіді і час відгуку за заданою адресою. Контур ловить падіння цілком, але не помічає, що сервіс працює повільно або віддає помилки тільки на частині запитів.
Контроль рівня сервісу ширший: він описує, як сервіс обслуговує користувача. Частка успішних запитів, час відповіді на 95-му процентилі, частота відмов на критичних сценаріях.
Формально адреса «доступна», але якщо оформлення замовлення триває 8 секунд, рівень сервісу порушено, а перевірка доступності мовчить.
Перевірка ззовні йде з зовнішнього вузла і показує рівно те, що бачить користувач. Синтетичні перевірки проганяють сценарій цілком — вхід, пошук, оплата — і дають ранній сигнал про деградацію, але не замінюють дані про реальний трафік.
| Варіант | Що показує | Обмеження |
|---|---|---|
| Перевірка ззовні | Доступність адреси, час відповіді | Не бачить процеси всередині сервісу |
| Синтетичні перевірки | Проходження ключового сценарію | Фіксований шлях, рідкісні гілки не ловить |
| Метрики застосунку | Черги, помилки, час обробки | Потрібна інструментировка коду |
| Контроль рівня сервісу | Частку успішних запитів, цільові значення | Потребує узгоджених цілей і розмітки шляхів |
Доступність — фундамент: без неї інші метрики не рахуються. Рівень сервісу — надбудова, яка переводить технічні сигнали в цільові значення: скільки дев'яток тримаємо, яка частка запитів вкладається у відгук, при якому відхиленні піднімається тривога.
Без другого контуру команда дізнається про проблему від користувачів, а не від системи. Тому ми налаштовуємо обидва рівні і пов'язуємо їх в одну картину з регламентом реакції.
Технічні сумніви: що уточнюють перед стартом
Перед стартом інженерні команди ставлять схожі питання — не про важливість контролю, а про те, як це відобразиться на їхній роботі: скільки буде хибних тривог, що робити в пік сезону, де закінчується наша відповідальність. Нижче — відповіді на ті, що найчастіше виринають під час розбору задачі.
Як відсікаєте хибні спрацьовування?
Оповіщення піднімається тільки після кількох невдалих перевірок підряд з різних точок спостереження — поодинокий сплеск затримки або короткочасний обрив зв'язку чергового не будить.
Окремо налаштовуємо пороги для синтетичних перевірок користувацьких сценаріїв і для метрик самого застосунку: природа в них різна, і загальний поріг дає шум.
Що відбувається на пікових навантаженнях?
Статичний поріг на піку сезону або під час кампанії дає або лавину оповіщень, або пропуск реальної деградації.
Тому частину перевірок переводимо на динамічний поріг — порівняння з тим самим часом і днем тижня, — а на період розпродажів заводимо окремий профіль з розширеним набором метрик.
Де межа зон відповідальності?
Ми відповідаємо за збір метрик, правила спрацьовування, доставку оповіщень і розбір інцидентів за застосунком. На стороні замовника залишаються доступи до інфраструктури, зміни в коді та узгодження регламенту ескалації: кому і куди йде сигнал, хто приймає рішення про відкат. Щодо зовнішніх сервісів заздалегідь фіксуємо, хто веде комунікацію з їхньою підтримкою.
Як виглядає етапність впровадження?
Починаємо з пілота на двох-трьох критичних сценаріях — вхід в особистий кабінет, наскрізний шлях оформлення замовлення. Дивимося реакцію на реальному трафіку, правимо пороги і тільки потім розкочуємо на інші сервіси. Так зайві тривоги відсіюються до того, як моніторинг почне впливати на чергування.
Обговоримо задачу: з чого починаємо і що потрібно від вас
Щоб повернутися з оцінкою термінів і планом робіт, а не із загальними словами, потрібні вихідні дані та доступи. Перший розбір — одна розмова: дивимося, як застосунок влаштований зараз, які збої вже були і що для вас вважається недоступністю.
Далі — короткий пілотний сервіс на узгодженому контурі: ставимо перевірки, збираємо статистику і звіряємо її з реальними інцидентами. Так видно, які пороги дають хибні спрацьовування, а які пропускають деградацію.
За підсумками пілота розгортаємо моніторинг на всьому контурі і виконуємо передачу моніторингу з документацією та правилами чергування.
Що потрібно від вас на старті:
- критичні сценарії — вхід, оплата, пошук, оформлення замовлення: що вважаємо недоступністю;
- схема застосунку і зовнішні залежності: база даних, черги, платіжні та партнерські інтеграції;
- доступи на читання до логів і поточних систем спостереження, конфігурації веб-сервера і балансувальника;
- історія інцидентів: що ламалося, як дізнавалися, скільки відновлювали;
- вікна обслуговування і допустимий час реакції та відновлення за кожним сценарієм;
- контакт чергового і правила ескалації — кому і як повідомляти про спрацьовування;
- вимоги до зберігання метрик і політика доступу до них.
Частини даних може не бути — зберемо разом на розборі. Опишіть задачу і надішліть те, що є: повернемося з оцінкою термінів, планом робіт і пропозицією щодо пілотного сервісу.
