НовостиСобытияКонференцииФорумыIT@Work
Идеи и практики автоматизации:

Блог

Равнение -- на Сбербанк!

Сергей Бобровский
10.07.2012 10:44:02

В ситуации с компьютерным сбоем в Сбербанке я лично никакого негатива не вижу. К таким событиям сегодня следует относиться как к неизбежности, непредсказуемым природным катаклизмам. В подобных организациях ИТ-инфраструктура столь сложна (и увы исторически столь запутана, а в данном случае, еще и несет немеряный груз тормознутой государственной финансовой мега-системы), что полностью избавиться от технических сбоев вряд ли возможно в обозримом будущем (по крайней мере, до технологической сингулярности и появления AGI).

Из-за программных ошибок ракеты еще долго будут падать, АЭС -- взрываться, роботы -- вести огонь по своим, а банки -- приостанавливать обслуживание. Какое-то особо грамотное проектирование не поможет, потому что задействовано слишком много софта сторонних фирм, по определению содержащее множество ошибок, да и немало работ отдается на аутсорсинг. Теоретически можно наращивать дублирование функций, однако помогает это скорее в горизонтальных системах типа Google, где функциональность можно "размазать" по сотням тысяч серверов, а в схемах, где задействовано тяжелое серверное оборудование и не менее тяжелый централизованный OLTP-софт, дублирование может лишь повысить общую сложность…

Сколько лет эксплуатировалась Windows XP огромным количеством пользователей, и то ошибки в ней находятся и по сей день. Для разнообразия можно также почитать текущий багтрекер Линухи. В конце июня из-за очередной ошибки в ядре Linux засбоили серверы Mozilla, Reddit, LinkedIt, вышла из строя и одна из крупнейших в мире систем резервирования мест на полеты австралийской Amadeus Altea. Хорошо еще, самолеты не упали.
А чуть ранее был найден баг Linux, который может портить информацию на RAID-массивах. А ведь сбербанковский кластер СУБД уже не раз останавливался "по причине сбоя в работе синхронизации данных между RAID массивами геокластера". Не находите связи, пусть и конспирологической?

В 2010-м, кстати, встали на три дня онлайновые сервисы JP Morgan Chase из-за бага в СУБД Oracle. Проблемы, судя по всему, начались в системе аутентификации на базе Oracle, причем система эта, несмотря на свою ключевую важность для банка, была отдана на аутсорсинг…

А вот оперативная реакция Сбера на это событие заслуживает самой позитивной оценки. Почитайте обсуждение этого сбоя:

Вот техническое описание причины:
"Oracle пишет логи в онлайн журналы, которые затем автоматически (типа FIFO буфера) сбрасываются на диски. Таким образом, журналы никогда не переполняются. По какой - то причине (пока не понятно по какой) СУБД перестал удалять события из журналов. После чего не прошел один из checkpoint-ов в системе и она перестала отвечать на действия администратора. Систему перевели на резервный комплекс и запустили recovery базы. Recovery остановился посередине пути и не был завершен. После чего возобновили Recovery процедуру, но уже в полуручном режиме, убрав параллельную (многпроцессорную) обработку. Поэтому получилось долго (последовательная обработка recovery и большой объем данных в требующих "наката" в базу)".

Вот одно из возможных объяснений:
"Не умеет универсальная база одновременно работать с миллионами коротких авторизационных запросов (есть деньги/нет денег) и с небольшим количеством, но длительных по обработке запросов из back-office (например расчет процентов по остаткам). Такие системы сравнительно дешевы, хорошо подходят для небольших/средних банков. Так же они хороши для построения гибких бизнес процессов, но не выдерживают объемов".

Виктор Орловский, член правления Сбербанка, старший вице-президент -- руководитель блока "Информационные Технологии" (фактически CIO Сбербанка) корректно объясняет на форуме сбой, обсуждает, консультируется. Более того, приглашает к обсуждению всех специалистов, и даже корпоративные логи готов выложить для анализа!

Вы встречали когда-нибудь подобную открытость ИТ-кухни крупнейших российских организаций? Будь я президентом, smile:) сделал бы Орловского министром связи.

Что касается причин подобных сбоев и их профилактики, то главная пожалуй -- это повсеместная нехватка спецов.

Комментариев: 5

Только зарегистрированные и авторизованные пользователи могут добавлять комментарии

10.07.2012 12:00:20

"Почитайте обсуждение этого сбоя: ..."

Вот это обсуждение этого сбоя почитать еще интереснее http://www.sql.ru/forum/actualthread.aspx?bid=3&tid=953904&pg=1

10.07.2012 14:44:36

Я полностью согласен с точкой зрения Сергея, сам уже писал по этому поводу в собственных комментариях по этому поводу.
Отдельно хочу подчеркнуть, что данные случай, как ни странно, демонстрирует высокую надежности ИТ. По сравнению, с "традиционными" методами.

11.07.2012 00:57:08

>>"Перевод системы на резервный комплекс не дал ожидаемых результатов, - заявили в банке

Потому что такой перевод надо делать не однократно после наступления аварийной ситуации, первый раз за долгий период, а периодически, когда система вполне работоспособна, чтобы гарантировать работоспособность горячей резервной копии системы. Этого не делалось. "Зеркало" системы не должно ничем отличаться от основной системы, и периодически они должны "меняться местами", т.е. осуществляться переключения между ними.

Пока гром не грянул, никто не крестился. А надо было. И не говорите мне, что такие масштабные сбои это нормально. Это ненормально.

11.07.2012 11:16:44

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

11.07.2012 13:54:07

Ну, если под фразой "сбой отнюдь не системный, как его пытаются представить" понимать, что сбой вовсе не связан с ошибкой функционала логов Oracle, как про то пишут, то я согласен.
Сбой связан с отсутствием системной процедуры проверки работоспособности резервной копии системы. Рабочая версия системы рано или поздно даст сбой по самым разным причинам (отказ оборудования и т.п.) и резервная копия системы или ее подсистем должна быть в гарантированно работоспособном состоянии. А именно это и не проверялось.

Только зарегистрированные и авторизованные пользователи могут добавлять комментарии