Привет, меня зовут Максим Осорин, я руковожу Х5 Облаком в Х5 Group. Хочу рассказать про то, как мы трансформируем ИТ инфраструктуру крупнейшего в стране продуктового ритейлера. Зачем это нужно, как мы это делаем, с какими сложностями сталкиваемся и как их преодолеваем.

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

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

Предыстория и проблематика

Ещё несколько лет назад Х5 в плане ИТ была вполне традиционной компанией – был CIO, под ним иерархия различных подразделений. В 2019 году в компании началась цифровая трансформация. Помноженная на эффекты от пандемии, она дала толчок к ИТ трансформации, которая привела к рождению абсолютно новой по смыслу организации, которая сейчас называется Х5 Tech. Произошло изменение парадигмы от “мы можем купить” к “мы делаем по максимуму всё сами”. С одной оговоркой: там, где это необходимо и имеет экономический смысл. 

Очень быстро Х5 Tech превратилась в полномасштабную ИТ компанию, которая сегодня насчитывает свыше 4000 человек – в основном разработчиков и инженеров. Была внедрена децентрализованная структура, где вместо одного CIO (Chief Information Officer или Директор по ИТ) есть дюжина CTO (Chief Technology Officer или Технический директор; в Х5 Технологии это Технический директор домена) – каждый отвечает за свою область деятельности определённого бизнеса Х5. Например, функцию маркетинга конкретной торговой сети.

Была внедрена матричная структура и центры компетенций, продуктовый подход и, куда же без него, Agile в дополнение к старому доброму Waterfall.

Это позволило компании в течение короткого промежутка времени начать реализовывать свыше 100 новых инициатив (проектов и продуктов) ежегодно. Общее количество действующих информационных систем в компании на сегодняшний день – 468.

Казалось бы, всё прекрасно, но есть одна большая проблема – это устаревшая ИТ инфраструктура компании. При этом её старость определяется не возрастом оборудования (здесь как раз всё в порядке), а её соответствием, точнее – несоответствием изменившимся требованиям (тому, как начали работать в Х5 Tech). 

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

Это создавало для компании следующие проблемы:

1. Низкая скорость предоставления инфраструктурных сервисов – от нескольких недель до нескольких месяцев (если нужна закупка мощностей).

2. Высокая сложность и административная нагрузка на проектные и продуктовые команды из-за отсутствия единого окна и недостаточной типизации/шаблонизации предоставляемых сервисов. Например, процесс согласования доступов к вычислительным ресурсам мог легко потребовать от конкретного проекта/продукта до 50 чел/дней затрат на его выполнение.

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

4. Низкая утилизация вычислительных мощностей.

5. Отсутствие современных стандартизованных сервисов (managed сервисов) для проектных и продуктовых команд. Современная разработка активно использует контейнеры, автоматизацию CI/CD (инструменты автоматизированной сборки и выкатки приложений Continuous integration/Continuous deployment) и т. д. Чтобы сделать разработку более эффективной, нужно внедрять стандарты и типовые “кубики”, из которых можно создать любую систему. Не должны команды тратить время на развёртывание и администрирование СУБД или контейнерную оркестрацию.

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

7. Медленные ЦОДы (центр обработки данных) – не в смысле скорости работы оборудования, а в части любых изменений: введения новых мощностей, замены, реконфигурации, открытия новых площадок и т. д.

Выбор стратегии развития инфраструктурной платформы

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

• Высокая стоимость при большом объёме использования – от 15 до 50+ % разницы в цене между частным и публичным облаком.

• 100% зависимость от вендора.

• Навязывание проприетарных платформенных сервисов, что автоматически сделает всю разработку opinionated (Opinionated разработка – разработка информационных систем с использованием проприетарных инструментов какого-то вендора, что делает невозможным последующий переезд куда-то и, соответственно, навсегда привязывает компанию к такому вендору).

• Невозможность реализации корпоративных стандартов информационной безопасности, потеря контроля.

• Невозможность финансового контроля за расходованием средств множества разных проектов и инициатив.

• В целом отсутствие поддержки Enterprise Use Case – невозможность встраивания платформы в производственные процессы компании и её интеграции в информационные системы компании от простейших AD (Active Directory – обычно решение от Microsoft для ведения учетных записей пользователей и управления правами доступа) / CMDB (Configuration Management Database/Система Управления Конфигурациями – система, которая связывает в единое целое все компоненты какого-то сервиса или системы от уровня железа до уровня программного кода с указанием ответственных и взаимного влияния) до более сложных, таких как ERP.

