Привет, Хабр!

Меня зовут Иван Маслов, я работаю в Страховом Доме ВСК на должности руководителя направления RPA. Расскажу Вам об опыте использования роботов, и о том, как упростить работу с legacy системами. Уверен, будет интересно всем: и тем, кто скептически относится к роботам, и тем, кто хочет побольше о них узнать. Подробности под катом.

Robotic process automation (RPA) — подход, о котором мало кто говорит, так как считается, что это костыль, который приносит больше проблем, чем пользы.

RPA позволяет посмотреть на все процессы глазами бизнес-заказчика.

В перспективе бизнес-заказчику можно даже передать разработку робота, так как для настройки робота, иногда, достаточно просто прокликать по веб-интерфейсам IT систем.

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

О компании

Инфраструктура Страхового Дома ВСК насчитывает несколько сотен информационных систем. Малая часть из них, это: 1С, почта, хелп-деск. Сейчас мы переходим на микросервисную архитектуру, поэтому накопилось большое количество legacy, которое уже не будем развивать. Переход — дело небыстрое, следовательно нужны эффективные временные решения.

Поскольку мы — финансовая организация, мы отчитываемся центральному банку РФ. В связи с этим любые изменения в IT-инфраструктуре компании нам надо согласовывать. И это понятно: изменения связаны с риском утечки конфиденциальной информации.

С одной стороны, это плюс: все команды работают в едином процессе. Но есть и минус: долгое согласование изменений, особенно при замене чего-то старого на модное-молодёжное. Всё это продляет жизнь legacy-систем.

Почему за роботами будущее

Когда пытаешься оценить IT-индустрию по выступлениям на конференциях и техническим статьям, то оказываешься в плену ошибки выжившего. Ведь делятся своим опытом не все компании, а только те... кто делится. Чаще это лидеры индустрии, разрабатывающие новые подходы, которые потом перетекают в другие компании. Да и всегда хочется говорить о чём-то новом и современном, а не о заделывании дыр в legacy.

Обратимся к статистике использования современных методов разработки ПО. А именно: доля компаний, которые используют Kubernetes в продуктиве, приближается к 50%. В контейнерах же (не в Kubernetes, а просто в контейнерах) в 2020 запускалось всего 5% enterprise-приложений. По прогнозам, в 2024 году этот показатель вырастет до 15%. Такая информация помогает оценить число систем, которые точно НЕ модные-молодёжные.

Конечно, есть специфичные вещи, которые пока при всём желании не получится перевести в k8s (стандартный пример — базы данных). Но даже если прикинуть, что треть систем вне k8s есть legacy, то выходит всё равно существенный процент, с которым нужно как-то работать.

Итак, основным методом борьбы с legacy считается его переписывание: по частям или полностью. Но это не всегда финансово/технически возможно, и здесь начинается торг: сначала с собой, потом с бюджетом компании.

В The Site Reliability Workbook представлены основные способы борьбы с legacy-приложениями:

• Игнорирование (avoidance) — оставляем всё как есть.

• Инкапсуляция (encapsulation/augmentation) — пытаемся добавить какие-то надстройки, обёртки. Сюда же относится и технология RPA.

• Replacement/refactoring — рефакторим, заменяем системы - самый непредсказуемый в плане трудозатрат подход.

• Retirement/custodial ownership — за поддержку и развитие legacy отвечают команды, которые его используют в своих продуктах. Этим мы мотивируем такие команды перейти на более современные аналоги. (Приведу пример с операционными системами. Если в компании централизованно используется, допустим, RHEL 8 и есть централизованный узел его настройки и обслуживания, а чей-то продукт работает только на RHEL 6, то команда этого продукта будет самостоятельно администрировать RHEL 6)

Если не можешь устранить хаос — возглавь его.

Так и здесь: если не получается сделать всё по красоте и без legacy, то RPA может оказаться очень кстати. Но это ни в коем случае не серебряная пуля.

Верхнеуровневая схема работы RPA: подход снизу, подход сверху

Сразу внесу ясность в классификацию, то есть чем робот отличается от сервиса/микросервиса. Такую терминологию мы используем у себя:

• Робот — то, что использует только графический интерфейс IT систем.

• Сервис — всё остальное.

Как это проявляется? Сотрудник без опыта программирования не сможет запрограммировать новый сервис, но вполне сможет самостоятельно автоматизировать свой бизнес-процесс с помощью робота. В случае с RPA всегда возникает вопрос, какое место конкретный процесс занимает в текущей инфраструктуре.

