Техподдержка сайта на Laravel: регламент, SLA и состав абонемента

Техподдержка сайта на Laravel — это обслуживание приложения, а не «правки по звонку». У Laravel-проекта свой набор точек отказа: версия PHP, зависимости Composer, очереди и планировщик, миграции базы, релизный цикл и конфигурация окружений. Сайт может годами открываться без ошибок и при этом быть в одном обновлении пакета от падения — и узнать об этом обычно получается в самый неподходящий момент.

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

Чем поддержка Laravel отличается от поддержки сайта на CMS

Коробочная CMS обновляется кнопкой в админке, и в 90% случаев этого достаточно: ядро и модули ставятся из репозитория, конфликты видны сразу. В Laravel-проекте обновление — это работа с кодом и инфраструктурой, потому что приложение собирается из десятков сторонних пакетов и собственного кода команды.

Отсюда главное отличие: в Laravel-поддержке половина работ — не «починить кнопку», а не дать проекту устареть. Каждая мажорная версия Laravel получает исправления ошибок примерно полтора года и патчи безопасности около двух лет, ветки PHP живут сопоставимо. Проект, который не обновляли два года, чинится уже не патчем, а миграцией — и стоит она в разы дороже абонемента за тот же период. Разница подходов хорошо видна на соседних платформах: в статье техподдержка сайтов на 1С-Битрикс логика та же, но инструменты другие.

Что входит в абонемент

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

• Мониторинг доступности и ошибок. Проверка страниц и ключевых сценариев снаружи, сбор исключений из логов приложения, алерты в чат или на телефон. Мониторинг «сайт отвечает 200» бесполезен, если не работает оплата или личный кабинет.
• Резервные копии с проверкой. База и пользовательские файлы, хранение вне того же сервера, регулярная проверка восстановления. Бэкап, который ни разу не разворачивали, — это надежда, а не резервная копия.
• Обновления. PHP, фреймворк, зависимости Composer, патчи безопасности. Сначала стенд, потом прод, с планом отката.
• Очереди, воркеры и планировщик. Контроль процессов под supervisor или systemd, разбор упавших задач, повторные попытки, устранение «зависших» джобов, проверка cron-задач планировщика.
• Деплой и откат. Предсказуемый релизный цикл: ветки, миграции, переменные окружения, возможность вернуться на предыдущий релиз за минуты, а не за ночь.
• Безопасность. Обновления, права на файлы, секреты в окружении вместо репозитория, защита админки и служебных маршрутов, реакция на инцидент.
• Мелкие доработки и консультации. Правки шаблонов, текстов, логики форм, разбор вопросов по админке.
• Документация и доступы. Инвентаризация: где лежит код, где база, какие сервисы задействованы, кто и как деплоит. Без этого любая авария превращается в археологию.

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

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

1. Единая точка входа. Тикет или чат с историей — не звонок и не сообщение в личный мессенджер разработчика.
2. Приоритет при приёме. Задаче присваивается уровень, от него зависят сроки.
3. Окна для плановых работ. Обновления и деплои — в согласованное время, не в час пик и не в день рекламной кампании.
4. Отчёт. Раз в месяц: что сделано, какие инциденты были, что осталось, что требует решения заказчика.

Приоритеты и сроки реакции — самая практичная часть регламента. Рабочий вариант:

SLA: что фиксировать в договоре

SLA — не «мы отвечаем быстро», а измеримые обязательства. В договоре имеет смысл закрепить пять вещей:

• Время реакции и время решения — разные метрики. Реакция — подтверждение, что задачу взяли и диагноз начат. Решение для P1 обычно ограничивают отдельно (например, восстановление работоспособности в течение 4–8 часов), но честный SLA всегда содержит оговорку про причины вне зоны контроля: хостинг, домен, сторонние API, атака на инфраструктуру.
• Каналы и часы. Куда писать, в какое время работает дежурство, что считается выходным днём.
• Состав работ. Что входит в абонемент, что считается доработкой и оплачивается отдельно, как оценивается сверх тарифа.
• Отчётность. Формат и периодичность отчёта, доступ к статусам задач.
• Ответственный на стороне заказчика. Один человек, который утверждает приоритеты и принимает результат, иначе согласование правок занимает больше времени, чем сами правки.

Сколько стоит поддержка Laravel-сайта

В Web-2A сопровождение Laravel-проектов идёт тремя тарифами: «Стандарт» — 10 000 ₽ в месяц (техподдержка, ежедневные бэкапы, мониторинг доступности, обновления, консультации), «Оптима» — 15 000 ₽ (плюс наполнение до 50 страниц и персональный менеджер), «ТОП» — 30 000 ₽ (плюс мелкие доработки, наполнение до 500 страниц и технический аудит). Состав и условия — на странице техподдержка сайтов на Laravel.

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

Что обычно находят в первый месяц

Проекты, которые доходят до поддержки, похожи по набору технического долга. Типичный список:

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

Это не приговор, а план работ на первые недели. Именно поэтому поддержку начинают с аудита, а не с правок.

Как передать проект на поддержку

1. Технический аудит. Версии, зависимости, состояние базы, очереди, бэкапы, безопасность, узкие места по скорости.
2. Доступы и инвентаризация. Репозиторий, сервер, хостинг, домен, сторонние сервисы, платежи, почта.
3. План приведения в порядок. Что критично (безопасность, бэкапы, деплой), что можно отложить.
4. Регламент и SLA. Приоритеты, каналы, окна, отчётность.
5. Стабилизация. Обновления на стенде, исправление найденного, перевод деплоя на предсказуемую схему.

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

Когда абонемент не нужен

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

Web-2A берёт на сопровождение Laravel-проекты, в том числе созданные другими командами. Пришлите ссылку на сайт и опишите, что беспокоит, — предложим состав работ и тариф. Контакты: контакты, телефон +7 (863) 226-56-27, офис в Ростове-на-Дону, работаем по всей России.