Частное облако: быстро и тотально
Стоит ли идти на миграцию? Насколько масштабной она должна быть? Сколько времени требуют такие проекты? Что дают SDN-сети и RPA на практике? Об опыте «облачной революции» рассказывает начальник управления ИТ-инфраструктуры Ак Барс Банка Олег Куликов.
Инфраструктура банка изменилась кардинально за последние годы. В чем причины такой радикальной смены подхода?
Три года назад в банке существенно обновилась ИТ-команда. Когда я вступил в должность, инфраструктура выглядела как в 90-е годы. Свои серверные, обслуживаемые силами АХО кондиционеры и пожаротушение — админы делали абсолютно все, но многие вещи по старинке.
Разработка в банке уже тогда была значительной, развивался подход DevOps, но реализовать его полноценно было невозможно, потому помимо выделения виртуальной машины была необходима организация сетевого окружения. DevOps приходилось создавать новые заявки, ждать их исполнения и так несколько раз. Разработка уже тогда была гибкой, но развертывание необходимой инфраструктуры занимало недели, а то и месяцы, что бизнес банка не устраивало совершенно.
Второй серьезной проблемой было то, что в отсутствии современных технологий управления мощностями, банк постоянно работал в режиме дефицита производительности. Любой пик нагрузки приводил к инцидентам.
Третьей проблемой была устаревшая инфраструктура. Конечно, это тоже приводило к большому числу инцидентов.
Времени постепенно все это модернизировать не было, мы пошли путем революционных изменений.
К какой архитектуре вы решили перейти и что получилось?
Мы развернули частное облако во внешнем ЦОДе. Все вычислительное оборудование наше, провайдер предоставляет помещение с инженерными системами и обеспечивает работоспособность аппаратной части на месте. Мониторинг аппаратной составляющей, замена жестких дисков или блоков питания – такие работы они выполняют сами. Все остальное – наша ответственность.
Облако мы сделали за 2019 год и начали миграцию в него сервисов. В банке около 500 сервисов, из них 150 – критичных для бизнеса. Уже переведены все основные сервисы, 90%, к 1 сентября все должно быть закончено. Частное облако действует по модели PaaS. DevOps-инженеры получили все необходимые средства для самостоятельного разворачивания виртуальных сред и их конфигурирования. У облака есть интеграция с Cisco ACI, это сильно экономит время DevOps-команд. Оркестратор и сам портал довольно сильно доработан. Пока мы закупали оборудование и монтировали его, интегратор настраивал под нас портал и делал эти доработки.
Миграция была непростой, потому что значительное число сервисов не были описаны, нашлись интеграции, о которых никто не знал. Теперь все облачные сервисы документируются полноценно, отражаются все взаимосвязи, создана CMDB – база конфигурационных единиц.
Как реагируют регуляторы и службы безопасности банка на облачную модель доступа к приложениям и данным?
Облако банка может быть только частным. Я не знаю ни одного банка в России, который работал бы в публичном облаке с чем-то большим, чем тестирование. Мы прямо сейчас проходим проверку ЦБ, в мае прошли очередную сертификацию по стандарту PCI DSS, и ясно, что по требованиям аудиторов проверку в публичном облаке не пройти. Где лежат данные, кто имеет к ним доступ: если бы мы использовали публичные облака, то ответить на эти вопросы мы бы не могли.
У нас в облаке применены SDN-сети. Оказалось, что с SDN проходить аудиты даже проще, чем со стандартными сетями. Все права и доступность ресурсов однозначно определены, и вопросов по безопасности такой организации сети возникло меньше, чем со стандартными сетями.
SDN снижает зависимость от аппаратной части, у нас решение от Cisco, SDN – фабрика CISCO ACI. Выбирая этот подход, мы хотели навести порядок в сетях, а не переносить в облако сложившуюся структуру. Делать рефакторинг существующих сетей было бы более трудоемко, чем развернуть SDN. Мы решили, и этот подход себя оправдал, что при переносе сервисов целиком будем организовывать необходимые сетевые связности. Это однозначный плюс с точки зрения безопасности.
Развернуть SDN нам помогали наши казанский интеграторы партнеры – ICL, Инностейдж. После проекта часть исполнителей перешли на работу в наш банк по согласованию с руководством интеграторов.
Как оценивается экономическая эффективность такой инфраструктурной революции?
Облако построено на технологиях VMWare и адаптировано к нашим нуждам. Стандартная классическая модель управления виртуализацией интегрирована с нашей методологической базой учета сервисов банка. Нельзя «нарезать» ресурсы, не выбрав сервис, для которого они нужны. По имени любого виртуального сервера понятно, для чего он создавался. За полчеловекодня мы считаем себестоимость поддержки любого сервиса за любое время.
Периодически такие оценки выполняются, и можно сразу увидеть, во что обошлась конкретная маркетинговая идея, реализованная в сервисе, какой была себестоимость его создания и поддержки. Дальше уже руководство бизнес-подразделений может сравнивать прибыль от такой идеи с расходами на нее.
Одна из проблем облака – ресурсы расходуются и быстрей чем раньше, и в большем объеме. Бывают случаи, когда недостаточно квалифицированный DevOps начинает поднимать производительность приложения только добавлением ресурсов, не понимая, что реально происходит и в чем проблемы.
Один из моих замов – менеджер по управлению мощностями. За биллингом следит он, опираясь на автоматически формируемую аналитику. Задача на будущее – выйти на реальный финансовый хозрасчет в использовании ИТ-ресурсов.
Раньше я был ИТ-директором банка, и там внутренние расчеты занимали до 20% рабочего времени. Считалось все. Вплоть до того, что в мой первый рабочий день мне мои же сотрудники установили приложения на корпоративный ноутбук и принесли счет на подпись за установку. Если финансовый результат подразделения не выполнен, отдел премию не получал. Считаю, что это уже перегиб.
Однако нужно понимать, что, выделяя миллиарды рублей на инфраструктуру, руководство банка хочет понимать, как они израсходованы, где отдача. Конечно, если управление инфраструктуры требует от разработчиков экономии ресурсов – это потенциальная зона постоянных конфликтов. Именно поэтому мы стараемся прийти с продуктовыми командами к компромиссам по утилизации мощностей.
Конечно, в целом повышение эффективности использования инфраструктуры – это наш следующий шаг. Пока мы сделали именно то, что было поставлено первой целью: быстрое выделение ресурсов продуктовым командам, когда скорость реализации превалирует над стоимостью ресурсов. Эта цель достигнута, следующая – развить существующий процесс управления мощностями, и научиться работать не только быстро, но и экономно.
Смена архитектурного подхода обычно требует и смены команды. Как было у вас?
Когда три года назад пришла новая команда, темп работы очень сильно вырос, и примерно 20% ИТ-сотрудников ушли сами, мы никого не подгоняли. Мы заполнили образовавшиеся вакансии и сформировали департамент заново. Удаленная работа – норма. В офисе должны быть только те, кому необходимо работать с аппаратурой. Все остальные – по желанию. Таких примерно 15%.
Большая кадровая проблема началась у нас с августа 2020 года – пошел резкий отток специалистов. Когда компании массово стали работать удаленно, в регионы пришли московские зарплаты. Квалифицированные админы, DevOps-инженеры, разработчики могут работать удаленно и делают это. Удаленная работа стала нормой в федеральных холдингах и множестве организаций, и рынок труда заметно изменился. Теперь из регионов стало намного проще работать не только для столичных компаний, но и с зарубежными организациями. Мы боремся, доказываем руководству, что нужно менять условия, но все региональные ИТ-директора жалуются на такое же положение дел.
На конференции, организованной клубом «я-ИТ-ы» у нас в Казани в Иннополисе в феврале 2021 года был очень интересный доклад о реальных потребностях индустрии в кадрах. Для создания цифровой экономики, о которой так много сейчас говорят, нужно, чтобы не менее 15% активно работающего населения было занято в ИТ. В России пока 3%. О каком взрывном росте можно говорить? Так что регионы или столицы – не так и важно, нехватка людей в 5 раз в любом случае. Для решения проблемы мы делаем то, что зависит от нас самих: автоматизируем рутинные функции, оптимизируем управление.
Заканчиваем мониторинг всей инфраструктуры и систему проактивного управления ей. Мониторинг подсказывает узкие места и точки потенциальных проблем, где не будет хватать ресурсов.
Какие рутинные функции и как именно вы автоматизируете?
Внедряем программных роботов – для автоматизации поддержки и обслуживания инфраструктуры. Вся текучка уходит к ним. Начали с простых решений, блокировка уволенных, передача прав по определенным правилам.
Так как все управление инфраструктурой банка централизованно, много админов постоянно выполняли только такие рутинные задачи. После внедрения автоматизации 95% таких заявок обрабатывается автоматически. Дальше нужны более сложные роботы. На входе в облако есть файрволы, есть старая сеть в серверных банках. Все вместе создает сложную топологию. Идем к тому, чтобы все сетевые связности для DevOps-команд формировались роботами.
Еще одна проблема – установка патчей безопасности. Отдел ИБ каждый месяц запускает сканер, ищет уязвимости и присылает нам список для их устранения. Вручную делать это мы точно не можем: для таких работ нужно выбирать технологическое окно, когда банк закрыт. Даже если мы все будем работать все ночи в месяце, мы все равно не успеем закрыть все найденные уязвимости и сделать все апгрейды. Хотим прийти к ситуации, когда робот должен на каждый сервер ставить все что нужно, а админ должен лишь в удобное для него время нажать кнопку «Принять изменения». Уровень защищенности поднимется кратно, не говоря уже об экономии труда.
Каковы ваши дальнейшие планы развития инфраструктуры?
Начинаем большой проект – создание резервного центра обработки данных.
Полный выход из строя ЦОДа не должен останавливать работу банка, во всяком случае бизнес-критичных систем. 10–15 минут перерыва и дальше должны мы работать без потери данных: именно так мы понимаем обеспечение непрерывности бизнеса, и работаем над реализацией такого проекта. При этом предполагаем использовать технологии Openstack.
Редакция благодарит клуб «я-ИТ-ы» за помощь в организации интервью.
Опубликовано 06.07.2021