Техническая поддержка сайта: регламент, который снижает риски

Поддержка — это управляемая готовность к изменениям и сбоям

Фраза «следим, чтобы всё работало» не задаёт ни объём, ни ответственность. Рабочий регламент перечисляет объекты контроля, частоту проверок, время реакции, порядок изменений и доказательства выполненных работ.

• Доступность Внешний мониторинг основных URL, проверка HTTPS и уведомление о недоступности.
• Заявки Контроль ответа API, сохранения обращения и статуса уведомления. Простого открытия формы недостаточно.
• Резервные копии Автоматическое создание, внешнее хранение, контрольные суммы и периодическая проверка восстановления.
• Изменения Отдельный release, фиксированная версия образа, smoke-тест и команда rollback.
• Безопасность Срок сертификата, обновления, права доступа, открытые порты и отсутствие публичных backup или .env.

Что проверять и как часто

Как определить время реакции

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

Критический

Высокий

Плановый

Что должно подтверждать выполненную поддержку

• Дата и результат последнего backup, а не только сообщение «копирование настроено».
• История релизов с commit, image и rollback-точкой.
• Перечень инцидентов: симптом, причина, действие и профилактика повторения.
• Результат проверки формы и уведомлений без хранения тестовых персональных данных.
• Список отложенных рисков с приоритетом и владельцем решения.

Границы поддержки нужно согласовать заранее

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