[spoiler]Из-за программных ошибок ракеты еще долго будут падать, АЭС -- взрываться, роботы -- вести огонь по своим, а банки -- приостанавливать обслуживание. Какое-то особо грамотное проектирование не поможет, потому что задействовано слишком много софта сторонних фирм, по определению содержащее множество ошибок, да и немало работ отдается на аутсорсинг. Теоретически можно наращивать дублирование функций, однако помогает это скорее в горизонтальных системах типа 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 Сбербанка) корректно объясняет на форуме сбой, обсуждает, консультируется. Более того, приглашает к обсуждению всех специалистов, и даже корпоративные логи готов выложить для анализа!
Вы встречали когда-нибудь подобную открытость ИТ-кухни крупнейших российских организаций? Будь я президентом,
сделал бы Орловского министром связи.Что касается причин подобных сбоев и их профилактики, то главная пожалуй -- это повсеместная нехватка спецов.
Потому что такой перевод надо делать не однократно после наступления аварийной ситуации, первый раз за долгий период, а периодически, когда система вполне работоспособна, чтобы гарантировать работоспособность горячей резервной копии системы. Этого не делалось. "Зеркало" системы не должно ничем отличаться от основной системы, и периодически они должны "меняться местами", т.е. осуществляться переключения между ними.
Пока гром не грянул, никто не крестился. А надо было. И не говорите мне, что такие масштабные сбои это нормально. Это ненормально.
Сбой связан с отсутствием системной процедуры проверки работоспособности резервной копии системы. Рабочая версия системы рано или поздно даст сбой по самым разным причинам (отказ оборудования и т.п.) и резервная копия системы или ее подсистем должна быть в гарантированно работоспособном состоянии. А именно это и не проверялось.