Но прежде чем лезть во все новое, надо помнить о такой страшной штуке, как “технический долг”.

Любой более менее опытный инженер не раз сталкивался с ситуацией, когда нужно сделать работу “грязно”. Например, отключить Puppet agent и руками настроить firewall, пообещав себе сделать “как надо” на следующей неделе. Или договорившись делать все строго по Infra-as-Code, создать часть ресурсов под новый проект “руками”. Потому что “временно”. Потому что “сейчас надо дать хоть что-нибудь, поправим чуть позже”.

Кривые конфигурации, забытые и неустановленные обновления, недокументированные изменения - все это копится тяжким грузом, который со временем очень сложно разгрести и проще устроить катарсис, начав все с чистого листа.
От этого никуда не уйти, и небольшое количество технического долга будет вас преследовать вплоть до пенсии. Чтобы как-то жить с этим, можно применять то же “золотое” правило 80/20. Если вы работаете в проектной группе, выделяйте на проект 80% ресурсов и 20 на “выплату” долга.

Кредитором и плательщиком здесь выступаете вы сами, и если пропустите пару “платежей” (и абсолютно неважно по каким причинам), то попадете в кабалу, когда, уже наоборот, 80% времени уходит на решение технического долга и всего 20% на проект.

А менеджер-коллектор с паяльником уже стучится вам в дверь и шлет смски с угрозами.
Для тех, кто дружит с английским и/или Google Translate, есть полезная статейка о причинах, последствиях и способах избежания технического “дефолта”, что в твоем 98-ом: https://www.extremeuncertainty.com/technical-debt-technical-bankruptcy/