Привет! Меня зовут Виктория Кабыткина, я работаю старшим системным аналитиком в компании Lamoda. По своему опыту как в банковской сфере, так и в сфере e-commerce, могу заметить, что во многих компаниях существует тенденция избавляться от монолита и переходить на микросервисную архитектуру. 

И это заставляет задуматься над множеством вопросов. А нужен ли на таких проектах бизнес-аналитик? А системный? А если все-таки нужен, то чем он там занимается? Какие задачи он решает? Полезен ли команде? 

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

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

Почему монолит пилят на микросервисы 

Вначале хочется ответить на вопрос: а зачем вообще распиливать монолит на микросервисы и почему многие компании сейчас этим занимаются?

К основным причинам можно отнести:

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

• Внесение изменений в монолит (сложно, дорого и больно). Попытка изменить что-то в коде может занять массу времени и вылиться в далеко идущие последствия. 

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

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

• Нехватка специалистов. Из-за своей сложности монолитные приложения требуют от инженера глубокого понимания внутреннего устройства кода. Это понимание обретается либо когда инженер долгое время работает над проектом, либо в ходе чтения документации, которая, к сожалению, остается неполной и неактуальной или ее нет вовсе. Тем самым, новички с трудом смогут разобраться в проекте (или не разберутся совсем), а уход ключевых опытных разработчиков может приостановить развитие проекта.

• Устаревший стек технологий. И последняя проблема монолитного приложения — устаревший стек технологий, который со временем может не поддерживаться. 

Чтобы решить эти проблемы, к нам на помощь приходит микросервисная архитектура. И вот что она может сделать:

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

• Time-2-market. Быстрая доработка ведет к ускорению time-2-market, что, конечно же, большое преимущество для бизнеса.

• Гибкость и надежность. Этот пункт можно разобрать на примере интернет-магазина, в котором есть следующие микросервисы: витрина с товарами, сервис оплаты, сервис доставки и сервис хранения. Вдруг сервис оплаты дает сбой. При микросервисной архитектуре все остальные сервисы будут работать, но клиент при оформлении заказа увидит сообщение: «Оплата заказа невозможна, повторите попытку позже». И как только мы починим наш сервис оплаты, клиенты получат уведомление и вернутся в интернет-магазин. При монолитной архитектуре мы такого бы не смогли сделать. 

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

• Переход на новый стек (при необходимости). При использовании устаревших технологий монолита всегда есть шанс перейти на более новые поддерживающие технологии.

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

• Маленькая система с небольшим набором бизнес-функций. Тут и распиливать нечего :)

• Не требуется масштабируемость проекта. Например, сервис отправки СМС клиенту, который не планируется развивать в дальнейшем.

• Отсутствие подготовленной команды разработчиков и администраторов (Agile и DevOps). Рост небольших независимых сервисов неизбежно увеличивает операционную деятельность. Необходимо обеспечить тесное сотрудничество программистов высокой компетенции, тестировщиков, инженеров сопровождения и прочих участников разработки продукта на всех этапах его жизненного цикла. Далеко не все компании смогут справиться с таким количеством изменений. 

Что и зачем мы распиливали в Lamoda

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

Система написана на языке PHP, а БД — на MySQL, размер которой приближается к 2 ТБ. Вся история заказа хранится в ней, а это более сотни таблиц, данные из которых активно используются BI-аналитиками. Еще есть несколько десятков точек взаимодействия с внутренними и внешними системами. На картинке показаны не все внутренние системы, а только малая их часть. 

Система существует с начала работы компании — то есть более 10 лет. Это большое серьезное приложение, содержащее домен Orders. А как известно, домен Orders это основополагающий домен любой компании из сферы e-Commerce.

Почему же нами было принято решение перейти на микросервисную архитектуру:

• Большой объемный монолит и шина данных. Система — не только единая точка взаимодействия с другими системами. Она содержит в себе доменную бизнес-логику. А объемная БД указывает на транзакционную зависимость.

• Блокировка бизнес-проектов. Сейчас запуск проектов требует проверку гипотез, организацию экспериментов и MVP. С этим очень тяжело и дорого в большом монолитном приложении, что приводит к медленному time-2-market.

• Слабо документированный код. Когда я пришла на проект, то документация по системе была, но устаревшая. Все время ее приходилось перепроверять, заглядывая в код, БД, логи и общаться с разработчиками из разных команд. 

• Устаревший стек технологий. Система процессинга заказа использует стек PHP/Zend1, который официально не поддерживается с 2016 года.

• Проблемы стабильности и сопровождения. Тяжело поддерживать и сопровождать такое объемное монолитное приложение как на инфраструктурном уровне, так и на программном.

Домены и их границы

Архитектурное решение по проекту принималось с использованием концепции DDD — Domain-Driven Design. Это подход, который нацелен на изучение предметной области компании в целом или каких-то отдельных бизнес-процессов. Весь его смысл строится вокруг контекстов. Ограниченный контекст (Bounded Context) — это явная граница, внутри которой существует модель предметной области.

Вот такое архитектурное решение было принято по распилу монолитного приложения на микросервисы. У каждого — своя БД и транзакционность.

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

• Checkout. Тут выделяется микросервис Order management, который несет в себе все функции, связанные с созданием, подтверждением и редактированием заказа.

• Delivery. В этот контекст входит создание и редактирование доставки в рамках заказа. За это отвечает микросервис Orders delivery, потому что у нас есть отдельные внутренние системы по доставке, где происходит настройка методов и интервалов доставки.

• Contact center. Здесь выделяется микросервис Notifications (пользовательские СМС и email), потому что большая их часть отправляется через монолит.

• Shipment. В данном контексте выделены сервисы стока (Stock), физической приемки товара (Returns) и Orders-shipment — взаимодействие со складом и ERP-системой в рамках заказа.

