Сайт запущен — это не финал: почему техподдержка это ежемесячный расход

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

Проблема в том, что сайт не существует в вакууме. Всё, что работает под капотом — ядро CMS, плагины, платёжный модуль, сертификат безопасности, серверное окружение — постоянно меняется, пока сам сайт остаётся неизменным. Разница не заметна за один день. Обычно она копится месяцами и проявляется разом: форма перестаёт отправлять письма, админка тормозит, браузер пишет в адресной строке «небезопасно».

«Готово» — статус объекта, а не программы

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

Например, у Let's Encrypt — самого распространённого поставщика TLS-сертификатов — стандартный сертификат действует всего 90 дней, и продление рекомендуется каждые 60 дней (letsencrypt.org). В норме это происходит автоматически и незаметно. Но при переезде на другой сервер, смене DNS-записей или сбое в автоматизации это продление молча останавливается — и первым об этом узнаёт посетитель, увидевший предупреждение в браузере. Единственное решение — обращаться с сайтом не как со сданным объектом, а как с живой системой, требующей постоянного ухода.

Почему сайт без обслуживания стареет сам по себе

Старение — не одна причина, а несколько мелких процессов, идущих параллельно:

• Копятся обновления ядра и плагинов. Большая часть сайтов в мире работает на системах управления вроде WordPress — по данным w3techs.com, на неё приходится 41,2% всех сайтов (w3techs.com). Каждая новая версия обычно закрывает уязвимости, найденные в предыдущей. Без обновления закрытая дыра остаётся открытой, потому что список закрытых в каждой версии уязвимостей публикуется в открытых базах, и автоматические сканеры проверяют по нему тысячи сайтов ежедневно.
• Сторонние интеграции меняются без предупреждения. Карты, оплата, виджет чата обновляются на своей стороне; на сайте ничего не менялось, а интеграция в один день просто перестаёт работать.
• Вес контента растёт незаметно. Каждая новая страница, картинка, запись в блоге добавляет несжатые файлы, и общий вес страницы медленно ползёт вверх — по одному изменению этого не почувствовать.
• Серверное окружение тоже не стоит на месте. Версия базы данных, версия языка программирования, конфигурация хостинга время от времени требуют обновления; сайт на устаревшей версии одновременно и замедляется, и остаётся уязвимым к новым дырам.
• Резервная копия существует, но не проверена. Раз автоматический бэкап работает, кажется, что всё в порядке. Настоящая проверка происходит только в момент, когда восстановление реально нужно — и это худший момент для первой проверки.

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

Типичная картина за 12 месяцев

Следы этих процессов не видны в первые месяцы, потому что каждый по отдельности мал. Обычно картина складывается поэтапно:

• 1–4-й месяцы: ничего не меняется, потому что накопления ещё недостаточно. Владелец читает эту тишину как «всё в порядке».
• 5–6-й месяцы: появляются первые мелкие симптомы — какая-то интеграция тихо перестаёт работать, админка открывается на секунду дольше. По отдельности ни один из них не привлекает внимания.
• 9–12-й месяцы: мелкие проблемы начинают накладываться друг на друга — вес медиафайлов замедляет первую загрузку, продление сертификата даёт сбой, уведомления с формы замолкают из-за смены ключа API.

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

Сайт без обслуживания не ломается сразу — он медленно разваливается там, куда никто не смотрит.

Реальный список ежемесячных работ

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

Обновления безопасности

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

Изменения в контенте

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

Устранение сбоев и время реакции

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

Ежемесячный отчёт

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

Когда обслуживание должно начинаться

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

Почему это ежемесячный расход, а не разовая работа

Разработка сайта — разовый проект: у него есть старт, финиш и дата сдачи. Обслуживание работает по другой логике — ежемесячный объём часов и время реакции согласуются заранее и повторяются каждый месяц, потому что меняющаяся среда тоже повторяется каждый месяц. Считать это разовой статьёй бюджета — ошибка; оно работает как страховка: в большинстве оплаченных месяцев внешне «ничего не происходит», и именно поэтому проблема не успевает разрастись.

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