В ИТ-службе все может выглядеть спокойно: серверы доступны, процессоры не перегружены, каналы связи работают, а SLA на панели зеленый. Руководитель видит, что инфраструктура формально жива, а инженер — что критических алертов нет. Система мониторинга не ошибается, но в это же время пользователи жалуются на задержки, сотрудники повторяют операции вручную, а часть транзакций не проходит с первого раза. Инженеры ЦОДа компенсируют отклонения в охлаждении. Бизнес-процесс еще не остановился, но уже стал хуже, дороже и менее предсказуемым. Об этом сообщает «Код Дурова».

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

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

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

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

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

Слепые зоны появляются на границах ответственности. Инфраструктура редко ломается строго внутри одной зоны ответственности. Приложение может зависеть от сервера, сеть — от внешнего канала, ЦОД — от электропитания и охлаждения, пользовательский сервис — от SaaS-платформы, которая формально находится у внешнего поставщика. На схемах эти зоны часто разделены. Серверы контролирует ИТ-служба, инженерную инфраструктуру ЦОДа ведет эксплуатация здания, SaaS находится у провайдера. Устаревшее оборудование может вообще жить в режиме «оно давно работает, не трогайте». Но для бизнес-процесса эти границы не имеют значения. Если охлаждение дает сбой, падает тот же сервис. Если SaaS недоступен, операция тоже не проходит. Если старый коммутатор в забытой зоне начинает сыпать ошибки, пользователи видят задержки.

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

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

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

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

Среднее время восстановления, MTTR, любят использовать как показатель эффективности эксплуатации. Метрика понятная: сколько времени проходит от обнаружения инцидента до возвращения сервиса в рабочее состояние. Чем меньше, тем лучше. Но здесь есть ловушка. MTTR можно улучшить быстрым перезапуском, переключением на резерв или временным обходом. Сервис снова доступен, показатель красивее, команда молодцы. Но если корневая причина не устранена, сбой повторится. Инженеры снова выполнят те же действия, пользователи снова столкнутся с проблемой, бизнес снова потеряет время.

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

То же касается алертинга. Если дежурную смену оценивают только по снижению ложных вызовов, команда начнет повышать пороги, отключать шумные правила и игнорировать часть уведомлений. Формально шума меньше. На практике значимые события могут начать проходить мимо. Правильнее разделять уведомления по требуемой реакции. Критичные события должны сразу попадать дежурной смене. Менее срочные — фиксироваться для разбора в рабочее время. Накопленные изменения — анализироваться как тренды. В KPI должны учитываться не только ложные вызовы, но и пропущенные инциденты, повторяемость сбоев и результаты анализа причин.

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

«Слепая зона часто возникает не там, где нет метрик, а там, где они принадлежат разным командам и не складываются в зависимость. Эксплуатация видит рост задержек, ИБ видит необычные соединения, бизнес видит просевшую операцию. Если эти данные не связаны, компания реагирует на фрагменты одного события и может неверно определить его причину», — сообщает «Код Дурова».

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

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

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

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

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

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

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

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

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

Экспертиза инженера тоже должна становиться данными. Часть качества мониторинга держится не на правилах, а на опыте людей. Опытный инженер видит сочетание метрик, вспоминает историю работ, замечает связь с соседними системами и понимает, что через несколько часов может случиться сбой. Начинающий специалист смотрит на те же графики, но не считывает контекст. Это похоже на рецепт, в котором все шаги записаны, но последний пункт звучит как «готовить 10-20 лет». Формально инструкция есть, а главный слой знания остается у человека.

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

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

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

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

Подписывайтесь на наш Telegram-канал, чтобы быть в курсе всех новостей и событий Рунета.