Мониторинг: навык, который замечают только когда всё упало

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

Что означает требование мониторинга

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

Мониторинг — это про ответы на вопросы: «Что сломалось?», «Когда сломалось?», «Почему?». Если вы не можете сформулировать, как отличить штатную нагрузку от аномалии, значит, навык у вас не сформирован, даже если вы ставили Zabbix.

Метрики, логи и события: три разных потока

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

Грамотный специалист не смешивает эти потоки. Для каждого — свой инструмент и свой подход к хранению. Метрики хранят в TSDB, логи — в ELK или аналогах, события — в системах алертинга. Если вы пытаетесь искать проблемы по логам в реальном времени, вы делаете что-то не так.

Порог срабатывания как главный вопрос

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

Опытный администратор не ставит порог на 90% загрузки CPU для всех серверов одинаково. Он учитывает характер нагрузки: для веб-сервера 90% может быть нормой, а для базы данных — уже критично. И всегда добавляет гистерезис, чтобы алерт не дёргался при кратковременных скачках.

Ложные тревоги и усталость от алертов

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

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

Что спрашивают у администратора

На собеседовании на позицию системного администратора по теме мониторинга спрашивают конкретные сценарии. Например: «У вас упал веб-сервер. Какие метрики вы проверите в первую очередь?» или «Как вы поймёте, что проблема в сети, а не в приложении?». Ожидают, что вы начнёте с проверки доступности, затем посмотрите на нагрузку CPU и память, потом на логи.

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

Что спрашивают у безопасника

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

Типичный вопрос: «Вы видите в логах много неудачных попыток входа. Это брутфорс или сбой в приложении?». Правильный ответ — посмотреть на источник: если все попытки с одного IP, это атака; если с разных, но с одинаковым временем — возможно, проблема в интеграции. Мониторинг безопасности — это про умение строить корреляционные правила и не создавать шум.

Инструменты, которые называют чаще всего

В вакансиях для администраторов чаще всего упоминаются Zabbix, Prometheus, Grafana, Nagios, Icinga. Для логов — Elasticsearch, Kibana, Graylog. Для безопасности — Splunk, MaxPatrol, Ku: (но Ku: — это продукт Positive Technologies, его тоже называют). Знание этих систем — база, но котируется не сам факт установки, а умение настроить их под конкретные задачи.

Работодатель смотрит, писали ли вы свои экспортёры для Prometheus, делали ли кастомные дашборды в Grafana, настраивали ли алерты через Alertmanager. Если вы только смотрели на готовые дашборды, это не будет засчитано как опыт. Лучше показать портфолио с описанием, какие проблемы вы решали с помощью мониторинга.