Эксперты CIO Club об «аварии» в Uzcard

119

15 сентября в работе системы Uzcard произошел сбой, из-за которого стали недоступны транзакции в течении нескольких дней. Это беспрецедентный случай, когда держатели карт в течении долгого времени не имели доступа к своим средствам.

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

Официального заявления о причинах сбоя в системе пока нет. Но эксперты CIO Club уже поделились своим мнением по поводу произошедшего.

Ахадбек Далимов, IT-консультант:

ЦБ должен разработать требования единые для всех. Например, в той же Украине ЦБ предписал всем банкам иметь резервную площадку, не указывая где и как они это будут делать. Были также предъявлены требования к этому резерву для того, чтобы бизнес не страдал.

В ЕОПЦ вышла из строя система IBM на front-end. Неправильная архитектура привела к тому, что неисправный диск в системе хранения данных повредил один из блоков в базе данных, что синхронизировалась на все системы хранения данных. В итоге было принято решение поднять бекап на тестовом оборудовании без standby (режима ожидания до последующего включения). Но утром выяснилось, что это ошибка возникла и на тестовом оборудовании. Сейчас удалось обойти ошибку и открыть базу. Ребята создали новую базу и копируют критические данные.  Ситуация осложнилась тем, что это произошло в конце недели, у них не было никакой техподдержки. Несмотря на это была создана рабочая группа из специалистов, которые помогают решить этот вопрос, хотя проблема не касается БД и приложения.

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

Александр Стеклянов, IT-директор UMS:

У Uzcard «упал» Oracle. Сами поднять не смогли, техподдержка не куплена в итоге кейс не завести. Наверно лучше не спрашивать тестировали ли restore. Ответ итак известен. Но у меня рука не поднимется сходу обвинить IT-администраторов. Видимо им просто было не на чем протестировать этот restore.

Антон Ракитский, начальник отдела ИБ IT-TEAM SERVICE:

У Центрального банка есть требования в части непрерывности, доступности и ИБ в целом. Их выполнение постоянно проверяют (головная боль для банков). Но распространяются они только на их лицензиатов (банки, ломбарды). Наверное, всё изменение в НПА будет заключаться в том, что платёжные системы тоже будет лицензировать Центральный банк.

Полноценный (с уведомлением о результате VISA, MasterCard и т.д.) аудит PCI DSS возможен же только для международных платежных систем, входящих в совет PCI SSC (вряд ли ЕОПЦ в него входит). То есть если аудит и проводился, то на каком-то отдельном тестовом сегменте. Не факт, что вся «боевая» инфраструктура вошла в область такого аудита.

Тимур Эмирсалиев, CIO АКБ «Капиталбанк»:

У Центрального банка есть определенные меры к банкам. Если ЕОПЦ попадет в зону действия, то я больше чем уверен, они серьезнее будут относится к таким сбоям. Со стороны контролирующего органа должны быть специалисты, которые будут проводить аудит соответствующей компетенции.

Ренат Ахтямов, директор проектов в ООО «Единый интегратор Uzinfocom»:

Если бы вышел из строя диск, то поднялись бы на резервном ЦОДе. Раз ошибка воспроизвелась на резерве, значит сбой произошел на уровне ПО и произошло повреждение файлов баз данных. Если в компании отсутствует change managment (управление изменениями), то это приводит к очевидным последствиям. Заявки о проблемах уже отправлены вендорам, но вполне возможно, что ответ вендора будет звучать так: «Не пропатчили своевременно».

Надирабегим Муратова, генеральный директор консалтинговой компании Ishonchli Davolash Amaliyot:

Падение системы было ожидаемо. Во многих банковский учреждениях нет четких должностных инструкций, не говоря уже о риск менеджменте. Например, летом к нам обратился один банк. Его обязали внедрить ISO 9001, хотя у банков должен быть свой стандарт управления. После проведения аудита по документам и процессам было выявлено отсутствие системы предупреждения рисков как в плане оборудования для электронного банкинга, так и процессов.

