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

Controlled fault injection в продакшене: как проверять fallback-логики без расширения blast radius

Fallback часто есть в коде и unit-тестах, но ломается в реальном prod из-за таймаутов, ретраев, кешей, circuit breaker, feature flags или форматов ошибок. Типичная ошибка QA и dev - проверять только happy path деградации в staging.

Что стоит проверять
- timeout pricing-api: checkout берет последнюю валидную цену из кеша
- 5xx от recommendations: показываем дефолтный блок, а не пустой экран
- 200 с invalid schema: не падаем на десериализации
- частичная деградация downstream: основной user journey завершается

Как не расширить blast radius
- allowlist вместо “1% пользователей”: synthetic user, test tenant, internal account, request header
- scope на одну зависимость и endpoint, а не “ломаем сеть сервису”
- TTL 5-15 минут, чтобы fault выключился сам
- kill switch без деплоя
- rate limit, чтобы не создать лавину ретраев
- dashboards до старта: fallback hit rate, latency, error rate, saturation, бизнес-метрика flow

Минимальный guardrail
if fault_enabled(req, "pricing-api"):
raise TimeoutError("controlled fault")

try:
price = pricing.get(item_id)
except TimeoutError:
metrics.inc("fallback.pricing")
price = cache.last_valid(item_id)

Практический сценарий
Гипотеза: если pricing-api не отвечает до 2 секунд, checkout использует cached price и заказ завершается. Запускаем только для synthetic user, одного endpoint, одного fault, TTL 10 минут, с trace id и stop condition: p95 latency выше лимита, error rate растет или ошибки вышли за targeted cohort.

Предупреждение:
не встраивайте fault injection хаотично в бизнес-код. Лучше слой клиента, middleware, proxy, service mesh или платформенный механизм, иначе стоимость поддержки быстро превысит пользу.

Вывод:
controlled fault injection ценен не “поломкой прода”, а проверяемым, ограниченным и наблюдаемым доказательством, что fallback реально снижает риск инцидента.

Совет на ближайшие годы — изучайте ВАЙБ-КОДИНГ

ИИ уже пишет код, чинит баги, генерирует тесты, документацию и помогает запускать продукты быстрее, чем это делали классические команды разработки. И это уже не "будущее когда-нибудь", а реальность, которая меняет рынок уже сегодня

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

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

Подписывайтесь, нас уже 45 тысяч: @vibecoding_tg

⁣Shadow testing асинхронных консьюмеров на прод-трафике: как сверять побочные эффекты без риска для данных

Shadow testing нужен, когда новый consumer проверяется на реальных сообщениях, но не должен менять prod. Частая ошибка - считать успехом no exception, не сравнивая реальные side effects.

Суть паттерна
Боевой consumer обрабатывает сообщение как обычно, shadow consumer получает копию и пишет “предполагаемые действия” в изолированный sink:
* shadow-таблицы
* отдельный topic
* audit storage
* recorder вместо БД, event bus и внешних клиентов

Главное правило: не “мы не будем писать в prod”, а технически не можем - отдельные credentials, network policy, запрет write-доступа.

Что сравнивать
Comparator должен сверять не только финальный статус, а модель побочных эффектов:
* созданные/обновленные записи
* downstream events и HTTP/gRPC вызовы
* суммы, комиссии, даты, reason codes
* idempotency key, retry/dedup/DLQ поведение
* отсутствие лишних действий

Перед сравнением нормализуйте timestamp, request_id, UUID, порядок JSON-полей, метаданные брокера и версии схем, если они не меняют бизнес-смысл. Иначе получите шум вместо полезных расхождений.

Production guardrails
Для Kafka shadow обычно запускают в отдельной consumer group; для SQS/RabbitMQ часто нужен fan-out или shadow-очередь, иначе consumers начнут конкурировать.

