Вернуться к главной странице, списку всех тем

Техническое задание для инженера мониторинга

Что проверяет: умеешь ли ты в одиночку развернуть мониторинг, настроить осмысленные алерты, разобрать инцидент и оставить после себя документацию

Что нужно пройти заранее: тему 1 (bash, systemd), тему 4 (Compose) и обязательно тему 8 (метрики, PromQL, SLO, алерты)

Сколько времени займёт: 12–16 часов

Результат: git-репозиторий, который не стыдно показать на собеседовании

Часть 1: Развёртывание стека мониторинга

Задача: самостоятельно развернуть полноценный стек мониторинга на своей машине или виртуальной машине

Требования:

  1. Развернуть через Docker Compose следующие компоненты:
    • Prometheus
    • Grafana
    • Alertmanager
    • Node Exporter (для мониторинга самой системы)
  2. Требования к качеству конфигурации:
    • У всех образов зафиксированы версии, тега latest быть не должно
    • У всех сервисов задан restart: unless-stopped
    • Данные Prometheus и Grafana лежат в именованных томах и переживают docker compose down
    • Ключ version: в начале файла не используется — он устарел
  3. Предоставить:
    • Файл compose.yml
    • Все конфигурационные файлы (prometheus.yml, alertmanager.yml)
    • Скриншот работающих контейнеров (docker compose ps)

Часть 2: Настройка мониторинга и алертинга

Задача: настроить сбор метрик и правила алертинга

Требования:

  1. В Prometheus настроить:
    • Scrape-конфиг для Node Exporter
    • Минимум 4 правила алертинга, из них обязательно:
      • HostHighCpuLoad — загрузка CPU выше 80% в течение 2 минут
      • HostHighMemoryUsage — использование памяти выше 85%
      • HostDiskSpaceCritical — свободного места на диске меньше 10%
      • HostDiskWillFillIn24h — по текущему тренду диск закончится в ближайшие сутки (подсказка: predict_linear)
  2. Обосновать письменно: в теме 8 объясняется, почему алерт «CPU выше 80%» сам по себе плохой — он сообщает о причине, а не о симптоме, и часто будит человека, когда пользователи ничего не заметили. В файле docs/alerts.md ответь:
    • Какой из твоих четырёх алертов действительно требует немедленной реакции ночью, а какой может подождать до утра?
    • Как ты изменил бы эти алерты, если бы за стеком стоял реальный пользовательский сервис? Приведи хотя бы один алерт на симптом (доля ошибок или задержка), а не на ресурс
    • У каждого алерта должно быть поле severity и аннотация с описанием, что делать дежурному
  3. В Alertmanager настроить:
    • Отправку уведомлений в Telegram
    • Маршрутизацию по severity: critical — немедленно, warning — с группировкой и задержкой
    • Дедупликацию и группировку (group_by, group_wait, repeat_interval) — объясни в комментариях выбранные значения
  4. Предоставить:
    • Файлы конфигураций с комментариями
    • Скриншот Prometheus → Status → Targets, все цели в состоянии UP
    • Скриншот страницы Alerts в Prometheus
    • Скриншот пришедшего в Telegram уведомления

Часть 3: Создание дашборда в Grafana

Задача: создать дашборд, по которому дежурный за 10 секунд понимает, всё ли в порядке

Требования:

Создать дашборд минимум с шестью панелями:

  1. Общее состояние — статус всех целей (up/down) одним числом или таблицей
  2. CPU Usage — график использования процессора
  3. Memory Usage — график использования памяти
  4. Disk Space — свободное место по разделам
  5. Disk I/O или Network — нагрузка на диск либо сетевой трафик
  6. Load Average — с линией порога, равной числу ядер

Требования к оформлению:

Предоставить:

Часть 4: Симуляция и диагностика инцидента

Задача: провести диагностику и задокументировать инцидент

Сценарий:

  1. Искусственно создать инцидент (на выбор):
    • Нагрузка на CPU: stress-ng --cpu 4 --timeout 300s или цикл в bash
    • Заполнение диска: fallocate -l 5G /tmp/bigfile
    • Утечка памяти: контейнер с лимитом и приложением, которое его превышает
  2. Действия:
    • Зафиксировать момент возникновения алерта (скриншот)
    • Замерить MTTD — сколько секунд прошло от начала проблемы до срабатывания алерта
    • Провести диагностику: метрики в Prometheus, логи, состояние системы
    • Определить причину
    • Устранить инцидент и замерить MTTR — время от алерта до восстановления
    • Зафиксировать восстановление
  3. Предоставить:

    • Хронологию инцидента в виде таблицы:

      | Время | Событие | Действие | Результат | |——-|———|———-|———–|

    • Скриншоты: алерт → метрики → диагностика → восстановление
    • Постмортем без поиска виноватых (5–10 предложений): что произошло, как обнаружили, как устранили, что сделать, чтобы не повторилось. Формулируй причины через процессы и системы, а не через людей

Часть 5: Автоматизация и документация

Задача: оставить после себя то, чем сможет пользоваться другой человек

Требования:

  1. Написать Runbook для одного из алертов в формате Markdown:
    • Описание проблемы и на что она влияет для пользователя
    • Как проверить — готовые к копированию команды
    • Шаги по устранению
    • Что делать, если не помогло; контакты для эскалации
    • Ссылка на дашборд с нужными метриками
  2. Написать bash-скрипт healthcheck.sh, который:
    • Начинается с set -euo pipefail
    • Проверяет доступность Prometheus, Grafana и Alertmanager через curl
    • Проверяет, что все контейнеры стека запущены
    • Выводит статус в читаемом виде — OK / FAIL по каждому компоненту
    • Возвращает код 0, если всё хорошо, и 1, если есть проблемы
    • Работает при запуске из любого каталога (никаких относительных путей)
  3. Проверить скрипт делом: останови один контейнер, запусти скрипт, убедись, что он вернул FAIL и код 1. Приложи скриншот обоих запусков

Предоставить: runbook.md, healthcheck.sh, скриншоты выполнения

Формат сдачи результатов

Создать git-репозиторий (GitHub или GitLab) со структурой:

monitoring-test/
├── README.md                 (описание и инструкция по запуску)
├── compose.yml
├── configs/
│   ├── prometheus.yml
│   ├── alert.rules.yml
│   └── alertmanager.yml
├── grafana/
│   └── dashboard.json
├── scripts/
│   └── healthcheck.sh
├── docs/
│   ├── alerts.md             (обоснование алертов из части 2)
│   ├── runbook.md
│   └── incident-report.md
└── screenshots/
    ├── 01-containers.png
    ├── 02-prometheus-targets.png
    ├── 03-alerts.png
    ├── 04-telegram.png
    ├── 05-grafana-dashboard.png
    ├── 06-incident-alert.png
    ├── 07-incident-recovery.png
    └── 08-healthcheck.png

Прислать ссылку на репозиторий

Как это будет оцениваться

Критерий На что смотрят
Работоспособность Стек поднимается из репозитория одной командой на чистой машине
Воспроизводимость Версии зафиксированы, данные в томах, нет ручных шагов «а потом я кликнул в интерфейсе»
Осмысленность алертов Алерт сообщает, что сломалось и что делать, а не просто «метрика превысила число»
Качество дашборда По нему видно состояние системы без объяснений автора
Разбор инцидента Есть измеренные MTTD и MTTR, причина названа честно, выводы конкретные
Документация По README посторонний человек запускает стек, по runbook — чинит проблему

Главный критерий: отдай репозиторий знакомому и попроси развернуть стек по инструкции, ничего не спрашивая у тебя. Получилось — задание сдано