Русский
Русский
English
Статистика
Реклама

Оркестровка

Роботизируем параллельную обработку тысяч документов практический пример

27.04.2021 12:23:09 | Автор: admin

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

По данным исследования Deloitte 36% руководителей считает фрагментарные процессы главнейшим барьером для масштабирования автоматизации. Вендоры стараются сделать максимально простым и бесшовным процесс взаимодействия человека с RPA-системами, выстраивая оптимальную архитектуру своих решений. Таким образом можно значительно упростить автоматизацию длительных процессов, требующих участия человека.

В статье мы расскажем:

- как можно организовать работу с большим количеством документов,

- как в эту работу вовлечь бизнес-пользователей, когда это необходимо,

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

Начнем с реального примера.

Кейс страховой компании: как с помощью RPA достигнуть эффективности в 122 ПШЕ

Крупная страховая компания России обрабатывает более 24 тыс. договоров в день. Для этих целей в компании был создан операционный центр, который принимает договора от агентов и заносит данные договоров в базу. Роботизация в компании началась как оптимизация работы центра. Компания планировала перенести на операционный центр дополнительные функции, не увеличивая при этом численность персонала. Для этого была поставлена задача автоматизации текущих задач центра. Для успеха проекта достаточно было автоматизировать 100 ПШЕ (полных штатных единиц), этих ресурсов хватало на выполнение дополнительных функций.

Проект по роботизации начался в компании в 2017 году и за это время удалось всего на трех процессах (один из которых обработка поступающих договоров страхования) достичь эффективности в 122 ПШЕ. Роботы помогают сотрудникам центра обрабатывать гораздо больший объем документов, снизив вероятность ошибок до минимума. Сегодня в компании полностью автоматизированы обработка и учет договоров страхования, а также процесс по поиску убытков.

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

Обработка одного договора человеком занимала 5 минут, у робота это занимает чуть больше 1 минуты.

Роботы работают на 80% быстрее человека, а 70% всех задач они выполняют без его участия. Окупаемость роботизации всех трех процессов составила 8 месяцев.

Что под капотом: техническая реализация оркестровки

Кейс, приведенный выше, является примером автоматизации фрагментированных процессов, то есть процессов, которые разделены на этапы и требуют участия человека между этими этапами. Для описания таких процессов также используется термин human-in-the-loop. Автоматизация фрагментированных процессов достаточно новая функциональность для RPA-систем. В решениях UiPath она стала доступна с появлением Action Center. Робот, столкнувшийся с каким-либо бизнес-исключением или ошибкой, может создать задачу пользователю и отправиться выполнять другие задачи. После того, как человек даст свой ответ, первый свободный робот продолжит выполнять процесс. Рассмотрим упрощенный пример того, как автоматизация таких процессов может быть реализована. Мы создали простой процесс приема и обработки страхового договора. Документ поступает на вход, сотрудник извлекает из него данные и принимает решение, требует ли этот договор согласования. Если договор удовлетворяет формальным требованиям, он заносится в учетную систему. Этот пример является довольно простым для роботизации, сложности возникают, когда приходится обрабатывать большое количество таких договоров.

Мы предлагаем решать задачу обработки большого количества документов в процессах human-in-the-loopс помощью процесса оркестровки, который проверяет что именно происходит с интересующими нас объектами. Изобразим наш пример на схеме, процесс состоит из четырех этапов:

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

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

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

Процесс оркестровки постоянно следит, что происходит с элементами нашей очереди, и как только какой-нибудь из них обогащается данными, процесс проверяет требует ли этот договор согласования (в нашем простом примере мы отправляем на согласование договора, у которых высокая сумма выплат). Если нам нужно согласование, процесс создает задачу человеку в Action Center, если согласование не требуется, процесс создает задачу роботу на ввод данных в учетную систему.

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

Список задач для роботов выглядит следующим образом:

