От простых роботов к «микроботам» (роботы как микросервисы)

Роботы завоевывают все больше места на ИТ-ландшафте компаний разного масштаба из разных секторов экономики благодаря своей простоте: создавать скрипты в визуальных интерфейсах могут специалисты, прошедшие 2-4 недельные курсы на том же уровне, что и программисты с многолетним стажем. Это возможно, так как современные RPA-платформы дают готовые технические и технологические решения «из коробки».
Такая простота часто приводит к тому, что роботов начинают использовать не только на маленьких рутинных операциях, но и на масштабных процессах, где требуется построить взаимодействие между разными системами, которые работают на отличающихся технологических стеках и не имеют готовой интеграции друг с другом.
В итоге не редко получается такая ситуация, что единожды запущенный робот действует много часов (в некоторых случаях – сутками). Но чем дольше выполняет операции робот, тем быстрее растет вероятность неожиданной ошибки, порой даже независящей от разработчиков решения: банальное падение сети, перезапуск серверов целевых приложений, высокая загрузка сети из-за массовых звонков по ВКС – в результате робот просто может остановить свою работу из-за «непредвиденной ошибки».
 


Самым неприятным в такой момент становится то, что мы не можем точно понять:

• На каком по счету документе или заявке он прекратил свою работу?
• В какие системы он уже успел внести информацию, а в какие нет?
• Сколько итераций не отработал робот – на сколько это критично для бизнеса?

Конечно, проведя расследование можно найти истину по всем вопросам, но время – деньги, которые тратит компания, а хотелось бы избежать таких ситуаций (или хотя бы сократить до минимума).

Реестр обработанных документов / заявок

Самым простым и очевидным решением является формирование реестра "задач" в виде какого-нибудь CSV или Excel-файла, в который будут записываться строчки с заданиями для робота (одна строчка = один документ или заявка). При запуске робота этот реестр должен пополняться новыми заданиями со статусом "Новая", после чего должны браться все задачи «от самой старой к самой новой», при этом обрабатываемая задача должна помечаться, например, статусом «В обработке». По мере обработки заданий будет проставляться статус "Выполнено" (или «Ошибка»). Таким образом в случае непредвиденной остановки робота будет гораздо легче понять – на какой итерации робот прекратил работу.

Формирование такого реестра не является сложной задачей, ведь операции по работе с теми же CSV и Excel-файлами – стандартные для любого адекватного RPA-решения, даже новичок сделает это меньше чем за час.
 

Здесь, наверное, можно было бы написать «Happy end» и закончить статью... Но нет, мы только начинаем постигать на сколько глубока кроличья нора этой проблемы!

С реестром в виде файла возникают новые проблемы:

• Он растет на диске машины с роботом. Иногда слишком быстро! Со временем это приведет к полному заполнению ограниченного в объеме диска, а разработчику придется придумывать схему хранения архивов, так как некоторые реестры удалять нельзя по требованиям безопасности или аналитиков, которые хотят иногда выполнять анализ выполненных ранее задач;
• Бывает так, что файлы на локальных дисках блокируются, и это может так же привести к полной остановке робота, при этом без пометки о том на каком моменте произошла проблема;
• При желании масштабировать робота, чтобы часть задач выполнялась на одной машине, а часть на другой, потребуется небольшая исследовательская работа, чтобы грамотно распределить документы и заявки между разными роботами.

Решение проблемы реестра

Отталкиваясь от последней проблемы довольно быстро приходит понимание, что необходимо вести такой реестр не на машине с роботом, а где-то на сервере, куда будет доступ у всех роботов. Кроме того, необходимо придумать механизм, который станет «узким горлышком» и не будет подпускать к реестру в одну единицу времени больше одного робота (чтобы два и более роботов не взяли одну задачу).  

Так как важное качество разработчика – это лень, первое решение принято находить в Интернете. Довольно быстро можно найти такую методологию, как «брокеры сообщений», которые позволяют создавать очереди, куда можно добавлять произвольное количество сообщений с данными, а также получать со множества «клиентов» эти сообщения в порядке очереди (FIFO - первый вошел первый вышел). Примеры брокеров: RabbitMQ, Kafka.

На первый взгляд кажется, что это то, что нам нужно:



Теперь можно, наверное, написать «Happy end»? К сожалению, нет!

С брокерами сообщений есть проблема – не все они хранят передаваемые данные длительное время. То есть, если в данный момент к брокеру не подключен ни один получатель - брокер может просто «забыть» это сообщение, а робот, который подключится через несколько минут – уже ничего не получит.

Но даже если мы уверены в том, что хотя бы один робот всегда будет доступен или мы настроим хранение данных в очереди брокера до востребования – нужно учитывать, что установка и обслуживание брокера сообщений потребует дополнительных ресурсов (как аппаратных, так и человеческих) и компетенций.

А можно без сторонних решений?

Отличная новость – похожий на брокеры сообщений механизм уже встроен в продвинутые RPA-платформы на стороне серверной компоненты, обычно он называется «Очередь данных», либо «Очередь транзакций». Помимо того, что его не нужно отдельно устанавливать, настраивать и обслуживать, этот механизм обеспечивает хранение всех данных как до использования роботами, так и после, благодаря чему наши коллеги из отдела информационной безопасности и аналитики будут спокойны.

Создание произвольного количества очередей не требует особых компетенций, а интерфейсы обычно построены так, что делать это могут даже не разработчики RPA-решений:
 


Для отправки задач в очередь, их получения и отметки статусов есть специальные активности, которые обычно так же доступны в студии разработки роботизированных процессов, пример из платформы PIX:



