Production-контур для крупного федерального ритейла
В течение 10 лет Progressive OS обеспечивала работу production-инфраструктурной среды для продуктовых команд METRO Cash & Carry. Это была не лабораторная площадка и не вспомогательный dev-контур, а реальная рабочая среда, на которой держались критичные для бизнеса сервисы, включая федеральный каталог.
Ключевая особенность проекта состояла в том, что инфраструктура должна была оставаться стабильной в условиях постоянной работы бизнеса, разнородных требований со стороны команд и ограниченного окна для серьёзных изменений. В такой модели цена ошибки определяется не только временем простоя, но и тем, насколько управляемой остаётся вся система в долгом горизонте.
Около 200 Linux-серверов под управлением небольшой команды
На пике в контуре находилось порядка 200 Linux-серверов. Физическая база была компактной, основная часть среды работала на KVM-виртуализации. При этом весь этот парк в боевом режиме удерживался командой из трёх инженеров.
Для такой конфигурации недостаточно просто “уметь администрировать Linux”. Нужна среда, в которой каждое решение подчинено управляемости: как выделяются ресурсы, как создаются новые машины, как контролируются диски, как отслеживается деградация производительности, как выполняются резервные копии, как проходит обновление, как локализуется проблема и как не допустить повторения той же ситуации в следующем цикле.
Проект опирался именно на такую модель. Не на героизм в авариях, а на заранее выстроенный порядок, который позволяет держать большой контур без расползания хаоса.
Чёткая граница между инфраструктурой и приложением
Одна из самых сильных сторон этого проекта — не отдельная технология, а правильно проведённая граница ответственности.
Progressive OS отвечала за инфраструктурную среду: серверы, виртуализацию, доступ, базы данных, веб-серверы, резервное копирование, мониторинг и защитный контур. Команды разработки отвечали за собственные приложения и свою прикладную логику. Это разграничение не мешало работе, а, наоборот, делало её предсказуемой: было понятно, где заканчивается зона платформы и где начинается зона продукта.
На практике именно такой подход позволял быстро разбирать любые вопросы — от производительности до проверок безопасности — без споров, догадок и перекладывания ответственности. Для production-среды, в которой одновременно работают около десяти продуктовых команд, это принципиально важно.
Почему была выбрана модель KVM, а не контейнерная абстракция
Для этого контура была осознанно выбрана модель с KVM-виртуализацией и нативной эксплуатацией сервисов. Причина была не в отрицании контейнеров как класса, а в требованиях к прозрачности управления.
Разработчику удобно собирать приложение в изолированной логике под себя. Но в production у инфраструктуры другая задача: быстро видеть, где именно заканчиваются ресурсы, где не хватает ядер, где узкое место в воркерах, где неправильно распределена память, где упирается диск, где приложение требует перенастройки окружения. Когда всё это закрыто дополнительной прослойкой, управляемость снижается: диагностика становится длиннее, вмешательство — сложнее, а часть критичных параметров оказывается спрятана внутри чужой логики сборки и публикации.
В выбранной архитектуре разработчик оставался в своём контуре приложения, а инфраструктура — в своём. Это позволяло управлять production-средой напрямую: добавлять ресурсы, корректировать системные параметры, донастраивать конфигурации, не таща за собой лишнюю абстракцию и не превращая каждое изменение в отдельный проект по разбору контейнерной упаковки. Для long-run эксплуатации это дало более предсказуемый результат.
Управляемость вместо “ручного искусства”
По мере роста контура проект нельзя было удерживать за счёт памяти инженера или набора случайных удачных решений. Нужна была система. Она была выстроена через стандартизацию среды, собственные регламенты взаимодействия с командами, готовые паттерны конфигураций, единые правила доступа, шаблоны резервного копирования и понятную модель мониторинга.
Именно это позволило постепенно нарастить контур от относительно небольшого числа серверов до полноценной production-инфраструктуры федерального масштаба, не превращая её в набор исключений. Новая машина не должна была быть “особенным случаем”. Новое требование не должно было ломать логику всей среды. Любое изменение должно было встраиваться в существующий порядок, а не порождать новый хаос.
Такая дисциплина редко бросается в глаза снаружи, но именно она делает возможной эксплуатацию крупной инфраструктуры малой командой.
Работа в условиях узкого окна изменений
Серьёзные изменения проводились в строго ограниченное ночное окно, выбранное по статистике нагрузки. Это задавало особый режим эксплуатации: на исправление, перенос, перенастройку и ввод изменений было мало времени, а цена ошибки оставалась высокой.
В таких условиях инфраструктура должна быть не просто “достаточно хорошей”, а заранее подготовленной к обслуживанию. Это означает, что инженер работает не только с текущей задачей, но и с последствиями наперёд: как поведёт себя система при следующем пике, какой запас по ресурсам нужен, где есть скрытое накопление технического долга, что произойдёт после очередного релиза, где проблема проявится первой.
Именно здесь проявлялась не показная сложность, а зрелость контура: production не требовал постоянного присутствия в аварийном режиме, потому что основная работа была сделана на уровне архитектуры, регламентов и предугадывания узких мест.
Безопасность как свойство правильно устроенной среды
В проекте не было попытки заменить системную работу красивой “секьюрити-легендой”. Защищённость среды обеспечивалась тем, как вообще был устроен доступ и как принимались инфраструктурные решения.
Доступ в контур был ограничен и управляем. Продуктовые команды получали ровно те возможности, которые нужны для работы, но не административную власть над средой. Критичные права не расползались по контуру. Любое вмешательство в инфраструктуру оставалось в зоне ответственности тех, кто за неё отвечал.
Такой подход регулярно проходил внешние проверки и, что важнее, выдержал десятилетний горизонт эксплуатации. За весь период не было подтверждённых инцидентов компрометации инфраструктуры. Для production-среды такого масштаба это не декларация, а результат правильно выстроенного управления.
Что означала стабильность на практике
О качестве инфраструктуры лучше всего говорит не количество героических историй, а их отсутствие. В этом проекте нормой была не постоянная аварийность, а длительные периоды, когда системы просто работали и не требовали лишнего внимания со стороны бизнеса и продуктовых команд.
Это и есть один из главных результатов: production-контур не жил от кризиса к кризису. Он оставался предсказуемым, контролируемым и устойчивым, несмотря на рост, гетерогенность сервисов, высокую нагрузку и длительный срок эксплуатации.
Нам удалось выстроить и много лет удерживать production-инфраструктуру федерального уровня там, где от платформы требуется сразу несколько вещей: стабильность, ясная граница ответственности, контролируемая безопасность, экономное использование ресурсов и возможность держать большой парк серверов малой инженерной командой без потери качества управления.