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

Провести аудит стоит, если:

• сайт передаётся новой команде на поддержку

• планируется крупная доработка или изменение архитектуры

• ошибки появляются повторно или не имеют понятной причины

• сайт работает медленно или нестабильно

• неизвестно состояние обновлений, доступов и резервных копий

• предстоит перенос, редизайн или интеграция с новой системой

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

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

Аудит нужен перед решением, на которое влияет состояние сайта

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

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

Аудит перед передачей сайта новой команде

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

Во время входа в проект подрядчик проверяет:

• доступы к сайту, серверу, домену и внешним сервисам

• наличие актуального исходного кода и порядок выпуска изменений

• резервные копии и возможность восстановления

• установленные обновления и индивидуальные компоненты

• интеграции и источники данных

• критичные пользовательские сценарии

• известные ошибки и незавершённые задачи

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

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

Аудит перед крупной доработкой или редизайном

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

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

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

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

Аудит при повторяющихся ошибках

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

Аудит в такой ситуации должен восстановить последовательность событий:

1. Какое действие выполняет пользователь или внешняя система

2. Какие данные принимает и обрабатывает сайт

3. Где возникает отклонение от ожидаемого результата

4. Какие изменения предшествовали сбою

5. Как система обрабатывает ошибку и повторную операцию

6. Какие соседние функции используют те же данные или компоненты

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

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

Аудит при низкой скорости сайта

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

Команда должна разделить проблему по сценариям:

• какие страницы или операции работают медленно

• возникает ли задержка постоянно или при определённых условиях

• зависит ли она от объёма каталога или числа запросов

• какая часть времени уходит на сайт, сервер или внешнюю систему

• меняется ли результат после очистки кеша или обновления данных

• какие действия можно оптимизировать без риска для функций

Если медленно открывается только каталог, проверка должна быть сосредоточена на его данных, фильтрах и шаблонах. Если замедляется административная часть во время обмена, причина может находиться в фоновых заданиях или обработке больших объёмов информации

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

Аудит безопасности и управления доступами

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

Аудит безопасности может включать:

• административные учётные записи и права пользователей

• доступы к серверу, домену, репозиторию и внешним сервисам

• состояние платформы, модулей и индивидуального кода

• журналы событий и подозрительные действия

• публично доступные служебные файлы

• резервные копии и порядок восстановления

• формы, обработчики и интеграции, принимающие данные

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

В Ameton рассматриваем безопасность через конкретные последствия. Устаревшая учётная запись важна не сама по себе, а потому, что через неё можно изменить сайт или получить доступ к данным. Такая связь помогает расставить приоритеты, а не выдавать заказчику длинный список настроек без объяснения риска

Аудит перед переносом сайта

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

До переноса команда проверяет:

• совместимость сайта с новым окружением

• объём и состояние файлов и базы данных

• индивидуальные настройки сервера

• фоновые операции и расписание их запуска

• подключение почты и внешних сервисов

• адреса, сертификаты и сетевые ограничения

• порядок переключения и возврата к прежней версии

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

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

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

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

Проверять всё с одинаковой детализацией не всегда разумно. Перед сменой хостинга важнее инфраструктура и совместимость, перед созданием личного кабинета — роли, данные и авторизация, а перед поддержкой — общий контекст, доступы и критичные сценарии. Подробнее о том, как проходит аудит – в статье Зачем нужен аудит сайта на 1С‑Битрикс перед стартом поддержки?

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

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

Например, если перестало отправляться уведомление после изменения настроек почты, можно проверить конкретный сценарий и связанные параметры. Если одновременно пропадают письма, заявки, фоновые операции и статусы заказов, локальная проверка уже не покажет общую причину

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

Если подрядчик предлагает обследование, он должен объяснить, какой вопрос нельзя решить обычной диагностикой. Аудит не должен становиться обязательной платной процедурой перед любой задачей

Для каких проектов применимы эти рекомендации

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

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

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

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