Современный on-call менеджмент: 5 основных шагов от мониторинга до постмортема

Управление инцидентами — это порой ночной кошмар любого ИТ-директора. Поднимите руку те, у кого не было ночных сообщений, что упал критический сервис! Почему так мало рук? Да потому что этот самый процесс в большинстве компаний устроен криво. Каждый раз его придумывают заново, проходя путь от ручного режима, далее общей почты или телеграмм группы до самописной системы управления инцидентами. И чем позже мы приходим в компанию выправлять процесс, тем больше сопротивления и непонимания “А что так можно было?”.

Помню, как 8 лет назад я руководил сервисной службой в компании, которая предоставляла услуги поддержки важной внутренней системы крупного клиента. Однажды ночью, примерно в три часа, мой телефон разрывается от звонка. На экране — заказчик. Не успеваю сказать «алло», как слышу: «Вы там спите что ли? У нас АСУ ПОБСУ лежит! Вы в курсе почему? (Я молчу) Мы больше не будем с вами работать!» — и бросает трубку.

Сон как рукой сняло. Адреналин зашкаливал. Я срочно набрал техлиду и мы помчались в офис. Наш ночной инженер сидел перед монитором, глаза квадратные. Спрашиваю: «Что случилось?» Он растерянно отвечает: «Ничего, всё зелёное, никаких проблем». Я решил проверить. Пытаюсь авторизоваться — получаю ошибку. Начинаем детально анализировать ситуацию.

Выяснилось, что после вчерашнего обновления системы, которое провели в нерабочее время ближе к 12 ночи, отвалилась внешняя авторизация. Проверки, которые провели инженеры разработчика были выполнены на внутренних учетках. Они спокойно закрыли релиз и сервисные работы, а мы продолжали смотреть на зеленые экраны Zabbix. При этом в почту первой линии, которая работала с 9 до 18 начали падать письма от сотрудников, что система не работает. Мониторинга пользовательского опыта, конечно же, не было. И что самое интересное, в почту пришел алерт от смежной команды другого подрядчика, отвечающей за инциденты на AD, который сообщал, что наша система не отвечает. Но он затерялся в почте.

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

По сути, он стал самым дорогим тестировщиком в моей практике. Этот случай многому нас научил:

Всегда нужен бизнес-мониторинг приложений со стороны пользователей: тогда мы построили систему проверок Selenium+Jenkins+Zabbix, начали отслеживать реальные пользовательские сценарии, настроили синтетические транзакции для имитации действий пользователей.
Все алерты одинаково полезные до обработки: то что мы не увидели алерт от коллег, это был провал, нужно все алерты складывать в одну систему и обеспечивать их проверку и определение критичности и влияния.
Нужен четкий процесс on-call менеджмента: разработали график дежурств не только на месте в офисе, но и матрицу эскалации.Затем подрубили виртуальную АТС, которая перебирала телефоны вплоть до гендира, если не отвечают на нижестоящем уровне.

После этого инцидента мы полностью переработали подход к мониторингу и управлению инцидентами. В то время у многих не было опыта, не было нормальных, инструментов, ни Monq, ни Grafana OnCall, ни OpsGenie, ни PagerDuty, а IBM NetCool был нам не по карману. Сейчас 2024 год, и в чем-то условия даже похожи, но есть накопленный опыт и проверенные отечественные решения. Не надо выдумывать велосипед.

Что такое on-call менеджмент и почему он необходим

On-call менеджмент — это организация процесса дежурств и управления инцидентами, обеспечивающая круглосуточную готовность команды к реагированию на проблемы в ИТ-инфраструктуре, сокращающая время простоя бизнес-сервисов. В современном мире, где бизнес зависит от непрерывной работы ИТ-систем, on-call менеджмент становится неотъемлемой частью стратегии управления непрерывностью бизнеса.

Представьте, что ваша ИТ-инфраструктура — это живой организм. Когда в нём происходит «болезнь» или сбой, необходимо немедленное вмешательство «врача» — инженера, который быстро диагностирует и устранит проблему. On-call менеджмент — это система, которая гарантирует, что такой «врач» всегда на связи и готов действовать.

С развитием технологий искусственного интеллекта и больших языковых моделей (LLM), таких как GPT-4, on-call менеджмент выходит на новый уровень. ИИ способен анализировать огромные объёмы данных, прогнозировать потенциальные инциденты и даже предлагать решения в реальном времени. Это открывает новые возможности для повышения эффективности и снижения нагрузки на команды. Пожалуй, среди всех процессов около эксплуатации, on-call менеджмент, наряду с обработкой входящих запросов пользователей, — два наиболее благотворных направления использования ИИ.

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

Наш путь к on-call менеджменту

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

Первым прототипом промышленной системы управления событиями и инцидентами была связка Zabbix+Asterix+Redmine. Алерты из Zabbix летели в общую почту, управление корреляцией и дедупликацией было организовано на папках и правилах, критические алерты отправлялись через самописную утилиту, где был настроен график дежурств и матрица эскалации в Asterix, который звонил дежурному, ему наговаривал автоинформатор, что он должен срочно посмотреть в Redmine и принять на себя обработку критического инцидента. Когда он нажимал соответствующую цифру на него переводилась задача. Нам это позволило отказаться от ночных дежурных, сократить затраты и обеспечить более надежное оповещение. Но управлять процессом было очень сложно, решение было негибким и сложным в развитии.

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

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

Что такое Монк и место on-call в нем

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

Ключевые возможности Monq:

Зонтичный мониторинг: Monq способен собирать и агрегировать данные из различных локальных систем мониторинга, таких как Zabbix, Prometheus и другие. Это позволяет получить целостное представление о состоянии инфраструктуры без необходимости замены уже внедрённых решений.
Централизованный мониторинг: Система может быть развёрнута как основное решение для мониторинга, обеспечивая полный контроль над ИТ-инфраструктурой без использования западных on-premises систем или сложных в поддержке open-source продуктов.
Ресурсно-сервисная модель: Monq предоставляет возможность моделирования и визуализации зависимостей между ИТ-ресурсами и бизнес-сервисами, что облегчает понимание влияния технических проблем на бизнес-процессы и приоритизацию задач.
Гибкая интеграция: Система открыта для интеграции с различными инструментами и технологиями, что позволяет адаптировать её под специфические потребности организации и обеспечить совместимость с существующей ИТ-средой.
Автоматизация и оркестрация: Monq поддерживает создание сценариев автоматического реагирования на инциденты, используя свой собственный no-code и low-code движки, позволяя ускорить процесс восстановления сервисов и снизить нагрузку на ИТ-персонал.
Соответствие мировым практикам: Внедряя современные подходы DevOps и SRE, Monq обеспечивает высокий уровень надежности и доступности сервисов, соответствуя передовым мировым стандартам в области мониторинга и управления инцидентами.

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

Процессы превыше всего

Корпоративный программный продукт — это прежде всего не функционал, а процессы. Наш бесплатный On-Call модуль вшит в большой Monq, в базе зашит следующий процесс (с возможностью кастомизации):

Предиктивный мониторинг

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

Сбор событий с систем мониторинга: объединение различных инструментов мониторинга в единую платформу позволяет получить полный обзор состояния окружения. Собираем метрики, логи, алерты и другие данные из разных источников для комплексного анализа. Это обеспечивает своевременное обнаружение инцидентов и сокращение времени реакции. Многие технологические гиганты, такие как Яндекс, Netflix и Amazon, успешно используют подобные подходы для управления своими масштабными системами.

Автоматизация уведомлений и эскалации

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

Централизация алертов: все алерты из различных систем мониторинга, анализа логов и пользовательских запросов должны поступать в единую систему управления инцидентами. Это обеспечивает полную видимость состояния системы и упрощает обработку событий. Например, интеграция с такими инструментами, как Prometheus, Пульт, Инити, ELK Stack и Zabbix, позволяет собрать всю информацию в одном месте, что существенно ускоряет диагностику проблем.

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

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

Автоматизированное реагирование и восстановление

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

ИИ-ассистенты помогают инженерам, предоставляя рекомендации по решению инцидентов на основе исторических данных и базы знаний. Компании, такие как IBM с их Watson AIOps, демонстрируют эффективность использования ИИ в ускорении процесса принятия решений. Сейчас мы в Monq запускаем в тестовую эксплуатацию коннектор с обученной моделью GigaChat от Сбера, о кейсе использования рассказывали в недавней статье.

Управление инцидентами и коммуникация

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

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

В Monq мы реализовали возможность создавать любые процессы ChatOps с помощью сценариев автоматизации в Telegram, Microsoft Teams и других мессенджерах. Наши интеграции позволяют настроить ботов, которые не только уведомляют о новых инцидентах, но и позволяют командам взаимодействовать с системой управления инцидентами непосредственно из чата. Это обеспечивает полный цикл управления инцидентами в привычной и удобной среде для вашей команды.

Постинцидентный анализ и непрерывное улучшение

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

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

Многие широко практикуют blameless postmortems — анализ инцидентов без поиска виноватых, что способствует открытой коммуникации и улучшению процессов.

Как писать хороший постмортем

Классические компоненты постмортема:

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

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

В качестве примера причин предлагаю вспомнить одну из крупнейших аварий в ядерной энергетике на станции Фукусима-1 после землетрясения и цунами 11 марта 2011 года. Анализ причин мог бы быть таким:

Почему произошла авария на Фукусима-1?
Станция потеряла электропитание, по причине затопления резервных дизельных генераторов из-за цунами, что привело к отказу систем охлаждения реакторов.
Почему генераторы оказались затоплены?
Защитные сооружения станции были рассчитаны на цунами до 5-7 метров, тогда как высота фактической волны превысила 14 метров. Конструкции не были предусмотрены для таких экстремальных природных явлений.
Почему системы охлаждения отказали?
Полная потеря электроэнергии (Station Blackout) привела к остановке насосов охлаждения реакторов. Резервные генераторы не смогли поддерживать работу систем из-за затопления.
Почему персонал не предотвратил катастрофу?
Персонал действовал строго по инструкциям, но не обладал глубоким пониманием физических процессов. Инструкции не предусматривали подобный сценарий, и принятие нестандартных решений было затруднено.
Почему станции не были готовы к таким событиям?
Проект станции не учитывал одновременное воздействие столь мощного землетрясения и цунами. Безопасность была рассчитана на меньшие риски, что стало ключевым фактором аварии.

Почему важно не искать виноватых, а фокусироваться на причинах

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

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

Исследования также подтверждают эффективность blameless подхода. В статье «Psychological Safety and Learning Behavior in Work Teams» (Amy Edmondson, 1999) показано, что команды с высокой психологической безопасностью более эффективно решают сложные задачи и быстрее адаптируются к изменениям.

Заключение

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

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

Мы прошли долгий путь от самописных решений до создания платформы Monq, интегрирующей лучшие мировые практики on-call менеджмента. Теперь мы готовы поделиться нашими наработками с вами. Приглашаем вас присоединиться к программе раннего доступа и протестировать наш бесплатный облачный сервис Monq On-Call и зарегистрироваться на ранний доступ. Если облако это не про вашу организацию — есть возможность поставить комьюнити OnPrem-версию большого Monq.

За новостями продукта следите на нашем канале https://t.me/monq_dev.

ссылка на оригинал статьи https://habr.com/ru/articles/859446/