9 правил внедрения корпоративного ИТ-мониторинга: как сделать все правильно и избежать боли на старте

Кто бы мог подумать, что внедрение корпоративного ИТ-мониторинга может быть таким… скажем так, «интересным»? Вы начинаете с благих намерений, а заканчиваете в окружении мигающих экранов и тысячи алертов. Большинство проектов могли бы проходить гораздо быстрее, если бы не хаотичный подход. Особенно «весело» дела обстоят с legacy-системами, где документация — это древний свиток, а знания разбросаны, как пазл, потерявший половину деталей. Мы собрали 9 правил, которые помогут избежать хаоса и внедрить мониторинг без боли.

О том, «Что делать?» (без «Кто виноват?») — читайте в нашей статье.

***

Внедрение корпоративного мониторинга — это как строительство моста. Сначала нужно изучить местность, рассчитать нагрузку и разработать проект, затем спланировать таймлайн стройки, заложить фундамент и только потом приступать к основному строительству. Если пропустить этап планирования, мост может рухнуть под собственным весом (ну, строители мостов нас поправят).

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

Но есть и хорошие новости: этого можно избежать. В этой статье мы собрали 9 правил, которые помогут вам сделать мониторинг действительно работающим инструментом, а не источником головной боли. Эти правила — результат работы с десятками проектов в Enterprise, где счет объектов мониторинга идет на миллионы.

Кстати, если хотите потренироваться и попробовать всё на практике, вы всегда можете скачать и установить нашу комьюнити-версию Monq. Это полнофункциональная песочница, где можно экспериментировать без риска для production-среды.

Попробуйте нашу бесплатную комьюнити OnPrem-версию — в ней доступен весь функционал, о котором мы пишем в блоге.

Теперь все 9 правил в виде кликабельного оглавления и ниже — уже подробнее.

1. Сначала – инвентаризация и аудит, потом – выбор инструментов

2. Стандартизация метрик и процессов

3. Регламентация процессов до написания сценариев

4. Продумайте ролевую модель и права доступа

5. Соберите требования пользователей — отзывы как «технарей», так и бизнеса

6. Запланируйте миграцию данных и бэкапы

7. Уберите условный «мусор» из инфраструктуры

8. Создайте чек-лист для тестирования

9. Запланируйте пост-внедренческую поддержку

10. Заключение и выводы

1. Сначала – инвентаризация и аудит, потом – выбор инструментов

Все из нас видели объявления “Инвентаризация” на дверях торговых точек, а теперь нужно сделать тоже самое перед внедрением ИТ-мониторинга в вашей организации. 

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

Такая задача включает в себя составление реестра всех компонентов: компьютеров на рабочих местах, серверов, сетевых устройств, баз данных, приложений и IoT-устройств (кассовое и складское оборудование) и т.д. 

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

На этом этапе важно выявить так называемые «черные ящики» — системы без документации и “непонятно как работающие”, устаревшие решения или процессы, выполняемые вручную. Идентификация таких элементов поможет определить потенциальные риски и области, требующие особого внимания при внедрении системы мониторинга.

Поскольку в большинстве компаний обычно уже есть какие-то внедренные процессы мониторинга, их тоже надо оценить. В данном случае – определить, какие метрики уже собираются, какие системы мониторинга используются (например, Zabbix, Prometheus или “трофейный” Splunk) и насколько эффективно они интегрированы в аналитикой по инцидентам (если есть приложение аналитики). Обзор существующих решений позволит выявить дублирование функций, недостаток интеграций и избыточную нагрузку на ИТ-персонал девопс и техподдержки из-за разрозненности инструментов.

Дополнительно на этом этапе важно оценить объем данных, которые будут поступать в систему мониторинга. Такой анализ поможет заранее заложить необходимые ресурсы и избежать проблем с нехваткой хранилища в будущем. Аудит позволит понять, сколько у вас сейчас разнообразного «добра», и прикинуть, какой запас дискового пространства может потребоваться для хранения поступающих данных от всего этого в «зонтике». Вам нужно 1 ТБ, если хотите хранить «первичку» два года, или 7-10 ТБ на 5 лет?

Также важно учитывать не только технические аспекты, но и организационные. На старте внедрения измеряется текущее состояние: 

• Сколько сервисов под мониторингом, 

• Какие интеграции требуются, 

• Какие команды участвуют в процессе получения алертов и реагирования на инциденты. 

