Зачем мониторинг QA
Тестирование не заканчивается, когда код попадает в продакшен. Мониторинг — продолжение обеспечения качества в боевой среде. Ни один набор тестов не ловит каждый баг, а некоторые проблемы появляются только при реальных паттернах трафика.
Для QA-инженеров мониторинг даёт:
- Постдеплойную валидацию: Подтверждение работы новых релизов в продакшене
- Обнаружение багов: Выявление проблем, пропущенных тестированием
- Анализ причин: Корреляция тестовых сбоев с поведением системы
- Нефункциональная валидация: Проверка соответствия производительности и доступности требованиям
Три столпа наблюдаемости
Логи
Дискретные события, описывающие что произошло в конкретный момент. QA использует логи для расследования упавших тестов, поиска паттернов ошибок после деплоев и отладки нестабильных проблем.
Метрики
Агрегированные измерения во времени. Типы: Counter (общее число событий), Gauge (текущее значение), Histogram (распределение значений).
Ключевые метрики для QA:
| Метрика | Что показывает |
|---|---|
| Error rate | Процент неуспешных запросов |
| Время ответа (P50/P95/P99) | Скорость отклика приложения |
| Throughput (RPS) | Запросов в секунду |
| Насыщение | Использование ресурсов |
| Доступность | Процент uptime |
Трейсы
Отслеживание запроса при прохождении через несколько сервисов. Необходимы для микросервисных архитектур.
SLI, SLO и SLA
| Термин | Определение | Пример |
|---|---|---|
| SLI | Измерение качества сервиса | 99.95% запросов успешны |
| SLO | Цель для SLI | «Целевой показатель 99.9%» |
| SLA | Контрактное обязательство | «Гарантируем 99.5% uptime» |
Настройка алертов
- Алерт на симптомы, не причины. Error rate > 1% вместо CPU > 80%.
- Установите значимые пороги. Слишком чувствительные = усталость от алертов.
- Включайте контекст для действий. Каждый алерт должен сообщать что происходит и что делать.
Упражнение: Спроектируйте мониторинг-дашборд для QA
Создайте спецификацию дашборда для мониторинга веб-приложения после деплоя.
Решение
QA-дашборд мониторинга
Ряд 1: Общее здоровье
- Доступность (gauge): Текущий uptime. Алерт < 99.9%
- Error rate (временной ряд): 5xx ошибки. Алерт > 1%
- Активные пользователи (gauge)
Ряд 2: Производительность
- Время ответа P50/P95/P99. Алерт P95 > 500мс
- Throughput: Запросов в секунду
- Медленные endpoints: Топ 10
Ряд 3: Бизнес-метрики
- Конверсия. Алерт > 10% падение
- Процент успешных платежей. Алерт < 99%
- Брошенные корзины. Алерт > 20% рост
Ряд 4: Инфраструктура
- CPU/Память по сервисам. Алерт > 80%
- Перезапуски подов. Алерт > 0 за 15 минут
- Соединения БД. Алерт > 80% пула
Инструменты мониторинга
| Инструмент | Тип | Лучше всего для |
|---|---|---|
| Prometheus | Метрики | Сбор time-series данных и алертинг |
| Grafana | Визуализация | Дашборды для любых источников данных |
| ELK Stack | Логи | Агрегация, поиск и анализ логов |
| Datadog | Всё-в-одном | Метрики, логи, трейсы, APM (SaaS) |
Ключевые выводы
- Мониторинг расширяет QA в продакшен
- Используйте все три столпа — логи для деталей, метрики для трендов, трейсы для потока
- Определите SLO до настройки мониторинга
- Алерт на симптомы, не причины
- Стройте QA-специфичные дашборды