Как за минуты понять, каких клиентов и какие SLA затронуло это падение
Система мониторинга фиксирует отказ порта на маршрутизаторе. Чтобы принять решение, оператору связи нужно знать, какие услуги и клиенты затронуты и сколько времени остается до нарушения SLA (соглашения об уровне услуг). Эти сведения распределены по нескольким системам, и их сопоставление вручную занимает время, которое отсчитывается от момента сбоя.
Сообщение мониторинга без контекста
Типичное сообщение системы мониторинга содержит имя устройства и номер интерфейса: на маршрутизаторе отказал 12-й порт. Однако значимость инцидента для бизнеса из сообщения не видна. Сведения об услугах хранятся в OSS (системах поддержки операций), о договорах и клиентах — в BSS (системах поддержки бизнеса) и CRM, об ответственных сотрудниках — в отдельных таблицах. Инженеру смены приходится открывать несколько источников данных и обращаться в смежные подразделения, а срок по SLA тем временем расходуется.
Ту же проблему описывает TM Forum. В отчете IT with intent, основанном на опросе 110 руководителей из 50 стран, фрагментированные данные в OSS и BSS названы главным препятствием для автоматизации и внедрения ИИ. Авторы отмечают, что отрасль переходит от модернизации отдельных систем к интеллектуальному сервисному слою, который объединяет ИТ и сетевые домены. Его можно реализовать средствами ESM-платформы, ниже разбираем сценарий ее работы.
Дерево конфигурационных единиц: от порта до SLA
ESM (Enterprise Service Management, управление корпоративными услугами) позволяет применять подход библиотеки практик ITIL ко всем подразделениям компании. По этому подходу ИТ-отдел оказывает услуги внутри предприятия, и для каждой определены срок и результат: например, четыре часа на решение инцидента. Тот же порядок распространяется на юристов, которые готовят справку в течение двух дней, и на бухгалтерию, которая начисляет зарплату 10-го числа. У оператора связи к внутренним услугам добавляются клиентские, и на них действуют договорные SLA. Реализовать этот подход помогает ESM-платформа.
Чтобы понять влияние упавшего оборудования, в ESM-платформе используется CMDB — база данных конфигурационных единиц (КЕ). КЕ может быть любая сущность, которой управляют: ноутбук, маршрутизатор, услуга целиком, сотрудник. Зависимости между КЕ выстраиваются в дерево связей, где видно, от чего зависит каждый элемент и кто им пользуется. Услуги и клиенты входят в эту иерархию, поэтому от отказавшего порта можно дойти до договора. Насколько точно система отвечает на вопросы о клиентах и SLA, зависит от того, как полно описано соотношение инфраструктуры, услуг и договоров. Эти данные нужно вносить в CMDB и поддерживать в актуальном состоянии.
Рассмотрим условный сценарий, что происходит с событием по 12-му порту маршрутизатора с момента его регистрации:
- Система мониторинга передает событие в ESM-платформу через REST API, и платформа регистрирует инцидент.
- Платформа находит маршрутизатор и порт среди КЕ и определяет, какие услуги работают через этот порт. Таких услуг 17.
- По связям услуг с клиентами платформа определяет затронутых клиентов. Их 11, из них один относится к категории «золотых».
- Для каждого клиента платформа берет условия SLA из договора и сопоставляет их со временем регистрации события. До нарушения соглашения с «золотым» клиентом остается 23 минуты.
- По этим данным оператор определяет приоритет: на узел направляют выездного сотрудника, клиента предупреждают до истечения срока.
Первые четыре шага платформа выполняет по данным CMDB без участия инженера, поэтому на выяснение обстановки уходит несколько минут.
SLA в ESM-платформе настраиваются для отдельного сотрудника, группы или департамента. Отчетность по ним формируется в той же системе и подтверждает выполнение лицензионных требований и обязательств перед абонентами.
Сквозные процессы оператора на одной платформе
Тот же принцип применим к процессу от заказа до активации (Order to Activate). Например, предприятие запрашивает у оператора 50 каналов связи и настройку SD-WAN (программно определяемой глобальной сети). Менеджер вносит данные в CRM. Далее выполняются:
- Проверка технической возможности;
- Проектирование;
- Согласование;
- Строительство или закупка каналов;
- Настройка;
- Передача в OSS;
- Активация;
- Подключение биллинга.
Затем клиента обслуживает служба поддержки. Каждая из этих систем работает штатно, но клиент ожидает канал 47 дней, и нигде не видно, на каком этапе остановился заказ. В то же время, если процесс выстроен на единой платформе, в ней отображаются стадия закупки, ответственный за склад, на котором находится кабель или система хранения данных, и статус задач у полевых сотрудников.
Процессы в таком случае описываются в редакторе бизнес-процессов, блоки и связи между ними размещаются на схеме перетаскиванием. Из любого шага процесса платформа обращается к внешним системам через REST API. Например, при согласовании она запрашивает данные в 1С или проверяет через Zabbix, работает ли сервер, на котором размещена услуга.
Права доступа настраиваются до уровня отдельных полей формы: пользователь без доступа их не видит. Инженер, читатель базы знаний и руководитель работают в одной системе с разным набором данных. ESM-платформа при этом дополняет действующие системы — отказываться от CRM, OSS, BSS и ERP не нужно.
«Клиент оценивает оператора по срокам подключения и времени восстановления услуг, а обе величины зависят от того, насколько согласованно работают внутренние системы компании. Поэтому данные об инфраструктуре, услугах и договорных обязательствах должны храниться в одной системе и обновляться по ходу операционной работы. Операторы, которые выстраивают такой подход сейчас, получают основу для автоматизации операционной работы и дальнейшего применения ИИ», — говорит Андрей Вишняков, директор по бизнес-продуктам компании SimpleOne, корпорация ITG, ITIL 4 Master, ITIL 3 Expert, Practitioner, автор РИТМ.
Внедрение практик сервисного подхода имеет смысл начинать с одного сценария, например с узлов, через которые проходит основная часть клиентских услуг, и расширять модель по мере подключения новых процессов. Накопленные связи используются повторно: на них опираются автоматизация обращений и ИИ-агенты, которым для решений нужны те же сведения об услугах, клиентах и сроках SLA.