Вместо эпиграфа:
Пускай слыву я старовером,
Мне всё равно, я даже рад.
Пишу я Гоблина размером,
Пою, друзья, на старый лад
(почти М. Ю. Лермонтов)
Итак,
— Что же произошло с процессингом Сбербанка?
— Произошла ошибка СУБД Oracle, приведшая к остановке экземпляра.
— Что за странные вещи написал вице-президент банка? Какое ещё удаление событий из журналов?
— Обратите внимание, комментарий написан далеко заполночь, и не на специализированном ресурсе типа sql.ru, и не администратором Oracle, а вице-президентом. Странно в такой ситуации ожидать глубокого технического описания. Тем не менее, описание достаточно точное. Чуть ниже будут технические подробности — попробуйте сформулировать «для простого народа» понятнее, чем это получилось у Орловского.
— Ну, давай уже технические подробности!
— Журнал повторного выполнения Oracle реализован в виде кольцевого буфера. В «голову» процесс LGWR пишет новые изменения в БД, а «хвост» подчищается процессом CKPT по мере того, как изменения, записанные в «хвосте» будут записаны процессами DBWn в файлы данных. «Голова» — это текущий (current) файл журнала, хвост — активные (active) файлы. Подчистка хвоста заключается в том, что журналы помечаются как пригодные к повторному использованию (inactive). Проблема состояла в том, что «подчистка» прекратилась, т.е. все файлы оперативного журнала стали активными, и экземпляру БД стало некуда записывать новые изменения.
— И что, у такой важной базы нет работоспособного резервного узла?
— Есть, но в данном случае он оказался бесполезен, т.к. все ошибки отреплицировались на резервный узел байт-в-байт. В таких случаях низкоуровневая копия (репликация на уровне СХД или standby-база) бесполезны, помочь может только прикладная репликация. Производительности IBM InfoSphere CDC for Oracle Replication не хватило, чтобы реплицировать такую базу. GoldenGate на ней пока не тестировали. Самым правильным был бы вариант, когда приложение само пишет данные в несколько баз одновременно, но много ли вы знаете приложений, способных на это?
— А почему у Сбербанка нет контракта на поддержку с Oracle?
— Контракт есть. То ли premium, то ли platinum, то ли что-то такое, круче чего только Эверест в безлунную ночь. Собственно, специалисты Oracle помогали решать проблему. Поверьте, три часа для восстановления сервиса при такой аварии — не так уж много.
— Как же так — такая база и без RAC!
— RAC — вовсе не панацея. Например, компания ЦФТ, один из ведущих производителей банковского ПО в России, адаптировала свои приложения для Exadata. При этом официально заявляется, что предыдущие версии ПО на Exadata работать не будут, т. е. ПО требует существенных доработок даже для лучшей реализации RAC, не говоря о «наколенных» сборках. ПО Way4 для RAC пока не адаптировано, хотя работы идут. И скорость этих работ зависит не только от Сбербанка.
— Наймите, наконец, нормальных администраторов!
— Администраторы в Сбербанке хорошие. Но они, увы, не волшебники.
— А вот в PostgreSQL можно было бы исправить все баги самому, не дожидаясь милости от поставщика!
— Не поверите, но настройка производительности БД, резервное копирование, сайзинг оборудования и т. д. — это совсем иной набор навыков и компетенций, чем написание достаточно низкоуровневого кода. Поэтому даже Postgres приобретается большими компаниями в виде EnterpriseDB или GreenPlum.
— На металинке давно можно найти решение любой проблемы!
— Вы никогда не обращали внимания, что описание проблемы сопровождается подробным описанием конфигурации оборудования, версии, ОС… инсталляция Oracle, используемая в процессинге Сбербанка, по-своему уникальна: серверов IBM P795 в полной конфигурации в мире не так много. Поэтому патча может и не быть. Сам сервер был выпущен только в октябре 2010 года, поэтому период «детских болезней» ещё не прошёл. Так что весьма вероятно (и есть ряд косвенных признаков, указывающих на это), что ошибка не в Oracle, а в AIX.
— Ну, заведите SR, и вам тут же выпустят патч!
— Посмотрите на том же металинке историю патчей. Когда проблема выявлена, когда подтверждена, когда решена. В 24 часа это не укладывается никогда.
— Но почему же в других банках ничего не падает!
Во-первых, в других банках вместе взятых карт почти столько же, сколько в одном Сбербанке. Поэтому процессинговые системы работают с меньшей нагрузкой на более простом оборудовании. А во-вторых, буквально на следующий день после обсуждаемого сбоя мой коллега весь день не мог совершить ни одной операции по карте банка «А...». Но кому это интересно?
— Да у Сбербанка банкоматы работают под Windows, о какой надёжности тут вообще можно говорить?
Банкоматы к процессингу не имеют вообще никакого отношения. Управление банкоматами и POS-терминалами в Сбербанке возложено на другую систему. Которая, кстати, во время пятничного сбоя продолжала работать, позволяя креативному классу отовариваться айфонами в бутиках по картам других банков. Ну, и в других банках банкоматы, очевидно, работают под управлением совсем других операционных систем. Да и сами банкоматы производятся на других заводах. Очевидно, эльфами :)
— Как-то подозрительно быстро у Сбербанка обнаружилась площадка для обсуждения причин аварии!
— Сбербанк старается следить за модными тенденциями. Сегодня «краудсорсинг», «социальные сети» и прочий «вебдваноль» для имиджа банка не менее важны, чем надёжная работа основных систем. Отсюда и готовая площадка для обсуждения.
— Видать совсем не осталось специалистов, раз обратились к «коллективному разуму». Да и кто заплатит «коллективному разуму» за решение проблемы?
— Насколько я понимаю, цель другая: специалист, увидев логи, поймёт, что имеет место действительно серьёзная проблема. Неспециалист, получив возможность высказаться, польёт Сбербанк помоями — да ради б~га, «собака лает — караван идёт». Ну, и беспокоиться о том, что в открытый доступ попадёт больше информации, чем можно, не надо. Вся информация проверяется.
Автор: hard_sign
