Привет, Хабр! Хотим рассказать о том, как и зачем Х5 Group внедряет зонтичный мониторинг Monq, почему сущность и состояние «магазина» для бизнеса важнее виртуальных объектов, ну и как вообще стало возможным не только собрать под один зонтик >1.1 млн объектов и данные всего ИТ-окружения, но и силами «ЛАНИТ-Интеграции» автоматизировать построение модели здоровья и ресурсно-сервисной модели с помощью low-code автоматизации. 

В этой статье мы хотим остановиться на следующих вопросах: 

• причинах, по которым Х5 принял решение внедрять зонтичный мониторинг;

• пирамиде внедрения – подходе, используемом на проекте для подключения всего ИТ-окружения к платформе;

• концепции организации мониторинга и трансформации подхода «смотрим на сервисы» в подход «смотрим на состояние объектов реального мира, влияющих на бизнес»;

• способах подключения данных к платформе; 

• автоматизации процессов построения ресурсно-сервисной модели и модели здоровья.

У этой статьи четыре автора (над проектом мы работаем как команда-связка «клиент – интегратор – вендор»): 

1. Александр Лукиных, начальник управления централизованного мониторинга Х5 Tech;

2. Олег Ширнин, ведущий разработчик инфраструктурных решений Х5 Tech;

3. Александр Петренко, ведущий аналитик Monq Digital Lab;

4. Илья Кузьминых, архитектор решений направления мониторинга компании «ЛАНИТ-Интеграция».

Проект находится на стадии внедрения, но уже сейчас:

1. зонтик подключён к 14 внешним системам;

2. создано 1.11 млн конфигурационных единиц (КЕ);

3. настроена метамодель для 10 типов КЕ;

4. данные о КЕ и метриках на них обновляются по 100+ сценариям автоматизации – они обеспечивают автоматическое поступление данных и их обработку, а также автопостроение ресурсно-сервисной модели и модели здоровья; 

5. Monq должен отслеживать состояния суммарно 50 млн метрик.

Кстати, если лень читать текст – можно посмотреть видео тут. 

Откуда ноги растут?

Рассказывает Александр Лукиных (отвечает в Х5 Tech за централизованный мониторинг). 

Зачем мы в Х5 вообще решили внедрять систему зонтичного мониторинга? В 2021 году мы провели аудит всего контура мониторинга в компании, который показал результат, наверное, свойственный любому крупному энтерпрайзу: качество данных, процессов и автоматизации было не самым высоким. В частности:

• текущая архитектура мониторинга имела низкую зрелость;

• основной упор был на реактивный мониторинг инфраструктуры в рамках зон ответственности подразделений;

• единые процессы и технические требования мониторинга отсутствовали;

• аварии в ITSM-системе с привязкой к сервисам не регистрировались; 

• устранение типовых и/или потенциально аварийных состояний было недостаточно автоматизированным;

• критические сервисы компании были недостаточно покрыты ИТ-мониторингом.

Чтобы устранить эти проблемы, мы решили внедрять ЕСЗМ – единую систему зонтичного мониторинга (не поверите, но мы выбирали и утверждали это название бОльшую часть проекта). С его помощью мы хотим повысить надежность функционирования компонентов и сервисов, снизить трудозатраты на мониторинг ИТ-сервисов и в результате: 

1. сократить среднее число и продолжительность аварий в месяц; 

2. повысить доступность критичных ИТ-сервисов;

3. сократить среднегодовые потери валового дохода. 

Как это выглядит: взаимосвязь всех элементов ИТ-окружения и пирамида внедрения  

Все данные из ИТ-окружения мы объединяем в две основные сущности: 

1. Ресурсно-сервисную модель (РСМ). В системе всё начинается с конфигурационной единицы (КЕ) – по сути, любого объекта ИТ-окружения. Это может быть касса, коммутатор, маршрутизатор, канал связи, ЦОД и сервис – все эти элементы связаны между собой и взаимно влияют друг на друга. Именно эту взаимосвязь мы называем ресурсно-сервисной моделью, в которой можно учитывать бесконечное количество единиц и связей.

Таким образом, РСМ – это логическая модель сервиса, описывающая состав и взаимосвязи набора Конфигурационных единиц, которые совместно обеспечивают предоставление сервиса на согласованном уровне. Предназначается для хранения информации об объектах и сущностях, включая взаимосвязи ИТ-окружения.

