Регламент работ по сайту: что должен присылать подрядчик в отчёте

Регламент работ по сайту описывает четыре вещи: что подрядчик делает регулярно и с какой периодичностью, за какое время реагирует на инцидент, что входит в лимит часов, и что приходит в отчёте. Хороший отчёт занимает 1-2 страницы и читается за 5 минут.

Самая частая жалоба клиентов на старого веб-подрядчика: «не понимаю, за что плачу». Деньги уходят, сайт работает, какие-то правки случаются, но непонятно, что именно делается, в каком объёме, и оправдано ли это абонетной платой. Лечится один раз и навсегда регламентом работ и адекватным ежемесячным отчётом.

Я веду отчёты по каждому клиенту с 2018 года. За это время выработал шаблон, в котором в среднем 1.5 страницы текста, и который реально читается, а не складывается в архив. Ниже разберу, что должно быть в нормальном отчёте маленького подрядчика, как договариваться о регламенте и какие пункты не пускать.

Что вообще такое регламент работ

Регламент это документ, в котором прописано:

1. Что делает подрядчик регулярно: ежедневно, еженедельно, ежемесячно, по запросу.
2. Какие задачи входят в абонентку без отдельной оплаты.
3. Какие задачи оплачиваются по часам сверх абонентки.
4. Как клиент получает обратную связь (отчёт, его частота, формат).
5. Кто и когда работает (часы дежурства, дежурный канал связи).

Регламент это парная документу часть к SLA. Если SLA это «как быстро реагирую и насколько долго работа не должна простаивать», регламент это «что я в принципе делаю, чтобы простоев не было».

Что входит в типовой регламент абонентского обслуживания

Минимальный набор пунктов, который я считаю профессиональным обязательным.

Ежедневно

• Мониторинг доступности. Аптайм-проверки каждые 5 минут. Алерт в Telegram при двух пропущенных подряд.
• Мониторинг сертификата SSL. Если срок истекает за 30 дней, алерт.
• Мониторинг домена. Алерт за 90 дней до истечения.
• Мониторинг почты. Если уходящие письма с домена начинают возвращаться (DKIM/SPF/DMARC ошибки), алерт.

Это всё автоматизировано. Подрядчик ничего не делает руками, но получает уведомления и реагирует, когда нужно.

Еженедельно

• Минорные обновления плагинов и ядра CMS. Накатываются автоматически или с минимальной проверкой.
• Проверка логов на аномалии. Что-то странное в логе ошибок, логе доступа, логе плагина безопасности.
• Проверка резервных копий. Что они создаются и читаемы.
• Краткая еженедельная сводка клиенту в Telegram (опционально, по желанию клиента).

Ежемесячно

• Мажорные обновления. С тестированием на staging, накатом на боевой.
• Аудит безопасности. Сканер на вирусы, проверка пользователей в админке, проверка прав доступа.
• Аудит производительности. PageSpeed Insights, Core Web Vitals, мониторинг времени загрузки.
• Обзор статистики. Метрика, посещаемость, поведение, ошибки.
• Учения по восстановлению. Раз в квартал, не каждый месяц, но в регламенте записано.
• Письменный отчёт клиенту. О чём ниже.

По запросу

• Контентные правки: тексты, фото, новые статьи в блог, изменения в каталоге.
• Косметические правки: цвета, шрифты, отступы, мобильная адаптация.
• Доработки: новые формы, новые разделы, интеграции с внешними сервисами.
• Реакция на инциденты: взлом, падение, потеря данных.

Какие правки идут «бесплатно» в рамках абонентки, а какие отдельно нужно прописать в договоре. Обычно граница: «правки до 30 минут работы» бесплатно, всё больше по часовой ставке. Или «до N часов в месяц включено, дальше по ставке».

Что должно быть в ежемесячном отчёте

Шаблон, который я использую. Файл в PDF или в Markdown отправляется первого числа каждого месяца.

1. Шапка

• Название проекта.
• Период (с 1 по 30 такое-то).
• Имя подрядчика.
• Сводка: основные достижения и инциденты.

