Телеграм канал «QA-Логия»

Анатомия парного доклада: как мы собирали «PROvoke» на Analyst Days. Часть 1 — подготовка

На прошлых Analyst Days авторы с Татьяной Маркиной зашли на территорию, где обычно стараются не светиться — тему манипуляций и провокаций в системной аналитике и IT. Они решили сделать парный доклад, чтобы показать не только результаты, но и сам процесс взаимодействия в аналитике на сцене.

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

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

Читать на Хабре

⁣Resource-leak в async context propagation: детекция orphaned tracing spans при неполной очистке OpenTelemetry baggage

Baggage в OpenTelemetry — тихий убийца памяти в асинхронных средах. В высоконагруженных продакшн-системах неполная очистка контекста после завершения span приводит к орфан-спанам и утечкам, которые часто маскируются под необъяснимый OOM. QA и разработчики ошибочно фокусируются на самих трейсах, игнорируя корень — незакрытый baggage.

Как возникает утечка: асинхронный контекст без очистки

В Go или Kotlin Coroutines после завершения span baggage остаётся в контексте. Пример на Go:

func process(ctx context.Context) {
ctx, span := tracer.Start(ctx, "operation")
defer span.End()
baggage.Set(ctx, baggage.String("key", "value"))
// goroutine продолжает работать с контекстом
}

Span закрылся, но baggage живёт. Этот контекст кочует между горутинами, цепляя orphaned spans — трейсы без родителя. Они не закрываются, память растёт, trace tree превращается в кашу.

Четыре метода детекции

* Метрики: смотри на otel_span_count с status_code = Unset. Высокий счётчик — явный признак утечки.
* Логи: middleware после завершения scope проверяет, пустой ли baggage. Если нет — предупреждение в лог.
* Анализ trace tree: если span при ожидании не видит родителя с помощью Span.current(), он почти гарантированно orphaned.
* Алерты по baggage: отслеживай рост количества spans с одинаковыми ключами — триггер для баг-трекинга.

Практический совет: обязательная очистка

В Go: defer baggage.Clear(ctx) после завершения операции. В Kotlin Coroutines используй OpenTelemetryContextElement. В Java с CompletableFuture — явно чисти контекст перед каждым .thenApply. Это предотвращает утечки независимо от инструмента.

Типичная ошибка: игнорирование асинхронных блоков

Опасность не в падении одного сервиса. В high-load системе тысяча болтающихся контекстов через пару часов даёт OOM, а трейсы в дампе ничего не объясняют: spans есть, цепочек нет. Проверять надо все асинхронные блоки: goroutine, async/await, CompletableFuture, корутины. Если есть JVM-мониторинг — смотри jvm.memory.used в разрезе контекстов.

Для тестов полезна эмуляция контекста: запускаешь асинхронную операцию, ждёшь completion, проверяешь, что baggage чистый. Если нет — тест красный.

Вывод: В production-oriented QA первым делом проверяй очистку baggage в асинхронных цепочках — это дешевле, чем разбирать OOM с кашей из orphaned spans в дампе.

⁣Диагностика дрейфа библиотек шифрования в gRPC middlewares через слепую смену версий в production

Регресс на стейджинге — не всегда следствие плохого кода. Часто проблема скрыта в библиотеке шифрования, которая тихо поменяла версию: OpenSSL на BoringSSL или GnuTLS, а gRPC middleware перестал согласовывать cipher suites. Разработчики и QA это редко замечают, пока production не падает на handshake.

Почему это ломает gRPC
Шифрование в gRPC работает через middlewares — перехватчики всех запросов. Если подменить BoringSSL на GnuTLS, может измениться порядок cipher suites, отвалиться OCSP stapling или сломаться handshake для клиента с устаревшим proto. Пример из практики: после замены OpenSSL на BoringSSL на прокси Envoy упал весь трафик, так как новый порядок suites не поддерживали старые клиенты. Ни один CI регресс это не поймал — тесты запускались на том же стейджинге, без изоляции версий.

Пассивная диагностика
Добавьте в gRPC клиент interceptors для логирования версии библиотеки. Например, через переменную окружения TLS_LIB_VERSION (если не задана — unknown). Это даёт картину при разборе ошибок. Но пассивное логирование не ловит дрейф до сбоя.

Активное тестирование с подменой
Запустите канареечный тест на малом проценте трафика: временно подмените OpenSSL на BoringSSL через подготовленный контейнер. Метрики для мониторинга:
* время handshake (допуск — не более 5% отклонения)
* количество ошибок UNAVAILABLE
* разница в cipher suites на прокси (HAProxy или Envoy)

