Привет, Хабр! Если вы, работая в ИТ, занимаетесь сопровождением и администрированием автоматизированных систем и предоставляете сервис внутреннему или внешнему клиенту, то у вас или уже есть система мониторинга, либо вы задумывались о её создании. И поэтому сейчас вы здесь!

Меня зовут Павел Степуро, я исполнительный директор ДИТа «Занять и Сберегать» в Сбере. В этой статье я расскажу о подходах и лучших практиках построения систем мониторинга автоматизированных систем в ИТ-компаниях.

Мы поэтапно пройдём путь от первого красивого дашборда до глубокой автоматизации, с помощью которой система мониторинга будет самостоятельно принимать решения, устранять инциденты, предотвращать их на ранних этапах, а также минимизировать их влияние на клиента и бизнес. А ещё вы найдете главу, посвящённую прогнозированию отклонений с помощью ML/AI-моделей.

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

Поэтому эта статья одинаково полезна для:

• компаний любого размера, в которых имеются онлайн‑сервисы и операции для клиентов, а также обеспечивающие их автоматизированные решения;

• компаний, находящихся на любом из уровней и этапов развития системы мониторинга;

• специалистов, которые имеют опыт в создании систем мониторинга;

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

Старт

Наличие качественной системы мониторинга особенно актуально сейчас, когда сервис клиенту предоставляется в режиме 24/7/365, а золотым стандартом надежности является доступность автоматизированных систем не ниже 99,99%. Мы давно не ждем начала рабочего дня, чтобы передать показания счетчиков, забронировать гостиницу или взять кредит и многое другое, в выходной день и посреди ночи — сервисы всегда доступны для нас.

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

Уровни развития мониторинга в компаниях:

1. Нулевой. Вы узнаёте о наличии проблем в ваших системах от ваших же клиентов или из СМИ.

2. Базовый, или «Зыринг». Метрики, агенты и дашборды.

3. Продвинутый. Наличие событий, уведомлений и алертинга.

4. Продвинутый мониторинг с базовой автоматизацией.

5. Продвинутый мониторинг с предсказанием метрик и событий.

6. PRO. Максимальная автоматизация на уровне атомной электростанции. Дежурный и администратор автоматизированной системы вам больше не нужны.

Вы находитесь здесь…

LEVEL 0. Нулевой

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

HINT: не пытайтесь отрицать необходимость создания системы мониторинга, не оттягивайте время начала её создания. Главное начать, остановиться вы уже не сможете.

LEVEL 1. Базовый, или «Зыринг»

На этом этапе вы уже организовали базовый мониторинг. Выбрали систему, на базе которой он построен. Установили первыe инфраструктурныe агенты на свои сервера. И переходите к созданию своего первого дашборда с метриками.

HINT: не ограничивайтесь на этом этапе настройкой исключительного инфраструктурного мониторинга. Есть много условно бесплатных безагентских способов его обогатить другими метриками без необходимости дорабатывать свою систему (пинг URL авторизации или сервиса и получаемый код ответа, запрос метрики из БД, метрики из логов и др.).

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

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

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

Level 2. Продвинутый

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

HINT: уведомлений много не бывает. Недостаточно одной почты, которая не является средством для оперативного реагирования. Хорошими практиками являются настройка SMS-уведомлений по критичным событиям и уведомления в рабочие чаты (вне зависимости от того, какими инструментами вы пользуетесь).

Важно разделить события по уровню критичности. Начните с трёх состояний: low, medium, high. При одновременном возникновении событий по нескольким метрикам, дежурному важно будет понимать, с какими из них важнее начать работу в первую очередь.

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

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

HINT: сразу введите кодификатор метрик, чтобы потом не переделывать уже созданные метрики, инструкции и алерты.

LEVEL 3. Продвинутый мониторинг с наличием базовой автоматизации

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

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

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

Всё это позволит вам сэкономить 7-10 минут, которые вы потратили бы во время инцидента без настроенной автоматизации.

LEVEL 4. Продвинутый мониторинг с предсказанием метрик и событий

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

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

На своём примере скажу, что мы пришли к 15 минутам. Это время, за которое администратор может подключиться к системе, обнаружить и устранить причины возможного сбоя, который мог бы случиться в будущем. При этом точность прогноза составила 80+ %. То есть 4 из 5 уведомлений от системы мониторинга реально могли привести к деградации сервиса и инцидентам.

Важно объяснить администраторам (будет сложно и потребуется время), что ML/AI-модель делает прогноз, похожий на прогноз погоды, который говорит о том, что необходимо взять зонт из‑за возможных осадков. Но если при 1 из 5 случаев (при точности прогноза в 80%) дождя не было, это не значит, что модель плохая и прогнозирование не работает.

Level 5. PRO

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

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

HINT: реализовать это можно с помощью управляющих сигналов, вызова API или за счёт дополнительных модулей, реализованных в составе системы мониторинга или в составе автоматизированной системы, которую вы поставили на мониторинг.

Поздравляем! Вы дошли до финала…

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

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