Статья
План сбоев интеграций для бота
Бот должен сохранять контекст и давать честный следующий шаг, когда CRM, расписание, оплата или уведомления недоступны.
Составьте реестр внешних зависимостей
Для каждого API запишите владельца, назначение, допустимое ожидание, ограничение запросов и данные, без которых сценарий не продолжается. Различайте недоступность, медленный ответ, отказ авторизации и корректный пустой результат. Сообщение «мест нет» нельзя показывать при таймауте календаря. Секреты и технические ответы не должны попадать пользователю или в открытый журнал.
Назначьте реакцию для каждого типа сбоя
Защитите действия от повторного выполнения
Пользователь может нажать кнопку снова, платформа — повторить webhook, а сервис — ответить после таймаута. Создание записи, списание и отправка заявки требуют ключа идемпотентности и проверки текущего статуса. Храните исходный запрос, внешний идентификатор и итог отдельно. Повтор должен вернуть известный результат, а не создать второй объект. Ручная обработка также обязана видеть, не завершилась ли операция позднее.
Пример: календарь студии не отвечает
Посетитель выбрал мастер-класс и дату, но календарь перестал отвечать. Бот сохраняет выбор как незавершённый запрос, сообщает, что место пока не подтверждено, и предлагает дождаться сообщения либо позвать администратора. Он не показывает время как свободное и не принимает оплату. После восстановления фоновая проверка получает актуальные окна: если выбранное доступно, бот просит подтвердить продолжение; если занято — предлагает вернуться к выбору. Администратор видит историю и не просит повторить вид занятия и дату.
Проведите учебное отключение и восстановление
На тестовой среде вызовите таймаут, ошибку доступа, повреждённый ответ и повтор webhook. Проверьте пользовательский текст, очередь, оповещение и отсутствие дублей. Затем верните сервис и убедитесь, что отложенные операции обработаны в контролируемом порядке. В журнале должны связываться диалог, попытка интеграции и внешний объект без хранения лишнего содержимого сообщений. Инструкция дежурному описывает, где увидеть масштаб, как остановить повторы и как сообщить пользователям результат.
Назначьте владельцев инцидента и данных
Технический дежурный восстанавливает обмен, но решение о клиентских обещаниях принимает владелец процесса. В плане укажите, кто подтверждает остановку операций, кто отвечает пользователям и кто сверяет данные после восстановления. Шаблон уведомления должен описывать затронутое действие и ожидаемый следующий контакт без неподтверждённого срока. После инцидента сопоставьте очередь, внешние объекты и сообщения клиентам; не считайте зелёный статус API доказательством целостности. Разберите первопричину, качество обнаружения и ручные действия, затем обновите тест отказа. Если раскрыт секрет интеграции, его отзывают и ротируют отдельно от обычного восстановления сервиса.
Вопросы о резервных сценариях
Сколько раз повторять запрос?
Это зависит от операции и правил API. Ограничьте попытки и не повторяйте необратимое действие без идемпотентности.
Нужно ли сообщать о технической ошибке?
Сообщайте влияние и следующий шаг простыми словами, без кода ошибки и внутренних деталей.
Когда будить сотрудника?
Когда остановлен критичный маршрут, растёт очередь или есть риск денег, данных либо двойных операций.