Новый подрядчик часто получает первую задачу в повелительном наклонении: «поправьте форму сегодня», «добавьте поле в заказ» или «обновите Битрикс». Но безопасная первая правка начинается не с файла шаблона, а с понимания, куда попал разработчик. На действующем сайте маленькое изменение может затронуть интеграцию, кеш, обработчики событий или код, о котором заказчик не знает.
Аудит перед первой доработкой не обязательно превращать в многонедельное обследование. Его глубина зависит от риска задачи. Однако есть минимальный набор проверок, без которого нельзя уверенно обещать, что изменение не повредит рабочему процессу.
Зачем бизнесу оплачивать вводный аудит
Результат аудита — не абстрактное мнение о качестве кода. Он должен ответить на практические вопросы:
- можно ли безопасно вносить запрошенное изменение;
- где находится соответствующая логика и от чего она зависит;
- как проверить результат до публикации;
- как вернуть предыдущую версию при проблеме;
- какие критичные риски требуют отдельного решения;
- что нужно задокументировать для дальнейшей поддержки.
Для небольшой задачи достаточно короткой технической разведки. Для обновления платформы, изменения заказа или восстановления обмена нужен более широкий охват. Цель — соотнести объём проверки с ценой ошибки, а не изучать весь проект «на всякий случай».
1. Зафиксировать границы и бизнес-критичность
Перед входом в административную панель полезно описать текущий и желаемый сценарии. Кто пользуется функцией? Какие данные создаются? Что считается успешным результатом? Есть ли зависимость от оплаты, оформления заказа, CRM или 1С?
Также важно узнать режим работы сайта. Изменение информационного блока и изменение расчёта стоимости доставки требуют разного контроля. Для критичных операций нужно заранее определить допустимое окно работ, ответственного за бизнес-проверку и способ остановить выпуск.
Аудитор должен отделить симптомы от задачи. «Форма иногда не отправляется» — симптом. Причиной могут быть JavaScript, серверная валидация, почта, антиспам или CRM API. Если сразу исправлять первый замеченный фрагмент, проблема может остаться.
2. Проверить доступы и ответственность
Нужны отдельные учётные записи с достаточными, но не избыточными правами. Общий пароль администратора не позволяет понять, кто менял настройки. Для полноценной диагностики обычно требуются:
- административная панель;
- файлы через SSH или панель хостинга;
- база данных в режиме, соответствующем задаче;
- репозиторий и история изменений;
- журналы веб-сервера и PHP;
- кабинеты внешних сервисов либо безопасно выданные тестовые ключи;
- доступ к тестовому контуру.
Пароли и токены нельзя пересылать в открытых задачах и хранить в репозитории. Одновременно следует проверить, кому принадлежат домен, хостинг, лицензия и внешние кабинеты. Технически исправный проект остаётся бизнес-риском, если критичный аккаунт зарегистрирован на бывшего сотрудника.
3. Подтвердить резервное копирование и восстановление
Надпись «бэкап настроен» не гарантирует восстановление. До первой рискованной операции нужно узнать:
- что копируется: файлы, база, пользовательские загрузки, настройки окружения;
- как часто и где хранятся копии;
- когда завершилась последняя успешная копия;
- кто умеет восстановить проект и сколько шагов для этого требуется;
- есть ли отдельная копия вне того же сервера.
Для конкретной доработки делается актуальная точка восстановления. Но бэкап — не замена системе контроля версий: он возвращает состояние целиком, тогда как Git позволяет увидеть и откатить изменения кода.
4. Снять технический профиль проекта
Аудит фиксирует редакцию и версию 1С-Битрикс, версию PHP, базу данных, веб-сервер и ключевые системные настройки. Проверяются совместимость, срок поддержки окружения и наличие критичных предупреждений в проверке системы.
Затем составляется карта структуры:
- локальные компоненты и их шаблоны;
- собственные модули;
- обработчики событий;
- init.php и подключаемые файлы;
- cron-задачи и агенты;
- маршруты и API-обработчики;
- изменения сторонних решений;
- места, где затронуто ядро.
Особенно опасны прямые правки файлов платформы или Marketplace-модуля. Обновление может их уничтожить. Найденный факт не означает немедленную переделку всего сайта, но должен влиять на способ реализации новой задачи.
5. Понять модель данных
Перед изменением каталога или заказа нужно определить источники истины. Свойство может редактироваться в Битрикс, приходить из 1С или рассчитываться обработчиком. Если разработчик не знает владельца данных, его правка исчезнет после следующего обмена.
Проверяются инфоблоки, свойства, пользовательские поля, типы цен, склады, статусы заказов и связи по XML_ID. Для собственной таблицы важны миграции и описание назначения. Полезно проследить один реальный объект по цепочке: от создания до отображения и передачи наружу.
Следует отдельно найти дублирующие справочники. Два поля «ИНН» или несколько способов хранить внешний ID создают ошибки не сами по себе, а из-за отсутствия однозначного правила выбора.
6. Инвентаризировать интеграции
Интеграция может работать в фоне и не быть видна на странице. Составьте перечень 1С, CRM, платежей, доставки, телефонии, почты, аналитики и webhook. Для каждой связи зафиксируйте:
- направление и состав данных;
- способ авторизации и место хранения секретов;
- расписание или событие запуска;
- таймауты и повторные попытки;
- защиту от дублей;
- журналирование и уведомление об ошибках;
- тестовую среду и контакт владельца системы.
Первая доработка формы может изменить имя поля, которое ожидает CRM. Обновление каталога может повлиять на XML_ID. Поэтому карта интеграций нужна даже тогда, когда задача напрямую не называется интеграционной.
7. Оценить качество процесса разработки
Наличие Git само по себе мало что говорит. Важно, соответствует ли рабочий сайт репозиторию, есть ли незакоммиченные изменения на сервере и понятен ли процесс выпуска. Если код редактировали прямо в production, сначала полезно зафиксировать его текущее состояние.
Минимально зрелый процесс включает:
- отдельную ветку или набор изменений под задачу;
- тестовую копию с обезличенными данными, если это необходимо;
- список проверок до и после выпуска;
- понятный способ миграции настроек и базы;
- план отката;
- запись о том, что изменено.
Для разовой правки процесс может быть лёгким, но он не должен сводиться к редактированию production без истории.
8. Проверить наблюдаемость и производительность
До изменения полезно зафиксировать исходное поведение. Какие ошибки уже есть в логах? Какие страницы медленные? Работают ли cron и агенты? Не переполнен ли диск? Иначе после выпуска разработчику припишут старую проблему или, наоборот, он не заметит новую.
Не нужно начинать с тотальной оптимизации. Достаточно проверить сценарии, связанные с задачей, и базовое здоровье системы. Для каталога — время ответа и тяжёлые запросы; для интеграции — очередь и последние ошибки; для формы — серверные события и доставку результата.
9. Выполнить базовую проверку безопасности
Полный аудит безопасности — отдельная услуга, но перед первой доработкой нельзя игнорировать очевидные риски:
- публично доступные резервные копии и служебные файлы;
- секреты в коде или репозитории;
- устаревшие модули с известными проблемами;
- административные аккаунты бывших сотрудников;
- отсутствие проверки прав и CSRF в кастомных обработчиках;
- загрузка файлов без ограничений;
- персональные данные в логах и тестовых копиях.
Не следует обещать абсолютную защищённость после короткого осмотра. Результат — список обнаруженного, уровень критичности и рекомендации, что блокирует работу, а что можно исправлять планово.
10. Провести тест до изменения
Для запрошенного сценария создаётся минимальный набор приёмочных проверок. Сначала их выполняют на текущей версии, чтобы увидеть фактическое поведение. Затем повторяют после изменения. Это простая защита от спора «раньше всё работало».
Если автоматических тестов нет, допустим документированный ручной чек-лист. В нём должны быть основной путь, ошибки ввода, различия прав и связанные сценарии. Для заказа — пересчёт, оплата и уведомления; для формы — отправка, CRM и защита от повторов.
Каким должен быть отчёт
Полезный отчёт не состоит из сотни замечаний без приоритета. Он включает:
- краткую схему проекта и зависимостей;
- факты, которые влияют на первую задачу;
- блокирующие риски и обязательные действия;
- план реализации и проверки;
- отдельный список технического долга;
- допущения, которые ещё нужно подтвердить.
Для каждого риска нужны последствие и рекомендация. Формулировка «плохой код» не помогает принять решение. Формулировка «файл стороннего модуля изменён локально; обновление перезапишет обработчик; вынести логику в событие до обновления» — помогает.
Аудит не означает обязательную переделку
Частая тревога заказчика: новый разработчик найдёт недостатки и предложит переписать всё. Зрелый аудит разделяет три категории: блокирует текущую задачу, повышает риск будущих изменений, допустимо оставить как есть. Рабочую часть системы не нужно заменять только потому, что она не соответствует личным предпочтениям исполнителя.
В кейсе Dom hub аудит позволил адаптировать существующие разделы и исправить ошибки без разработки сайта заново. В проектах регулярного сопровождения КриоКлиник и Тосе накопленный контекст помогает внедрять дальнейшие изменения последовательно, а не начинать расследование с нуля под каждую задачу.
Что делать после аудита
Первую доработку лучше выделить в ограниченный этап: понятный результат, тесты, выпуск и документация. Критичные проблемы резервного копирования, доступов или прав исправляются до неё. Некритичный технический долг попадает в отдельный бэклог и не раздувает срочную задачу.
Если проект перешёл от другого подрядчика и нужен безопасный старт, можно начать с аудита и доработки чужого проекта либо обсудить регулярную поддержку 1С-Битрикс. В обращении полезно сразу указать первую задачу, известные интеграции и доступность тестового контура — так объём проверки будет соразмерен реальному риску.