1) Разработчики RabbitMQ ко всем потерям данных на стороне самого RabbitMQ относятся критично, так что, если в какой-то момент будете уверены, что теряет данные именно он, то смело создавайте баг (с подробностями как повторить).
2) Если админы не умеют настраивать стейтфул приложения в контейнерной среде или куча ручных операций, то это больше административная задача, чтобы научиться и, например, использовать шаблоны/чарты/т.п. для предотвращения сюрпризов. Но также RabbitMQ в контейнере нужно настраивать, чтобы не получать деградации и дампов.
3) Со стороны самого RabbitMQ есть зеркалирование очередей (queue mirroring) для дублирования данных, что позволит внезапно терять ноды (но восстановление может обойтись высоким потреблением процессора).
4) Также рекомендую логировать и идентифицировать каждое отправленное и полученное сообщение, чтобы оценивать проблему. Для большей достоверности можно включить логирование ещё и на уровне RabbitMQ (если позволяют ресурсы). На прошлой работе у нас был свой плагин для RabbitMQ, который получал копию всех полученных и отправленных сообщений, выгребал из них нужную метаинформацию и отправлял в Graylog.
5) Ну и конечно нужно делать отправку и приём с подтверждением, но это, я думаю, Вы и без меня уже делаете.
Сложный
Средний
Простой
