Автоматизація має неприємну властивість: коли вона ламається, нічого не вибухає. Сайт відкривається, форма відправляється, клієнт бачить «дякуємо». Просто заявка не доходить до CRM, залишки не оновлюються, а замовлення з маркетплейсу не потрапляють у систему.
Дізнаються про це через кілька днів — найчастіше від клієнта, який запитує, чому з ним ніхто не звʼязався.
Чому збої тихі
Інтеграція — це обмін між двома системами, які нічого не знають одна про одну. Сайт відправив дані й пішов далі. Чи прийняв їх другий бік, чи не змінилося щось у його форматі, чи не закінчився токен доступу — сайт не перевіряє, якщо його про це не попросили. Загальна логіка цього обміну розкладена в матеріалі про API-інтеграції простими словами.
Типові причини поламки виглядають буденно: у зовнішнього сервісу закінчився термін дії ключа, змінився формат відповіді, вичерпався ліміт запитів, змінили пароль до облікового запису, оновили модуль на сайті. Жодна з них не супроводжується повідомленням.
Окрема категорія — зміни не у вас, а на тому боці: сервіс оновив версію свого інтерфейсу обміну, і старий формат перестав прийматися. Попереджають про це листом, який зазвичай приходить на адресу, яку ніхто не читає.
І ще одна деталь, через яку збій живе довго: він рідко буває повним. Частіше «зламалося наполовину» — проходить кожне друге замовлення, або губляться тільки ті, де є коментар клієнта. Такий збій не помітно навіть по загальній кількості заявок.
Три речі, які треба бачити
Доступність. Чи відповідає зовнішній сервіс. Найпростіша перевірка, і водночас найменш корисна: більшість реальних збоїв відбувається при живому сервісі.
Помилки. Скільки операцій завершилося невдало за останню годину. Одна помилка — норма, мережа буває нестабільною. Десять поспіль — це вже подія.
Тиша. Найважливіший і найчастіше пропущений сигнал. Якщо за годину, у яку зазвичай проходить десять замовлень, не пройшло жодного, це важливіше за будь-яку помилку. Саме тиша ловить збої, які не дають помилок узагалі, — а таких більшість. Той самий принцип, що й у сповіщеннях команді про події: найцінніший алерт — не про подію, а про її відсутність.
Мінімальний робочий набір
Для малого бізнесу не потрібні окремі системи моніторингу. Достатньо чотирьох речей, які налаштовуються один раз.
Журнал обмінів. Кожна передача даних записується: що відправили, що відповіли, коли. Без журналу розбір збою перетворюється на гадання, а відновити втрачене нема з чого.
Повідомлення в робочий чат при помилці. З дедублікацією — інакше при масовому збої ви отримаєте триста однакових повідомлень і вимкнете канал назавжди. Куди їх слати й як не потонути в шумі, розібрано в матеріалі про інтеграцію месенджерів в єдине вікно.
Щоденне зведення. Один короткий підсумок зранку: скільки заявок передано, скільки помилок, чи всі системи відповідали. Це те, що ловить «наполовину зламане» — і те, що варто вивести на дашборд для бізнесу.
Черга з повторами. Заявка спочатку зберігається у вас, потім передається далі. Не вдалося — лишається в черзі й повторюється автоматично. Тоді короткий збій узагалі не має наслідків, а довгий вирішується повторним запуском черги.
Типові помилки
Зберігати заявку тільки в чужій системі. Якщо єдиний екземпляр даних живе в момент передачі, після збою відновлювати нема з чого. Заявка має спершу лягти до вас — саме тому форми на сайті не варто замикати виключно на зовнішній сервіс.
Слати алерти всім. Повідомлення, яке стосується всіх, не стосується нікого. У кожного сигналу має бути одна відповідальна людина.
Реагувати тільки на помилки. Найдорожчі збої проходять без жодної помилки — тому сигнал «тиша» обовʼязковий.
Не перевіряти після змін. Оновили модуль, змінили тариф у сервісу, поміняли пароль — перевірте наскрізний сценарій, а не тільки те, що сайт відкрився. Про суміжні граблі — у матеріалі про помилки автоматизації бізнесу.
Не записувати, коли і що змінювали. Половина збоїв починається не сама по собі, а після чиєїсь дії: оновлення, зміни тарифу, нового співробітника з іншими правами. Короткий журнал змін у два рядки скорочує розбір із півдня до пʼяти хвилин, бо одразу видно, що сталося напередодні.
Коротко
Інтеграції ламаються тихо: сайт працює, клієнт бачить підтвердження, а дані не доходять — тому середній час виявлення збою вимірюється днями, і виявляє його зазвичай клієнт. Моніторити треба три речі: доступність зовнішнього сервісу, кількість помилок за період і — найголовніше — тишу, тобто відсутність операцій там, де вони мають бути щогодини. Мінімальний набір для малого бізнесу коштує один раз налаштованої роботи: журнал усіх обмінів, повідомлення в робочий чат із дедублікацією, щоденне коротке зведення й черга з автоматичними повторами. Головна вимога до архітектури — заявка спершу зберігається у вас і лише потім передається далі, інакше після збою відновлювати нема з чого. І перевіряйте наскрізний сценарій після кожної зміни в будь-якій із систем: інтеграція сайту з CRM ламається саме в такі моменти.
Ми в Obliko розробляємо сайти й автоматизацію з журналом обмінів і чергою повторів за замовчуванням — щоб про збій ви дізнавалися з повідомлення в чаті, а не з питання клієнта.
Чому збій інтеграції помічають через кілька днів?
Бо інтеграція ламається без жодного видимого симптому. Сайт працює, форма відправляється, клієнт бачить «дякуємо» — а заявка просто не доїжджає до CRM. Помилку видно тільки в логах, куди ніхто не заглядає, поки все добре. Різницю зазвичай помічає людина: «щось мало заявок сьогодні» — і це найдорожчий спосіб моніторингу, бо між збоєм і цією фразою минає кілька днів роботи.
Що саме треба моніторити, а не просто «щоб працювало»?
Три різні речі. Перше — доступність: чи відповідає зовнішній сервіс взагалі. Друге — успішність операцій: скільки запитів завершилися помилкою за останню годину. Третє, найважливіше, — тиша: коли за період, у якому зазвичай проходить десять замовлень, не пройшло жодного. Саме третій сигнал ловить збої, які не дають помилок, — а таких більшість.
Чи можна обійтися без окремих сервісів моніторингу?
Для малого бізнесу — так. Мінімальний робочий варіант складається з трьох елементів: журнал усіх обмінів із зовнішніми системами, повідомлення в робочий чат при помилці й щоденне зведення «стільки заявок передано, стільки помилок». Це закриває більшу частину випадків. Окремі сервіси потрібні тоді, коли інтеграцій багато й важливо бачити картину за всіма одразу.
Що робити із замовленнями, які загубилися під час збою?
Нічого не має губитися взагалі — це вимога до архітектури, а не до реакції. Заявка спершу зберігається у вас, і лише потім передається далі; якщо передача не вдалася, вона лишається в черзі й повторюється автоматично. Тоді відновлення після збою — це просто повторний запуск черги. Якщо ж заявка існувала тільки в момент передачі, після збою відновити її нема з чого — і саме цей сценарій найдорожчий.
Потрібен сайт або застосунок?
Розробляємо під ключ — від дизайну до запуску. Порахуємо ваш проєкт безкоштовно.