2. Модель здоровья (МЗ). Сама по себе РСМ, если находится в некотором вакууме, никакого значения не имеет. Каждая конфигурационная единица может иметь свой набор метрик, порогов и сигналов, и, когда между КЕ построены связи влияния, через них состояние одних КЕ может оказывать влияние на состояние других – это и есть модель здоровья.

Модель здоровья – математическая модель, описывающая изменения состояния конфигурационной единицы в зависимости от влияющих на неё факторов (Сигналов и КЕ).

В РСМ и модели здоровья мы объединяем три типа систем:

1. системы больше инвентаризационного характера, которые дают информацию для РСМ: несколько open source-решений (NetBox, RackTables и др.) и коммерческих продуктов (например, Microsoft SCOM), а также наши собственные разработки – например, СУИМ (Система управления инфраструктурой магазина);

2. системы мониторинга, которые не содержат никакой инвентарной информации и дают только огромное количество метрик, – их мы потом связываем с ресурсно-сервисной моделью: здесь много различных Zabbix, несколько инсталляций Splunk и др.;

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

Внушительный скоуп систем, из которых мы собираем данные для РСМ и модели здоровья, представлен на схеме:

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

Пирамида состоит из нескольких частей, отражающих последовательность внедрения: 

• Фундамент: так как система не позволяет сразу же начать интегрироваться с внешними источниками данных, в качестве основы нужна разработка архитектурных принципов: как будут выглядеть плагины для интеграции? Как будет дорабатываться API самой системы? и т.д.

• Создание базы: у нас есть ITSM-система от Microfocus, где хранятся наши сервисы и всё, что с ними связано. Поэтому мы построили некоторый «пирог» связи сервисов с различными элементами ИТ-окружения. Например, сервисы могут быть завязаны на виртуальные машины, виртуальные машины завязаны на железные серверы, железные серверы подключены к оборудованию ЦОД, коммутаторам ЦОД. Соответственно, у нас есть есть MFSM, есть Netbox, который мониторит эту сеть через Zabbix, есть VMWare, где хранится информация по виртуальным машинам и метрикам виртуальных машин, и есть Zabbix Core IT, который содержит информацию о непосредственно железном оборудовании. 

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

• Расширение блока мониторинга в систему ЦОД – подключение объектов телефонии, управление базами данных, интеграция с облачной платформой X5 Salt;

• «Обвес»: дальше в планах на подключение – скоуп систем, которые, в отличие от первого слоя, представляющего базу для внедрения, являются некоторым «обвесом» (например, та же система резервного копирования – не самый самый важный элемент в общей инфраструктуре).  

Концепция внедрения и ценность зонтичного мониторинга

Рассказывает Олег Ширнин (отвечает в Х5 Tech за разработку инфраструктурных решений).

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

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

Несколько слов о концепции, которую мы применяем при внедрении зонтика. Возьмем, например, часть ресурсно-сервисной модели, которая построена для одного из самых важных объектов с точки зрения бизнеса компании X5, – это торговый объект, или любой магазин «Пятерочка», «Перекресток» или «Чижик». За исключением некоторых отличий в количестве элементов, в каждом магазине представлена достаточно стандартная ИТ-архитектура. Прежде всего, это объекты, которые относятся именно к базовой ИТ-инфраструктуре: 

• источники бесперебойного питания;

• серверы;

• каналы связи;

• маршрутизаторы;

• коммутаторы;

• торговое оборудование – конечно, здесь речь в первую очередь идёт о кассах.

Вот сокращенная схема того, что представлено с точки зрения инфраструктуры в каждом магазине, – эти элементы являются источниками данных для построения РСМ и модели здоровья:

Важно отметить, что мы не отражаем в системе какие-то непонятные конфигурационные единицы, не имеющие реального понятного осязаемого объекта. Любая конфигурационная единица в ресурсно-сервисной модели – это какой-то объект реального мира. Такие сущности, как, например, Zabbix-агенты, характерные для соответствующих систем, которые занимаются уровнем первичного сбора метрик, конечно, существуют, но в нашей системе конфигурационная единица – это какой-то реальный объект. Он может быть, как физическим (сервера, коммутаторы, маршрутизаторы и др.), так и виртуальным, но являющимся объектом реального мира (виртуальные машины, прикладное программное обеспечение и его экземпляры, базы данных, веб-сайты и т.д).

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