• Payments. Сюда входит все то, что связано с оплатой заказа и возвратом денег клиенту. 

И еще есть orders-data-api, который объединяет все данные из каждого контекста и по которому можно получить агрегат заказа — то есть данные в рамках одного заказа по оплате, доставке, набору items, статусу. Фактически этот микросервис заменяет БД монолита для получения всей истории по любому заказу.

Чтобы было немного понятнее, можно посмотреть на эту картинку через flow стандартного создания заказа. Сначала клиент создает заказ и к нему должна добавиться доставка через Orders-delivery, оплата через Orders-payment и отправка заказа на склад через Order-shipment. В дальнейшем, если клиент решит сдать товар, заказ пройдет физическую приемку товара через Returns и получит возврат денег через Refunds.

Какие задачи выполнял системный аналитик

Команда проекта выглядела таким образом:

• Рroject manager — 2 человека;

• Аналитик — 2 человека;

• IT-архитектор —  1 человек;

• Инженеры (разработчики + QA) — 35 человек.

Когда я пришла на проект в роли аналитика, меня уже ждал подготовленный бэклог из задач с их приоритетами и сроками. Он составлялся силами архитектора и PM на основе тех проблем и потребностей, с которыми команда уже столкнулась при верхнеуровневной проработке проекта. 

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

Исследование текущих бизнесов-процессов AS IS

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

Примеры:

Отмена заказа и редактирование заказа. В этих бизнес-процессах исследовались моменты от инициатора процесса до пользовательских нотификаций: через какие системы проходит бизнес-процесс, как происходит обмен данными между системами и какими именно данными, какие есть ограничения и нюансы по видам оплаты и по видам контрактов. Это помогло разграничить перенос бизнес-процессов на разные фазы разработки и разложить понимание бизнес-процесса на контексты (checkout, delivery, shipment).

Возврат денег. Полное погружение в бизнес-процесс возврата денег клиенту совместно с коллегами из бизнеса помогло найти и выделить узкие места, которые можно сразу закладывать в решение TO BE. А еще запланировать стадийность разработки будущего микросервиса (или микросервисов) с проработкой архитектуры.

Использование UI. У монолитного приложения есть свой UI. Необходимо было найти пользователей этого UI, чтобы подробнее изучить всю возможную функциональность монолита в плане пользовательского взаимодействия с системой и проработать TO BE решение для проекта. Само исследование было достаточно интересным: оказалось, что многие сотрудники компании используют этот пользовательский интерфейс (от бухгалтерии и маркетинга до инженеров технической поддержки).

Разбор существующих алгоритмов и интеграций монолита 

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

Примеры:

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

Взаимодействие с ERP. Также проводилась аналитика на предмет того, какие триггеры существуют в монолите для взаимодействия с ERP-системой и какой существует набор данных для каждого триггера. Еще один повод для изучения: пользуется ли ERP-система текущими взаимодействиями или они уже не актуальны. Это делалось с целью того, чтобы спроектировать домен правильно и по возможности не плодить лишних взаимодействий или объединить некоторые обмены или данные в них.

Проработка и согласование TO BE процессов с разработкой и бизнесом

Достаточно важный тип задач, в которых аналитик не просто собирает требования и передает их разработке, но и сама разработка активно вовлечена в проблемы и боли бизнеса. Тем самым проработка TO BE решения выглядит прозрачной для всех заинтересованных лиц. 

Примеры:

Исследование бизнес-процесса возврата денег. Тут можно вернуться к вышеуказанному примеру. После того как мы исследовали процесс AS IS, совместно с командой разработки и бизнесом были обозначены узкие места, которые необходимо закладывать в решение TO BE, а также проработку архитектурного решения. Еще мы собрали бизнес-требования для будущего TO BE решения, некоторые из которых можно внедрить сразу при разработке нового сервиса, улучшая тем самым процесс AS IS.

Систематизация микросервисов и их описание 

Эта задача возникла уже после того, как проект начал разрастаться. Многие коллеги приходили с вопросами, что это за сервис, зачем он нужен, если уже есть один с похожим названием и кучей всего остального. Когда мы устали отвечать на эти вопросы, то разработали шаблон карточки микросервиса, по которому мы создавали описание каждого сервиса совместно с разработкой.

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

Поддержка на этапе разработки и интеграционного тестирования

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

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

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

Какими инструментами пользовался аналитик для решения задач

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

• Интервьюирование бизнес-подразделений. Встречи, лекции и практические пособия со стороны бизнеса.

• Изучение существующей документации (Jira, Confluence). Тут хочется отметить, что документация не всегда была актуальной и ее приходилось обновлять на ходу.

• Анализ legacy-кода (IDE). С языком программирования PHP я была не очень знакома, но разобралась при помощи коллег из разработки.

• Анализ логов и данных в БД (Kibana, IDE для БД).

• Общение со смежными группами разработки по различным возникающим вопросам.

Чем полезен аналитик на подобном проекте

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

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

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

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

Оценивает проект целиком и помогает при проектировании API-методов. Поскольку все домены в Order processing так или иначе связаны между собой, то аналитик и IT-архитектор держат общую картину у себя в голове, чтобы помогать команде разработки справляться с трудностями и консультировать их. Аналитик помогает с точки зрения бизнес-процессов и их пересечения, а IT-архитектор — с технической стороны.

Выводы на основе личного опыта

Это был мой первый опыт участия в подобном проекте. Раньше я работала в проектах по рефакторингу системы, где не затрагивался контекст бизнес-процессов. А сейчас я поняла, насколько это круто и интересно — погружаться не только в технические аспекты и детали микросервисов (что напоминает конструктор Лего), но и решать такие проекты с участием самого бизнеса.

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

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