От общего хостинга к собственной инфраструктуре: руководство для основателей стартапов

Почему привычки общего хостинга перестают работать

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

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

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

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

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

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

Как выглядит владение инфраструктурой в повседневной работе

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

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

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

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

Видимость так же важна. Запишите, куда идут логи, кто получает оповещения и где хранятся бэкапы. Если сайт тормозит в 2:00 ночи, кто‑то должен знать, куда смотреть первым делом. Если база падает, кто‑то должен знать, какой бэкап актуален и как его восстановить.

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

Планируйте переезд, не ломая сайт

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

Сохраните файлы сайта, базу данных, планировщик задач, записи DNS, данные SSL и настройки почты. Этот снимок даст вам чистый путь назад, если что‑то пойдёт не так.

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

Храните секреты и настройки в одном месте. Пароли к БД, API‑ключи, SMTP‑данные и переменные окружения не должны храниться в старых заметках или чатах. Поместите их в контролируемое хранилище и четко пометьте. Малые команды часто пропускают это и потом тратят полдня, угадывая актуальный пароль.

Используйте staging‑копию перед запуском. Ей не нужно быть сложной — достаточно, чтобы она вела себя как реальный сайт, чтобы вы могли тестировать обычные действия пользователей без риска. Восстановите свежий бэкап на новом сервере, подключите те же сервисы, что нужны живому сайту, и проверьте входы, формы, платежи, письма и загрузки файлов. Полезно попросить кого‑то со стороны пройтись по основным сценариям — свежий взгляд ловит простые упущения.

День запуска должен иметь конкретный и скучный план отката. Решите, кто может переключить трафик обратно, какой бэкап восстанавливать в первую очередь и сколько времени ждать, прежде чем признать миграцию неудачной. Запишите шаги. Если люди вынуждены выдумывать план во время инцидента, подготовка была неготовой.

Настройте бэкапы в первую очередь

Перед тем как менять сервер, DNS или процесс деплоя, сделайте бэкапы своей обязанностью.

Начните с базы данных. Поставьте её на расписание до любых других изменений. Для небольшого стартапа чаще всего хватает ночного бэкапа на начальном этапе. Если заказы, бронирования или сообщения клиентов приходят круглосуточно, делайте бэкапы чаще.

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

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

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

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

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

Контролируйте доступ без единого общего администратора

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

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

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

Ограничьте доступ к живой системе. В молодой компании обычно нуждаются в доступе немногие: один основатель, технический лидер или CTO, один инженер, делающий деплои, и один резервный человек на случай экстренных ситуаций. Остальные работают с ограниченным доступом. Дизайнеру может быть нужен доступ к CMS, но не к серверу. Маркетинг‑подрядчику — аналитика, но не DNS. Если прошлое агентство делало сайт, у него не должно оставаться полных админ‑прав навсегда.

Удаляйте старых подрядчиков и неиспользуемые аккаунты сразу при смене ролей. Не оставляйте аккаунты активными «на всякий случай». Такая привычка создаёт тихий риск, и никто не замечает, пока не станет возможен вход у неподходящего человека.

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

Сделайте развертывания повторяемыми

Если команда всё ещё копирует файлы прямо на живой сервер, мелкие правки легко перерастают в долгие ночи. Один файл пропал, одна настройка слетела, и никто не понимает, где ошибка.

Начните с системы контроля версий. Храните код в Git, даже если один разработчик делает большую часть работы. Вы получите ясную историю: что поменялось, когда и какая версия сейчас в продакшне. Когда после релиза появляется баг, команда может увидеть точное изменение, вместо того чтобы гадать.

Используйте одну команду, скрипт или простую CI‑цепочку для каждого деплоя. У команды не должно быть трёх способов публиковать обновления. Если кто‑то пользуется FTP, другой копирует файлы вручную, а третий перезапускает сервисы по памяти, ошибки накапливаются. Один путь делает релизы скучными, а скучные релизы — это хорошо.

Процесс развертывания для маленькой команды может быть простым: вливаем одобренные изменения в main, прогоняем те же проверки, деплоим одним скриптом или CI‑заданием, маркируем релиз тегом вроде v1.4.2 и сохраняем короткую заметку о том, что изменилось.

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

