+, сам то всегда поймешь, а другим если с первого взгляда не понятно, то в пустую созданная модель

С мтч:
1. Техдолг может быть обнаружен как факт неполной работы при проверке структуры системы саппортом, аналитиком, бизнес-партнером при разборе инцидентов.
Архитектором на момент код ревью или ревью тр.
Клиентом на этапе приемки.
Аналитиком, разработчиком, тестировщиком при переиспользовании сервисов, их доработке. При 'тупых вопросах аналитика' во время актуализации тр после реализации.
Есть еще проверки аудита
Можно делать ревью апи и базы данных
В некоторых случаях можно выявить техдолг кривого кода из мониторинга системы, при превышении максимального порога ограничений нефункциональных требований

Как факт договорённости - в случае этапности проекта - сперва костыль, потом красота

Коллеги, что сейчас есть более легковесное, чем k8s? Как понимаю, docker swarm скорее мерт, чем жив. k8s слишком сложен.
От платформы контейнеризации ждем в первую очередь облегчение деплоя. Все эти истории про балансировку нагрузки, cannery deploy - скорее не к нам.

Нужно что то более простое, чем k8s, с сохранением возможности описать деплой в виде конфигов/скриптов.

Техдолг можно хранить как список задач в джире с тегом техдолга и делить по командам или проектам. Сделать себе выборку или отчет в джире по тегу не сложно. Либо обычным списком где угодно.

Куда уж проще

Так не нужно усложнять, можно и разбить на наборы простых диаграмм. А сотрудников нужно обучать, обязательно. Хорошо бы архитектурный стандарт в организации внедрить, для начала)))

Спасибо, хорошая пепяка для разработки под k8s.

Спасибо

Пожалуйста, чем богаты

)

Тут часто после вопроса, на тяге холливара, ответ моментально может улететь в стратосферу.

Мы также делаем. И на доске выделили отдельную полоску с задачами по тех долгу. И периодически в минуты, когда срочных задач становится чуть поменьше (или когда припекает от конкретного долга особо сильно) идем и разбираем.

На прошлом месте работы у нас были определенные стандарты, и если разработчик, дорабатывая модуль, их не соблюдал (проверялось при приемке крупных кусков функционала), ему возвращали задачу. "Выйди и войди, как положено!!"

Также были архитектурные комитеты, на которых обсуждались отдельные модули и скоуп техдолга по модулю,  а также идеи на развитие. По итогам что-то бралось в работу

"Предыдущий архитектор команды в свое время сказал, что по нашей системе у нас долг такого размера — это не технический долг, а,  скорее, техническая ипотека."
\\ из доклада LaModa

Я видел возникновение тех долга (любого) в процессе принятия решения. И соотвественно фиксация его в зоне ответственности принимающих решение.

Ниже уровнем бывает в процессе имплементации решения (было выбрано ошибочное или не оптимальное решение), и его имплементация создает долг. Теперь все зависит от исполнителя, вынесет он это выше, или примет решение сам. И фиксация опять на принимающем решение.