Привет, я Александр Подмосковный, руководитель Центра компетенций (BPM, CRM и SAS-системы) в Московском кредитном банке. С 2020 года начал активно развивать девопс-тему, чем, собственно, сейчас и продолжаю заниматься. 

В своей статье я расскажу, как с помощью облачной инфраструктуры и dev-платформы разработчики ПО могут получить инструменты для автоматизации развертывания и тестирования, что ускорит выпуск новых версий продукта, а также о том, как компании могут повысить надежность и безопасность ИТ-систем за счет централизованного управления, мониторинга и автоматизации процессов.

Главное фокус

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

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

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

Что обычно делает команда? Создает невероятное множество заявок сначала на заказ сервера, потом на заказ доступов к этому серверу, на настройку окружения. Это все затягивается на бесчисленное количество времени. И ну что, я вам рассказываю? Я думаю, большинство из вас с заявочками в SD. Кто-то уже преодолел этот этап, кто-то еще не до конца.

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

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

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

Что из себя представляет само приложение?

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

А если таких команд, к примеру, 50, то каждая из них пытается сделать свои сервисы, свой процесс. И получается некий зоопарк, которым совершенно невозможно управлять, масштабировать и развивать, и делать какие-то системные истории, связанные с ИТ-ландшафтом. Чем это плохо, я уже частично сказал.

Самое главное это то, что команда отвлекается от своего продукта, а остальное - как по накатанной.

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

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

Что-то на облачном

Давайте ненадолго, но очень резко переместимся в облака и поговорим о чем-то на «облачным языке». Что же такое уникальное есть в облаках, чего нет в традиционном подходе? Облака по сути предоставляют такие сервисы, как IaaS, PaaS, SaaS.

Достаточно много сервисов сейчас предоставляется, потому что эта тема уже давно популярная. Она родилась не один год назад. И для этих сервисов применен принципиально иной подход к взаимодействию с инфраструктурой – Infrastructure as Code (IaC). Любые запросы на создание, изменение, удаление виртуальных машин, сетей, файловых и объектных хранилищ, managed k8s кластеров или баз данных, мы описываем ровно так же, как описываем код нашего приложения. Мы этот код храним в системе контроля версии, будь то git или еще какие-то аналогичные, проводим все те же процессы, связанные с код-ревью, merge request. 

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

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

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

Что же такое облако? Да, вроде с одной стороны какая-то магическая сущность, ты туда пишешь код, отдаешь его, а на выходе получаешь элементы инфраструктуры.

Вот, например, взять openstack - это самый распространенное opensource ПО, которое из всего чего угодно может сделать cloud-инфраструктуру.

Если мы посмотрим на архитектуру немного детальнее, то увидим, что здесь есть также группы сервисов. Часть из них отвечает за предоставление вычислительных мощностей, часть - за предоставление хранилищ данных, и сетевых ресурсов. Выше располагаются сервисы, которые уже из элементов делают сервисы типа PaaS, это готовые managed Kubernetes кластера или базы данных. И когда мы достаточно долго смотрим на эту картинку, мы понимаем, что магии никакой нет, все объяснимо и все понятно. А понимая это, мы уже начинаем мыслить иначе и думать, как применить эти новые инструменты, которые дает нам cloud-инфраструктура. Вот с первой проблемой вроде как более-менее разобрались.

IaC и cloud-инструменты - вещь интересная, современная, да, сложная, но преимущества очевидные, и они очень классные. Кому давать эти инструменты, кто ими будет пользоваться? Если мы их отдадим в продуктовую команду, то она будет отвлекаться, а мы не достигнем нашей цели.

Вручите инструменты

Ну кто-то же должен их вручить?! Здесь мы вспоминаем про экосистему и плавно подходим к определению инфраструктурной платформы. Достаточно сложное определение, но смысл его в том, чтобы взять все инструменты и все процессы, связанные с экосистемой, вооружиться инструментами cloud-инфраструктуры, создать некую инфраструктурную платформу. Назовем ее девопс-платформа, чтобы дальше не путаться со словом «инфраструктура». Взять деовпс-платформу, команду девопсеров и создать таким образом мост между продуктовыми командами и инфраструктурой. В рамках этого моста выстроить все необходимые процессы для доставки кода уже до конечной среды исполнения. Используя в том числе и инструменты cloud-инфраструктуры, возможно, звучит сложно. 

Примерный состав инструментов:

В МКБ все примерно так же, и я не призываю говорить о каких-то вещах, связанных с rocket science. И это все очень много кому знакомо. Но понимать недостаточно. Гораздо сложнее эту историю внедрить. 

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

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

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

Подводя итоги

Cloud-инфраструктура:

Преимущества — это автоматизация, масштабируемость, системность

Ограничения — это высокий порог вхождения, сложность в освоении настройки и поддержания. Но, освоив это, можно в полной мере те преимущества использовать. 

Инфраструктурная платформа:

Является основой, мостом и фундаментом для построения дальнейшего ИТ-ландшафта, а также становится нашим конкурентным преимуществом в будущем.

Да, придется переосмыслить подходы относительно традиционных методов развития и построения ландшафта. Но движение — это жизнь, я считаю, и нужно постоянно стремиться развиваться.

Я надеюсь, вам было полезно прочитать мою статью. Буду рад ответить на ваши вопросы в комментариях!