Ресурсно-сервисная модель по торговому объекту строится из систем, о которых мы подробно рассказали выше, – это система NetBox и две системы, которые разработаны внутри компании X5: Store Manager и СУИМ (Система управления инфраструктурой магазина). 

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

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

Вот что в результате можно увидеть на участке карты РСМ (это кусочек модели, к ней сейчас подключено более 1 млн элементов): в центре магазин, а вокруг объекты, которые на него влияют. Это, в сущности, разработанные и заложенные нами правила, определяющие, как конфигурационные единицы связаны между собой: 

Важное дополнение – мы не пытаемся строить РСМ отдельных сервисов. Мы понимаем, что всё ИТ в компании связано друг с другом, тут нет каких-то изолированных кусков инфраструктуры. Сервис – это просто промежуточный слой, на котором работает бизнес-приложение. 

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

Ресурсно-сервисную модель можно также выстраивать в виде графа – здесь мы видим проблемные объекты и как они влияют на магазин (также возможны другие представления актуального состояния, например, в виде диаграммы влияния). Здесь также представлено непроблемное оборудование со своим состоянием. 

Как мы получаем здоровье? На каждый объект мы настроили определённое количество метрик, эти метрики забираются исходными системами с конкретных объектов, дальше они обрабатываются в Monq, где оценивается их значение в применении к настроенным значениям. Дальше генерируется сигнал – событие, которое является входным элементом любого процесса по устранению сбойного события. Вот пример таких сигналов на кассовом узле: 

По сути, сигнал – это сущность, которая генерирует некий сценарий поддержки – мы видим, какие сигналы и когда срабатывали, когда они появились, когда их устранили. Ценность заключается в том, что сигнал не может появляться из воздуха. Важно именно то, что любой сигнал связан с какой-то конфигурационной единицей, и отчёты по сигналам в разрезе КЕ позволяют управлять процессом устранения проблем. Так, мы можем находить наиболее проблемные конфигурационные единицы, на которых чаще других появляются сигналы, структурировать сами сигналы, структурировать объекты по различным категориям и т.д. 

Построение ресурсно-сервисной модели и роль атрибутивного состава

Одна из сложностей проектирования ресурсно-сервисной модели заключается в том, что в первую очередь нам надо определиться с тем, какие элементы мы хотим отразить на ресурсно-сервисной модели. Здесь главное – поймать некую правильную градацию, потому что модель можно строить крайне детальную, можно не очень детальную, а можно совсем недетальную. Проблема с недетальной РСМ в том, что тогда на одну конфигурационную единицу придётся очень много метрик, и будет непонятно, как и какая конфигурационная единица, в физическом мире отличающаяся от другой, влияет на другую. 

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

Чтобы понять, где физически есть проблемы, у нас есть сущность торгового объекта – здесь атрибутивный состав интереснее, и он соотносятся с атрибутами, принятыми в компании для категоризации магазинов. Здесь важно понимать, в каком вообще статусе находится магазин, ведь магазины могут быть открыты-закрыты, авария может происходить в рабочие или нерабочие часы, в различных торговых сетях, регионах и т.д. От этих параметров может влиять сценарий устранения проблемы, поэтому мы включили в модель подробный атрибутивный состав, в том числе полный физический адрес объекта, куда может потребоваться выезд. Для инженера поддержки, когда горит авария, эта информация находится под рукой, не нужно искать её в каких-то специальных справочниках. 

В результате мы видим в системе реальное состояние ИТ в виде графа и в виде диаграмм состояний. Очень удобно, что в  Monq есть возможность посмотреть на состояние компонентов в разрезе времени. Вот пример, как это выглядит: 

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

Надо понимать, что эта магия сама не работает – дальше рассказываем, что надо сделать, чтобы РСМ и модели здоровья в Monq заработали. Поэтому передаю виртуальное слово Александру Петренко, аналитику Monq Digital Lab.

Способы подключения источников данных к Monq и плагины

Несколько слов о том, что такое вообще зонтичный мониторинг (или observability-система, как такой класс решений известен на Западе). Это один инструмент для всего комплекса приложений и инфраструктуры. Он показывает состояние ИТ-окружения в связке с бизнес-сервисами и обеспечивает одно окно наблюдения и быстрое выявление и устранение аварий. Его особенность также в возможности собирать и анализировать любые данные об ИТ-окружении из самых разных источников:

