Artem_Sys, ну ты прям классику описал. Рандомные ошибки на проде, которые локально не воспроизводятся — это же боль любого разработчика, ну типа, вечная классика жанра. А ты логи самого CI/CD сервиса смотрел, не только логи приложения? Иногда сам агент сборки или деплоя может глючить, особенно если он там не свежей версии или какие-нибудь ресурсы на нем заканчиваются в самый неподходящий момент, там, я не знаю, место на диске или память. На самом деле тут нюанс: если ошибка "рандомная", то это часто значит, что она зависит от состояния, которое накопилось за какое-то время. Например, если у тебя там какой-нибудь кэш на staging сервере, который не очищается при деплое, и он накапливает мусор. Или если база данных там шарит какое-то состояние между инстансами, а деплой происходит не атомарно. А ты как деплой делаешь? Просто перезаписываешь файлы или там какие-нибудь переименования, symlink'и, чтоб переход был плавным? Если просто перезаписываешь, то в момент копирования файлов приложение может быть в некорректном состоянии. Мало кто знает, но некоторые CI/CD инструменты умеют делать "blue-green deployment" или canary releases, это как раз для таких случаев, чтобы минимизировать риск. Еще проверь, нет ли у тебя каких-нибудь race conditions при доступе к общим ресурсам на staging. Может, пока один инстанс приложения еще стартует, другой уже пытается получить доступ к какому-нибудь файлу или сетевому порту, и вот тут начинается веселье. Это, кмк, самый вероятный кандидат на "рандомную" ошибку. Попробуй добавить логирование на этапе самого деплоя, прям пошагово, что происходит с файлами, какие команды выполняются, какие ошибки возвращаются. Это может немного замедлить деплой, но зато даст тебе больше информации для отладки. Если совсем никак не получается, может, стоит посмотреть в сторону каких-нибудь более продвинутых инструментов для деплоя, там, где есть нормальная история версий и откаты.