Стартап без администратора: минимальная схема, которая доживёт до первого года

MAATRIX

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

Почему обычная DevOps-схема здесь не работает

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

Отсюда следует не «нанять админа как можно раньше» (на ранней стадии это часто не по карману и не по масштабу задачи), а «строить схему, которая прощает отсутствие рефлексов». У такой схемы три свойства:

• Меньше ручных решений в моменте. Если восстановление после сбоя требует пятнадцать нетривиальных шагов подряд, которые надо помнить или гуглить на бегу, — при реальном инциденте под давлением это провалится с высокой вероятностью, независимо от того, насколько толковый разработчик их выполняет.
• Меньше состояния, которое можно потерять безвозвратно. Часть решений (в первую очередь бэкапы) физически нельзя принять «постфактум» — если не настроено заранее, то в момент сбоя уже поздно.
• Меньше зависимости от одного человека и его памяти. Даже если сейчас сервером занимается конкретный Вася, схема должна работать и тогда, когда Вася в отпуске, в другом часовом поясе или уже не в проекте.

Дальше — по каждому пункту с конкретикой, а в конце отдельно про то, где стоит остановиться и не усложнять.

Managed-сервисы там, где это возможно

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

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

Практический список, что стоит рассмотреть как managed в первую очередь:

• База данных (PostgreSQL/MySQL) — самая частая точка отказа у самостоятельно администрируемых баз: забытый бэкап, разросшийся pg_wal, забитый диск от неоткрученного автовакуума.
• Очередь сообщений / кэш (Redis, RabbitMQ) — если это критический компонент, а не временная затычка.
• Объектное хранилище для файлов пользователей — не изобретайте свой велосипед на NFS-шаре, S3-совместимое хранилище стоит недорого и снимает вопрос отказоустойчивости диска.
• TLS-сертификаты — Let's Encrypt с автопродлением через certbot или встроенный механизм панели/прокси закрывает вопрос полностью, вручную заниматься сертификатами в 2026 году уже незачем.
• DNS — держите его у отдельного провайдера с нормальным API и UI, а не поднимайте свой bind9 ради одного домена.

Что оставить себе на VPS без сожалений: сам код приложения, обратный прокси (nginx/Caddy), очевидно простые статические вещи. Здесь managed-обёртка обычно добавляет накладные расходы и слой абстракции без реального снижения риска — вы и так справитесь.

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

Автоматизация рутины вместо разовой экспертизы

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

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

Обновления безопасности. На Ubuntu/Debian включите unattended-upgrades для security-патчей — это несколько минут настройки, которые закрывают самый частый вектор компрометации (непропатченная уязвимость в пакете, который никто не трогал полгода):

sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

Деплой приложения. Даже без CI/CD в полном смысле — один bash-скрипт или Makefile-таргет, который тянет код, накатывает миграции и перезапускает сервис, снимает риск, что кто-то забудет шаг при ручном деплое в панике перед релизом:

#!/usr/bin/env bash
set -euo pipefail
cd /opt/app
git pull origin main
docker compose pull
docker compose up -d --build
docker compose exec app python manage.py migrate

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

Плановый рестарт при утечках памяти. Если у сервиса есть известная утечка, которую пока некогда чинить, — не помните об этом вручную, повесьте systemd-таймер с ночным рестартом, это дешевле, чем разбор инцидента в 3 часа ночи.

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

Бэкапы — то, что нельзя настроить постфактум

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

Минимальная рабочая схема бэкапов для проекта без штатного админа:

1. Автоматический бэкап базы данных ежедневно, с ротацией (хранить последние 7 дней и, например, 4 недельных). Для PostgreSQL — pg_dump в связке с cron или встроенный механизм managed-провайдера, если база managed:

# /etc/cron.d/db-backup
0 3 * * * app pg_dump -Fc mydb > /backups/db_$(date +\%Y\%m\%d).dump

1. Копия вне сервера. Бэкап на том же диске, что и продакшн, — это не бэкап, а иллюзия бэкапа: при отказе диска или компрометации сервера вы теряете и оригинал, и копию одновременно. Выгружайте архив в отдельное хранилище — объектное хранилище другого провайдера или хотя бы другой физический сервер.
2. Проверка восстановления хотя бы раз в квартал. Бэкап, который никогда не разворачивали, с равной вероятностью может быть битым файлом нулевого размера — узнать это стоит не в момент реального сбоя, а заранее, на тестовом окружении.
3. Мониторинг самого факта бэкапа, а не только его наличия в расписании cron — задача может годами стоять в crontab и молча падать с ошибкой, о которой никто не узнает, пока не понадобится восстановление. Про то, как это отследить по exit-коду и размеру файла, а не по факту «письма об ошибке не приходили»: мониторинг бэкапов.

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

Базовый мониторинг с оповещением

Задача мониторинга на этой стадии — не построить дашборд с полусотней метрик, а не узнавать о падении сервиса от пользователей в чате поддержки. Этого достаточно на первый год, и большего пока не нужно.

Минимальный набор, который закрывает основные риски:

Для внешнего пинга и uptime-проверок достаточно лёгкого self-hosted инструмента вроде Uptime Kuma или внешнего сервиса с бесплатным тарифом — поднимать для этого Prometheus с Grafana и Alertmanager на старте избыточно, если некому поддерживать этот стек. Для проверки «дожил ли cron до конца» удобны сервисы вида healthchecks.io — задача сама отчитывается о завершении, и вы узнаёте о пропуске, а не гадаете по логам.

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

Документация-минимум: что где развёрнуто

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

Минимум, который стоит зафиксировать и держать в актуальном состоянии — не в личных заметках, а в месте, доступном всей команде (общий репозиторий, вики, хотя бы закреплённое сообщение в чате):

• Что и где развёрнуто — список серверов, их назначение, IP-адреса, доступ (кто, как, куда обращаться за новым ключом).
• Как перезапустить каждый компонент — конкретные команды, а не «ну там же всё понятно» (то, что понятно автору в моменте, часто непонятно через полгода даже ему самому).
• Где лежат бэкапы и как из них восстановиться — пошагово, проверено на практике, а не в теории.
• Контакты провайдеров и учётные записи — хостинг, DNS, домен, managed-сервисы, у кого доступ к оплате.
• Известные особенности и грабли — «если сервис X не отвечает, сначала проверить Y» экономит часы при инциденте.

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

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

Где остановиться и не переусложнять

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

Ориентиры, где стоит сознательно упроститься:

• Один сервер вместо кластера, пока нагрузка это позволяет. Отказоустойчивость на два-три сервера с балансировщиком добавляет на порядок больше движущихся частей, чем даёт реальной пользы при вашем текущем трафике.
• Docker Compose вместо Kubernetes. Оркестрация контейнеров нужна, когда сервисов десятки и они масштабируются независимо. Для двух-пяти сервисов Compose закрывает всё то же самое без отдельной экспертизы в кластерах.
• Один вариант окружения вместо dev/staging/prod с полной симметрией. Тестовое окружение полезно, но не обязано быть зеркальной копией продакшна по инфраструктуре — обычно хватает отдельной базы и отдельного домена на том же сервере.
• Готовые панели управления вместо ручной настройки с нуля, если разработчику комфортнее в UI, чем в конфиге nginx построчно — это не признак некомпетентности, а рациональный выбор для человека, у которого администрирование не основная роль.

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

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