Этапы развития мониторинга: шесть ступеней зрелости
Мониторинг растёт не количеством графиков, а тем, насколько рано и насколько точно служба узнаёт о проблеме. Ступени ниже идут именно по этому признаку. Они не про бюджет и не про марку системы: на одном и том же Zabbix можно стоять на второй ступени и на пятой.
Практическая польза лестницы в том, что перепрыгнуть ступень не выходит. Алерты без выверенных порогов дают шум, а не раннее предупреждение; автоматизация поверх шума автоматизирует шум. Поэтому у каждой ступени ниже стоит признак, по которому себя узнают, и один шаг наверх - тот, который имеет смысл делать следующим.
Нулевой. Мониторинга нет
Как узнать себя: о проблемах на сети и сервисах становится известно из отчётов, от клиентов, иногда из соцсетей и прессы. Поздно, одним словом. Служба эксплуатации есть, системы наблюдения за ней - нет.
Что болит: время до обнаружения не измеряется, потому что момент обнаружения совпадает с моментом жалобы. Любой разговор о надёжности упирается в то, что фактов нет - есть впечатления.
Шаг наверх: начать собирать хоть что-то и хранить историю. Не «выбрать лучшую систему», а получить первые ряды данных: доступность ключевых узлов и сервисов, время отклика, ошибки. Выбор инструмента на этой ступени вторичен - первично, чтобы история копилась и не стиралась.
Начальный. Есть метрики и дашборды
Как узнать себя: метрики контроля определены и собираются, дашборды построены, кто-то смотрит на них круглосуточно. Минимальный надзор за ситуацией есть.
Что болит: дашборд показывает состояние в момент, когда на него смотрят. Ночная деградация, медленный рост очереди, редкий, но длинный отказ - всё это проходит мимо, пока не станет аварией. Дежурный видит красное, но не знает, красное это норма или повод будить людей.
Шаг наверх: превратить наблюдение в реакцию: для каждой ключевой метрики назначить порог и уровень критичности. Пороги на этой ступени берутся грубо - по историческому поведению и здравому смыслу; точность придёт позже.
Эффективный. Пороги, алерты и алгоритмы реагирования
Как узнать себя: у метрик есть пороги и уровни критичности, на их основе построены оповещения и написаны алгоритмы реагирования. По этим алгоритмам работает смена дежурных инженеров и ключевые специалисты.
Что болит: шум. Первая редакция порогов почти всегда даёт поток оповещений, среди которых доля настоящих невелика. Дальше происходит худшее, что может случиться с мониторингом: на оповещения перестают реагировать. Формально система есть, фактически предупреждение снова приходит от клиента.
Шаг наверх: начать измерять сами оповещения, а не только инфраструктуру. Сколько их за неделю, какая доля закончилась реальным действием, какие срабатывают чаще всего и ничем не заканчиваются. Это единственный способ выверять пороги по факту, а не по спору.
Оптимальный. Рутина автоматизирована, алерты выверены
Как узнать себя: заметная часть предсказуемых событий и фиксируется, и решается автоматически. Оповещения прошли проверку и адаптацию: дежурный владеет ситуацией, а администраторов не тревожат по пустякам.
Что болит: служба хорошо справляется с тем, что уже случилось, и почти не влияет на то, случится ли оно снова. Инциденты закрываются быстро, но повторяются: одна и та же сигнатура возвращается неделями, и это никого не удивляет, потому что каждый отдельный случай отработан по регламенту.
Шаг наверх: перестать смотреть на инциденты по одному. Взять историю за несколько месяцев целиком и спросить у неё, где простой концентрируется, что повторяется и что систематически предшествует авариям. Это переход от управления инцидентами к управлению проблемами.
Аналитический. Часть аварий просто не происходит
Как узнать себя: часть аварийных событий не случается вовсе - их предотвратили, разобрав состояние ресурсов, настроив наблюдение под найденные риски и починив причину, а не следствие. Есть реальная, а не бумажная готовность к катастрофическим сценариям.
Что болит: служба надёжна, но объясняет свою ценность на своём языке - в терминах доступности и времени восстановления. Для бизнеса это внутренняя кухня, и разговор о ресурсах даётся тяжело.
Шаг наверх: связать показатели наблюдения с тем, что важно бизнесу: какие сервисы критичны, что происходит с клиентом при их отказе, какие обещания даны в договорах. Дальше настраивать мониторинг от этого, а не от списка оборудования.
Smart. Настройка под показатели бизнеса
Как узнать себя: тонкая настройка под ключевые показатели бизнеса на основе уже накопленных данных и опыта работы с ними. Где-то это глубокое понимание бизнес-рисков и корректировка алгоритмов под них, где-то более широкий контроль влияния смежных систем и сервисов, где-то акцент на безопасность.
Что болит: ступень не имеет общего рецепта, и это её главное свойство. Здесь заканчиваются практики, которые можно взять из книги, и начинается работа с собственными данными компании.
Что удерживает на ней: регулярность. Настройка, сделанная один раз, устаревает вместе с инфраструктурой: меняется нагрузка, состав сервисов, состав команды. Ступень удерживается повторным разбором данных, а не разовым проектом.
Ступень видна не по тому, что установлено, а по тому, что осталось в журналах. Концентрация простоя, повторяющиеся сигнатуры, доля оповещений без действия, разрыв между временем до обнаружения и временем до восстановления - всё это читается из обычной выгрузки инцидентов за полгода.
Быстрый способ прикинуть ступень словами - тест зрелости в нашем боте: 7 вопросов, около 5 минут, в конце уровень и 2-3 совета, куда смотреть первым. Способ по данным - прислать выгрузку инцидентов и получить разбор: что деградирует, где отказ повторяется, что предшествует авариям.
Разбираете это внутри команды и хотите обсудить результат с инженером-эксплуатационником - hello@opslab.consulting.