1. Пройдите путь клиента
Открытая главная страница не доказывает, что сайт принимает заявки. Проверьте формы и получение сообщения в почте или CRM, телефонные ссылки и WhatsApp на мобильном устройстве. В магазине проверьте согласованный сценарий заказа и уведомления. Используйте тестовый режим оплаты или разрешённую транзакцию. Повторяйте важные проверки также после изменений.
2. Проверьте копии и место хранения
Посмотрите результат последнего задания, состав данных, доступное место и срок хранения версий. Просроченные ключи или изменения приложения могут нарушить копирование. Запланируйте восстановление в отдельной среде и проверьте запуск приложения вместе с базой и настройками. Свежая дата архива сама по себе не доказывает возможность вернуть работающий сайт.
3. Проверьте продления, обновления и права
Проверьте домен, способ оплаты продления и работу механизма обновления сертификата. Оцените важные уведомления для CMS и плагинов. Просмотрите административные аккаунты сайта, почты и хостинга, согласуйте отзыв лишних прав. Ежемесячный график является базовой процедурой: срочное уведомление об угрозе или отказ сервиса нельзя откладывать до следующего месяца.
Как превратить ежемесячный чек-лист в рабочую запись
Для каждого сайта заведите владельца, дату, проверяемую функцию, результат и следующее действие. Сравнивайте с прошлым месяцем: новые администраторы, изменившиеся плагины и ошибки копирования важнее механического повторения «всё проверено». Частоту выбирают по изменениям и рискам, а не только по календарю.
Для магазина нужно учитывать операции ежедневно, а некоторые изменения проверять сразу после выпуска. Ежемесячный обзор не заменяет реагирование на обнаруженный сбой и не означает непрерывного наблюдения.
Пример журнала обслуживания
Пустой результат означает незавершённую проверку, а не положительный вывод.
| Пункт | Как подтвердить | Что записать |
|---|---|---|
| Домен и сертификат | Проверить владельца продления и нужные имена | Срок, ответственного, замечания |
| Формы и заказы | Согласованный тест до конечного получателя | Время и результат сценария |
| Компоненты | Сверить версии и поддержку | Изменения и несовместимости |
| Права | Сверить администраторов с владельцами | Подтверждённые и неизвестные аккаунты |
| Копии | Проверить задания и последний тест запуска | Возраст копии и статус восстановления |
Как приоритизировать найденные проблемы
Сначала рассматривают потерю контроля над доменом или администратором, неработающие заявки и отсутствие понятного пути восстановления. Косметические ошибки не должны вытеснять эти задачи. Для каждой проблемы назначьте ответственного и следующую дату проверки.
Не удаляйте неизвестный аккаунт, пока не выяснено, не обслуживает ли он важную интеграцию. Для потенциально опасного изменения нужны разрешение, копия и способ проверки. Регулярное сопровождение помогает вести журнал, но конкретный состав и пределы работ должны быть согласованы.
Учебная строка журнала и частота проверок
Пример: 29.10.2026, форма TEST-01, ожидается карточка CRM, браузер показал успех, запись в CRM не найдена; доказательство безопасный идентификатор и время; владелец интеграции назначен ответственным, повторная проверка после разбора. Статус остаётся открытым. После изменения проверяют затронутую функцию сразу; регулярный обзор сверяет состояние и зависимости; обнаруженный инцидент требует действий при выявлении. Итог для владельца: что проверено, что не прошло, влияние, ответственный и согласованная дата следующей проверки.
