План технического обслуживания сайта: календарь на месяц и год

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

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

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

Границы плана важно зафиксировать сразу. В него входят повторяемые работы: проверки доступности, обновления, резервное копирование, ревизия прав, подготовка к нагрузке. Разовые доработки — новые разделы, интеграции, изменение логики — в план не входят, для них нужен отдельный цикл с оценкой и приёмкой. Если смешать регулярные и разовые работы, календарь теряет смысл: невозможно понять, что именно должно повторяться.

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

Результат внедрённого плана наблюдаем: появляется журнал работ, снижается число внезапных отказов, обновления перестают быть рискованным событием. Но гарантировать полное отсутствие аварий нельзя — план снижает вероятность управляемых сбоев, а не отменяет внешние факторы.

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

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

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

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

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

Еженедельный обход

Еженедельная проверка занимает меньше времени, чем кажется, если идти по списку. Сначала проверяются журналы ошибок: нет ли повторяющихся сбоев, которые не видны посетителю. Затем — резервные копии: создана ли последняя копия и пробовали ли её восстанавливать. Потом — ключевые сценарии: оформление заказа, отправка формы, вход в личный кабинет. В конце — свободное место на диске и срок действия сертификатов.

Отдельный пункт — кэширование. В материалах по контролю качества внедрения указано, что для компонентов рекомендуется режим «Авто+Управляемое» или «Авто», а объём файла кэша компонента не должен превышать 1 МБ (ориентир). Это ориентир для проверки: разросшийся кэш может сигналить о проблемах с ключами или о лишних данных.

Ежемесячная ревизия

Ежемесячно стоит смотреть шире. Проверяются обновления ядра и модулей, но не в момент выхода, а по плану — сначала на копии. Пересматриваются права доступа: не осталось ли учётных записей уволенных сотрудников или подрядчиков. Проверяется, не появились ли в журналах ошибки, связанные с устаревшими вызовами. Если на сайте есть собственные компоненты, полезно убедиться, что они не выполняют прямых запросов к базе данных, а работают через API платформы — это рекомендация из чеклиста качества внедрения.

Ежемесячная ревизия — хорошее время для сверки с чеклистом. В чеклисте контроля качества внедрения пункты разбиты на группы: интеграция дизайна и разработка, размещение на хостинге, производительность, безопасность, сдача проекта. Часть пунктов проверяется автоматически, часть — вручную. Для плана обслуживания это удобная рамка: не нужно изобретать проверки с нуля.

Работы после изменений: как не сломать работающий сайт

Порядок для любого изменения

Любое изменение — обновление, правка шаблона, новая настройка — проходит один и тот же путь. Сначала создаётся копия сайта или его части. Затем резервируются данные, которые изменение затрагивает. После этого изменение проверяется на копии. И только потом переносится на боевой сайт. Если что-то пошло не так, должен быть план возврата: как вернуть прежнее состояние и за какое время.

Этот порядок кажется медленным, но он экономит время при сбое. Обновление сразу на боевом сайте — самая частая причина внезапных отказов. Даже небольшое обновление модуля может затронуть шаблон или кэш, поэтому проверка на копии обязательна.

Что проверять после обновления

После переноса изменения проверяются ключевые сценарии, журналы ошибок и кэш. Если обновление затрагивало компоненты, стоит убедиться, что кэш сброшен корректно и страницы отдают актуальные данные. Если менялись права доступа — проверить, что редакторы видят нужные разделы, а лишние доступы закрыты.

В материалах по разработке на Битрикс отмечается, что собственные компоненты должны профилироваться встроенными средствами, а число и сложность запросов к базе данных — соответствовать задаче. Для плана обслуживания это означает: после изменений в коде полезно смотреть не только на внешний результат, но и на нагрузку. Если страница стала открываться заметно дольше, это повод проверить кэширование и запросы, а не ждать сезонного пика.

Подготовка к сезонной нагрузке: что проверить заранее

За месяц до пика

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

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

За неделю до пика

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

Учебный пример: план обслуживания для интернет-магазина на месяц и год

Учебный пример. Условный интернет-магазин «Северный сад» продаёт саженцы. Каталог — около 1 200 товаров, три менеджера, пик заказов — апрель и май. Сайт работает на Битрикс, есть тестовая копия. Данные условные и не являются статистикой.

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

Месячный цикл выглядит так. Первая неделя — обновление ядра и модулей на копии, проверка ключевых сценариев, перенос на боевой сайт. Вторая неделя — ревизия прав доступа и учётных записей. Третья неделя — проверка резервных копий и пробное восстановление на копии. Четвёртая неделя — отчёт о работах и план на следующий месяц.

Годовой цикл: январь — ревизия плана и инфраструктуры; февраль — подготовка к весеннему пику, проверка кэширования; март — тестовый прогон нагрузки на копии; апрель и май — усиленный мониторинг, заморозка несрочных изменений; июнь — разбор пика и корректировка плана; июль — плановые обновления; август — ревизия прав; сентябрь — подготовка к осеннему сезону; октябрь — проверка резервных копий; ноябрь — подготовка к декабрьскому пику; декабрь — усиленный мониторинг.

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

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

Как проверить результат и принять работу по плану

Критерии приёмки

Приёмка идёт не по факту «что-то делали», а по журналу и критериям. Для каждой работы должен быть виден результат: обновление установлено, копия создана и проверена, права пересмотрены, отчёт сдан. Если работа не выполнена, фиксируется причина и переносится на следующий период.

• Для каждой работы в календаре указан ответственный и срок.
• Ведётся журнал выполнения за период.
• Ключевые сценарии проверены на копии и на боевом сайте.
• Резервная копия создана, восстановление проверено на копии.
• Обновления установлены по порядку: копия, проверка, перенос.
• Права доступа пересмотрены, лишние учётные записи закрыты.
• Отчёт содержит отклонения от плана и принятые решения.
• План на следующий период обновлён с учётом инцидентов.

Что делать с отклонениями

Отклонения — нормальная часть обслуживания. Важно не скрывать их, а разбирать. Если обновление переносилось без проверки, нужно понять причину: не было копии, не хватило времени, не сработал план возврата. Если резервная копия не восстанавливалась, это риск, который нужно закрыть в следующем периоде. Отклонения фиксируются в отчёте и влияют на план.

Типичные ошибки при составлении плана обслуживания

Первая ошибка — план без ответственных. Работа есть, срок есть, а кто её делает — непонятно. Вторая — отсутствие критериев: непонятно, что считать выполненным. Третья — обновления сразу на боевом сайте. Четвёртая — редкая проверка резервных копий: копия может создаваться, но не восстанавливаться. Пятая — игнорирование сезонности: план не учитывает пики, и подготовка начинается слишком поздно. Шестая — смешивание регулярных и разовых работ. Седьмая — отсутствие журнала: через месяц невозможно вспомнить, что делали. Восьмая — план не пересматривается: он устаревает вместе с сайтом.

Ограничения плана и что он не заменяет

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

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

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

Какие исходные данные подготовить для оценки плана

Чтобы составить план, нужны исходные данные. Без них календарь получится общим и неприменимым. Собрать стоит следующее:

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

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