Стартап получил инвестиции: что менять в инфраструктуре в первую очередь

MAATRIX

Раунд закрыт, деньги на счету — и первый инстинкт почти у всех фаундеров одинаковый: купить сервер помощнее, поднять кластер «как у больших», нанять сразу целую DevOps-команду. Проблема в том, что за месяцы bootstrap-режима у вас наверняка накопился список компромиссов, о которых вслух не говорили, потому что «сейчас не до этого» — сервер, который держится на честном слове одного разработчика, бэкапы, которые никто не проверял, мониторинг, которого нет вовсе. Именно эти компромиссы стоит закрывать в первую очередь, и в статье — порядок, в котором это разумно делать, и от каких трат лучше воздержаться.

Приоритет 1: закрыть критичные дыры в безопасности и надёжности

Первым делом — не покупка мощностей, а закрытие рисков, на которые раньше не хватало ни денег, ни времени. В подавляющем большинстве стартапов на bootstrap-стадии это выглядит примерно одинаково: один сервер тянет на себе базу, приложение и веб-сервер одновременно; бэкапы либо не настроены, либо настроены, но их восстановление ни разу не проверяли; секреты лежат в .env-файле в открытом виде в репозитории; SSH пускает по паролю, потому что «так проще подключаться».

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

После переезда на нормальный VPS или выделенный сервер стоит пройтись по базовому чек-листу, который часто откладывали «на потом»:

• Root-доступ и контроль над окружением — вместо панели shared-хостинга с ограничениями.
• SSH только по ключу, пароль отключён:

# /etc/ssh/sshd_config
PasswordAuthentication no
PermitRootLogin prohibit-password

• Firewall с явным белым списком портов:

ufw default deny incoming
ufw allow 22/tcp
ufw allow 80,443/tcp
ufw enable

• fail2ban на SSH и на публичные формы входа (админка, API).
• Автоматические бэкапы с проверкой восстановления — не просто cron с pg_dump, а регулярный тестовый restore на отдельный инстанс. Если бэкапы никогда не разворачивали — считайте, что бэкапов нет.
• TLS через certbot с автопродлением, а не самоподписанный сертификат, который «когда-нибудь заменим».
• Разделение окружений: прод, staging и (если есть) dev не должны жить на одной машине с одной базой.

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

Приоритет 2: первый администратор или DevOps-инженер в команде

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

Первый найм администратора или DevOps-инженера — логичный шаг сразу после закрытия дыр из первого пункта (а иногда и параллельно с ним — толковый администратор сам быстрее закроет чек-лист выше, чем разработчик, который делает это не в фокусе своей роли). Что именно нужно передать новому человеку в первую очередь и что стоит попридержать у себя, разобрано отдельно в статье первый найм администратора: что отдать, а что нет — там подробно про распределение ответственности на старте.

Коротко: в первые 30–60 дней новому администратору логично передать операционную рутину — бэкапы, мониторинг, управление доступами, деплой-пайплайн, реакцию на инциденты. У фаундеров и техлида остаются архитектурные решения, приоритизация бюджета и то, что напрямую завязано на продуктовую стратегию. Ошибка, которую совершают часто: нанимают администратора и тут же перекладывают на него вообще всё, включая решения, которые требуют знания продукта и бизнеса — в итоге человек тонет в тикетах, а стратегические вопросы инфраструктуры откладываются точно так же, как и раньше.

Приоритет 3: мониторинг и алертинг, на которые раньше не было ресурсов

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

Минимальный практичный стек, который не требует отдельной команды:

• Uptime-проверки извне — не с самого сервера, а с внешней точки, чтобы не пропустить полную недоступность машины (например, связкой на базе Uptime Kuma).
• Системные метрики — CPU, память, диск, сеть — через связку вроде node_exporter + Prometheus + Grafana, если нужна гибкость, или готовый агент, если нужна скорость запуска.
• Алерты в канал, который реально смотрят — Telegram-бот или интеграция с рабочим чатом, а не письмо на общий ящик, которое никто не читает.
• Пороги алертов, настроенные под реальное поведение сервиса, а не «на всякий случай» на 90% — сервис может деградировать и раньше.

