Дебора Камбе, менеджер по маркетингу продуктов компании PagerDuty, рассказывает на портале The New Stack о том, как с помощью пяти практических шагов реализовать сервисную архитектуру, повысить операционную устойчивость, оптимизировать управление инцидентами и усилить ИИ-триаж (использование искусственного интеллекта для сортировки, оценки и приоритизации разных задач или инцидентов).

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

1. Что сломалось?

2. Что от этого зависит?

3. Кто за это отвечает?

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

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

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

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

• Технические сервисы: API, базы данных, системы аутентификации и микросервисы, обеспечивающие работу цифровых операций.

• Бизнес-сервисы: возможности, ориентированные на клиента и построенные на основе технических сервисов.

Короче говоря, технические сервисы показывают, как все работает «под капотом», а бизнес-сервисы показывают, что фактически испытывает клиент.

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

Пять шагов для проектирования сервисной архитектуры

Организации могут предпринять следующие шаги для структурирования своих бизнес- и технических сервисов с помощью четкого архитектурного проекта:

1. Начните с бизнес-сервисов, ориентированных на клиента

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

2. Составьте карту поддерживающих технических сервисов

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

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

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

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

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

3. Четко распределите ответственности

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

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

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

4. Используйте циклы развертывания в качестве ориентира

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

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

5. Соедините операционные данные

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

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

Начните с малого, чтобы добиться постепенных успехов

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

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