✻ Урок 13.5 · Тема 13: Финал: работа и собеседования

Пробное собеседование: инженер мониторинга

⏱ 2 ч

Зачем это нужно

Я расскажу, как однажды на разборе меня спросили: «Алерт сработал в три ночи. Как ты поймёшь, что это не ложная тревога?» Я начал перечислять названия инструментов, а надо было идти от симптома к причине по приборам. С тех пор на такие вопросы я отвечаю маршрутом, а не списком.

Вторая роль, на которую ты можешь претендовать после курса, это инженер мониторинга (monitoring engineer, часто часть команды SRE): он настраивает сбор метрик, строит дашборды и пишет алерты, чтобы система была видна. На собеседовании на эту роль меньше говорят про генераторы нагрузки и больше про метрики, PromQL (язык запросов к метрикам, урок 7.2), алерты и чтение картины инцидента. Тебе, нагрузочнику, это пригодится: в небольших командах нагрузку и мониторинг ведёт один человек, а результат теста всё равно читают по графикам. В уроке банк из 35 вопросов (двенадцать самых быстрых вынесены в тренажёр ниже), задачи на запросы и дашборд, практическое задание вживую и самооценка.

Шаг проекта: файл ~/perf-lab/13-final/mock-monitoring.md с самооценкой и твоя шпаргалка запросов PromQL, которые ты пишешь по памяти.

Что нужно знать

• Метрики, Prometheus и модель pull: 7.1, PromQL: 7.2, Grafana: 7.3, экспортеры: 7.4, логи Loki: 7.5, алерты: 7.6.
• Теория производительности: 8.1, 8.2.
• Инцидент под нагрузкой и постмортем: 13.1.
• Техника ответа вслух, «не знаю», самооценка: 13.4: прочитай «Теорию» оттуда, она общая.

Картина целиком

Инженер мониторинга похож на диспетчера аэропорта: десятки сигналов, из которых надо быстро собрать картину. Но у диспетчера приборы готовые, а инженер сам решает, какие приборы поставить, и отвечает за то, чтобы они не врали. Главное качество здесь умение идти от симптома к причине по приборам. Интервьюер часто просит: «опиши по шагам путь от метрики до сообщения дежурному».

flowchart TD
    A["Приложение<br/>отдаёт /metrics"] --> B["Prometheus<br/>забирает (scrape)"]
    B --> C["Правила алертов<br/>проверяют условие"]
    C --> D["Alertmanager<br/>группирует, шлёт"]
    D --> E["Дежурный<br/>читает дашборд и логи"]

Метрики Prometheus забирает сам, приходя на /metrics (модель pull). Для коротких заданий, которые заканчиваются до его прихода, есть Pushgateway: приёмник, куда задание само отправляет метрики. В «Магазине» он не нужен. Пять звеньев, и каждое может сломаться. Приложение не отдаёт метрику, Prometheus не достучаться, правило ошиблось в условии, Alertmanager заглушил, человек не заметил. Хороший ответ на «что может пойти не так с алертингом» проходит по этой цепочке.

Теория

Чего ждёт интервьюер

Нанимающий проверяет три вещи. Знаешь ли ты модель метрик: типы (счётчик, измеритель, гистограмма) и метки (labels). Умеешь ли читать и писать запросы PromQL и объяснять их по частям. Способен ли рассуждать об алертах: что считать симптомом, какой порог, чтобы не будить людей зря и не пропустить беду.

Беседа идёт по плану: десять минут о тебе, двадцать вопросов по метрикам и Prometheus, десять задача на дашборд или запрос, десять про алерты и инциденты. Банк ниже следует тому же порядку. Технику ответа вслух, «не знаю» и самооценку мы разобрали в 13.4, здесь она та же.

Главное: на интервью проверяют модель метрик, PromQL и рассуждения об алертах.

Начнём с рамки, без которой дашборд читать страшно.

Как читать дашборд: RED и USE

Тебя просят «прочитай дашборд», и без рамки ты начнёшь метаться между панелями. Рамок две, и обе давно знакомы по уроку 7.3. RED для сервиса: Rate (сколько запросов), Errors (сколько ошибок), Duration (сколько времени, p95). USE для ресурсов: Utilization (занятость), Saturation (очередь, ожидание), Errors.

Порядок такой. Сначала RED верхнего уровня: болит ли пользователь, то есть растут ли ошибки и задержка. Потом USE: какой ресурс перегружен. Попробуй сам.

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

Прикинь сам: p95 вырос с 0,3 до 2 с, доля ошибок 0%, CPU 30%. Что проверишь первым?

Ресурс не перегружен, пользователь страдает, а значит, система чего-то ждёт: пул соединений (shop_db_pool_waiting) или внешний вызов оплаты. Осторожно: «CPU в норме, значит, всё хорошо» неверно, бывают задержки без загрузки процессора.

Главное: сначала RED (болит ли пользователь), потом USE (какой ресурс виноват).

Рамка есть, теперь запросы, которые просят написать.

Как писать PromQL вслух

Просят «напиши запрос», и главное не молчать. Говори по шагам: «Метрика такая, это счётчик, значит, беру rate за пять минут. Нужны ошибки, фильтрую по метке status. Суммирую по маршруту». Частые ошибки: rate от гистограммы без histogram_quantile; sum до rate (после перезапуска одного экземпляра сумма «проваливается», и rate принимает это за сброс: сначала rate, потом sum); забытое by (le) в квантиле. Проговаривание показывает, что ты понимаешь, а не вспоминаешь шаблон.

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

# RPS по маршрутам
sum by (route) (rate(http_requests_total[5m]))

# Доля ошибок 5xx
sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m]))

# p95 задержки
histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

# Очередь за соединением БД
shop_db_pool_waiting

rate(...[5m]) берёт счётчик за пять минут и делает скорость в секунду. sum by (route) складывает серии, оставляя метку route. Выражение 5.. в status=~ ловит три символа, начинающиеся с пятёрки. В histogram_quantile корзины (бакеты) складываются по метке le, иначе квантиль считать не из чего.

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

Запросы есть, значит, можно решать, на какие из них вешать алерты.

Алерты: симптом или причина

Тебя спросят: «Какие алерты ты поставишь на сервис?» Хороший ответ различает симптомные алерты (пользователь страдает: ошибки, задержка) и причинные (ресурс подходит к пределу: пул, диск, память). Симптомные будят человека, причинные чаще предупреждают днём. Пример на «Магазине»:

Алерт	Тип	Условие	for	Реакция
Доля 5xx выше 5%	симптом	sum(rate(...{status=~"5.."}[5m])) / sum(rate(...[5m])) > 0.05	2 мин	Страница дежурному
p95 каталога выше 1 с	симптом	histogram_quantile(...) > 1	5 мин	Страница
Очередь за пулом растёт	причина	shop_db_pool_waiting > 0	1 мин	Сообщение в канал
Оплата медленнее 1 с	причина	p95 shop_payment_duration_seconds выше 1 с	5 мин	Сообщение в канал

Параметр for задаёт, сколько условие должно держаться, прежде чем алерт сработает. Очередь пула сама не «мигает», ей хватает минуты, а задержка и доля ошибок скачут, им нужно две-пять. Он убирает ложные срабатывания от коротких всплесков. Слишком длинный for задерживает обнаружение, слишком короткий превращает алерт в шум. Хороший алерт отвечает дежурному на четыре вопроса: что случилось, кого касается, куда смотреть, что делать (ссылка на инструкцию).

Осторожно: «много алертов значит надёжно». Много алертов дают усталость от алертов (alert fatigue): люди перестают реагировать. Пять осмысленных лучше пятидесяти шумных.

Главное: будят людей симптомами, а причины идут днём и в канал.

Остаётся ловушка, на которой проверяют опыт.

Кардинальность и три источника сигнала

Добавь метку user_id в счётчик запросов при миллионе пользователей, и Prometheus заведёт миллион серий и упрётся в память. Кардинальность (cardinality) это число уникальных сочетаний значений меток. Поэтому в метках держат ограниченные значения (route, method, status), а идентификаторы живут в логах и трассах.