В нашем случае работают 2 робота, они берут задачи из списка на выполнение. На скриншоте нижний процесс InsContract_Main и есть наш процесс оркестровки. Он стоит на паузе, ожидая, пока какой-нибудь из элементов очереди обновится. На вход поступили 10 документов, соответственно добавилось 10 элементов в очередь, и на каждый элемент инициировался свой процесс InsContract_DU - распознавание и извлечение данных. Как мы видим, 4 таких процесса уже успешно завершилось, два документа из четырех не требуют согласования, и поэтому процесс оркестровки создал две задачи InsContract_EnterApprovedContract - процесс заведения договора в учетную систему, мы видим их первыми на экране.

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

Форма, которую вы видите на экране, создана с помощью low-code. Таким образом, задачи могут иметь любое представление. Для данного примера мы создали форму в которой виден сам документ, и слева от него отображаются нужные нам данные.

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

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

Пример отчета:

Как это было разработано?

Для реализации этого примера мы использовали активности из блока Long Running, они созданы специально для работы с фрагментированными процессами:

При отправке элемента в очередь мы использовали активности Add Queue Item And Get Reference/Wait For Queue Item And Resume.

При добавлении элемента в очередь автоматически запускается процесс обработки: для этого мы использовали триггеры на очередь - функциональность оркестратора.

Для создания задач по вводу данных в учетную систему - Start Job And Get Reference/Wait for Job and Resume.

Для создания задачи для человека в Action Center Create Form Task/Wait For Form Task and Resume.

Для параллельной обработки всех документов активность Parallel For Each.

Часть процесса оркестрации выглядит следующим образом

Итоги

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

Подробнее..

Вышел минималистичный Linux-дистрибутив Bottlerocket для запуска контейнеров. Самое главное о нём

11.09.2020 12:04:11 | Автор: admin


Компания Amazon объявила о финальном релизе Bottlerocket специализированного дистрибутива для запуска контейнеров и эффективного управления ими.

Bottlerocket (кстати, так называют мелкие самодельные ракеты на дымном порохе) не первая ОС для контейнеров, но вполне вероятно, что она получит широкое распространение благодаря дефолтной интеграции с сервисами AWS. Хотя система ориентирована на облако Amazon, открытый исходный код позволяет собрать её где угодно: локально на сервере, на Raspberry Pi, в любом конкурирующем облаке и даже в среде без контейнеров.

Это вполне достойная замена дистрибутиву CoreOS, который похоронила Red Hat.

Вообще, у подразделения Amazon Web Services уже есть Amazon Linux, который недавно вышел во второй версии: это дистрибутив общего назначения, который можно запустить в контейнере Docker или с гипервизорами Linux KVM, Microsoft Hyper-V и VMware ESXi. Он был оптимизирован для работы в облаке AWS, но с выходом Bottlerocket всем рекомендуется сделать апгрейд на новую систему, которая более безопасная, современная и потребляет меньше ресурсов.

AWS анонсировала Bottlerocket в марте 2020 года. Она сразу признала, что это не первый Linux для контейнеров, упомянув в качестве источников вдохновения CoreOS, Rancher OS и Project Atomic. Разработчики написали, что операционная система является результатом уроков, которые мы извлекли за долгое время работы производственных служб в масштабе Amazon, и с учётом опыта, который мы получили за последние шесть лет о том, как запускать контейнеры.

Экстремальный минимализм


Linux очищен от всего, что не нужно для запуска контейнеров. Такой дизайн, по словам компании, сокращает поверхность атаки.

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

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

Управление системой предусмотрено двумя способами: через API и оркестровку.

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

Фреймворк TUF (The Update Framework) загружает обновления на основе образов в альтернативные или размонтированные разделы. Под систему выделяется два дисковых раздела, один из которых содержит активную систему, а на второй копируется обновление. При этом корневой раздел монтируется в режиме только для чтения, а раздел /etc монтируется с файловой системой в оперативной памяти tmpfs и восстанавливает исходное состояние после перезапуска. Прямое изменение конфигурационных файлов в /etc не поддерживается: для сохранения настроек следует использовать API или выносить функциональность в отдельные контейнеры.


