Аудит имеет смысл, когда его результат помогает принять решение: устранить задержку, подготовить переезд, проверить резервирование или принять проект на сопровождение. Формулировка «проверить всё» не определяет ни объём работ, ни способ оценить результат. До выдачи доступов полезно записать, что именно беспокоит владельца сайта и какие изменения он рассматривает.
Например, магазин теряет заказы в часы рекламной кампании. Здесь важны путь оформления покупки, состояние базы, фоновые обмены и поведение системы под нагрузкой. Проверка только обновлений CMS не ответит на вопрос о причине отказов. Для другого проекта, который давно никто не обслуживал, первым результатом может стать перечень компонентов и доступов.
Согласуйте задачу и границы проверки
Перечислите входящие в аудит домены, серверы, базы, приложения и внешние интеграции. Уточните, кто предоставляет журналы, доступ к панели хостинга и описание публикации изменений. Если компонент обслуживает другая организация, заранее определите порядок получения сведений. Отсутствующий доступ нужно отметить как ограничение проверки, а не заменить предположением.
Отдельно согласуйте разрешённые действия. Чтение конфигурации, профилирование и нагрузочный тест по-разному влияют на рабочую систему. Запуск тяжёлой проверки на production требует отдельного решения, наблюдения и условий остановки. Аудит не должен неожиданно превращаться в обновление плагинов или изменение правил сети.
Сначала соберите схему проекта
Нужен список реально работающих компонентов: веб-сервер, PHP, CMS, база, пользовательские файлы, кеш, планировщик, очереди и почтовая отправка. Для каждого укажите версию, расположение, назначение и ответственного. Проверьте, какие процессы запускаются из командной строки: их окружение может отличаться от обработки страниц.
Полезна простая схема движения данных. Где принимается заявка, куда записывается заказ, кто отправляет уведомление, откуда сайт получает остатки? Такая схема выявляет зависимости, которых нет в списке установленных программ. Заодно становится понятно, какие части системы можно проверить самостоятельно, а какие требуют участия разработчика или провайдера.
Проверьте состояние и наблюдаемость
Смотрите на свободное место, доступную память, работу сервисов, ошибки и сроки действия сертификатов. Сопоставляйте показатели с конкретным временем жалоб. Средние значения за месяц не объяснят короткую остановку базы вчера вечером. Для производительности нужны повторяемый сценарий и измерения до изменений.
Проверьте, какие события замечает мониторинг и кому приходят сообщения. Успешное открытие главной страницы не подтверждает работу формы или обмена с учётной системой. В отчёте должно быть видно, какие функции проверены, а для каких наблюдения пока нет. Подробнее этот вопрос разобран в статье о мониторинге помимо ответа 200 OK.
Отдельно оцените безопасность и восстановление
Сверьте пользователей и права, способ хранения секретов, доступность административных интерфейсов и состояние обновлений. Найденную устаревшую версию сопоставляйте с условиями конкретной уязвимости. Аудит конфигурации не равен полноценному тестированию на проникновение; глубину проверки нужно назвать явно.
Для резервных копий важны состав, независимое хранение, доступ к ключам и подтверждённое восстановление. Зелёный статус задания показывает выполнение процедуры, но не гарантирует запуск приложения из архива. Если тест восстановления не проводился, это самостоятельный риск. Его нельзя скрывать за формулировкой «резервное копирование настроено». Практический порядок есть в проверке копий до аварии.
Требуйте проверяемых выводов
Для каждого замечания полезны четыре части: наблюдение, подтверждение, последствия и рекомендация. «Плохая конфигурация» не позволяет оценить серьёзность проблемы. Гораздо понятнее: архивы лежат только на рабочем диске; потеря этого диска оставит проект без копии; требуется независимое хранилище и тест получения архива из него.
Рекомендация должна учитывать ограничения проекта. Если обновление PHP требует исправления собственного модуля, в отчёте нужен этот порядок, а не совет немедленно переключить версию. Список покупок без связи с найденными причинами тоже не заменяет выводы. Для работ с риском остановки указывают способ проверки и возврата.
Превратите отчёт в план работ
Разделите замечания на срочные риски, плановые исправления и улучшения. Укажите зависимости: прежде миграции нужно получить доступ к DNS, прежде обновления — проверить копию. Для каждой задачи назначьте ответственного и определите, как подтвердить её завершение. Стоимость и сроки последующих работ оцениваются отдельно по согласованному объёму.
Сохраните исходные измерения, дату обследования и перечень непроверенных компонентов. После исправлений проведите повторную проверку затронутых функций. Сам отчёт быстро устареет, если инфраструктура меняется, поэтому схема и сведения о доступах должны перейти в рабочую документацию проекта.
Полезно сразу договориться о формате передачи отчёта. Владелец должен получить доступный ему документ, а не только ссылку в закрытой системе исполнителя. Для каждого замечания нужны адрес или компонент, способ подтверждения, последствия и следующий шаг. Пароли и полные выгрузки данных в отчёт не включают: достаточно описать проверенный факт и защищённое место хранения необходимых материалов.
Если нужен аудит вашего сайта и сервера, напишите в HOMEWEB. Укажите CMS, размещение и проблему, которую хотите разобрать: это поможет определить состав проверки и необходимые доступы.
