Привет, Хабр! На связи Дарья Попова, тимлид группы мониторинга в Купере. Наша миссия — минимизировать потери от инцидентов для компании и обеспечить сервис на 10/10 для клиентов. Почему это именно группа — вы поймете дальше. Сегодня я расскажу, как мы выстраивали процессы и инструменты мониторинга и автоматизации — и как это все упростило нам жизнь.
В Купере есть отдел мониторинга. Внутри — 4 подразделения:
Группа управления инцидентами и проблемами. 4 инцидент-менеджера, которые разделены по доменам Купер.теха. Они считают финансовые потери от инцидентов, проводят постмортемы и контролируют выполнение action items по итогам постмортемов.
Группа поддержки инфраструктуры. 3 инженера IТ-инфраструктуры. В их обязанности входят решение и (по возможности) эскалация заявок от внутренних пользователей.
Группа разработки внутренних автоматизаций. 2 сотрудника. Они автоматизируют рутинные операции и создают инструменты как для отдела мониторинга, так и для компании в целом.
Группа мониторинга. Это мы! 10 инженеров мониторинга круглосуточно обрабатывают алерты (более 2 000 за день), мониторят более 1 700 микросервисов, занимаются первичной диагностикой аномалий, управляют всеми IT-инцидентами Купера и контролируют проведение нагрузочного тестирования.
Наша группа работает только с массовыми инцидентами. Единичные обращения берет на себя либо контактный центр, либо продуктовая поддержка. И только в случае большого количества обращений с одинаковым диагнозом коллеги приходят к нам.
По сути, мы выступаем аналогом третьей линии. Аналогом — потому что самостоятельно мы устраняем только базовые аномалии. При крупных поломках инженеры мониторинга просто знают, кого позвать.
Почему так? Потому что иначе все плохо!
До того, как устаканилась эта структура, мы жили как Сизиф, который изнывал в попытках поднять на гору огромный камень.
Во-первых, у нас не было процессов по регистрации и разбору инцидентов — мы плыли по течению. Только создание команд мониторинга и инцидент-менеджеров помогло нам начать грамотно учитывать инциденты и извлекать из них уроки.
Во-вторых, миллионы алертов по всем сервисам летели напрямую в разработчиков. Нагрузка — огромная! Разрабам приходилось и днем и ночью подключаться к анализу аномалий, на которые сработали алерты. Сейчас отработка алертов возложена на инженеров мониторинга, и разработка подключается только в случае подтвержденного влияния.
Группа мониторинга: люди и боты
Клиенты по всей России пользуются Купером в любое время суток, и сервис нужно поддерживать 24/7. Поэтому мы сразу решили, что инженеры мониторинга должны работать посменно. Но давать сотрудникам ночные смены мы не хотели — не самая здоровая практика.
Решение? Follow the Sun. Но битлы ни при чем. Мы придумали искать инженеров и на Дальнем Востоке, и в московском часовом поясе. Благодаря большой разнице во времени все работают в течение светового дня, а мы обеспечиваем мониторинг по всей России. Как говорится, от Камчатки до Калининграда!
Кроме сменных инженеров, есть те, кто работает в стандартном графике 5/2. Они выявляют слабые места, улучшают процессы и инструменты и в пиковые часы нагрузки приходят на помощь к сменникам.
По каким критериям выбирали инженеров мониторинга?
Технический бэкграунд. Ежу понятно: спец должен знать системы мониторинга и понимать принципы, на которых строится IT-инфраструктура.
Процессный бэкграунд. Хотите знать, как и для чего управлять инцидентами? Как их приоритизировать? Как фасилитировать звонки? Спросите у наших инженеров мониторинга! Они точно знают.
Когнитивные навыки. Далеко не уедешь без логики, умения задавать вопросы и сохранять холодный рассудок в стрессовой ситуации.
Скажу без ложной скромности, мы придумали классный план, как собрать команду, и реализовали его. Но человеческого ресурса тут недостаточно.
По мере роста сервиса растет и количество инцидентов. В какой-то момент инженеры мониторинга стали тратить непозволительно много времени на рутинные операции, переключение между окнами и вызовы дежурных.
Так в чат вошел Jarvis Bot, который создали супергерои из нашей группы разработки. Он забрал на себя львиную долю работы инженеров мониторинга:
инструменты детекта инцидентов
передачу смены
управление знаниями в команде
практически все шаги жизненного цикла инцидента
Запомните это благородное имя, я буду его упоминать.
А теперь — к важным деталям организации процессов.
Как мы узнаем об инцидентах
Первый путь — SLO Health-check критичных сервисов.
Конечно, у нас есть настроенные алерты по просадке SLO, но они работают именно на снижение показателя. На широкий период SLO настроить сложнее, поэтому мы пришли к следующему решению.
Jarvis Bot автоматически запускает проверку 12 раз в сутки. Бот переходит на дашборд с графиком SLO, делает скрин графика за последние 2 часа и отправляет эту картинку в тред Health-check. Дальше в игру вступает инженер мониторинга: анализирует скрины, выявляет аномалии и, если нужно, призывает ответственную команду.
Второе — собственно алертинг.
Мы собственноручно разработали дашборд, где алерты удобно фильтровать по статусу и длительности. При получении алерта инженер мониторинга анализирует его и выполняет действия, описанные в Runbook (расскажу в следующем разделе!).
Все критичные алерты роутятся в нашу команду, но мы не настраиваем алертинг самостоятельно. Это зона ответственности разработчиков, которые отвечают за сервисы, и DevOps-специалистов. Тем не менее у нас есть список требований к алертам, которые приходят к нам на мониторинг:
Summary & Description. Короткий заголовок, из которого ясна суть аномалии, а также более подробное описание с уточнением деталей.
Tier & Severity. В алерте должна быть указана критичность сервиса, критичность самого алерта и приоритет алерта — чтобы понимать, насколько важная аномалия случилась.
Ссылки на дашборд и график команды. Из алерта должно быть легко перейти на график метрики, по которой сработал триггер, и на график дежурств ответственной команды.
Ссылка на Runbook.
Так выглядит алерт, который соответствует требованиям:
Все, что вы хотели знать о Runbook, но боялись спросить
Runbook — это документ, где собрана вся информация о работе с алертом.
Первый блок — ответственная за алерт команда. Кто будет выполнять действия, описанные в Runbook? Какие права и доступы нужны для выполнения этих действий?
Второй блок — описание аномалии. Из-за чего сработал алерт? Каковы последствия срабатывания алерта? Каковы способы диагностики и определения массовости влияния?
Третий блок — действия. Какие действия нужно предпринять для устранения алерта? Это могут быть действия со стороны как команды-оунера, так и инженеров мониторинга.
Четвертый блок — стабилизация. Как мы поймем, что аномалии больше нет? Также здесь указывается любая дополнительная информация: график дежурств, подробное описание сервиса и ссылки, которые команда посчитает полезными.
Команда мониторинга является оунером сервиса Runbook. Мы валидируем новые документы по алертам. Как это происходит?
Ответственная за сервис команда пишет Runbook по алерту, формирует Merge Request (MR), который приходит на аппрув в нашу команду. Далее инженер мониторинга проверяет Runbook на соответствие всем нашим требованиям. Если данных недостаточно, мы пишем прямо в MR, что нужно исправить. Runbook вида «Позвони дежурному» мы не аппрувим принципиально! Такие алерты должны не приходить к нам на мониторинг, а сразу лететь к разработчикам и самостоятельно призывать их.
Обнаружили инцидент. Что дальше?
Шаг первый — регистрация инцидента в специально отведенном Jira-проекте. Регистрация происходит из треда Mattermost посредством отправки команды для нашего бота Jarvis.
У нас есть несколько типов инцидентов:
условно классический инцидент
инцидент безопасности
инцидент нагрузочного тестирования
Для каждого типа инцидентов у бота есть отдельная команда. В момент регистрации инцидента он генерирует ссылку на комнату в сервисе видеосвязи, где будет проходить звонок по устранению. URL ссылки всегда заканчивается номером инцидента, чтобы избежать путаницы.
Первичные поля для инцидента мы заполняем в Playbook Mattermost. Он запускается автоматически после регистрации инцидента из треда. Чтобы использовать Playbook, переходим в отдельный канал и делаем себя его участником. Дальше заполняем первичные поля, и они прокидываются в карточку инцидента в Jira. После наш инцидент автоматически переходит из статуса «Открыт» в статус «В процессе».
Шаг второй — первичный анализ. Здесь мы выявляем страдающий функционал и определяем ответственную команду. Далее определяем приоритет инцидента на основании двух параметров: критичности и массовости.
Для оценки критичности у нас есть четыре уровня: блокирующий, высокий, нормальный и низкий. Что определить уровень, отвечаем на эти вопросы:
На кого влияет инцидент? (Клиенты, партнеры, сотрудники)
Есть ли финансовые потери по инциденту? (Текущие или отложенные)
Инцидент влияет на критичные бизнес-процессы сотрудников?
Для оценки массовости тоже используем четыре уровня: до 10%, до 30%, до 50% и свыше 50%. Мы определяем массовость по доле пользователей конкретной функции или услуги, на которую влияет инцидент.
Все инциденты отправляем на Status Page. Это наша разработка. Из нее можно отфильтровать инциденты по статусу и приоритету, а также посмотреть название и минимальные детали. Чтобы узнать больше, надо провалиться в инцидент по кнопке «Посмотреть детали». Там находим ссылки на тред по инциденту, ссылку на звонок, где происходит устранение, массовость, причину и всю хронологию этого инцидента.
Чем измеряем успех первичного анализа?
Метрика №1. Время начала фактического устранения инцидента. Наше целевое значение составляет 10 минут: 5 минут на первичную диагностику и поиск ответственных, 3 минуты на поиск дежурного и 2 минуты на подключение дежурного.
Команда мониторинга отвечает за первую часть метрики. Чем быстрее мы проведем первичный анализ и поймем, кто отвечает за деградирующий функционал, тем скорее начнут чинить.
Метрика №2. Время установки приоритета. Целевое значение — 4 минуты. Опять же: чем быстрее мы установим приоритет, тем быстрее начнем призывать ответственных. Это особенно важно, когда мы решаем острый вопрос в нерабочее время, чтобы зря не звать спецов или, наоборот, не откладывать решение. Первичное оповещение инцидента также завязано на скорость выставления приоритета: чем быстрее мы оповестим коллег, тем меньше вопросов получим от них в чатах.
Посмотрите на скрины ниже. В этом году мы держим время начала устранения инцидента в рамках 7 минут.
Как мы этого добились?
Прежде всего — призыв дежурного для устранения. Инженеры мониторинга эскалируют инциденты в зависимости от приоритета: высокоприоритетные инциденты мы устраняем в любое время суток, а вот низкоприоритетные — только в рабочие часы.
Призыв дежурного у нас осуществляется через команду для Jarvis-бота. Можно призвать конкретного пользователя или дежурного от конкретной команды.
В обоих случаях наш помощник Jarvis формирует алерт в Grafana OnCall. Далее сотрудник получает уведомление: сообщение в Telegram, звонок или SMS. Зависит от индивидуальных настроек профиля — кому как удобно! Дополнительно наш бот тегает призванного дежурного в тред инцидента, чтобы он быстро нашел нужное обсуждение. Подтвердить алерт от бота можно прямо из треда Mattermost.
Еще одна классная фича Jarvis. Если мы призываем дежурного от конкретной команды, бот идет в расписание дежурств команды, находит дежурного, направляет его ФИО в тред и формирует на него алерт.
Аналогично призываем дежурных инцидент-менеджеров в нерабочее время, если нужна дополнительная координация для устранения инцидента.
А что, если никто не реагирует на призыв? На этот случай у нас реализована эскалация на руководителя. Если дежурный не подключается к решению инцидента или подключается без подтверждения алерта, бот формирует тег на руководителя этого дежурного и кидает клич: «Смотри, у тебя ребята не подключаются к инцидентам».
Как бот находит руководителя дежурного? Идет на корпоративный портал и определяет его по email. Если руководитель в отпуске или тоже не реагирует на призывы, эскалация идет дальше на руководителя +1. Мы настроили для бота исключение, до CTO он эскалировать не будет.
Вызываем команду по спасению мира
У нас есть киллер-фича, которой мы особенно гордимся. Это призыв команды по спасению мира, куда входят дежурные SRE, руководящий состав Купера и дежурные от наиболее популярных команд. Бот использует эту фичу, только если зарегистрирован инцидент с высочайшим приоритетом.
Как мы определили топ команд? Взяли критические сервисы, определили ответственных, посмотрели, кого чаще призываем на решение высокоприоритетных инцидентов, и все эти команды закинули в автоматику для Jarvis. Когда бот нажимает «красную кнопку», тот звонит во все выбранные команды одновременно. Команду по спасению мира можно призывать и при первичной установке критического приоритета, и в случае повышения приоритета.
Как определяем, что надо призвать команду? При установке критичного приоритета бот спрашивает у инженера мониторинга, ответственного за инцидент: «Зовем команду по спасению мира?» Реализовали на случай, если все нужные люди уже решают инцидент и дополнительные звонки не нужны. Кстати, здесь тоже работает эскалация на руководителя, если дежурный не подключается. Мало ли что!
Апдейты в каждый дом
Отдельно расскажу про оповещения и апдейты по инцидентам. Мы уведомляем коллег в Mattermost и закрытом Telegram-канале. По опыту — в Telegram удобнее. Можно следить за ходом решения, не подключаясь непосредственно к решению. При регистрации инцидента бот генерирует форму оповещения, куда записывает значение из ранее заполненных полей, и отправляет форму в Telegram-канал. Выглядит это так:
Также у нас есть апдейты по ходу решения, которые транслируются в тред инцидента в Telegram-канале. Чтобы дать апдейт, нужно ввести команду для Jarvis-бота, после чего откроется форма с полями для апдейта. В этой форме вводим текущий статус инцидента, предполагаемую причину, массовость и предполагаемое время восстановления.
Важная штука: один апдейт нельзя предоставить дважды. Для низкоприоритетных инцидентов апдейт можно перенести на следующий рабочий день. Также у нас есть время до следующего апдейта, и оно зависит от фактора возникновения инцидента.
Что, если инженер мониторинга забудет предоставить апдейт? Мы позаботились об этом и реализовали напоминалку: каждые 15–30 минут бот тегает ответственного за инцидент инженера мониторинга и напоминает, что пора дать апдейт. Если апдейта нет в течение 10 минут после напоминания, Jarvis тегает старших инженеров для контроля.
Все предоставляемые апдейты транслируются в поле «Хронология» в Jira. Описывать хронологию — самый тягомотный и затратный процесс в заполнении карточки. Поэтому наш бот сам записывает апдейты с указанием даты и времени. Когда инцидент устранен, инженеру мониторинга остается только причесать эту хронологию.
Чем измеряем успех этапа оповещения?
Метрика №1. Время установки компонента. Целевое значение 15 минут. Под компонентом мы понимаем не сервис, который деградирует, а именно бизнес-функцию, на которую идет влияние. Например, у нас инфраструктурные проблемы, из-за которых не работает телефония в контактном центре. В таком случае — компонентом инцидента будет телефония.
Метрика №2. Предоставление апдейтов по ходу решения инцидентов. Целевое значение 15–30 минут. Почему такой разброс? Мы делим инциденты на два фактора возникновения:
внутренний, когда причина инцидента на нашей стороне;
внешний, когда причина инцидента на стороне вендора, партнера, ритейлера — кого угодно.
По внутренним инцидентам предоставляем апдейты каждые 15 минут, по внешним — каждые 30.
Оповещения у нас реализованы на базе компонентов, которые хранятся в CMDB. У каждого компонента отдельная карточка, где указано, на какие группы пользователей есть влияние, если происходит инцидент. Это могут быть клиенты, партнеры, сотрудники, рестораны, etc.
В каждый компонент у нас заложена схема оповещения на случай инцидента. Она включает в себя определенные каналы в определенных мессенджерах и оповещения по email. В карточке компонента можно посмотреть все залинкованные с ним инциденты.
Если инцидент произошел, а подходящего компонента нет, обращаемся к универсальному компоненту с дефолтной схемой оповещения. Когда инцидент с универсальным компонентом закрывается, автоматически появляется задача на создание нужного компонента. Удобно? Еще как!
С помощью компонентов мы реализовали не только внутренние, но и внешние оповещения. Мы отправляем их партнерам по email, если инцидент непосредственно на них влияет.
Например, мы зарегистрировали инцидент по недоступности панели администрирования, и он влияет не только на Купер, а потенциально может задеть кого-то из ритейлеров. Тогда в инциденте выбираем компонент «Панель администрирования», и внешним партнерам рассылаются письма, что у нас зарегистрирован такой инцидент. Повторное оповещение придет уже по факту устранения. Апдейты партнерам мы не транслируем.
Что потом?
Когда мы устранили инцидент, обязательно заполняем тикет в течение 24 часов с момента устранения. Описываем хронологию, причины, выявления, устранения, описания влияния и проставляем временные метрики.
Инцидент-менеджер домена также считает финансовые потери, проводит разбор с участниками устранения, формирует action items и контролирует их выполнение. Для высокоприоритетного инцидента это делают на следующий день после устранения. Для низкоприоритетного — по запросу.
Самые внимательные из вас заметили, что я рассказала только про метрики, завязанные на скорость. Но, конечно, нельзя ориентироваться на них и не учитывать качество.
Метрика №3. Качество заполнения инцидентов, предоставляемых апдейтов и эскалации. Для трекинга этих показателей у нас есть дашборд по инженерам мониторинга, мы реализовали его в Metabase. Там можно отслеживать и единичные, и системные ошибки. Проверяющий проходит по чек-листу и снимает с инженера баллы за неверное заполнение полей. Потом баллы суммируются и попадают в табличку, где мы их и смотрим.
Чего мы добились?
Нам удалось в разы снизить нагрузку на команды разработки. Теперь у нас есть выделенная команда мониторинга, которая примет алерт, проанализирует его и привлечет разработчиков только в случае реального влияния на сервис.
Мы стабильно укладываемся в целевые метрики по скорости. Спасибо эффективному взаимодействию с разными командами, проблем-менеджменту и сильной культуре работы с инцидентами!
Благодаря автоматизациям мы реализовали управление активным инцидентом в одном окне.
Я рассказала про большую и мощную схему, которую мы долго и усердно строили. Однако в ней предостаточно небольших фичи, которые спокойно можно реализовать у себя. Забирайте по потребностям, применяйте по возможностям!