11 вопросов по теме «DevOps: Наблюдаемость и SRE» на собеседовании

Короткий ответ: SLI — измеряемый показатель: доля хороших событий от всех. SLO — внутренняя цель по SLI на окне (99.9% за 30 дней). SLA — внешний контракт с клиентом, где за нарушение платят штрафами. Error budget = 1 − SLO: доля «разрешённых» ошибок, которую можно тратить.

Подробно:

SLO 99.9% за 30 дней: 30 × 24 × 60 = 43 200 мин
бюджет = 0.1% × 43 200 ≈ 43.2 мин даунтайма в месяц
SLO 99.99%             ≈ 4.4 мин в месяц

SLO всегда строже SLA: внутренняя цель должна срабатывать раньше, чем контрактные штрафы.

⚠️ Частая ошибка: называть SLO и SLA синонимами и не знать цифр. Интервьюер ждёт именно расчёт: 99.9% в месяц ≈ 43 минуты, 99.99% ≈ 4.4 минуты.

Короткий ответ: Error budget — это механизм принятия решений, а не отчётная цифра. Политика согласована с продактами заранее: бюджет исчерпан → feature freeze, приоритет надёжностной работе, гейтинг релизов, пока бюджет не восстановится. Без enforcement всё это — театр.

Подробно:

1. Политика подписана до инцидента — команда и продакт заранее договорились: кончился бюджет — фичи ждут. Спорить в момент исчерпания уже поздно.
2. Эскалация по остатку бюджета:

3. Надёжность в приоритете — экшены из постмортемов, автоматизация откатов, тесты: то, что реально вернёт бюджет.
4. Восстановление — бюджет считается на скользящем окне (обычно 30 дней): старые ошибки выкатываются из окна, и бюджет отрастает сам.

⚠️ Частая ошибка: отвечать «мы будем стараться лучше». Без заранее согласованных последствий error budget — просто цифра на дашборде, а не контракт между надёжностью и скоростью фич.

Короткий ответ: Пейджить человека нужно тогда, когда страдают пользователи, — то есть по SLI: error rate, латентность. Алерт «CPU 90%» будит дежурного из-за не-проблем и молчит при настоящих: причин у деградации много, а симптом один. Причинные метрики живут на дашбордах — для диагностики.

Подробно:

1. CPU 90% ≠ инцидент — батч-джоб честно утилизирует машину; дежурного разбудили зря.
2. Все хосты зелёные, пользователи страдают — баг в коде, битый конфиг, лёг сторонний API: причинные алерты молчат.
3. Медленный диск, который никому не мешает — если SLI в порядке, это тикет на завтра, а не пейдж в 3 часа ночи.

⚠️ Частая ошибка: алертить на всё «на всякий случай». Итог — alert fatigue: дежурный мьютит канал и пропускает настоящий инцидент.

Короткий ответ: Burn rate — во сколько раз быстрее заложенного вы тратите error budget: фактическая доля ошибок ÷ бюджетная. Burn rate 1 — бюджет израсходуется ровно к концу окна. Алертим по скорости сжигания на нескольких окнах: быстрое горение — пейдж, медленное — тикет. Каждый алерт привязан к математике реального ущерба.

Подробно:

SLO 99.9% за 30 дней → бюджетная доля ошибок 0.1%
burn rate = фактическая доля ошибок / 0.1%
burn 1 → бюджет кончится ровно к концу 30-дневного окна

пейдж:  burn 14.4× на окне 1 ч
        сожжено 14.4 × (1 ч / 720 ч) = 2% месячного бюджета за час
тикет:  burn 6× на окне 6 ч
        сожжено 6 × (6 / 720) = 5% бюджета — медленно, но верно

1. Multi-window, multi-burn-rate — быстрые пожары ловит короткое окно (пейдж), медленные утечки — длинное (тикет); короткое контрольное окно (5 мин) гасит алерт сразу после восстановления.
2. Против статического порога — «error rate > 1%» либо будит на всплеске из десятка запросов, либо неделями молчит, пока утечка съедает бюджет. Burn rate масштабирует срочность от серьёзности сам.
3. Ответ на «почему разбудили?» — в цифрах: «за час сгорело 2% месячного бюджета».

