Пока веб-студия ведет один или два проекта, вопрос хостинга обычно решается без особой системы. Сайт разместили там, где было удобно разработчику, пароль сохранили, домен подключили и перешли к следующему заказу. Проблемы начинаются позже, когда клиентов становится десять, двадцать или пятьдесят.
Один заказчик просит дать доступ новому программисту. Второй решил уйти в другую студию. У третьего закончилась оплата домена. Четвертый сайт внезапно начал потреблять все доступные ресурсы. На пятом нужно обновить PHP, но остальные проекты на аккаунте трогать нельзя.
В этот момент становится понятно, что хостинг для веб-студии нужно выбирать не только по цене и объему диска. Важнее то, насколько удобно разделять проекты, управлять доступами, создавать тестовые копии, переносить сайты и передавать их заказчикам.
Единственного правильного способа размещать клиентские сайты нет. Студия может использовать отдельный аккаунт для каждого клиента, реселлерский хостинг, собственный VPS или сочетать несколько вариантов. Выбор зависит от количества проектов, технологий и от того, кто после запуска отвечает за сайт.
Кому должен принадлежать хостинг клиентского сайта
Это первый вопрос, который лучше решить еще до выбора провайдера.
Самая прозрачная схема выглядит просто: домен и хостинг принадлежат заказчику, а студия получает необходимые доступы для разработки и обслуживания.
У такого подхода есть большое преимущество. Если сотрудничество закончится, клиенту не нужно переносить сайт только потому, что он решил сменить подрядчика. У него уже есть собственный аккаунт, платежные данные и контроль над услугой.
Для студии эта схема тоже снимает часть организационных проблем. Она не должна помнить, когда каждому клиенту оплачивать хостинг, собирать деньги за продление и объяснять, почему сайт отключился после неоплаченного счета.
Но на практике отдельные аккаунты не всегда удобны.
Представим студию, которая создает и постоянно обслуживает несколько десятков небольших сайтов. Заказчики не хотят самостоятельно заниматься хостингом. Для них сайт, домен, техническая поддержка и обновления являются одной услугой.
Тогда централизованное размещение становится вполне разумным.
Главное, чтобы оно было организовано как услуга, а не как случайная коллекция клиентских сайтов внутри личного аккаунта разработчика.
Нужно заранее определить, кому принадлежат данные, что происходит при прекращении обслуживания, как клиент получает копию проекта и можно ли перенести его на отдельный аккаунт.
Особенно осторожно стоит относиться к доменам.
Даже если студия полностью обслуживает сайт, домен коммерческого проекта лучше регистрировать на самого клиента. Потерять доступ к файлам неприятно, но сайт можно восстановить из резервной копии. Спор о контроле над доменным именем способен создать гораздо более серьезную проблему.
Хорошая схема не должна удерживать клиента техническими препятствиями. Если заказчик решил уйти, студия передает файлы, базу данных и необходимые настройки или помогает перенести проект.
Такая возможность полезна не только клиенту. Она дисциплинирует внутреннюю инфраструктуру самой студии. Если любой проект можно относительно быстро отделить от остальных, значит сайты не превратились в неразделимый клубок.
Один аккаунт, реселлерский хостинг или VPS
Для нескольких собственных сайтов обычный тариф с поддержкой множества доменов может быть прекрасным решением. Для независимых клиентских проектов требования меняются.
Главный недостаток одного общего аккаунта заключается не в количестве сайтов, а в слабой изоляции.
Если все проекты работают в одном окружении и под одной учетной записью, проблемы одного сайта потенциально могут затронуть остальные. Последствия зависят от устройства конкретного хостинга, но сама идея складывать десятки независимых коммерческих проектов в одну корзину требует осторожности.
Есть и бытовая проблема с доступами.
Допустим, стороннему разработчику клиента нужно изменить несколько файлов. Давать ему главный доступ от аккаунта, где находятся сайты других заказчиков, нельзя. Приходится создавать отдельный FTP или SFTP доступ и внимательно ограничивать его нужным каталогом.
Когда подобных ситуаций много, управление становится неудобным.
Отдельный аккаунт для каждого клиента решает проблему радикально. У каждого проекта свои данные для входа, ресурсы, резервные копии и настройки. Один сайт легче передать другому подрядчику или перенести к другому провайдеру.
Недостаток очевиден: студии приходится управлять множеством учетных записей и оплат.
Промежуточным вариантом является реселлерский хостинг.
Студия получает возможность создавать отдельные клиентские аккаунты внутри одной системы управления. В зависимости от провайдера можно назначать им тарифы, ограничения ресурсов и собственные доступы.
Такой формат особенно удобен, если студия не просто создает сайты, а продает дальнейшее техническое обслуживание как регулярную услугу.
Клиенту не обязательно знать детали инфраструктуры. Он платит студии за работающий сайт, а студия самостоятельно управляет размещением.
Но реселлерский тариф не стоит путать с собственным сервером.
Обычно физической инфраструктурой, операционной системой и значительной частью серверного окружения продолжает заниматься хостинг-провайдер. Студия управляет своими клиентскими аккаунтами, не превращаясь при этом в полноценного системного администратора.
VPS дает значительно больше свободы.
Можно самостоятельно выбирать программное окружение, устанавливать нужные сервисы, создавать отдельные сайты и пользователей, настраивать версии программ и автоматизировать развертывание.
Для технически сильной веб-студии это удобно.
Но вместе со свободой появляется ответственность.
Кто будет устанавливать обновления безопасности? Кто заметит, что заканчивается место? Кто восстановит сервер после неудачной конфигурации? Где находятся резервные копии? Что произойдет ночью, если веб-сервер перестанет отвечать?
Если на эти вопросы нет конкретного ответа, VPS может оказаться не преимуществом, а дополнительным источником проблем.
Студии без собственного администратора стоит рассмотреть управляемый VPS либо оставить обычные клиентские проекты на хостинге, где серверную часть обслуживает провайдер.
Необязательно выбирать одну технологию для всех клиентов.
Небольшие сайты компаний можно держать на виртуальном или реселлерском хостинге. Ресурсоемкий интернет-магазин разместить на отдельном VPS. Для нестандартного приложения использовать инфраструктуру, которая подходит именно его стеку.
Чем больше становится студия, тем меньше смысла пытаться втиснуть все проекты в один универсальный тариф.
Какие функции хостинга действительно нужны веб-студии
При выборе тарифа легко увлечься количеством гигабайт. Для студии гораздо важнее инструменты, которые экономят время при ежедневной работе.
Раздельные доступы
Возможность создавать отдельных пользователей и ограничивать их права очень полезна.
Разработчику может требоваться доступ к файлам, но не к платежам. Клиенту нужен собственный кабинет, но не административный доступ ко всем проектам студии. Внешнему специалисту иногда требуется подключение только к одному сайту.
Чем точнее можно разделить права, тем реже приходится раздавать главный пароль.
Для технической работы удобны SFTP и SSH. Они позволяют безопасно работать с файлами и выполнять серверные операции без постоянного использования файлового менеджера в браузере.
Разные версии PHP и настройки окружения
У веб-студии редко все проекты одинаковые.
Один сайт только что создан и работает на актуальной версии PHP. Второй существует несколько лет и использует старый плагин. Третий находится в процессе обновления.
Если изменение версии PHP применяется сразу ко всему аккаунту, обслуживание такой коллекции становится рискованным.
Удобнее, когда окружение можно настраивать отдельно для каждого сайта.
Это не означает, что устаревшие версии нужно сохранять бесконечно. Старые проекты необходимо постепенно обновлять. Но возможность проводить миграцию по одному сайту значительно безопаснее массового переключения.
Тестовые копии
Staging особенно полезен именно студии.
Обновлять рабочий сайт клиента напрямую, а затем проверять, сломалось ли что-нибудь, плохая привычка. Чем важнее проект, тем дороже может оказаться такая экономия времени.
На тестовой копии можно обновить CMS, заменить плагин, проверить новую версию PHP, изменить шаблон или протестировать крупную доработку.
После проверки изменения переносятся на рабочий сайт.
Если хостинг умеет создавать staging автоматически, это экономит время. Если нет, тестовую среду можно организовать самостоятельно, но тогда студии нужен понятный внутренний процесс.
Резервное копирование
Для клиентских проектов одного обещания делаем бэкапы недостаточно.
Нужно знать частоту создания копий, срок хранения, способ восстановления и что именно попадает в резерв.
Особенно важно не путать резервную копию сайта с полной стратегией восстановления.
Если все копии находятся на той же инфраструктуре и доступны только через тот же аккаунт, серьезная проблема с учетной записью или площадкой может осложнить восстановление.
Для важных проектов студии полезно иметь независимые копии критичных данных.
Git и автоматизация
Небольшой сайт можно обновлять вручную. Когда проектов десятки, повторяющиеся действия начинают съедать рабочее время.
Если команда использует Git, возможность удобно развертывать код из репозитория становится плюсом. Более зрелый процесс может включать автоматические проверки и развертывание после утверждения изменений.
Не каждому сайту нужен сложный CI/CD. Но инфраструктура не должна мешать студии автоматизировать то, что она делает постоянно.
Логи и мониторинг
Фраза сайт не работает слишком расплывчата для технической поддержки.
Нужен доступ к журналам ошибок, статистике ресурсов и другим данным, которые помогают понять причину проблемы.
Полезно дополнительно использовать внешний мониторинг доступности для клиентских проектов, за которые студия отвечает после запуска.
Тогда о сбое можно узнать раньше звонка заказчика.
Как организовать хостинг клиентских сайтов без хаоса
Даже хороший провайдер не спасет, если внутри студии нет порядка.
Начать можно с простой инвентаризации.
Для каждого проекта стоит знать домен, владельца домена, хостинг, владельца аккаунта, дату продления, используемые технологии, версию PHP, способ резервного копирования и ответственного сотрудника.
Пароли при этом не нужно хранить в общей таблице. Для учетных данных лучше использовать нормальный менеджер паролей с контролем доступа.
Очень полезно разделить проекты по критичности.
Сайт небольшой мастерской из пяти страниц и интернет-магазин с ежедневными заказами не должны автоматически получать одинаковую инфраструктуру только потому, что их создавала одна студия.
Для каждого проекта стоит заранее понимать допустимый простой и последствия потери данных.
От этого зависит частота резервного копирования, необходимость мониторинга и уровень изоляции.
Еще одно хорошее правило: новый клиентский сайт не должен появляться на сервере просто потому, что там пока есть свободное место.
Сначала нужно определить его требования.
Какая CMS или технология используется? Нужны ли фоновые процессы? Сколько места занимают файлы? Есть ли почта? Как меняется база данных? Планируется ли высокая посещаемость? Кто будет обслуживать проект после запуска?
После этого выбирается площадка.
Стоит заранее определить и процедуру передачи сайта.
Если клиент прекращает обслуживание, сотрудник студии не должен каждый раз придумывать, что делать. Должен существовать понятный сценарий: подготовить актуальную копию, передать базу, файлы и необходимые настройки, помочь со сменой DNS при необходимости и удалить проект из инфраструктуры студии после подтверждения переноса.
То же относится к доступам сотрудников.
Когда разработчик покидает команду, его доступы должны быть отключены централизованно. Если для всех проектов использовался один общий пароль, это превращается в многочасовую смену учетных данных.
Поэтому хорошая инфраструктура веб-студии начинается не с мощного сервера, а с разделения ответственности.
Небольшой команде с несколькими клиентами часто достаточно отдельных аккаунтов виртуального хостинга. Студии, которая берет сайты на постоянное обслуживание, может быть удобен реселлерский тариф. Команде разработчиков со своими специалистами по инфраструктуре постепенно становится интереснее VPS и автоматизированное развертывание.
Самый дорогой вариант не обязательно самый профессиональный.
Профессиональная схема та, в которой понятно, где находится каждый сайт, кому он принадлежит, кто имеет к нему доступ, как его восстановить и как передать клиенту.
Если для отделения одного заказчика от остальных приходится распутывать каталоги, общие пароли и неизвестно кому принадлежащие домены, проблема уже не в хостинге.
Хорошо организованная веб-студия должна уметь принять новый проект и так же спокойно с ним расстаться. Хостинг в этой системе является не складом для файлов клиентов, а частью рабочего процесса разработки и поддержки сайтов.