Напишите короткий чек‑лист релиза и держите его на виду. Укажите, кто одобряет релиз, нужен ли бэкап базы перед деплоем, кто следит за ошибками после выпуска и кто принимает решение об откате. Это поместится на полстраницы.

Не нужен огромный DevOps‑парк в первый день. Нужен один чистый процесс, которого команда придерживается каждый раз.

Добавьте простой мониторинг

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

Большинству маленьких команд эффективнее несколько проверок, которые они просматривают каждый день, чем гигантская панель, которую никто не понимает.

Что смотреть в первую очередь

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

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

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

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

Для маленькой команды достаточно одного сервиса проверки аптайма, трекера ошибок и места, где можно посмотреть базовую статистику сервера. В больших продакшен‑сетапах Oleg Sotnikov часто работает с инструментами вроде Sentry, Grafana и Prometheus. Урок для основателей проще: выберите небольшой набор проверок, отправляйте оповещения людям и просматривайте их целенаправленно.

Мониторинг не должен быть шикарным. Он должен быть видимым, назначенным и постоянным.

Сценарий для основателя

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

Основатель думает, что миграция пройдёт просто. Но один вопрос выявляет риск: «Кто понимает, как устроен сервер?» Только один разработчик. Шаги деплоя живут в его голове, а команда всё ещё делит один админ‑логин.

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

Этот день меняет работу команды. Они начинают отправлять бэкапы в отдельное место и тестировать восстановление. Даёт каждому человеку отдельный логин. Убирают широкие права у тех, кому они не нужны. Записывают точные шаги деплоя. Добавляют оповещения по аптайму, дисковому пространству и ошибкам приложений.

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

Вот где настоящая разница. Владение инфраструктурой — это не покупка более мощного сервера. Это знание того, кто имеет доступ, где бэкапы, как проходят релизы и как команда видит проблемы раньше пользователей.

Ошибки, которые создают риск

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

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

Контроль доступа тоже быстро разрушается. Команды часто хранят один root‑пароль в чате, чтобы «быстро двигаться». Позже никто не видит, кто что менял, нельзя аккуратно убрать доступ у ушедшего подрядчика и трудно ограничить права.

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

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

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

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

Проверьте передачу перед тем, как полагаться на неё

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

Отнеситесь к этому как к реальному тесту. Попросите другого человека зайти на сервер, в аккаунт хостинга, репозиторий кода и панели инструментов со своим аккаунтом. Если он заблокирован, у вас ещё есть пробел.

Проведите учение по восстановлению бэкапа. Поднимите приложение и базу в тестовой среде, затем проверьте, что сайт действительно стартует и данные на месте.

Храните короткую заметку о каждом релизе: что изменилось, когда и кто одобрил.

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

Запишите ежемесячные расходы на хостинг, домены, почту, мониторинг и хранение бэкапов. Добавьте владельца каждого счёта и где хранится платёжный метод. Проблемы с биллингом могут снять сайт так же эффективно, как и технические ошибки.

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

Если что‑то звучит расплывчато — передача ещё не готова. Почините это до следующего релиза, а не во время сбоя в 2 ночи.

Когда привлекать помощь

Большинству основателей не нужен полный ремонт. Нужна одна безопасная правка на этой неделе. Если бэкапы неясны — начните с них. Если несколько человек делят один админ‑аккаунт — исправьте доступы. Если никто не может объяснить, как проходит деплой — запишите и один раз протестируйте.

Превратите заметки в короткий runbook. Часто достаточно одной страницы, если она отвечает на несколько базовых вопросов: что и где бэкапится, кто имеет доступ к серверам и DNS, как команда делает деплой и откат, и какие оповещения критичны.

Этот документ помогает, когда разработчик уходит, плагин ломается или трафик скачет после релиза. Он быстро выявляет слабые места. Если всё ещё один человек хранит ответы в голове — работы ещё много.

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

Если вам нужен практический аудит, Oleg Sotnikov на oleg.is работает со стартапами именно по этим вопросам. Он помогает командам укрепить бэкапы, доступы, развертывания и мониторинг, не превращая небольшую систему в чрезмерно сложную.