Покажу это графически на небольшом примере

Возьмём простую систему из 3 сервисов, с которыми работает пользователь (НЕ программист). Сервисы ещё общаются между собой по разным протоколам: сокеты, REST API, файловый обмен. Других протоколов обмена данными каждый из сервисов не поддерживает. И чтобы был честный кровавый enterprise — каждый из сервисов написан в своей парадигме: клиент-сервер / десктоп / какой-то внешний облачный сервис.

Если же мы автоматизируем работу пользователя, мы только заменяем пользователя на блок робота. Притом интерфейс работы робота точно такой же, как и у пользователя (графический). Пользователь может запустить робота и проверить, что робот делает те же самые действия, что и он. А значит, вовлечение программиста может быть минимальным: не нужны круги с внесением правок.

Теперь представим, что мы разрабатываем сервис, программу. В таком случае нам нужно описать работу с каждым интерфейсом. Если и интерфейсы в первых трёх сервисах написаны на разных языках программирования, а мы пишем вообще на четвёртом языке, то затрат будет ещё больше. Тут уже сам пользователь сделать ничего не сможет без программиста.

Резюме: есть условный подход «сверху», когда мы заменяем пользователя роботом, который выполняет те же самые действия, что и пользователь. И есть подход «снизу»: когда мы разрабатываем программу, которая выполняет аналогичные действия программно. У обоих подходов есть свои плюсы и минусы, но главное, что хотелось показать этим примером:

подход с RPA — это не костыль, а полноценное решение

Использование сторонних централизованных решений

У нас в компании до pyOpenRPA долгое время работало проприетарное решение для RPA (входит в топ-4), на базе которого было успешно разработано огромное множество роботов. Для их работы использовалась БД SQL Server. Получалось, что если возникала проблема с БД (а проблемы возникали), то отключались сразу все роботы. Такая централизованная точка отказа создавала много проблем.

Пример соотносится со всеми централизованными решениями: Jira, CI, Power BI. Понятно, что их доступность высока за счёт резервирования всего и вся. Но, как ни крути, изначально в архитектуру заложено то, что какое-то изменение может порушить сразу всё.

В предыдущей статье я кратко рассказал о технической составляющей решения, на которое мы перешли. Преимущество архитектуры pyOpenRPA — это децентрализация. Для запуска робота нужно всего лишь скачать себе Git-репозиторий на ноутбук и запустить. В случае каких-либо проблем с обновлением или настройками упадёт только часть роботов.

Для недоступности же всех роботов нужно уронить всю сеть компании.

Тем не менее это не освобождает от анализа существующих решений перед написанием нового робота. Мы всегда задаем сами себе такие вопросы: «А можно ли взять существующее решение?», «Не изобретаем ли мы велосипед?».

Основной стоп-фактор по использованию ряда существующих решений — это сложность развёртывания и конфигурирования, которая не обоснована в каждом конкретном случае.

Как роботы могут служить

Подключение нового сотрудника

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

При подключении нового сотрудника заявок нужно много: создание учётной записи, сетевые доступы, VPN. Логичное решение — комплексная заявка, содержащая несколько атомарных. Это было бы удобнее сотрудникам-пользователям, но сложнее в поддержке со стороны разработки. Поэтому здесь напрашивается робот, который сможет генерировать и отслеживать любое количество комплексных заявок.

Автоматическое добавление логов в инциденты

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

Ещё один кейс для робота, который при создании инцидента добавил бы недостающую информацию.

Автоматизированный учёт бизнес-эффектов

Мы всегда должны быть готовы продемонстрировать бизнес-результат нашей роботской деятельности. Для того чтобы это сделать, необходимо составить отчёт по следующим параметрам:

• увеличение выручки (увеличение числа продаж);

• уменьшение затрат (минимизация штрафов);

• сокращение FTE (сокращение рутинного ручного труда);

• минимизация SLA (уменьшение допустимого времени на покупку страхового продукта).

Первая идея: «Нам нужен Power BI». Дальше мы начали исследование по Power BI (нужен ли он нам для такой задачи, реально ли обеспечивает потребности и т. д., и т. п.).

Power BI состоит из нескольких сущностей: БД, сервер приложений, отдельная виртуалка. Следовательно, требует больше ресурсов и настройки, чем робот.