Как быть?

В критически важных организациях подобные случаи не редкость. Вся проблема в том, что их IT-структуры не всегда отвечают требованиям и не просчитывают возможные угрозы. Что же необходимо предпринять для предупреждения таких проблем?

Саид Махлуфи, технический директор Somrant Tech Investment:

Необходимо выполнять полное бекапироварие не только баз, но и всей системы в целом, в двух версиях, и на разных носителях. Постоянно следить за актуальностью обновлений данных баз backup, систем безопасности и обновлять ПО до актуальных версий и устанавливать патчи на сервера и СХД. Не обойтись и без резерва «железа» как полностью, так и запчастей (hdd, fan, ddr) и т.д. Никто не отменял виртуализацию, где backup делается очень просто, а снимки виртуальной машины можно хранить не только на одном железе, но и в других местах.

Андрей Афанасьев, архитектор IT-решений «Sharifa COM»:

Если говорить про требования к системе уровня UzCard (если это Oracle), то можно воспользоваться такими решениями:

Продуктив (сама система) на базе RAC (сервера или exadata) — основная система хранения данных (СХД) с высокой доступностью; Dataguard (защита данных) на резервном сервере плюс отдельная СХД, а также сервер достаточный для работы всего функционала; резервное копирование в стандартном режиме на диски, потом на удаленный ленточный накопитель; система препрода (pre-prodaction) для периодического восстановления backup и обкатки обновлений и патчей. Оптимальное решение — купить полноценную систему типа NonStop.

Необходимо на глобальном уровне делать общий аудит систем на наличие резервирования как фронта, так и бэка. Я думаю, что у половины банков нет системы резервирования. Я говорю именно про standby систему с актуальной копией базы. Также можно подумать над тем, чтобы сделать процессинг Uzcard распределенным с 3-4 опорными центрами, которые будут владеть всей информацией.

К сожалению, они экономят абсолютно на всем, не только на серверах и СХД. Камеры, виртуализация, бекапирование. И это явление наблюдается везде.

Умид Набиев, заместитель директора департамента розничных операций в НБУ:

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

Шухрат Курбанов, независимый банковский консультант:

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

Да, с одной стороны друг друга надо выручать. Но у людей появляется твердое убеждение, что если даже экономить и работать спустя рукава, то всегда найдутся те, кто решит твою проблему.

В скором времени появиться государственный ОПЦ. Но если он будет построен по тому же принципу централизации ситуация не измениться. Необходима децентрализация: у каждого банка свой процессинг, или один на несколько банков. Пусть строят Host-2-Host между собой.

Главные выводы уже есть, особенно для банков, которые сидят с лицензиями Oracle на 4 ядра и без техподдержки.

Ахадбек Далимов, IT-консультант:

После такого фиаско нужно думать о полном резерве, в особенности для таких систем. Альтернативой строительству своих резервных центров может стать заказ резерва в ЦОД или облаке. Но и с ЦОДами у нас беда, а с облаками беда в кубе. И даже если все DBA (Database administrator) от Фидо будут пытаться что-то сделать, то без системщика, инженера по сторожам (особенно сторевайзам) и сетевому оборудованию не обойтись.

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

Прежде всего нужно менять ситуацию на законодательном уровне и прописывать все необходимые правила и сценарии рисков. Совсем недавно было объявлено о создании Национального межбанковского процессингового центра, который позволит избежать подобные ситуации. Также будет разработан законопроект «О платежах и платежных системах». Как будет развиваться сфера и как вынужденное решение о создании национального ОПЦ повлияет на сферу в дальнейшем пока еще не ясно. Но понятно одно — необходимо быть готовым к проблеме еще до ее появления и менять отношение к работе финансовых IT-структур. Этот случай с Uzcard не должен стать нормой и оправданием последующих подобных ошибок.

ОСТАВЬТЕ КОММЕНТАРИЙ: