Краткая стратегия — воспроизвести проблему под контролируемой нагрузкой, собрать телеметрию и трассировки, сузить пространство поиска методом исключения (компонентная изоляция / бинарный поиск), затем фикс + регресс-тесты. Ниже — конкретный план.
1) Гипотезы для проверки (коротко)
- Потеря из-за таймаутов/падений сетевых соединений или пула соединений.
- Утечка/перезапись из-за некорректной идемпотентности/рейтраев.
- Асинхронная очередь (broker/worker) теряет/не подтверждает сообщения.
- Базы данных: откаты/блокировки/deadlock/слишком низкие уровни изоляции.
- Слабое логирование/отсутствие корреляции request/transaction id.
2) Какие тесты запускать и как их проектировать
- Unit tests
- Проверить атомарность бизнес-логики в памяти: коммиты/откаты, обработка ошибок, логика retries и idempotency keys.
- Мокать внешние зависимости (DB, брокер) и тестировать сценарии ошибок (timeouts, partial failures).
- Проверять гонки доступа к общим структурам (многопоточность).
- Integration tests
- Поднимать реальные компоненты (API, очередь, worker, БД, кеш) в тестовом окружении.
- Проверять end-to-end корректность: если API вернул success, транзакция должна появиться в БД в течение заданного окна $T$ (например $T=30$ с).
- Тестировать разные isolation levels и поведение при deadlocks/rollback.
- Нагрузочные тесты (load / stress)
- Сценарии: steady high load, пики/бурсты, длительная нагрузка.
- Примеры нагрузок: rampa up до $10^3$–$10^4$ concurrent users; длительная выдержка $1$–$4$ часа для выявления утечек.
- Добавить chaos: искусственные задержки/потери сети/сбросы соединений, симуляция полной загрузки ЦП/Диска.
- Property-based / model-based tests
- Задайте инварианты, которые всегда должны выполняться (см. ниже). Генерируйте случайные последовательности операций (конкурентные транзакции, retries).
- Примеры инвариантов: сумма балансов = исходное + суммарные входящие транзакции; нет «невидимых» подтверждённых транзакций.
- Используйте генерацию последовательностей с параллельным исполнением и проверкой конечного состояния.
3) Какие метрики и какие значения собирать
- Транзакции
- throughput: accepted tx/s и committed tx/s; ratio committed/received.
- latency percentiles: $p_{50},p_{95},p_{99},p_{999}$ для end-to-end и для отдельных стадий (API, queue, worker, DB commit).
- success/error counts (по типам ошибок).
- Очереди/брокеры
- queue length, consumer lag, unacked count, visibility timeout expirations.
- БД
- commit rate, rollback rate, deadlock count, lock wait time, number of open transactions, long-running transactions (> $T_{long}$).
- connection pool usage (used/max), active sessions, slow queries (лог).
- Инфраструктура
- CPU, memory, GC pauses, thread count, file descriptors, disk I/O, network errors/retransmits.
- Прочее
- Retries count per tx, duplicate detections, timeouts.
- Alarms/SLAs
- Alert, если ratio committed/received < threshold (напр. $95\%$) или if queue lag grows.
4) Логирование и трассировка (must)
- Correlation IDs: каждый входящий запрос и его транзакция должны иметь уникальный transaction_id и correlation_id, которые проходят через все сервисы и логи.
- Structured logs (json) с полями: timestamp, transaction_id, correlation_id, component, host, thread, event (received/enqueued/processed/committed), latency_ms, error (type, code, stack).
- Пределы логов: включить DEBUG/TRACE на подозрительных компонентах в тестовом окружении.
- Distributed tracing (Jaeger/Zipkin): собрать полные спаны для всех потерянных транзакций; включить трассирование ошибок 100%.
- DB и broker logs: включить binlog/WAL / slow_query_log / broker audit logs.
- Capture snapshots: при обнаружении пропажи, сохранить полные логи трассы и метрики окна времени.
5) Как локализовать проблему — пошаговый план
- 1) Воспроизвести: создайте тестовый стенд, максимально приближённый к проду (данные, конфигурации, нагрузка). Запустите нагрузку, пока не проявится потеря tx.
- 2) Корреляция: найдите transaction_id пропавшей tx; проследите следы в логах: API -> enqueue -> consumer -> DB.
- 3) Определить этап, где «теряется» запись:
- Если есть запись «accepted» в API, но нет «enqueued» — проблема на входе/producer.
- Если «enqueued», но нет «processed» — проблема в broker/consumer (lag, ack, visibility).
- Если processed, но нет commit — проблема в worker/DB (ошибка/rollback).
- 4) Изолировать компонент:
- Отключите/замените компонент заглушкой (например, при direct write минуя очередь) — если проблема исчезла, виноват broker/queue.
- Бинарный поиск: поочерёдно заменяйте/выключайте части потока.
- 5) Собрать низкоуровневые данные:
- DB: check transaction logs, show engine innodb status, count rollbacks/deadlocks, посмотреть timeline транзакции и причины отката.
- Broker: проверить подтверждения (acks), requeues, visibility-timeouts, retention, денормализацию.
- Network: tcpdump/pcap в момент ошибки, посмотреть ресет/timeout.
- JVM/Runtime: heap dump, thread dump, GC log (если GC pauses), pprof/async-profiler.
- 6) Рейс-конкурентность и гонки:
- Запустить специальные concurrency tests с большими параллелизмами и с искусственным замедлением частей кода, чтобы воспроизвести race condition.
- Использовать tools для детекции data races (например, race detector в Go).
- 7) Property-based и model checking:
- Сгенерировать последовательности операций, сверять инварианты, искать counterexample.
- 8) Fault injection:
- Симулировать сетевые разрывы, сбросы брокера, искусственные ошибки БД, истечение времени ожидания на commit.
- 9) Минимальный воспроизводимый кейс:
- После локализации собрать минимальный сценарий, который reliably reproduces bug; на его основе написать regression тест.
6) Исправление и защита от повторения
- Добавить idempotency keys и гарантии at-least-once vs exactly-once по архитектуре.
- Убедиться в корректности retries: backoff, дедупликация, корректная обработка результата retry.
- Обработать откаты: логировать причину отката и ретраить/сохранять в dead-letter queue.
- Тесты: блок регресс и stress тест на CI, property-based test покрывающий найденный кейс.
- Наблюдаемость: оставить расширенное логирование + трассировку для первых N процентов прод-трафика после релиза (canary).
7) Примеры инвариантов для property-based тестов
- «Сумма по всем счетам после серии операций = исходная сумма + sum(инфиксы)» (проверять для произвольной последовательности).
- «Если API вернул success для transaction_id, то через $T$ с запись должна быть в БД» (например $T=30$ с).
- «Нельзя потерять транзакцию без соответствующей ошибочной записи в логах/DLQ».
8) Краткий чек-лист при расследовании
- reproducible? окружение/конфигурация совпадают с продом?
- есть ли correlation_id через стек?
- где последний лог о tx? (API/queue/worker/DB)
- DB: откаты/long transactions/deadlocks?
- Broker: ack/visibility/consumer lag?
- Connection pools exhausted? timeouts?
- Retries приводят к дубликатам или перезаписи?
- GC/threads/IO spikes во время потерь?
Если нужно, могу дать шаблон лог-сообщения с обязательными полями и пример сценариев нагрузочного теста (конкретные команды/скрипты для JMeter/k6/locust) или пример property-based теста на конкретном языке.