← вся теориятеория к собесу · Теория тестирования

Логи и наблюдаемость для тестировщика

Наблюдаемость для тестировщика

Три запроса пришли одновременно, каждый прошёл через четыре сервиса. В общем логе получилась каша: строки трёх запросов вперемешку по времени, понять, что с чем связано, невозможно. Я отфильтровал по идентификатору одного запроса - и путь развернулся целиком: шлюз (сервис на входе, через который проходит всё) 2 мс, заказы 5 мс, расчёты 12 мс, уведомления 3 мс. Двенадцать миллисекунд на расчётах видно сразу.

Стержень: прод - не чёрный ящик, а самый честный источник данных о дефектах, и репорт со ссылкой на логи разбирают за минуты вместо дней.

// Формулировки: «как наблюдаемость помогает QA?», «что такое тестирование на проде?», «зачем сквозной идентификатор запроса?».

Логи, метрики, трейсы

Наблюдаемость стоит на трёх источниках. Логи - записи о событиях: что произошло, когда, с какими параметрами. Метрики - числа во времени: сколько запросов в секунду, какая доля ответов с ошибкой, сколько миллисекунд занимает ответ. Трейсы - путь одного запроса через все сервисы, разложенный по шагам; отдельный шаг называют спаном, и картинка из спанов сразу показывает, кто съел время.

Ключ ко всему - сквозной идентификатор запроса (его называют correlation id или request_id): случайная строка, которую шлюз выдаёт входящему запросу и которую все сервисы дальше протаскивают в свои логи. Без него мой пример выше остаётся кашей из трёх запросов; с ним фильтр по одной строке восстанавливает путь целиком.

// Для тестировщика это меняет две вещи. Первая: репорт с идентификатором запроса и ссылкой на график разбирают за минуты, потому что разработчику не надо угадывать, какой из тысяч вызовов был ваш. Вторая: метрики прода - боевой среды, где сидят живые пользователи, - работают как непрерывный тест на реальном трафике - всплеск ошибок или падение доли успешных оплат после выката находит дефекты, которых тестовая среда не покажет никогда.

correlation id: сквозная метка запроса, которую все сервисы пишут в свои логи
спан / трейс: один шаг обработки / полный путь запроса по шагам

Канарейка: сколько трафика нужно, чтобы поймать

Канареечный выкат - это когда новую версию сначала получает малая доля трафика на проде (то есть в боевой среде, где живые пользователи), её метрики сравнивают со старой версией и только потом раскатывают на всех. Вопрос, который редко задают: а сколько трафика надо пропустить, чтобы дефект вообще проявился?

Считается это одной формулой: вероятность поймать хотя бы раз равна единице минус вероятность промахнуться на всех попытках подряд. Если баг задевает 1% запросов, то на 50 запросах канарейки вы поймаете его с вероятностью 39%, на 200 запросах - 87%, на 500 - 99%. А если баг задевает 0,1% запросов, то и 500 запросов дают всего 39%: редкий дефект канарейка на маленьком трафике просто не увидит.

// Практический вывод: длительность канарейки задают не «полчаса на глазок», а нужным числом запросов, посчитанным от ожидаемой частоты дефекта. И к канарейке обязателен план отката - погасить функцию фиче-флагом (переключателем, которым её выключают без новой выкладки) или вернуть предыдущую версию, - иначе наблюдение превращается в наблюдение за тем, как всё падает.

канареечный выкат: новая версия на малой доле трафика под сравнением метрик
план отката: заранее известный способ вернуть всё назад за минуты

Релиз не кончается деплоем

Выкладка новой версии (она же деплой) - середина работы, а не конец. До неё QA определяет, за чем смотреть после: доля ответов с ошибкой, скорость главных запросов, продуктовые числа вроде доли дошедших до оплаты. И заранее договаривается о пороге: при каком значении откатываемся, а не «посмотрим, как пойдёт».

Синтетический мониторинг - роботы, которые круглосуточно гоняют по проду главные сценарии: зайти, найти товар, оформить, оплатить тестовой картой. По сути, это ваша быстрая проверка главных сценариев, запущенная навсегда. Ловит то, чего не видно по метрикам: сценарий формально отвечает 200, а кнопка не работает.

