Короткий ответ: техническая поддержка сайта — это не «правки по звонку», а регламент: обновления, резервные копии, мониторинг доступности, разбор инцидентов и очередь доработок. Без регламента поддержка превращается в тушение пожаров, а сайт постепенно накапливает устаревшие компоненты и незакрытые уязвимости. Ключевой показатель качества поддержки — не число выполненных заявок, а время простоя за период.
Направление описано на странице услуги поддержки и развития; здесь — про то, что должно входить в регламент.
Что входит в поддержку
| Блок | Что делается | Периодичность |
|---|---|---|
| Обновления | Ядро, плагины, тема, зависимости | Ежемесячно, критические — сразу |
| Резервные копии | Файлы и база, с проверкой восстановления | Ежедневно, проверка — раз в квартал |
| Мониторинг | Доступность, время ответа, ошибки, сертификат | Постоянно |
| Безопасность | Firewall, ограничение попыток входа, разбор инцидентов | Постоянно, аудит — раз в квартал |
| Доработки | Изменения в вёрстке, функциональности, контенте | По заявкам, в согласованной очереди |
| Отчётность | Что сделано, что обнаружено, что планируется | Ежемесячно |
Разделение на «поддержку» и «развитие» принципиально. Поддержка — это регулярные работы по сохранению работоспособности, они планируются заранее. Развитие — новые задачи, их объём заранее неизвестен. Смешивание этих блоков в одном бюджете приводит к тому, что при потоке доработок регулярные работы перестают выполняться.
Почему обновления обязательны
Устаревший компонент — это известная уязвимость, о которой знают все, включая автоматические сканеры. Сайт без обновлений взламывают не потому, что он интересен, а потому что он попал в список уязвимых.
Порядок обновления, который снижает риск:
- Резервная копия перед обновлением. Обязательно и без исключений.
- Тестовый контур. Копия сайта, где обновление проверяется до рабочего сервера.
- Проверка ключевых сценариев. Форма заявки, оплата, вход в админку, отображение каталога.
- Обновление на рабочем сервере. В момент минимальной нагрузки.
- Наблюдение. Первые часы после обновления — время, когда проявляются несовместимости.
Автоматические обновления без проверки на тестовом контуре экономят время, но именно они чаще всего ломают сайт: несовместимость плагина с новой версией ядра обнаруживается уже на рабочем сервере.
Мониторинг: что отслеживать
| Что | Почему |
|---|---|
| Доступность сайта | Основной показатель; о падении нужно узнавать раньше клиентов |
| Срок действия SSL-сертификата | Истёкший сертификат закрывает сайт для посетителей |
| Время ответа | Постепенный рост указывает на проблему до того, как она станет отказом |
| Свободное место на диске | Заполненный диск останавливает работу сайта и баз данных |
| Ошибки в журналах | Рост числа ошибок предшествует сбоям |
| Доступность формы заявки | Сайт может работать, а заявки — не доходить |
Последний пункт часто упускают. Сайт отвечает 200, посетители заходят, а форма не отправляет заявки — и потери идут неделями, пока кто-нибудь не позвонит и не спросит, почему не отвечают. Проверка сквозного сценария «отправка заявки» должна быть в мониторинге наравне с доступностью.
Что должно быть в отчёте
- Доступность за период. Процент времени, когда сайт отвечал нормально, и список сбоев с причинами.
- Выполненные регулярные работы. Обновления, копии, проверки.
- Инциденты. Что произошло, как обнаружено, сколько заняло устранение, что изменено, чтобы не повторилось.
- Выполненные доработки. По заявкам, с указанием сроков.
- План на следующий период. Что требует внимания: устаревшие компоненты, рост нагрузки, риски.
Отчёт без пункта об инцидентах бесполезен: он не показывает, где система слаба.
Как выбрать формат работы
| Формат | Когда подходит |
|---|---|
| Абонентское обслуживание с часами | Регулярные небольшие доработки, предсказуемая нагрузка |
| Только регулярные работы | Сайт стабилен, доработки редки |
| Разовая поддержка по заявкам | Сайт простой, критичность низкая |
| Аварийное восстановление | Дополнение к любому формату: разбор и восстановление после взлома или сбоя |
Отдельно стоит оговорить время реакции: сколько проходит от сообщения о проблеме до начала работ. Без этого пункта договорённость о поддержке остаётся неопределённой.
Признаки, что поддержка не работает
- Обновления не выполнялись месяцами, и никто не знает текущих версий.
- Резервные копии есть, но ни разу не проверялись восстановлением.
- О падении сайта первым сообщает клиент, а не мониторинг.
- Нет списка выполненных работ за период.
- Заявки на доработку теряются: невозможно узнать, что в очереди и в каком порядке.
Проверить состояние сайта прямо сейчас можно по косвенным признакам: версии компонентов, наличие копий, срок действия сертификата. Часть этих работ пересекается с резервным копированием и защитой сервера.