Метрики, логи, трейсы, SLI/SLO и разбор инцидента

Завершающий блок собеседования уровня senior: как вы понимаете, что система здорова, и что делаете, когда это не так.

Вопрос: «Чем метрики отличаются от логов и трейсов? Что такое SLO и error budget? И расскажите про инцидент, который вы разбирали.»

Что на самом деле проверяет интервьюер

Здесь оценивают зрелость. Junior отвечает «настроил Prometheus и Grafana». Senior объясняет, какой вопрос решает каждый инструмент, умеет договариваться с бизнесом о допустимом уровне отказа через SLO и рассказывает про инцидент без поиска виноватых. Последний пункт — важнейший маркер культуры: обвинение конкретного человека в постмортеме почти всегда закрывает кандидату дорогу в зрелую команду.

Три столпа наблюдаемости

Метрики — агрегированные числовые ряды с метками (http_requests_total{status="500"}). Дёшевы, хранятся долго, годятся для алертов и трендов. Но по метрике нельзя узнать, что случилось с конкретным пользователем.

Логи отвечают именно на этот вопрос, но дороги. Практика: структурированный JSON вместо свободного текста, обязательный request_id в каждой строке, разумные уровни (не писать INFO на каждый шаг цикла) и раздельный срок хранения — ошибки дольше, отладочные записи короче.

Трейсы показывают путь запроса через все сервисы со временем на каждом участке. Незаменимы в микросервисах, где «медленно» может означать четвёртый вызов из семи. Обычно используется сэмплирование: например, 1% обычных запросов и 100% ошибочных.

Полезно назвать и две классические схемы алертов: USE (Utilization, Saturation, Errors) для ресурсов и RED (Rate, Errors, Duration) для сервисов. И отдельно — важность связки: по метрике находим момент и сервис, по трейсу — конкретный узкий участок, по логам с тем же request_id — точную причину.

SLI, SLO и error budget

• SLI (indicator) — измеряемая величина, отражающая опыт пользователя: доля успешных запросов, доля запросов быстрее 300 мс.
• SLO (objective) — целевое значение SLI на окне времени: «99.9% запросов успешны за 30 дней».
• SLA — договор с клиентом с финансовыми последствиями. Внутренние SLO всегда строже SLA.
• Error budget — обратная сторона SLO: 99.9% за 30 дней означает примерно 43 минуты допустимой неготовности в месяц.

Ценность error budget в том, что он превращает надёжность из спора в арифметику. Бюджет не израсходован — команда катит фичи быстрее и смелее экспериментирует. Бюджет исчерпан — выкатки замораживаются, и приоритет уходит на устойчивость. Это готовый ответ на вечный конфликт «нам нужно быстрее» против «нам нужно надёжнее».

Второй практический эффект — алертинг по симптомам, а не по причинам. Будить дежурного из-за 85% CPU бессмысленно: пользователи этого не чувствуют. Будить нужно, когда горит SLO — растёт доля ошибок или деградировала задержка. Хорошая практика — алерты на скорость сжигания бюджета (burn rate): быстрый расход поднимает дежурного немедленно, медленный создаёт задачу на разбор в рабочее время.

groups:
  - name: slo
    rules:
      - alert: HighErrorBudgetBurn
        expr: |
          sum(rate(http_requests_total{status=~"5.."}[5m]))
            / sum(rate(http_requests_total[5m])) > 0.014
        for: 5m
        labels:
          severity: page
        annotations:
          summary: "Быстрое сжигание error budget: доля 5xx выше порога"
          runbook: "https://wiki.internal/runbooks/api-5xx"

Разбор инцидента

Рассказ про инцидент стоит строить по чёткой схеме — так вы демонстрируете процесс, а не только историю.

1. Обнаружение. Как узнали: сработал алерт по SLO или пожаловались пользователи. Второй вариант — сам по себе повод для действия.
2. Смягчение раньше расследования. Первая задача — вернуть сервис, а не понять причину. Откат, переключение трафика, отключение фичи флагом. Разбор — потом, по логам и метрикам.
3. Роли и коммуникация. Есть командир инцидента, который координирует и не лезет чинить руками; есть отдельный человек для общения со стейкхолдерами. Ход событий пишется в общий канал — это и координация, и готовая хронология.
4. Постмортем без поиска виноватых. Хронология, влияние в цифрах (сколько минут, сколько запросов, сколько пользователей), корневые причины через «пять почему», список конкретных действий с ответственными и сроками.
5. Проверка на повторяемость. Хороший постмортем отвечает не только «почему сломалось», но и «почему мы узнали об этом от пользователя через 20 минут» и «почему откат занял 15 минут».

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

Типичные ошибки кандидатов

• Ставят знак равенства между мониторингом и «настроил Grafana», не объясняя, какие вопросы решают метрики, логи и трейсы.
• Алертят на причины (CPU, память, диск) вместо симптомов, ощущаемых пользователем.
• Не различают SLO и SLA и не знают, что такое error budget.
• Пишут неструктурированные логи без request_id — сквозная трассировка становится невозможной.
• В рассказе про инцидент начинают с «разработчик выкатил плохой код», выдавая культуру поиска виноватых.
• Сначала расследуют, потом чинят — вместо того чтобы сначала вернуть сервис.

Как ответить кратко (20–30 секунд)

«Метрики дёшевы и отвечают на вопрос «что и когда сломалось», логи дороги и отвечают «что именно произошло в этом запросе», трейсы показывают, где в цепочке сервисов теряется время; связываю их через request_id. SLI — измеряемая величина вроде доли успешных запросов, SLO — цель по ней на окне, а error budget — допустимый остаток отказа: при 99.9% за месяц это около 43 минут. Бюджет превращает спор о надёжности в арифметику: исчерпали — замораживаем фичи. Алерчу по симптомам и скорости сжигания бюджета, а не по загрузке CPU. В инциденте сначала смягчение — откат или флаг, потом расследование, и постмортем без поиска виноватых: если один клик роняет прод, проблема в процессе, а не в человеке.»