Практический минимум:
* feature flag для отключения
* sampling и rate limit
* TTL для shadow-данных
* маркировка shadow=true
* запрет реальных платежей, email, SMS, delivery, CRM
* dashboard по diff, а не падение prod-flow

Trade-off: больше инфраструктуры и поддержки recorder’ов, зато быстрее feedback loop на реальном трафике и ниже риск релиза async-логики.

Вывод:
Shadow testing полезен только тогда, когда побочные эффекты измеряются инженерно, а риск для prod-данных исключен архитектурно.

АЙТИШНИКИ БЕСПЛАТНОЕ ОБУЧЕНИЕ сборник курсов, инструментов и книг

Проект «TERMINAL» стал крупнейшей библиотекой бесплатного образования. В одном канале собраны курсы, книги, полезные инструменты и практические тренажёры для всех разработчиков

🎓 Практические курсы и задания

🪽 Книги и статьи известных авторов

😮‍💨 Полезные инструменты и ресурсы

🌟 IT-новости и инсайды

Обучение по всем направлениям: SQL, Python, Frontend, PHP, C++, Golang, GIT, Linux, QA, Java, Vibe-coding, Infosec и др.

Ценишь знания, подпишись: Terminal_tg

Тестирование идемпотентности в продакшене: как ловить дубли событий до инцидента

Идемпотентность не заканчивается unique key в базе: при at-least-once delivery одно событие может прийти несколько раз. Частая ошибка QA и разработки - проверять только happy path, не доказывая, что повтор не создает второй бизнес-эффект.

Что проверять

Инвариант не "событие пришло один раз", а "повтор не изменил состояние второй раз":

* один payment_id - максимум одно списание
* один order_id + event_type - один переход статуса
* один external_webhook_id - одна обработка
* один idempotency_key - один результат операции
* повтор не меняет баланс, лимиты, остатки

Production probes без риска

Практичный подход - безопасные контрольные дубли:

* отправить событие
* повторить его с тем же event_id или idempotency_key
* проверить, что нет нового side effect
* убедиться, что ответ совпал или вернулся already processed
* проверить рост метрики дедупликации

Предупреждение: не делайте это на живых деньгах и реальных клиентах. Используйте test tenants, synthetic users, sandbox merchants, zero-amount операции или internal-only флаги.

Логи и метрики

Если нельзя связать дубль с эффектом, observability бесполезна. Логируйте:

* event_id, idempotency_key, trace_id
* consumer_group, handler_name
* dedup_decision: new | duplicate | conflict
* side_effect_created: true | false
* business_entity_id, версию схемы

Алерт на events_duplicate_with_side_effect_total > 0 почти всегда оправдан: это уже инцидент или состояние перед ним.

SQL-инвариант

SELECT idempotency_key, COUNT(*) AS effects
FROM payment_charges
WHERE created_at > now() - interval '10 minutes'
GROUP BY idempotency_key
HAVING COUNT(*) > 1;

Смотрите таблицу эффектов, а не входящих сообщений: событие может повторяться, эффект - нет. В regression и CI/CD quality gates добавляйте replay after TTL, timeout retry с тем же ключом, restart consumer-а до commit offset и payload conflict.

Вывод:
Идемпотентность нужно тестировать как production-инвариант с логами, метриками и безопасными дублями, иначе дефект проявится уже в деньгах, статусах или данных клиента.

Нейросети, IT и AI — в одной папке

💬 С коллегами собрали новые каналы про:

💠 промпты для нейросетей и готовые решения
💠 AI-фотосессии, генерация изображений и контента
💠 новости искусственного интеллекта без лишнего шума
💠 применение AI в работе, бизнесе и повседневной жизни
💠 Python, JavaScript, Data Science и системный анализ
💠 вакансии и возможности для специалистов в IT

Посмотреть и подписаться тут 👉 https://t.me/addlist/c_rbhnzprbAwMmFi

💌 Добавить свой канал в папку

Страшная тайна российского айти

✖️ xCode Journal