Администрирование сайта: обязанности, чек-лист и когда нужен внешний подрядчик

Администрирование сайта часто путают с «есть человек, который иногда заходит в админку». На практике это зона ответственности за стабильность, безопасность и базовую гигиену инфраструктуры. Если роли нет — риски копятся тихо: устаревшие плагины, непроверенные бэкапы, истёкший сертификат, диск на 98%.

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

Администрирование, поддержка и разработка — не одно и то же

Коротко по границам:

Администрирование — поддерживать среду в рабочем состоянии: доступы, обновления, бэкапы, мониторинг ресурсов, базовая скорость и безопасность.
Техническая поддержка — процесс реакции на инциденты + плановые работы; часто включает администрирование. Подробнее — в статье про техническую поддержку сайта.
Разработка / доработка — новый функционал, интеграции, крупные изменения логики и вёрстки.
Контент и маркетинг — тексты, акции, гипотезы конверсии; админ обеспечивает, чтобы это можно было безопасно выкатывать.

Когда один фрилансер «и админ, и разработчик, и SEO», границы размываются — и в кризис непонятно, кто виноват, что форма молчит три дня.

Обязанности администратора сайта

Ниже — практический список для бизнеса, а не для хостинг-провайдера уровня «сервер под ключ».

1. Доступы и учётные записи

Инвентаризация: кто имеет доступ к CMS, хостингу, DNS, FTP/SSH, репозиторию.
Парольная политика, 2FA где возможно.
Отзыв доступов при увольнении подрядчика или сотрудника.
Разделение ролей: маркетолог не обязан иметь root.

Потеря контроля над доступами — частая причина долгих простоев после «сайт вёл прошлый программист, связи нет».

2. Обновления CMS и расширений

Календарь обновлений (не «когда вспомним»).
Тестовая проверка критичных сценариев после апдейта.
План отката.
Отказ от заброшенных плагинов и «волшебных» nulled-тем.

Это пересекается с безопасностью: большинство взломов коммерческих сайтов — через устаревшие компоненты, а не через «гениальный хакерский zero-day».

3. Резервное копирование

Расписание бэкапов файлов и базы.
Хранение копии вне того же диска, который может умереть вместе с сайтом.
Регулярный тест восстановления (хотя бы раз в квартал).
Понимание RPO/RTO на уровне бизнеса: сколько данных готовы потерять и как быстро нужно подняться.

4. Мониторинг доступности и ресурсов

Алерты, если сайт недоступен.
Контроль места на диске, сертификата SSL, квот почты/БД.
Базовый взгляд на скорость ключевых страниц — в связке с Core Web Vitals.

Админ не обязан быть фронтенд-инженером по перформансу, но обязан заметить, что главная «потяжелела» втрое после установки виджета.

5. Безопасность в операционном контуре

Актуальный HTTPS.
Ограничение прав на запись там, где не нужно.
Реакция на подозрительную активность и вредоносный код.
Понимание, куда эскалировать инцидент.

6. Связка с бизнесом

Хороший администратор сайта знает:

какие страницы и формы критичны для заявок;
когда нельзя выкатывать обновления (пик записи, акция, чёрная пятница);
кому сообщать о простое.

Без этой связки администрирование превращается в «сервер зелёный», а бизнес уже потерял день лидов.

Чек-лист администрирования сайта

Используйте как ежемесячный минимум.

Еженедельно

[ ] Сайт открывается, формы отправляются (ручная проверка ключевых сценариев).
[ ] Сертификат SSL не на грани истечения.
[ ] Нет критических алертов по доступности / диску.

Ежемесячно

[ ] Обновления CMS/плагинов (или осознанный перенос в окно обслуживания).
[ ] Проверка, что бэкапы создаются по регламенту.
[ ] Просмотр логов на аномалии (по возможности).
[ ] Список рисков: что отложили и почему.

Ежеквартально

[ ] Тестовое восстановление из бэкапа.
[ ] Ревизия доступов.
[ ] Обзор плагинов/сервисов: что удалить, что заменить.
[ ] Сверка с чек-листом здоровья сайта.

Чек-лист бесполезен, если его никто не подписывает. Назначьте владельца — штатного или внешнего.

Когда администрирование «своими» перестаёт работать

Типичные сигналы:

Обновления откладывают месяцами, потому что «страшно сломать».
Бэкапы есть только на словах.
Инциденты закрывают ночью силами маркетолога или директора.
Нет единого ответственного — «это к хостеру / к тому парню / к агентству».
Скорость и безопасность чинят только после жалоб клиентов или поисковика.
IT-команда перегружена продуктом, а сайт компании — пятый приоритет.

В этих случаях внешнее администрирование в рамках поддержки 24/7 часто дешевле скрытых потерь: простоев, срочных «спасателей» и репутационных ударов.

Как выбрать внешнего подрядчика на администрирование

Спрашивайте не «вы умеете WordPress?», а:

какой регламент обновлений и бэкапов;
какое SLA на недоступность;
как оформляются доступы;
что входит и не входит в абонемент;
как выглядит ежемесячный отчёт;
где граница с доработками.

Красный флаг — подрядчик обещает «полное администрирование и развитие без лимитов» за символическую сумму. Либо качество будет символическим, либо границы всплывут в первый же инцидент.

Для роли IT и веб-админов у нас есть отдельный вход: для IT-специалистов — как снимаем операционную нагрузку, не ломая внутренние процессы.

Мини-модель ответственности

Зона	Кто обычно отвечает	Пример
Хостинг-железо / PaaS	Провайдер	Падение дата-центра
CMS, плагины, бэкапы приложения	Администратор сайта	Конфликт плагинов после апдейта
Новый функционал	Разработка	Калькулятор, личный кабинет
Тексты и акции	Маркетинг / контент	Баннер на главной
Приоритет инцидента для бизнеса	Владелец процесса внутри компании	«Форма записи — P1»

Путаница в таблице = конфликт на ровном месте.

Практический вывод

Администрирование сайта — это не должность «на всякий случай», а регулярная гигиена канала заявок. Закройте чек-лист, назначьте владельца, отделите администрирование от разработки. Если внутри нет ресурса на ритм и SLA — вынесите слой стабильности наружу и верните команде фокус на продукт и маркетинг.