Это создает четкие ориентиры для отслеживания прогресса аудита и затем внедрения. Например, на первом этапе может быть покрыто 20% инфраструктуры, затем 45%, 70% и так далее. Как показывает практика, при наличии большой и сложной ИТ-инфраструктуры движение к цели с фиксированными вехами мотивирует команду больше, чем бесконечный процесс без видимого конца.  

Команде внедрения гораздо легче работать, когда есть четкий прогресс, чем просто «день сурка» без понимания, когда наконец будет результат.

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

2. Стандартизация метрик и процессов

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

Для эффективного мониторинга необходимо заранее определить KPI. Например, доступность сервиса на уровне 99,95% в рамках SLA или время реакции на инциденты в пределах 15 минут. Важно четко разделять технические и бизнес-метрики, а также учитывать, как они соотносятся друг с другом.

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

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

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

О роли архитектора проекта внедрения

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

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

3. Регламентация процессов до написания сценариев

Этот пункт начнем с постулата «Эффективная автоматизация мониторинга невозможна без четких регламентов».

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

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

Кроме того, необходимо создать централизованное хранилище знаний (например, типа Confluence или GitLab Wiki), где будут собраны все схемы, инструкции и технические регламенты. Это позволит команде быстро находить необходимую информацию и обеспечит преемственность знаний по мере обновления коллектива сотрудников.

4. Продумайте ролевую модель и права доступа

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

Это важно: корпоративный ИТ-мониторинг невозможен без гибкой ролевой модели. Подразделениям важно ограничить доступ к своим данным или грамотно им управлять, причем даже внутри одной организации. Функциональность ролевой модели поддерживается в Monq.

Для начала постарайтесь определить ключевые роли:

• Администраторы – отвечают за настройку системы мониторинга и интеграций.

• Инженеры поддержки 1-й и 2-й линии, хотлайн – анализируют алерты и реагируют на инциденты.

• Менеджеры и аналитики – оценивают метрики и готовят отчеты.

В Monq предусмотрена ролевая модель с рабочими группами (РГ). Например, администраторы и инженеры поддержки могут находиться в разных РГ с различными уровнями доступа. У каждого мониторингового объекта (ключевого элемента, сигнала, правила) есть владелец – рабочая группа. Доступ к объектам, за которые отвечает другая РГ, будет закрыт, если не был заранее расшарен.

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

5. Соберите требования пользователей — включая как отзывы «технарей», так и бизнеса

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

Давайте в этом разделе распишем, что желательно сделать:

1. Провести интервью с конечными пользователями. Начните с выявления потребностей и проблем, с которыми сталкиваются пользователи. Задавайте по возможности простые и понятные им вопросы, такие как:

   • Какие проблемы вас беспокоят в текущем мониторинге?
     Пример ответа: «приходится бегать по разным интерфейсам искать причину аварии».

   • Какие отчеты вам нужны для принятия решений?
     Сюда могут входить такие данные, как SLA (уровень доступности), время реакции на инциденты и т.д.

   • Как инженеры привыкли работать с алертами?
     Какой таскфлоу существует сейчас, и каким этим же самым инженерам хотелось бы, чтобы он был в новой системе? 

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

2. Создать MVP (минимально жизнеспособный продукт) для мониторинга и протестировать его на фокус-группе. Прототип системы мониторинга поможет пользователям лучше понять, как будет работать новая система, и выявить слабо проработанные места на ранней стадии. Фокус-группа может предоставить “предиктивные” замечания, которые помогут избежать крупных изменений на более поздних этапах.

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

Теперь о том, почему знать мнение пользователей — это не просто дань пресловутому «Корпоративному духу».

Технически идеальная система, которой никто не пользуется — это пустая трата бюджета

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

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

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

Диалоги внедренцев и конечных пользователей помогут не только снизить сопротивление к изменениям, но и привлечь среди конечных пользователей «адептов» новой системы — тех, кто сам захочет разобраться в новой системе, станет ее сторонниками и «агентами влияния». Лидеры мнений в команде, такие как старшие инженеры и менеджеры групп, могут существенно повлиять на восприятие полезности внедрения. Если остальные пользователи увидят, что лидеры уверенно пользуются новым инструментарием и довольны, научились быстрее разруливать алерты, — это значительно ускорит процесс адаптации.  

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

6. Запланируйте миграцию данных и бэкапы

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

Первый шаг – создание резервных копий конфигураций существующих систем. Это особенно важно при миграции метрик из таких решений, как Zabbix, Prometheus или Nagios, где форматы данных могут отличаться. Например, в Monq данные хранятся в формате JSON, тогда как Zabbix использует свою внутреннюю структуру. Ошибки при конвертации могут привести к потере критически важных параметров, поэтому совместимость стоит проверить заранее и по возможности, на малых датасетах.

