Привет, всем!
Меня зовут Дмитрий Комиссаров, я системный аналитик, давно читаю хабр и вот решил попробовать выйти из RO. Недавно выступал на конференции с докладом, о системе сквозного бизнес‑мониторинга — теперь хочу написать статью на эту тему сюда.
Введение
Когда говорят «мониторинг», большинство представляет себе примерно одну и туже картину: стены экранов с цветными графиками, на которые пристально смотрит дежурная смена, готовая в любой момент что‑то предпринять при появлении красных огоньков. Наша система выглядит примерно так же, но проблемы которые такой мониторинг решает лежат на более высоком уровне абстракции.
В чём же принципиальная разница между бизнес мониторингом, и классическими системами мониторинга? Почему недостаточно просто поставить Prometheus с Grafana и считать, что всё готово? Дело в том, что бизнес‑мониторинг — это не про отдельные системы, а про здоровье процесса в целом. Представьте ситуацию: все ваши сервисы зелёные, нагрузка в норме, ответы приходят быстро, но часть транзакций даже не создалась, а в другом месте наоборот, пользователь несколько раз вынужден заполнять одни и те же данные. Техническому мониторингу тут нечего сказать — с его точки зрения всё работает отлично.
Поделюсь с вами, с какими вызовами мы столкнулись при создании бизнес‑мониторинга, какие решения нашли, и что узнали в процессе.
Что такое бизнес-мониторинг и зачем он нужен
Бизнес‑мониторинг отличается от технического двумя ключевыми особенностями. Во‑первых, мы мониторим не конкретные системы, а здоровье процесса в целом. Во‑вторых, этот мониторинг должен быть единым от создания клиентской транзакции до её завершения, проходя через все участвующие в процессе системы.
Возьмём типичный банковский процесс создания продукта. Клиент на фронтенде подаёт заявку, она попадает в первый бэкенд для проверок (которые могут включать в себя даже ручные операции вроде выгрузки Excel-файлов), затем передаётся во второй бэкенд для создания продукта. Каждый из этих шагов может работать технически нормально, но заявка может теряться на стыках между системами или на каком-нибудь из "ручных" этапов. Именно поэтому нужно мониторить весь путь целиком.
В системе мониторинга мы создаём модель процесса в виде последовательности состояний процесса. Если от отправки заявки с фронтенда до начала её проверки прошло больше времени, чем t1, значит, что-то пошло не так, даже если все отдельные компоненты формально работают исправно.
Требования к системе и их подводные камни
Когда мы начинали проектировать систему, у нас было несколько ключевых требований от бизнеса, многие из которых из которых оказались не такими простым, как казались на первый взгляд.
Отсутствие единого сквозного идентификатора
Первое и основное требование от бизнеса — система должна работать без единого сквозного идентификатора процесса. В реальном мире так происходит сплошь и рядом: заявка имеет свой номер, из неё рождается договор со своим номером, потом появляются файлы со своими идентификаторами. И все эти сущности нужно связать в единую цепочку событий.
Представьте последовательность событий, где у каждого есть набор ключей‑значений — идентификаторов. Первые два события имеют общий идентификатор (скажем, номер заявки), затем появляется событие, которое содержит и номер заявки, и номер договора — оно становится связующим звеном. Дальнейшие события уже могут ссылаться только на номер договора. Таким образом, система должна уметь строить цепочки по пересекающимся множествам идентификаторов.
Работа с произвольным порядком событий
Второе требование кажется техническим, но создаёт серьёзные проблемы в сочетании с первым. События могут приходить в систему мониторинга не в том порядке, в котором происходили в реальности. Сеть, особенности отправки событий разными системами — всё это нарушает хронологию.
Система может получить события в произвольном порядке, но должна выстроить их правильно, и уже на основе корректной последовательности считать метрики и отклонения.
Проблема совместного выполнения требований
А теперь представьте, что происходит, когда эти два требования работают вместе. События приходят не по порядку, у них разные идентификаторы, и мы не знаем заранее, какое событие с каким связано.
Может сложиться ситуация, когда сначала приходит событие с новым идентификатором — создаём для него отдельный процесс. Потом приходит связующее событие, которое показывает, что это был один и тот же процесс. Как их корректно объединить, не нарушив уже начатые расчёты метрик?
Мы решили эту проблему введением понятия «стартующее событие»: только определённые события могут создавать новый бизнес‑процесс в системе. Обычно это некое «зелёное окно успеха», показанное клиенту на фронтенде — момент, когда система сообщила клиенту что больше от него ничего не требуется.
Все остальные события, которые нельзя привязать к созданным процессам, просто откладываем в очередь. Как только приходит стартующее событие, создаём процесс, и все отложенные события пробуем привязать нему по идентификаторам в процессе. Это ограничение упрощает логику работы системы, хотя требует дополнительного анализа при постановке процесса на мониторинг.
Хранение информации для диагностики
Третье требование — хранения информации для первичной оценки проблем. Когда мониторинг показывает отклонение в конкретной клиентской транзакции, специалисты должны получить достаточно данных, чтобы понять, в какую систему идти разбираться дальше.
Проблема в том, что заранее неизвестно, какая информация понадобится для конкретного процесса. Сегодня это номер заявки и RQUID, завтра может понадобиться номер договора или идентификатор, о котором на момент разработки системы никто не подозревал.
Мы разделили события на две части: техническую (RQUID, статус, время, система‑источник, ключи‑значения) и дополнительную (произвольные данные в JSON). Техническая часть стандартна для всех процессов, а дополнительная настраивается под специфику конкретного бизнес‑процесса без изменения структуры базы.
Остальные требования
Следующие требования оказались более простыми в реализации и не преподнесли особых сюрпризов. Отслеживание нескольких SLA по процессу превратилось в обычную техническую задачу без подводных камней. Требование не становиться новой точкой отказа мы выполнили использованием push‑модели, когда системы сами отправляют нам события, а не мы их опрашиваем. Мониторинг в режиме онлайн стал естественным следствием этой же push‑модели: события приходят именно тогда, когда происходят, без задержек на опросы.
Для архитектуры мы выбрали сервисный подход с чётким разделением ответственности между компонентами, что позволило каждому модулю сосредоточиться на своей задаче. Gate реализует REST API для приёма сигналов мониторинга от внешних систем. Wire преобразует эти сигналы в события нашей системы и сохраняет их. Linker выстраивает из разрозненных событий правильные цепочки бизнес‑процессов, а Metrics работает фоновым процессом, считая отклонения и другие метрики по уже собранным процессам.
Разделение сигналов и событий
Ключевой архитектурный принцип — разделение сигналов от систем‑источников и событий мониторинга. Внешние системы отправляют нам сигналы о том, что у них что‑то произошло(желтые). А модель бизнес‑процесса в нашей системе состоит из событий или состояний процесса(зеленые).
На этапе анализа мы преобразуем: сначала строим модель процесса (какие события мониторим, между какими считаем время), потом настраиваем сопоставление сигналов и событий. Один сигнал может превращаться в несколько событий, или несколько сигналов — в одно событие, в зависимости от потребностей.
Такое разделение даёт гибкость: не все системы могут встать на мониторинг одновременно, фронтенды могут меняться, процессы развиваются. Сопоставления можно корректировать без изменения основной логики.
Фиксированный контракт
У нас есть фиксированная часть контракта (техническая информация) и переменная часть (бизнес‑данные). В фиксированной части стандартные поля: RQUID, статус, время, система‑источник, ключи. В переменной — структуры типа «заявка», «договор», «файл» с базовыми полями, которые можно расширять под нужды конкретного процесса.
Когда приходитновый процесс, часто можно начать со стандартного набора полей, а потом расширять по мере необходимости. Все дополнительные данные хранятся в JSON, что позволяет изменять структуру без миграций базы.
Что узнали в ходе работы
Чем раньше — тем лучше, но никогда не поздно
Если ставить процесс на мониторинг на этапе разработки, это помогает раньше и точнее выявить проблемы, которые всё равно бы всплыли в эксплуатации.
Однако даже процессы, которые годами работают в производственной системе, могут преподнести сюрпризы. Однажды мы поставили на мониторинг некий процесс скорее для галочки — он работал пару лет, претензий особых не было. И обнаружили, что 3,5% заявок в определённом статусе просто умирают. Люди ругались, заводили заявки заново, и с точки зрения бизнеса процесс работал. А мониторинг показал техническую проблему, которая съедала время и раздражала сотрудников.
Наблюдаемость — наше всё
Когда ставишь мониторинг на этапе разработки процесса, можно заложить удобную наблюдаемость с самого начала. Единая транзакция через все системы, нормальное журналирование, понятные метрики — всё это гораздо проще делать сразу, чем прикручивать потом.
Объективная картина для нескольких команд
Когда над процессом работают несколько команд, каждая хорошо знает свою зону ответственности, но плохо представляет общую картину. Единый мониторинг показывает, где реально узкие места. Не стоит одной команде оптимизировать ответ на 5 миллисекунд, если в соседнем окне заявки пропадают на день.
Не только отклонения, но и бизнес-метрики
Изначально мы планировали считать только SLA — отклонения от нормативного времени. Но когда процесс встал на мониторинг, бизнес понял, что можно считать ещё и количественные метрики. У нас есть воронка не только фронтового поведения клиентов, но и всех внутренних проверок. Можно посчитать, на каком шаге отваливаются клиенты, сколько циклов в среднем проходят процедуры, и найти точки для оптимизации.
Что делать, когда система мониторинга упала
А теперь история о том, как наша система упала, и что мы с этим делали.
Полгода спустя после запуска ко мне прибежало сопровождение: «ААА! мы в ПРОМе упали!» Первое, что порадовало — мы не утянули за собой клиентские процессы, то есть не стали той самой новой точкой отказа. Понятно, что это закладывалось изначально, но убедиться, что все прошло «штатно» в «не штатной» ситуации — это хорошо.
Разбираясь в причинах, обнаружили, что одна внешняя система, которая нормально работала месяцами, вдруг отправила нам 3764 раза подряд один и тот же статус. При этом это был не дубль события(тут идемпотентная обработка входящих событий сделала бы свое дело), а честные уникальные события со своим временим отправки — мы проверили их журналы. У них зациклился процесс и начал греть воздух отправкой одних и тех же файлов, которые система получатель отбрасывала, но каналы сеть забивалась и в принципе на ровном месте росла утилизация.
Мы не только исправили проблему на своей стороне (поставили ограничения на количество повторений статуса), но и сделали это новой метрикой мониторинга. Теперь, когда команда ставит процесс на мониторинг, мы спрашиваем: сколько раз может повторяться каждый статус? Если один раз — ставим лимит два, если может быть цикл до 10 раз — ставим лимит 11. По приходу лишнего статуса подсвечиваем проблему владельцам процесса.
И даже когда система мониторинга падает, из этого можно извлечь пользу при разборе проблемы.
Общие рекомендации
Перед тем как браться за e2e бизнес-мониторинг, оцените потребности и подумайте, нельзя ли их решить доработкой обычного технического мониторинга. Если процесс небольшой и хорошо формализуется, то можно обойтись Prometheus с дашбордами для бизнеса.
Но если есть сложные процессы, особенно с ручными действиями пользователей, если много команд участвует в одном процессе, если есть проблемы с единой транзакцией — тогда e2e бизнес-мониторинг будет полезен.
Используйте наши подходы, развивайте их, и это позволит сделать систему быстрее и надёжнее. Особенно важны: разделение сигналов и событий, концепция стартующих событий, фиксированный но расширяемый контракт.
И помните — любая система мониторинга требует команды на фулл-тайм поддержке. Чем более гранулярно вы мониторите процесс, тем чаще его нужно дорабатывать. Найдите баланс между детальностью и трудозатратами на сопровождение.
Главное — если команда понимает ценность мониторинга, она будет сама приходить с изменениями процесса и помогать поддерживать систему в актуальном состоянии. А если не понимает — лучше не тратить ресурсы двух команд на то, в чём не видят пользы.