⚠️ Частая ошибка: один порог на все случаи. Быстрый пожар и медленная утечка требуют разных окон и разной срочности реакции.

Короткий ответ: Метрики — дешёвые агрегаты: алертинг и тренды. Логи — дискретные события: форензика конкретного инцидента, дорого на объёме. Трейсы — причинность одного запроса через все сервисы: «куда ушли 2 секунды?». Сигналы связываются через trace ID и exemplars.

Подробно:

1. Начинаем с метрик — алерт по SLI сообщает, что что-то не так.
2. Трейс показывает, где — какой из 12 сервисов добавил 1.8 с из 2.
3. Логи объясняют, почему — стектрейс, конкретный запрос, конкретный пользователь.
4. Корреляция — общий trace ID в логах и exemplars в метриках позволяют прыгать между сигналами, а не сверять таймстемпы глазами.

⚠️ Частая ошибка: «логируем всё — потом разберёмся». На проде это счёт за хранение выше счёта за компьют и grep по терабайтам вместо алерта за секунды.

Короткий ответ: Prometheus сам опрашивает (pull) эндпоинты /metrics у таргетов, найденных через service discovery. Временной ряд = имя метрики + набор лейблов. Счётчики только растут, поэтому смотрим не значение, а скорость: rate() считает прирост в секунду и корректно переживает рестарты.

Подробно:

1. Pull, не push — Prometheus скрейпит таргеты по расписанию: сам факт удачного скрейпа (up == 1) — бесплатный health-check; service discovery (Kubernetes, Consul) находит таргеты автоматически.
2. Модель данных — http_requests_total{method="GET", status="500"}: каждая уникальная комбинация лейблов — отдельный ряд.
3. rate() поверх counter — абсолютное значение счётчика бессмысленно (зависит от аптайма); rate() даёт прирост/с и обрабатывает сброс счётчика на рестарте.

# доля 5xx
sum(rate(http_requests_total{status=~"5.."}[5m]))
  / sum(rate(http_requests_total[5m]))

