Комментарии 39
Как неожиданно! " Head of RPA" рекламирует очередную «кнопку счастья», которая снимет прямо вот все все проблемы.
«кнопке счастья»
Применительно к поставленной задаче, с помощью RPA можно разработать специального робота, который в режиме реального времени будет извлекать через UI необходимую информацию об остатках, после чего учитывать ее при расчете в системе заказа, внося соответствующие изменения через API.
Что тут обсуждать?
Ни какого то более менее внятного описания.
А стоит ввести RPA в поиск google, то вся первая страница выдачи — реклама.
что характерно ни одной ссылки на живые топики с вопросами. Н и ч е г о.
Плавали… знаем. поэтому Ваша статья — это просто рекламная статья.
Так что такое RPA? Даже расшифровки не увидел и ниче не понял. На счет микросервисов — видимо, ты не понимаешь что это такое или ты видел их неправильное использование. Примеры высосаны из пальца. Особенно про переписывание продукта на микросервисы для выполнения одной небольшой задачи)
А можно более подробно про минусы в долгосрочной перспективе? Я представил, что несколько лет спустя будет куча роботов между основными системами. Это начнет походить на сервисы/микросервисы. И может даже начнет конфликтовать в каких-то моментах. С этой точки зрения — архитектор из первой истории предлагал довольно рациональные вещи.
Поэтому архитектор вполне обоснованно послал. Делать работу качественно.
К тому-же этот робот, как и любая другая программа, должны быть протестированы перед запуском в «эксплуатацию» — вроде азы разработки.
И по этому тоже, архитектор послал.
Да, с колокольни мегаразработчика это видится как глумление над талантами. Но иначе ваш труд несет ничего полезного для бизнеса, поскольку создает больше проблем, чем решает.
Оказывается, иногда, для решения проблем бизнес не обязательно все и вся перекраивать.
Достаточно точечно снять боль, используя в том числе RPA. И выиграть время на постепенное разрешение узких мест.
Просто разработчики/девелоперы имеет непосредственное дело с последствиями этих попыток выиграть время.
Сама идея хорошая:
Что-то спарсить. Откуда-то быстро собрать данные.
Как «сесть на трубу процесса» для его изучения и оптимизации — отличная штука.
Шикарная штука для внедрения изменений: сели на процесс «сбоку», автоматизировали, поняли какие данные есть, каких не хватает, оптимизировали процесс, доказали бизнесу эффективность и передали в разработку.
Но вот только не надо говорить что роботы, которые через интерфейсы как боты взаимодействуют со старым неэффективным неудобным интерфейсом — это основа хорошей архитектуры. Если текущая команда не может хорошо справиться со старой архитектурой, то старая архитектура + роботы поверх этого всего — это смерть. После появления роботов вносить изменения станет вообще невозможно. Особенно если они сядут где-то на интерфейсы, где-то на API. И судя по всему еще и будут сделаны какой-то внешней командой или под управление внешних «консультантов по RPA».
Представим задачу:
Маленький европейский городок, очень узкие улочки, нет железных дорог, в радиусе 1000 км нет ни одного грузовика, и надо срочно перевезти 20 тонн в 30-килограммовых мешках.
И тут вдруг мы обнаруживаем, что в городке есть очень дружная тусовка автолюбителей. И они как раз собираются в автопробег в нужном направлении, и можно в каждый из автомобилей накидать мешков, и вся колонка отлично перевезет наш груз. Командный дух, польза для города, задача решена, не надо решать сложные вопросы с грузовиками, нет нагрузки на наш старенький мост 15 века, не будет перекрыта дорога для погрузки и вообще всё прошло на ура. Фанфары, салют, все молодцы, задача решена!!!
Но только не надо после этого говорить, что перевозка грузов колоннами по 100 автомобилей — это хорошая основа транспортной архитектуры для завода. Это прекрасное латание дыр, где больше вообще нет никакого выбора. А хорошей транспортной архитектурой так и остались железные дороги, порты, портовые краны, наливные и насыпные станции, контейнеровозы, сортировочные станции и т.д.
Вот и с RPA так же. Шикарное решение, чтобы быстро собрать данные, что-то проанализировать, собрать прототип, и выкинуть. И IMHO называть это основой IT архитектуры — это уже вредительство)
Представьте, бывают более прозаичные случаи.
Есть легаси система А, которая может только писать файлы в локальный каталог.
И легаси система Б, которая может только с GUI получать команды.
И нужно на основе информации из системы А, что-то переносить на регулярной основе в систему Б.
И в большой конторе, таких легаси систем может быть пачка.
RPA вполне закрывают такие вопросы. И в зависимости от количества легаси систем, такой подход в целом может превалировать над другими.
И это не означает, что подход RPA надо применять везде.
«Если у вас много легаси и у вас принято решение поддерживать его, то в рамках периода этой поддержки использовать RPA может быть разумно»
несколько отличается от
«RPA как основа IT архитектуры, которая победит Микросервисы»
P.S. Я вообще не сторонник микросервисов. И считаю, в 9 из 10 случаев переход на микросервисную архитектура вредит. А RPA в контексте очередной волшебной таблетки я считаю еще бОльшим злом. Сам подход RPA может быть ок, но вот подача этого подхода как «Основа архитектуры», которая «Решит вашу боль» — это откровенное вредительство и введение в заблуждение.
Да решать бизнес задачи быстро и дешево это хорошо и это то, к чему стремится любое взрослое подразделение разработки.
И вывод один RPA это действительно на все 100% КОСТЫЛИ и по другом назвать это нельзя
Хотите я расскажу свои истории. (извините, код пишу я лучше чем излагаю)
И так поехали:
История 1. Прибегает такой разработчик роботов с новой задачей — дайте доступ к БД. Мы такие — ну как же это не по канонам. И мы даже не боимся то он своими кривыми селектами или миллионом незакрытых контактов завалит нам базу, мы боимся костылей и боимся несогласованных действий (чуть по позже объясню)
И так этот человечек с горячими глазами прожужжал бизнесу все уши о том какой он молодец и как за пару часов решит все их проблемы и естественно прогнул все ИТ подразделение и пришлось ему дать доступ на прод.
Человечек этот решил все проблемы, ничего нам не сказав о том, как он их решил и не предоставив документацию что он делает в нашей базе.
ИТОГ: через месяц поменялись некоторые структуры в БД и значения так, что новая автоматизация завалилась. Не хочу дальше продолжать ибо мне самому противно от этой истории, в итоге которой я остался виноватым.
Но эпилог такой:
1. Задумываются ли эти мальчики с горячими глазами над тем, что классические команды разработки не валяют дурака и ЕЖЕДНЕВНО выполняются десятки релизов меняющие сложную и запутанную инфраструктуру. А архитекторы и бизнес аналитики усердно трудятся над тем чтобы изменения в точке А не привели к краху точки Б (и это тоже капец работенка)
2. Задумываются ли эти мальчики над безопасностью? Доступ к чтению из БД рандомных данных это огромная черная дыра в безопасности (у нас был инцидент когда один такой мальчик слил базу конкурентам)
3. Задумываются ли эти мальчики об обслуживании всего этого хозяйства? Были случаи когда чудо люди из отдела инноваций (у нас они себя зовут так) хостили продуктивные приложения на тестовом окружении и обижались когда админы их грохали без предупреждения и бэкапов.
P.s Может быть эта заметка просто порыв злости на это все дело, но и Вы должны понимать — написать код не самая трудозатратная часть разработки. Большинство проблем в согласовании требований, спецификаций API различных систем, тестировании и внедрении и эту проблему не решит ни одна роботизация
P.p.s За годы своего существования у так называемого отдела инноваций у нас не было ни одного действительно удачного проекта
История вторая
В одной компании была разработана концепция Микросервисной IT архитектуры. Рассчитывалось, что эта концепция избавит компанию от многочисленных проблем, связанных с работоспособностью бизнес-процессов. Привлекли специально обученных людей: архитекторов, проектировщиков, разработчиков, девопсеров — задумку стали притворять в жизнь. Подошел обозначенный срок запуска, а чуда не произошло.
Где-то заплакал Греф.
Рад, что тема резонансная. Значит потенциал, действительно, огромный. Будем работать в этом направлении еще активнее!
Конечно «резонансная». Ведь после таких «внедренцев» it-отделу это поддерживать. Было: апи с описанной структурой, стало нечто без структуры и изменяется в любой момент. Утрирую конечно, но не сильно.
P.S.: с каких пор парсинг ui противопоставляют архитектуре и, тем более, сервисам?
Вы просто сравниваете горячее с твердым. Архитектурное решение с автоматизацией процесса. Микросервисная архитектура легко живет без RPA, а вот RPA без архитектуры существовать не способно. Расскажите лучше почему, по вашему, RPA не может работать поверх микросервисов.
И если бы вы знали, почему микросервисы должны ходить каждый в свою БД, то легко бы поняли того архитектора, который не пустил в нее вашего робота.
К сожалению вы не за живое задели, а написали бесполезную статью для тех, кто не в теме. Вот вас прочитает "эффективный менеджер" или продукт менеджер за чашкой чая и пойдет мозги выносить обычным разработчикам.
Применительно к поставленной задаче, с помощью RPA можно разработать специального робота, который в режиме реального времени будет извлекать через UI необходимую информацию об остатках, после чего учитывать ее при расчете в системе заказа, внося соответствующие изменения через API.
Т.е. теперь у нас появился неявный контракт на фиксированный UI, про который никто нигде не знает?
Потому что в каком архитектурном документе это зафиксировано и какими тестами покрыто?
По поводу регрессионного тестирования могу дополнить, что наибольшую эффективность (по моему опыту) показывают запуск тестовых версий роботов на псевдозаявках — лучше любого отслеживания зависимостей.
Ничего не мешает фиксировать все зависимости корпоративной архитектуры в некотором едином пространстве, в том числе и Ui зависимости. И тесты/автотесты точно также делаются на все виды зависимостей.
И вы хотите сказать, что поддержка робота в этом случае дешевле, чем поддержка выделенного API? А за счет чего, собственно?
По поводу регрессионного тестирования могу дополнить, что наибольшую эффективность (по моему опыту) показывают запуск тестовых версий роботов на псевдозаявках
Наибольшую по сравнению с чем?
У меня, на самом деле, назрел вопрос: а почему вы, собственно, противопоставляете роботов традиционной IT-инфраструктуре? На основании чего вы говорите: вот это — не микросервис, и не традиционное решение, а RPA?
Если этот UI поставляется извне, то да, об его обновлении вы знаете заранее, обновляетесь не в любой момент, и проверяете в том числе работу роботов, заточенных на UI.
Если этот UI пилится внутри конторы, то довольно странно, использовать вообще UI,
Странно. Но автор статьи предлагает именно это.
есть возможность дергать API, который дергает UI.
… а вот это совершенно не обязательно.
Если этот UI поставляется извне, то да, об его обновлении вы знаете заранее
Неа, не знаете. Вы знаете об обновлении ПО. А вот содержит ли обновление ПО обновление UI — вопрос открытый.
Много воды и мало фактов. Сравнения не подкреплены какими-то цифрами или данными.
Также хочется услышать ответы на пару вопросов:
- Робот работает с UI. Т.е. в момент работы робота машина, на которой он запущен, другими роботами использоваться не может Т.е. аппаратные мощности будут утилизироваться по минимуму и большую часть времени будут простаивать? В то время как сервисы могут в фоне параллельно работать и выполнять какие-то операции. Есть сравнения по скорости выполнения и объëмам операций, загрузке сервера и т.п?
- Как администрируется всë это добро из N роботов? Как раскатываются доработки? Что с версионированием разработки? Что вообще требуется на минималке для поднятия одного робота?
- У сайта меняется UI, проблемы с сетью — лоадер после операции крутится на пару секунд дольше обычного, новая версия Chrome и прочее… Внешние факторы, влияющие на работоспособность роботов. Как повышается стабильность их работы? Retry-pattern'ы там всякие как реализуются и реализуются ли? Как много таких багов за день в среднем на бота приходится и кто (и главное — как? На ручном приводе?) эти баги устраняет?
Робот работает и с UI и это ужасно, непрогрузился элемент, завис ui, послали клик элементу, а он не сработал там еще можно что-то еще вспомнить. По поводу простоя, бывают разовые и непрерывные процессы, у обоих есть время на выполнение одного бизнес прохода по фамилии например, а таких фамилий 30 тысяч, а робот один обрабатывает только 5000, на этапе анализа бизнес процесса обычно узнается нагрузка и затем моделируется обработка всего скриптом-роботом. Тут много всего и соотношение во сколько раз быстрее робот сделает чем человек. И да насчет простоя оно же всё на виртуальных фермах крутится, ну не будет там нагрузки диспетчер в какой-нибудь полусон загонит машину.
Как администрируется.. плохо, гроб боль кладбище, в общем когда как. Если разраб не совсем дурной, то он прогоняет много тестов и всю падучесть фиксит, в идеале если падает робот то надо проверить последние действия и перезапустить, покрыть всё логами чтобы сапорту было что показать разрабу. Раскатка обновлений, там не те масштабы, нет миллиардов тразнакций в милисекунду, роботы параллелятся либо по тредам внутри своего потока, либо учетными записями в винде. На небольших проектах это отношение 1-1 поэтому последний релиз просто копируется в прод (ну ясен пень после тестов). Версионность особо смысла нет так как бизнес процесс он довольно статичен и если совсем сильно будет меняться, то начинается новый проект. В смысле что нужно для поднятия одного робота? Ну надо винсервер16+ и лицензии на учетки роботов, один сервак условно держит до 20 учеток, это всё так условность смотря сколько денег в мощи сервака бахнуть и сколько процессы жрут озу
у сайта/вин-приложения что-то меняется, тут надо сперва засмеяться потом заплакать. Смотря насколько разраб протестировал, добавил вместо слипов нормальные способы ожидания действий и тд. Если что-то меняется радикально, то робот ломается и требуется доработка, обычно после обновлений SAP много проблем, то индексы строк списка в ui поплыл, то элементов стало больше/меньше, если сапорт может то чинит мелочи иначе уходит разрабу. Не совсем внешние, но виндовое окно обновлений которое всё перекрывает может всё остановить, какие-то попап-окна которые ты не ждешь и они блокируют слой уи сзади. Стабильность делается от обычных трай до декоратора ретрай, есть в пипе удобный довольно, если надо больше то можно самому допилить, например следить чтоб процесс работал не более 10 минут иначе глушим его и перезапускаем. На каждый чих лучше логи писать, на критичные места можно письма слать. Если процесс не сильно монстро, то он быстро отлаживается до высокой стабильности. Такие моменты всё равно раз за разом прорабатываешь на стадии создания же еще. Сколько багов приходится на робота вопрос некорректный, размеры и сложность сильно отличаются, ну более-менее стабильно если раз в день зависнет, если дали подержать чужой проект смотришь мануал по рестарту (бывает сложный перезапуск особенно когда речь идет о больших суммах штрафов), а если свой проект ну штош дебаг в руки и погнал (в случае с чужим проектом тоже но если дают время на исследование, если надо просто гнать пока поток данных то всё на потом)
Разочарованы в IT? RPA как основа IT архитектуры, которая победит Микросервисы