«Сделай так, как это сделала бы мама»

Главное требование к современным продуктам: «Сделай так, как это сделала бы мама». Последние поколения, которые сейчас задают тренды, привыкли к качественным сервисам, чтобы сервис окружал их заботой и вниманием, был персонализированным и фактически предугадывал их желания. Мобильность и простота также лежат в основе нынешних сервисов, без них вы неконкурентоспособны. Наши услуги должны быть доступны на расстоянии пары кликов, иначе мы проиграем. При этом построить продукты нового типа на старой ИТ-инфраструктуре практически невозможно.

Чтобы подход к построению ИТ-инфраструктуры начал меняться, нужны проводники идей. Нельзя полистать журнал и сказать: «Мне это подходит, начинаю внедрять». В устоявшихся командах новые идеи, как правило, внедряются неохотно. Зачем что-то трогать, если все работает? Когда Росбанк начал уходить от монолитной ИТ-инфраструктуры, люди остались, но значительно поменялось штатное расписание, мы перешли на Аgile, сформировались команды по направлениям. Когда появились люди — проводники идей, все начало получаться.

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

Open Source и автоматизация

В ближайшие годы продукты с открытым исходным кодом будут главным драйвером российского рынка. На Западе уже давно есть целые программы Open Source First. Мы, к сожалению, в этом вопросе несколько отстаем. Ведь надо узнать о новом, попробовать и только потом попытаться внедрить. 

Росбанк активно внедряет Open Source. Практически половина наших серверов работают на CentOS — ОС с открытым исходным кодом на базе Red Hat Enterprise Linux. Мы переходим с коммерческих баз данных на открытые, в частности PostgeSQL, отказываемся от проприетарных решений в пользу Kafka и Hadoop. Я уверен: количество решений Open Source в нашем ИТ-ландшафте будет только расти.

Open Source боятся по трем причинам: отсутствие саппорта, вопросы ИБ и ненадежность. Ответ здесь один — люди. Если сотрудники ИБ-отдела или клиентского сервиса понимают, что такое Open Source и какие бенефиты он дает бизнесу, внедрение пройдет гладко. Но некоторые с непривычки могут быть сильно против таких перемен. Так, после перехода на Open Source специалисты по траблшутингу уже не смогут просто описать возникшие сложности и передать вендору: мол, я кейс создал, пускай он решает. Надо научиться обращаться к Google, комьюнити, читать техническую информацию, смотреть логи. А иногда даже обращаться напрямую к разработчикам. 

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

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

Хороший админ — ленивый админ. Знаете, почему? Он все автоматизирует. Карта серверов, установка обновлений, смена настроек — автоматизация проникла настолько глубоко, что иногда человек может не вспомнить, как развернул сервер. Если все настройки лежат в Git, проще не восстанавливаться из бэкапа, а с нуля переустановить сервер с нужными настройками. Все это пришло к нам из мира разработки и дальше будет только увеличиваться. Это и быстрее, и дешевле. 

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

Контейнеры и облака

Для нас контейнеризация — must have. Все передовые разработки Росбанка строятся на основе микросервисной архитектуры, в частности контейнеров. С микросервисами у нас уже работают 15 команд, и их количество только растет.

Как показывает практика, контейнеры в разы увеличивают скорость разработки. Если следовать базовым правилам CI/CD (Continuous Integration / Continuous Delivery), процесс создания ПО станет проще и быстрее. Новый подход добавляет прозрачности. Раньше команда хранила исходные коды в отдельном файле, посылала каждое обновление на ревью в службу ИБ, затем согласовывала их с другими продуктовыми командами и т.д. В схеме отсутствовали автоматизация и прозрачность, на выход в продуктив могло уйти до полугода. В случае с контейнерами переход от сдачи кода до релиза занимает пару недель.

Декомпозиция монолитного продукта на микросервисы дает гибкость. Предположим, приложение состоит из 20 функций. В монолитном коде ошибка в одной приводит к откату до предыдущего релиза всех 20. Если же мы работаем с микросервисами, «отмотать» придется только один, остальные функции это не затронет. А оркестрация еще и автоматизирует весь процесс.

Мы строим много облаков, потому что этот подход соответствует банковской специфике. У регулятора (ЦБ) и платежных систем (Visa и MasterCard) свои требования к информационным системам. Можно построить одно гигантское облако, которое будет соответствовать сразу всем условиям, но оно будет неповоротливым. Мы предпочитаем разворачивать небольшие cloud-решения под отдельные системы. Например, под информационные системы, которые соответствуют требованиям PCI DSS.

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

Росбанк смотрит на внешние облака, но пока реализует только частные. Прямо сейчас мы тестируем публичные cloud-сервисы, смотрим, как можно интегрировать их в нашу единую консоль. При этом требования ЦБ или ФЗ для нас на первом месте. Соответствовать регулятору — закон. 

Мы планируем развиваться именно в облачном направлении. Почему? Допустим, есть сервер с мощностью 30 ядер и сервис, который будет потреблять 10. Здесь нужна виртуализация: два таких сервиса прекрасно уместятся на один сервер, а это означает экономию в два раза. Хотя большие и сложные задачи, например, связанные с базами данных, проще решать on premise на выделенных, консолидированных серверах.

К DevSecOps я отношусь положительно. Сначала был DevOps, который объединил разработку и обслуживание. Теперь к ним присоединилась безопасность, что делает конечный продукт еще надежнее. Если все три стороны смогут договориться, они значительно облегчат друг другу жизнь. В Росбанке есть отдельный портал DevSecOps. Мы подготовили обзор всех систем и вывели данные на портал, где владельцы решений могут проверить их соответствие требованиям, гайдлайнам, проведенным аудитам. В условиях удаленной работы единый источник с информацией о работе всех ИС очень полезен.

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