Все цитируют «лучшие практики». Все на них ссылаются. Но я заметила странную штуку: чем громче кто-то произносит «best practices», тем меньше он задумывается о том, а надо ли это конкретно ему.

Концепция пришла из мира корпораций и больших команд. Amazon, Google, Netflix — все они написали свои инженерные блоги, где описали, как они деплоят код. Эти документы стали священными текстами. GitOps! Непрерывный деплой! Инфраструктура как код!

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

Что «должно быть» против того, что реально работает

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

GitOps для одного репозитория? Звучит солидно. Но если ты один и деплоишь раз в неделю, то автоматизация по merge в main — это три дня настройки ради экономии одной команды.

Непрерывный деплой как в Google? Прекрасно. Но сначала ответь: у тебя есть QA-команда, которая покрывает 90% кода тестами? Если нет — непрерывный деплой это непрерывный хаос.

Цена слепого следования

Избыточная сложность. Ты тратишь время на конфигурацию, которая не решает ни одной твоей проблемы. Мой сайт работал на простом Node.js-сервере месяцами, пока я не «внедрила лучшие практики» — и сразу получила проблемы с конфигурацией, которых не было раньше.

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

Блокировка на пустом месте. Kubernetes привязывает тебя к конкретной облачной платформе и конкретному набору инструментов. Для маленького проекта это как купить грузовик для поездки в магазин за хлебом.

Когда это действительно нужно

Лучшие практики важны — для масштаба. Они решают реальные проблемы:

  • Kubernetes — когда у тебя больше одного разработчика и нужна изоляция сервисов
  • Terraform — когда инфраструктура сложная и её нужно воспроизводить
  • CI/CD с автотестами — когда изменения вносятся часто и их нужно проверять быстро

Но они не универсальны. Для одного сервера с одним приложением CI/CD из одной строчки в crontab работает лучше, чем GitHub Actions с пятью джобами.

Как думать об этом

Вместо вопроса «соответствую ли я лучшим практикам?» спроси себя:

  • Какую проблему это решит?
  • Сколько времени это займёт?
  • Что будет, если это сломается в три часа ночи?

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

Best practices важны. Но сначала — задай правильный вопрос: «это подходит для моего случая?»