В одном из предыдущих постов мой коллега Юрий рассказывал об устройстве нашего мониторинга.

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

Для ленивых или занятых — переходите сразу на последний раздел: там краткая выжимка.

Самый классный мониторинг

После внедрения платформы наблюдаемости у нас появились очень крутые инструменты мониторинга. Мы провели большую работу по централизации всех локальных мониторингов, ответили около 150 раз на вопрос «У меня и так все мониторится. Зачем мне дублировать данные к вам?», сами разобрались в устройстве некоторых особо сложных приложений и в итоге смогли собрать достаточный объем подключённых систем/продуктов, чтобы сказать «мы частично начали наблюдать за ИТ-ландшафтом». 

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

Хронология событий: 

1. Завис сервер, упала система и продукт стал недоступен. 

2. Быстро поняли факт зависания (спасибо нотификациям) и оперативно исправили причину.

3. После профилактического рестарта система не заработала.

4. Диагностика новых гипотез продлилась непозволительные 2 часа. В итоге пришлось просто перебирать все дашборды и алармы вручную. После того как нашли активный аларм, решили проблему за 5 минут.

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

Как мы отреагировали на полученный опыт

Вывод — это хорошо, а дальше-то что? 

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

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

Идея оказалась на поверхности: 

• у нас есть инцидент, который связан с системой (Конфигурационной единицей в терминах CMDB); 

• у нас есть мониторинг, который связан с этой же системой и имеет алармы. 

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

С чем мы столкнулись при реализации

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

Давайте по порядку: 

1. Оказалось, что у нас неидеально наполненная CMDB, и из-за этого построить связь между алармом на сервере и инцидентом по конкретной системе в ряде случаев было нельзя;

2. Внезапно пользователи не знают номенклатурное название системы, в которой у них возникла проблема (одних только zabbix’ов у нас штук 5 официальных наименований), и поэтому автоматически понять, в какой именно дашборд надо лезть за алармами, невозможно; 

3. Главное — пользователи не хотят заводить параметризированные инциденты, так как нужно много читать / выбирать, а не просто сказать «у меня тут сломалось, почините плз».

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

На наши же плечи легла очень сложная задача: обеспечить нас данными для построения и поиска связей и влияния инцидента на ИТ-ландшафт.

Связь инцидента и аларма

Единственным общим полем у аларма и инцидента была мнемоника конфигурационной единицы. 

Но была проблема — аларм возникает на железном и/или виртуальном хосте (с одной мнемоникой), а инцидент возникает у пользователя на системе (с другой мнемоникой). При этом то, что пользователь называет системой, в терминах CMDB может быть хоть приложением, хоть базой данных, хоть сервером. Не будем же мы терроризировать уважаемых сотрудниц из условной бухгалтерии вопросами о точном названии приложения, которое у них не работает. 

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

Итерационно мы внедряли новые функции по указанию описания пользовательского обращения:

1. Мы предлагали указать систему, на которой возникла проблема. Около 60% пользователей выбирали «Система не указана».

2. Мы дали возможность выбора текста обращения из выпадающего списка, каждый пункт списка был связан со своей мнемоникой системы (Конфигурационной единицей) из CMDB. Влияние на качество заполнения систем было, но незначительное.

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

4. Предупреждения вида «Укажите систему, и ваш инцидент решится в 2 раза быстрее» или другие попытки заставить пользователей заполнять системы не принесли значимых результатов. 

Что касается связей инфраструктуры (на которой возникает аларм) и приложений (на которые этот аларм оказывает влияние), то здесь всё оказалось проще. 

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

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

После этих манипуляций мы получили такую картину: 100% мониторинговых 50% пользовательских инцидентов обогащались информацией об алармах. Это неплохой результат, но наша конечная цель (north star) состояла в обогащении 100% инцидентов. При этом идеи, как заставить пользователей указывать пострадавшую систему, закончились. 

Пусть пользователь не заводит инцидент

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

Для перевода пользовательских инцидентов в мониторинговые мы начали развивать наши возможности как по оценке мониторинга продуктов, так и по возможностям управления инцидентами через API:

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

2. Мы облегчили подключение к нашему web-сервису для управления инцидентами. При этом целевым для команд способом заведения инцидентов мы продвигаем платформу наблюдаемости. 

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

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

В сухом остатке и что дальше

1. Мониторинг — хорошо, но когда его много, то можно пропустить самое важное.

2. Когда решаешь аварию, важно понимать актуальное состояние всех элементов продукта. Для этого мы реализовали кнопку «Проверить статус», которая возвращает список активных на данный момент алармов.

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

4. Самый действенный способ заставить пользователя завести «правильный» инцидент — завести этот инцидент за него. 

На этом мы, конечно, не останавливаемся. Сейчас у нас несколько крупных задач:

1. На этапе MVP у нас реализация автодиагностики аварий. Сбор всей необходимой информации для принятия решения о том, как исправить тот или иной инцидент. Разница с алармов в том, что аларм сообщает, что сломалось, а автодиагностика отвечает на вопрос — почему сломалось.

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

На этом на сегодня всё. 

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

P.s: совсем скоро мы выпустим статью о том, как за один год мы перешли от мониторинга к наблюдаемости.