Legacy — тема, о которой знают все, но которую по-прежнему редко обсуждают публично. Хотя именно в 2025 году она стала особенно заметной: старые системы не просто продолжают жить, они формируют основу огромного количества реальных проектов.
И если попытаться честно взглянуть на картину — станет понятно, что DevOps никогда не был только про Docker и Kubernetes. Он про культуру, инженерное мышление и про умение работать с тем, что есть. А есть у большинства — всё тот же Legacy.
DevOps: шире, чем модный стек
В индустрии по инерции живёт ощущение, что современный DevOps — это: Docker, Kubernetes, Helm-чарты, GitOps, операторы, Istio — «чтобы было как у больших».
Но DevOps — не набор технологий. Это жизненный цикл, ответственность и отказ от самообмана. А главный самообман — утверждать, что «у всех давно микросервисы и кластер k8s».
Реальность куда прозаичнее.
Реальный 2025 год: один сервер на всё
Большая часть клиентов, приходящих за помощью, работают примерно так: один выделенный сервер, на нём в обнимку: приложение (часто на PHP), MySQL/PostgreSQL, Redis, очереди, Nginx, cron-скрипты, иногда поверх — MinIO, SMTP, что-то тестовое.
Бэкапы? «Ну, что-то делается».
Мониторинг? «SSH отвечает — значит всё работает».
Конфигурации? «А что это?».
И речь идёт не о студенческих пет-проектах, а о компаниях с реальными пользователями.
Где начинается боль
Обычно DevOps-сервис вызывают тогда, когда: база падает под нагрузкой, Redis переполняется, cron-ы конфликтуют, бэкапы забивают диск, сервер рушится — и останавливается бизнес, а админ, который всё собирал, давно уволился.
И возникает главный вопрос: «Что теперь делать? И можно ли не разнести всё к чёрту?». Ответ: можно. Но эволюционно, а не революционно, без резких движений. Самая частая ошибка — пытаться «переехать в Kubernetes сразу». Kubernetes — это финиш, а не старт.
Наш подход обычно выглядит так.
1. Аудит: честная археология
Сначала мы разбираемся: что работает, как работает, почему оно до сих пор работает, и что случится, если перестанет. На этом этапе встречаются сюрпризы вида: «Этот сервис нельзя выключать — мы не знаем, что он делает, но без него всё падает».
2. Разделение сервисов
Дальше начинается инженерия: база — на отдельный узел, кэш — отдельно, балансировщик и приложение — на разные машины, репликация, failover, нормальные бэкапы, отказоустойчивость. Система становится предсказуемой. Появляется пространство для манёвра.
3. Автоматизация и контроль
Когда хаос локализован — включаем инструменты: CI/CD, IaC, мониторинг на Prometheus + Grafana, алерты, централизованное логирование, SLO/SLA. Инфраструктура переходит в инженерную плоскость.
4. Масштабируемая архитектура
И только теперь звучит честный вопрос: «Нужен ли Kubernetes?».
Мы анализируем: нагрузку, скорость релизов, наличие микросервисов, требования к HA, компетенции, бюджет. Иногда Kubernetes действительно нужен. Иногда — избыточен. Иногда — стоит вернуться через год. Kubernetes — не трофей. Это инструмент, который требует зрелости.
Главное: Legacy — это не стыдно
Стыдно — когда никто его не понимает, не документирует и не контролирует.
DevOps в 2025 году — это: трезвая оценка архитектуры, осознанная миграция, системное мышление, выбор подходящих инструментов.
Мы не переписываем инфраструктуру ради Kubernetes. Мы делаем так, чтобы бизнес работал и рос. И именно это сегодня — реальный DevOps.
И если попытаться честно взглянуть на картину — станет понятно, что DevOps никогда не был только про Docker и Kubernetes. Он про культуру, инженерное мышление и про умение работать с тем, что есть. А есть у большинства — всё тот же Legacy.
DevOps: шире, чем модный стек
В индустрии по инерции живёт ощущение, что современный DevOps — это: Docker, Kubernetes, Helm-чарты, GitOps, операторы, Istio — «чтобы было как у больших».
Но DevOps — не набор технологий. Это жизненный цикл, ответственность и отказ от самообмана. А главный самообман — утверждать, что «у всех давно микросервисы и кластер k8s».
Реальность куда прозаичнее.
Реальный 2025 год: один сервер на всё
Большая часть клиентов, приходящих за помощью, работают примерно так: один выделенный сервер, на нём в обнимку: приложение (часто на PHP), MySQL/PostgreSQL, Redis, очереди, Nginx, cron-скрипты, иногда поверх — MinIO, SMTP, что-то тестовое.
Бэкапы? «Ну, что-то делается».
Мониторинг? «SSH отвечает — значит всё работает».
Конфигурации? «А что это?».
И речь идёт не о студенческих пет-проектах, а о компаниях с реальными пользователями.
Где начинается боль
Обычно DevOps-сервис вызывают тогда, когда: база падает под нагрузкой, Redis переполняется, cron-ы конфликтуют, бэкапы забивают диск, сервер рушится — и останавливается бизнес, а админ, который всё собирал, давно уволился.
И возникает главный вопрос: «Что теперь делать? И можно ли не разнести всё к чёрту?». Ответ: можно. Но эволюционно, а не революционно, без резких движений. Самая частая ошибка — пытаться «переехать в Kubernetes сразу». Kubernetes — это финиш, а не старт.
Наш подход обычно выглядит так.
1. Аудит: честная археология
Сначала мы разбираемся: что работает, как работает, почему оно до сих пор работает, и что случится, если перестанет. На этом этапе встречаются сюрпризы вида: «Этот сервис нельзя выключать — мы не знаем, что он делает, но без него всё падает».
2. Разделение сервисов
Дальше начинается инженерия: база — на отдельный узел, кэш — отдельно, балансировщик и приложение — на разные машины, репликация, failover, нормальные бэкапы, отказоустойчивость. Система становится предсказуемой. Появляется пространство для манёвра.
3. Автоматизация и контроль
Когда хаос локализован — включаем инструменты: CI/CD, IaC, мониторинг на Prometheus + Grafana, алерты, централизованное логирование, SLO/SLA. Инфраструктура переходит в инженерную плоскость.
4. Масштабируемая архитектура
И только теперь звучит честный вопрос: «Нужен ли Kubernetes?».
Мы анализируем: нагрузку, скорость релизов, наличие микросервисов, требования к HA, компетенции, бюджет. Иногда Kubernetes действительно нужен. Иногда — избыточен. Иногда — стоит вернуться через год. Kubernetes — не трофей. Это инструмент, который требует зрелости.
Главное: Legacy — это не стыдно
Стыдно — когда никто его не понимает, не документирует и не контролирует.
DevOps в 2025 году — это: трезвая оценка архитектуры, осознанная миграция, системное мышление, выбор подходящих инструментов.
Мы не переписываем инфраструктуру ради Kubernetes. Мы делаем так, чтобы бизнес работал и рос. И именно это сегодня — реальный DevOps.
