Привет, меня зовут Денис, я работаю в Тинькофф и занимаюсь BPM-системами. В этой статье я расскажу, как мигрировать с легаси систем а-ля IBM BPM на опенсорс движок процессов Camunda на примере большого процесса. А в конце приглашу вас на четвертый митап по Camunda, который пройдет 27 февраля в Тинькофф, в Москве (м. Водный Стадион) вечером.

BPMS-системы и BPMN как способ их программировать

Идея про то, что через схемки можно программировать, хорошо продается, рынок растёт из года в год. Некоторые предприятия получают действительно классные результаты.
Чтобы делать хорошие проекты и успешно продаваться, BPMS-системы, помимо “поедания” BPMN-файлов, еще должны уметь:

• Определять конкретных исполнителей в процессах
• Предоставлять интерфейсы для пользователей, внедренцев и администраторов
• Вызывать внешние сервисы, слать и слушать события и т.д. В целом уметь “проваливаться” в код
• Обеспечивать моделирование и хранение данных
• Выполнять бизнес-правила
• Тестировать всё созданное

У нас в Тинькофф использовалась BPMS IBM BPM, которая помогала нам развиваться за счёт своей комплексности и приемлемого покрытия указанных фич. Но мы решили от неё отказаться.

Причины отказа от IBM BPM

Мы поняли, что от большого функционала BPMS системы мы используем только:

• Интерпретация bpmn-файлов
• Проваливание в код

Прочие вещи были вынесены в другие системы, например:

• Определение исполнителей зависит не только от конкретного процесса, но от множества факторов — больничные, отгулы, потенциальная выгода по конкретной заявке и так далее. Определение исполнителя в таком сценарии требует слишком много контекста, который не уживается в BPMS. По некоторым продуктам мы написали отдельные системы для определения исполнителей, а для некоторых — используем встроенные возможности CRM Siebel.
• Предоставление интерфейсов тоже уехало в Siebel или самописные CRM-системы. В Siebel как единую систему работы операционных сотрудников, а в самописные системы — потому что нужно было уметь делать что-то красивое и современное на UI.
• Хранение данных где-то переехало в Siebel — в ситуациях, когда множеству потребителей нужны CRUD-операции над данными, а где-то — в отдельные приложения. IBM BPM позволяет моделировать данные в реляционном стиле, сам создает таблички под модели. Но хранит это всё в одной базе для всех процессов, что создает дополнительную связность и нагрузку на базу.
• Для бизнес-правил традиционно используем IBM ODM, а сейчас начинаем использовать свой фреймворк на Kotlin.
• Нормально, в девелоперском стиле, тестировать приложения на IBM BPM мы так и не научились.

Были и общие вопросы, которые нам не нравились:

• Мы перешли на Kotlin и Spring, с этим сложно в IBM BPM.
• Очень мало специалистов или желающих работать c этим продуктом.
• Сложности совместной разработки схем\кода, по существу монопольный режим разработки.
• Здоровенный кластер из 4 нод требовал перезагрузки на 3 часа ( ~40 минут на ноду), что дико неудобно.

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

Например, был код отправки смсок, которым пользовались 2 продукта — РКО и аутсорсная бухгалтерия. Раньше текст был захардкожен на уровне компонента, но теперь процессу “аутсорсной бухгалтерии” захотелось передавать текст смс-ки из процесса. А процессу РКО этого не хотелось, но изменения надо вносить везде.

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

Почему выбрали Camunda мой коллега Николай писал в предыдущем посте.

Что такое большой процесс

Мы решили перенести крупный процесс из IBM (сначала, правда, потренировались на маленьком):

• Больше 100к инстансов в месяц.
• Больше 70 квадратиков
• Больше 30 интеграций с другими системами
• Быстрорастущий бэклог

Это процесс открытия расчётного счёта в Тинькофф Бизнес. Такой процесс перенести за один подход не получалось, требовалось бы пауза на 3-4 месяца в разработке, что не очень подходит темпам развития бизнеса.
Мы решили переезжать по кускам и рефакторить всё, что попадется под руку. А чтобы решить проблему шумных соседей, мы сделали отдельное приложение, которое отвечало только за заявки на РКО.

На верхнем уровне процесс выглядит так:

Правила перехода

№1: Перестали копать

Мы решили перестать делать новые фичи в старом приложении. Когда в беклоге появилась задача, мы старались идентифицировать квадратик\компонент\сервис к которому он относится и переписывали эту штуку с нуля в Camunda. Иногда по стоимости это было 1.2х (х — если бы делали в IBM), иногда — 3х или 5х.

№2: Camunda ничего не знает про IBM

После рефакторинга мы хотели просто выключить старое приложение, поэтому решили новые фичи делать в Camunda так, чтобы она вообще ничего не знала про IBM. Нам помогли две вещи:

• Бизнес-данные хранились в Siebel
• Готовые API от Camuda, которые помогают полноценно понять, чем и как завершился процесс.

В итоге мы сделали процесс в IBM, который запускает и получает результат от Camunda:

№3: Долгие “ручные задачи” и склеивание процессов

Сначала мы перенесли простые, одношаговые синхронные вызовы в Camunda и всё работало хорошо. После этого мы стали склеивать эти штуки в нормальные “бизнес-процессы”, где стало появляться ожидание от пользователей.
Пользователи могут делать свои задачи годами, поэтому у нас начала сыпаться куча задач на ручное исправление процессов из трешхолда. Победили так — просто стали учитывать тип конкретной задачи в Camunda и не учитывать трешхолд на задачах, где возможно долгое ожидание.

№4: Feature toggling на развилках

Некоторые куски кода были такие замороченные, что проще было написать с нуля и посмотреть “нормально ли работает”. Для этого ввели в IBM feature toggling со шлюзами. Направляли небольшой поток заявок в Camuda и смотрели ручками, всё ли ок.

Миграция инстансов из IBM в Camunda

В конечном счёте процесс в IBM состоял только из вызовов Camunda, а в Camunda была собрано 3 уровня процессов. Сами бизнес-процессы не сильно поменялись, поэтому у нас получилось перенести старые инстансы из IBM в Camunda на те же точки ожидания. И выключить IBM.

Что делать, если у вас похожая ситуация

Если хотите переехать на Camunda с легси BPMS, то:

• Перенесите контекст в отдельную базу.
• Перенесите пользовательские интерфейсы в отдельное приложение.
• Перестаньте кодить новый функционал в старом приложении.
• Используйте односторонние вызовы так, чтобы Camunda не знала о старой системе.
• Начните с маленьких квадратиков, но не забывайте о длинных пользовательских задачах.

Такой подход помог нам сократить количество инцидентов в 14 раз, время регресса в 4 раза, дал возможность релизить день-в-день и сократил затраты на ручное тестирование в 4 раза. Сейчас над проектом работает 5 человек и делает такой же объем работы, как 9 человек с IBM. Надеюсь, результаты у вас будут не хуже.

Приглашение на митап №4 по Camunda

27 февраля 2020 (четверг) в 19:30 по адресу Москва, Головинское шоссе 5А, бизнес-центр «Водный» проведём очередной митап по Camunda. Зарегистрироваться и прочитать про докладчиков можно по ссылке. Приходите!