2. Аптайм и инциденты

• Процент аптайма за период (с тремя знаками после запятой).
• Список простоев: время, длительность, причина, действия.
• Соответствие SLA: уложились или нарушили.
• Если нарушили, сумма скидки на следующий месяц.

3. Выполненные работы

Таблица или список с тремя колонками:

• Дата.
• Тип работы (правка, обновление, инцидент, проектная).
• Описание (1-2 предложения, что сделано).
• Затраченное время.

В конце сумма часов и сравнение с включённой в абонентку нормой.

4. Безопасность

• Когда последний раз обновлялся WordPress, основные плагины.
• Сколько попыток входа в админку зафиксировано (с разбивкой: успешно/неуспешно).
• Сколько IP заблокировано.
• Ссылка на отчёт сканера на вирусы.
• Состояние SSL и домена.

5. Скорость

• Текущий PageSpeed Insights (мобильный + десктопный).
• LCP, CLS, INP за период (по данным Search Console или внутреннего мониторинга).
• Что в скорости изменилось за месяц и почему.

6. Бэкапы

• Сколько копий хранится.
• Размер хранилища.
• Дата последней проверки восстановления (учения).

7. Аналитика

• Посещения за период.
• Сравнение с прошлым периодом.
• Топ-10 страниц по трафику.
• Источники трафика (поисковики, прямые, реклама).
• Цели в Метрике (заявки, звонки, корзина) с разбивкой по источникам.

8. Рекомендации на следующий месяц

• Что предлагается сделать (новые функции, оптимизации).
• Сколько часов это займёт.
• Стоимость, если выходит за абонентку.

9. Финансовый блок

• Сумма абонентки.
• Сумма доплат сверх абонентки за месяц.
• Сумма к оплате (с НДС/без, реквизиты).
• Дата выставления счёта.

Такой отчёт занимает 1-2 страницы, читается за 5 минут, но даёт полную картину.

Что НЕ должно быть в отчёте

Несколько паттернов, которые отличают «хороший отчёт» от «галочного отчёта».

Списки технических действий без объяснения. «Установил mod_evasive» сам по себе бессмыслица для владельца. Должно быть «Усилил защиту от ботов: блокирую IP, делающие больше 4 запросов в секунду. Это снизит нагрузку на сайт во время массовых атак».

Графики без выводов. PageSpeed Insights график за месяц без подписи «вот тут падение из-за того-то и того-то» бесполезен.

Длинные общие фразы. «Проводилась оптимизация производительности и работы с базой данных» это вода. «Включил Redis-кеш для запросов к БД, среднее время рендера страницы упало с 800 до 320 мс» это конкретика.

«Никаких инцидентов» при пустой таблице работ. Вопрос: подрядчик что-то делал, или просто получает деньги за «ничего не сломалось»? Тогда зачем абонентка?

Ссылки на внутренние тикеты, которые клиент не видит. «Подробнее в Jira-ticket SF-123». Клиент не должен лазить в чужой тикетник, чтобы понять, что сделано.

Канал коммуникации

Часть регламента это где общаемся.

Что я использую для разных типов сообщений:

• Telegram-чат для оперативных вопросов, инцидентов, мелких правок. Реакция в SLA-окне.
• Email для отчётов, договоров, документов, формальных согласований.
• Видеосозвон по Zoom или Telegram для крупных вопросов и квартальных созвонов.
• Личный канал клиента в Telegram (только в премиум-тарифе) для критических случаев в нерабочее время.

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

Что НЕ использую:

• WhatsApp. Архивирует переписку у себя, восстановить историю при смене телефона неудобно.
• Голосовой звонок как основной канал. Только синхронные созвоны по согласованию. Иначе не остаётся следа: что сказали, когда, какие договорённости.
• Соцсети как канал поддержки. Сообщения теряются, истории неудобно искать.

Что входит в абонентку, а что нет

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

Точно в абонентке