Три источника дополняют друг друга. Метрики отвечают «сколько и когда» и годятся для алертов. Логи отвечают «что именно произошло» с конкретным запросом. Трассы показывают путь запроса через сервисы и время на каждом участке (урок 7.7). Хороший ответ их связывает: по метрике видишь рост ошибок, по логам с request_id находишь запросы, а по trace_id из лога открываешь трейс.

Главное: в метках только ограниченные значения, идентификаторы идут в логи и трассы.

Теперь самый частый вопрос: расскажи про инцидент.

Как рассказывать про инцидент

«Расскажи про сбой, который ты разбирал»: у тебя есть материал из урока 13.1. Схема: что видели (симптом с цифрой), как нашли причину (метрики, потом логи), что сделали (сначала смягчение, потом исправление), чему научились (действия постмортема). Рассказывай без обвинений: «замедлилась оплата», а не «кто-то сломал». Это тоже проверка зрелости.

Распродажа близко, и я прошу тебя повторить эту схему вслух на своём инциденте, пока не уложишься в две минуты. Отдельно считай блок задач: если «плывёшь» в PromQL, вернись к уроку 7.2 и напиши десять запросов руками на живом Prometheus.

Вопросы по мониторингу, таймер 40 секунд: ответы чуть длиннее, чем в нагрузочных.

Практика

1. Файл самооценки

cd ~/perf-lab/13-final
cat > mock-monitoring.md <<'EOF'
# Самооценка: собеседование по мониторингу

Шкала: 2 = уверенно за 30-90 с с цифрой, 1 = путался, 0 = не смог.

| Блок | Вопросы | Баллы | Что повторить |
| --- | --- | --- | --- |
| A. Основы метрик | 1-6 | | |
| B. Prometheus и PromQL | 7-12 | | |
| C. Grafana и экспортеры | 13-17 | | |
| D. Логи и алерты | 18-23 | | |
| E. Инциденты и процесс | 24-27 | | |
| F. Задачи | 28-34 | | |
| G. Практика работы | 35 | | |
EOF

2. Шпаргалка запросов: напиши руками

Подними стенд с мониторингом (если не поднят) и открой Prometheus по адресу http://localhost:9090. Запусти нагрузку на минуту, чтобы были данные:

cd ~/learning/load-tester/project/shop && docker compose --profile monitoring up -d --wait
source ~/perf-lab/.venv/bin/activate
locust -f ~/perf-lab/09-locust/locustfile.py --host http://localhost:8000 --headless -u 5 -r 1 -t 3m --only-summary

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

cat > ~/perf-lab/13-final/promql-cheatsheet.md <<'EOF'
# PromQL: рабочие запросы по стенду
- RPS по маршрутам: sum by (route) (rate(http_requests_total[5m]))
- Доля 5xx: sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m]))
- p95 задержки: histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))
- Очередь за соединением: shop_db_pool_waiting
- Доля попаданий в кэш: sum(rate(shop_cache_requests_total{result="hit"}[5m])) / sum(rate(shop_cache_requests_total[5m]))
- Оплата, p95: histogram_quantile(0.95, sum by (le) (rate(shop_payment_duration_seconds_bucket[5m])))
EOF

Одиночные фигурные скобки в запросах Jekyll не мешают, а двойных здесь нет. Как читать: если запрос вернул «Empty query result», проверь имя метрики (автодополнение в Prometheus) и окно: за последние секунды данных может быть мало.

Типичные ошибки: parse error: unexpected значит пропущена скобка или кавычка; many-to-many matching not allowed значит при делении двух запросов метки не совпали (добавь sum с by или on(...)); квантиль выдаёт NaN, когда нет запросов в окне.

3. Практическое задание вживую: прочитай дашборд