// И честная граница: тестирование на проде без канареек, флагов и отката - это не тестирование, а инцидент. А синтетика без оповещений бесполезна: робот может падать неделю, и никто не заметит, если некому прилетает уведомление. Проверка на проде живёт связкой «сигнал плюс тот, кто на него отвечает».

синтетический мониторинг: роботы, круглосуточно гоняющие главные сценарии по проду
порог отката: заранее оговорённое значение метрики, при котором возвращаем версию

Как отвечать: «Что такое тестирование на проде и почему это не «тестим на юзерах»?»

Это проверка поведения системы в боевой среде под реальным трафиком, но с ограниченным охватом и возможностью мгновенно всё вернуть. Нужно оно потому, что тестовую среду невозможно сделать точной копией прода: ни по объёму данных, ни по нагрузке, ни по разнообразию пользователей и их данных, и часть дефектов проявляется только там. Инструменты делают риск управляемым. Канареечный выкат отправляет новую версию на малую долю трафика и сравнивает её метрики со старой. Фиче-флаги включают функцию на процент аудитории и выключают её без выкладки. Синтетические роботы круглосуточно гоняют главные сценарии. И тут важна арифметика, которую часто пропускают: если дефект задевает один процент запросов, то полсотни запросов канарейки поймают его лишь с вероятностью около сорока процентов, а вот пятьсот - уже почти наверняка. То есть длительность канарейки считают от ожидаемой частоты дефекта, а не на глаз. Граница простая: есть ограниченный охват, наблюдение и заранее готовый откат - это тестирование. Нет - это выкат непроверенного на всех, то есть инцидент.

Почему это сильный ответ: объяснено, зачем вообще прод (среду не скопировать), названы инструменты, приведён счёт по вероятности поймать дефект и проведена чёткая граница между контролируемым выкатом и инцидентом.

На чём валят

−Считать прод чёрным ящиком: «у юзера упало, не воспроизвелось», хотя трейс этого запроса лежит и ждёт.
−Репорт без идентификатора запроса, когда он был в ответе сервера - разработчик ищет иголку в логах.
−Держать канарейку «полчаса на глазок»: при дефекте у 0,1% запросов даже 500 запросов дают шанс поймать 39%.
−Выкатывать на прод без флага и плана отката - это уже не тест, а инцидент.
−Синтетика без оповещений: робот падает неделю, и никто не смотрит.

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 12, остальные разбираются в тренажёре.

