Технический аудит продукта: когда нужен и что проверяют

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

Разберём, когда аудит нужен, что в него входит и как использовать результат.

Когда нужен технический аудит?

Технический аудит нужен, когда решение о деньгах или сроках зависит от состояния системы, а внутри команды нет независимого взгляда на неё. Чаще всего это переломные моменты в жизни продукта.

Типичные поводы:

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

Что проверяют при техническом аудите?

При техническом аудите проверяют всё, от чего зависит стоимость владения продуктом: архитектуру, качество кода, зависимости, безопасность, инфраструктуру, данные и процессы команды. Каждое направление даёт свой список рисков.

Направление	Что смотрим	Типичные находки
Архитектура	Структура модулей, связи, границы, интеграции	Всё связано со всем, бизнес-логика размазана по слоям
Качество кода	Читаемость, дублирование, соблюдение стандартов	Копипаста, огромные классы, отсутствие соглашений
Тесты	Покрытие критичных сценариев, стабильность	Тестов нет или они не запускаются
Зависимости	Версии фреймворка и библиотек, известные уязвимости	Устаревшая версия без обновлений безопасности
Безопасность	Авторизация, работа с вводом, секреты, доступы	Секреты в репозитории, доступ к чужим данным
Инфраструктура	Серверы, выкладка, бэкапы, мониторинг	Ручной деплой, бэкапы без проверки восстановления
Производительность	Медленные запросы, кеширование, нагрузка	Запросы без индексов, проблема N+1
Документация и процессы	README, описание архитектуры, ревью, релизы	Знания только в голове одного разработчика

Фото: Unsplash

Инструменты, которые ускоряют аудит

Часть проверок автоматизирована: анализ зависимостей, статический анализ кода, поиск секретов, профилирование запросов. Ручная работа — чтение ключевых модулей, разговоры с командой и проверка того, как система ведёт себя в реальных сценариях.

# Известные уязвимости в зависимостях
composer audit
npm audit --omit=dev

# Секреты, случайно попавшие в историю репозитория
gitleaks detect --source .

# Медленные запросы в PostgreSQL — по статистике pg_stat_statements
psql -c "SELECT calls, mean_exec_time, left(query, 80) FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 10"

Подробнее о поиске медленных запросов — в статье индексы в PostgreSQL, а о главных уязвимостях — в статье OWASP Top 10.

Что заказчик получает по итогам аудита?

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

Структура отчёта:

1. Краткий вывод для бизнеса: общее состояние, главные риски, рекомендация.
2. Критичные проблемы — то, что нужно исправить немедленно: уязвимости, риски потери данных.
3. Существенные проблемы — то, что замедляет развитие и увеличивает стоимость поддержки.
4. Рекомендации по улучшению с оценкой трудозатрат.
5. План по этапам: что делать в первый месяц, квартал, полгода.

Сколько длится аудит и как к нему подготовиться?

Аудит типичного веб-продукта у нас занимает от одной до трёх недель — это ориентир студии, а длительность зависит от объёма кода, числа сервисов и интеграций. Быстрее всего аудит идёт, когда аудиторы с первого дня получают доступы и возможность задать вопросы команде.

Что подготовить:

• доступ на чтение к репозиториям, включая историю изменений;
• доступ к тестовому окружению и, по возможности, к мониторингу и логам;
• описание архитектуры и интеграций, если оно есть;
• контакт разработчика или техлида, который знает систему;
• список проблем, которые беспокоят бизнес, — чтобы уделить им особое внимание.

Что делать после аудита?

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

Как обычно выглядит план после аудита:

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

Как организовать регулярную поддержку и сколько она стоит, мы разбирали в статье сколько стоит поддержка сайта и приложения.

Коротко

• Технический аудит — независимая проверка кода, архитектуры, инфраструктуры и процессов.
• Его заказывают перед покупкой или инвестициями, при смене подрядчика и при проблемах со скоростью разработки.
• Проверяются архитектура, код, тесты, зависимости, безопасность, инфраструктура и документация.
• Результат — отчёт с рисками по приоритету и план работ, понятный бизнесу.
• Ценность аудита — в действиях после него: критичное сразу, остальное по плану.