Открой дашборд Grafana «Магазин: обзор (эталон)» (http://localhost:3000, вход без пароля). Включи вживую нагрузку и измени задержку оплаты (команда из 13.1: curl -X POST ... /admin/config с delay_ms). Затем без бумажки, вслух, как на собеседовании, проговори за 2 минуты: что болит у пользователя (RED), какой ресурс перегружен (USE), чем подтверждаешь, что сделал бы. Запиши себя на диктофон и прослушай.

# вернуть оплату в норму после упражнения
curl -s -X POST http://localhost:8001/admin/config -H 'content-type: application/json' -d '{"delay_ms": 50, "fail_rate": 0}'

4. Разбери плохой алерт

Задание: ниже описание алерта «из прошлой жизни». Найди проблемы и перепиши:

Алерт «CPU высокий»: node_cpu загружен выше 70% в течение 10 секунд. Шлёт в личку всем 12 инженерам. Описание: «CPU».

Проблемы: условие причинное, а не симптом, без for нормального (10 секунд это шум), нет понятия «что делать», описание пустое, получатели все сразу. Исправление: основной алерт на симптом (доля 5xx или p95), CPU как предупреждение с for: 15m в канал, в аннотации ссылка на инструкцию и дашборд, маршрутизация на дежурного. Напиши свою версию в mock-monitoring.md.

5. Пройди банк вопросов

Дальше идёт банк. Проговаривай вслух, потом сверяйся. Отмечай баллы. Два-три блока за сессию.

6. Итоговая сессия

Через день-два сделай сессию на время: десять случайных вопросов виджетом, по 40 секунд, и запиши итог:

echo "$(date +%F): сессия на время, мониторинг, знал 8 из 10, слабое: кардинальность" >> ~/perf-lab/13-final/mock-monitoring.md

Сломай и почини

1. Молчаливый алерт. Создай правило, которое никогда не срабатывает: в запросе опечатка в имени метрики (http_request_total вместо http_requests_total). Правило в Prometheus будет «здорово», алерта нет. Урок: алерт, который не срабатывает, не отличить от здоровой системы. Лечение: тест правила на заведомо плохих данных и алерт на отсутствие метрики (absent(...)).
2. Ложные срабатывания. Поставь порог p95 на 100 мс с for: 0. Запусти нагрузку: правило будет мигать при каждом всплеске. Подними for до 5 минут и сравни: шум пропал, обнаружение задержалось ровно на пять минут. Это и есть компромисс.
3. Взрыв кардинальности. В тетради посчитай: метрика с метками route (10 значений), method (3), status (5): до 150 серий, нормально. Добавь метку user_id (1000 пользователей): 150 000 серий. Объясни вслух, почему это плохо и где хранить идентификаторы.
4. Путаница rate и значения. Построй график http_requests_total без rate: счётчик растёт монотонно и ничего не говорит. Оберни в rate(...[5m]) и сравни. Запомни: счётчик без rate смотрят редко.

Сначала сам прочти график или ответ вслух по схеме урока, потом попроси нейросеть задать уточняющие вопросы интервьюера. Её эталонный ответ сверь с теорией курса и со своими запросами в Prometheus.

ИИ в помощь

Нейросеть хороша как тренажёр и проверяющий запросов PromQL, но эталонные ответы у неё бывают ошибочными. Общие правила: ИИ-помощник.

Задача: провести пробное собеседование по мониторингу.

Ты технический интервьюер на позицию junior-инженера по мониторингу. Я знаю: метрики и их типы, Prometheus и PromQL,
Grafana, Loki, алерты, SLO, кардинальность меток. Задавай по одному вопросу, потом давай разбор: что было верно,
чего не хватило, и одно уточнение. Включи две задачи на запрос PromQL и одну на чтение графика
(опиши график словами). После 8 вопросов дай итог по шкале 0-1-2 по каждому блоку.

Проверь ответ: все запросы из «правильных» ответов выполни в Prometheus на стенде. Типичные ошибки: rate() от значения, которое не счётчик, histogram_quantile без by (le), придуманные имена метрик и устаревшее «Grafana 8» в описании интерфейса.

Задача: пересказать собственный разбор инцидента для собеседования.

Вот краткий конспект моего разбора учебного инцидента: <вставь 5-8 строк: симптом, как нашёл, причина, исправление, урок>.
Задай мне вопросы, как скептичный интервьюер, чтобы найти пробелы. Не придумывай деталей, которых нет в конспекте,
и не называй причину за меня.

Проверь ответ: ответь на вопросы вслух, и если не нашлось ответа в твоих данных, вернись к уроку 13.1 и дополни конспект. Типичная ошибка: слишком общие вопросы без привязки к твоему случаю.

Данные реальных рабочих систем в тренировку не вставляй: на собеседовании о прошлой работе говори в общих чертах.

Словарик урока

Термин	Простыми словами
Инженер мониторинга	Специалист, который строит и поддерживает сбор метрик, дашборды и алерты.
RED	Три показателя сервиса: запросы, ошибки, время.
USE	Три показателя ресурса: занятость, очередь, ошибки.
Кардинальность	Число уникальных серий метрики; растёт с числом значений меток.
Симптомный алерт	Срабатывает, когда страдает пользователь (ошибки, задержка).
Причинный алерт	Срабатывает, когда ресурс подходит к пределу; предупреждает заранее.
for	Время, которое условие алерта должно держаться до срабатывания.
Alert fatigue	Усталость от шумных алертов, из-за которой их перестают замечать.
Тишина (silence)	Временное подавление алерта в Alertmanager, например на время работ.
Runbook	Инструкция дежурного для типового алерта.

Вопросы с собеседований

Раздел для повторения: ответь вслух, потом открой ответ. Блоки идут от простого к сложному; блок F это задачи. Баллы записывай в mock-monitoring.md.

Блок A. Основы метрик

1. [junior] [часто] Какие типы метрик есть в Prometheus?

Ответ

Counter (только растёт: запросы, ошибки), gauge (растёт и падает: память, очередь), histogram (распределение по бакетам: время ответа) и summary (квантили на стороне приложения). Для задержек обычно берут гистограмму, потому что её можно агрегировать по сервисам.

Что хотят услышать: четыре типа с примерами и применение.

Красный флаг: «метрики бывают числовые и текстовые».

2. [junior] [часто] Чем метрики отличаются от логов и трасс?

Ответ

Метрики: числа во времени, дёшево, для алертов и трендов. Логи: события с деталями, для разбора конкретного случая. Трассы: путь одного запроса через сервисы со временем на каждом участке. Дополняют друг друга: по метрике вижу, что ошибки выросли, по логам с request_id читаю причину, по trace_id открываю трейс и вижу, где запрос потерял время.

Что хотят услышать: три источника и связка между ними.

Красный флаг: «логи заменяют метрики».

3. [junior] Что такое label?

Ответ

Пара «ключ=значение», которая делит метрику на серии: http_requests_total{route="/api/orders", status="200"}. Позволяет фильтровать и группировать. Важно держать набор значений ограниченным.

Что хотят услышать: пример и осторожность с количеством значений.

Красный флаг: метка с идентификатором пользователя.

4. [junior] Что такое кардинальность и чем она опасна?

Ответ

Число уникальных серий метрики. Если в метку попадают значения с неограниченным набором (id пользователя, адрес), серий становятся миллионы, Prometheus упирается в память и замедляется. Идентификаторы хранят в логах и трассах.

Что хотят услышать: пример и последствие.

Красный флаг: не знать понятия.

5. [junior] Pull или push: как Prometheus получает метрики?

Ответ

Pull: Prometheus сам ходит за метриками на /metrics с интервалом (scrape interval). Плюс: сразу видно, что цель недоступна (метрика up равна 0). Push нужен для коротких заданий, которые не успеют быть опрошены (Pushgateway).

Что хотят услышать: модель pull и метрика up.

Красный флаг: «приложение само отправляет метрики».

6. [на скорость] Что такое scrape interval?

Ответ

Как часто Prometheus забирает метрики: в нашем стенде 5 секунд. От него зависит, насколько мелкие события видны и какое окно брать для rate.

Что хотят услышать: период опроса и связь с окном.

Красный флаг: «секунд сколько хватит».

Блок B. Prometheus и PromQL

7. [junior] [часто] Что делает функция rate и когда она нужна?

Ответ

Берёт счётчик за окно и считает скорость роста в секунду. Нужна, потому что сам счётчик монотонно растёт и ничего не говорит. Пример: rate(http_requests_total[5m]) даёт запросы в секунду за последние пять минут.

Что хотят услышать: смысл и пример.

Красный флаг: строить график счётчика без rate.

8. [junior] Как посчитать долю ошибок?

Ответ

Делю скорость ошибочных запросов на скорость всех: sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])). Регулярное выражение 5.. берёт статусы 5xx.