В production мне так вскрылась несовместимость по OCSP, которую регресс не поймал: старый сертификат не проходил проверку на новом BoringSSL. Обязательно используйте feature flag для отката и логируйте sha256 бинарника библиотеки, чтобы точно знать, что подменили.

Типичная ошибка
Не верьте, что если регресс прошёл на стейджинге, то всё чисто. Без изоляции версий вы не заметите дрейф библиотек. Слепая смена — не проблема, если есть active monitoring. Но без неё вы просто молитесь, что handshake не сломается.

Вывод:
Активное тестирование с подменой библиотек и мониторинг метрик handshake — единственный способ поймать несовместимости шифрования, которые регресс пропускает до падения production.

«Освоение модульного тестирования с использованием Pytest» курс на Stepik

Сегодня умение писать тесты ценится почти так же, как и умение писать сам код. Если pytest, fixtures, CI/CD и coverage всё ещё вызывают вопросы самое время это исправить

Программа курса:

• Pytest: от базовых тестов до CI/CD
• fixtures, mocking, parametrization
• Flask/API testing
• Selenium и UI тестирование
• Docker + Docker Compose
• GitHub Actions
• coverage и отчёты
• debugging и refactoring тестов

Курс построен вокруг практики: много примеров, готовых кейсов и разборов рабочих сценариев

48 часов действует скидка 25%

↗️ Пройти курс на Stepik

⁣Retry-шторм как скрытая DDOS при cascading-отказах в async-оркестраторах

Ретри-логика кажется безобидной, пока не происходит каскадный отказ. В production я встречал ситуацию, где падение одного сервиса через саги превратилось в лавину ретраев, положившую всю инфраструктуру за 3 минуты. Ошибка в том, что разработчики и QA считают retry безопасным механизмом, не учитывая exponential growth нагрузки при одновременных вызовах.

Анатомия retry-шторма
Когда async-оркестратор (сага, workflow-движок) видит ошибку от downstream-сервиса, каждый экземпляр workflow запускает ретрай с экспоненциальной задержкой. При cascading-отказе, например падении БД, сотни оркестраторов одновременно выполняют шаги, каждый генерирует 3-5 ретраев. Итоговая нагрузка растет квадратично: 100 запросов в секунду превращаются в 10 тысяч ретраев за пару минут. Мониторинг показывает рост 5xx, но истинная причина — забитые очереди — не видна на графиках. Восстановление занимает часы вместо минут, как на реальном проекте после падения кластера БД.

Примитивный код-пример с проблемой
Допустим, в aiohttp воркфлоу вызывает сервис с ретраем:

async def call_service(session, url, retries=0):
try:
async with session.get(url) as resp:
resp.raise_for_status()
except ClientError:
if retries < MAX_RETRIES:
await asyncio.sleep(2 ** retries) # экспоненциальная задержка без jitter
return await call_service(session, url, retries + 1)
raise

Проблема: нет circuit breaker и rate limiter, jitter отсутствует. Экспоненциальная задержка без случайности даёт синхронные волны ретраев.

Практический совет: защита через три механизма
Добавьте circuit breaker, который отключает ретраи при ошибке сервиса. Используйте jitter для размазывания задержки:

import random

await asyncio.sleep((2 ** retries) + random.uniform(0, 0.5))

Также внедрите глобальный rate limiter на уровне оркестратора. После 2-3 ретраев сразу отправляйте запрос в dead-letter queue для ручного разбора.

Типичная ошибка: игнорирование cascading-отказов в тестах
Многие QA ограничиваются unit-тестами ретраев с изолированными вызовами. В реальном production retry-шторм возникает только при массовых отказах. Если у вас нет тестов, где симулируется падение БД с последующим восстановлением — вы не видите, как нагрузка расходится по очередям. Это скрытая DDOS, которая не выдаёт себя на стандартном мониторинге (CPU, memory, latency). Мой совет: заведите сценарий с cascading-отказом, используя инструменты вроде chaos engineering, и измеряйте количество ретраев в очередях. Источники: Martin Kleppmann, "Designing Data-Intensive Applications"; AWS Well-Architected Framework; GitHub Outage 2023.

Вывод: Retry-шторм — скрытая DDOS, требующая circuit breaker, jitter и rate limiting, иначе cascading-отказ в async-оркестраторах может привести к часам простоя.

⁣Метрика rogue-запросов: как поймать SQL-инъекцию по аномалии плана выполнения

