DevOps для небольшой команды: без Kubernetes и лишней сложности

§ 01Почему Kubernetes обычно перебор

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

Для команды из 3 человек с одним приложением на 100 тысяч пользователей в месяц эти проблемы не существуют. А сложность, которую k8s добавляет, никуда не девается.

Что на самом деле стоит Kubernetes

Минимальный рабочий кластер — это 3 master-ноды и 2–3 worker-ноды. Даже в управляемом решении (Yandex Managed Kubernetes, DigitalOcean Kubernetes) это 8–15 тысяч рублей в месяц только за ноды. Плюс storage, load balancer, мониторинг.

То же самое приложение на одном VPS за 1000 рублей работает без разницы для конечного пользователя. Разница — 10-кратная стоимость за опции, которыми вы не пользуетесь.

Скрытая стоимость — время команды

Kubernetes — это отдельная профессия. Helm charts, ingress controllers, service mesh, CRD, ресурсные лимиты, RBAC, secrets management. Чтобы рабоче-боеспособно поддерживать кластер, нужно либо нанимать отдельного DevOps, либо тратить 20–30% времени разработчика на эти темы.

Для стартапа из 3 человек это 20–30% всего ресурса компании. Тот же ресурс можно потратить на разработку новых функций, которые принесут реальных пользователей и деньги.

Отладка в k8s в 5 раз сложнее

В простой инфраструктуре «контейнер на одном сервере» отладка — это ssh, docker logs, перезапуск. В k8s — это kubectl get pods, kubectl describe, kubectl logs с правильным namespace, pod name и container name, проверка init containers, readiness probes, network policies, service routing. Каждый шаг добавляет место, где может быть проблема.

Для простого приложения это всё не требуется. Но если вы выбрали k8s, вы обречены с этим жить.

«Переедем через год на k8s» — и не переезжают

Мы слышим это часто: «сейчас маленькие, сделаем простое, потом переедем». На практике, если приложение контейнеризировано (Dockerfile, docker-compose), миграция на k8s занимает 1–3 недели. Это легко сделать, когда реально понадобится. А понадобится в 90% случаев никогда — бизнес вырастет или нет задолго до того, как k8s станет необходимым.

Рекомендую начинать просто. Про то, как именно мы настраиваю инфраструктуру, — на странице услуги DevOps.

§ 02Минимум, который реально нужен

Что обязательно должно быть в любой инфраструктуре, даже санаш маленькой. Без этого — не devops, а самодеятельность.

Docker или эквивалент

Приложение должно запускаться одной командой в любом окружении. Dockerfile с описанием зависимостей, docker-compose.yml с связкой сервисов (app, база, кэш). Это основа. Без контейнеризации вы привязаны к конкретной версии ОС, PHP или Node на конкретном сервере.

CI/CD

Автоматическая сборка и деплой по пушу в определённую ветку. GitHub Actions, GitLab CI, или своя установка Jenkins / Drone — любой вариант работает. Главное — ручных шагов при деплое нет. Ни одного.

Типичный флоу: пуш в main → прогоняются тесты → собирается Docker-образ → пушится в registry → SSH на сервер, pull нового образа, рестарт через docker-compose. 3–5 минут от пуша до прода.

Мониторинг ошибок

Sentry, Rollbar, GlitchTip (open-source альтернатива). Приложение шлёт все исключения в систему, вы получаете алерты в Telegram-канал команды. Критично: без этого вы узнаёте об ошибках от клиентов, через сутки после того, как они всё уже потеряли.

Мониторинг uptime

UptimeRobot, BetterStack, Pingdom — внешний сервис, который каждую минуту проверяет, что ваш сайт отвечает. Если не отвечает — алерт. Бесплатные тарифы покрывают основной сценарий.

Логи

Как минимум логи приложения собираются в одно место и доступны для поиска. Простой вариант — docker logs + grep на сервере. Продвинутее — отправка в Loki / Grafana или Yandex Cloud Logging. Не обязательно ELK-стек с Kibana, но искать по логам прошлой недели должно быть можно.

Бэкапы с проверкой восстановимости

Автоматические бэкапы базы данных — раз в сутки как минимум, в отдельное место (S3 / облачное хранилище, не тот же сервер). Раз в месяц — тест восстановления из бэкапа в dev-окружение. «Мы делаем бэкапы» и «мы умеем восстанавливаться» — две разные вещи. Проверяйте обе.

Secrets management

Пароли от БД, API-ключи, токены — не в коде, не в Docker-образе, не в git. В переменных окружения, загружаемых из .env или секретов хостинга (GitHub Actions Secrets, Yandex Cloud Secret Manager). Всегда.

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

§ 03Hetzner vs Yandex Cloud vs Selectel

Три основных варианта хостинга для российских проектов. У каждого своя ниша.

Hetzner

Немецкий хостер, известный лучшей ценой среди европейских. VPS CX11 (2 vCPU, 2GB RAM, 40GB SSD) — 4.5 евро в месяц. Выделенные серверы (dedicated) — от 30 евро. Отличная сеть, хорошая поддержка на английском и немецком.

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

Минусы: данные в Европе — не подходит для 152-ФЗ, если обрабатываются ПДн российских граждан без дополнительных условий. Оплата иногда усложняется для российских клиентов.