• Все мониторинги и автоматизация.
• Все обновления (минорные автоматически, мажорные по графику).
• Бэкапы и проверки восстановления.
• Реакция на инциденты до X часов в месяц (зависит от тарифа).
• Мелкие правки (до 30 минут каждая) до Y штук в месяц.
• Ежемесячный отчёт.
• Консультации по телефону или в чате до Z часов в месяц.

Точно не в абонентке

• Разработка нового раздела или новой функции.
• Редизайн, серьёзные изменения внешнего вида.
• Подключение новых интеграций (CRM, оплата, доставка).
• Перенос на новый хостинг или новую CMS.
• Восстановление после взлома, требующее больше N часов работы.
• Создание контента (тексты, фото, видео).
• SEO-продвижение (это отдельная услуга, не часть техподдержки).

Серая зона, согласуется отдельно

• Срочные правки (нужно прямо сейчас, в 23:30 в пятницу).
• Большие контентные правки (массовое обновление каталога).
• Помощь с настройкой сторонних сервисов.
• Обучение и подготовка инструкций.

Как переходить от старого регламента к новому

Если у вас уже работает подрядчик с непонятной системой, и вы хотите перейти на нормальный регламент, шаги такие.

1. Запросить у текущего подрядчика любые отчёты за прошлый год. Если их нет, это уже сигнал, что регламент не работает.
2. Сформулировать, что именно вас не устраивает: непрозрачность, сроки, качество.
3. Предложить новый шаблон отчёта и регламента (можно с этой статьи).
4. Согласовать SLA и регламент в письменной форме. Если подрядчик отказывается это плохой знак.
5. Дать испытательный месяц. Если не получается, искать другого.

Если переходите на меня (или на другого подрядчика), ритуал передачи описан в статье о смене веб-мастера.

Что делать с отчётом, который вам не нравится

Если первый отчёт нового подрядчика выглядит формально и не отвечает на ваши вопросы, говорите об этом сразу.

Хороший подрядчик возьмёт правки и в следующем месяце пришлёт улучшенную версию. Плохой будет защищаться и говорить, что «у нас все клиенты этим довольны».

Я лично переписывал шаблон отчёта за пять лет три раза. Текущий это компромисс между «достаточно подробно для владельца» и «не теряется в деталях». Если клиент просит конкретный пункт убрать, или добавить что-то своё, переделываю под него.

Регламент это не страшно

Иногда клиенты пугаются слова «регламент»: «у меня маленький сайт, какие там регламенты». На самом деле это просто список из 10-15 пунктов, который показывает, что подрядчик работает по системе, а не «по обращению».

Без регламента подрядчик работает реактивно. С регламентом проактивно. Разница в том, что во втором случае проблемы заранее предотвращаются, а не разгребаются после.

Стоит ли регламент чего-то это вопрос. На моих тарифах регламент входит в стоимость абонентки, отдельной графы за «процессы» нет. Но если посмотреть на структуру цены, около 25 процентов абонентки уходит именно на регламентные работы (мониторинг, обновления, отчёт). Без них тариф был бы дешевле, но и сайт реже бы переживал инциденты без боли.

Куда дальше

Связанные материалы: SLA для маленького сайта, Что входит в техническую поддержку сайта, Acceptance-тестирование после правок.

Мой текущий шаблон отчёта в полном виде высылаю по запросу. Если интересно, заявка через форму на главной, и я пришлю пример с обезличенными данными за прошлый месяц.

Частые вопросы

Что должно быть в регламенте работ по сайту

Список регулярных работ с периодичностью: бэкапы, аптайм-проверки каждые 5 минут, обновления, продление домена и сертификата с алертом заранее. Плюс время реакции на инцидент и правила по лимиту часов.

Что должно быть в ежемесячном отчёте

Что сделано списком с датами и затраченным временем, что случилось из инцидентов и как закрыли, сколько часов израсходовано из лимита, что планируется дальше. Одна-две страницы, не больше.

Чего в отчёте быть не должно

Формулировок вроде проведены работы по оптимизации без указания, каких именно. Скриншотов графиков без выводов. Пунктов, которые повторяются из месяца в месяц одним текстом.

Что делать, если отчёт не устраивает

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