Техдолг. Все говорят: "невозможно", а я говорю, что буду Техдолг

Уже много было сказано про "распил монолитов". Много было дискуссий про то, переписывать или нет. Активно идут обсуждения о том, как и от чего отталкиваясь, нужно бороться с возрастающей сложностью микросервисов.

Поговорить об этом хорошо, но когда это делать? Реинжиниринг, техдолг, рефакторинг. Все эти движения в рамках успешного, активно развивающегося, высоконагруженного сервиса очень болезненно вписываются в бэклог продукта. Который расписан, может быть, на два года вперёд, и у продакта возникает острое желание послать к черту всю эту "новую этику" и тупо утилизировать ресурс команды.

Если на это пойти, сломаться, поддаться темной стороне силы, то со временем продукт превращается в сильно связанного кровоточащего Левиафана, к которому сильно выросшая в размерах команда со всех сторон пытается наживую прибить новые части тела.

Но взять и посадить этот самолёт, у которого SLO 24/7, в ангар для исправления накопленного техдолга шансов нет никаких.

Как быть? Строить самолёт на лету! И да, это возможно. Управление техдолгом — это не сказка о розовых пони, это болезненный для техдиректора процесс, который вытягивает из него все соки, заставляет непрерывно находить компромисс, верить настраивать и вдохновлять, когда, кажется, никто не верит.

И это норм, это просто такая работа.

Про это как раз и расскажу. Как сделали техдолг видимым и осязаемым. Как боролись за реальное понимание в головах как менеджеров, так и разработчиков — что из этого действительно страшно, а что пока ещё нормально. Как меняли методы и способы выделения времени, ресурсов, людей на решение задач. На какие уловки я иду, чтобы это все протаскивать.