Классические WAF и сигнатурки пропускают инъекции, когда атакующий вшивает UNION в конец легитимного WHERE, избегая типичных паттернов. В production такие запросы незаметны до момента утечки данных. Метрика аномалии плана выполнения ловит их по поведению оптимизатора, а не по тексту.

Почему план выполнения сбоит при инъекции
Нормальный запрос даёт стабильный план: Index Scan, Nested Loop, предсказуемый cost. Инъекция вводит нестандартные операторы (OR, UNION, комментарии), которые ломают оптимизатор. Появляются неожиданные Filter, SeqScan вместо IndexScan, или cost подскакивает в 10 раз. Это выглядит как выброс в статистической выборке.

Формула детекции rogue-запроса
Я считаю аномалию так: Deviation = |Cost_actual - Median(Cost_history)| / IQR(Cost_history). Если значение больше 5 — это повод проверить запрос. Но cost — не единственный индикатор. Упрощённый пример на Python:

normal_plans = {"IndexScan->NestedLoop": 12.3}
rogue_plan = "SeqScan->Filter" # cost = 450.0

if rogue_plan not in normal_plans:
alert("Неизвестный тип плана — потенциальная инъекция")
else:
deviation = (450.0 - 12.4) / 0.3 # > 1000
if deviation > 5:
alert("Статистическая аномалия затрат")


Признаки аномалии и типичная ошибка
Главные признаки: смена типа сканирования (SeqScan вместо IndexScan), появление сортировки там, где её не было, резкий скачок estimated_rows в 100+ раз, необычный join (NestedLoop вместо HashJoin). Типичная ошибка: игнорировать ложные срабатывания при выкатке фичи или изменении данных. Без калибровки на контрольной выборке метрика завалит алертами.

Практический совет и trade-offs
Для production используй медиану и IQR — они устойчивы к кратковременным пикам. Cтоимость: хранение истории планов для каждого запроса и вычислительные затраты на анализ. Но trade-off оправдан: rogue-запросы выявляются до того, как инъекция выполнится. Не полагайся только на cost — сравнивай структуру plan tree, чтобы отсечь случайные колебания.

Вывод: Статистическая аномалия плана выполнения превращает оптимизатор базы данных в сенсор безопасности, ловящий инъекции по поведению, а не по тексту запроса.

⁣Архитектурная гниль в read-оптимизированных кэшах: детекция утечки старого бизнес-логика через stale projection в CQRS-потоках

Каждый, кто работал с CQRS, знает: проекции живут своей жизнью. Со временем read-модели превращаются в «кладбище полей» — хранят то, что уже нигде не используется бизнесом. Это не баг, а stale projection — классическая архитектурная гниль, когда кеш возвращает данные, не соответствующие актуальным правилам, что приводит к скрытым дефектам в production.

Как это выглядит в production
Когда команда меняет требования, а projection продолжает агрегировать данные по старым правилам, кеш честно отдает то, что накопили. Пример: событие OrderShipped приходит в projection. В коде когда-то было поле IsDelayed — его вычисляли на основе expectedDeliveryDate и actualShipDate. Потом бизнес изменил метрики: задержка считается только после статуса «On Hold». Но projection продолжает считать IsDelayed по-старому.

func (p *OrderProjection) Handle(event OrderShipped) {
// Старая логика — уже не актуальна
p.IsDelayed = event.ShipDate.After(event.ExpectedDelivery)
// Новая логика — требует проверки статуса
// p.IsDelayed = event.ShipDate.After(event.ExpectedDelivery) && event.Status == "OnHold"
p.ShipmentId = event.ShipmentId
// ... остальные поля
}

Как детектировать гниль
* Мониторинг "мертвых полей" — заведите метрику, сколько раз поле из projection читается за период. Если 0 в течение двух недель — кандидат на удаление.
* Дата последнего изменения — храните updated_at как часть projection. Если проекция не обновлялась дольше N циклов бизнес-событий — она stale.
* Audit-лог использованных событий — проверяйте, какие события применяются к projection, а какие — нет. Если из 10 ивентов применяется только 3, остальные — legacy.

Типичная ошибка и практический совет
Ошибка: чистка проекции только при обнаружении бага в production, а не на этапе changelog. Совет: при каждом рефакториге бизнес-логики сразу обновляйте код обработчика и очищайте projection. Если бизнес позволяет простой, выполняйте тотальный пересчет (replay) после изменения логики.

Вывод: Stale projection — это не ошибка кеша, а сигнал о рассинхронизации между бизнес-требованиями и read-моделью, который можно предотвратить мониторингом использования полей и обязательным cleanup при changelog.