О компании

Renault Россия — один из мировых лидеров в области цифровых технологий в автомобильной сфере. Компания имеет опыт внедрения информационных решений в РФ, СНГ, а также на территории стран Латинской Америки, Юго-Восточной Азии и Северной Африки, создает инновационные информационные продукты для других заводов Renault Group и сторонних предприятий автопрома.

Задача компании

Renault Россия работает в формате небольших и средних проектов, поэтому исторически внутри компании есть много команд разработки и стеков технологий. В течение многих лет приложения и сервисы разворачиваются в нескольких разных хостингах.

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

Поэтому перед IT-командой Renault Россия встала задача стандартизировать подходы к разработке и администрированию, а также научиться повторно использовать уже разработанные решения для ускорения бизнес-процессов.

Первый этап. Перенос приложений «как есть»

IT-команда Renault Россия решила убедиться, что Yandex.Cloud подходит для развертывания IT-приложений компании. Поэтому первым шагом стал перенос текущих приложений и сервисов «как есть» с использованием виртуальных машин в сервисе Yandex Compute Cloud. За два месяца специалисты Renault Россия получили среду для разработки, тестирования и продуктивную среду. В новой инфраструктуре инкапсуляция окружений осуществлялась с использованием нескольких сетей и межсетевых экранов, что позволило IT-команде просто и понятно управлять инфраструктурой в облаке по уже привычным правилам.

В результате был получен ответ на главный вопрос о запуске старого workflow в Yandex.Cloud. Самым главным достоинством стала возможность консолидации всех ресурсов в одном месте. Однако скорость и сложность конфигурирования и разработки остались прежними, а для управления средой использовался ручной подход. Любое изменение в количестве виртуальных машин, их конфигурации, переконфигурации правил на межсетевых экранах и другие настройки требовали ручного администрирования через GUI Yandex.Cloud и других инструментов. Это влекло за собой трудозатраты, сопоставимые с работой в старой инфраструктуре.

Первый этап открыл много новых возможностей для улучшения инфраструктуры.

Второй этап. Одной консолидации недостаточно

В результате было принято решение двигаться дальше в облака, но для этого было необходимо вернуться к изучению стека технологий и подготовке новых требований.

Используемый стек:

  • Linux- и Windows-приложения.
  • Обширный список языков разработки.
  • Разные фреймворки и библиотеки.
  • Несколько типов баз данных.

Также был опыт запуска приложений поверх виртуальных машин с использованием различных средств автоматизации, таких как Ansible, Docker Compose, Docker Swarm и даже кластер Nomad.

При этом были выявлены следующие проблемы:

  • Отсутствие стандартов управления жизненным циклом приложений.
  • Большие вложения в администрирование баз данных.
  • Разные способы журналирования.
  • Сложность отслеживания изменений.

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

  • Infrastructure as a code — для максимального упрощения администрирования инфраструктуры и хранения истории.
  • Immutable-подход — для создания более стабильных приложений, менее зависимых от окружения.
  • Kubernetes® — как единая, стандартизованная среда для управления сервисами, запущенными в Docker.
  • Управляемые базы данных — для уменьшения времени на обслуживание баз данных.
  • GitLab CI — для стандартизации методов непрерывной поставки, контроля качества и развертывания приложений.

Были добавлены требования:

  • Централизованное логирование всех событий, хранение истории логов приложений длительное время.
  • Наличие proxy-сервиса:
  • Для возможности полностью или частично ограничивать сервису доступ в интернет или к другим сервисам.
  • Для логирования всех запросов к внешним ресурсам.
  • Полное разграничение сред dev, stage и prod.
  • Web Application FW для контроля запросов из интернета к нашим сервисам.
  • Использование VPN для изоляции приложений на стадии разработки и тестирования.

Третий этап. Выбор партнера

Учитывая количество новых требований, частично противоречащих друг другу, и практик, которые во многом были новыми для компании, было очень сложно просчитать, сколько времени займет реализация новой инфраструктуры, адаптация legacy-приложений и обучение команд. Поэтому успех самостоятельного развертывания был не очевиден, и Yandex.Cloud порекомендовала партнера: OpsGuru, глобальную технологическую компанию с фокусом на Cloud Engineering и Data Engineering. У них уже был опыт переезда в облако legacy-решений и эксплуатации необходимых сервисов.

Совместными решениями были обобщены требования к архитектуре и спрогнозированы сроки миграции — от 2 до 4 месяцев:

  • Резервирование
  • Изоляция и разделение ответственности
  • Мониторинг
  • Шаблоны Terraform + Terragrunt
  • Шаблоны GitLab CI + Helm
  • Быстрая сборка и выкатка версий
  • Динамическое масштабирование
  • Централизованное журналирование
  • Гибкая модель инфраструктуры
  • Стандартные процессы управления циклом разработки IT + dev + business

После анализа требований стало очевидно, что некоторые из них противоречат друг другу, например:

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

Необходимо было решить, какие сервисы оставить как есть, а какие докеризировать и адаптировать к новым правилам.

Четвертый этап. Решение

Было решено использовать сервисы Yandex.Cloud для разделения между собой окружений разных стадий, таких как dev, stage и prod, и разные команды для удовлетворения многочисленным требованиям.

Дизайн инфраструктуры был выстроен с помощью таких ресурсов, как Yandex Resource Manager, Yandex Object Storage, folder и network, что позволило достичь максимальной инкапсуляции и гибкости. Абстракция folder’ов позволила отделять prod от dev разных команд с разными стеками друг от друга, а для гибкой коммуникации между ними использовать VPN.

Все манипуляции по созданию и настройке folder’ов производятся через Terraform в Yandex Message Queue, а значит, можно легко повторно использовать ранее написанную конфигурацию и есть вся история инфраструктуры в Git. Использование Terraform снижает риски при изменении инфраструктуры и повышает скорость ее создания. Этот подход позволил, с одной стороны, совместить стандартизацию и повторное использование инфраструктуры, а с другой — добиться гибкости и независимости окружений и команд.

В Yandex Message Queue есть библиотека модулей для создания ресурсов, описанных в Terraform-коде и сконфигурированных с помощью YAML-файлов. Это облегчает использование модулей под конкретную задачу, и теперь команды разработки сами могут разворачивать проверенные и новые ресурсы в dev-окружении средствами Terraform.

Созданное окружение в дальнейшем проходит review команды поддержки инфраструктуры и переходит в stage и prod, за счет этого сократилась трудоемкость работы специалистов. С помощью нового workflow удалось ускорить разработку и развертывание, а Terragrunt позволил одной командой применять изменения в масштабе целого окружения.

Пятый этап. Непрерывная поставка — GitLab CI Pipeline

Одним из важных результатов стало внедрение pipeline’ов для поставки продуктов.

  • Code review: GitLab
  • Code Coverage: SonarQube
  • Build & Test: GitLab runner tags
  • Yandex Container Registry
  • Deploy: Folder + Kubernetes namespaces

Каждый коммит запускает последовательность разнообразных проверок, которые варьируются от команды к команде. Например, для упрощения мониторинга качества кода все метрики отправляются в SonarQube, где их можно удобно просмотреть на дашбордах.

При успешной сборке и завершении всех проверок в Yandex Container Registry сохраняется готовый образ, и в любой момент его можно опубликовать в любой из сред.

Что получилось

Использование новых подходов и принципов отлично сработало. Сервисы Yandex.Cloud позволили совместить несовместимое и при этом дали возможность получить запас изоляции на двух уровнях, где можно реализовать гибкие вещи. Можно делать разные облака и разные VPC в рамках каталогов.

Управляемые сервисы Yandex.Cloud позволили значительно ускорить циклы разработки:

  • Было: команда делает заявку на создание нужных ресурсов, и срок ожидания составляет от нескольких часов до нескольких дней.
  • Стало: команда сама создает нужные ресурсы в dev-окружении по требованию за несколько минут.

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

У Renault Россия получилось выстроить несколько уровней инфраструктуры с использованием как управляемых сервисов Yandex.Cloud, так и современных cloud-native продуктов и практик. Это позволило значительно оптимизировать вложения в ее развитие и поддержку.

Мнение

Павел Лисин,
исполняющий обязанности директора по информационным технологиям
Павел Лисин,
исполняющий обязанности директора по информационным технологиям

Согласно стратегическому плану трансформации «Ренолюция» (Renaulution), озвученному Renault Group в начале года, основными задачами компании являются сокращение затрат, обеспечение обновления модельного ряда и увеличение диджитализации услуг. Департамент IT Renault Россия является активным участником процессов трансформации. Нам удалось снизить текущие капитальные затраты (CAPEX) с помощью перевода расходов на развитие инфраструктуры в Yandex.Cloud на операционную модель затрат (OPEX). Таким образом, теперь благодаря использованию сервисов Yandex.Cloud мы готовы более быстро разворачивать цифровые решения.

Есть похожая задача?

Напишите нам

И мы оперативно расскажем о возможностях Yandex.Cloud для вашего бизнеса или подберём партнёра, который полностью реализует ваш ИТ-проект.

Связаться со специалистом Yandex.Cloud
Как к вам обращаться?
Телефон
Email
Компания
Частное лицо
Должность
Размер компании
Индустрия
Какую задачу вы хотели бы решить? (Опционально)

Партнёры, которые могут помочь