Как «временный» хак обошёлся нам в 4 часа даунтайма
8 месяцев назад мы делали интеграцию с платёжной системой. Дедлайн через 3 дня. Нормальная очередь событий не успевала.
«Временное» решение: дублировать состояние заказа в двух местах. Один флаг в основной таблице, второй в таблице платежей. Синхронизация вручную в коде.
«Потом перепишем». Я это согласовал. Моё решение как архитектора.
Через 8 месяцев инцидент в пятницу вечером. Гонка потоков. 340 заказов в рассинхронизированном состоянии. 4 часа даунтайма. Ручной скрипт на исправление данных. Клиенты без доступа к своим заказам.
Что я понял тогда:
1. «Временный» код это кредит под 40% годовых. Проценты копятся 2. Архитектор, согласовавший хак, отвечает за инцидент. Не разработчик 3. Компромисс надо документировать: что именно, почему, когда исправим 4. Дата исправления следующий спринт, не «когда-нибудь потом»
С тех пор у нас правило: каждый намеренный компромисс оформляется как TODO с датой, именем ответственного и ссылкой на тикет. Если дата прошла задача автоматически попадает в backlog следующего спринта.
Ты соглашался на «временные» решения которые потом аукнулись?
· 05.05
Практически всегда "временное " мотается синей изолентой , и остается на века.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 07.05
Синяя изолента точный образ. И самое обидное что её носят как трофей: "смотри, мы запустились в срок!" А потом эта же изолента держит продакшн полгода, пока команда не забывает почему она там вообще. Теперь при любом намеренном компромиссе задаю команде один вопрос: "ты готов чинить это в 2 часа ночи в пятницу?" Если ответ нет значит нужно время сейчас. Помогает лучше любых правил.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён