Legacy и редкий стек: почему принципы важнее утилит

На каждом втором звонке с потенциальным клиентом в 2025–2026 годах звучит одно и то же: «у нас PHP 5.6», или «мы на 1С-Битриксе», или «монолит на Java 8, никто не трогал пять лет». И следом — вопрос, который стал почти ритуальным: «а вы с таким работали?»

Импортозамещение вытащило наружу всё, что годами не трогали. Компании, которые раньше тихо жили на зарубежных SaaS-инструментах, вдруг оказались перед необходимостью переезда на собственную инфраструктуру — со стеком, который никто особенно не развивал.

Наш ответ на вопрос «работали ли» честный: не всегда. Но это не та проблема, которой стоит бояться — и вот почему.

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

Когда мы настраиваем CI/CD, мы не «настраиваем Jenkins для PHP». Мы выстраиваем процесс: код попал в репозиторий — запускается сборка — проходят тесты — артефакт деплоится в окружение — проверяется работоспособность. Этот процесс одинаков независимо от языка.

PHP 5.6, Go, Python 3.12 или Perl — на уровне пайплайна это просто команда сборки в build-шаге. Меняется строка, не архитектура. Мы строили подобные пайплайны ещё в 2014 году — тогда это был Jenkins с Ansible и Serverspec-тестами на инфраструктуру. Инструменты сменились на GitLab и Docker, логика осталась та же.

То же самое с Terraform и IaC: мы описываем ресурсы — ВМ, сети, диски, секреты — декларативно. Нам не важно, что внутри этой виртуальной машины поднимет приложение. Мы начинали с Terraform 0.6 ещё в 2016-м с концептом state-в-git и plan перед apply. С тех пор сменились версии, появились OpenTofu и remote state, но принцип «инфраструктура как код» не изменился — и он применим к любому стеку.

Контейнеризация на Docker работает одинаково: берём приложение, упаковываем в образ, запускаем в Kubernetes. Kubernetes не знает и не заботится о том, что внутри контейнера — PHP 5.6 или свежий Go. Он управляет подами, следит за ресурсами, перезапускает упавшие процессы. Для него всё приложение — процесс, который слушает порт.

Кейс: PHP 5.6 с нормальным пайплайном

Один из клиентов пришёл с eCommerce-монолитом на PHP 5.6. Это был живой production, который обрабатывал заказы, — уходить с него в обозримой перспективе не планировали. Деплой делался вручную по SSH, staging-среды не существовало, один разработчик знал «как правильно».

Мы выстроили стандартный пайплайн в GitLab:

• сборка Docker-образа с PHP 5.6 из официального базового образа (он поддерживается в репозиториях);
• запуск unit-тестов и линтера внутри контейнера;
• автоматический деплой на staging при мёрже в develop, на production — из main после ручного approve;
• smoke-тесты после деплоя: проверяем что ключевые эндпоинты отвечают 200.

Для Kubernetes-кластера описали Helm-чарт, добавили Prometheus и Grafana для мониторинга. Окружения описали в Terraform — виртуалки, DNS, сертификаты. Всё воспроизводимо, всё в репозитории.

Специфика PHP 5.6 проявилась ровно в одном месте: пришлось собрать собственный Docker-образ с несколькими PHP-расширениями, которые в стандартном образе уже убраны. Это заняло пару часов. Остальное — стандартная работа.

Отечественный стек — та же история

Импортозамещение добавило в наш рабочий обиход ОС и инфраструктурное ПО, которое раньше в проектах не встречалось: РЕД ОС, Astra Linux, ALT Linux, Postgres Pro, виртуализация на zVirt.

Принципы те же. Ansible-плейбук для Astra Linux пишется так же, как для Ubuntu — меняется менеджер пакетов (apt в обоих случаях) и имена пакетов. Terraform-провайдер для отечественного облака — другой по синтаксису ресурсов, одинаковый по концепции: описываешь желаемое состояние, получаешь воспроизводимую инфраструктуру.

Специфика отечественного стека часто не в принципах, а в деталях: сертификаты ГОСТ вместо RSA, другой репозиторий пакетов, специфика лицензирования Postgres Pro. Это изучаемо — и ровно здесь мы переходим к честному разговору.

Честный trade-off: ресёрч на незнакомом стеке

Скажем прямо: когда стек нам незнаком, первые часы работы с ним — это ресёрч. Чтение документации, проверка совместимости, тест на тестовом окружении перед тем как двигаться в production.

Как мы с этим поступаем:

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

Называем неопределённость заранее. Если приходит задача со стеком, который мы раньше не эксплуатировали в production, мы говорим об этом на старте. Не «мы с таким не работали, поэтому не возьмём», а «у нас нет готовых решений под этот стек, есть опыт применения принципов к разным стекам и время на ресёрч». Разница принципиальная.

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

Это честнее, чем сказать «да, конечно работали» и обнаружить сюрпризы на третьей неделе.

Что это значит на практике

Когда клиент спрашивает «а вы умеете с нашим стеком», правильный вопрос не «какой стек», а «какую проблему нужно решить».

Если проблема — релизы делаются руками и по ночам — мы знаем, как выстроить процесс. Это не зависит от языка.

Если проблема — инфраструктура настроена вручную и не воспроизводима — мы знаем, как её описать кодом. Terraform и Ansible работают на Astra Linux так же, как на Debian.

Если проблема — нет мониторинга — Prometheus собирает метрики с любого сервиса, который умеет отдавать HTTP или стандартные экспортёры. Языку приложения это безразлично.

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

Принципы остаются, инструменты меняются

Мы занимаемся инженерной практикой с 2000 года. За это время сменилось несколько поколений инструментов — но CI/CD, IaC и контейнеризация как подходы не изменились в своей основе. Автоматизированный пайплайн 2014 года на Jenkins и Serverspec работал по тем же принципам, что GitLab CI 2026 года. Terraform, который мы впервые применили в 2016-м, эволюционировал в OpenTofu — концепция state, plan и apply осталась.

Редкий стек меняет детали, не принципы. Мы автоматизируем процессы, а не конкретные утилиты — и именно поэтому задача «старый PHP» или «Astra Linux» решается теми же методами, что и современный Go-сервис.

Если вам нужно разобраться с инфраструктурой на нестандартном или редком стеке — начните с обследования. За 3–5 дней мы разберём ваш контур, назовём неизвестные и дадим план. Подробнее — на странице DevOps-аутсорсинга. Если в задаче явно стоит импортозамещение стека — это отдельная практика на странице импортозамещения.