Связной Банк можно с полным правом считать стартапом, хотя его предшественник, Промторгбанк, обладал довольно длительной историей. Ведь перечень оказываемых услуг, количество клиентов и точек продаж стало несоизмеримо больше. Это, естественно, предъявляет совсем иные требования к ИТ. О том, как удалось запустить центр обработки данных со всеми необходимыми сервисами в короткие сроки, а также о том, как противостоять росту объемов данных, мы беседовали с заместителем председателя правления Связного Банка Александром Тютюнником.

Intelligent Enterprise: Насколько изменились требования к ИТ после того, как Промторгбанк был преобразован в Связной Банк? Насколько им отвечала имевшаяся на тот момент инфраструктура?

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

А с технологической точки зрения Связной Банк был безусловным стартапом. Все пришлось создавать с нуля. Хотя АБС Промторгбанка, а она работает до сих пор, справлялась с обслуживанием текущей деятельности и подготовкой отчетности.

Почему решили идти по пути аутсорсинга?

Аутсорсинг — понятие весьма широкое, и оно много в себя включает. И каждый использует эту модель по‑своему. Кому‑то нужно снизить затраты. Кому‑то нужно сократить численность штатных сотрудников. У кого‑то нет специально подготовленных помещений для оборудования. Для нас главным параметром было время. Скорость запуска необходимых ИТ‑сервисов при использовании аутсорсинга оказалась минимальной. Быстро и хорошо может сделать только профессионал, и о финансовых затратах в таких случаях думают редко, поскольку издержки от любого промедления будут существенно выше. А скорость для компании очень важна, это один из ключевых элементов нашей бизнес‑стратегии. Один из наших владельцев даже перефразировал фразу главного героя известного вестерна: «Компании бывают или быстрые, или мертвые».

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

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

А отказоустойчивость? Как повлияло сильное увели­­чение уровня затрат на строительство собственных ЦОД по мере увеличения уровня TIER?

Для нас обеспечение отказоустойчивости тоже было очень важно. И мы находимся на довольно высоких уровнях, хотя работаем в «боевом» режиме меньше года. Наш SLA не опускается ниже уровня 99%. И это при том, что наш банк единственный в России, который работает без выходных во всех часовых поясах в единое время с 8.30 до 21.00. У нас 2600 точек продаж. И наше технологическое окно ограничено тремя часами ночью. В остальное время все системы должны работать.

Для обеспечения отказоустойчивости мы тоже пошли по пути аутсорсинга. Оба наших ЦОД мы арендуем. Кроме того, мы решили идти по пути работы с единым подрядчиком, а не поступать, как это часто делается: стойки арендуются в одном месте, серверы закупаются в другом, СХД в третьем, устанавливается ПО у четвертых, а сопровождением занимаются пятые. Весь комплекс работ осуществляет компания IBM.

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

Использовался ли опыт «Связного»? И если да, в какой степени?

Да, он использовался, в основном в бизнес‑стратегии. И один из ключевых ее элементов — доступность. Сейчас крупнейший частный банк в России имеет лишь около 500 точек продаж услуг, у нас же их 2600. В любой точке «Связного» можно не только купить телефон или другой высокотехнологичный товар, но и оформить или пополнить карточный счет. Но при этом учить продавца банковским проводкам или работе с АБС было абсолютно невозможно. Мы были вынуждены интегрировать свои системы с фронт-офисными системами «Связного», а также с теми системами, которые управляют платежами. Это нам позволило использовать целый ряд ноу-хау материнской компании. У «Связного» большой опыт поддержки распределенной торговой сети, и он также использовался. Кроме того, мы присоединились к договорам поддержки «Связного» ряда ключевых вендоров, в частности Microsoft. А поскольку головная компания относится к крупным клиентам, то это удалось сделать на выгодных для нас условиях, сэкономив нам немалые средства.

Был ли ваш ЦОД неким «черным ящиком», где вы задаете лишь некие основные параметры, а способ их реализации целиком отдаете на откуп подрядчику? Какова конфигурация вашей системы?

Нет, никаким «черным ящиком» ЦОД не был. Мы активно участвовали в его проектировании. Также мы настояли на том, чтобы было именно два зеркальных ЦОД с полностью идентичным оборудованием, соединенных по темной оптике.

Нам был нужен ЦОД высокого уровня надежности, с сертификацией инженерных систем на уровне TIER 3 и выше. А подобных в России, насколько мне известно, просто нет. В таких условиях единственный способ добиться высокого уровня отказоустойчивости — создание кластера из двух ЦОД, пусть и несколько более низкого класса. Хотя их класс нельзя считать таким уж низким. Сама IBM оценивает их как TIER 2+, что превышает стандартные требования TIER 2, но ниже, чем необходимо для TIER 3. И это дает более высокий уровень надежности, чем «честный» TIER 3, причем с меньшими затратами.

Основу нашего ЦОД составляют два сервера IBM System p 780 на архитектуре POWER. При этом серверы используют технологию Capacity on Demand (вычислительные ресурсы по требованию). Часть вычислительных ресурсов задействована в момент пиковых нагрузок и неактивна тогда, когда в них нет необходимости. Таким образом, мы получили возможность существенно сэкономить на оборудовании, что важно для нас как для стартапа. Эту возможность мы также выбрали сами. Кроме того, у таких систем оказался самый высокий потенциал по наращиванию вычислительной мощности. Нам, скорее всего, не придется заменять систему года через два, когда объем операций вырастет. В итоге из имеющихся на рынке «тяжелых» решений, а их не так много, было выбрано именно это.

