Мой контейнер: облако для технологической компании с запасом для роста

«Мой Контейнер» — технологическая компания, которая управляет контейнерным парком и помогает бизнесу арендовать, покупать, продавать и хранить контейнеры, а также закрывает связанные операционные задачи. Компания работает в 80 странах и даёт доступ более чем к 16 тысячам контейнеров с партнёрской сетью в СНГ и Азии. При этом в команде — меньше 50 человек.

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

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

• Повторяющиеся сбои. На прежней облачной площадке сбои стали регулярными — примерно два продолжительных периода в год. Это мешало и поддерживать текущие сервисы, и публиковать изменения, и планировать рост нагрузки.
• Инфраструктура как ограничение для продукта. Компания разрабатывает собственные сервисы, и каждый следующий шаг упирался в вопрос, «а выдержит ли площадка». Без уверенности в инфраструктуре планы по развитию продуктов приходилось строить с оговорками — и закладывать в них риск, который команда не контролировала.

Формулировка задачи получилась короткой: обеспечить стабильную работу того, что уже есть, и получить инфраструктурную основу, на которой можно расти дальше.

Решение принимал архитектор инфраструктуры вместе с командой разработки. Критерии были такими:

• формализованный SLA — формализованный SLA с документально зафиксированными обязательствами;
• стабильность платформы под реальной, а не тестовой нагрузкой;
• низкие сетевые задержки — критично для части сервисов компании;
• предсказуемая работа ресурсов;
• возможность масштабироваться, не меняя технологическую основу через год.

Сам этап выбора занял немного времени. Команда подала заявку на закрытое тестирование MWS Cloud Platform и сразу начала с практики: разместила первые нагрузки и посмотрела, как платформа ведёт себя в деле. Основной переезд прошёл ещё до публичного запуска платформы.

Внедрение целиком вела внутренняя инфраструктурная команда «Мой Контейнер». Со стороны MWS Cloud Platform, по вопросам, которые возникали в процессе миграции, подключались наши инженеры.

Главным требованием при миграции была непрерывность работы: остановить действующие сервисы на время переезда компания не могла. Поэтому миграцию разбили на этапы и выстроили от наименьшего риска к наибольшему.

Этап 1. Нагрузки без высоких требований к SLA. Внутренние базы знаний, демоверсии сервиса ULEY, лёгкие лендинги. Задача этапа — не столько «перенести», сколько проверить платформу в реальной эксплуатации: как ведут себя ресурсы, что с задержками, как работает поддержка, когда что-то идёт не так.

Этап 2. Критичные бизнес-системы. После того как первый контур отработал, команда поэтапно перенесла остальное: CRM на базе Bitrix, Jira, основной продуктовый стек ULEY, коммерческий проект Charon, телефонию FreePBX и CI/CD-инфраструктуру разработчиков. Всего в облако уехало больше 10 ИТ-систем и сервисов — сейчас они живут на 23 виртуальных машинах.

Пользователи переезда не заметили: действующие системы оставались доступны на всём протяжении миграции.

Архитектура построена на типовых решениях: её сопровождением занимается небольшая инфраструктурная команда, и это учитывали при проектировании. Вычисления для внутренних и внешних систем реализованы на виртуальных машинах в изолированных VPC. Для хранения данных и вспомогательных задач используют объектное хранилище.

• Разделение по облачным проектам. Системы разведены по отдельным проектам, а не сложены в один контур. Это упрощает и управление доступом, и понимание, что где происходит.
• Управляемые сервисы платформы для того, что не стоит держать на виртуалках вручную: доставка контента, сертификаты, образы, секреты.

Часть экосистемных сервисов команда обкатывает в отдельных контурах.

• Контур Charon — это система, которая объединяет мессенджеры и CRM, и она чувствительна к задержкам — тут счёт идёт на миллисекунды. В этом контуре тестируются CDN, Certificate Manager и KMS.
• Artifact Registry — для хранения образов и артефактов сборки рядом с инфраструктурой.
• Secret Manager — чтобы секреты пайплайнов не жили в репозиториях и конфигурационных файлах.
• MWS CLI — команда использует его в собственных скриптах для аудита, масштабирования и процессов непрерывной доставки. Побочный, но приятный эффект: типовая облачная инфраструктура теперь разворачивается по готовому шаблону одним скриптом — примерно за две минуты вместо ручной сборки.

Ушли от периодов нестабильности. Количество крупных периодов нестабильности сократилось с двух в год до нуля. Фактическая доступность инфраструктуры выросла с ~93% примерно на 7 процентных пунктов — это оценка реальной доступности.

Обновления выходят за секунды, а не за минуты. Время выпуска обновления сократилось примерно с 20 минут до 30 секунд. Здесь важна честная оговорка: это результат не только переезда. Параллельно с миграцией команда переработала CI/CD-пайплайны — и сделала это сразу, чтобы не возвращаться к перестройке процесса выпуска отдельно. Облако не ускорило релизы само по себе, но сделало эту работу возможной. Для организации CI/CD-пайплайнов команда применяет Artifact Registry и Secret Manager, а для автоматизации аудита, масштабирования и процессов непрерывной доставки активно использует MWS CLI в собственных скриптах.

Ресурсы разворачиваются быстрее и более предсказуемо. Типовую инфраструктуру можно поднять по шаблону за пару минут.

Оплата только за используемые ресурсы. Ресурсы в проект добавляются по мере развития сервисов, а не закупаются впрок.

Сетевые задержки снизились. По качественной оценке команды — заметно, и это особенно важно для сервисов вроде Charon.

Инфраструктура перестала быть ограничением. Это, пожалуй, главный результат, который сложно уложить в цифру. Команда может масштабировать существующие сервисы и проверять новые архитектурные подходы, не упираясь в вопрос, «а выдержит ли площадка».

Инфраструктура стала дороже. Компания пошла на это осознанно: стабильность, низкие задержки и запас для роста оказались важнее разницы в стоимости. Задачи сэкономить при переезде не стояло — компания решала вопрос надёжности, а не стоимости.

Команда «Мой Контейнер» продолжает масштабировать существующие сервисы и проверять новые архитектурные решения в собственных разработках, выбирая наиболее эффективный способ их реализации в MWS Cloud Platform. Конкретный список следующих сервисов пока не зафиксирован: управляемые сервисы подключают по мере появления задач и подтверждённого практического преимущества.