Налаштування Synthetic Monitoring: виявлення прихованих проблем сайту

Synthetic Monitoring: збої, які бачать лише клієнти

Серверні метрики зелені, черги порожні, у логах застосунку жодного винятку — а клієнти пишуть, що кошик не працює. Так виглядає прихований збій сайту: код відповіді 200, запит дійшов до застосунку, але користувач на третьому кроці оформлення замовлення бачить завислий екран.

Серверний моніторинг доступності підтверджує, що сервіс живий, і мовчить — з погляду інфраструктури все гаразд.

Деградація без помилок у логах — найдорожчий клас відмов. Платіжний шлюз відповідає, але через сорок секунд замість двох; сторонній скрипт аналітики блокує відмальовування кнопки «Оплатити»; кеш віддає застарілий файл кошика після релізу.

Кожен випадок формально успішний і не створює жодного рядка в журналі, а страждає лише конверсія — її падіння помічають уже за виторгом.

Synthetic monitoring закриває цю сліпу зону: зовнішній робот проходить ключові сценарії — вхід, пошук, додавання в кошик, оплату — за розкладом і з кількох регіонів.

Він бачить рівно те, що бачить клієнт: час відмальовування, доступність елементів, коректність відповіді на кожному кроці.

Перевірка ключових сценаріїв змінює економіку інциденту: замість скарги через годину-дві команда отримує сигнал протягом кількох хвилин, а відкат релізу починається до просідання трафіку.

Частка користувацьких шляхів під автоперевірками перестає залежати від того, хто сьогодні чергує. Розбираємо, як це закривається на практиці.

Що дає імітація дій користувача за розкладом

Сценарій описує шлях цілком: відкрити сторінку, дочекатися відмальовування, авторизуватися, додати товар у кошик, оформити замовлення, перевірити відповідь платіжного шлюзу.

Окрема група перевірок працює на рівні програмних викликів — вона ловить деградацію віддачі даних, коли візуально сайт ще відкривається.

Запуск іде за розкладом із кроком у хвилини, а не «коли помітимо», і повторюється з кількох регіонів: те, що недоступне в користувачів в одній мережі, не маскується успішною відповіддю з іншої.

Саме тому час виявлення збою вимірюється хвилинами, а не годинами до першого листа в підтримку. Раннє оповіщення приходить у черговий канал із прив'язкою до конкретного кроку сценарію — видно, що зламалося: вхід, оплата, видача каталогу.

Частка відмов, знайдених до звернення клієнта, стає керованою величиною, і її видно на графіку по тижнях.

Окремий шар — контроль зовнішніх інтеграцій. Перевірка на межі з чужою системою показує, деградація в нас чи в постачальника, і знімає листування «у нас усе працює».

Пороги налаштовуємо із запасом: наприклад, сценарій вважається таким, що впав, після двох невдалих спроб поспіль із різних регіонів, щоб одиничний мережевий сплеск не піднімав чергового.

Ми збираємо такі сценарії на Grafana і пов'язуємо з панелями доступності, щоб цифри на графіку та в оповіщенні збігалися. Навантаження на підтримку падає завдяки тому, що частина відмов закривається до появи тікетів, а решта приходить із готовим контекстом. Обговоріть задачу — повернемося з планом сценаріїв та їхнього розкладу.

Режими Synthetic Monitoring: доступність, точка входу, браузер

Три режими перевірок відрізняються глибиною: чим ближчий сценарій до поведінки живого користувача, тим більше класів відмов він ловить — і тим дорожче обходиться підтримка.

Вибирати «найповніший» варіант невигідно: сценарій у браузері ламається за кожного редизайну і потребує ручної правки, а перевірка доступності працює роками без втручання.

Розділяти режими варто за класом відмови, а не за «важливістю» сторінки.

Доступність відповідає на питання «вузол живий», точка входу — «сторінка віддає потрібний контент», програмний інтерфейс — «дані приходять в очікуваній структурі», сценарій у браузері — «користувач доходить до результату».

Частота запусків і географія перевірок

Інтервал задають за ціною простою: доступність перевіряють раз на хвилину, сценарій у браузері — раз на 5–15 хвилин, інакше навантаження на прод зростає без користі.

Запуски розкидаємо по 3–5 регіонах присутності користувачів: так збій локального маршруту не маскується під загальну аварію, а розходження результатів між майданчиками одразу вказує на мережу, а не на застосунок.

Зведені графіки та історію відмов тримаємо в Grafana — за ними видно, чи це деградація, чи разовий таймаут. Тривогу піднімаємо лише за повторюваних відмов із двох майданчиків: черговий не прокидається через одиничний сплеск.

Як ми будуємо перевірки: від інвентаризації до передачі

