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