«Открою секрет. Мы строим совершенно новую технологическую платформу для банка будущего», – Никита Волков, Сбербанк
Сбербанк развивает свою IT-инфраструктуру как с применением уже доказавших свою эффективность технологий и подходов, так и рассматривая и тестируя новые. Старший вице-президент Сбербанка по IT Никита Волков рассказал FutureBanking о работе по повышению надежности и о закладке фундамента платформы «банка будущего».
МегаЦОД Сбербанка получил уже третий сертификат Uptime Institute. Обычно подобная сертификация нужна коммерческим ЦОД, чтобы привлечь клиентов. Зачем это Сбербанку? Перед постройкой МегаЦОДа руководство банка заявляло, что в будущем, возможно, банк будет предоставлять услуги по аренде ЦОД и другим клиентам. Не готовитесь ли вы к этому?
Сбербанк – публичная компания. Чем мы надежней, тем выше цена акций. И, кстати, зарплаты топ-менеджеров публичных компаний часто зависят от стоимости акций, и мой доход – тоже. Поэтому мы очень заинтересованы в надежности и рады получить подтверждение, что она у нас есть. На самом деле только 11 организаций в мире имеют сертификат Uptime Institute Tier III Operations Gold, и около половины из них построили ЦОД для собственных нужд.
Конечно, мы должны быть уверены, что наша инфраструктура способна работать без сбоев. Мы уже получали сертификаты Tier III за дизайн ЦОД и его реализацию. Теперь банк получил подтверждение, что и все наши процедуры и регламенты соответствуют лучшим практикам, то есть влияние «человеческого фактора» в процессе операционного управления минимально.
Что касается предоставления услуг другим банкам – на самом деле, мы их уже предоставляем. Как вы знаете, у Сбербанка есть несколько дочерних банков в других странах, и они пользуются услугами нашего МегаЦОД. Кстати, в странах нашего присутствия разные правила регулирования, и некоторые из них касаются надежности. Так что сертификация нужна и для подтверждения соответствия этим правилам.
Каких показателей надежности вам удалось добиться?
Вот уже 2 года Сбербанк реализует так называемую Программу 99,99. За это время более чем в 6 раз снижено суммарное время простоя автоматизированных систем из-за технологических работ и инцидентов. Критичные системы банка полностью задублированы. Существующая схема резервирования позволяет обеспечить восстановление систем при выходе из строя основного ЦОД или его частей. Более чем в 4 раза увеличена производительность ключевых систем. В результате использования дублирующего режима Stand-in, позволяющего не останавливать работу систем во время технологических работ, мы сэкономили 255 часов работы ключевых систем, из которых 100 часов – интернет-банкинг и 110 часов – процессинг. Мы постоянно повышаем производительность наших систем и планируем на полтора года вперед.
Однако одних технологий мало. Нужна соответствующая культура. На всех уровнях в банке люди должны осознавать, что надежность — это то, о чем необходимо помнить всегда.
То есть сейчас вы можете утверждать, что продолжительные инциденты, подобные тому, что случился в 2013 году, когда клиенты долгое время не могли воспользоваться картами Сбербанка, больше не повторятся?
Та конкретная проблема была решена еще до моего прихода в банк. Невозможно однозначно утверждать, что инцидентов никогда не будет. Они могут быть, но мы стремимся минимизировать влияние инцидент на уровень сервиса для клиентов или минимизировать этот период. Вообще мы считаем, что возможны различные ошибки – в операционных системах, базах данных, аппаратные и коммуникационные сбои, ошибки персонала, наших разработчиков, тестировщиков. Сбоем для нас является не только полная неработоспособность системы, но и существенное падение ее производительности (для разных систем применяются разные параметры, но обычно инцидент фиксируется при падении производительности на 20–30%). Наша главная задача не в том, чтобы инцидентов не стало вовсе, а в том, чтобы инциденты устранялись без влияния на клиентов.
Каков ваш план по развитию системы ЦОД?
В целевом сценарии мы рассчитываем прийти к наличию 3 ЦОД к 2019-2020 году. Сейчас их больше 16 в регионах и МегаЦОД в Москве. Хотя мы ведем масштабную программу централизации, какие-то локальные системы в регионах все еще сохраняются. Впоследствии мы надеемся оставить в регионах только коммуникационные узлы.
Кроме того, мы сейчас арендуем 3 ЦОД в Москве, потому что имеющихся мощностей не хватает. Но уже запланирована постройка нашего второго МегаЦОД в «Сколково». Еще один, резервный, ЦОД мы планируем построить на Урале.
Что происходит с IT-бюджетом Сбербанка?
Недавно мы приняли IT-бюджет на следующий год. Не буду называть сумму, потому что все банки считают IT-бюджет по-разному, и могут возникнуть разночтения. Могу лишь сказать, что наш IT-бюджет растет в среднем на 15% в год.
«Сбербанк-Технологии» недавно заняли третье место в рейтинге CNews крупнейших поставщиков IT для банков по выручке от проектов, при этом рост за год составил 48%. Почему и будет ли эта тенденция сохраняться?
Да, компания вырастет еще на 25-30 % в следующем году. Считаю оптимальным иметь разумный баланс между разработкой «своими» и «сторонними» силами. На рынке нужна конкуренция, выбор. На мой взгляд, «Сбербанк-Технологии» уже достаточно большая компания, которой при бурном росте будет все сложнее и сложнее эффективно управлять. Сейчас она выполняет почти 70% IT-проектов Сбербанка. Это большая доля, и наращивать ее считаю нецелесообразным.
Недавно Лев Хасис говорил, что Сбербанк собирается присоединиться к альянсу R3. Какие-то конкретные шаги к использованию блокчейн делаются?
Да, технология блокчейн мне нравится, она очень красивая. Но не могу сказать, что у меня есть какие-то определенные кейсы, как ее можно использовать. Мы на нее смотрим, изучаем, но ее применение – это не самое ближайшее будущее.
Есть ли в IT Сбербанка что-то инновационное?
Открою секрет. Мы строим совершенно новую технологическую платформу для «банка будущего». Руководство банка понимает, что это необходимо, и выделяет все необходимые ресурсы. В основу платформы положены технологии grid, in-memory computing. Это принципиально иная архитектура, там используются серверы более низкого класса. Потому что то железо, которое у нас есть сейчас — самое мощное из существующего на рынке. И даже оно работает на пределе.
Эта статья была разослана 1209 людям, которые подписались на тему «IT в банке»
Чтобы подписаться на «IT в банке», просто введите Ваш
электронный адрес.
Режим ожидания Standby, или Держите аппаратуру включенной [перевод]
Вы замечали, что большинство кнопок «power» на передней панели оборудования на самом деле не включают и не выключают питание? Большинство из них — это кнопки режима ожидания «Standby» — они включают индикацию на передней панели и поддерживают устройства в режиме ожидания. Чаще всего это нужно, чтобы держать наготове достаточно схем для работы пульта дистанционного управления. Если вы совсем выключите питание, пульт ничего не сможет сделать.
Много лет назад все продукты оснащались механическими выключателями питания и кнопками на передней панели. Но только не устройства PS Audio. Мы были одной из первых компаний, встроивших функции режима ожидания в нашу продукцию. И это было задолго до того, как у кого-то появился пульт дистанционного управления. Некоторые из вас, возможно, помнят, что пульты ДУ в 1970-х годах были неуклюжими устройствами и использовались в основном для телевизоров. Я помню наш первый пульт — приходилось давить на переключатель каждой команды, чтобы заставить его работать. Усилие было необходимо, потому что пульт генерировал ультразвук, который воспринимал телевизор.
Нет, мы не добавили наш уникальный режим ожидания только для того, чтобы использовать пульт дистанционного управления. Мы сделали это, чтобы удостовериться, что наши продукты звучат лучше, несмотря на привычки наших покупателей.
Когда мы вначале выпустили наш первый продукт — автономный фоно-предусилитель, там вообще не было никаких элементов управления. Ни выключателя питания, ни нагрузочных резисторов. Ни-че-го. Надо было вставить вилку в розетку, запитать предусилитель и оставить его работать. Существовали две причины для такого решения: во-первых, мы хотели убедиться, что владелец не выключит питание, когда устройство подключено к работающей аудио системе, вызывая громкий и потенциально вредный для динамиков удар. Но главная причина была в звуке. Мы довольно рано обнаружили, что аудиотехника нуждается в прогреве и всегда звучит лучше, если ее уже включали на некоторое время. Холодный фоно-предусилитель звучал значительно хуже, чем оставленный включенным на несколько дней. Сейчас это кажется очевидным для нас. А те клиенты, которые хотели бы иметь возможность выключить его, как оказалось, были просто неправы.
Наши продукты стали одним из первых в отрасли, которые продавались с гарантией возврата денег (money back). Вспомните, это ведь было еще в 1973 году и никакое Hi-Fi-оборудование, которое я знаю, не имело такой гарантии. Это был смелый шаг, благодаря ему мы процветали (и процветаем сегодня). Из многих тысяч фоно-предусилителей, которые мы отгрузили, наверное, всего 10 или 20 вернули нам с возвратом денег. Один из них вернулся от человека, который был расстроен тем, что когда он подключал предусилитель-корректор в свою систему, его колонки, казалось, «исчезали». Он уже больше не мог закрыть глаза и точно указать пальцем на левый или правый канал; настолько явно они были слышны до появления нашего продукта. И он потребовал свои деньги назад. Мы с удовлетворение вернули ему деньги, в восторге от признания того, что наш тяжелый труд по приданию колонкам «невидимости» окупился.
Когда он вернул нам устройство, оказалось, что он перерезал шнур питания и вставил небольшой проходной выключатель. Это было довольно странно, поэтому мы позвонили ему и спросили, зачем он это сделал.
Мы не могли вынести мысль, что люди регулярно выключают питание системы каждый вечер
«Я не могу терпеть и смотреть, как этот свет все время горит». Мы уточнили, связана ли его ненависть с заботой об экономии энергии, на что он ответил: «Нет, просто я не могу видеть этот проклятый свет». Ночью в его системе все должно быть выключено. И он был не одинок в своих капризах — весьма распространенная жалоба тогда среди наших клиентов, они требовали спокойствия. Мы, с другой стороны, не могли вынести мысль, что люди регулярно выключают питание системы каждый вечер, только чтобы звук вновь оказался холодным и не захватывающим при очередном включении.
Я уверен, что вы понимаете, как это происходит. С этого дня каждый продукт PS Аудио, за исключением наших усилителей мощности, имеет кнопку на передней панели с надписью «Power». Но кнопка не выключает питание. Она лишь приглушает звук на выходах устройства и выключает все световые индикаторы на передней панели. А чтобы мы были счастливы, питание при этом оставалось включенным, и устройство всегда было готово выдать отличный звук.
В более поздних моделях мы почувствовали себя слегка виноватыми, называя эту кнопку «Power», и поменяли ее на «Input» (или «Off», которая делал то же самое).
К нам никогда не было претензий, и у нас было много клиентов, пораженных тем, что наши устройства всегда звучали идеально, даже когда они якобы были «холодными» (не прогретыми).
Мы просто улыбались в ответ и говорили спасибо.
Держите аппаратуру включенной
По поводу прогрева или приработки, чтобы аппарат зазвучал с течением времени лучше, не утихают споры, и мнения встречаются самые разные. Настолько разные, что порой они напоминают байки о том, что делают медведи в лесу, горят ли внутри холодильника лампочки, когда он выключен, или что происходит с деревьями, когда они падают.
Вот вам мое мнение: за небольшими исключениями, такими как ламповые устройства и усилители мощности, которые сильно греются, свободно оставляйте свое оборудование включенным в режиме 24 часа/7 дней в неделю. Для этого есть несколько причин.
Больше всего электроника страдает от процесса включения/выключения, чем от постоянной работы. Скачок напряжения, поступающий в технику, может иметь во много раз более разрушительные последствия, нежели вы оставите оборудование включенным в течение длительного периода времени. Более того, если вы не прожжете большую дыру в вашем бюджете платой за электричество, то расходы, связанные с этим, практически отсутствуют. Современное оборудование с каждым годом становится все более эффективным по потреблению в режиме ожидания или холостого хода. Новые европейские правила требуют потребления предельно низкого тока в режиме Standby, и большая часть оборудования не потребляет много энергии из розетки ни при каких обстоятельствах.
Это не относится к усилителям, работающим в классе А, ламповым приборам и всему, что производит много тепла, поскольку их эффективная долговечность заметно сокращается от перегрева конденсаторов и прочих болезней.
В то же время в пользу постоянного включения оборудования есть много аргументов. Никто не сможет убедить меня в том, что система, которая была включена и проработала в течение нескольких дней подряд, станет от этого звучать хуже, чем та, которая только что претерпела холодный запуск. Я бы осмелился предположить, что, если вы с этим не согласны, значит, вы действительно мало слушали аудиосистемы с высоким разрешением. Но я знаю, что некоторые люди в ответ сразу «ощетинятся всеми иголками», поэтому лучше промолчу.
Лучший совет, который я могу вам дать: держите аппаратуру включенной. Поддерживайте огонь в своем домашнем очаге.
Это самый простой путь к лучшему звуку.
Об авторе: Пол МакГоуэн (Paul McGowan) – директор (CEO) и сооснователь компании PS Audio Inc. из города Боулдер, Колорадо, конструирующей и выпускающей High End-аудио продукты и сервисы.
Надежность ВТБ: как мы добились «четырёх девяток» доступности банковских систем
Привет! Меня зовут Иван Мартинович, я заместитель руководителя департамента поддержки прикладных систем и сервисов — вице-президент в ВТБ. В теперь уже далёком 2019 году мы запустили одну из ключевых программ цифровой трансформации банка, нацеленную на обеспечение надёжности целевых систем. О том, как мы проводили её в разгар пандемии коронавируса и что из этого всего вышло, мне бы и хотелось сегодня рассказать.
Итак, 2019-й, четвёртый квартал. В состав ВТБ входит ряд крупных банков, таких как Банк Москвы, ВТБ-24. В каждом присоединённом банке на протяжении долгих лет развивались собственные информационные системы. У каждого была своя философия, свой технологический стек, подход к ведению процессов, представления о том, как все сделать наилучшим образом в текущих условиях.
Все эти разрозненные благие намерения привели к тому, что три с половиной года назад в совокупности мы имели:
- разномастные ландшафты со своими архитектурами, технологиями, стандартами;
- устаревшие ЦОД’ы, не соответствующие требованиям надёжности;
- устаревшие и разрозненные сети, как опорные в ЦОД’ах, так и региональные;
- запутанную схему взаимодействия между ЦОД’ами;
- коллективы, привыкшие к своим процессам, культурам, отношениям внутри компаний.
Всё это сказывалось на надёжности сервисов — доступность business- и mission-critical-систем банка составляла 96,74%. Наши клиенты могли наблюдать сбои и простои во время технических работ. Региональные офисы страдали от проблем из-за старого оборудования и сетей. Нам предстояло создать единый ландшафт — современный и надёжный. И быстро.
Задача обеспечения надёжности IT-ландшафта банка легла в название соответствующей программы. Её символом стали «четыре девятки» — 99,99% доступности банковских систем, — это то, к чему мы стремились. Для нас это означало, что в любой системе допустимы простои не более 52 минут в год, невзирая на аварии или технические работы.
Но легко сказать «давайте сделаем, чтобы не было простоев». На тот момент мы не могли соответствовать таким требованиям — у нас не было на руках всех инструментов, технологий, процессов. Решать проблемы приходилось буквально по всем фронтам. Для простоты мы разделили задачи на три больших кластера.
Кластер первый. Инфраструктура
Нам предстояло разобраться с ЦОД’ами. После объединения банков у ВТБ оказалось аж девять ЦОД’ов. Увы, они никуда не годились — два можно было назвать приличными, семь — изрядно устарели. И все девять не соответствовали нашим требованиям надёжности и безопасности. Тут был только один выход: делать заново и сразу так, как надо. Сказано — сделано! В итоге мы:
- построили 2 целевых основных ЦОД’а по новым стандартам;
- закупили туда современное оборудование вместо устаревшего;
- построили новую опорную сеть внутри ЦОД’ов и между ними;
- провели миграцию систем, причём с проверкой на соответствие новым паттернам надёжности и перестройкой резервирования и последующей доработкой при несоответствии.
В результате у нас появились ЦОД’ы, которые по параметрам доступности и непрерывности поставляемых сервисов соответствовали уровню Tier 3.
Параллельно начали заниматься платформой VDI, которая обеспечивала бы сотрудников виртуальными рабочими местами. У нас также сложился разрозненный ландшафт решений VDI, плюс ранее мы использовали VDI Horizon, но признали его недостаточно безопасным и решили заменить на собственную целевую платформу VDI. Как раз в то время в Россию пришёл Covid-19, люди массово переходили на удалённую работу — и возможности новой платформы оказались очень кстати. Только в начале пандемии она позволила нам создать 30 тысяч рабочих мест для удалёнщиков.
Наша региональная сеть, связывающая ЦОД с региональными офисами и точками продаж, тоже была устаревшей и разрозненной. Мы полностью заменили сетевое оборудование на новое, соответствующее нашим паттернами надёжности. Создали централизованные почтовые сервисы, разобрались с доставшимися нам от банков системами управления учётными записями пользователей сети — Active Directory, для их объединения мы реализовали новый проект.
Кроме того, мы полностью пересмотрели подход к организации инфраструктуры регионов. Переход на новую целевую сеть позволил отказаться от размещения в региональных офисах собственных инфраструктурных сервисов и перенести их все в целевые ЦОД ГО. Что значительно повысило их надёжность и сократило затраты на сопровождение.
В инфраструктурном кластере была также значимая проблема, связанная с облачными решениями. На тот момент у нас уже были и облака, и средства виртуализации, но вендорские и устаревшие. Нам нужно было новое облако, причём покрывающее всю созданную инфраструктуру. Как и в случае с ЦОД’ами, мы взялись за разработку облака сами — хоть и не без помощи опенсорсных решений. Для управления разработали движок, облачный оркестратор, интерфейс. А для отслеживания параметров — построили системы биллинга и анализа отчётности по облаку.
С облаком у нас появились новые возможности на разных уровнях. На уровне IaaS мы смогли управлять виртуализацией серверов уже не с помощью сторонних решений вроде VMware, как делали это раньше, а опираясь на собственные решения. А на уровне PaaS — поднимать не просто виртуальные серверы, а серверы с интеграционными компонентами, развёрнутой базой данных, Kafka и так далее. При этом команды разработки теперь могли сами создавать инструменты и получать вычислительные мощности — просто и без участия в этом процессе каких-либо сотрудников поддержки, для чего был разработан и внедрён портал самообслуживания.
Создание облака и инструментов на его уровнях дало буст развитию других, смежных программ. Например, благодаря им существенно сократилась метрика time-to-market. Мы также могли теперь управлять нашими мощностями в виде ресурсов. Например, выделять командам разработки квоты на мощности, в рамках которых эти команды могут брать и использовать оборудование, возвращать его. И в целом новое облако позволило нам правильно утилизировать оборудование, чтобы оно не простаивало.
Кластер второй. Архитектура
Здесь мы начали работу с анализа. Собрали чек-лист требований надёжности и необходимых для их реализации элементов. Проверили по нему все наши критичные системы и выявили бэклог задач по каждой из них — своего рода техдолг. И уже по этим задачам запустили решающие их проекты.
Одна из ключевых задач этого кластера — резервирование. На старте программы во многих системах не было правильно реализованного резервирования. Резервирование должно было обеспечить нам не только защиту от сбоев и аварий на оборудовании, но и возможность проведения технических работ без остановки систем. Чтобы пользователи получали сервис 24/7 и больше не видели рассылок вроде «Уважаемый клиент, в ночь с такого-то по такое-то число будут проводиться технические работы, извините за неудобства».
Мы обратились к Stand-In — инструменту резервирования, создающему копию системы, на которую можно перейти в момент простоя основной системы. Причём мы пошли дальше и не стали делать репликацию только на аппаратном или платформенном уровне, как это обычно принято, а дополнительно реализовали её ещё и на прикладном уровне. То есть система в нашем случае реплицирует данные на защищённую дополнительную резервную часть.
Это работает так: когда нам нужно провести какие-то работы в рамках технологического окна, мы переводим систему в Stand-In. Клиенты не замечают этого и получают свой сервис, как обычно. Так же незаметно система переключается обратно. И такими Stand-In мы покрыли все наши критичные системы. В первую очередь — работающие онлайн высоконагруженные и критически важные системы: АБС, процессинг, системы противодействия мошенничеству, системы фронтального обслуживания — клиентские приложения и их веб-версии.
Кластер третий. Организация и процессы
Здесь нам пришлось решать проблемы наследия процессов, команд и корпоративных культур.
Одной из важных задач стала выработка понятной всем методологии и набора процессов. В ВТБ и до слияния были внедрены основные процессы, но цифровая трансформация заставила нас серьёзно пересмотреть их. Мы переосмыслили процессы управления инцидентами, авариями, проблемами, управление мощностями, мониторингом и другие. Но мало было просто разработать методологию — нам нужно было ещё донести её до сотрудников, обучить их. Также требовалось создать единые инструменты, где процессы будут автоматизированы. Для управления ими мы построили единую платформу.
Для того чтобы процессы заработали, нужны были данные — с ними мы могли бы понимать всю картину. У нас были разные средства мониторинга, но ни одно не позволяло консолидировать все данные и показывать весь ландшафт в целом. И опять нам пришлось создавать всё заново самим — на сей раз уже единую систему мониторинга. Мониторинг покрыл 100% наших систем и инфраструктуры под ними, и с его помощью мы наконец смогли в режиме реального времени наблюдать весь ландшафт, получать информацию о текущем состоянии сетей, железа, баз данных, взаимодействиях систем, бизнес-метриках. Мониторинг стал важным инструментом для сотрудников поддержки и ситуационного центра.
К слову, единый ситуационный центр тоже появился у нас в ходе реализации программы «Надёжность». Мы их построили даже два — в Москве и Самаре, чтобы в случае форс-мажоров в одном второй продолжил бы работать. И не только обеспечили их помещениями и оборудованием, но и инструментами реализации процессов.
Наконец, мы создали для сотрудников ВТБ мобильное приложение, чтобы они оперативно получали информацию об авариях, работе бизнес-сервисов, могли видеть бизнес-метрики и реагировать в случае каких-то проблем.
Итоги
Мы завершили программу «Надёжность», и этот этап цифровой трансформации во втором квартале 2022 года. Уже можно подвести итоги и посмотреть, стоили ли эти изменения усилий и достигли ли мы своих целей. А лучше всего о результатах скажут цифры.
Инфраструктура
ЦОД’ы: вместо 9 устаревших и ненадёжных создали 2 новых ЦОД’а уровня Tier 3.
Оборудование: вывели из эксплуатации более 4000 единиц устаревшей техники.
Единая региональная сеть вобрала в себя 1400 точек продаж по стране:
- создано более 30 000 виртуальных рабочих мест в целевых ЦОД’ах;
- около 15 000 пользователей объединены на целевых доменах AD;
- создана своими силами единая облачная платформа.
Архитектура
Техдолг: устранён на 100%. Да, все те бэклоги, всё наследие присоединённых банков, из которого мы его сформировали в начале программы, были выполнены.
Резервирование: реализовано 11 Stand-In в различных МС-системах, в их числе — процессинг, противодействие мошенничеству, фронтенд и т. д.
Интеграционные платформы присоединённых банков объединили в одну.
В кластере организации и процессов: 100% систем подключены к единой системе мониторинга и находятся под наблюдением ситуационных центров:
- среднее время решения инцидентов снизилось на 72%;
- среднее время реакции на инцидент сократилось в 5 раз;
- аварий стало меньше в 2,4 раза;
- общая длительность аварий сократилась в 16 раз;
- в 20 раз сократилось время выявления критичных аварий;
- в 13 раз снизилось время регистрации таких аварий;
- в 3 раза быстрее стали устранять критичные аварии.
Экономический эффект программы «Надёжность» к её закрытию составил 17,9 млрд рублей. Мы прогнозируем, что через десять лет он вырастет до 80 млрд.
На этом цифровая трансформация ВТБ не закончилась, — это был лишь первый большой её этап. В начале 2023 года мы запустили новую программу — «Непрерывность». Теперь, когда мы устранили техдолг и достигли тех 99,99% надёжности, за которые боролись, сфокусируемся на повышении уровня доступности сервисов для клиентов, займёмся проблемами хранения информации архивных данных, продолжим улучшать наши ЦОД’ы и развивать облачные продукты VTB.Cloud. И в целом будем стремиться к технологическому суверенитету ВТБ. Программа продлится до конца 2025 года, и мы подробно расскажем и о ней.
Надеюсь, было интересно и познавательно. Буду рад ответить на вопросы о наших технических решениях.
- цод
- втб
- ситуационный центр
- облако
- надежность
- непрерывность
- надежность данных
- непрерывность бизнеса
- надежное хранение
- ит-инфраструктура
- Блог компании ВТБ
- IT-инфраструктура
- Облачные вычисления
- Сетевые технологии
- Инженерные системы
Сбербанк борется со сбоями и завершает централизацию
Сбербанк начал программу реструктуризации IT довольно давно, но «учить слона танцевать» оказалось непросто и с технологической точки зрения — в работе банка случались масштабные технические сбои — и в 2011, и в 2012 годах. С неспособностью обеспечить требуемую надежность многие связывают вывод из правления Виктора Орловского, после чего курировать IT назначили отвечающего за риски Вадима Кулика. В сентябре 2013 года Сбербанк привлек на должность старшего вице-президента по IT Никиту Волкова, до этого 21 год проработавшего в одном из крупнейших банков Украины — ПриватБанке.
На встрече с журналистами 21 января Никита Волков рассказал, что было сделано в Сбербанке для обеспечения надежности IT и бесперебойности его работы. Прежде всего, интересно решение проблемы с авторизацией платежей, о которой еще летом 2012 года говорил сам Герман Греф — тогда после нескольких длительных перерывов в обслуживании карт глава Сбербанка пообещал, что будут предприняты все усилия, чтобы такая ситуация не повторилась — в частности, он говорил о возможности офлайн-авторизации операций по картам на случай, если системы Сбербанка на какое-то время выйдут из строя.
Теперь же в Сбербанке, по словам Никиты Волкова, реализована схема stand-in — введена дублирующая система, которая всегда имеет актуальные остатки по картам, и, соответственно, всегда может авторизовать покупку или перевод. Эта система поддерживает работу и в периоды технологических обновлений. При этом если раньше она не обеспечивала поддержку карт в «Сбербанк Онлайн», то вскоре и эта проблема будет устранена.
Новая масштабная программа по повышению надежности была открыта в 2013 году. Главный IT-архитектор Сбербанка Андрей Хлызов говорит, что ее задача — повысить доступность всех систем до «четырех девяток», то есть системы должны быть доступны 99,99% времени — допустим простой не более 52 минут в год. До начала программы, по словам Андрея Хлызова, доступность составляла не ниже 99,5%.
На постоянной основе в программе повышения надежности задействованы более 1 тыс. сотрудников банка. Планировалось, что программа займет три года, однако поскольку в нее постоянно добавляются новые системы, теперь в Сбербанке рассчитывают, что на реализацию уйдет еще один дополнительный год. Результаты будут заметны для клиентов: к примеру, если сейчас в «Сбербанк Онлайн» деньги со вклада ночью снять нельзя, то теперь это будет возможно.
Уже сейчас, спустя полтора года работы программы, как рассказывает Андрей Хлызов, суммарное время простоя критичных систем банка сократилось в четыре раза, время простоя при проведении технических работ — в 2,5 раза, а количество инцидентов в системах — в 2,4 раза.
Никита Волков, старший вице-президент по IT
и Андрей Хлызов, главный IT-архитектор Сбербанка
При этом нагрузка на системы за это время существенно возросла. Для розничного интернет-банка количество осуществляемых транзакций возросло почти в шесть раз — 20 млн его активных клиентов сейчас могут осуществлять 3,7 млн транзакций в день. В корпоративном интернет-банке нагрузка выросла почти в четыре раза — 1,2 млн клиентов и 1,5 млн транзакций в день максимум. Нагрузка на процессинг выросла почти в два раза — у Сбербанка сейчас 125 млн карт и 750 тыс. POS-терминалов, в день он может обрабатывать 54 млн карточных транзакций.
Повышенное внимание уделяется резервированию. Для дублирования систем банк сейчас арендует коммерческие ЦОД, но в 2016 году все-таки обещает построить второй МегаЦОД — в Сколково, причем мощность его будет выше, чем у существующего ЦОДа «Южный порт» — 32 МВт против 20 МВт.
Еще более масштабна проводящаяся в Сбербанке с середины 2011 года программа централизации, которая должна завершиться летом текущего года. В ней, по словам Андрея Хлызова, приняли участие 32 тыс. человек. При этом с точки зрения сокращения затрат программа оказалась очень эффективна — она окупилась уже на второй год, даже если не считать дополнительные доходы, которые получил бизнес.
Буквально в новогодние праздники в программе централизации состоялось весьма значимое событие — Сбербанк, наконец, полностью централизовал свою розничную АБС. Как утверждают в банке, это вторая по величине в мире система — после китайского ICBC. Централизация же корпоративной АБС все еще продолжается — пока в МегаЦОД перенесены лишь системы десяти территориальных банков, к ним предстоит добавить еще шесть.
Доступ к системам с рабочих мест тоже централизован — все они работают на базе «тонких» клиентов, то есть через браузер, что существенно для обеспечения мобильности сотрудников. Чтобы это стало возможным, Сбербанку пришлось провести большую работу и в обеспечении хороших каналов связи — к примеру, в восточной части России пришлось перейти на другой спутник.
Но главным результатом программы централизации Андрей Хлызов считает создание «колоссальной мощной команды». Такая команда Сбербанку действительно нужна — ведь если в 2011 году в нем велось около 200 IT-проектов, то сейчас их уже более 600. При этом значительные изменения претерпела не только IT-архитектура, но и операционная модель. К примеру, у каждого из бизнес-направлений — розничного, корпоративного, инвестиционного и т.д. — теперь есть свой IT-офис. На такую модель управления IT банк перешел в 2014 году.
Диспетчерский центр ЦОД «Южный порт»
Разразившийся кризис, как говорит Никита Волков, несущественно повлияет на работу IT-службы Сбербанка: «Мы разработали конкретные мероприятия и собираемся их выполнять». Однако он не отрицает, что ряд не самых приоритетных проектов — до 10% бюджета— может быть сдвинут с 2015-го на 2016 год.
Вопросом импортозамещения в Сбербанке, по словам Никиты Волкова, занимаются, однако понимают, что критические системы, такие как СУБД, заменить просто нечем — здесь, скорее, наоборот, идет перевод всей инфраструктуры на продукты стэка одного американского производителя. При этом руководитель IT-блока уверяет, что условия работы этих систем таковы, что никакие изменения не могут быть внесены извне — у Сбербанка все под контролем.
Самым инновационным, как следует из слов Никиты Волкова, столь крупный банк не может быть по определению. «Мы не стремимся быть первыми, но ставим задачу быть вторыми», — говорит он. То есть Сбербанк не хочет в ущерб надежности внедрять что-то раньше других, но, по словам IT-руководителя, если в банке видят работающую новую технологию, причем не только в России и не только в банковской сфере, то стараются ее внедрить в течение трех-шести месяцев.
