Автоматизация инцидент-менеджмента для 10000 инженеров в Т-Банке / Иван Юрченко

Презентация посвящена построению платформы инцидент-менеджмента в Т-Банке, направленной на поддержку большого числа инженеров. В рамках доклада планируется поделиться причинами создания этой системы, а также продемонстрировать конкретные результаты и примеры интерфейсов. Руководитель продукта Иван Юрченко, ранее занимавшийся разработкой высоконагруженных платформ в сферах ИИ и энергетики, представил ключевые определения, необходимые для понимания дальнейшего материала. Важно установить общие понятия, такие как «услуга» — набор действий, приносящих клиенту ценность (например, вход в мобильное приложение), и «инцидент» — незапланированное событие с негативным влиянием на клиента.

В системе используется градация критичности для юнитов (услуг) от 1 до 5, где B+ и Mission Critical считаются наиболее критичными. Аналогичная градация применяется к инцидентам, от белого до чёрного цвета, где чем темнее цвет, тем серьёзнее инцидент. Понимание этой иерархии является основой для дальнейшего обсуждения интеграции инцидент-менеджмента в текущие бизнес-тренды.

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

Жизненный цикл инцидента включает обнаружение (детекцию), своевременное реагирование, подтверждение, устранение, проведение коммуникаций и, наконец, написание постмортема для предотвращения повторения. Год назад отсутствовал инструментарий для автоматического определения среднего времени жизни инцидента. Экспертная оценка от инженеров показывала, что детектирование занимает от 5 до 7 минут, устранение может занимать от 5 минут до полудня в зависимости от сложности. Процесс улучшения работы для предотвращения повторов занимал более недели. В результате оценки было получено среднее время восстановления (MTTR) в размере 830 минут.

Бизнесу важно знать, что клиент получает услуги компании, а если не получает, то важно понимать, когда он их начнет получать.

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

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

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

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

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

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

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

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

В рамках работы с постмортемами была реализована автогенерация документа, который можно использовать для проверки отработки всех экшн-айтемов по инциденту. Добавление этого функционала привело к значительному росту заполняемости постмортемов: для желтых инцидентов этот показатель вырос с условных 1-3% до 39% за несколько месяцев, поскольку процесс стал удобным и быстрым, а аналитика, основанная на этих данных, стала более полной.

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

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

При личных разговорах инженеры часто заявляют: «Фу, ненавижу этот код, сделайте нормальный UI, хочется всё смотреть и видеть».

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

Финальный опрос показал, что пользователи наиболее высоко отметили объединение инструментов. Удовлетворенность пользователей выросла: NPS (Net Promoter Score) перешел из отрицательной зоны (-14 в прошлом году) в положительную сторону. Самая важная метрика, MTTR (Mean Time To Recovery), снизилась более чем в 2 раза. Признается, что это результат комплексной работы, а не только внедрения платформы.

Продолжается движение в сторону искусственного интеллекта. Один из проектов — автоматическое суммирование информации из чатов инцидента и ее преобразование в короткий постмортем. Модель эффективно выделяет причину и время устранения для инцидентов средней и низкой критичности. Второй проект — Log Analysis, где логи с типом 'error' кластеризуются для выявления аномалий и скрытых связей между инцидентами в разных частях бизнеса, вызванными, например, общей проблемой с Kafka.

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

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