У автоматизации есть неприятный класс ошибок, который обнаруживается не по красному уведомлению и не по упавшему серверу. Наоборот, с технической точки зрения всё может выглядеть совершенно нормально.
Задание запускается по расписанию. Все сервисы доступны. В журнале последнего выполнения стоит статус «успешно». Ошибок нет.
Только полезная работа почему-то больше не происходит.
Например, система должна забирать новые заявки с сайта и передавать их дальше в рабочий процесс. В какой-то момент в форме меняется название одного поля. Интеграция продолжает запускаться, получать данные и успешно завершаться, но фильтр больше не находит подходящих записей. Никакого исключения не возникает. Просто на выходе получается пустой результат.
Через несколько дней кто-то замечает, что новых заявок подозрительно мало.
С точки зрения программы всё это время всё работало.
С точки зрения бизнеса автоматизация остановилась несколько дней назад.
Именно поэтому при внедрении автоматизации недостаточно контролировать, что программа запустилась и не упала. Нужно отдельно проверять, что произошло то, ради чего она вообще существует.
Технический успех и бизнесовый успех — разные вещи
Большинство систем мониторинга хорошо отвечают на технические вопросы.
Доступен ли сервер?
Работает ли приложение?
Запустилось ли фоновое задание?
Завершилось ли оно без исключений?
Получен ли ответ от внешнего сервиса?
Все эти проверки нужны. Но ни одна из них сама по себе не доказывает, что бизнес-процесс выполнился.
Представим автоматизацию, которая должна получить новые обращения, классифицировать их и создать задачи для сотрудников. Система успешно подключилась к источнику, получила ответ, обработала его и завершила выполнение.
Но в ответе оказалось ноль записей.
Возможно, действительно никто не обращался.
А возможно, изменился формат данных, сломался фильтр или система смотрит уже не туда.
Для программы оба случая могут выглядеть одинаково: ошибки нет.
Для бизнеса разница огромна.
Поэтому кроме технического состояния у автоматизации должно существовать понятие ожидаемого результата.
Самые неприятные сбои не выглядят как сбои
Если приложение упало, проблему обычно найти проще. Есть ошибка, журнал, уведомление, иногда даже конкретная строка кода.
Гораздо хуже так называемые тихие сбои, когда система продолжает выполнять сценарий, но перестаёт приносить полезный результат.
Причин у этого много.
Может измениться название поля во внешней системе. Старый фильтр перестанет находить записи, но технически останется корректным.
Может поменяться формат ответа. Нужные данные теперь находятся в другом месте, а обработчик продолжает искать их по старому пути.
Внешний сервис может ответить успешно с точки зрения сетевого протокола, но внутри ответа сообщить, что операция не выполнена.
Условие в процессе может начать отправлять все записи не в ту ветку.
Файл может приходить пустым.
Синхронизация может получать те же записи снова и снова, ничего нового не создавая.
В каждом из этих случаях система может честно поставить себе зелёную галочку.
Потому что программа проверяет одно: смогла ли она выполнить свои инструкции.
А бизнес интересует другое: получился ли ожидаемый результат.
Хороший мониторинг должен понимать смысл процесса
Допустим, есть автоматизация, которая каждый час переносит новые заявки из одного сервиса в другой.
Простой технический контроль может выглядеть так:
«Последний запуск был 15 минут назад. Ошибок нет».
Более полезный контроль задаёт другие вопросы.
Сколько заявок поступило на вход?
Сколько удалось обработать?
Сколько появилось на выходе?
Есть ли записи, которые находятся в промежуточном состоянии слишком долго?
Когда последний раз процесс действительно создал полезный результат?
Есть ли заметное отклонение от обычного потока?
Именно эти показатели описывают не работу программы, а работу бизнес-процесса.
В одном случае нормой может быть несколько сотен событий в час. В другом — одна операция в неделю. Поэтому универсального правила вроде «если за час ничего не произошло, отправить тревогу» не существует.
Мониторинг должен учитывать нормальное поведение конкретного процесса.
Отсутствие данных тоже нужно уметь интерпретировать
Здесь возникает важная сложность.
Если за последний час не было ни одной новой заявки, это ошибка или просто спокойный час?
Если за день не появилось ни одного документа, система сломалась или документов действительно не было?
Поэтому контроль результата нельзя строить только на жёстком условии «значение должно быть больше нуля».
Полезнее смотреть на несколько сигналов одновременно.
Например, процесс обычно получает от 50 до 100 событий в рабочий день. Сегодня к середине дня пришло два. Технических ошибок нет.
Это уже повод проверить систему.
Или процесс обычно что-то обрабатывает хотя бы раз в несколько часов. Последняя успешная бизнес-операция была двое суток назад, хотя источник продолжает генерировать новые данные.
Это намного сильнее говорит о проблеме, чем зелёный статус очередного запуска.
Для некоторых процессов имеет смысл учитывать день недели, рабочее время, сезонность и обычный диапазон нагрузки. Чем важнее автоматизация для бизнеса, тем точнее можно описывать её нормальное поведение.
Четыре уровня контроля автоматизации
Удобно разделять контроль на несколько уровней.
Первый уровень — доступность. Сервер отвечает, приложение запущено, необходимые сервисы доступны.
Второй — выполнение. Регламентное задание действительно стартовало и дошло до конца.
Третий — результат. После выполнения появились ожидаемые записи, документы, задачи, сообщения или другие объекты.
Четвёртый — качество результата. Данные прошли проверки, нет подозрительных дублей, количество исключений находится в нормальном диапазоне, а ручная очередь не растёт бесконечно.
Первые два уровня относятся в основном к ИТ-инфраструктуре.
Последние два уже описывают здоровье бизнес-процесса.
Именно их чаще всего не хватает в небольших автоматизациях.
Иногда система должна сама признать выполнение ошибочным
Есть полезный архитектурный приём: если критичный бизнесовый результат не достигнут, сценарий должен уметь сам превратить это в ошибку.
Например, процесс получил входные данные, но после фильтрации осталось ноль записей, хотя по условиям задачи такое состояние невозможно.
Или система отправила данные во внешний сервис, получила формально успешный ответ, но обязательного идентификатора созданного объекта в нём нет.
Или из ста входящих записей обработана только одна.
Вместо того чтобы завершить сценарий как успешный, можно явно зафиксировать нарушение ожидаемого условия.
Тогда технический мониторинг снова начинает приносить пользу, потому что бизнесовая проблема превращается в технически наблюдаемую ошибку.
Но важно не переборщить. Пустой результат далеко не всегда означает поломку. Условие должно опираться на смысл конкретного процесса.
Проверять нужно не только факт действия, но и состояние после него
Особенно полезна проверка результата после операций, которые что-то изменяют.
Представим, что автоматизация должна создать объект во внешней системе. Она отправила запрос и получила ответ.
Наивная реализация считает задачу выполненной на этом месте.
Более надёжная дополнительно проверяет: объект действительно существует? У него правильный статус? Данные сохранились полностью? Не появился ли дубль?
Такая проверка особенно важна при нестабильных интеграциях и повторных попытках.
Потому что между «мы отправили команду» и «нужное изменение действительно произошло» всегда существует небольшой разрыв.
Чем критичнее операция, тем меньше стоит доверять одному только факту успешного вызова.
Мониторинг самой автоматизации должен быть независимым
Есть ещё одна типичная ловушка: автоматизация контролирует сама себя.
Например, если произошла ошибка, тот же сервер должен отправить уведомление.
Пока проблема локальная, это работает.
Но если недоступен сам сервер, контейнер, сеть или вся среда выполнения, уведомление тоже не уйдёт. Поэтому для критичных процессов полезно иметь внешний контроль. Что-то независимое периодически проверяет, когда в последний раз автоматизация действительно выполнила полезную операцию.
Это может быть совсем простой механизм.
Главное, чтобы контролирующая система не падала одновременно с той системой, за которой она наблюдает.
Иначе получается пожарная сигнализация, подключённая к тому же автомату, который отключился вместе с пожаром.
ИИ делает эту проблему ещё заметнее
В обычной автоматизации большинство действий детерминированы. Если условия известны заранее, поведение системы хотя бы относительно легко описать.
С ИИ появляется дополнительная неопределённость.
Модель может правильно выполнить технический сценарий, но неверно классифицировать входящий запрос.
Она может вернуть структурированный ответ нужного формата, но ошибиться в содержании.
Агент может вызвать все необходимые инструменты и поставить задачу себе в статус «выполнено», хотя бизнесовый результат остался неправильным.
Поэтому в ИИ-процессах особенно опасно считать успехом факт того, что модель ответила или агент завершил цепочку.
Нужно контролировать состояние внешнего мира после работы модели.
Что появилось в системе?
Соответствует ли результат допустимым ограничениям?
Не выросло ли число исключений?
Не стал ли агент внезапно отправлять почти всё на ручную проверку?
Не изменилось ли распределение его решений после обновления модели или промпта?
ИИ усиливает старую инженерную проблему: формально успешное выполнение ещё меньше гарантирует полезный результат.
Полезно следить за количеством исключений
Есть ещё один показатель, который часто обнаруживает деградацию раньше серьёзной аварии.
Допустим, автоматизация обычно самостоятельно обрабатывает 95% входящих случаев, а 5% отправляет человеку.
Через месяц что-то изменилось во входных данных.
Теперь автоматически проходит 60%, а 40% оказываются в ручной очереди.
Система технически работает. Ничего не падает. Все данные в итоге обрабатываются.
Но автоматизация практически потеряла экономический смысл.
Если никто не следит за этим показателем, сотрудники просто начинают тратить всё больше времени на исключения, а руководитель может долго не понимать, почему ожидаемая экономия исчезла.
Поэтому мониторинг должен смотреть не только на ошибки, но и на долю ручного вмешательства.
Иногда это лучший индикатор здоровья процесса.
Необходимо проверять сами проверки
Самый надёжный способ понять, работает ли мониторинг, — специально сломать систему.
Не production, конечно, а тестовый сценарий.
Изменить ожидаемое поле.
Подать пустой результат.
Остановить один из этапов.
Вернуть неправильный статус.
Создать дубликат.
Задержать обработку на несколько часов.
И посмотреть, заметит ли это контроль.
Если мониторинг никогда не проверяли реальным отказом, нельзя быть уверенным, что при настоящей проблеме он действительно сработает.
Это очень похоже на резервное копирование: наличие бэкапа ещё не означает, что из него получится восстановиться. Наличие мониторинга ещё не означает, что он умеет обнаруживать нужный класс ошибок.
Что измерять после запуска автоматизации
Для каждого процесса набор показателей будет своим, но обычно полезно иметь хотя бы несколько.
Количество входящих событий.
Количество успешно обработанных.
Количество отклонённых.
Размер очереди ручной проверки.
Среднее время прохождения процесса.
Возраст самой старой необработанной записи.
Время последней успешной бизнес-операции.
Количество повторных попыток.
Число дублей или отменённых результатов.
Не обязательно строить отдельную сложную аналитическую систему. Иногда достаточно нескольких счётчиков и простых порогов.
Главное — чтобы они описывали то, ради чего автоматизация была создана.
Автоматизация не заканчивается после запуска
Многие проекты воспринимаются так: процесс настроили, протестировали, запустили — задача завершена.
Но автоматизация работает внутри постоянно меняющейся среды.
Меняются внешние системы.
Переименовываются поля.
Обновляются API.
Меняются бизнес-правила.
Появляются новые типы входных данных.
Сотрудники начинают использовать процесс немного иначе, чем предполагалось.
Поэтому надёжная автоматизация — это не только сценарий выполнения. У неё должен быть ещё сценарий обнаружения того, что она перестала делать полезную работу.
Именно этот слой отличает демо от системы, на которую бизнес действительно может опереться.
С чего начинать
Если в компании уже работают автоматизации, я бы не начинал с переписывания архитектуры или внедрения сложного мониторинга.
Полезнее взять один важный процесс и задать простой вопрос:
Как мы сегодня узнаем, что он перестал выполнять свою задачу?
Если ответ звучит как «сотрудник заметит», «клиент пожалуется» или «увидим, что данных давно нет», значит контроля результата практически нет.
Следующий вопрос: какой один показатель лучше всего характеризует полезную работу этого процесса?
Для одного процесса это число новых объектов. Для другого — время последнего успешного результата. Для третьего — размер очереди исключений или процент автоматически обработанных случаев.
После этого уже можно определить нормальный диапазон и настроить независимую проверку.
При аудите автоматизации я бы именно так и рассматривал каждый процесс: не только что он делает, но и каким образом доказывает, что продолжает это делать.
Потому что зелёная галочка означает лишь, что программа не заметила ошибки.
Бизнесу нужно знать, что работа действительно выполнена.
