Как «временный» хак обошёлся нам в 4 часа даунтайма

8 месяцев назад мы делали интеграцию с платёжной системой. Дедлайн через 3 дня. Нормальная очередь событий не успевала.

«Временное» решение: дублировать состояние заказа в двух местах. Один флаг в основной таблице, второй в таблице платежей. Синхронизация вручную в коде.

«Потом перепишем». Я это согласовал. Моё решение как архитектора.

Через 8 месяцев инцидент в пятницу вечером. Гонка потоков. 340 заказов в рассинхронизированном состоянии. 4 часа даунтайма. Ручной скрипт на исправление данных. Клиенты без доступа к своим заказам.

Что я понял тогда:

1. «Временный» код это кредит под 40% годовых. Проценты копятся 2. Архитектор, согласовавший хак, отвечает за инцидент. Не разработчик 3. Компромисс надо документировать: что именно, почему, когда исправим 4. Дата исправления следующий спринт, не «когда-нибудь потом»

С тех пор у нас правило: каждый намеренный компромисс оформляется как TODO с датой, именем ответственного и ссылкой на тикет. Если дата прошла задача автоматически попадает в backlog следующего спринта.

Ты соглашался на «временные» решения которые потом аукнулись?