Статья

Опыт банка «Открытие»: agile-инфраструктура как основа успешности agile-команд

ИТ в банках
мобильная версия

Какими характеристиками должна обладать agile-инфраструктура, размещенная в частном облаке, чтобы не стать уязвимым для команды местом? Как подходить к его проектированию и почему не стоит использовать стандартные приемы? На эти вопросы в своей статье для CNews ответил директор по информационным технологиям банка «Открытие» Кирилл Меньшов.

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

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

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

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

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

Cтандартные подходы с закупкой под сформулированные требования или закупки впрок не будут работать

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

Однако в таком случае встает вопрос организации облака. Какими характеристиками должна обладать agile-инфраструктура, размещенная в частном облаке, чтобы не быть узким местом работы команд?

Ответ, на самом деле, на поверхности: новое окружение должно создаваться не дольше чем за стандартную итерацию (как правило, речь о 2 неделях). Но под созданием следует понимать полный цикл: выделение оборудования и СХД, настройка сети и организация доступов, накат золотых образов всех ИТ-систем, входящих в скоуп-команды, обезличивание персональных данных, накат необходимых обновлений и доработок, настройку интеграций, смок-тестирование, проверку на соответствие требованиям информационной безопасности и приемку. Поскольку каждая команда отвечает за результат от начала до конца, в скоуп-команды входят ИТ-системы от фронта до бэка.

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

Каковы же тогда требования непосредственно к agile-инфраструктуре частного облака? Как подходить к его проектированию? Cтандартные подходы с закупкой под сформулированные требования или закупки впрок наиболее часто заказываемого оборудования здесь не будут работать. В первом случае сложно в принципе гарантировать разумные сроки (оборудования может просто не оказаться на складах в России), а во втором — выделение и настройка одного только оборудования займет, скорее всего, всю итерацию.

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

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