Yandex Cloud

Managed-решения: Postgres, Redis, Kafka, хранилище, CDN. Можно использовать отдельные сервисы без админки серверов. Данные в РФ, соответствие 152-ФЗ, подходит для государственных контрактов.

Когда работает: проекты с серьёзными требованиями к комплаенсу, финтех, медицина, госсектор. Когда нужны managed-базы без необходимости самому поддерживать Postgres.

Минусы: дороже Hetzner в 2–3 раза за то же железо. Vendor lock-in — если привыкли к Managed Postgres, переезд к конкуренту нетривиален.

Selectel

Российский хостер с широким спектром услуг: VPS, dedicated, managed-базы, облако. По цене ближе к Yandex Cloud, по гибкости — ближе к Hetzner. Российские датацентры, соответствие локальным требованиям.

Когда работает: средний бизнес в России, которому нужна оптимальная связка «ПДн в РФ + разумная цена». Много вариантов: от VPS за 200 рублей до выделенных серверов с GPU.

Минусы: поддержка иногда медленнее, чем у крупных провайдеров. Сеть чуть хуже, чем у Hetzner в Европе.

Моя обычная рекомендация

Для международных проектов — Hetzner. Для российских с ПДн — Selectel (баланс цены и комплаенса). Для проектов с серьёзным уклоном в Managed-сервисы и корп-клиентов — Yandex Cloud. Для сайтов без серверной части — Cloudflare Pages или Vercel (бесплатно на старте).

Никогда не берём: Heroku (дорого), GoDaddy (ужасный саппорт), голый FTP-хостинг «как у прошлых подрядчиков» (безопасность).

§ 04Бэкапы, которые работают

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

Что бэкапим

1. База данных. Минимум раз в сутки, полный дамп через pg_dump или mysqldump. Хранение — 30 дней минимум. Критично для любого приложения.
2. Пользовательские файлы. Если у вас файлохранилище на сервере (фотографии, документы клиентов) — синхронизация в S3-совместимое хранилище через rclone.
3. Конфигурация. Nginx-конфиги, переменные окружения (без секретов), Docker Compose файлы. Обычно хранятся в git, но не забудьте.
4. Логи. Только критичные, за последние 30 дней. Остальное архивируется или удаляется.

Куда хранить

Не на тот же сервер. Хостер падает — теряете и прод, и бэкап одновременно. Варианты:

• S3 от Yandex Object Storage, Backblaze B2, Wasabi. Дёшево (от 200 рублей в месяц), надёжно.
• Отдельный VPS у другого провайдера для бэкапов.
• Для совсем параноиков — дополнительно ежемесячно на офлайн-носитель (внешний жёсткий диск).

Тестирование восстановления

Раз в месяц обязательно: берёте последний бэкап, разворачиваете на dev-сервере, проверяете что приложение запускается и данные на месте. Если тест провалился — чините бэкапы до следующего месяца. Это занимает 30 минут раз в месяц. Это не лишнее.

3-2-1 правило

Классика ИБ: 3 копии данных, на 2 разных носителях, 1 из которых off-site. Для большинства бизнесов это избыточно, но для критичной информации (финансы, медицина, интеллектуальная собственность) — оправдано.

Подробнее о миграции на современный стек и как не потерять данные при переезде — в статье миграция с Bitrix и WordPress.

§ 05Когда пора переезжать на k8s

k8s действительно нужен в определённых ситуациях. Их немного, но они бывают.

Десятки независимых сервисов

У вас микросервисная архитектура (настоящая, не «мы так назвали две связанные службы»). 15+ сервисов, каждый со своей кодовой базой и командой. Сложность ручного управления зашкаливает — тут k8s правда экономит время.

Автоматическое масштабирование критично

Нагрузка меняется в десятки раз в течение суток. Ночью приложению нужно 2 ноды, днём — 20. Вручную скейлить невозможно, статический пул избыточен. Horizontal Pod Autoscaler в k8s решает это за минуты.

Но! Если нагрузка предсказуема и растёт линейно — вам не нужен автоскейлинг в реальном времени. Докупили ноды раз в квартал — и живёте.

Несколько окружений с точным воспроизведением

Dev, staging, prod, production-EU, production-US с одинаковой конфигурацией. k8s обеспечивает, что во всех пяти окружениях приложение работает одинаково. Без k8s вы ловите расхождения по мелочам годами.

Команда, которая умеет k8s

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

Корпоративный контекст

Если вы работаете с крупными клиентами, у которых требование «деплой в k8s» — тогда приходится. Это не техническая необходимость, а клиентское требование, которое надо выполнить.

Признаки, что «пора»

Мы советуем переезд на k8s, когда одновременно:

• У вас 10+ сервисов, которые связаны между собой сложными зависимостями.
• В команде есть человек, который разбирается в k8s (свой или на ретейнере).
• Ручной деплой занимает больше 30 минут или требует согласования нескольких человек.
• Пиковая нагрузка отличается от минимальной в 5+ раз.

Если выполняются меньше 3 из 4 — ждёте. Если все 4 — переезжаете.

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

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

Типичные вопросы про инфраструктуру для небольшой команды.