Технический аудит нужен, когда решения о деньгах и сроках принимаются вслепую: команда говорит «всё сложно», релизы буксуют, а инвестор или основатель не понимает, где кончается объективная сложность и начинается запущенный техдолг. Аудит переводит ощущения в цифры и артефакты, на которые можно опираться при планировании.

Работа охватывает три слоя. Код — читаемость, связанность, покрытие тестами, дублирование, статический анализ, разбор критичных модулей вручную. Архитектура — границы компонентов, модель данных, узкие места, точки отказа, зависимости от внешних систем. Инфраструктура — деплой, окружения, мониторинг, бэкапы, секреты, стоимость облака и запас по нагрузке.

Отдельный блок — процессы и команда. Смотрю, как устроены ветки и релизы, есть ли code review и CI, как быстро правка доезжает до прода, как обрабатываются инциденты. Оцениваю DORA-метрики (частота деплоев, lead time, MTTR, доля откатов) и бас-фактор — где знание держится на одном человеке и что будет при его уходе.

Результат — не «список замечаний», а решение к действию. Отчёт содержит карту рисков с оценкой вероятности и последствий, техдолг, разложенный по стоимости устранения, и roadmap на 3–6 месяцев с приоритетами. Каждый пункт сопровождается обоснованием: почему это важно, что случится, если не трогать, и сколько примерно стоит починка. По итогу — часовая защита отчёта с ответами на вопросы команды.

Технический аудит

$ cat описание.md

$ uname -a # методы и артефакты

$ ls -1 что-входит/

$ grep -r "типовые задачи"

$ ./process.sh --steps

$ whoami && echo $RESULT

Для кого

Результат

$ cat faq.md