Что хотят услышать: деление двух rate, фильтр по статусу.

Красный флаг: делить счётчики без rate.

9. [middle] [часто] Как посчитать p95 задержки из гистограммы?

Ответ

histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m]))). Сначала rate по бакетам, затем суммирование с сохранением метки le, затем квантиль. Точность зависит от границ бакетов: p95 не может быть точнее ширины бакета.

Что хотят услышать: порядок rate, sum by (le), квантиль, ограничение точности.

Красный флаг: забыть by (le).

10. [middle] Чем sum by отличается от sum without?

Ответ

sum by (route) оставляет только перечисленные метки и складывает остальное. sum without (instance) убирает перечисленные и оставляет все остальные. Выбор зависит от того, что короче: перечислить нужное или лишнее.

Что хотят услышать: различие и пример.

Красный флаг: считать их синонимами.

11. [middle] Чем rate отличается от irate и increase?

Ответ

rate: средняя скорость за окно, гладкая, подходит для алертов и графиков. irate: скорость по последним двум точкам, резкая, для быстрых колебаний. increase: прирост за окно (в штуках, а не в секунду).

Что хотят услышать: три функции и когда какая.

Красный флаг: использовать irate в алертах.

12. [на скорость] Что показывает метрика up?

Ответ

1, если Prometheus успешно забрал метрики с цели, 0, если нет. Основа проверки «живы ли источники».

Что хотят услышать: смысл 0 и 1.

Красный флаг: «аптайм сервиса».

Блок C. Grafana и экспортеры

13. [junior] Что такое экспортер и зачем он?

Ответ

Программа, которая берёт данные из системы, не умеющей отдавать метрики Prometheus (ОС, база), и публикует их на /metrics. Примеры из стенда: node-exporter (хост), cAdvisor (контейнеры), postgres-exporter (база).

Что хотят услышать: назначение и примеры.

Красный флаг: «плагин Grafana».

14. [junior] Как выбрать, какие панели нужны на дашборде?

Ответ

По RED для сервиса (запросы, ошибки, p95) и USE для ресурсов (CPU, память, пул БД). Сверху то, что болит у пользователя, ниже причины. Каждая панель отвечает на вопрос, а не просто «красиво».

Что хотят услышать: рамка и порядок.

Красный флаг: «все метрики, какие есть».

15. [middle] Чем опасно среднее на дашборде?

Ответ

Прячет хвост: p95 может быть в разы хуже среднего. Для задержек показываю p50, p95, p99. Для ресурсов смотрю пики, а не только среднее по окну.

Что хотят услышать: пример, перцентили.

Красный флаг: «среднее достаточно».

16. [middle] Что значит «дашборд врёт»?

Ответ

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

Что хотят услышать: список причин и проверка.

Красный флаг: «цифрам с дашборда верю всегда».

17. [на скорость] Что такое переменная дашборда?

Ответ

Список значений (сервис, маршрут), которым переключается дашборд без правки запросов.

Что хотят услышать: переиспользование дашборда.

Красный флаг: «настройки интерфейса».

Блок D. Логи и алерты

18. [junior] [часто] Какие алерты ты поставишь на веб-сервис?

Ответ

Симптомные: доля 5xx выше порога и p95 выше SLO, с for несколько минут, будят дежурного. Причинные: очередь за пулом, оплата медленнее нормы, диск и память, уходят в канал. Плюс алерт на живость целей (up).

Что хотят услышать: разделение симптом и причина, for.

Красный флаг: «CPU выше 80%» как единственный алерт.

19. [junior] Что делает параметр for?

Ответ

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

Что хотят услышать: компромисс.

