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

⁣Диагностика дрейфа библиотек шифрования в 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.

⁣Sleeping-read consistency gaps: детекция stale коммитов при пониженной изоляции read-committed в production

Работаете с read-committed и считаете, что это "достаточно безопасно"? Есть нюанс, который в production вылезает неочевидными гонками. Sleeping-read consistency gap.

Проблема stale чтений
Транзакция читает данные, потом делает паузу — sleep, внешний вызов API, что угодно. После пробуждения читает снова. Read-committed не обещает snapshot между двумя SELECT. Только что первый запрос выполнился на старых данных — второй ловит свежий коммит. Для тестировщика это значит: отчёт, собранный за два запроса, может быть неконсистентным. Проверили баланс, пошли списывать — а между ними пришёл внешний платёж. Бизнес-логика ломается, хотя СУБД формально права.

Методы детекции
Как ловить в production?

* Логируйте snapshot age. В PostgreSQL — pg_current_snapshot() до и после паузы. Если снапшоты разные — gap есть.
* Реперные точки. Вставляйте timestamp начала транзакции. Если после паузы читаете строки с меткой времени больше старта — это stale-чтение.
* SQL + Python для воспроизведения:

import psycopg2, time
conn = psycopg2.connect("...")
conn.autocommit = False
cur = conn.cursor()
cur.execute("SELECT COUNT(*) FROM orders")
cnt1 = cur.fetchone()
time.sleep(2)
cur.execute("SELECT COUNT(*) FROM orders")
cnt2 = cur.fetchone()
print(cnt1, cnt2) # разные — gap

Типичная ошибка
Многие QA прогоняют паузы только в идеальных условиях. В реальности задержки от внешних API или очередей могут превышать 100 мс и гарантированно вызывать stale чтения. Проверяйте с искусственными задержками — имитируйте реальное поведение, а не идеальное окружение.

Защита в production
Для транзакций с паузами переходите на REPEATABLE READ или SERIALIZABLE. Вставляйте оптимистичные блокировки, проверяйте версии строк. Это не баг PostgreSQL. Это контракт read-committed. И QA нужно проверять, что приложение терпит изменения данных между чтениями в одной транзакции. Иначе в проде начинается "а почему у нас баланс разъехался".

Вывод:
Sleeping-read gap — это не ошибка изоляции, а инженерный компромисс между производительностью и консистентностью, который QA обязано детектировать через тесты с реальными задержками и переходом на уровень repeatable read для критичных операций.

⁣Non-idempotent retry poisoning: как повторная обработка успешных Kafka-сообщений плодит дубликаты в production

Классическая ситуация: consumer упал после того, как обработал сообщение, но до коммита offset. Kafka переотправляет то же сообщение при ребалансе. Если обработка не идемпотентна, каждый retry создаёт дублирующие side-effect записи — в БД, внешних API, логах. Это retry poisoning, который часто остаётся незамеченным до инцидента.

Как это выглядит в production
Обычный pipeline:
1. Получить сообщение.
2. Выполнить бизнес-логику — списать деньги, создать заказ, отправить письмо.
3. Записать результат в БД.
4. Закоммитить offset.

Крах на шаге 2 или 3 — offset не зафиксирован. После рестарта consumer получает то же сообщение снова. Если side-effect записи не имеют уникальных ключей — появляются дубли:
* Один и тот же заказ с разными order_id.
* Двойное списание с одного счёта.
* Повторная отправка email или SMS.

Как выявить дубликаты
Метрики и мониторинг:
* consumer_lag резко падает, но processed_messages растёт быстрее committed_offsets.
* Искать записи с одинаковым businessKey, но разными id в базе.
* Логи: повторная обработка сообщения с тем же partition/offset в течение короткого окна.

Практический совет: идемпотентный ключ
Храните уникальный event_id в сообщении. При обработке:
INSERT INTO orders (event_id, data)
VALUES (:event_id, :data)
ON CONFLICT (event_id) DO NOTHING;
Или сначала проверяйте:
SELECT 1 FROM outbox WHERE event_id = :id;
Это дешевле повторного вызова внешнего API.

Типичная ошибка
Использовать idempotent producer на стороне Kafka и думать, что этого достаточно. Он гарантирует, что сообщение не запишется дважды в partition, но не защищает от повторной обработки одного сообщения после краша consumer. Идемпотентность должна быть на уровне consumer-логики.

Trade-off: скорость vs надежность
Автокоммит enable.auto.commit=true или ручной коммит до выполнения логики ускоряет throughput, но увеличивает риск потери данных при краше. Выбирать между потерей и дублированием — риск-ориентированное решение. Для финансовых транзакций дубли критичнее.

Вывод:
Retry poisoning — не баг в коде, а архитектурная дыра, которая лечится только внедрением идемпотентности на уровне consumer с уникальными идентификаторами и upsert-операциями.