Пример базового алерта в Prometheus Alertmanager на нехватку места на диске:

- alert: DiskSpaceLow
  expr: node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"} < 0.15
  for: 10m
  labels:
    severity: warning
  annotations:
    summary: "Диск заполнен более чем на 85%"

Важный нюанс: мониторинг, поднятый наспех «для галочки», часто оказывается бесполезным — алерты либо никто не смотрит, либо их слишком много и команда их игнорирует. Здесь тоже приоритет — не количество метрик, а несколько ключевых индикаторов (доступность, место на диске, нагрузка на базу, ошибки 5xx) с адекватными порогами и понятным адресатом уведомления.

Приоритет 4: снизить bus factor

Bus factor, равный единице — ситуация, когда доступ к домену, хостингу, репозиторию или ключевым сервисам знает и держит один человек — типичное наследие bootstrap-периода: пароли создавались «на бегу» и хранились там, где было удобно в моменте, а не там, где должны храниться по правилам компании. После раунда это одна из самых дешёвых в исправлении и одновременно самых опасных нерешённых проблем: если единственный носитель знаний уходит из компании или недоступен в критический момент, бизнес может встать.

Подробный разбор, с чего начать снижение bus factor, есть в статье bus factor, равный единице: как перестать быть одним. Практический минимум на этом этапе:

• Групповой менеджер паролей (Bitwarden Teams, 1Password Business и подобные) вместо личных заметок и переписок в мессенджере.
• Домен, DNS и хостинг зарегистрированы на аккаунт компании, а не на личную почту сотрудника, который когда-нибудь может уйти.
• Минимум два человека знают полный путь деплоя — от git push до прода, без «спроси у Х, он один умеет».
• Runbook на типовые инциденты — что делать, если упала база, кончилось место на диске, истёк сертификат — оформлен текстом, а не живёт только в голове одного администратора.
• Инфраструктура как код (Ansible, Terraform или хотя бы подробно задокументированные скрипты установки) — вместо конфигурации, которую один человек когда-то настроил руками и не записал, что именно сделал.

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

Частая ошибка: инфраструктура «на вырост» и архитектура «как у больших»

Инвестиционные деньги провоцируют характерную ошибку — тратить не на реальные узкие места, а на то, что выглядит солидно. Типичные проявления: Kubernetes-кластер на десяток нод для сервиса с несколькими сотнями пользователей; микросервисная архитектура, разрезанная на 15 сервисов там, где справился бы один монолит с нормальным деплоем; мультирегиональная инфраструктура «на случай, если завтра выйдем в другую страну»; дорогие managed-сервисы, выбранные не по нагрузке, а потому что «так делают у Google».

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

Практическое правило: сложность инфраструктуры должна догонять реальную нагрузку и реальный размер команды, а не обгонять их на несколько шагов вперёд. Если сомневаетесь, нужен ли выделенный сервер конкретно под вашу задачу — вырос трафик, растёт база, нужна изоляция — почти под любой типовой профиль нагрузки (1С, CRM, аналитика, медиахостинг и другие) на блоге есть отдельные разборы конфигурации и ориентировочной цены, с них проще стартовать, чем с абстрактного «возьмём помощнее».

Как расставить приоритеты: явный список технического долга

Самая практичная вещь, которую можно сделать в первую неделю после раунда — не покупка нового железа, а полтора часа с командой и списком технического долга, который накопился за bootstrap-период. Если такого списка нет — значит, решения о том, куда идут новые деньги, будут приниматься по ощущению «что горит громче всего сейчас», а не по реальному риску.

Простой формат таблицы, который легко завести хоть в Notion, хоть в обычном markdown-файле в репозитории:

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

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