Услуга 06 / 08 // понять, что происходит в проекте

Технический
аудит
проекта.

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

Заказать аудит Узнать стоимость
Независимая оценка
Код · Архитектура · Безопасность · Инфраструктура
Взгляд со стороны выявляет то, что незаметно изнутри — накопленный долг, скрытые риски и точки роста. Изменения в код не вносятся — только анализ и рекомендации.
Срок
3–7
дней на полный аудит
Результат
Отчёт + план
Приоритеты: срочно, важно, хорошо.
01 — Кому подходит

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

— 01
Хотите понять реальное состояние проекта перед тем, как вкладывать в него дальше
— 02
Собираетесь нанять разработчика и хотите знать, с чем ему придётся работать
— 03
Проект тормозит или падает — и непонятно где именно и почему
— 04
Сменили подрядчика и хотите независимую оценку сделанного
— 05
Готовитесь к росту нагрузки и хотите убедиться, что система выдержит
— 06
Инвестор или партнёр просит техническую оценку проекта перед сделкой
02 — Что проверяю

Шесть направлений технического аудита

code · architecture · security · infra

Смотрю не только на код, но и на то, как проект живёт в проде

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

PHP / Laravel JavaScript / TypeScript React / Next.js PostgreSQL / MySQL Docker / Linux OWASP Top 10
01

Архитектура и структура проекта

Архитектура, которую не видно снаружи

Внешне проект может работать нормально, но внутри — бизнес-логика в контроллерах, God Objects на 2000 строк, круговые зависимости между модулями и полное отсутствие разделения ответственности. Это не эстетическая проблема: это причина, по которой каждая новая задача занимает в три раза дольше, чем должна.

Что проверяю

Разделение на слои: контроллеры, сервисы, репозитории, модели. Размер и связность модулей — нет ли God Objects и Spaghetti Code. Зависимости между компонентами: есть ли цикличность, соблюдается ли принцип единственной ответственности. Соответствие выбранной архитектуры реальным требованиям проекта.

Как фиксирую результат

Описываю архитектурные антипаттерны с конкретными примерами из кода — не «плохая структура», а «в файле OrderController.php 800 строк бизнес-логики, которая должна быть в сервисах». Для каждой проблемы — рекомендация и оценка усилий на исправление.

02

Качество кода и технический долг

Долг, который не виден в задачах

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

Что проверяю

Дублирование кода и нарушения DRY. Сложность функций и методов — цикломатическая сложность, длина, количество параметров. Покрытие тестами критичной бизнес-логики. Использование устаревших паттернов или библиотек. Читаемость и документированность нетривиальных мест.

Как фиксирую результат

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

03

Безопасность

Уязвимости, которые не вылезают в разработке

SQL-инъекции через непараметризованные запросы, XSS через неэкранированный вывод, CSRF без токенов, небезопасное хранение паролей, API без аутентификации, секреты в git-репозитории — это OWASP Top 10, которые встречаются в реальных проектах до сих пор. Проблема не в незнании, а в том, что под давлением сроков «добавим защиту потом».

Что проверяю

OWASP Top 10: инъекции, XSS, CSRF, небезопасная десериализация, открытые редиректы. Хранение credentials: секреты в коде, git-истории или конфигурационных файлах. Управление сессиями и аутентификацией. Авторизация: возможность доступа к чужим данным или действиям. Зависимости с известными уязвимостями.

Как фиксирую результат

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

04

Производительность и база данных

«Тормозит» — это не диагноз

«Страница грузится 8 секунд» — это симптом. Причина может быть в N+1 запросах к базе, отсутствии индексов, синхронных операциях в запросе, тяжёлых вычислениях без кеша или медленном рендеринге на фронтенде. Без измерений — это угадывание, и «оптимизация» часто улучшает не то место.

Что проверяю

N+1 запросы и неоптимальные ORM-запросы. Индексы: какие есть, каких не хватает, какие избыточны. Медленные запросы через EXPLAIN ANALYZE. Использование кеша: что кешируется, что должно кешироваться, нет ли проблем с инвалидацией. Core Web Vitals и производительность фронтенда.

Как фиксирую результат

