Заканчивается ли работа разработчика после запуска сайта?
Нет — хотя часто выглядит именно так. Приёмка проекта — это не финал, а начало новой фазы: в момент сдачи всё работает (актуальный PHP, выпущенный SSL, форма отправляет заявки, хостинг тянет нагрузку, контент вычитан), но дальше начинается эксплуатация, и она не стоит на месте. Без отдельной договорённости о сопровождении ответственность за это обычно ни на кого не закреплена.
PHP и библиотеки выходят с обновлениями безопасности, часть из них закрывает реальные уязвимости. Сертификат SSL продлевается автоматически не везде и не всегда — бывает, что домен продлил один сотрудник, а хостинг оплачивал другой, и в итоге не продлил никто. Форма может перестать отправлять письма после смены SMTP-настроек у хостера, а редактор контента — сломать вёрстку блока, вставив кусок текста из Word. По отдельности это мелочи. Вместе — источник простоев, которые владелец сайта обычно замечает последним: через звонок клиента «а у вас сайт не открывается» или через падение заявок, причину которого никто не искал неделю.
Разработчик, который сдал проект, часто недоступен «по умолчанию» — он либо переключился на новый заказ, либо готов помочь, но не обязан и не гарантирует срок реакции. Разница между «могу посмотреть на неделе» и «отвечаю в течение суток по договору» — это и есть смысл сопровождения.
«Починим, когда сломается» vs регулярное сопровождение
Реактивный подход выглядит логично на старте: зачем платить за то, что не сломалось. На практике у него есть цена, которая проявляется позже.
Во-первых, время реакции непредсказуемо. Без обязательств исполнитель чинит по остаточному принципу — между другими проектами. Если сайт приносит заявки каждый день, сутки простоя — это не абстракция, а конкретная упущенная выручка.
Во-вторых, реактивная модель не предотвращает проблему, а устраняет её последствия. Обновление PHP до конца жизненного цикла версии, ротация зависимостей с известными уязвимостями, настроенные бэкапы — всё это снижает вероятность инцидента, но требует, чтобы кто-то делал это регулярно, а не после первого взлома или сбоя.
В-третьих, у реактивной модели нет памяти о проекте. Каждый новый инцидент решает человек, который заново разбирается в коде, хостинге и истории решений — это дольше и дороже разового фикса у того, кто уже ведёт сайт.
Сопровождение — это не «страховка на всякий случай», а перенос части операционных рисков на исполнителя, который берёт на себя обязательство следить за проектом на регулярной основе, а не только когда что-то уже упало.
Что обычно входит в сопровождение
Набор задач у разных студий отличается деталями, но костяк устойчив:
- Инциденты — 500-я ошибка, сломанная интеграция, недоступный сайт: разбор причины, исправление, короткий отчёт о том, что произошло и почему.
- Обновления и безопасность — плановые патчи PHP, CMS и зависимостей, без «сюрпризов в пятницу вечером» на боевом сервере.
- Резервные копии — настройка расписания бэкапов и проверка, что они реально восстанавливаются, а не просто лежат архивом на диске.
- Мелкие и средние правки — обновить текст, добавить поле в форму, поправить верстку блока — в рамках оговорённого объёма часов.
- Отчёт — что сделано за период, сколько часов израсходовано, какие риски видны на горизонте.
Это операционная гигиена, а не разработка новых модулей — но именно она держит сайт живым между релизами. Подробнее о наборе работ и тарифах — на странице технического сопровождения.
Чем сопровождение не является
Здесь чаще всего возникает путаница, поэтому стоит обозначить границы явно.
Сопровождение — это не безлимитная разработка. Пакет часов покрывает поддержание и точечные правки, а не создание нового раздела каталога, интеграцию с новой CRM или редизайн главной страницы. Такие задачи оцениваются и ведутся отдельно — как проектная работа или как развитие продукта, если фичи выходят регулярно и нужен приоритет в очереди.
Сопровождение — это не маркетинг и не продвижение. Оно не приведёт новый трафик и не поднимет позиции в поиске само по себе: это отдельная задача с другой логикой и другим набором работ — технический SEO и производительность.
И сопровождение — не гарантия нулевых простоев. Ни один договор не исключает сбои у хостера, DDoS или отказ стороннего API. Задача сопровождения — сократить время обнаружения и реакции, а не обещать невозможное.
Понимание этих границ на старте экономит время обеим сторонам: клиент не ждёт от пакета часов того, что тот не покрывает, а исполнитель не тратит время на споры о том, входит ли новая фича в «мелкую правку». Границы стоит зафиксировать в договоре явно — какие задачи идут в счёт часов, а какие оцениваются отдельно.
Связка с мониторингом: узнать о падении раньше клиента
Сопровождение без мониторинга работает вслепую: команда узнаёт о проблеме из письма клиента или, хуже, из звонка «а что у вас с сайтом». С мониторингом порядок обратный — алерт о падении приходит раньше, чем кто-то из посетителей успевает пожаловаться.
Мы подробно разбирали, как устроен собственный сервис мониторинга сайтов на Laravel и Filament — периодические HTTP-проверки, контроль SSL и домена, алерты при смене статуса. На практике это не отдельная услуга «для галочки», а часть той же ответственности: если сайт на мониторинге и одновременно на техническом сопровождении, клиент получает 2 часа работ в месяц бесплатно — на настройку алертов, мелкие правки, помощь с SSL. Мониторинг фиксирует факт проблемы, сопровождение её решает — по отдельности каждый инструмент закрывает только половину задачи.
Кому нужен пакет часов, а кому SLA
Формат сопровождения зависит от того, насколько сайт критичен для бизнеса ежедневно.
Пакет часов подходит стабильному проекту без ежедневных изменений — визитке, корпоративному сайту, каталогу услуг. Здесь важно не время реакции в минутах, а сам факт, что раз в месяц кто-то проверяет обновления, чинит то, что накопилось, и отвечает в разумный срок, если что-то сломалось.
SLA с фиксированным временем реакции нужен, когда сайт или система — часть ежедневных продаж: интернет-магазин, CRM с заявками, портал с личным кабинетом. Здесь простой на несколько часов ощутимо бьёт по выручке, и разница между «ответим сегодня» и «ответим в течение двух часов» перестаёт быть формальностью.
Для проектов с несколькими системами, интеграциями и жёсткими требованиями к доступности логика та же, но масштабируется: выделенный объём часов, приоритетная очередь и координация с внутренней IT-командой клиента, если она есть. Конкретный объём часов и условия реакции обсуждаются индивидуально — универсального тарифа «на все случаи» не бывает, потому что риски у визитки и у магазина с ежедневными платежами разные.
Есть и промежуточный случай: сайт стабилен большую часть года, но раз в квартал — распродажа, набор на курс, сезонный всплеск заявок — и именно в эти недели простой критичен. Здесь разумно держать базовый пакет часов на фоновую эксплуатацию и заранее договариваться об усиленном режиме реакции на пиковый период, а не пытаться держать SLA уровня интернет-магазина круглый год ради двух недель в квартале.
Вопросы
Нужно ли сопровождение, если сайт делали не вы?
Нет, это не обязательное условие. Первым шагом обычно идёт onboarding-аудит: разбираемся в коде, хостинге и деплое, прежде чем брать на себя ответственность за продакшен.
Чем сопровождение отличается от разовой поддержки «по звонку»?
Разовая задача решается по отдельной оценке, без гарантии срока реакции — исполнитель может быть занят другим проектом. Сопровождение — это предсказуемый объём работ и приоритет в очереди задач.
Можно ли совместить сопровождение с разработкой новых функций?
Да. Сопровождение отвечает за стабильность текущей версии сайта, а развитие — за новые фичи и доработки. Это разные по логике задачи, которые часто идут параллельно.
Что будет, если закончатся часы в пакете раньше конца месяца?
Обычно это сигнал пересмотреть объём на следующий период либо перейти на задачи по фактической оценке сверх пакета — конкретный механизм фиксируется в договоре.
Сопровождение работает только с сайтами на Laravel?
Нет. Стек оценивается на аудите — работаем и с проектами на других технологиях, если код и хостинг позволяют вести их ответственно.
Что делать дальше
Если сайт уже в проде и никто не отвечает за него на регулярной основе — это стоит закрыть раньше, чем случится первый заметный простой. Посмотрите тарифы и состав работ на странице технического сопровождения, подключите мониторинг, чтобы узнавать о сбоях раньше клиентов, и оставьте заявку через форму на главной — обсудим объём часов под ваш проект. Если сайт ещё только планируется, полезно заранее заложить бюджет на сопровождение в смету — как в статье «Сколько стоит сайт под ключ», а для регионального контекста — в материале «Сайт для бизнеса в ПМР и Молдове».