Контекст
Observability — это способность судить о внутреннем состоянии системы по её внешним выходным сигналам. Три фундаментальных сигнала — логи, метрики и трейсы — образуют «три столпа», и каждый отвечает на свой вопрос: что произошло, насколько часто и почему именно так. QA-инженер, умеющий читать все три источника, может самостоятельно локализовать дефект до уровня строки кода или конкретного сервиса, не дожидаясь разработчика.
- Логи — текстовые записи событий с меткой времени: ошибки, предупреждения, входные/выходные параметры. Отвечают на вопрос «что произошло?»
- Метрики — числовые агрегаты, собираемые с фиксированным интервалом: CPU, latency p99, error rate. Отвечают на вопрос «как часто и насколько плохо?»
- Трейсы — граф вызовов через несколько сервисов с временными отрезками для каждого span. Отвечают на вопрос «где именно возникла задержка или ошибка?»
- Сигналы взаимодополняют: метрика сигнализирует об аномалии, лог объясняет причину, трейс показывает путь запроса
- Без понимания различий QA тратит часы на чтение нерелевантных логов или интерпретирует метрику как причину, а не симптом
Рабочий алгоритм
Диагностика дефекта начинается с выбора правильного сигнала. Следующий алгоритм позволяет QA-инженеру быстро переключаться между тремя столпами и извлекать максимальную информацию за минимальное время.
- Шаг 1. Зафиксируйте симптом: пользователь получил ошибку, страница медленная, данные некорректные — это определяет стартовый сигнал
- Шаг 2. Откройте дашборд метрик (Prometheus/Grafana): проверьте error rate и latency в момент воспроизведения дефекта
- Шаг 3. Если метрика аномальна — перейдите к логам (Loki/Kibana): отфильтруйте по временному диапазону и уровню ERROR/WARN
- Шаг 4. Найдите trace_id в логе и откройте трейс в Tempo/Jaeger: визуализируйте путь запроса и найдите долгий или упавший span
- Шаг 5. Зафиксируйте все три артефакта в баг-репорте: скриншот метрики, фрагмент лога, ссылку на трейс
- Шаг 6. Воспроизведите сценарий повторно и убедитесь, что паттерн стабильный, а не разовый шум
Пример из практики
Команда выкатила новую версию сервиса оформления заказов. Через 10 минут после деплоя мониторинг зафиксировал рост error rate с 0.1% до 4.7%. QA-инженер открыл Grafana, нашёл временную точку роста метрики, затем в Loki по фильтру `level=error service=checkout` обнаружил сообщение «database connection pool exhausted». Через trace_id из лога он перешёл в Tempo и увидел, что span `db.query` занимает 8 секунд из 9 секунд общего времени запроса — пул соединений не был увеличен под новую нагрузку.
- Метрика: error rate 4.7% — сигнал о проблеме в момент деплоя
- Лог: «database connection pool exhausted» — точная причина ошибок
- Трейс: span db.query занимает 8/9 сек — локализация до конкретной операции
- Итог: баг-репорт содержал все три артефакта, разработчик исправил pool size за 15 минут
Частые ошибки
Большинство QA-инженеров, начинающих работать с observability, совершают предсказуемые ошибки, которые снижают качество диагностики и тратят время команды. Знание этих ловушек позволяет их избежать с первых дней работы.
- Читать только логи, игнорируя метрики: логи шумные, без метрик непонятно, является ли ошибка массовой или единичной
- Путать корреляцию и причинность: рост CPU во время дефекта — симптом, а не причина; причину ищите в трейсе
- Не фиксировать trace_id при воспроизведении: без него невозможно связать лог с конкретным трейсом постфактум
- Исследовать бесконечный поток логов без фильтра по времени: всегда начинайте с узкого временного окна ±2 минуты от воспроизведения
- Игнорировать WARN-уровень: предупреждения часто предшествуют ERROR и содержат ключ к пониманию первопричины