После миграции данных настройте автоматическое резервное копирование:

• Конфигураций новой системы (Monq), чтобы при сбое можно было быстро откатиться к рабочему состоянию.

• Сценариев автоматизации, поскольку восстановление сложных цепочек событий вручную займет много времени.

• Исторических данных, которые необходимы для трендов, прогнозов и ретроспективного анализа.

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

Любой системе нужны бэкапы, логирование и мониторинг. Система мониторинга тоже может сломаться, и об этом надо помнить. На этапе внедрения, когда платформа мониторинга еще только настраивается, отсутствие логов может превращать поиск проблем в хаос. Пример решения — использовать комбинацию On-premise мониторинга и сервиса в облаке, который “мониторит мониторинг”, чтобы не получить ситуацию перенасыщения алертами и фигурально говоря, “остаться без глаз” во время крупной аварии.

7. Уберите условный «мусор» из инфраструктуры

Прежде чем интегрировать новые системы мониторинга в ИТ-инфраструктуру, важно тщательно очистить инфраструктуру от недостоверных и избыточных данных.

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

Теперь распишем, что полезно делать на данном этапе:

1. Ликвидируйте ненужное. Первым шагом является удаление всех неактуальных данных или данных от «мертвых конфигурационных единиц»  из системы:

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

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

   • Устаревшие алерты: Устаревшие или неправильно настроенные алерты могут привести к перенасыщению системы ложными тревогами и затруднить восприятие настоящих инцидентов со стороны инженеров. Необходимо провести аудит всех алертов и настроить их соответствующим образом.

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

   • Пример: Region: N-West_78, Type: POS — такой подход помогает структурировать данные и упрощает их анализ.

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

Немного пояснений и подробностей к этапу 7:

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

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

8. Создайте чек-лист для тестирования

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

Основной инструмент контроля – чек-лист тестирования, который поможет систематически проверять все ключевые аспекты работы. Например в Monq он выглядит следующим образом:

1. Корректность сбора данных, проверка подключенных интеграций и то что данные поступают с систему в ожидаемом виде;

2. Работающая автоматизация. Важно проверить, что low-code сценарии запускаются корректно и создают объекты с правильными параметрами. Для этого в Monq есть debug-режим для полноценной отладки.

3. Работоспособность алертов – система должна корректно определять инциденты и отправлять оповещения в нужные каналы коммуникаций (почта, Telegram и т. д.). Важно протестировать все сценарии эскалации: если ответственный не реагирует, как должен инцидент автоматически передаваться на следующий уровень?

4. Отображение данных в дашбордах – метрики, алерты и статус сервисов должны визуализироваться так, чтобы их можно было быстро интерпретировать. Например, критические ошибки – красным, предупреждения – желтым, а нормальное состояние – зеленым.

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

Дополнительно, в чек-листе стоит зафиксировать критерии приемки системы по результату тестов. Например:

• «Изменение здоровья сервиса отображаются в Monq в течение 1 минуты после сбоя.»

• «1000 сигналов загружаются в интерфейсе не дольше 2 сек»

• «Система должна принимать и обрабатывать на менее 1000 аварийных событий в секунду»

Продуманный чек-лист тестирования – это гарантия того, что мониторинг будет работать стабильно, а критические инциденты не останутся незамеченными.

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

9. Запланируйте пост-внедренческую поддержку

Запуск системы мониторинга — это только начало ее эксплуатации. Даже если мониторинг успешно интегрирован, без четкого плана по поддержке он быстро превратится в «затерянный мир»: сценарии устареют, сотрудники забудут, как ими пользоваться (а недавно нанятые будут не знать где и кого спрашивать), документация останется в лучшем случае на жестком диске админа и прочие «Ужасы нашего городка».

Чтобы этого не произошло, нужно заранее предусмотреть «золотую неделю» — период после запуска, когда команда активно отслеживает работу системы и оперативно исправляет выявленные проблемы. 

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

• Обновляет документацию (Confluence, GitLab Wiki и т.п.), чтобы она всегда оставалась актуальной.

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

Как показывает практика, без четко выделенного ответственного (куратора) мониторинг со временем начинает «засоряться»: появляются дублирующие алерты, устаревшие правила, а новые сотрудники девопс не проходят качественный онбординг и не понимают, как работать с системой.

Заключение

Главное правило успешного внедрения мониторинга: он начинается не с установки новой системы, а с аудита инфраструктуры, наведения порядка в процессах и регламентах.

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

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

---

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

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