Конкретные запросы с их реальным временем выполнения и планом. Список отсутствующих индексов с оценкой прироста. Рекомендации по кешированию с указанием, где именно и на сколько времени. Ориентировочный прирост производительности после исправления.

05

Инфраструктура и DevOps

Сервер, которого никто не настраивал

Проект работает, но: деплой делается вручную через FTP или SSH-команды, бэкапы не проверялись с момента настройки, мониторинга нет и о падении узнают от пользователей, секреты хранятся в .env прямо на сервере без ротации. Это стандартная картина для проектов, в которых DevOps «делал разработчик между делом».

Что проверяю

Процесс деплоя: воспроизводимость, откат при ошибке, время простоя. Бэкапы: частота, хранение, тестирование восстановления. Мониторинг: uptime, ошибки, медленные запросы, дисковое пространство. Управление секретами: где хранятся, кто имеет доступ, есть ли ротация. Версии ПО: PHP, Node.js, зависимости — актуальны ли, есть ли известные уязвимости.

Как фиксирую результат

Чеклист инфраструктурных рисков с приоритетами. Отдельно выделяю то, что может привести к потере данных или длительному простою — это первоочередные исправления вне зависимости от остального аудита.

06

Зависимости и стек технологий

Устаревший стек — нарастающий риск

PHP 7.4, Laravel 8, Node.js 14, jQuery 1.x — всё это вне активной поддержки. Критические уязвимости в таких версиях не будут закрываться патчами. При этом миграция через несколько мажорных версий — нетривиальная задача, которая становится сложнее с каждым месяцем откладывания.

Что проверяю

Версии ядровых зависимостей и фреймворков — актуальность и поддержка. npm/composer audit: зависимости с известными CVE. Заброшенные пакеты: библиотеки без обновлений более двух лет. Размер node_modules и bundle size фронтенда. Дублирующиеся зависимости, решающие одну задачу разными способами.

Как фиксирую результат

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

03 — Как проходит работа

Четыре этапа — от доступа до готового отчёта

Access

Получаю доступ

Репозиторий, доступ к серверу (read-only), ссылка на рабочее окружение. Подписываю NDA при необходимости. Никаких изменений в коде или конфигурации — только чтение.

Analysis

Провожу аудит

Изучаю код, архитектуру, конфигурацию и инфраструктуру по структурированному чеклисту. Фиксирую находки с конкретными примерами, не абстрактными формулировками.

Report

Готовлю отчёт

Структурированный документ: находки по категориям, уровень критичности каждой, конкретные примеры из кода и рекомендации по исправлению. Резюме с топ-5 приоритетами.

Debrief

Разбираем вместе

Созвон по итогам отчёта: отвечаю на вопросы, объясняю приоритеты, помогаю сформировать план работ. Вы уходите с ясным пониманием, что делать дальше.

04 — Результат

Что получаете после технического аудита

Не список претензий, а
план конкретных действий

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

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

Лучшее время для аудита — до, а не после проблемы

Аудит стоит дешевле одного серьёзного инцидента: утечки данных, длительного даунтайма или переписывания архитектуры под нагрузкой. Даже если всё «работает нормально» — независимая оценка покажет, насколько это устойчиво. Стоимость аудита фиксируется до старта. Изменения в код не вносятся.

Заказать аудит Заполнить бриф
обычно отвечаю в течение часа обсуждение бесплатно
работаем вместе на связи
<1 дн
ответ на
заявку
1:1
напрямую,
без посредников
0 ₽
за первое
обсуждение
Отвечаю быстро
в течение дня
Один исполнитель
единый контекст
05 — FAQ

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

Что нужно предоставить для аудита?
Доступ к репозиторию и, по возможности, read-only доступ к серверу или staging-окружению. Если есть документация по архитектуре или известные проблемы — передайте их тоже, это поможет сфокусироваться на важном. NDA подписываю при необходимости.
06 — Другие услуги
из каталога услуг
смотреть все →
— Доработка
Доработка существующего проекта
Перейти
— Оптимизация
Оптимизация скорости и стабильности
Перейти
— Поддержка
Поддержка и развитие продукта
Перейти

Хотите знать, в каком состоянии проект?

Расскажите о проекте — скажу, что именно проверю, сколько займёт и что будет в отчёте. Стоимость фиксируется до старта. Изменений в код нет.

Оставить заявку