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

Полноценный технический аудит должен:

• учитывать роль сайта в бизнесе

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

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

• оценивать код, инфраструктуру и связанные системы

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

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

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

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

В Ameton начинаем аудит с бизнес-сценариев. Сначала выясняем, какие функции нельзя нарушить, а затем проверяем технические решения, от которых зависит их работа

Сначала определите цель и границы аудита

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

Цель аудита может заключаться в том, чтобы:

• определить причины нестабильной работы

• оценить возможность дальнейшего развития сайта

• проверить проект перед передачей новой команде

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

• найти риски безопасности

• оценить состояние интеграций

• подготовиться к росту нагрузки

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

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

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

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

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

Для начала проверки полезно подготовить:

• адрес сайта и описание его роли в бизнесе

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

• известные ошибки и историю недавних изменений

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

• сведения об интеграциях и внешних сервисах

• описание ролей пользователей

• документацию и предыдущие отчёты, если они есть

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

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

Начните проверку с критичных сценариев

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

Для интернет-магазина к критичным сценариям обычно относятся:

• поиск и выбор товара

• отображение цены и наличия

• добавление товара в корзину

• выбор доставки

• оформление и оплата

• передача заказа в обработку

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

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

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

Критичный сценарий связывает интерфейс, данные и внутренние процессы. Именно поэтому технический аудит нельзя сводить к просмотру отдельных страниц

Проверка архитектуры и качества кода

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

Команда изучает:

• структуру проекта и расположение индивидуальных доработок

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

• повторяющиеся или противоречащие друг другу решения

• обработку ошибок и нестандартных состояний

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

• зависимости между компонентами

• понятность выпуска и отмены изменений

Для сайта на 1С-Битрикс особенно важно понять, изменялись ли стандартные файлы платформы. Такие изменения могут потеряться или вызвать конфликт при обновлении. Индивидуальную логику безопаснее выносить в предусмотренные для доработок области проекта

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

В Ameton при проверке кода связываем техническое замечание с конкретным последствием. Формулировка «компонент требует переработки» недостаточна без объяснения, какую функцию он ограничивает и почему это важно для следующих изменений

Оцените состояние инфраструктуры

Инфраструктура должна соответствовать фактической работе сайта и позволять команде диагностировать сбои. Недостаточно проверить только доступность сервера в момент аудита

При обследовании обычно рассматривают:

• соответствие окружения требованиям проекта

• использование ресурсов при обычной и повышенной нагрузке

• настройки веб-сервера и базы данных

• выполнение фоновых и регулярных задач

• хранение журналов ошибок

• срок действия сертификатов

• создание и хранение резервных копий

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

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

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

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

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

Во время аудита проверяют:

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

• доступы действующих и бывших сотрудников или подрядчиков

• использование общих паролей

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

• обработку данных в формах и личных кабинетах

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

• доступность резервных копий

• хранение секретных ключей и паролей

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

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

Оцените производительность сайта

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

Команда должна определить:

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

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

• где проходит время ожидания

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

• как работают кеширование и фоновые процессы

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

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

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

Проверьте интеграции и качество данных

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

Для каталога и заказов проверяют:

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

• какая система отвечает за каждый тип данных

• в каком направлении передаётся информация

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

• что происходит при неполном обмене

• возникают ли дубли

• можно ли безопасно повторить неудачную операцию

• где фиксируются ошибки

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

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

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

Проверьте процесс выпуска изменений

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

Следует проверить:

1. Где хранится актуальная версия кода

2. Как разработчики разделяют и объединяют изменения

3. Где проверяются доработки до публикации

4. Кто согласовывает выпуск

5. Какие критичные сценарии проверяются после него

6. Как команда возвращается к предыдущей версии при проблеме

7. Где фиксируется результат изменения

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

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

Пример из практики Ameton

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

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

Практический вывод: аудит должен не только находить причину сбоя, но и определять способ контроля его повторения

Как оформить результаты технического аудита

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

Для каждой существенной проблемы следует указать:

• где она обнаружена

• какую функцию затрагивает

• при каких условиях проявляется

• к чему может привести

• насколько срочно нужно вмешаться

• какое решение рекомендуется

• что требуется проверить после исправления

• нужна ли дополнительная диагностика до оценки

Описание должно быть воспроизводимым. Формулировку «сайт иногда работает медленно» нельзя использовать как готовую задачу. Нужно указать конкретное действие, условия возникновения задержки и ожидаемый результат

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

Как расставить приоритеты после аудита

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

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

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

Как отличить качественный аудит от формальной проверки

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

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

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

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

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

Для каких проектов нужен технический аудит

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

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

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

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

Ameton может провести аудит сайта на 1С-Битрикс, проверить критичные сценарии, код, инфраструктуру и интеграции, а затем подготовить приоритетный план работ Такой документ позволяет отдельно оценить необходимые исправления и не смешивать срочные риски с плановым развитием