Перевірки починаються не з інструменту, а з інвентаризації того, що взагалі має працювати. Далі ми збираємо схему покриття, калібруємо пороги і обов'язково ламаємо систему руками — інакше перший справжній збій стане і першим тестом оповіщень. Нижче — шість етапів, які проходить кожне налаштування.

1. Аудит критичних сценаріїв. Збираємо користувацькі шляхи: вхід, пошук, оформлення замовлення, оплата, особистий кабінет. Окремо позначаємо ті, що зав'язані на зовнішні сервіси та на фонові завдання — саме вони найчастіше відвалюються непомітно.

2. Схема покриття перевірками. Для кожного сценарію визначаємо точки контролю: доступність, код відповіді, наявність ключового елемента на сторінці, проходження всього ланцюжка запитів. Стежимо, щоб перевірки не дублювали одна одну і не створювали зайвого навантаження.

3. Налаштування перевірок. Розклад, географія запусків, авторизація, тестові облікові записи та дані. Сценарії виконуються в ізольованому контурі, не пишуть у бойові таблиці та не заважають реальному трафіку.

4. Калібрування порогів спрацювання. Знімаємо базову лінію за кожним сценарієм за період, потім задаємо поріг за часом відгуку та за кількістю послідовних помилок. Так нічні сплески навантаження не піднімають чергового, а стійка деградація — піднімає.

5. Тест на реальному збої. Зупиняємо сервіс, блокуємо зовнішній виклик, розриваємо з'єднання — і дивимося, що оповіщення пішло, за який час і чи вистачає в ньому даних для діагностики. Пороги після цього правимо.

6. Передача в експлуатацію. Віддаємо правила, інструкцію для чергового, схему ескалації та список відповідальних. Прогоняємо за кожним оповіщенням питання «що робити» — якщо відповіді немає, перевірка недоопрацьована.

Після передачі покриття живе: раз на квартал переглядаємо сценарії під нові розділи та інтеграції, щоб моніторинг не розходився з продуктом.

Що залишається в проєкті після налаштування перевірок

Налаштування синтетичного моніторингу закінчується не вмиканням оповіщень, а набором артефактів, за якими черговий і замовник розуміють, що саме контролюється і що робити при спрацюванні.

Без них перевірки за пару місяців перетворюються на потік шуму, який спершу терплять, а потім вимикають.

• Карта покриття перевірками — які користувацькі сценарії та зовнішні точки входу закриті, де проходить межа контролю і що свідомо залишено поза перевірками.
• Параметри перевірок — склад кроків, періодичність запуску, набір точок запуску, пороги за часом відповіді та допустимі коди відповіді.
• Правила оповіщень — що будить чергового, що йде в чергу на ранок, кому адресований канал і як гаситься лавина повідомлень при масовому збої.
• Регламент реакції — строки взяття інциденту, точки ескалації, зона відповідальності нашої команди та контакт на боці замовника.
• Інструкція для чергового — що перевірити в перші хвилини, як відрізнити відмову застосунку від збою зовнішнього постачальника, де дивитися історію запусків.
• Документація з моніторингу — опис сценаріїв, власники, порядок додавання нових перевірок і виведення застарілих з експлуатації.
• Журнал змін перевірок — коли і з якої причини змінювався сценарій, щоб зростання кількості перевірок не перетворилося на некерований набір.

Усе це лежить поруч із кодом у репозиторії і проходить таку саму перевірку за змін, як сам застосунок — перевірки живуть разом із продуктом, а не окремо від нього.

Кейс: приховані відмови оплати на сайті-каталозі

Відмова, якої не було в серверних метриках

Каталог на кілька тисяч позицій, оплата — через зовнішній платіжний шлюз. Серверні метрики виглядали рівно: час відповіді застосунку в нормі, частка п'ятисотих не зростає, черги порожні.

При цьому підтримка щотижня отримувала звернення «оплата пройшла, замовлення немає», і кожне спливало через 4–11 годин після початку збою — коли постраждали вже десятки покупців.

Причина лежала на стику сервісів: шлюз коректно приймав запит на створення платежу, але повідомлення про успіх не доходило до застосунку — провайдер під час планових робіт змінював формат події.

Застосунок вважав замовлення неоплаченим і не віддавав його у збірку, а в логах було порожньо. Це і є прихована відмова зовнішнього сервісу: кожна сторона окремо відповідає в нормі.

Що налаштували і що змінилося

Зібрали повний сценарій покупки: пошук товару, кошик, оформлення, вибір доставки, перехід на платіжну сторінку, очікування підтвердження в тестовому контурі та перевірка, що в особистому кабінеті з'явилося замовлення з вірним статусом.

Прогін — раз на 5 хвилин із чотирьох регіонів через Checkly, з перевіркою не лише коду відповіді, а й вмісту сторінки: так ловиться випадок, коли сервер віддає «успіх» із порожнім кошиком.

Метрики до і після: час до виявлення відмов — із 4–11 годин до 2 хвилин, частка втрачених оплат у години пік — із 3–5% до 0,2%, частка сценаріїв, що доходять до кінця, — 99,8%.

Черговий отримує оповіщення з номером кроку, що впав, знімком екрана та трасуванням запитів, тому відновлення сценарію займає один розбір, а не пошук причини наосліп.

Той самий сценарій запускається після кожного релізу — регресія на кроці оплати видна до того, як про неї напишуть покупці.

Чим синтетичні перевірки відрізняються від даних реальних відвідувачів?

Синтетична перевірка — це робот, який за розкладом проходить описаний шлях: відкриває сторінку, входить в акаунт, додає товар у кошик, доходить до оплати і фіксує відповідь та час кожного кроку.

Прогін не залежить від трафіку: навіть уночі він покаже, що оформлення замовлення віддає помилку. Тому синтетика дає ранній сигнал і годиться для чергових оповіщень.

Дані реальних відвідувачів відповідають на інше питання — що відбувалося в людей. Вони показують розкид пристроїв і мереж, частку покинутих кошиків і крок, на якому відвідувачі йдуть.

Слабке місце — затримка та шум: збій видно після того, як зачеплено живих людей, а за низького трафіку вибірки не вистачає, щоб відрізнити проблему від випадковості.

Підходи доповнюють один одного. Синтетика фіксує момент відмови і піднімає чергового, статистика показує масштаб: скільки людей зачеплено і які групи постраждали сильніше.

Якщо оповіщати лише за статистикою, про збій дізнаються зі звернень у підтримку — тобто вже після втрати замовлень.

Головне обмеження синтетики — репрезентативність: сценарій перевіряє рівно ті шляхи, що в нього закладені. Набір сценаріїв звіряють із фактичними маршрутами, інакше нова воронка або регіональна версія сайту залишиться без нагляду. Статистика таких прогалин не створює, але й не передбачає — вона збирає те, що вже сталося.

Технічні сумніви перед запуском перевірок

Перевірки йдуть із зовнішніх вузлів і поводяться як рідкісний акуратний відвідувач: одиниці запитів на хвилину на сценарій, а планувальник розносить обходи, щоб вони не збігалися з піками трафіку.

Закриті розділи перевіряємо окремим технічним обліковим записом із мінімальними правами — реальних даних це не стосується.

Хибні спрацювання гасимо підтвердженням із двох незалежних вузлів і порогом у два провали поспіль: у черговий канал потрапляє підтверджений інцидент, а не одиничний мережевий збій.

Розмежування відповідальності фіксуємо заздалегідь — відмова інфраструктури йде в експлуатацію, збій бізнес-сценарію власнику продукту.

Як перевіряти закриті розділи, де потрібна авторизація?

Заводимо обліковий запис лише на читання, його сесійні дані зберігаємо в захищеному сховищі та ротуємо. Сценарій проходить весь ланцюжок: форму входу, редірект за роллю та доступність цільового екрана — там найчастіше ламається після релізу.

Куди приходять оповіщення і хто їх розбирає?

Сигнал іде в канал, де команда чергує, із зазначенням кроку, вузла та коду відповіді — цього вистачає, щоб відтворити відмову. До запуску фіксуємо, хто реагує на недоступність, а хто на збій оформлення замовлення, щоб оповіщення не зависало між відділами.

Обговорімо задачу і повернемося з планом перевірок

Щоб оцінити обсяг і запропонувати порядок робіт, нам потрібен мінімум: перелік сценаріїв, які впливають на виторг або потік звернень, список контурів із вікнами, коли прогони не завадять реальному трафіку, та доступи.

З боку замовника достатньо назвати критичні користувацькі шляхи і вказати, хто підтверджує сценарії.

У відповідь надсилаємо план, за яким далі йдемо:

• Перелік сценаріїв — вхід, пошук, оформлення замовлення, оплата, особистий кабінет; окремо позначаємо критичні та спостережувані.
• Схема покриття — майданчики та регіони, частота прогонів, розподіл за вікнами навантаження, кроки авторизації.
• Порядок впровадження — що вмикаємо першою хвилею, що додаємо після стабілізації, щоб не потонути в оповіщеннях.
• Етапи та точки контролю — із чим звіряємося на кожному кроці і що показуємо після завершення.
• Відповідальні з обох сторін — хто підтверджує сценарії, хто приймає спрацювання і в які години реагує.
• Правила оповіщень — пороги та адресати, щоб сигнали не перетворювалися на шум.
• Знімок базових значень — фіксуємо доступність і час відгуку до запуску, щоб було з чим порівнювати.
• Передача команді — документація, шаблони сценаріїв та інструкція з додавання перевірок без нас.

Опишіть задачу — повернемося з оцінкою та планом перевірок.