Когда переписывать ML/inference платформу из-за техдолга
Когда накопившийся технический долг оправдывает переписывание сервиса или ML-платформы с нуля, а когда лучше улучшать систему итеративно?
Ответить самому
Сначала сформулируйте ответ как на собеседовании, затем откройте разбор и оцените себя.
Короткий ответ
Переписывание оправдано, если техдолг измеримо ломает надежность, скорость разработки, стоимость эксплуатации или business-critical SLA сильнее, чем стоит миграция. По умолчанию лучше incremental migration с метриками, ownership и rollback.
Полный разбор
Решение о rewrite должно начинаться с измеримого ущерба: частые incidents, невозможность деплоить модели, отсутствие monitoring, высокая latency/cost, долгий onboarding, постоянные ручные операции, плохая testability или риск для critical business path. “Код некрасивый” сам по себе не аргумент.
Нужно сравнить стоимость текущего состояния со стоимостью миграции: сколько developer time уходит на поддержку, какие product initiatives блокируются, насколько сложно обеспечить compatibility и кто будет владеть новой платформой. Если система стабильна и редко меняется, точечные улучшения могут быть дешевле.
Безопасный путь - не big bang, а strangler pattern: выделить target interfaces, обернуть старый сервис, перенести один workflow, запустить old/new параллельно, сравнить метрики и держать rollback. Success criteria должны быть заранее: latency, failure rate, deployment frequency, incident time, model rollout time или cost.
Теория
Технический долг - экономический trade-off; rewrite имеет смысл только при доказуемой выгоде и управляемом migration risk.
Типичные ошибки
- Переписывать стабильную систему только из-за старого кода.
- Не оценить migration risk и compatibility.
- Не определить success metrics для нового решения.
Как отвечать на собеседовании
- Говорите через reliability, developer time и business risk.
- Предложите incremental migration вместо big bang по умолчанию.