Тиха відмова: сигналізація, що ловить зупинку інтеграції за 15 хвилин

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

Ніщо не впало, ніде не загорілося червоне. Стало трохи тихіше, а «трохи тихіше» буває в будь-який вівторок. Помітили випадково, і замовлення довелось заводити заднім числом.

Тепер кожні пʼятнадцять хвилин система дивиться на всі девʼять каналів продажу і ставить одне питання. Цей канал мовчить тому, що зламався, чи тому, що зараз просто немає покупців?

каналів продажу під наглядом

15 хв

цикл перевірки замість двох діб наосліп

незалежні яруси: тиша і зустрічна перевірка

Проблема: усе працює, а замовлення не заходять

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

Зламався сам обмін, і жодна зі сторін про це не знала. А далі починаються дві пастки, через які просте правило «немає замовлень N годин - тривога» не працює.

Три причини, чому тишу не можна ловити одним правилом

🟢 Усе відповідає

Сайти віддають сторінки, CRM відкривається, обмін не показує помилок
Падіння немає - є розрив між двома здоровими сторонами
Класична перевірка доступності тут сліпа за визначенням

⏱ Єдиного порогу не існує

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

⚠️ Тиша буває законною

Маркетплейс може просто не дати продажів пів дня, і це нормально
Якщо слати тривогу на кожну таку паузу, її перестануть читати за тиждень
А потім пропустять справжню - вона виглядатиме так само

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

Як автоматизація це вирішує

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

Логіка одного циклу перевірки

9 каналів продажу → коли було останнє замовлення → поріг тиші для цієї години

зустрічний запит до майданчика → там замовлення є? → тривога → або жовта позначка в підсумку

Ярус перший: поріг задають дані, а не людина

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

Ніхто не сідає й не вигадує, що «три години без замовлень - це погано». Нічна тиша для нічної години нормальна, а та сама тиша опівдні вже підозріла.

Ярус другий: спитати сам майданчик

Коли перший ярус спрацював, система не кричить одразу. Вона питає сам майданчик: а в тебе за цей час замовлення були?

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

Що це дало бізнесу

Розрив між вітриною і системою замовлень тепер видно за пʼятнадцять хвилин, а не за дві доби. Різниця між цими двома числами - це замовлення, які встигають обробити вчасно, замість того щоб заводити їх руками заднім числом.

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

Чого ця система не бачить

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

Як це влаштовано всередині

Далі - інженерна частина

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

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

Чотири перевірки, кожна з реального інциденту

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

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

Склад подійОдного разу зовнішній сервіс просто перейменував подію, на яку ми підписані. Тепер система тримає відбиток списку підписок і сигналить у форматі «було / стало»

ПідтвердженняЗдоровʼя зовнішніх сервісів фіксується не з першого промаху, а з трьох поспіль. Один випадковий таймаут - не подія, три підряд - уже подія

Правила каналу тривог

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

Що робить канал тривог робочим, а не фоновим шумом

Два кольориЧервоне - аварія інтеграції. Помаранчеве - робота для людини. Змішувати не можна: спільний канал працює тільки поки два сигнали візуально різні

ПоштучноОдна подія - одне повідомлення, ніколи списком. Успішні операції не пишемо взагалі, інакше важливе тоне в потоці звичайного

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

Кому це підходить

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

Ознака, за якою легко перевірити, чи це про вас: якщо ви дізнаєтесь про поламаний обмін від клієнта, який питає «а де моє замовлення» - так, це про вас.

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