Схема обновления через API

Безопасность


Контейнеры создаются штатными механизмами ядра Linux cgroups, пространства имён и seccomp, а в качестве системы принудительного контроля доступа, то есть для дополнительной изоляции используется SELinux в режиме "enforcing".

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

Режим проверенной загрузки реализован через функцию device-mapper-verity (dm-verity), которая проверяет целостность корневого раздела во время загрузки. AWS описывает dm-verity как функцию ядра Linux, обеспечивающую проверку целостности, чтобы предотвратить работу зловредов в ОС, таких как перезапись основного системного программного обеспечения.

Также в системе присутствует фильтр eBPF (extended BPF, разработка Алексея Старовойтова), который позволяет заменять модули ядра более безопасными программами BPF для низкоуровневых системных операций.

Модель выполнения Задаётся пользователем Компиляция Безопасность Режим сбоя Доступ к ресурсам
Юзер задача да любая права пользователей прерывание выполнения системный вызов, fault
Ядро задача нет статическая нет паника ядра прямой
BPF событие да JIT, CO-RE верификация, JIT сообщение об ошибке ограниченные хелперы

Отличие BPF от обычного кода уровня пользователя или ядра, источник

AWS заявила, что Bottlerocket применяет операционную модель, которая ещё больше повышает безопасность, препятствуя подключению к продакшн-серверам с привилегиями администратора, и подходит для больших распределённых систем, в которых ограничен контроль над каждым отдельным хостом.

Для системных администраторов предусмотрен контейнер администратора. Но AWS не думает, что админу часто придется работать внутри Bottlerocket: Акт входа в отдельный инстанс Bottlerocket предназначен для нечастых операций: расширенной отладки и устранения неполадок, пишут разработчики.

Язык Rust


Инструментарий ОС поверх ядра в основном написан на Rust. Этот язык по своей природе уменьшает вероятность небезопасного доступа к памяти, а также устраняет условия гонки между потоками.

При сборке по умолчанию применяются флаги --enable-default-pie и --enable-default-ssp для включения рандомизации адресного пространства исполняемых файлов (position-independent executable, PIE) и защиты от переполнения стека.

Для пакетов на C/C++ дополнительно включаются флаги -Wall, -Werror=format-security, -Wp,-D_FORTIFY_SOURCE=2, -Wp,-D_GLIBCXX_ASSERTIONS и -fstack-clash-protection.

Кроме Rust и C/C++, некоторые пакеты написаны на языке Go.

Интеграция с сервисами AWS


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

Самым популярным оркестратором контейнеров является Kubernetes, поэтому AWS внедрила интеграцию с собственным Enterprise Kubernetes Service (EKS). Инструменты для оркестровки идут в отдельном управляющем контейнере bottlerocket-control-container, который включён по умолчанию и управляется через API и AWS SSM Agent.

Будет интересно посмотреть, взлетит ли Bottlerocket, учитывая провал некоторых подобных инициатив в прошлом. Например, PhotonOS от Vmware оказалась невостребованной, а RedHat купила CoreOS и закрыла проект, который считался пионером в данной области.

Интеграция Bottlerocket в сервисы AWS делает эту систему в своём роде уникальной. Возможно, это главная причина, почему некоторые пользователи могут предпочесть Bottlerocket другим дистрибутивам, таким как CoreOS или Alpine. Система изначально спроектирована для работы с EKS и ECS, но повторим, что это не обязательно. Во-первых, Bottlerocket можно собрать самостоятельно и использовать, например, как hosted-решение. Во-вторых, пользователи EKS и ECS по-прежнему сохранят возможность выбора ОС.

Исходный код Bottlerocket опубликован на GitHub под лицензией Apache 2.0. Разработчики уже реагируют на баг-репорты и запросы фич.



На правах рекламы


VDSina предлагает VDS с посуточной оплатой. Возможно установить любую операционную систему, в том числе из своего образа. Каждый сервер подключён к интернет-каналу в 500 Мегабит и бесплатно защищён от DDoS-атак!

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru