Каждый, кто хоть раз участвовал в крупном проекте автоматизации, знает это странное чувство — вроде всё делали по плану, а на выходе получается громоздкий, неуправляемый монстр. Почему современные ERP и CRM-системы часто не доживают до реального запуска в актуальном виде? Разберём, как инфраструктура стареет быстрее проекта, какие признаки указывают на надвигающуюся катастрофу, и что можно сделать, чтобы не повторять чужие ошибки.

Вы когда-нибудь участвовали в проекте, который длился так долго, что к моменту запуска половина технологий уже устарела? Когда дата-центры, арендованные под пилот, уже не поддерживают нужные версии PostgreSQL, а CI-конвейер запускается только «через раз»?
Я участвовал. И не один раз.

Парадокс крупных ERP/CRM-внедрений в том, что они задумываются как решение на годы вперёд, но строятся на инфраструктуре, которая морально стареет уже через полгода после старта. Средний жизненный цикл таких проектов — 18–24 месяца, и за это время меняется всё: требования бизнеса, облачные API, политика лицензирования, структура команд. А проект продолжает жить в своём параллельном мире, где Ansible ещё «актуален», а Jenkins всё ещё «встроен надёжно».

Архитектура на песке

Главная ошибка — считать инфраструктуру статичной. При проектировании ERP или CRM-решений часто строят «идеальную» схему: балансировщики, базы, кэши, микросервисы, CI/CD, monitoring stack. Но всё это существует в контексте: технологии обновляются, зависимости уходят в депрекейт, появляются новые требования безопасности.

Типичный сценарий выглядит так:

1. Команда выбирает стек — скажем, Java 17, Spring Boot, PostgreSQL 14, Kubernetes 1.21.

2. Проходит полтора года разработки.

3. Kubernetes 1.21 уже EOL, PostgreSQL 16 требует миграции схемы, а Java-библиотеки имеют критичные CVE.

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

Вот пример минимального пайплайна на Python для проверки актуальности зависимостей — простая, но забываемая практика:

# check_versions.py
import subprocess
import json

def get_version(pkg):
    try:
        result = subprocess.run(["pip", "show", pkg], capture_output=True, text=True)
        for line in result.stdout.splitlines():
            if line.startswith("Version:"):
                return line.split(":")[1].strip()
    except Exception:
        return None

packages = ["fastapi", "sqlalchemy", "pydantic"]
versions = {pkg: get_version(pkg) for pkg in packages}

print(json.dumps(versions, indent=2))

Да, это примитив, но сколько команд проверяют свои продакшн-зависимости хотя бы раз в квартал?

Когда инфраструктура опережает бизнес

Одна из самых забавных, но типичных ситуаций — когда инфраструктура становится «лучше», чем бизнес-логика.
Я видел, как в проекте ERP-системы внедрили трёхуровневую Kubernetes-архитектуру, Canary-деплой и ArgoCD, но сами модули продаж всё ещё передавали данные через FTP.
Инфраструктура жила по DevOps-правилам, а бизнес — в прошлом веке.

Корень проблемы в том, что техническая команда часто оптимизирует то, что ей ближе. Бизнес-часть в это время тонет в согласованиях и регламентных изменениях. В итоге запускается идеальный CI/CD-контур для неподготовленного продукта.

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

Когда технологии «гниют» незаметно

Есть незаметные факторы, которые убивают ERP-проект задолго до запуска. Один из них — технический долг, спрятанный в слое инфраструктуры.
Пример: в проекте внедряли централизованный логинг на базе Elasticsearch 7. К моменту финального тестирования вышла 8-я версия, несовместимая по API. В логах начали появляться ошибки, но никто не рискнул обновлять: «всё же работает». Через три месяца API окончательно изменился, и мониторинг перестал реагировать на критичные события.

Проблема не в том, что Elastic обновился. Проблема в том, что инфраструктура была изолирована от кода.

Лучший способ избежать подобного — использовать Infrastructure as Code не только как DevOps-мантру, а как живой документ. Код инфраструктуры должен меняться вместе с кодом приложения.

Пример простого Terraform-фрагмента, где версия модуля явно фиксируется:

module "network" {
  source  = "git::https://github.com/company/terraform-network.git?ref=v2.3.1"
  region  = "eu-central-1"
  subnets = ["10.0.1.0/24", "10.0.2.0/24"]
}

Если у вас нет версии в ref, готовьтесь к сюрпризам.

Что делать, чтобы проект не устарел

Пожалуй, главный вывод — перестать думать о проекте как о статичном артефакте. ERP или CRM-внедрение — это живой организм. Он стареет, если не получает обновлений.

Несколько практических приёмов:

• Внедрите ротацию инфраструктурных технологий: пересматривайте версии, модули и библиотеки каждые 6 месяцев.

• Разделите бюджеты на разработку и на эволюцию инфраструктуры — это разные задачи.

• Проводите «архитектурные аудиты» перед каждым крупным релизом.

• Создайте инженерную культуру, где деплой не является финальной целью, а просто состоянием системы на сегодня.

И самое важное — задавайте себе неприятные вопросы: что в нашей инфраструктуре уже устарело? Где мы зависим от неподдерживаемых библиотек?

Заключение

Большинство ERP/CRM-проектов погибают не из-за плохих программистов, а из-за инерции. Команды боятся признать, что архитектура устарела раньше, чем код стал готов. Но признание проблемы — это и есть начало зрелости.

Автоматизация ради стабильности возможна только тогда, когда мы принимаем изменчивость как норму. И, возможно, через пару лет ваши CI-скрипты будут уже другими, но система — жива. А ведь это главное.