Сценарий (реальное поведение в проде): ночью в 03:20 система залогировала серию апдейтов, которые частично пересекаются, через пару часов стали появляться расхождения между таблицами orders и order_events: некоторые заказы показываются завершёнными в orders, но в order_events нет финального payment_confirmed. Релизы не было за последние 48 ч. Ошибки sporadic, воспроизводятся редко. Логи показывают sporadic spikes в queue depth в 02:50–03:10, и несколько deadletter записей.
Прошу: сходу 1) ваши рабочие гипотезы почему это могло произойти, 2) какие точные команды/проверки вы выполните в первые 30/60/180 минут, 3) быстрые mitigations, которые можно включить без полного отката.
Гипотеза 1: race condition при обработке вебхуков + retry logic без idempotency - два воркера параллельно применяют финальный статус. Гипотеза 2: partial failure в транзакции базы - запись в orders прошла, но order_events писалась в отдельную таблицу/queue и упала. Первые 30 мин: взять snapshot БД на время инцидента (pg_dump/export последних 5 минут), посмотреть pg_stat_activity, pg_locks и txid_current. 60 мин: посмотреть queue metrics (length, consumers), посмотреть DLQ reason. 180 мин: реплеить DLQ events в sandbox и смотреть, почему не прошли. Mitigation: 1) временно stop consumers, 2) включить single-writer режим для проблемного потока (feature-flag), 3) запуск reconciliation job, который сводит orders и order_events (safe, idempotent).
Команды: SELECT * FROM order_events WHERE created_at > now() - interval '4 hours' ORDER BY created_at DESC LIMIT 200;SELECT count(*) FROM dlq WHERE reason IS NOT NULL;ss -s для проверки consumers. Если очередь Redis Streams: xpending + xinfo - смотреть consumers idle. Для Kafka kafka-consumer-groups.sh --describe.
Если backlog рос, возможно, автоскейл воркеров сработал некорректно (новые инстансы без нужных миграций/фич-флагов). Посмотрите deployment events: kubectl get events --sort-by='.lastTimestamp' и kubectl describe pod <consumer>, может быть, новый pod поднял старый код. Быстрая mitigation: pin current replica count and drain newcomers, или rollback autoscale policy.
Проверьте IAM/секреты: не было ли автоматического ротающегося токена, который привёл к ошибкам в consumers (ошибки авторизации иногда выглядят как transient failures). Логи auth сервера в приоритете.
После первичных шагов запустите reconciliation job в read-only режиме: соберите несогласованные заказы, отрежьте возможные дубликаты, сформируйте репорт для manual review. Не делайте mass-update без ручной проверки — это опасно.