non-functionalobservabilitymonitoringsloqa

Observability для QA: логи, метрики, трейсы — что проверять и как пользоваться

«Баг воспроизводится только на проде раз в сутки и только у части пользователей». Без наблюдаемости (observability) такой баг — это часы гадания. С ней — несколько минут: открыл трейс упавшего запроса, увидел, на каком сервисе и почему отвалилось. Observability — это не «про DevOps», это рабочий инструмент QA. Разберём три столпа, как тестировать саму наблюдаемость, и как ею пользоваться в работе.

Три столпа: логи, метрики, трейсы

Канонический разбор — у Peter Bourgon и в документации OpenTelemetry. Коротко и по-QA-шному:

  • Логи — дискретные события («что случилось в этот момент»): ошибка, вход в функцию, отказ внешнего вызова. Хороши для деталей конкретного инцидента. Должны быть структурными (JSON), а не «простыня текста».
  • Метрики — числовые агрегаты во времени («сколько и как быстро»): RPS, error rate, перцентили latency, очереди, использование ресурсов. Дёшевы, хороши для трендов и алертов.
  • Трейсы — путь одного запроса сквозь все сервисы («где именно потратилось время и где упало»). Незаменимы в распределённых системах: показывают всю цепочку A→B→C с таймингами каждого шага.

Правило: метрика говорит что что-то не так, трейс — где, лог — почему.

Тестировать саму наблюдаемость

Наблюдаемость — это фича, и её тоже тестируют. Что проверять:

  • При ошибке реально пишется лог нужного уровня с контекстом (что за операция, id сущности, причина), а не «тихо проглочено».
  • Есть сквозной correlation/trace id: один запрос можно проследить через все сервисы по одному идентификатору.
  • Ключевые бизнес- и тех-события порождают метрики (успех/ошибка/латентность), и они растут на дашборде, когда ты гоняешь сценарий.
  • ⚠️ В логи/трейсы не утекают секреты и PII: пароли, токены, номера карт, персональные данные замаскированы. Это частый и дорогой баг — проверять отдельно.
  • Уровни логирования осмысленны: ERROR — то, что требует реакции; WARN — подозрительное; INFO — бизнес-события; DEBUG — детали. На проде не сыпет DEBUG’ом в гигабайтах.
  • Алерт реально срабатывает на смоделированную проблему (подними error rate в тесте — прилетел ли алерт).

Как QA пользуется observability в работе

  • Локализовать распределённый баг: по trace id видно, на каком из 5 сервисов запрос упал или завис — не нужно гадать и дёргать всех разработчиков.
  • Воспроизвести по логам: структурные логи с контекстом дают точные входные данные и последовательность, при которых баг случился.
  • Ловить тихие деградации: функционально всё «работает», но p99 latency вырос вдвое или error rate пополз вверх — это видно только в метриках, не в ручном клике.
  • Проверять после релиза: сравнить дашборды до/после деплоя — не выросли ли ошибки/латентность (часть приёмки на проде, канарейка).
  • Подтверждать баг данными: не «кажется, тормозит», а «p95 чекаута 4.2с при SLO 1с, вот график» — баг-репорт с метрикой не оспоришь.

SLI / SLO / error budget

Из Google SRE Book. Это язык, на котором команда договаривается, что такое «достаточно надёжно»:

  • SLI — метрика-индикатор (например, доля запросов быстрее 300мс, доля успешных ответов).
  • SLO — целевое значение SLI (например, 99.9% запросов < 300мс за 30 дней).
  • Error budget — допустимый «бюджет» нарушений (0.1% = сколько можно ошибаться). Пока бюджет есть — катим фичи; бюджет исчерпан — стоп, чиним надёжность.

Для QA это конкретные критерии приёмки нефункциональных требований: не «должно быть быстро», а «p95 < 300мс при заданной нагрузке». Проверяемо.

Подводные камни

  • Кардинальность метрик: тег с высокой кардинальностью (user_id, request_id в метках метрики) взрывает хранилище и счёт. Высокая кардинальность — в логи/трейсы, а не в метки метрик.
  • Шумные алерты: если алертит на всё — на это перестают реагировать (alert fatigue). Алерты — на симптомы для пользователя (SLO-нарушения), а не на каждый чих CPU.
  • Логи без структуры: по «простыне» текста нельзя фильтровать и агрегировать. Только структурные (key-value/JSON).
  • Семплирование трейсов: на проде трейсы часто семплируются (например, 1%) — редкий баг может не попасть в выборку; знать это при расследовании.

Чек-лист «observability-ready фича» (для приёмки)

  • Ошибки логируются с уровнем ERROR и контекстом (операция, id, причина)
  • Сквозной correlation/trace id проходит через все вовлечённые сервисы
  • Ключевые события дают метрики: счётчик успехов/ошибок + латентность
  • Заданы SLI/SLO для критичного пути + проверяемый порог (например, p95 < N мс)
  • Секреты и PII не попадают в логи/трейсы (проверено явно)
  • Уровни логирования корректны, на проде нет DEBUG-спама
  • Есть алерт на нарушение SLO, и он реально срабатывает на смоделированной проблеме
  • Метки метрик без высокой кардинальности (нет user_id/request_id в labels)
  • Дашборд показывает фичу: можно увидеть её трафик/ошибки/латентность

Итог. Observability — это рычаг для QA: метрика показывает что не так, трейс — где, лог — почему. Тестируйте саму наблюдаемость (логи, trace id, метрики, отсутствие PII в логах) как полноценную часть фичи и пользуйтесь ею, чтобы локализовать распределённые баги, ловить тихие деградации и подтверждать находки данными, а не ощущениями.

Источники: Google SRE Book — Service Level Objectives, OpenTelemetry — Signals (logs/metrics/traces), Peter Bourgon — Metrics, tracing, and logging.