Красный флаг: «не нужен».

20. [middle] Зачем нужен Alertmanager?

Ответ

Группирует похожие алерты в одно сообщение, подавляет дубли, маршрутизирует по командам и каналам, поддерживает тишину и подавление (inhibition: не слать «сервис не отвечает», если уже сработал «сервер недоступен»).

Что хотят услышать: группировка, маршрутизация, тишина.

Красный флаг: «просто отправляет письма».

21. [middle] Что такое alert fatigue и как с ней бороться?

Ответ

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

Что хотят услышать: признаки и меры.

Красный флаг: «больше алертов безопаснее».

22. [middle] Как ты ищешь причину по логам в Loki?

Ответ

Сужаю по меткам ({service="shop", level="ERROR"}), по времени из метрики, потом по request_id смотрю цепочку одного запроса. Для всплеска считаю частоту сообщений. Из логов читаю точный текст ошибки, например про исчерпанный пул.

Что хотят услышать: метки, время, request_id.

Красный флаг: «открываю файл и читаю всё».

23. [на скорость] Что должно быть в описании хорошего алерта?

Ответ

Что случилось, кого касается, куда смотреть (ссылка на дашборд), что делать (ссылка на инструкцию).

Что хотят услышать: четыре пункта.

Красный флаг: «название алерта».

Блок E. Инциденты и процесс

24. [middle] [часто] Расскажи, как ты разбирал инцидент.

Ответ

По схеме: что видели (симптом с цифрой), как нашли причину (метрики, логи), что сделали (смягчение, затем исправление), чему научились (действия постмортема с владельцами). Без поиска виноватых: «замедлилась оплата, пул исчерпался, нет алерта на очередь».

Что хотят услышать: хронология, цифры, действия, культура без обвинений.

Красный флаг: «нашёл виноватого».

25. [middle] С чего начнёшь, если ночью сработал алерт?

Ответ

Оцениваю влияние на пользователя (RED), выбираю смягчение, если оно безопасно (откат, отключение функции), сообщаю статус, ищу причину по метрикам и логам. Причину не называю, пока она не подтверждена. Записываю хронологию по ходу.

Что хотят услышать: сначала влияние и смягчение, потом причина.

Красный флаг: «сразу лезу в код».

26. [middle] Что такое SLO и бюджет ошибок?

Ответ

SLO это цель по качеству (например, 99,5% успешных запросов). Бюджет ошибок это допустимая доля сбоев (0,5%). Если бюджет израсходован, приоритет сдвигается к надёжности, а не новым функциям.

Что хотят услышать: связь с решениями.

Красный флаг: путать с SLA как с юридическим договором без пояснения.

27. [на скорость] Что такое runbook?

Ответ

Инструкция дежурного для типового алерта: что значит, куда смотреть, что делать, кому эскалировать.

Что хотят услышать: практичность.

Красный флаг: «описание проекта».

Блок F. Задачи

28. [middle] Задача: напиши запрос RPS по маршрутам за 5 минут.

Ответ

sum by (route) (rate(http_requests_total[5m])). Проговариваю: счётчик, значит rate по окну пять минут, суммирую по маршрутам.

Что хотят услышать: rate, sum by, пояснение по шагам.

Красный флаг: sum вместо rate.

29. [middle] Задача: напиши запрос доли попаданий в кэш.

Ответ

sum(rate(shop_cache_requests_total{result="hit"}[5m])) / sum(rate(shop_cache_requests_total[5m])). Если доля падает, кэш не помогает: проверяю ключи и время жизни.

Что хотят услышать: деление двух rate.

Красный флаг: брать значения счётчиков без rate.

30. [middle] Задача: p95 вырос, ошибок нет, RPS стал меньше. Что скажешь?

Ответ

Признаки зависимости или очереди: запросы стоят и ждут, поэтому RPS падает. Проверю панель оплаты (shop_payment_duration_seconds), shop_db_pool_waiting, запросы в работе (http_requests_in_progress). Ошибок нет, потому что до таймаута не дошло.

Что хотят услышать: вывод из сочетания, список проверок.

