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

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

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

Ниже — набор проверок, который полезен ещё до разговора о полном переписывании. Они не выглядят эффектно, зато быстро отделяют реальные риски от общих впечатлений. Именно это и нужно бизнесу: не красивый отчёт, а понятная карта того, что ломается и почему.

1. Один путь заявки от отправки до результата

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

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

2. Одна задержка, выраженная числом

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

Если за нужный промежуток есть slow log, его стоит читать как источник повторяющегося рисунка, а не как склад пугающих строк. Сгруппируйте одинаковые запросы, сравните Rows_examined и Rows_sent, посмотрите на повторы. Даже тихий журнал не гарантирует быструю страницу, потому что серию коротких вызовов он может не показать как главную проблему. Порядок такого чтения описан в заметке что смотреть в slow log до рефакторинга. Чужие цифры ускорения сюда переносить не стоит: нужен замер именно вашей операции, здесь, до изменения и после него.

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

3. Как изменение попадает на живой сайт

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

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

4. Общие клиенты — общий риск утечки

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

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

5. От каких выводов лучше отказаться

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

Неровный код сам по себе ещё не означает сегодняшнюю аварию. Запутанный модуль может работать терпимо, если он не ломает маршрут заявки и не создаёт задержку на важной операции. Точно так же очередь не спасает запрос, который никто не прочитал: фоновая джоба с тем же циклом просто переносит расход в другое место. Кэш полезен после понимания, что именно стоит хранить, а очередь — когда работу действительно нужно вынести из HTTP-запроса и контролировать повторы побочного эффекта. Эту границу подробно разбирает заметка когда очередь уместна рядом с приложением.

6. Как должен выглядеть результат

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

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

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

Когда второй взгляд действительно нужен

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