"Wildberries крадёт заказы. Жёсткий баг заставляет покупки СРАЗУ уезжать обратно на склад, даже если срок хранения не истёк. Деньги при этом списываются! Проблема висит уже больше четырёх часов."

В СильныхИдеях разбираю подобные случаи и рекомендую, что с ними можно поделать:

"...В 98% проектов, где более-менее организовано нормальное тестирование, от вас ожидают множества модульных/регрессионных тестов, и небольшого количества высокоуровневых тестов. Причина в том, что интеграционные и сквозные тесты дорогие и медленные, и "покрыть" ими обычно удаётся лишь малую часть пространства состояний программы. Поэтому в мэйнстриме подразумевается, что лучше сосредоточиться на тестировании всех частей по отдельности, чем на тестировании того, как они все работают вместе.
Но глобальная корректность вообще никак не следует из локальной корректности. Вполне возможно, что каждая часть по отдельности будет надёжной, но система в целом поломается. Более того, вполне возможен эффект эмерджентности: ваша система начнёт проявлять совершенно непредсказуемое и никем не планировавшееся и не ожидавшееся поведение :) Чаще всего это случается, когда нестандартная комбинация фич нарушает глобальное поведение...

Зачастую нет очевидно неправильного прогнозируемого состояния. Система выглядит так, будто работает нормально, пока всё не сломается...

Данный класс ошибок -- глобальное свойство системы, модульные тесты не могут найти их через тестирование локального взаимодействия функций, и не могут подтвердить, что вы их избежали. Нам нужна трассировка поведения от начала до конца. Однако это огромное пространство состояний, и E2E тесты могут покрыть только (совсем небольшую) часть этого пространства...

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

Извините, вы обречены.