• Недостаточный уровень надёжности. Фактически обязательства любого поставщика публичных облачных сервисов ограничены тем, что в случае нарушение SLA, вы получаете скидку от 10 до 100% за период (мес.) на конкретный объект, который был недоступен, например виртуальную машину. Так как мы ритейлер с большим количеством консьюмерских сервисов, нас это категорически не устраивает.

Что важно, мы запустили несколько проектов по внедрению сторонних решений. У нас был OpenShift от RedHat, Rancher от SUSE, частное облако на базе OpenStack от тогдашней Mail.ru Group (ныне VK Cloud). Мы не только внедрили эти решения, мы их эксплуатировали с продуктивными нагрузками. 

И? И ни одно из них не решало наших проблем. У всех них не было той функциональности, которая нам была нужна в полной мере. Они были закрытыми, некоторые с тупиковой продуктовой стратегией, очень высоким ценником и прочим набором Vendor Lock проблем (полная зависимость от внешнего подрядчика). Любые изменения – это месяцы или никогда. Мы не могли ничего в них добавить своего или изменить существующие сервисы.

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

Мы сформулировали для себя несколько принципов, которые легли в основу нашей новой платформы. Вот основные из них:

1. Максимальное использование OpenSource компонентов (решения с открытым кодом, которые разрабатываются сообществом индивидуальных и корпоративных разработчиков, но при этом отсутствует какая-то одна компания, которая контролирует или управляет работой сообщества). Мы не делаем Fork (термин, применимый к ситуации, когда какая-то компания берёт решение OpenSource и переписывает его части или начинает единолично его развивать собственным способом вне сообщества разработчиков) этих компонент, наоборот изменения мы согласуем с сообществом разработчиков и добиваемся их включения в Upstream (направление развития сообщества разработчиков, последние версии ПО с открытым кодом). Все custom доработки, которые по каким-то причинам нельзя включить в Upstream, мы делаем сбоку (Side-by-Side).

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

3. Принцип самообслуживания. Мы реализуем инфраструктурную платформу, которая будет работать с пользователями в режиме самообслуживания. То есть её использование предполагает, что пользователи (команды проектов/продуктов) самостоятельно выполняют все операции: активируют/деактивируют сервисы, выбирают/меняют их конфигурацию.

4. Инфраструктура как код. Пользователи должны иметь возможность работать с платформой не только через её портал, но и используя платформенный Terraform Provider.

5. Гранулярный финансовый учёт и интеграция платформы во все системы управления ИТ проектами и финансовые системы компании. Реализация принципа Pay-as-You-Go – когда средства проекта/продукта тратятся только в момент фактического использования тех или иных сервисов. Отдельно стоит отметить, что нам было важно иметь в нашей инфраструктурной платформе полную информацию о проекте/продукте (интегрированные финансовые и организационные мастер данные), а также всю историю изменений – переход на различные этапы жизненного цикла – например, переход инвест инициативы из активной стадии реализации в промышленную эксплуатацию, история всех финансовых операций, изменения связанных с системой персоналий, ответственных за проект и пр.

6. Безопасность как код. Работа с сетевыми доступами должна быть максимально автоматизирована понятным для разработчиков и Devops инженеров способом и привычными для них инструментами.

7. Сеть внутри облака должна быть а) сегментирована б) мы не хотим использовать такие рудименты, как выделенные DMZ сегменты (демилитаризованная зона, выделенный сетевой сегмент для размещения там приложений или их частей для публикации в интернет).

8. Максимальная стандартизация и шаблонизация.

9. Максимальная автоматизация всех процессов вокруг облака.

10. Инфраструктурная платформа должна позволять работать с несколькими регионами и потенциально несколькими инфраструктурными слоями – OpenStack, VMWare и т. д.

11. ЦОД и оборудование в нём – это commodity: нам всё равно, какой это бренд, важны технические характеристики, скорость изменений, стоимость и SLA (Service Level Agreement, соглашение об уровне сервиса между платформой и её пользователями) по доступности.

После детального изучения рынка, который, к слову, с тех пор мало изменился, мы выбрали для себя OpenStack в виде инфраструктурного слоя. Также стратегически мы поняли, что нет никакого смысла самим заниматься OpenStack – это очень дорого в плане команды, её практически невозможно собрать, и это несёт большие риски для компании (как минимум, ежегодного шантажа «незаменимых» инженеров). 

Мы решили купить OpenStack как сервис у компании, которая профильно этим занимается и имеет большую клиентскую базу – т. е. для которой потеря нескольких инженеров не является проблемой. При этом OpenStack должен быть максимально “ванильным”, и мы должны иметь возможность работать на версии не старше N-1 или N-2 от актуальной в Upstream.

Напомню, это было в середине 2021 года. Мы провели конкурс, в котором участвовали Mirantis, RackSpace, Canonical, RedHat, VMWare, VK Cloud. И по итогам выбрали Mirantis.

Изначально у нас была иллюзия, что мы сможем интегрировать “поверх” OpenStack несколько других решений, таких как оркестратор, портал и биллинг, но после нескольких PoC (Proof Of Concept или пилотный проект) мы быстро отказались от этой идеи, как от сложно реализуемой, дорогой и малоперспективной. 

В итоге всё, что “выше” OpenStack, мы разработали самостоятельно. Часть commodity сервисов, таких как S3 или резервное копирование, мы взяли у внешних поставщиков и глубоко их интегрировали, так что пользователь не подозревает, что это 3rd party компоненты.

Наша разработка – это десятки микросервисов, сделанных по всем канонам Cloud Native, образующие Control Plane облака и его скелет. Плюс отдельные компоненты для пользовательского портала, биллинга и платформенных сервисов. Наш основной стек разработки – это Go, мы также используем Python для узкого круга задач, прежде всего в части биллинга.

Так родилась инфраструктурная платформа, которая внутри Х5 называется Salt.

Нас все спрашивают, почему Salt? Ответ такой: нам было нужно простое и легко запоминающееся название, с одной стороны. С другой стороны, соль – это базовый ингредиент в любом блюде. Так же и наша платформа – это базовый ингредиент любой новой информационной системы, цифрового проекта или продукта внутри Х5.

Организационный подход или как мы были стартапом внутри огромной компании

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

Поэтому мы создали новое подразделение – Дирекцию по развитию облачной инфраструктуры, которая сейчас называется Х5 Облако. Эта организационная единица объединила в себе функции развития платформы и её эксплуатации, а также все вопросы, связанные с клиентским сервисом и миграциями. 

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

Мы вкладываем много смыслов в это понятие. Это касается “зелёного света” на найм тех людей, которые нам нравятся, зачастую минуя ресурсные пулы и лишнюю волокиту. Свобода мышления, творчество команды, не “уставшей” от внутренних процессов, правил и процедур, свойственных рутинному бизнесу, поддержка принципа “ошибайся быстро и дёшево”. 

Что, наверное, самое важное – было общее желание сделать не так, как проще, быстрее, легче и с меньшей ответственностью, а как правильнее для компании, особенно в средне- и долгосрочной перспективе. 

Ну и главное – это time-to-market, ведь уровень любой поддержки конечен и нужно показывать результат, подтверждающий правильность выбранной стратегии как можно быстрее. Это важно как для команды, так и для спонсоров всей затеи.

У нас ушло примерно полгода, чтобы сформировать ядро команды разработки и эксплуатации. Мы потратили колоссальные усилия на поиск и привлечение правильных людей, с нужными hard и soft скилами, релевантным опытом, и, главное, – со схожим менталитетом. Полгода вопросы формирования команды занимали как минимум процентов 40% времени в моём календаре. 

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

Могу сразу сказать: мы не та команда, где кто-то один решает, как будет правильно. Например, у нас нет выделенного архитектора, это коллективный орган. А руководитель Х5 Облака не может принимать продуктовые и технологические решения без коллегиального обсуждения и формирования сбалансированной точки зрения.

Примерно к ноябрю 2021 года мы поняли, что мы точно хотим сделать, и началась активная фаза разработки и развёртывания платформы. Параллельно работали несколько стримов/команд, мы проектировали платформу и её основные компоненты, принципы их взаимодействия, разрабатывали микросервисы платформы, разворачивали и конфигурировали OpenStack.

Отдельная команда занималась проработкой того, как будет устроена наша платформа с точки зрения сетей, взаимодействия со “старой” инфрой. Мы проектировали и планировали ЦОДы, прорабатывали платформенные интеграции. 

"Рояль в кустах" или никогда не недооценивайте информационную безопасность

Была одна область, которую мы сильно недооценили. Это всё, что связано с информационной безопасностью (ИБ) в части того, как будет устроена сеть в облаке, что такое окружения и чем они отличаются, новый процесс предоставления доступов. По факту мы потратили на это порядка трёх месяцев, а изначальный план был согласовать это в течение нескольких недель.

Здесь стоит сделать отступление и объяснить, почему так получилось. Дело в том, что, внедряя новое облако, мы запускали внутри него сегментированную сеть. До этого все инфраструктурные решения Х5 работали в “плоских” сетях, разграничение которых осуществлялось совершенно по другим принципам – с помощью классических межсетевых экранов и файрволов. Приложения, публикуемые в интернет, размещались в отдельном выделенном ландшафте – DMZ. 

Мы же хотели использовать программно-определяемую сеть (SDN) и современные облачные принципы обеспечения безопасности: изоляцию тенантов, шаблонизированные доступы, автоматизированный процесс предоставления сетевых доступов проектам и продуктам. Отдельный ландшафт для интернета ломал вообще всю красоту нашей платформы.

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

У нас было множество эскалаций в начале этой работы, но нам удалось, с одной стороны, объяснить новые принципы и подходы, а также технологические возможности коллегам из ИБ, а с другой – услышать, на самом деле какую проблему они хотят решить, и предложить такое решение.

В итоге, совместными усилиями, родилась очень красивая сетевая схема, которая предполагает не только вертикальную изоляцию тенантов (проектов), но и использование сетевого шаблона. Он предполагал горизонтальное сегментирование внутри тенанта, чтобы разнести компоненты классического (работающего на виртуальных машинах) или контенеризированного приложения – отдельные внутритенантные сети для размещения фронта, бэка, СУБД и контейнеров, плюс служебные сети.

Это позволило применить универсальный сетевой шаблон ко всей платформе, уйти от DMZ, при этом существенно повысив уровень информационной безопасности и минимизировать гипотетические “поверхности поражения” в случае взлома. 

Ещё мы реализовали принцип харденинга слева направо. У нас есть типовые окружения: dev, stage, prod и набор связанных с ними правил доступа в эти окружения и из них. 

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

Отдельная история – это как мы переделали работу с сетевыми доступами. У нас есть автоматизированный процесс предоставления сетевых доступов (например, для того, чтобы проект внутри Salt сделал интеграцию с SAP). Мы используем механизм групп безопасности. Фактически проект смотрит в справочник (внутри Salt) имеющихся групп безопасности, находит подходящую и применяет её к своим сущностям в Salt. Если таковой нет, то с помощью Gitlab и Merge Request создается запрос на новую группу безопасности, которая автоматизированно согласуется представителем ИБ.

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

Сделать платформу – это только половина дела

Первую презентацию платформы пользователям в формате Slideware мы сделали на День Космонавтики – 12 апреля 2022 года. Потом был режим ограниченного использования, в рамках которого мы занимались стабилизацией платформы, исправляли ошибки, переделывали какие-то решения на основе обратной связи от ограниченного круга пользователей. 

1 июля 2022 года Salt перешла в промышленную эксплуатацию, и мы открыли платформу для всех желающих внутри Х5 Group. Казалось бы – отлично, можно выдохнуть, взять отпуск и мысленно поставить большую зелёную галочку “Done”. Но это совсем не так.

Как тогда говорил руководитель нашей платформенной разработки – Сергей Кирсанов: “Мы построили дом, теперь нужно заселить его жильцами”. 

Для нас это означало начало проекта миграции. Наша первая миграция включала в себя переход из старого облака VK Cloud и из RedHat OpenShift. В общей сложности 232 проекта, большая часть из которых продуктивные.

Мы, конечно же, пошли в рынок, чтобы кто-то поделился с нами экспертизой и опытом. Каково же было наше удивление, что её не было. Ничего, кроме банальностей типа методологии 6R, нам никто не рассказал. 

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

Ключевые проблемы и задачи миграции следующие:

1. Миграция информационных систем из платформ, где “плоская” сеть и “широкий” доступ в современное облако, где доступ гранулярный, а проекты изолированы друг от друга.

2. Необходимость актуализации и согласования всех интеграционных потоков с ИБ для получения необходимых для работы групп безопасности.

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

4. Необходимость максимально понятного и простого выделения средств для работы системы на новой платформе.

5. Необходимость выделения технических ресурсов для переноса систем. Для проектов, где есть активные команды, развитие – это выделение ресурсов для миграции в ущерб задачам развития внутри существующей команды или их расширение внешними ресурсами подрядчиков.  Для проектов, где уже нет активной команды, это выделение ресурсов, знакомство с системой и её перенос.

6. Максимальная стандартизация и шаблонизация миграции, организации непрерывного процесса миграции, информирования, решения эскалационных вопросов.

Представьте, что вы просите огромное количество специалистов (а в пике миграции в процесс было вовлечено свыше 500 человек) что-то изменить там, где уже всё давно работает. При этом, эти изменения требуют достаточно серьёзных затрат, но главное – они показывают все исторически накопленные проблемы. Весь сор, который когда-то замели под лавку, становится очевидным и нужно в нём разбираться.

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

Как завоевать доверие пользователей

Давайте я расскажу, как мы завоёвывали доверие пользователей.

Мы для себя сформулировали следующие принципы работы: 

1. Мы работаем для наших клиентов – внутренних команд проектов/продуктов. Наша задача – помогать им, предоставлять качественные и надёжные облачные сервисы на наилучших условиях, делать это эффективно и безопасно. 

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

Для работы с внутренними клиентами мы создали отдельное подразделение – команду по онбордингу и миграции. У нас есть Customer Success менеджеры или по-другому – внутренние клиентские менеджеры, менеджеры по миграции, выделенные Devops инженеры и аналитик. Часть ресурсов мы привлекли от подрядчика. 

Команда миграции разработала методологию, которая включала в себя пошаговое описание того, что необходимо сделать информационной системе, чтобы переехать. В неё также был включен алгоритм расчёта начальных балансов в облаке, который позволял нашим клиентским менеджерам, в зависимости от фактического объёма потребления проектов в старых платформах, остатка баланса и срока использования, рассчитать начальный баланс. Всё это разрабатывалось командой миграции при тесном взаимодействии с внутренними финансовыми подразделениями Х5 Tech.

Также методология включает в себя типовой технический проект миграции с максимальной детализацией всех работ и трудоёмкостью.

Ключевые участники миграции в нашем случае были следующие: наши СТО и команды проектов/продуктов, корпоративная и Solution архитектура, информационная безопасность, финансовые подразделения. 

Если бы мы пропускали миграцию каждой информационный системы через стандартный процесс согласования архитектур и доступов, то миграция бы заняла у нас лет 5. Поэтому мы разработали новые процессы взаимодействия с корпоративной архитектурой и информационной безопасностью в режиме Fast Track. Идея заключалась в том, что мы собираем для миграции минимально необходимый набор артефактов, все остальные несоответствия фиксируем в виде технического долга со сроком устранения. Эти процессы родились не сразу, а спустя несколько месяцев совместной работы команд.

Мало придумать и утвердить методологию. Нужно её объяснить всем и организовать работы. Мы провели порядка 20 внутренних митапов в 2022-2023 г. г., среднее количество участников каждого было порядка 150 чел, самое большое – 270 человек. У нас есть очень развёрнутый портал документации. Это помогло нам начать формирование культуры использования облачной инфраструктуры. Помимо этого, команда миграции начала работать со всеми проектами, формировать графики миграции и решать возникающие проблемы.

Отдельная работа заключалась в экстремально быстром решении любых технических проблем, а также отработки изменений и новых фич по требованию пользователей, которые начали использовать платформу. Нам удалось выстроить партнёрские отношения с несколькими ключевыми очень сильными командами. Это, прежде всего, команда интеграционной платформы и логистический сервис 5Post. Благодаря постоянному взаимодействию в оперативном режиме за несколько месяцев удалось решить все проблемы роста платформы, сделать её удобной в использовании и функционально богатой для пользователей.

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

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

Команды начали ценить то, что мы делаем для них. У нас лёгкие и частные релизы,  фактически 4 дня в неделю. Это позволяет нам быстро реагировать на проблемы или запросы на новые фичи/изменения. Это ценят наши клиенты. Ведь это, в принципе, невозможно с любым внешним решением и уж тем более с публичным облаком.

Мы приступили к разработке методологии миграции в июле 2022 года. Миграцию старого облака и OpenShift мы закончили 3 и 4 октября 2023 года. Отсюда следует вычесть 2 месяца “высокого сезона” в ритейле – ноябрь/декабрь – когда у нас действует мораторий на любые существенные изменения. 

Импортозамещение

Я говорил выше, что мы выбрали Mirantis в качестве поставщика OpenStack ещё в 2021 году, не зная об ограничениях, с которыми мы столкнёмся уже весной 2022 года. Мы приобрели Mirantis Container Cloud, в который, помимо OpenStack, входил также сервис Kubernetes. Именно так наш Salt запустился в промышленную эксплуатацию.

Mirantis – компания с русскими корнями, родом из Саратова, которая уже потом стала американской и международной. Конечно же, сохранив множество наших соотечественников на различных уровнях.

2022 год стал непростым для многих ИТ-компаний. Нужно отдать должное коллегам – они до последнего нас поддерживали, хотя большинство западных вендоров уже к лету 2022 года ввели ограничения или начали уходить с рынка.

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

Вы построили самолёт, посадили в него экипаж, пассажиров и взлетели. И в полёте вам нужно заменить двигатели самолёта без посадки. Вот примерно такая задача перед нами встала в октябре 2022 года.

Для её решения мы к середине ноября придумали и запустили проект с кодовым названием Wasabi, предполагающий замену Mirantis OpenStack в горячем режиме “на лету” и замену сервиса Mirantis Kubernetes на собственную разработку. Это точно тема для отдельной статьи. Но, забегая вперед, скажу: мы справились. Весной 2023 года мы выпустили свой сервис Kubernetes, а в сентябре завершили замену OpenStack в наших ЦОДах на KeyStack от ITKey. 

KeyStack – это ванильный Openstack от российской компании ИТ Ключевые решения. Он дополнительно обвязан автоматизацией, инструментами управления жизненным циклом и захарденин, но сам OpenStack ванильный.

Так Salt стала полностью российской платформой. А наш инфраструктурный спецназ стал старше и немного седым, но приобрёл уникальный опыт – такого масштаба проект делали всего несколько команд в мире.

Медленные ЦОДы

Одна из проблем, с которой мы столкнулись – это неэффективность традиционных подходов и процессов в части организации работы ЦОД в крупной компании. Классическое инфраструктурное подразделение работает по модели Colocation:  арендуют место в ЦОД, далее проводятся различные конкурсы и либо разные поставщики, либо собственные подразделения выполняют поставку вычислительного, сетевого оборудования, пусконаладочные работы и занимаются эксплуатацией ЦОДа. Т. е. это смешанная подрядно-хозяйственная модель. 

В контексте современных инфраструктурных платформ, которые, по сути, динамические, с такой моделью есть несколько проблем:

1. Дорого.

2. Долго.

3. Нужно покупать мощности впрок и всегда опасаться “рояля в кустах” в виде неожиданного большого проекта, который “съест” резерв.

4. Сложно выдерживать SLA, т. к. нет единого центра ответственности. 

Вместе с нашими партнёрами из Selectel мы придумали другую модель – “ЦОД как сервис”. 

В чём её смысл? 

1. Мы можем выводить полностью готовую стойку со всем оборудованием внутри за срок <3 недель. Это возможно, когда оператор ЦОДа одновременно является крупным производителем серверных платформ. Также это возможно, когда подрядчик делает всё – ЦОД, стойки, кэйблинг, ПНР, эксплуатацию железа и каналов связи. Какой это даёт эффект: нет нужды “морозить деньги” в оборудование, складирование, ЗИПы и проч.

2. Нам всё равно, что написано на сервере, главное – его технические характеристики и цена.

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

3. Мы хотим платить за всё оборудование так же или близко к тому, как нам платят наши пользователи. Они ведь не выкупают у нас ничего на годы вперёд. Они постоянно пополняют свой лицевой счёт и тратят с него средства. Отсюда модель финансового лизинга. Мы платим не всё сразу, а в течение пяти лет. 

4. Ну и, конечно же, единый центр ответственности и максимальная интеграция такого комплексного подрядчика в процессы эксплуатации нашей платформы. При этом мы отвечаем за всё, что от уровня операционной системы и выше, а партнёр – за всё железо. Нам не нужны ЗИПы, у нас сроки замены вышедших из строя компонент не превышают двух часов.

5. Ещё один косвенный плюс – это отсутствие множества административного персонала: один конкурс вместо десятка, один подрядчик вместо нескольких. Это всё ускоряет, делает более прозрачным и понятным.

6. Быстрое открытие новых площадок. Классическая модель – это 6-12 месяцев. Мы можем запустить новые регионы в течение месяца.

Salt сегодня и завтра

Сегодня

Что такое Salt сегодня? У нас два независимых региона – Москва и Санкт-Петербург. Они равнозначны в части предоставляемых сервисов. В случае какого-то ЧП в одном из ЦОДов, второй продолжит работать. 

С точки зрения сервисов мы предоставляем стандартные Compute, Network и Storage. Т. е. это виртуальные машины, балансировщики нагрузки, разные типы дисков, как в виде СХД, так и Ceph. У нас есть сервисы S3 и бэкапы как сервис. 

Ключевой сервис – это managed Kubernetes и managed PostgreSQL. Недавно мы запустили мониторинг как сервис. 

На начало октября 2023 года у нас «живут» 125 информационных систем – это порядка 560 проектов. Свыше 8000 виртуальных машин, 376 кластеров Kubernetes, 199 СУБД PostgreSQL.

В организационном смысле наша команда сегодня – это 120 человек. Основной прирост идёт за счёт присоединения новых команд (таких, например, как SRE) в рамках нашей стратегии по превращению ИТ4ИТ сервисов в облачные.

Облачная платформа Salt активно растёт. Наш среднемесячный прирост в объёме потребления – свыше 13% в деньгах и “физике”.

Завтра

Мы активно работаем над реализацией сервисов высокой доступности и катастрофоустойчивости. 

Готовятся к релизу другие наиболее востребованные Devops сервисы именно как платформенные – логгирование, трейсинг, RabbitMQ и пр.

 В 2024 году один из наших старых ЦОДов заполнится, и мы будем открывать ещё один облачный регион – новый ЦОД.

Также Salt расширяется на традиционные инфраструктурные сервисы. Сейчас мы реализуем MVP по интеграции VMWare, при этом мы хотим максимально приблизить классическую виртуализацию к облачной парадигме – это касается и способа предоставления сервисов пользователям, и реализации сегментированной сети. 

К середине 2024 года заработает сервис Bare Metal как сервис.

Помимо этого, сейчас на повестке переосмысление того, как нужно строить и эксплуатировать критические высоконагруженные информационные системы. Как правильно, системно и на практике применять Cloud Native подходы и SRE практики.

Заключение

Конечно же, пытливый читатель задастся вопросом: а чего вы добились для компании? Что изменилось? Нам есть что на это ответить.

1. Мы дешевле практически по всем сервисам любого публичного облака в РФ от 16% до 47%. Наш внутренний бенчмарк – это Яндекс Облако. И это очень существенные цифры в масштабе такой крупной компании, как Х5 Group. И да, это корректно рассчитанные тарифы, которые включают в себя все затраты. Мы потратили много месяцев на разработку и внедрение полноценной ресурсно-сервисной модели вместе с нашими финансистами.

2. Time-to-Market для проектных и продуктовых команд. Salt – это динамическая инфраструктура. То, что раньше занимало недели-месяцы, сейчас занимает минуты. Причем, это не просто предоставление, например, виртуальных машин, а предоставление их со всеми необходимыми доступами.

3. Полная финансовая и организационная прозрачность использования инфраструктурной платформы, её глубокая интеграция в производственные процессы Х5 Tech.

4. В компании появилась функционально богатая платформа, удобная в использовании, с современным набором инфраструктурных сервисов. Мы её разрабатывали в тесном контакте с сотнями команд, которые её использовали и старались реализовать их пожелания как к логике работы предоставляемых сервисов, так и к удобству использования. 

5. Высокая скорость изменений: исправление ошибок, реализация фича реквестов и выпуска новых сервисов. Мы делаем лёгкие релизы 4-5 раз в неделю.

6. Инфраструктура и команда, которой доверяют. Сейчас даже с учётом сложнейших операций по замене OpenStack у нас доступность на уровне 99.9%, к концу года мы достигнем 99.95%. 

7. Полная независимость от любого внешнего вендора и самодостаточность.

По сути, мы создали основу для облачной трансформации компании. Дальше мы будем превращать в платформенные (облачные) все ИТ сервисы, которые сегодня оказываются разными командами по заявкам. Будем распространять на них ресурсно-сервисную модель, унифицировать и гармонизировать всё от способа предоставления сервиса до SLA.

Инвестиции в облачную трансформацию полностью себя окупают и приносят весьма заметные финансовые и нефинансовые результаты, создавая, в конечном счёте, дополнительное конкурентное преимущество для компании.