Красный флаг: «добавить серверов».

31. [middle] Задача: при 20 RPS соединение занято 0,5 с, в пуле 5. Хватит ли пула?

Ответ

Пропускная способность пула 5 / 0,5 = 10 в секунду. Приходит 20, значит нет: очередь растёт. Нужно уменьшить время удержания, увеличить пул (проверив лимит базы) или ограничить поток. Алерт поставлю на shop_db_pool_waiting.

Что хотят услышать: закон Литтла, число, варианты.

Красный флаг: «пул хватит, 5 больше 0,5».

32. [middle] Задача: алерт срабатывает каждые 10 минут и сам проходит. Что делаешь?

Ответ

Смотрю график метрики за сутки: это настоящий всплеск или шум? Если шум, увеличиваю for и проверяю окно rate. Если настоящий, ищу причину периодичности (задание по расписанию, сборка мусора). Если алерт не требует действий, превращаю его в предупреждение или убираю.

Что хотят услышать: анализ данных, а не «заглушить».

Красный флаг: «просто отключу».

33. [middle] Задача: нужно измерять время запроса по пользователям. Предлагают метку user_id. Что ответишь?

Ответ

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

Что хотят услышать: расчёт серий, альтернатива.

Красный флаг: «добавить метку и всё».

34. [middle] Задача (разбор отчёта): отчёт показывает среднюю задержку 120 мс и вывод «всё хорошо». Что скажешь?

Ответ

Среднее прячет хвост. Попрошу p95 и p99, распределение по маршрутам и ошибки. Если p95 около секунды, каждый двадцатый запрос медленный, хотя среднее красивое. Вывод по среднему недоказателен.

Что хотят услышать: перцентили, запрос данных.

Красный флаг: «среднее 120 мс, значит всё хорошо».

Блок G. Практика работы

35. [junior] Как ты используешь ИИ в работе с мониторингом?

Ответ

Как помощника для черновиков и объяснений: просить разобрать незнакомую метрику или ошибку, набросать запрос PromQL или правило алерта, найти слабые места в тексте runbook. Всегда даю контекст: версию, список реальных имён метрик, точный вывод. Секреты, токены и данные пользователей в запрос не попадают. Ответ проверяю в Prometheus: запрос должен вернуть ряд, а имя метрики существовать (нейросети любят придумывать имена). Алерт проверяю через promtool check rules и на тестовой нагрузке. Что не понимаю, не внедряю.

Что хотят услышать: конкретные задачи, проверка запросов на реальных данных, защита данных.

Красный флаг: внедрить запрос или алерт из ответа без проверки, вставка рабочих логов и токенов в публичный чат.

Проверено на версиях

Prometheus 3.15, Alertmanager 0.34, Grafana 13.2, Loki 3.7, стенд «Магазин» из project/shop. Запросы проверяй на своём стенде: имена метрик взяты из project/shop/README.md. Октябрь 2026.

Итог урока: ты умеешь

• Отвечать на вопросы по метрикам, Prometheus и алертам вслух за 30-90 секунд.
• Читать дашборд по рамкам RED и USE и проговаривать вывод.
• Написать по памяти запросы: RPS, доля ошибок, p95, доля попаданий в кэш.
• Различать симптомные и причинные алерты и объяснять for.
• Объяснить кардинальность и почему идентификатор пользователя нельзя в метку.
• Рассказать про разбор инцидента без поиска виноватых.
• Оценить себя по шкале 0-1-2 и составить план повторения.
• Использовать нейросеть как интервьюера и проверять её запросы PromQL в Prometheus.

Ты прошёл курс. Дальше: возвращайся к слабым блокам, повторяй вслух, выполняй тестовые задания и откликайся на вакансии. Возвращайся на главную страницу курса.

Проверь себя

Короткий тест по уроку: 10 вопросов из банка в 40. Засчитывается только полностью правильный ответ, порог 60%. Каждая новая попытка даёт другие вопросы, пока банк не закончится. Ответы видны после проверки.

Тест работает с включённым JavaScript.

тема 13 урок 13.5 2 ч курс 0/0 ← → уроки