Сервер відповідає, контейнер запущений, а заявка клієнта не потрапила в CRM. Технічна доступність і виконання бізнес-задачі — різні речі. Під час розгортання мережі сервісів ми побачили, чому перевірка «все увімкнено» не замінює перевірку результату.
Для власника важливо, щоб замовлення дійшло до менеджера, документ сформувався, а звіт містив актуальні дані. Саме ці події варто покласти в основу моніторингу.
Перевіряйте весь шлях
У сценарії «форма → обробка → CRM → повідомлення» кожен перехід може зупинитися окремо. Форма прийняла дані, але зовнішній сервіс повернув помилку. CRM створила картку, але повідомлення не було доставлено.
Присвойте зверненню ідентифікатор і збережіть статус кожного кроку. Тоді можна знайти, на якому переході воно зупинилося, та повторити потрібну дію. Повторно запускати весь процес без перевірок небезпечно: можна створити друге замовлення.
Повтор має бути безпечним
Мережевий тайм-аут не завжди означає, що зовнішня дія не виконалася. Сервіс міг зберегти замовлення, але відповідь не дійшла до вашої системи.
Тому перед повтором потрібен спосіб розпізнати вже виконану операцію: ключ запиту, зовнішній ідентифікатор або звірка статусу. Це правило особливо важливе для документів, платежів і повідомлень клієнтам.
Слідкуйте за тишею
Помилка в журналі — очевидний сигнал. Менш очевидний випадок: нових подій немає взагалі. Якщо звичайний потік звернень раптово зупинився, можливо, проблема у формі, доступі чи джерелі.
Поріг залежить від процесу. Для рідкісного щомісячного звіту один день тиші нормальний. Для активного магазину тривала відсутність замовлень потребує перевірки. Узгодьте очікуваний ритм із командою, яка працює з цим потоком.
Перевірте відновлення до інциденту
Резервна копія корисна лише тоді, коли з неї можна відновити потрібні дані. Журнал помилок корисний, коли зрозуміло, хто його переглядає і що робить далі.
Перед передачею системи команді змоделюйте недоступний сервіс, повторну подію й прострочений доступ. Зафіксуйте, які кроки відновлюються автоматично, а де потрібна людина. Інструкція має бути короткою й прив’язаною до конкретного симптому.
План супроводу — частина впровадження автоматизації. Його варто погодити разом із функціями системи, поки ще легко змінити спосіб обробки помилок.