# p99 из гистограммы
histogram_quantile(0.99,
  sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

4. Окно rate() ≥ 2× интервала скрейпа — иначе в окно попадает меньше двух точек и график дырявый.

⚠️ Частая ошибка: алертить на сырое значение счётчика или брать rate() от gauge. Counter → rate(), gauge → текущее значение/дельта.

Короткий ответ: Кардинальность — число уникальных комбинаций лейблов: каждая комбинация — отдельный временной ряд, живущий в памяти. Память растёт примерно линейно с числом активных серий. Лейбл user_id, полный URL или хэш пода порождает неограниченное число серий — и Prometheus уходит в OOM.

Подробно:

http_requests_total{path="/user/48211/cart", ...}
100 000 юзеров × 5 методов × 10 статусов = 5 000 000 серий
→ память TSDB взрывается, скрейпы тормозят, OOM

1. Правило — перед добавлением лейбла спросить: может ли у него быть 10 000+ значений? Тогда это измерение для трейсов и логов, а не для метрик.
2. Типичные виновники — user_id, session_id, полный путь с параметрами (нормализуйте в /user/:id), IP-адрес, хэш пода в значении лейбла.
3. Диагностика — prometheus_tsdb_head_series и топ метрик по кардинальности через /api/v1/status/tsdb.
4. Когда серий законно много — ответ на масштаб не «ещё один Prometheus», а VictoriaMetrics или Thanos: долгое хранение, глобальный запрос, дедупликация. Частый вопрос на собеседованиях в Avito/Ozon — там это боевой стек.

⚠️ Частая ошибка: лейбл по параметру запроса «чтобы удобнее фильтровать». Одна строка инструментации — и через неделю мониторинг лежит вместе с сервисом.

Короткий ответ: Латентность, трафик, ошибки, насыщение (saturation) — из SRE-книги Google. Этого набора достаточно, чтобы мониторить почти любую user-facing систему. Тонкость: латентность считаем по успешным запросам — ошибки обычно отвечают быстро и «улучшают» среднее.

Подробно:

1. Латентность ошибок — отдельно — быстрый 500-й в общей куче маскирует деградацию: p99 «улучшился», а пользователи страдают.
2. Насыщение смотрит вперёд — опережающий сигнал: очередь растёт сейчас → латентность деградирует через минуты.
3. Это блиц-вопрос — отвечать без паузы; углубляют обычно в латентность и saturation.

⚠️ Частая ошибка: считать латентность по всем запросам вместе с ошибками — быстрые 5xx статистически прячут реальное замедление.

Короткий ответ: Сначала митигировать, потом диагностировать. Корреляция с деплоем очевидна — откатываем релиз, не выясняя root cause: пока вы дебажите, пользователи теряют заказы. Диагноз — после того, как кровотечение остановлено.

Подробно:

0–2 мин    подтвердить: дашборд SLI чекаута, масштаб (все? регион? сегмент?)
2–5 мин    корреляция: деплой 20 мин назад — главный подозреваемый
5–8 мин    ОТКАТ деплоя. Не hotfix, не дебаг — rollback
8–12 мин   проверить восстановление SLI; коммуникация: инцидент-канал,
           статус-пейдж; при крупном масштабе — объявить инцидент
           и раздать роли (IC / comms / ops)
12–15 мин  зафиксировать улики: графики, логи, id релиза — для постмортема

1. Mitigate first — откат почти всегда быстрее и дешевле диагноза; root cause спокойно подождёт до утра.
2. Коммуникация — не опция — молчащий дежурный порождает второй инцидент; таймстемпы в канале потом станут таймлайном постмортема.
3. Сохранить состояние — снять логи и графики до того, как откат сотрёт картину.

⚠️ Частая ошибка: героически дебажить root cause на горящем проде. Интервьюер слушает порядок действий: остановить ущерб → связь → и только потом причина.

Короткий ответ: Blameless — фокус на системе, а не на людях: «человеческая ошибка» — точка, где анализ начинается, а не заканчивается. Полезным его делают конкретные action items с владельцами и дедлайнами, которые реально доезжают до прода, и выводы, расшаренные на всю организацию.

Подробно:

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

3. Полезность = закрытые экшены — трекать их как обычные задачи в спринте; постмортем, после которого ничего не изменилось, — ритуал.
4. Шарить широко — чужой инцидент — самый дешёвый урок для соседней команды.

⚠️ Частая ошибка: «виноват Вася, впредь будет внимательнее» — или 15 экшенов без владельцев. Оба варианта гарантируют повтор инцидента.

Короткий ответ: Toil — операционная работа, которая одновременно: ручная, повторяющаяся, автоматизируемая, тактическая, не создаёт долгосрочной ценности и растёт линейно с ростом сервиса. Google ограничивает toil примерно 50% времени SRE — остальное должно уходить на инжиниринг, который этот toil убивает.

Подробно:

1. Шесть признаков — ручная, повторяющаяся, автоматизируемая, тактическая (реактивная), без устойчивой ценности, масштабируется линейно с ростом. Чем больше совпало, тем чище toil.
2. Сначала измерить — одна-две недели учёта: категории тикетов, время на каждую. Без данных «мы тонем» не превращается в план.
3. Атаковать топ — 2–3 категории обычно дают половину объёма: автоматизация (скрипт вместо ранбука), self-service (кнопка для разработчиков вместо тикета «выдайте доступ»), устранение источника (починить корневой баг).
4. Toil budget как аргумент — «мы тратим 60% времени на toil, вот учёт» — легитимный кейс перед менеджментом, чтобы выделить инженерное время.

⚠️ Частая ошибка: называть toil'ом всю операционную работу. Он-колл и разбор новых инцидентов — не toil: они требуют суждения и создают знание.