1. Обложка отчета
Корпоративный портал и личный кабинет сотрудников
ЗаказчикУсловная компания, B2B / девелопмент / сервисная группа
Период аудита10 рабочих дней
Объем аудитаbackend, frontend, архитектура, интеграции, CI/CD, тесты, документация
Команда аудитаархитектор ПО, backend, frontend, QA, DevOps
Версия отчета1.0
2. Executive summary
Система работает, но дальнейшее развитие связано с повышенными рисками
Система находится в рабочем состоянии и может поддерживать текущие бизнес-процессы, но дальнейшее развитие связано с повышенными рисками по срокам, качеству релизов и стоимости доработок.
Бизнес-логика распределена между контроллерами, моделями, фоновой обработкой и frontend-слоем.
Критические сценарии недостаточно покрыты автоматическими тестами.
Интеграции реализованы точечно, без единого слоя и общей модели ошибок.
Накоплен технический долг: дублирование логики, устаревшие зависимости, слабая документация.
Релизный процесс частично зависит от ручных действий.
Общий вывод: систему не нужно переписывать с нуля. Рациональный сценарий — стабилизация, устранение критичных рисков и постепенная модернизация по модулям.
3. Итоговая оценка
Суммарная оценка зрелости: 53 / 100
Рекомендуемый сценарий: стабилизация за 1-2 месяца и плановая модернизация за 3-6 месяцев.
53 из 100
Уровень зрелости
Рабочая система с управляемой зоной риска
График показывает, что продукт можно развивать без переписывания с нуля, если сначала закрыть тестирование, документацию, интеграции и релизный контур.
32 риска в карте
9 Critical / High
4-8 нед. первый этап стабилизации
| Направление | Оценка | Комментарий |
|---|---|---|
| Архитектура | 58 / 100 | Архитектура работоспособна, но границы модулей размыты. Есть риск роста стоимости доработок. |
| Качество backend-кода | 62 / 100 | Код поддерживаемый, но есть дублирование, смешение ответственности и слабое покрытие тестами. |
| Качество frontend-кода | 55 / 100 | Основные сценарии работают, но есть дублирование компонентов, сложное состояние и неоднородная работа с API. |
| Интеграции | 51 / 100 | Интеграции решают текущие задачи, но плохо документированы и слабо защищены от отказов внешних систем. |
| Безопасность прикладного уровня | 57 / 100 | Критичных подтвержденных инцидентов не выявлено, но есть зоны повышенного риска. Нужен отдельный security-аудит. |
| Производительность | 60 / 100 | Есть узкие места в отчетах, списках и массовых операциях. Часть проблем решается быстрыми оптимизациями. |
| Тестирование и QA | 42 / 100 | Автотесты покрывают не все критические пользовательские и интеграционные сценарии. |
| CI/CD и эксплуатация | 50 / 100 | Сборка и деплой есть, но релизный процесс недостаточно формализован. |
| Документация | 38 / 100 | Документация фрагментарная. Новым участникам команды сложно быстро войти в проект. |
4. Карта рисков
Приоритеты Critical / High / Medium / Low
Всего рисков 32
28% рисков находятся в зоне Critical / High и должны идти в первый план стабилизации.
Critical 2 шт.
High 7 шт.
Medium 14 шт.
Low 9 шт.
Влияние
Вероятность
Потеря данных Остановка релиза Регрессии Интеграции Роли Тесты Документация UI-долг Critical 2
Может привести к остановке критичного процесса, потере данных или невозможности безопасно развивать систему.
High 7
Существенно влияет на сроки, стоимость доработок, стабильность релизов или безопасность.
Medium 14
Требует планового исправления, чтобы не накапливать технический долг.
Low 9
Локальные улучшения качества, документации и удобства сопровождения.
5. Что входило в аудит
Область проверки и ограничения
В аудит включены
- backend-код приложения
- frontend-код приложения
- архитектура модулей и границы ответственности
- интеграции с CRM, 1С, ЭДО и внутренними сервисами
- структура базы данных и основные запросы
- авторизация, роли и права доступа
- обработка ошибок
- фоновая обработка задач
- CI/CD и релизный процесс
- тестовое покрытие
- техническая документация
- наблюдаемость: логи, метрики, алерты
Не входило в аудит
- полноценный pentest
- нагрузочное тестирование под промышленной нагрузкой
- юридическая оценка обработки персональных данных
- аудит инфраструктуры дата-центра
- ревизия финансовой модели проекта
- проверка всех исторических веток и архивных репозиториев
6. Исходный технический контекст
Пример стека указан условно
| Backend | Python / Django / Django REST Framework |
|---|---|
| Frontend | React / TypeScript |
| База данных | PostgreSQL |
| Фоновые задачи | Celery / Redis |
| Интеграции | 1С, CRM, ЭДО, внутренние API |
| CI/CD | GitLab CI, Docker |
| Среды | dev, stage, production |
| Документация | README, отдельные Confluence/Notion-страницы, частично устаревшие схемы |
7. Ключевые находки
10 примеров проблем, рисков и рекомендаций
F-01 High
Бизнес-логика распределена между несколькими слоями
- Зона
- backend / архитектура
- Влияние
- рост стоимости доработок, высокий риск регрессий, сложность онбординга новых разработчиков
- Описание
- Часть бизнес-правил реализована в моделях, часть во view/controller-слое, часть в фоновых задачах, часть на frontend. Один и тот же сценарий может исполняться по-разному в зависимости от точки входа: API, админка, фоновая задача или ручной импорт.
- Риск для бизнеса
- При доработке одного сценария команда может не учесть альтернативные точки изменения данных. Это повышает вероятность ошибок в статусах, некорректных уведомлений и расхождений между системами.
- Рекомендация
- Выделить единый слой доменной логики для статусов заявок, согласований, интеграционных событий, уведомлений и проверок прав. Начать с одного критичного процесса и провести рефакторинг как пилот.
- Приоритет
- P1
F-02 High
Недостаточное покрытие автотестами критических сценариев
- Зона
- QA / backend / frontend
- Влияние
- нестабильные релизы, ручная приемка, увеличение сроков выпуска изменений
- Описание
- Автотесты присутствуют, но покрывают в основном базовые сценарии и отдельные функции. Критические бизнес-процессы не покрыты end-to-end или интеграционными тестами.
- Риск для бизнеса
- Каждый релиз требует значительного ручного тестирования. При ускорении разработки вероятность пропуска критичных дефектов будет расти.
- Рекомендация
- Сформировать минимальный регрессионный набор: 10-15 критичных API-тестов, 5-7 end-to-end сценариев, smoke-тест после деплоя и тесты на права доступа для ключевых ролей.
- Приоритет
- P1
F-03 High
Интеграции реализованы без единой модели ошибок
- Зона
- интеграции / эксплуатация
- Влияние
- потеря прозрачности, ручные разборы инцидентов, риск расхождения данных
- Описание
- Интеграции с внешними системами реализованы в разных стилях. Для части обменов есть повторные попытки, для части нет. Не везде фиксируется единый correlation ID.
- Риск для бизнеса
- Если внешняя система недоступна или возвращает ошибку, пользователь может не понимать статус операции. Поддержка вынуждена разбирать проблему вручную по логам.
- Рекомендация
- Создать единый интеграционный слой: журнал обменов, статусы обработки, повторные попытки, dead-letter очередь, бизнес-интерфейс просмотра ошибок и регламент повторной отправки.
- Приоритет
- P1 для критичных интеграций, P2 для второстепенных
F-04 High
Ролевая модель описана не полностью
- Зона
- безопасность / backend / frontend
- Влияние
- риск некорректного доступа к данным, сложность поддержки новых ролей
- Описание
- Права доступа проверяются в нескольких местах: backend permissions, frontend guards, административные настройки и отдельные условия в бизнес-логике. Документированной матрицы ролей и операций нет.
- Риск для бизнеса
- При добавлении новой роли или изменении процесса есть риск открыть доступ шире, чем требуется, либо заблокировать нужный сценарий.
- Рекомендация
- Подготовить матрицу ролей и унифицировать проверки на backend. Frontend использовать только как вспомогательный слой отображения.
- Приоритет
- P1, если система содержит персональные, финансовые или договорные данные
F-05 Medium
Есть признаки N+1-запросов и неоптимальных выборок
- Зона
- backend / база данных / производительность
- Влияние
- замедление списков, отчетов и массовых операций
- Описание
- В нескольких списках и отчетах данные загружаются через последовательные запросы к связанным объектам. На малых объемах это незаметно, но при росте количества заявок и документов время ответа будет увеличиваться.
- Риск для бизнеса
- Пользовательские сценарии со списками, отчетами и массовыми действиями будут замедляться по мере роста данных.
- Рекомендация
- Добавить профилирование SQL-запросов, оптимизировать выборки через select_related / prefetch_related или аналоги ORM, добавить индексы и вынести тяжелые отчеты в фоновые задачи.
- Приоритет
- P2, но может стать P1 при росте нагрузки
F-06 Medium
Часть зависимостей устарела
- Зона
- backend / frontend / безопасность
- Влияние
- риск несовместимости, уязвимостей, сложность обновлений
- Описание
- В проекте есть зависимости, которые давно не обновлялись. Часть библиотек используется в старых major-версиях.
- Риск для бизнеса
- Массовое обновление рискованно из-за недостаточного тестового покрытия, а откладывание обновлений повышает security-риск.
- Рекомендация
- Зафиксировать версии, проверить известные уязвимости, обновить низкорисковые patch/minor-версии и вынести major-обновления в отдельные задачи.
- Приоритет
- P2. Критичные security-обновления — P1
F-07 Medium
Релизный процесс зависит от ручных действий
- Зона
- DevOps / CI/CD
- Влияние
- риск ошибки при выкладке, нестабильные релизы, зависимость от отдельных сотрудников
- Описание
- Сборка и деплой автоматизированы частично. Отдельные шаги выполняются вручную или требуют знания неформального регламента.
- Риск для бизнеса
- Релиз может зависеть от конкретного сотрудника и неформальной памяти команды.
- Рекомендация
- Формализовать checklist релиза, smoke-тест, миграции с проверкой обратимости, rollback, stage-контур и журнал релизов.
- Приоритет
- P2. Если релизы частые — P1
F-08 Medium
Frontend содержит дублирование бизнес-правил
- Зона
- frontend / архитектура
- Влияние
- риск расхождения поведения frontend и backend
- Описание
- На frontend реализованы проверки, которые частично дублируют backend-логику: доступность действий, переходы статусов, фильтрация операций по ролям.
- Риск для бизнеса
- Правила могут разойтись между frontend и backend, особенно при появлении новых ролей и статусов.
- Рекомендация
- Перенести ключевые правила на backend, а frontend использовать для отображения доступных действий, полученных из API.
- Приоритет
- P2
F-09 Medium
Документация не отражает фактическую архитектуру
- Зона
- документация / сопровождение
- Влияние
- сложный онбординг, риск ошибок при доработках
- Описание
- Документация есть, но часть схем устарела. Нет единого актуального описания модулей, интеграций, ролей и релизного процесса.
- Риск для бизнеса
- Новые участники команды дольше входят в проект, а изменения повышают риск регрессий.
- Рекомендация
- Подготовить карту модулей, карту интеграций, матрицу ролей, описание релизного процесса, инструкцию локального запуска и список известных ограничений.
- Приоритет
- P2
F-10 High
Нет единой стратегии модернизации
- Зона
- управление разработкой / архитектура
- Влияние
- риск хаотичного рефакторинга и перерасхода бюджета
- Описание
- У команды есть понимание локальных проблем, но нет согласованной дорожной карты модернизации: что исправлять первым, какие модули трогать, как оценивать эффект, какие изменения опасны для бизнеса.
- Риск для бизнеса
- Рефакторинг может стать набором несвязанных задач без измеримого управленческого эффекта.
- Рекомендация
- Сформировать дорожную карту на три горизонта: быстрые стабилизирующие изменения, модульный рефакторинг критичных процессов и архитектурная модернизация интеграций.
- Приоритет
- P1
8. Архитектурная оценка
Рекомендуется двигаться к модульному монолиту
Система развивается как монолитное приложение с несколькими интеграционными точками и отдельными фоновыми задачами. Переход на микросервисы не рекомендуется как первый шаг: это увеличит сложность и не решит базовые проблемы качества.
Application
├── Modules
│ ├── Requests
│ ├── Documents
│ ├── Approvals
│ ├── Notifications
│ ├── Integrations
│ └── Users / Roles
├── Domain services
├── Integration layer
├── API layer
├── Background jobs
└── Shared infrastructure Почему не переписывать с нуля: полная перепись несет риск потери бизнес-логики, повторения старых ошибок, параллельной поддержки и роста бюджета без гарантии результата.
9. Рекомендованная дорожная карта
От быстрых исправлений к модернизации
1-2 недели
Этап 0. Быстрые исправления
Снизить самые очевидные риски без глубокого рефакторинга.
| Задача | Эффект | Приоритет / оценка |
|---|---|---|
| Составить матрицу ролей и критичных операций | Уменьшение риска некорректного доступа | P1 |
| Добавить smoke-тесты для 5-7 ключевых сценариев | Более безопасные релизы | P1 |
| Проверить и обновить критичные зависимости | Снижение security-рисков | P1 |
| Добавить индексы для самых тяжелых списков | Ускорение интерфейсов | P2 |
| Зафиксировать checklist релиза | Меньше ручных ошибок | P2 |
| Составить карту интеграций | Понимание зависимостей и рисков | P1 |
1-2 месяца
Этап 1. Стабилизация
Сделать систему предсказуемой для дальнейшего развития.
| Задача | Эффект | Приоритет / оценка |
|---|---|---|
| Выделить доменную логику для статусов и согласований | Снижение регрессий | 15-25 чел.-дней |
| Ввести интеграционный журнал | Прозрачность обменов | 10-20 чел.-дней |
| Покрыть критичные сценарии API/e2e-тестами | Стабильнее релизы | 15-30 чел.-дней |
| Унифицировать обработку ошибок API | Понятнее поддержка и UX | 8-15 чел.-дней |
| Подготовить актуальную техдокументацию | Быстрее онбординг | 5-10 чел.-дней |
| Формализовать CI/CD и rollback | Ниже риск релизов | 8-15 чел.-дней |
3-6 месяцев
Этап 2. Модернизация
Снизить стоимость развития и подготовить систему к масштабированию.
| Задача | Эффект | Приоритет / оценка |
|---|---|---|
| Перейти к модульной структуре backend | Ниже связанность | 40-80 чел.-дней |
| Пересобрать интеграционный слой | Стабильнее обмены | 30-60 чел.-дней |
| Перепроектировать frontend-state для ключевых разделов | Меньше ошибок UI | 25-50 чел.-дней |
| Ввести observability: метрики, алерты, трассировка | Быстрее поиск инцидентов | 20-40 чел.-дней |
| Обновить major-зависимости | Поддерживаемость и безопасность | 25-60 чел.-дней |
10. Рекомендуемый backlog исправлений
Задачи для команды разработки
| ID | Задача | Приоритет | Сложность | Ожидаемый эффект |
|---|---|---|---|---|
| B-01 | Сформировать матрицу ролей и доступов | P1 | M | Снижение security-рисков |
| B-02 | Выделить единый сервис изменения статусов | P1 | L | Меньше регрессий в бизнес-процессах |
| B-03 | Добавить API-тесты для критичных сценариев | P1 | M | Стабильнее релизы |
| B-04 | Настроить smoke-тест после деплоя | P1 | S | Быстрое обнаружение проблем релиза |
| B-05 | Составить карту интеграций и форматов обмена | P1 | M | Понятная зона модернизации |
| B-06 | Добавить интеграционный журнал | P1 | L | Прозрачность ошибок обмена |
| B-07 | Оптимизировать тяжелые списки и отчеты | P2 | M | Быстрее интерфейсы |
| B-08 | Обновить критичные зависимости | P1 | M | Снижение security-рисков |
| B-09 | Описать релизный процесс и rollback | P2 | S | Меньше ручных ошибок |
| B-10 | Унифицировать обработку ошибок API | P2 | M | Лучше UX и поддержка |
| B-11 | Перенести дублирующую frontend-логику на backend | P2 | L | Меньше расхождений правил |
| B-12 | Актуализировать техническую документацию | P2 | M | Быстрее онбординг |
11-13. Управленческие выводы
Что можно делать дальше
Что можно сделать без большого бюджета
- Матрица ролей.
- Карта интеграций.
- Smoke-тесты и критичные API-тесты.
- Checklist релиза и rollback.
- Обновление зависимостей с критичными уязвимостями.
- Оптимизация 2-3 самых тяжелых пользовательских сценариев.
Что не рекомендуется делать
- Переписывать систему с нуля без экономического обоснования.
- Начинать масштабный рефакторинг без тестов и карты критичных сценариев.
- Выносить модули в микросервисы только ради микросервисов.
- Обновлять все зависимости одновременно без регрессионного набора.
- Менять подрядчика без передачи документации, доступа и знаний по интеграциям.
Только отчет и самостоятельная реализация
Заказчик использует отчет как внутреннюю дорожную карту для своей команды или текущего подрядчика.
Подходит, если у заказчика есть сильная внутренняя команда разработки.Пилотная стабилизация
Исполнитель берет 1-2 критичных зоны и показывает результат на ограниченном участке: интеграционный журнал, тесты критичного процесса, checklist релиза.
Подходит, если заказчик хочет проверить подрядчика перед большим контрактом.Модернизация по roadmap
После согласования приоритетов команда берет систему на плановую модернизацию.
Подходит, если нужно снизить техдолг и ускорить развитие продукта.Сопровождение и развитие
Команда подключается как выделенная группа: backend, frontend, QA, DevOps, аналитик/PM.
Подходит, если у заказчика не хватает ресурсов или текущий подрядчик не справляется.14-15. Формат результата
Пример структуры финального PDF-отчета
Состав PDF/Docx
- Резюме для руководства
- Общая оценка зрелости системы
- Карта рисков
- Список критичных находок
- Архитектурная схема текущего состояния
- Рекомендуемая целевая архитектура
- Анализ backend
- Анализ frontend
- Анализ интеграций
- Анализ тестового покрытия
- Анализ CI/CD и эксплуатации
- Анализ документации
- Backlog исправлений
- Roadmap на 1-2 недели, 1-2 месяца и 3-6 месяцев
- Предварительная оценка трудозатрат
- Приложения: чек-листы, таблицы, ссылки на артефакты
Краткая версия для лендинга
- отчет по коду, архитектуре, тестам, интеграциям и релизному процессу
- карту рисков с приоритетами Critical / High / Medium / Low
- список конкретных проблем с влиянием на бизнес
- рекомендации по исправлению
- backlog задач для команды разработки
- roadmap стабилизации и модернизации
- предварительную оценку трудозатрат
- вывод: развивать систему, модернизировать по модулям или готовить замену
16-18. Старт аудита
Чек-лист входных данных для аудита
- Доступ к репозиториям
- Описание основных бизнес-процессов
- Список критичных пользовательских сценариев
- Описание ролей и прав доступа
- Список интеграций
- Доступ к документации
- Описание релизного процесса
- Список известных проблем
- Информацию о средах dev/stage/prod
- Контакты технического ответственного со стороны заказчика
Финальный вывод примера: система пригодна для дальнейшего развития, но требует стабилизации перед расширением функциональности. Первый рекомендуемый шаг — короткий проект стабилизации на 4-8 недель с измеримыми результатами.