#qa_observability1 / 5
Сценарий упал, на экране — общее «Что-то пошло не так». С чего начать диагностику?
A)Перезапустить сценарий несколько раз — если повторится, значит баг реальный
B)Сразу завести баг с одним скриншотом экрана и оставить поиск причины целиком на разработчика
C)Поменять тестовые данные и посмотреть, исчезнет ли сообщение об ошибке само
D)Открыть логи бэкенда и вкладку Network/Console в DevTools — найти реальную ошибку
показать ответ и разбор
+D)Открыть логи бэкенда и вкладку Network/Console в DevTools — найти реальную ошибку
// разбор: Экранное «что-то пошло не так» — верхушка: настоящая ошибка (стектрейс, код ответа, отвалившийся запрос) лежит в логах сервиса и в DevTools — вкладки Network (какой запрос вернул 4xx/5xx и что в теле) и Console (JS-ошибки). Начав отсюда, тестировщик локализует причину до заведения бага и приложит к репорту конкретику (запрос, код, сообщение, timestamp), а не только скриншот. Это отличает сильный баг-репорт от «не работает» и экономит круг переписки с разработкой.
#qa_observability2 / 5
Зачем логи со всех сервисов собирают в одну систему (ELK/Kibana, Grafana Loki)?
A)Иначе логи размазаны по машинам и сервисам — искать по одному запросу пришлось бы вручную везде
B)Централизованный сбор нужен главным образом ради экономии места на дисках серверов, где логи сжимают и архивируют
C)Так логи становятся недоступны разработчикам, и их видит лишь служба эксплуатации
D)Единая система логов заменяет собой мониторинг, метрики и алерты по продукту
показать ответ и разбор
+A)Иначе логи размазаны по машинам и сервисам — искать по одному запросу пришлось бы вручную везде
// разбор: В системе из многих сервисов на разных машинах логи одного пользовательского запроса раскиданы по разным местам. Централизованный сбор (например, ELK: Elasticsearch хранит и ищет, Logstash/агенты собирают, Kibana показывает; или Grafana Loki) сводит их в одно место с поиском и фильтрами — можно пройти по всей цепочке запроса, не заходя руками на каждый сервер. Тестировщику это ускоряет локализацию: фильтр по времени, сервису, уровню или correlation-id вместо ручного обхода машин.
#qa_observability3 / 5
Как понять, какие строки логов в разных сервисах относятся к одному и тому же запросу пользователя?
A)Сопоставить их по времени: записи с близкими значениями timestamp почти наверняка принадлежат одному запросу
B)Искать по имени пользователя во всех логах — оно уникально идентифицирует запрос
C)По сквозному correlation-id (trace-id), который проставляют на входе и тащат через все вызовы
D)Никак: логи разных сервисов между собой не связать, каждый смотрят отдельно
показать ответ и разбор
+C)По сквозному correlation-id (trace-id), который проставляют на входе и тащат через все вызовы
// разбор: Надёжный способ — сквозной идентификатор: на входе (шлюз/первый сервис) запросу присваивают correlation-id (он же trace-id) и передают его во все последующие вызовы, а каждый сервис пишет его в свои логи. Тогда фильтр по этому id собирает всю цепочку по сервисам. Время ненадёжно (параллельные запросы, рассинхрон часов), а имя пользователя не различает его отдельные запросы. Это основа распределённой трассировки (Jaeger/Zipkin). Тестировщику полезно уметь достать correlation-id из ответа/заголовка и приложить его к багу.
#qa_observability4 / 5
Три столпа наблюдаемости — логи, метрики и трейсы. В чём разница их задач?
A)Это три названия одного и того же: разные команды по-разному зовут журнал событий системы
B)Логи и метрики нужны только разработчикам, а трейсы существуют исключительно для нужд бизнес-аналитики и отчётности
C)Метрики хранят полный текст каждого события, а логи — только усреднённые числа за период
D)Логи — детали событий, метрики — числа во времени (RPS, latency, ошибки), трейсы — путь запроса
показать ответ и разбор
+D)Логи — детали событий, метрики — числа во времени (RPS, latency, ошибки), трейсы — путь запроса
// разбор: Это три взгляда на поведение системы. Логи — дискретные записи о событиях с деталями (что случилось, с каким сообщением). Метрики — числовые агрегаты во времени: частота запросов (RPS), задержка (latency, перцентили), доля ошибок; на них строят дашборды и алерты. Трейсы — путь одного запроса через сервисы с таймингами каждого шага. Для задачи выбирают своё: «сколько 5xx за час» — метрика, «что именно упало в этом запросе» — лог/трейс. Тестировщик пользуется всеми тремя при разборе.
#qa_observability5 / 5
Зачем тестировщику смотреть на дашборды и алерты (Grafana) уже после релиза?
A)Часть проблем видна лишь под реальным трафиком — рост 5xx и latency ловят на проде
B)После релиза тестирование закончено, а дашборды смотрят просто из любопытства к цифрам
C)Мониторинг на проде полностью заменяет пред-релизные тесты, если дашборды настроены
D)Дашборды нужны прежде всего, чтобы отчитаться перед руководством о количестве прогнанных тест-кейсов за спринт
показать ответ и разбор
+A)Часть проблем видна лишь под реальным трафиком — рост 5xx и latency ловят на проде
// разбор: Пред-релизные тесты не покрывают всё: реальные объёмы, редкие данные, пиковые нагрузки и странное поведение пользователей проявляются только на проде. Поэтому наблюдение после релиза — часть работы над качеством: следят за долей 5xx, задержками (p95/p99), частотой ошибок сразу после выката, чтобы поймать регресс раньше пользователей и быстро откатить. Это дополняет, а не заменяет тесты до релиза. Такой пост-релизный контроль иногда называют «тестированием в проде» (в связке с канареечными выкатками и алертами).

дальше

Теорию прочитали. Навык ставится повторением

В Сеньорчике эта подтема идёт в ежедневных сессиях: движок возвращает её, пока ответы не станут уверенными, и ведёт прогресс отдельно по каждой подтеме. Теория внутри тоже бесплатна, лимит только на количество вопросов в день.

Открыть тренажёр Вся тема: Теория тестирования