• журналы событий операционных систем, оборудования и приложений;

• логи с разных уровней;

• алерты систем мониторинга;

• метрики с оборудования, прикладного и системного программного обеспечения;

• трейсы и т.д.

Это даёт быстрое обнаружение и устранение проблем в приложениях, инфраструктуре и сервисах. Подробнее об этом мы писали в этой статье. 

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

1. Датасеты – сырые данные из внешних систем, максимально приближенные к первоисточнику, на основе которых впоследствии создаются конфигурационные единицы. 

2. Метрики – значения самых разных показателей с произвольным набором лейблов. Именно по этим лейблам мы впоследствии связываем метрики с конфигурационными единицами.

Это ещё не конфигурационная единица и не сигнал на ней – это сырые данные из источников.

В системе есть несколько способов получить данные в Потоки:

1. Первый и самый простой – подключаемая система сама умеет отправлять данные на точку API, а мы в Потоке только генерируем специальный ключ и отдаём это всё на сторону подключаемой системы.

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

3. Третий – когда плагины для интеграции пишутся под требования заказчика. На этом проекте мы так и делаем – Х5 важно, чтобы наш зонтик сам забирал данные из подключаемых систем и контролировал корректную передачу этих данных. 

Какие действия выполняет плагин? Их шесть: 

1. проверка доступности системы – можно ли подключиться к системе или нет;

2. если подключиться можно, то подключается;

3. запрашивает необходимые данные согласно параметрам из задания;

4. выбрасывает «мусорные» данные, если такие имеются;

5. структурирует данные при необходимости, чтобы в дальнейшем с ними было удобно работать;

6. отправляет данные в систему. 

Разработка плагинов пока на стороне вендора, но скоро это сможет делать любой инженер со знанием .Net. 

Если всё это делает Плагин, тогда возникает справедливый вопрос, зачем нужен Поток? Поток – это сущность, которая по факту определяет:

• какие функции плагинов;

• с какими параметрами;

• на каких агентах;

• с какой частотой будут запускаться;

• а также разграничивает права доступа пользователей к данным из Потока.

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

Все эти параметры настраиваются непосредственно в интерфейсе системы. 

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

По ним очень легко можно отследить проблемы в сборе данных, если такие имеются, и “заалертить”, если что-то вдруг пошло не так. Экран позволяет работать с сырыми данными, которые система получает на вход – так же, как, например, в Splunk или других подобных решениях.

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

Автопостроение ресурсно-сервисной модели

РСМ и МЗ (модель здоровья) в совокупности позволяют в режиме реального времени визуализировать ИТ-ландшафт на всех уровнях: от работы кассовых аппаратов в магазине до системы планирования поставок и взаимодействия с контрагентами. Например, на карте РСМ возможны: 

• Демонстрация состояния магазинов Х5 (регионы, филиалы, форматы сетей): если мы хотим увидеть состояние всех магазинов «Пятёрочка», мы это можем сделать в одной конфигурационной единице; то же самое можно сделать, если хочется посмотреть все магазины «Пятёрочка» в Москве – и т.д.

• Детализация оборудования на каждом объекте: сетевое и серверное оборудование, кассы.

• Отображение каналов связи провайдеров и общий статус по ним: у нас есть информация по операторам связи и по всем связанным с ними событиям, которые происходят в магазине (мы собираем по ним метрики и объединяем в определенные блоки – так, в случае поломки какого-то провайдера мы можем понять, массовая это проблема или локальная).

• Объединение 5000+ сервисов и систем, таких, как продажа товаров на кассе, финансовых отчётов и программ лояльности: в РСМ у нас есть информация по сервисам, системам и их взаимосвязи, например, о продажах на кассе, учёте алкогольной продукции и т.д. Если, допустим, произошёл сбой в ЦОД или из строя выходит главный или сопутствующий сервер, сломается порт на коммутаторе – мы увидим эту связь между собой и влияние этой поломки на сервис, в частности, работает у нас продажа нормально или есть какие-то проблемы. 

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

Для того, чтобы всё заработало, нам потребовались:

1. источник, готовый отдавать все необходимые данные;

2. плагины для сбора информации;

3. метамодель РСМ;

4. алгоритмы построения РСМ;

5. список метрик и порогов для них. 

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

Оптимизировать и ускорить долгий процесс построения РСМ было одной из ключевых задач на проекте, ведь для примера:

• для обработки 100 сообщений требовалось несколько минут;

• для 10 000 сообщений КЕ – несколько часов;

• для 100 000 КЕ – недели.

Мы ускорили построение РСМ с помощью двух решений: 

1. Пакетная обработка сообщений. С этим решением нам помогли коллеги из Monq, реализовав пакетную обработку информации, когда мы получаем сообщение, но обрабатываем его не каждое по отдельности, а сразу пачкой. Тем самым система сильно ускоряется, причём с обработкой не только уже имеющейся, но и новой информации. В результате скорость обработки входящих сообщений  увеличилась от нескольких минут до 20 секунд, а обновление информации для существующих КЕ ускорилось до нескольких минут. 

2. Разделение одного большого универсального сценария на несколько атомарных, каждый из которых выполняет свою функцию:

• создания и обновления КЕ из источника;

• создания синтетической КЕ с «идеальным» набором данных;

• обновления данных в синтетической КЕ;

• построения связей для всех типов КЕ. 

Проще говоря, мы разбили большие и общие сценарии на частности. У нас есть два типа конфигурационных единиц:

• для первого типа мы используем всю информацию из источников;

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

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

Пройдёмся по внутренностям таких сценариев в блоке пакетной обработки (следите за стрелочками): 

• нам приходит массив;

• мы его разбираем;

• верифицируем данные – источники по большей части всегда выдают правильную информацию, но проверить её нужно, чтобы ничего не сломалось;

• сверяем и преобразуем исходную информацию в структуру;

• затем с помощью автоматизации данные разбираются на разные массивы (в одном массиве новая информация, в другом – всё, что нужно обновить).

На картинке ниже – вторая часть того же сценария: 

Тоже идём по стрелкам – это часть, в которой мы создаём конфигурационные единицы. Здесь мы можем увидеть массив, который пришёл с новыми конфигурационными единицами. Далее они трансформируются в нужные нам структуры и передаются дальше в блоки создания в нужном формате. 

А это пример боевого сценария (выглядит страшно, но на самом деле нет):

На входе обычно сортируется и фильтруется информация по потоку, из которого мы получаем данные. Допустим, мы точно знаем, что здесь обрабатывается какой-то тип конфигурационной единицы – в этом случае используется несколько типов событий: одно событие – с информацией о том, что нужно что-то сделать с уже существующими КЕ, второе – если этой информации нет, и системе нужно её заархивировать. Далее из блока фильтрации выходят несколько веток. Мы работаем с разной синхронизацией, одна из них – полная, потому что нам нужно контролировать весь процесс поступления информации в систему. 

В результате на карте РСМ мы можем увидеть состояние влияния – от самых небольших элементов до непосредственно каждых сервисов и магазинов и то, как они могут друг на друга повлиять. Мы очень сильно ускорились с разработкой благодаря такому подходу, а в результате разработали более 150 активных сценариев, обрабатывающих РСМ и метрики. Благодаря им создана «карта цифрового здоровья бизнеса», скорость разработки сценариев снизилась с 7 до 3 рабочих дней, время обработки КЕ сократилось до нескольких минут и выявление ошибок в сценариях РСМ стало быстрее.

Заключение

Ожидайте продолжения истории – мы обязательно вернёмся с результатами по завершению внедрения, а пока несколько советов для тех, кто планирует реализацию подобного проекта. 

Понятно, что при внедрении подобных решений можно столкнуться с целым рядом сложностей, и, чтобы их преодолеть, нужны: 

1. Всесторонняя поддержка руководства, например, CIO или CTO, а лучше обоих. Когда вы пытаетесь объединить огромное количество систем, обязательно будут вскрываться какие-то болезненные места, и команды, отвечающие за их сопровождение, могут тормозить процесс. 

2. Компетенции в архитектуре и ИТ. Команда внедрения должна разбираться во всём ИТ-окружении – от кассового узла до сервера виртуальной машины, wi-fi точки доступа, работы облачной инфраструктуры, чтобы правильно выстроить связи влияния.

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

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

5. Отсутствие иллюзий. Нужно правильно управлять ожиданиями внутри компании, потому что магия здесь рукотворная, и, чтобы всё получилось, нужно приложить определённое количество усилий.