Поріг уже спрацював — але що саме сталося?
До початку продажу квитків залишається година. Трафік швидко зростає, і статичний поріг подає тривогу. Черговий інженер бачить стрибок, але графік не відповідає на головне запитання: це очікуваний прихід аудиторії чи початок відмови?
Просто вимкнути алерт небезпечно. Якщо вважати будь-який пік нормальним ефектом події, можна пропустити перевантаження бази даних або збій залежного сервісу. Але викликати всю команду через передбачувану зміну трафіку теж не варто: повторювані хибні тривоги виснажують людей.
Практичне рішення — порівнювати поточне значення не з одним постійним порогом, а з динамічним базовим рівнем. Він показує, яким трафік зазвичай буває саме в цей час, у цьому регіоні та для цього компонента.
За кілька тижнів до події: будуємо базовий рівень
Для кожної хвилини події візьміть відповідні хвилини за чотири попередні тижні. Наприклад, для вівторка о 19:30 використайте значення о 19:30 у чотири попередні вівторки. Базовим рівнем стане їхня медіана.
Такий підхід враховує звичний тижневий ритм і менше залежить від одного випадкового сплеску. Дані все одно треба переглянути: великий запуск, попередня аварія або пропуск вимірювань можуть спотворити навіть корисну історію.
Не змішуйте всі країни в один графік. Вечірній пік в одному регіоні може збігатися з нічним мінімумом в іншому. Окремі базові рівні потрібні принаймні для важливих регіонів, типів трафіку та критичних компонентів. Надмірне дроблення теж шкодить: у сегменті з майже нульовим трафіком випадковий запит виглядатиме як величезне зростання.
Для нормалізації поділіть поточне значення на базовий рівень:
відношення = поточний трафік / базовий рівень
Якщо звичайне значення дорівнює 10 000 запитів за хвилину, а поточне — 20 000, відношення становить 2. Для симетричного показу зростання і падіння застосуйте log₂: відношення 2 дає +1, значення 1 дає 0, а 0,5 дає −1. Так подвоєння та зменшення вдвічі однаково помітні на графіку.
Напередодні: перетворюємо календар на контекст
Позначте в системі спостереження початок і завершення події, очікувані хвилі аудиторії та масові сповіщення. Ці мітки не доводять, що зміна безпечна. Вони лише пояснюють черговому інженеру, чому поведінка могла змінитися саме зараз.
Проведіть коротку репетицію. Якщо команда очікує подвоєння трафіку, а навантажувальний тест підтвердив стабільну роботу лише на рівні 1,6 від базового, зміна порога нічого не виправить. Потрібно додати потужність, зменшити дорогу роботу в запиті або переглянути сценарій. Перевірте масштабування, ліміти з’єднань і черги. Безпечно прогрійте кеші, які мають прийняти першу хвилю запитів.
Тимчасові алерти повинні мати власника, час активації та час завершення. Призначте людину, яка стежитиме за подією, і заздалегідь домовтеся, за яких сигналів вона викликає ширшу команду.
Під час події: дивимося не лише на трафік
Коли за годину до старту спрацьовує тривога, черговий спочатку перевіряє календарну мітку, регіон і нормалізоване відхилення. Потім дивиться на три технічні сигнали: затримку, частку помилок і насичення ресурсів.
Якщо трафік подвоївся, але затримка та помилки стабільні, а ресурси залишаються нижче перевіреної межі, це схоже на очікувану хвилю. Спостереження можна продовжити без загальної ескалації.
Інша картина виникає, коли трафік відповідає прогнозу, але затримка зростає, помилки накопичуються, а пул з’єднань вичерпується. Це вже проблема сервісу, навіть якщо сам графік відвідуваності виглядає нормальним. Так само не варто списувати падіння трафіку на поведінку аудиторії, якщо воно зачепило лише один регіон і супроводжується помилками.
Порівняння регіонів і компонентів допомагає звузити пошук. Одночасна зміна в багатьох регіонах частіше відповідає спільній події. Відхилення в одному API, центрі обробки або каналі доступу потребує окремої перевірки.
Чотири пастки, які послаблюють метод
- Один глобальний базовий рівень приховує локальні проблеми та часові відмінності.
- Алерт лише за трафіком не бачить повільних відповідей, помилок і вичерпання ресурсів.
- Ділення на майже нульовий базовий рівень створює гігантські відношення. Для малих обсягів потрібен також абсолютний мінімум.
- Тимчасове правило без дати завершення стає постійною дірою в моніторингу.
Після завершення: повертаємо звичайні правила
Після події поверніть стандартні пороги та перевірте, що тимчасові винятки справді вимкнені. Запишіть максимальне відхилення від базового рівня, найвищу затримку, частку помилок, насичення ресурсів і результат кожної тривоги. Не перетворюйте подієвий пік на нову норму без окремого рішення.
Кейс Cloudflare з даними Чемпіонату світу показує, що великі події можуть змінювати інтернет-трафік похвилинно, а результат залежить від країни та локального часу. Метод чотиритижневої медіани й шкали log₂ походить із цього аналізу. Перевірки місткості, правила ескалації та робота з кешами залишаються загальними рекомендаціями, які команда має пристосувати до власного сервісу.
Джерела
- Cloudflare — How the 2026 World Cup affected Internet traffic: https://blog.cloudflare.com/2026-world-cup-internet-traffic/
Короткий чеклист
- зберіть похвилинні дані за чотири попередні тижні
- розділіть базовий рівень за регіонами та локальним часом
- позначте початок, етапи й завершення події в календарі
- перевірте трафік разом із затримкою, помилками та ресурсами
- протестуйте запас потужності й прогрійте потрібні кеші
- задайте час автоматичного повернення звичайних алертів
Підготуйте план моніторингу сервісу під час великої події
Допоможи підготувати моніторинг сервісу до запланованої події. Спочатку попроси в мене такі дані: - дата, час, тривалість і регіони події; - основні користувацькі сценарії та компоненти сервісу; - похвилинні метрики трафіку щонайменше за чотири попередні тижні; - поточні правила алертів; - перевірена максимальна потужність і бажаний запас; - доступні метрики затримки, помилок і насичення ресурсів. Не вигадуй відсутні пороги. Познач припущення та постав уточнювальні запитання. Поверни результат у форматі: 1. Вхідні дані та прогалини. 2. Спосіб розрахунку базового рівня. 3. Розрізи за регіонами й компонентами. 4. Правила алертів до, під час і після події. 5. Перевірки місткості та кешів. 6. Послідовність дій чергового інженера. 7. Умови повернення звичайних правил.