Статьи Nazara
Как проверить автоматизацию на сбое внешнего сервиса
Как безопасно проверить отказ API: задержку ответа, правила повторов, защиту от лишних действий, уведомления и сверку очереди после восстановления.
АвторЮлия Назарова
Чтобы проверить автоматизацию на сбое внешнего сервиса, воспроизведите отказ на учебных данных и проследите всю цепочку: что увидит человек, сохранится ли задание, кто узнает о проблеме и как будет проверен результат после восстановления. Эта инструкция поможет владельцу процесса и разработчику составить испытания до запуска или обновления рабочего маршрута.
Под внешним сервисом здесь понимается система, к которой обращается Ваша автоматизация: например, календарь, CRM или служба доставки сообщений. Ниже разобран вымышленный маршрут записи заявки из формы в календарь. Это учебный пример, а не описание функций конкретного бота Nazara.
Определите, что именно должно пережить отказ
Критерий устойчивости — понятная судьба каждого задания. Автоматизация может временно не выполнить действие, но не должна сообщать об успехе без подтверждения, терять заявку незаметно или повторять уже выполненную операцию без проверки.
Сначала нарисуйте короткую цепочку нашего примера: форма приняла учебную заявку → обработчик подготовил данные → календарь получил запрос → вернул результат → человек получил сообщение. У каждого перехода есть свой смысл. Принятие формы ещё не означает, что встреча появилась в календаре. Ответ календаря ещё не доказывает, что уведомление дошло адресату.
Если сам процесс пока не описан, начните с разбора процесса перед автоматизацией. Для испытания отказов нужна уже понятная последовательность действий: иначе невозможно отличить сбой связи от ошибки в договорённости о результате.
- Что считается выполненным действием: созданная запись, переданный документ или другое наблюдаемое изменение?
- Где останется исходное задание, если следующий шаг недоступен?
- Как отличить «точно не выполнено» от «результат пока неизвестен»?
- Кто сможет принять решение о ручном продолжении?
Запишите ответы в карточку испытания. В нашем примере результатом будет ровно одна учебная запись с узнаваемым тестовым обозначением. Сообщение «запись создана» допустимо только после подтверждения этого результата. Такой критерий позволяет проверять поведение, а не наличие зелёной плашки на экране.
Подготовьте безопасное место для испытаний
Проверять недоступность нужно в тестовой среде или через управляемую подмену ответа. Не отключайте рабочую CRM, не блокируйте общий сервер и не отзывайте действующий ключ ради эксперимента с одним маршрутом.
Разработчик может заменить обращение к календарю тестовым обработчиком, который возвращает выбранную ошибку или задерживает ответ. Важно записать, какая часть настоящего маршрута при этом проверяется. Подмена проверит реакцию Вашего приложения, но сама по себе не подтвердит реальные ограничения стороннего API.
Если сервис предоставляет отдельную среду для разработки, используйте её по документации этого сервиса. Наличие такой среды нельзя предполагать. При её отсутствии согласуйте отдельный безопасный объект, исключите отправку настоящим клиентам и предусмотрите удаление учебных записей после сверки.
Для каждого опыта заведите одну строку: обозначение теста, входные данные, искусственный отказ, ожидаемый статус, фактический результат, подтверждение и ответственный. Используйте вымышленные контакты и сообщения. Пароли, токены и реальные клиентские данные в протокол испытаний не включайте.
Заранее определите условие остановки: например, неожиданная отправка в рабочий канал или появление записи вне тестового календаря. В таком случае прекращают испытание и выясняют границы среды. Продолжать серию ради заполненного отчёта нельзя: результаты уже нельзя считать контролируемыми.
Разделите ошибки, задержку и неизвестный результат
Один общий тест «сервис не работает» скрывает разные ситуации. Проверьте как минимум отказ до отправки, явную ошибку после обращения и потерю ответа после возможного выполнения действия. Реакция на них может различаться.
Запрос не был отправлен
Например, обработчик обнаружил неверный адрес тестового сервиса. Ожидаемый результат — задание не отмечено выполненным, причина видна ответственному, дальнейшая обработка соответствует согласованному правилу. Пользователю не нужно показывать служебные адреса или подробности доступа.
Сервис явно отклонил запрос
Учебная заявка может содержать недопустимое поле. Повтор той же заявки без исправления данных не устраняет причину. Проверьте, что система выделяет ошибку содержимого, даёт понятный следующий шаг и не создаёт бесконечный поток одинаковых обращений. Классификацию конкретных кодов и условий берут из документации используемого API.
Ответ не пришёл вовремя
Тайм-аут — истечение времени ожидания ответа. Он не доказывает, что действие не произошло. Календарь мог создать запись, а подтверждение могло потеряться по дороге. Поэтому отдельное испытание должно показать, как приложение проверяет результат перед повтором и что сообщает человеку до выяснения.
Добавьте к серии медленный успешный ответ и ответ с неожиданной структурой. Первый выявляет слишком раннее сообщение об ошибке, второй — ложный успех при неполном подтверждении. Эти случаи воспроизводят раздельно, чтобы понимать причину каждого наблюдения.
Проверьте правила повтора без лишних действий
Повтор запроса допустим только там, где понятны его последствия и пределы. До испытания зафиксируйте, какие ошибки допускают повтор, сколько времени задание может ожидать и что произойдёт после исчерпания попыток.
В руководстве AWS по повторным запросам с увеличением задержки отдельно отмечены нагрузка от частых повторов и необходимость идемпотентности. Идемпотентной называют операцию, повторение которой не создаёт дополнительный эффект. Применимость этого свойства к Вашему действию нужно подтвердить, а не вывести из названия метода.
Для учебного календаря заранее договоритесь о способе узнавать одно и то же задание. Если API поддерживает специальный ключ защиты от повторов, проверьте его реальное поведение и ограничения. Если такой функции нет, разработчик должен описать другой способ сопоставления. Совпадение имени клиента и времени само по себе может быть недостаточно: иногда человек действительно делает две похожие заявки.
- Отправьте одно учебное задание и сохраните его обозначение.
- Воспроизведите потерю подтверждения после возможного выполнения.
- Дождитесь предусмотренного повторного действия или запустите его согласованным способом.
- Проверьте итог в принимающей системе: появилась одна запись или несколько.
- Сравните итоговый статус с тем, что увидел пользователь.
Универсального числа попыток для всех интеграций нет. Учитываются ограничения API, допустимое ожидание и цена ошибочного повторения. Критерий приёмки здесь — соблюдение выбранной политики, отсутствие лишнего эффекта и понятный выход после остановки. Паузы между попытками также проверяют по журналу, а не только по описанию разработчика.
Проверьте сообщения и ручной маршрут
Во время сбоя человеку нужен честный статус и конкретное действие. Разделите сообщения для клиента, сотрудника и технического ответственного: у них разные задачи и разная потребность в подробностях.
Для клиента в нашем примере подходит смысл: «Заявка принята, подтверждение записи ожидается». Использовать такую формулировку можно только если заявка действительно сохранена. Если сохранение не состоялось, нужен другой текст и способ повторной подачи. Нельзя успокаивать человека обещанием, которое система не может выполнить.
Сотруднику нужны обозначение задания, время последней проверки и следующий шаг: подождать, проверить календарь или принять заявку вручную. Техническому ответственному — обезличенное описание причины и ссылка на безопасный журнал. Ключи доступа и содержимое чужих заявок в общие уведомления не попадают.
Отдельно проверьте недоступность самого канала уведомления. Если сообщение о сбое отправляется через тот же отключённый сервис, оно не поможет. Владелец процесса должен знать, где самостоятельно увидеть очередь проблем и когда это делать. Способ оповещения выбирают по значимости процесса и возможностям действующей системы.
Ручной маршрут также заканчивается сверкой. Сотрудник, создавший запись самостоятельно, должен отметить это в учёте задания. Иначе восстановившаяся автоматизация может сделать то же действие снова. Заранее определите, кто передаёт такую отметку и как автоматическая обработка узнаёт о ручном результате.
Восстановите связь и сверьте очередь
Возвращение доступности — начало проверки восстановления. Нужно убедиться, что отложенные задания не потерялись, не выполнились дважды и не ушли с устаревшими данными.
В учебной серии оставьте три различимых задания: ожидающее обработки, выполненное вручную и отменённое до восстановления. После возврата связи сравните результат каждого с ожидаемым. Первое должно пройти согласованный маршрут, второе — не получить лишний повтор, третье — сохранить отмену. Если действующая система не поддерживает какую-то из этих ситуаций, зафиксируйте ограничение и доступный способ работы, прежде чем принимать её.
Проверьте порядок обработки только там, где он важен для процесса. Запоздавшая заявка на уже прошедшее время может требовать решения сотрудника, а не автоматического выполнения. Сервис не должен объявлять такое решение заранее принятым без правила, согласованного с владельцем процесса.
Сверяйте не только число заданий. Для каждого учебного обозначения должны быть понятны состояние, итоговое действие и подтверждение. Равенство общего количества не исключает подмену: одно задание могло потеряться, а другое выполниться дважды. После проверки удалите учебные записи установленным способом и сохраните обезличенный протокол.
Зафиксируйте результат испытаний до запуска
Итоговый документ должен отвечать на вопрос, при каких отказах процесс остаётся управляемым и какие ограничения ещё требуют решения. Одного слова «пройдено» недостаточно: сохраните ожидаемое поведение, факт и основание вывода по каждому сценарию.
Сбой считается разобранным, когда известно место сохранения задания, правдивый статус для человека, предел повторов, ответственный за исключение и способ сверки после восстановления. Если один из пунктов неизвестен, это конкретный незавершённый участок испытания.
Используйте чек-лист после серии, а не вместо неё. Его отметки сохраняются в этом браузере; они не проверяют интеграцию автоматически и не являются журналом реальных событий.
Готовность испытания
Отмечено 0 из 8
Сравнить задачи для ботов и автоматизации Nazara можно в разделе решений. Если у Вас уже есть маршрут с внешним сервисом, передайте через Умную форму его шаги, ожидаемый результат и описание опасного сбоя без секретов. Если вопрос связан с повторными обращениями, отдельно разберите проверку повторной заявки: она помогает договориться, что именно считать дубликатом.
Вопросы и ответы
Нужно ли намеренно ломать сторонний сервис?
Нет. Проверяют реакцию своей автоматизации через управляемую ошибку, задержку или тестовую среду. Воздействовать на чужую рабочую систему ради испытания нельзя; границы проверки согласуют заранее.
Доказывает ли успешный повтор, что всё восстановилось?
Он подтверждает судьбу конкретного задания. Для завершения серии ещё сверяют ожидающие, отменённые и выполненные вручную задания, а также достоверность показанного человеку статуса.
Можно ли одинаково обрабатывать все коды ошибок?
Такая политика требует обоснования. Неверные данные, нехватка прав и временная недоступность могут требовать разных действий. Значение ответа уточняют по документации конкретного API и проверяют на своём маршруте.
Что делать, если журнал содержит персональные данные?
Не переносите его целиком в общую переписку. Для разбора подготовьте обезличенный фрагмент с обозначением теста, временем и типом события, а доступ к исходному журналу ограничьте ответственными.
Как проверить интеграцию без отдельной тестовой среды?
Начните с управляемой подмены ответа своей стороной. Проверку настоящего обмена планируют отдельно на разрешённых учебных объектах. Если безопасные границы установить нельзя, испытание на рабочих данных откладывают.
Когда повторять испытания после первого запуска?
После изменений обмена, правил повторов, формата данных или способа подтверждения результата. Повторяют затронутые сценарии и связанные проверки восстановления; объём выбирают по фактическому изменению и его последствиям.