Поддержка самописного сайта: особенности сопровождения

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

Особенности поддержки самописного сайта

Плюсы и минусы поддержки самописного сайта

Если сайт ещё предстоит разработать с нуля, особенности такого подхода разбираем в статье «Создание самописного сайта». Похожий уровень инженерной поддержки требуется и для сайтов на Laravel или Yii.

Практические рекомендации

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

На сайте с готовой CMS большую часть работы по обновлению и безопасности выполняют разработчики платформы. На самописном сайте такого «фонового» сопровождения нет: каждую уязвимость, каждое обновление зависимости и каждое изменение окружения должна отслеживать команда проекта. Это не недостаток, а особенность, которую нужно учитывать при планировании бюджета.

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

Что должно быть передано при начале сопровождения

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

Регламент сопровождения

Работа с кодом: порядок внесения изменений

Ветки и проверка кода

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

Автоматические тесты

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

Публикация и откат

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

Безопасность самописного сайта

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

• Защита от внедрения вредоносных запросов в базу данных и в страницы.
• Корректная проверка прав доступа на каждом действии, а не только в интерфейсе.
• Безопасное хранение паролей и ограничение числа попыток входа.
• Своевременное обновление библиотек и серверного окружения.
• Шифрование соединения и защита служебных данных и ключей.
• Регулярные резервные копии вне основного сервера.

Стоимость сопровождения и доработок

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

Когда сайт нужно рефакторить или переписать

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

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

Как принять сайт без документации

1. Получить все доступы и сделать полную резервную копию кода, базы и файлов.
2. Развернуть копию на отдельном сервере и убедиться, что она работает.
3. Описать структуру проекта: модули, базы, внешние сервисы, периодические задачи.
4. Запустить проверку зависимостей и зафиксировать найденные уязвимости.
5. Составить список рисков и план исправлений с оценкой трудоёмкости.
6. Согласовать регламент и приоритеты на ближайшие три месяца.

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

Как оценивать подрядчика по сопровождению

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

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

Планирование развития сайта

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

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

Как договориться о сроках реакции

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

• Авария, когда сайт недоступен или не принимает заказы: реакция в течение 1 часа в рабочее время и устранение в течение рабочего дня.
• Серьёзный сбой одной из функций: реакция в течение 4 часов и устранение в течение 1–2 рабочих дней.
• Обычные задачи и доработки: реакция в течение 1 рабочего дня, срок определяется после оценки трудоёмкости.

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

Итоговые рекомендации

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

Что запомнить

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

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

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