Я думаю многие согласятся с тем, что: «Чем больше технических звеньев, тем выше риск сбоев». Между тем RPA даёт простоту развёртывания, так как это всего лишь репозиторий в Git. Это на 90% сокращает этап с доп. настройкой приложения.

Тут мы решили (вы угадали) разработать робота. Основной плюс — робот был запущен за неделю. И вот он собирает для нас аналитику уже полтора года. Также мы рассчитали, что наша система сбора бизнес-эффектов точно сможет работать в течение 10 лет, если не менять функциональность.

Как развиваем существующее решение

Сейчас в компании используются суммарно 40 роботов. Для каждого робота у нас выводится 3 контура: dev, test, prod. Роботов специально проектируем простыми (до 3-х месяцев разработки). Если робот сложный, для проверки его работы требуются автотесты. Но пока сложных роботов не делаем, так как это противоречит основной концепции их использования.

На этапе появления задачи по проектированию сложного робота, я думаю, проще будет реализовать простой сервис. Визуализацию результатов робота делаем, только когда это действительно необходимо. Для этого используем Jupyter Notebook с библиотекой Pandas. Серверного Jupiter нет, да и не особо мы испытываем в нём потребность — нам достаточно локальной визуализации.

Как и в случае с сервисами, грамотное тестирование перед продуктивом — это обязательное требование. Так как роботы работают с другими сервисами, очень важно соблюдать релизную политику по обновлению всем участникам (и команде роботов, и другим).

Однажды при выкатке обновления на продуктив со стороны другой IT-системы разработчик робота узнал об изменениях только после того, как робот перестал выполнять свою функцию — далее эта проблема решалась в лучших IT-традициях.

В каждом роботе есть файл конфигурации и его исходный код. Наш подход: при изменениях в исходном коде робот проходит полное тестирование. Если происходит только изменение конфигурации — нужно лишь небольшое тестирование, которое обычно занимает 1 день.

Собираем логи

В процессе эксплуатации наши логи эволюционировали по количеству и качеству информации, ведь, пока не возникнут проблемы или сбои, написать хорошие логи вряд ли получится. Поскольку роботы выполняют свою функцию децентрализованно, то логи у нас сначала фиксировались в разных локациях — в зависимости от робота. Но у некоторых процессов возникла реальная необходимость в консолидации логов для постанализа. Чтобы решить эту проблему, мы сверстали и запустили консолидированное хранилище логов.

Консолидированное хранилище логов реализовано в PostgreSQL. Чтобы проверить, подходит ли нам такое решение, провели успешное нагрузочное тестирование, в котором 200 сервисов писали одномоментно в общую базу данных. Для локальной разработки робота сделали свой «дистрибутив» PostgreSQL, не зависящий от установки. При его установке копируется папка с БД, настраивается автозапуск и всё, что упрощает настройку локального окружения разработки.

Отсюда логичный вопрос: почему не взяли ELK (Elasticsearch, Logstash, Kibana) в качестве решения по сбору и хранению логов? Мы решили, что ELK будет оверкиллом в нашем случае, вдобавок нет соответствующих компетенций, а нам было важно запуститься быстро. Плюс с PostgreSQL команда была уже знакома.

По нашим оценкам, если бы выбрали ELK, его запуск занял бы 2 месяца. Тем не менее ELK подключается к целевой платформе микросервисов, поэтому в планах всё равно перейти на него в будущем.

Храним конфигурацию

Важный вопрос: как хранится конфигурация для каждого из контуров? Имеются в виду адреса сервисов и порты. Мы пошли по пути стандартизации использования роботов через локальные конфигурационные файлы. Робот понимает, в каком контуре запущен, исходя из конфигурации. Файл конфигурации накатывается через инструмент CI (continuous integration) на стороне оркестратора. Для логов/паролей используем хранилище секретов.

Приглашение к дискуссии

Используете ли вы технологию RPA в своей компании? Считаете ли это стоящим подходом, или есть сомнения? Какие технологии применяете для увеличения бизнес-эффекта? Давайте обсудим это в комментариях.

P. S.

Кстати, мы в поиске сотрудников, которые хотели бы выстроить новую технологическую компанию. Ищем специалистов всех профилей: программисты, тестировщики, DevOps’ы, аналитики. Также в Томске и Волгограде мы набираем студентов на оплачиваемую стажировку. Enjoy :)