В общем календаре на среду стоит «проверить сайт». Разработчик открывает главную, SEO-специалист смотрит Search Console, администратор вспоминает о сертификате. Каждый сделал полезное действие, но никто не знает, выполнена ли запись. В следующий раз набор проверок окажется другим.
Рабочее расписание состоит из буквальных строк: объект, время, метод, критерий, ответственный и действие при отклонении. Его можно выполнить в отсутствие автора и получить сопоставимый результат.
Привяжите частоту к сроку обнаружения
Для каждого риска задайте максимальное время, в течение которого проблема может оставаться незамеченной. Недоступность заказа может требовать пяти минут. Истекающий через три недели сертификат достаточно пересчитывать раз в сутки. Битые ссылки в архиве допустимо собирать недельным пакетом.
Частота теряет смысл без готовности реагировать. Если ночью нет дежурного, уведомление каждые пять минут должно копить факты для утренней эскалации либо вести к внешней поддержке с полномочиями. Формальная круглосуточность при выключенных телефонах создаёт шум.
Начальный перечень объектов можно взять из чек-листа технического SEO, затем убрать пункты без владельца и понятного действия. Для каждой оставшейся строки запишите цену позднего обнаружения.
Заполните календарь буквальными строками
Ниже стартовый вариант для небольшого сайта. Время указано по рабочему часовому поясу команды.
| Когда | Строка календаря | Критерий | Что сохранить |
|---|---|---|---|
| каждые 5 минут | открыть основную страницу по HTTPS из внешней точки | получен ожидаемый HTTP-статус за установленный тайм-аут | запись попытки со временем и статусом |
| каждый день, 09:05 | проверить дату окончания TLS-сертификата и цепочку доверия | до внутреннего срока продления больше установленного запаса | число оставшихся дней и результат цепочки |
| каждый день, 09:10 | скачать robots.txt и основные sitemap | файлы доступны, синтаксис читается, состав не изменился без задачи | сохранённый diff |
| каждый день, 09:15 | открыть главную и критичный бизнес-URL | статус и обязательный текст соответствуют ожиданию | два ответа с временем |
| понедельник, 10:00 | обойти по три URL каждого основного шаблона | нет новых 4xx/5xx, пустых Title, H1 и неожиданных canonical | таблица URL и значений |
| среда, 11:00 | проверить новые внутренние 404 за семь дней | источники определены, критичные переходы оформлены задачами | сгруппированная выгрузка |
| первый рабочий день месяца | выполнить расширенный технический обход | охват соответствует списку шаблонов, находки распределены | версия отчёта и список решений |
| первый понедельник квартала | проверить восстановление резервной копии и права доступа | тест завершён по процедуре, лишние права сняты | протокол теста |
Срок TLS вынесен в ежедневную строку. Каждые несколько минут проверять дату окончания сертификата бессмысленно: число дней не меняется с такой скоростью. Частые HTTPS-запросы отвечают на другой вопрос — доступен ли сайт сейчас. Пороговые напоминания и запас на продление описаны в статье о контроле истечения SSL.
Добавьте строки, которые запускает событие
Релиз в четверг не дождётся плановой проверки понедельника. Событийные строки входят в критерии готовности изменения:
| Событие | Проверка сразу после него | Кто подтверждает |
|---|---|---|
| деплой приложения | главная, критичный URL, изменённая функция, ответ сервера | ответственный за релиз |
| правка маршрутов | старые URL, цепочки редиректов, canonical, sitemap | разработчик и SEO-специалист |
| обновление CMS или плагина | шаблоны, формы, кэш, фоновые задания | владелец сайта |
| массовый импорт | число записей, Title, Description, H1 на выборке | редакция и владелец шаблона |
| смена DNS | ответы из двух внешних сетей, IPv4/IPv6, TLS | инфраструктурный специалист |
У каждой строки есть крайний срок: например, «до завершения окна релиза» или «через 15 минут после переключения DNS». Фраза «проверим позже» не задаёт момента принятия.
Оформите одну запись полностью
Даже понятная строка календаря требует инструкции. Готовая карточка может выглядеть так:
ID: WEB-DAILY-03
Когда: каждый день в 09:15 MSK
Объект: https://example.ru/checkout
Метод: внешний GET без авторизации, без локального кэша
Успех: HTTP 200; в HTML есть точный текст «Оформление заказа»
Ответственный: дежурный веб-команды
Повтор: один запрос через 60 секунд из второй сети
Эскалация: два отказа — координатору инцидента немедленно
Артефакт: ссылка на оба ответа и время проверкиДля ручной строки добавьте заместителя и срок просрочки. Для автоматической — владельца уведомления. Робот выполняет запрос, ответственность за решение остаётся у назначенной роли.
Разведите отклонения по трём очередям
Не каждое расхождение требует аварийной реакции. Удобно заранее определить три исхода.
Инцидент: главная или критичный путь недоступны, возник массовый 5xx, ключевой раздел получил noindex. Действует короткая эскалация и отдельный процесс восстановления.
Плановая задача: несколько ссылок в архиве ведут на 404, у одного шаблона ухудшилась скорость, обнаружено некритичное расхождение метаданных. В календаре сохраняется ссылка на созданную задачу и срок.
Наблюдение: единичный сетевой тайм-аут не повторился из второй точки, метрика осталась в допустимом диапазоне. Запись хранится до следующего окна сравнения. Практика подтверждения внешнего сигнала есть в руководстве по мониторингу доступности.
Граница задаётся числами и условиями проекта: количество URL, длительность, затронутый путь, порог времени ответа. Чужой универсальный порог редко подходит без собственной базовой линии.
Назначьте источники автоматическим строкам
В поле «Метод» укажите конкретную систему и её границу. Например, Site Control может дать сигналы доступности, SSL и изменений страниц, но не назначает владельца, срок или эскалацию и не проверяет восстановление резервной копии. Эти части остаются в календаре команды.
Если используются другие инструменты, укажите их в поле «Метод» так же конкретно. Замена сервиса не должна менять критерий успеха и маршрут реакции.
Проверьте календарь через четыре недели
Перед запуском назначьте версию таблицы и дату ревизии. Через четыре недели выгрузите четыре числа: долю выполненных ручных строк, количество подтверждённых отклонений, число ложных тревог и медианное время до назначения ответственного.
Для каждой пропущенной проблемы задайте отдельный вопрос: отсутствовала строка, был слишком редкий ритм, не сработал метод или уведомление осталось без получателя. Частоту меняйте по этому ответу. Если проблема возникла из-за заполненного диска, проверка главной по-прежнему нужна для симптома, а в календарь добавляется отдельная метрика свободного места для раннего предупреждения.
Минимальный запуск на следующий месяц можно зафиксировать прямо в протоколе: восемь регулярных строк из таблицы, пять событийных триггеров, один ответственный и заместитель на каждую ручную проверку, дата ревизии через 28 дней. На ревизии у команды будут четыре измеримых показателя и список строк, которые требуется изменить.