В итоге мы получаем универсальный централизованный реестр, благодаря которому всегда будем знать какие задачи выполняются прямо сейчас, а также легко сможем понять на чем остановился робот, чтобы помочь ему продолжить свою работу в кратчайшие сроки.

Похоже, мы приблизились к тому моменту, когда напишем с вами «Happy end»… Но это еще не так…

Микросервисный подход и в чем его проблема

Использование механизма очередей открывает нам дорогу к переходу от монолитной архитектуры робота (когда весь процесс обрабатывается от начала до конца на одной машине) к микросервисной когда весь процесс разделен на логические части, каждая из которой может обрабатываться как на этой же, так и на других машинах:



Если скрипт робота разработан таким образом, что имеются отдельные блоки, подскрипты, то как правило разделить один процесс на несколько независимых, связанных друг с другом через очереди не является серьезной проблемой.

Скорее, даже наоборот – такой подход позволяет сделать более контролируемой разработку процессов по типу «Единого окна», когда требуется получить исходную заявку из единого массива, а далее в зависимости от ее типа выполнить определенный набор действий – в этом случае будет достаточно всего лишь поместить заявку в нужную очередь, которая будет подхвачена другим роботом с соответствующим скриптом.

После первичного ввода в эксплуатацию такого процесса на микросервисной архитектуре будет гораздо проще добавлять новые варианты обработки типов заявок: создавая новую очередь и соответствующий скрипт, не влияющий на всю остальную схему.

Но кажущаяся простота перехода скрывает за собой новые проблемы, связанные с вопросами обслуживания такой схемы:

• Сколько всего есть очередей для одного микросервисного процесса?
• Как можно контролировать нагрузку на конкретный участок процесса?
• Где посмотреть схему взаимосвязей роботов через очереди?
• Как сформировать информацию о "сквозном" прохождении (времени запуска первого и завершения последнего роботов)?

Все эти вопросы можно решить с помощью ведения технической документации, описывающей ваше решение целиком. Но на сколько вам удобно постоянно сверяться с документацией? Не стоит так же забывать, что мы живем в реальной жизни, а не в учебнике: в большинстве случаев документация составляется один раз при вводе системы в эксплуатацию и не обновляется по мере «небольших незначительных правок» системы (вот только через полгода-год эти «незначительные правки» приводят к тому, что большая часть документации не соответствует действительности).

Таким образом мы приходим к выводу: нам необходим какой-то такой инструмент, который позволил бы нам визуализировать все связи, причем в «живом» режиме (не отличался от действительности в любой момент времени).

Создание «процессов-диспетчеров»

Одним из самых популярных решений данной проблемы является создание так называемых «Процессов-диспетчеров» (на английском dispatcher). Суть их проста – выделить отдельный скрипт робота, который будет управлять передачей данных между другими роботами «исполнителями» (на английском performer).

Данный подход в целом делает историю более контролируемой, но несет в себе новые недостатки:

• Если схем много и между ними надо сверяться, придется открывать много экземпляров студии разработки, что может сильно нагрузить процессор и оперативную память;
• Исполнение каждого «диспетчера» требует свою лицензию робота. То есть чем больше у вас процессов, которыми надо «рулить сверху», тем больше лицензий необходимо докупить.

Как можно решить эту проблему? Можно использовать сторонние инструменты контроля, в которых будут выполняться аналогичные операции через API сервера RPA-решения, но без потребности в закупке дополнительных лицензий. Однако, как и в случае с брокерами сообщений – это еще одна технология, которую нужно устанавливать и обслуживать.

Интересное решение данной проблемы предлагает Российский вендор PIX – инструмент диспетчеризации сложных процессов встроен непосредственно в мастер. Он обладает понятным визуальным интерфейсом, работе с которым можно научить далекого от программирования человека. Кроме банальных операций вызова роботов, этот инструмент позволяет:

• Строить цепочки исполнения задач на роботах
• Запускать несколько задач параллельно (с ожиданием завершения)
• Ожидать появления элементов в очередях
• Получать данные из сторонних брокеров сообщений (RabbitMQ, Kafka)
• Отправлять HTTP-запросы, письма, уведомления
• Учитывать выполнение условий, тем самым обеспечивая нелинейность исполнения

За каждым синим прямоугольником с иконкой «PLAY» на картинке выше – кроется вызов задач. При этом для каждой задачи можно настроить произвольное количество резервных роботов, которые будут ее исполнять:


 
Самый приятный бонус – все это работает без необходимости закупать дополнительные лицензии на роботов. Сколько вам нужно «процессов-диспетчеров» – столько и запускайте, вы ограничены только техническими ресурсами вашего сервера (если что – можно перейти в кластерный режим, но об этом расскажем в другой раз).

Заключение

С переходом на микросервисную архитектуру мы можем обеспечить гибкое управление ресурсами при выполнении большого процесса. Например, если несколько задач выполняются быстро – для них будет достаточно выделить единого робота на всех, а вот для других задач, которые выполняются долгое время – можно выделить сразу нескольких роботов, которые будут вести обработку параллельно, независимо друг от друга.

Чтобы не потерять контроль – у современных RPA-разработчиков есть все необходимые инструменты, ими лишь нужно научиться правильно пользоваться. Для этого есть как официальная база знаний вендора, так и курсы профессиональной подготовки, например, от академии RPA2.

Совершенствуйте свои навыки и переводите своих роботов на современные рельсы, тогда точно у всех будет Happy end!

Автор статьи: Драздов Валентин Сергеевич, менеджер продукта PIX RPA
Подписывайтесь на канал Валентина в Telegram, где он делится технической информацией об RPA и рассказывает о разных интересных мероприятиях: https://t.me/vdsdblog