Несмотря на то что ITSM появился еще в 80-х годах прошлого столетия, страсти вокруг него не утихают до сих пор. Часто такие дискуссии сводятся к обсуждению конкретных инструментов, к тому, соответствуют ли они очередной версии ITIL. Не менее часто звучат вопросы вроде «А стоит ли вообще реализовывать рекомендации в своей компании?» — ведь в целом ITIL довольно абстрактен и избыточен для любого бизнеса. Для малого и среднего так и вовсе слишком сложен. А крупный может трактовать практики очень вольно. В любом случае стоимость внедрения автоматизаций и практик ITIL высока — цена систем, поддержки и консалтинга может измеряться десятками миллионов рублей. Не забудем усилия для адаптации и обучения сотрудников. При таких порядках «внедрение ради внедрения» слишком неэффективно, а аббревиатуры давно получили маркетинговый оттенок. Давайте вернемся к истокам и вспомним, что ITSM — это подход к организации управления, когда акцент делается не на системах или технологиях, а на услугах, которые эти самые системы оказывают пользователям. Внешним или внутренним клиентам не столь важно. Пользователю не важно, что находится под капотом той или иной системы, если услуга, то есть совокупность операций, осуществляемых клиентом, системой, операторами или кем-то еще, скрытым за фасадом, оказана качественно. В теории, рассмотрим одну крайность: внутри банкомата может сидеть человек и выполнять все операции вручную, как кассир в 90-х, но какая разница пользователю, если деньги на счет зачисляются менее чем за минуту? Другая крайность — представим себе конвертерный цех с множеством агрегатов. Услуга, которую предоставляет этот цех бизнесу, металлургическому комбинату, — выплавка стали. Если же посмотреть на цех локально, то каждый агрегат внутри также оказывает определенную услугу — доставка ли сырья, кислорода, нагрев конвертера и так далее. Само понимание каждого такого процесса как услуги открывает возможности описания качества в форматах SLA/SLO или любом другом, его отслеживания, выращивания метрик качества и т. д. Таким образом, изначально рожденная для управления ИТ-сервисами концепция может быть применена для любой корпоративной функции. И это мы уже видим, например, в отчетах Gartner и в системах, поставляемых крупными вендорами, — расширение инструментов за пределы ИТ и переход в концепцию ESM — Enterprise Service Management. А что в Т? Для начала необходимо понять что же такое Т. Это большая экосистема цифровых сервисов, обслуживающая более 50 млн клиентов. Сервисы эти включают финансы (банкинг, страхование, инвестиции), телеком, образование, лайфстайл (путешествия, доставка, маркетплейс) и другие. Внутри это более трех тысяч команд и десятки тысяч сотрудников, выполняющих те или иные задачи, от разработки ПО до логистики, HR и других функций. И непременные требования для всех — быть качественными. Качество в нашем понимании состоит из надежности и доступности сервисов, скорости их работы и постоянного развития — улучшения, а еще эффективности. Внедряем ITSM: а вам оно точно надо? Каждая продуктовая команда для каждого такого требования выбирает показатели, отслеживает их, работает над улучшением собственных продуктов. Надо сказать, что каждая такая команда имеет высокую степень самостоятельности — для любого продукта формируется PnL, бюджет и планы. Все это создается внутри продукта, а не спускается сверху. Благодаря такой структуре команда может развиваться очень быстро, поскольку принципиально у продуктов нет ограничений. Возможен любой полет фантазий, тестирования гипотез, движения продукта в ту или иную сторону — какую решит продукт сам. Для облегчения общих задач, например, построения инфраструктуры, у нас принят и широко распространен платформенный подход. Платформа с нашей точки зрения — это сущность, объединяющая данные, инструменты и экспертизу, которая может быть переиспользована в самых разных сценариях. И которой все остальные команды и продукты могут пользоваться как сервисом в режиме самообслуживания. Таким образом мы предоставляем, например, внутри S3-as-a-Service, Kafka-as-a-Service, DBaaS, LBaaS и много других -aaS, к которым легко подключиться. При этом сами по себе такие платформы тоже являются услугами со своими метриками качества и развития. Получается такая схема. Продукт «Вклад» предоставляет клиентам услуги «Открытие вклада», «Закрытие вклада», «Добавление валюты на вклад» и т. д. При этом сам состоит из определенных сотрудников, ИТ-систем и является потребителем услуг «запуск приложений в k8s-runtime», DBaaS. При этом DBaaS оказывает услуги хранения данных с определенными SLA и в свою очередь зависит от продуктов команд виртуальной инфраструктуры и управления сетью. И так далее. Каждый элемент является сервисом, содержит параметры качества и, кстати, стоимости. Все это здорово работает (на самом деле да!). Но это «здорово» невозможно без двух очень важных решений, в концепции ITSM лежащих в областях управления инцидентами, проблемами, изменениями. Наблюдаемость Ситуация, когда в инфраструктуре используются сотни и тысячи информационных систем, типична для любой крупной компании. Они множественно связаны между собой, то есть количество взаимодействий многократно больше. Подливают масла в огонь гибридные среды, микросервисы, разобраться в работе которых очень сложно, не говоря уже о понимании их влияния на конечного клиента. И это мы говорим только об ИТ-составляющей, а сколько было ситуаций, когда ИТ-системы работают корректно, точнее так, как они запрограммированы, но из-за ошибок в бизнес-логике клиенты не получают ожидаемую ценность, а бизнес теряет деньги. Это не такой уж и редкий случай. Как российскому бизнесу адаптироваться к трансформации и перестройке сферы ITSM В 2012 году крупнейший глобальный маркет-мейкер Knight Capital Group за 45 минут из-за проблем с логикой выполнения ордеров потерял $460 млн и обанкротился. Поэтому принципиально важным мы считаем понимание того, что происходит — наблюдаемости в масштабах всей компании и на всех слоях «пирога», начиная от уровня инфраструктуры, сети и серверов и заканчивая бизнес-процессами и транзакциями клиентов. Для решения этой задачи мы разработали и внедрили платформу наблюдаемости и операционной аналитики Sage Observability (рис.1). Она собирает самую детальную информацию обо всем происходящем — телеметрию, цифровые следы. И дает возможность отслеживать любые показатели и связывать бизнес-метрики с работой приложений, оборудования, рассчитывать себестоимость услуг и т. д. Приведу простой, надо сказать, несколько надуманный, но пример. Существует сервис продажи авиабилетов. Пользовательский путь включает поиск билетов, выбор предложения, заполнения данных пассажиров, бронирование и собственно оплату. Заполнение данных — один из самых неудобных для пользователя этапов, поскольку нужно найти документы, аккуратно списать серию, номер. Мы облегчаем этот этап автозаполнением тех данных, что у нас есть, чтобы клиенту оставалось только кликнуть «далее». В результате изменений авторизация во время запроса данных не отрабатывала корректно, но система хранения не отдавала ошибку, а корректно отвечала на запрос «данные отсутствуют». В результате конверсия на этапе CJM сильно просела, и если бы не сквозная наблюдаемость и Sage, мы бы увидели бы проблему лишь спустя несколько дней и потратили много нервов и денег на исправление. В целом Sage Observability позволяет анализировать и сообщать о проблемах в любых процессах. Вот как мы рассчитываем, например, продолжительность процесса, визуализируем его и настраиваем уведомления, если его течение выходит за рамки целевых показателей. Несложный скрипт, который способен написать аналитик, знакомый с SQL, но именно данный запрос был реализован с помощью ИИ-ассистента Nestor, которому достаточно сказать: «Рассчитай продолжительность операции, начинающейся с сообщения enter и заканчивающийся сообщением exit». Далее ассистент изучает контекст данных и пишет код. Остается в два клика настроить алерт — уведомление, что что-то пошло не так. Sage Observability Инциденты и здоровье Выявление инцидента, конечно, лишь начало пути. Необходимо быстро найти причину, определить команду, которая должна заниматься починкой и устранением проблемы (вспомним про множество сервисов, команд и связей), а еще устранить последствия инцидента для пользователей, ведь любой сбой может повлечь не только недополученную прибыль, но и риски штрафов, снижение лояльности клиентов. Иными словами, действовать надо быстро и слаженно. Для этого мы создали и внедрили FineDog. Да-да, это про ту собачку, что сидит посреди пожара и говорит: "It's fine!" В центре продукта — каталог юнитов. Древовидная структура, где юнит может быть произвольным объектом или сервисом, если к нему можно определить метрики качества, а также критичность для всей компании. Мы развиваем концепцию SRE в компании и применяем соответствующую терминологию. Для каждого юнита можно установить набор индикаторов SLI, отслеживающих качество работы. Целевой показатель здоровья сервиса — SLO. Само дерево может строиться произвольным образом — у нас оно повторяет организационную структуру, но главное в каталоге — связи влияния юнитов друг на друга (Рис.2). Таким образом можно мгновенно понять, по чьей вине произошла просадка той или иной метрики и кто должен заниматься устранением. Связи влияния можно создать вручную, но большую ценность дает автоматическое связывание благодаря возможности в Sage отслеживать маршруты запросов (трассировка) — с ее помощью топология строится автоматически. Карта влияния сервисов За каждым юнитом закреплена команда, в которой есть инженеры, в том числе дежурные — в системе есть календарь дежурств, других ответственных вплоть до руководителей направления. И программа эскалации (рис.3), если инцидент не удается разрешить быстро и устранить влияние. Программа эскалации Кроме календаря дежурств в FineDog есть планировщик изменений — релизов, плановых работ по обслуживанию систем и других событий, которые могут повлиять на качество предоставления сервисов.