От представителей банковского сектора часто приходится слышать, что объемы данных растут быстрее, чем предполагается. Пришлось ли в связи с этим корректировать требования к СХД уже по ходу проекта?

Мы очень серьезно подошли к выбору систем хранения. Каждый из двух серверов имеет свою систему хранения от Hitachi Data Systems, причем это модели высокого уровня. Мы тщательнее все рассчитали. Наши прогнозы полностью совпадают. Действительно, прикладные системы генерируют огромное количество данных, которые заполняют пространство на системах хранения. Мы внимательно изучали опыт других банков, которые работают на схожих системах и имеют сопоставимые объемы данных. Современные СХД представляют собой весьма сложную материю, и далеко не всегда можно понять, какие изменения там происходят, особенно за более-менее длительный период времени. Даже сами производители не могут внятно объяснить, чем их система этого года кардинально отличается от тех, что выпускались года два назад.

Так что мы, как ни банально это звучит, исходили из критерия практики. Мы не пошли на поводу у вендоров и применили опыт тех, кто имеет опыт реальной эксплуатации. И этот подход нас пока не подвел. Никаких неприятных сюрпризов мы не имели. То, что у нас есть, вполне отвечает нашим потребностям, в том числе и с прицелом на рост. А уже до конца текущего года мы намерены увеличить количество карт в пять раз, с 300 тыс. до 1,5 млн, а в перспективе довести этот уровень и до 3 млн.

Насколько перспективны новые решения в области хранения данных — например, модель иерархического хранения, использование SSD-дисков, дедупликация, устранение дублирования, сжатие данных, архивирование «на лету»? Планируется ли их использование?

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

Хотя, возможно, я и не прав. Произошло это после того, как любая модернизация и самих СУБД, и систем, которые являются надстройкой над ними, стала приводить к росту данных в несколько раз. Доводилось слышать, например, что рост объемов при переходе на новую версию АБС или ERP‑системы был четырехкратным. К росту объемов часто приводят и явные ошибки в прикладном ПО, с чем приходилось сталкиваться и мне. И поэтому, естественно, пользователи до последнего держались за относительно старые версии и не приобретали новые, что им совсем не нравилось. С этой целью им и пришлось взяться за борьбу с генерацией объемов данных.

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

Но все же я надеюсь, что каждый из трех участников — производители СУБД, систем хранения, прикладных систем — чуть поработает над решением этой системной проблемы. Мне же она кажется в какой‑то степени надуманной. Одним было все равно, а другие и вовсе прямо заинтересованы в росте объемов данных, так как это способствовало сохранению устойчивого спроса на их продукцию. Я далек от конспирологических теорий, но идея о каком‑то негласном сговоре тут появляется практически сама собой. Однако всю эту свалку надо как‑то контролировать. Впрочем, некий прогресс все же имеет место.

Но, с другой стороны, мы вынуждены сохранять разумный консерватизм, внедряя новые технологии. Ведь новые решения не всегда хорошо отлажены, и это может приводить к появлению всевозможных проблем. Любую новую систему мы тщательно оцениваем на тестовых средах. Любое обновление ПО происходит максимально аккуратно и вдумчиво. Но даже это не всегда исключает возникновение всяческих эксцессов, которых, по словам вендоров, «точно не должно быть». А любой такой сбой ведет как к прямым убыткам, так и к потере репутации. Не надо долго объяснять, что клиента, у которого из‑за такого сбоя, к примеру, не проходил платеж по карточке, потом будет очень трудно вернуть. На это могут уйти годы.

Что касается устранения дублирования, то тут, как мне кажется, чудес не бывает. Моя позиция: чисто не там, где убирают, а где не сорят. Так что данную проблему можно и нужно решать на уровне повышения дисциплины пользователей и наведения порядка в том, что и где они хранят, а также в построении политик резервного копирования. К тому же у нас основной источник дублирования данных — тестовые среды. А в наших тестовых контурах может использоваться до 10 полных копий реальной базы данных. И от этого уйти практически невозможно, поскольку наша система чрезвычайно сложна сама по себе и при этом тесно интегрированная с другими, которые применяются в группе компаний, с процессингом. Причем параллельно идет несколько проектов, связанных с тестированием приложений собственной разработки или внедрением тех или иных систем, часто крупных. И как‑то повлиять на эту ситуацию просто не представляется возможным. По сравнению с этим недисциплинированность пользователей или нестыковки в работе системы архивирования электронной почты вносят очень небольшой вклад, которым, языком математиков, можно пренебречь по малости. И такая же ситуация будет в любом другом крупном банке.

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

Если все делать правильно и аккуратно, то никаких проблем не будет. Они могут появляться лишь тогда, когда нет желания сотрудничать. Требования и Центробанка, и PCI Security Standart Council разумны и при этом понятно написаны. Другое дело, что этих требований много. Но они выполнимы. В том числе и те, что относятся к хранению данных. Хотя по мере изменения требований могут возникать сложности. Например, вступление в силу Федерального закона «О персональных данных» в полном объеме вводит некоторые изменения, в том числе появление новых регуляторов. Но эти изменения не носят системного характера. И надо просто заблаговременно подготовиться. У нас, например, уже год существует рабочая группа по приведению систем в соответствие с Федеральным законом № 152‑ФЗ.

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

Насколько остро стоит проблема работы с неструктурированной информацией (графика, аудио, видео)?

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

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

Каковы ближайшие планы по развитию вашей системы?

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