Вчера утром метким ударом молнии был полностью выведен из строя датацентр в Дублине,  в котором размещаются все мощности Amazon AWS, обеспечивающие европейскую зону, а также Microsoft’s Business Productivity Online Standard Suite.

Несмотря на наличие резервирования по питанию, удар молнии и последовавший за ним взрыв на трансформаторной подстанции вывел из строя не только основную систему электроснабжения, но и резервные генераторы. В результате,электроснабжение удалось восстановить через 3 часа, но такое жесткое выключение ЦОДа привело к необходимости серьезного ручного вмешательства при восстановлении серверов. На момент написания этого текста процесс восстановления продолжался, и, по оценке Amazon, может занять 24-48 часов.

Неприятной особенностью данного сбоя AWS оказалось то, что те европейские пользователи AWS, которые по требованиям законодательства не могут хранить свои данные за пределами EU, оказались лишены возможности перенести свои приложения в другие ЦОДы Amazon — это был единственный ЦОД европейской зоны.

Возможно, это событие заставит многих пересмотреть оценку надежности облачных провайдеров и задуматься о необходимости резервирования наиболее критичных приложений в облаках альтернативных провайдеров. Учитывая модель ценообразования для облаков, эта задача может оказаться менее затратной, чем в «дооблачном мире», т.к. резервная инфраструктура, хотя и требует существенных объемов для хранения данных, но может оказаться существенно дешевле в части аренды вычислительных мощностей в «мирное время».

Update 1. По уточненной информации, недоступна была только часть европейской availability zone. См. также историю о том, как поднимались коллеги из Битрикса, расположенные на этой площадке.

Реклама

BCaaS… очередной «as a Service». Не факт, что именно под таким названием, но то, что анонсировал SWIFT на этой неделе, может вскоре стать популярным трендом. Итак, о чем же речь?

SWIFT пообещал в течение двух ближайших лет запустить сервис под названием MIRS (Market Infrastructure Resiliency Service), ориентированный на операторов Системы валовых расчетов в реальном времени (RTGS, Real Time Gross Settlement). Цель сервиса — обеспечить работу операторов RTGS, в первую очередь центральных банков, в случае масштабной ЧС, которая выведет из строя все площадки оператора.

По сути своей — это разделяемый сервис. На площадке SWIFT будет организован хостинг типовой системы RTGS, доступ к которой будет в час Х предоставлен именно тому банку, который подвергся воздействию ЧС. Как и с любым разделяемым сервисом, это обойдется конечному потребителю дешевле, чем создание своей выделенной резервной инфраструктуры  (хотя в данном случае, это будет, скорее, 3-я резервная площадка). Понятно, что дьявол в деталях, и есть масса подводных камней, связанных с безопасностью, кастомизацией и проч., но сама идея, как мне кажется, неплоха.

Интересно в данном предложении то, что оно исходит не от компании-поставщика услуг по хостингу/аварийному восстановлению, а от сервис-провайдера. Продолжая эту аналогию — операторы связи могут предлагать своим клиентам резервные решения по защите периметра или контентной фильтрации, налоговая — сервис по сдаче отчетности, и т.п. Google, например, уже предлагает услугу по аварийному восстановлению корпоративных exchange серверов на Gmail.

Эту тему мы еще будем активно обсуждать в рамках секции «Непрерывность бизнеса и облака» на InfoSecurity Russia 29 сентября, так что добро пожаловать.

Сегодняшний день ознаменовался серьезным ЧП для Tele2-Латвия, крупнейшего в Латвии оператора, обслуживающего в этой стране  более 1.1 млн. абонентов. По поступающим новостям Латвийских информационных агентств, начиная с 14:30 (15:30 МСК) не работает полностью вся сеть оператора.

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

Так что ждем новостей, следим за апдейтами…

Update 1. (18:30 МСК). Судя по всему, prepaid-платформа в Риге обслуживала также абонентов Эстонии и Литвы. Эстония поднялась в течение 20 минут, про Литву информации нет. Общее число затронутых аварией абонентов — превысило 2 миллиона.

Update 2. (18:40 МСК). Начали приходить сообщения о восстановлении работы сети.

Три дня заняло у Amazon разрешение проблем с доступностью сервисов EC2 и RDS в одной из зон, North Carolyna.

Amazon Web Services StatusК размышлению о том, как резервировать облачные сервисы — в разных зонах, у разных провайдеров, в частных облаках….

Похоже, что нет. По-крайней мере, готовы хуже, чем были три года назад…

Forrester Research опубликовал отчет «Wake-Up Call: You Aren’t Ready For A Disaster», посвященный оценке уровня подготовленности организаций к наступлению чрезвычайной ситуации. Не то, чтобы все было совсем плохо, но цифры четко свидетельствуют — кризис и сопутствующее сокращение затрат не прошли даром. Основные проблемные области, в которых зафиксировано ухудшение  — актуальность планов и их регулярное тестирование. Если в 2007 тестировали свои планы чаще, чем раз в год, 58% организаций, то в 2010 это число снизилось до 42%. В результате, например, по факту случившихся чрезвычайных ситуаций процент организаций с нулевым фактическим временем восстановления  снизился с 30% до 13%.

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

 

Как многие из вас наверное слышали, в этом году LinkedIn выходит на IPO. В соответствии с требованиями законодательства, LinkedIn направил в Комиссию по ценным бумагам (US Securities and Exchange ComissionStatement of registration for an Initial Public Offering — документ, который достаточно любопытен сам по себе для тех, кто желает поближе познакомиться с бизнесом компании.

Но в контексте нашего блога интерес представляет заявление LinkedIn, касающееся рисков, связанных с непрерывностью бизнеса. Read the rest of this entry »

Расширяя свои облачные сервисы на базе Postini, Google предложила рынку решение по защите (в смысле обеспечения непрерывности) почтовых сервисов, построенных на базе Microsoft Exchange. Обеспечивая постоянную репликацию содержимого Exchange Server на свои сервера, Google позволяет сотрудникам организации в случае сбоя Exchange переключиться на Google Mail, в котором уже будет находиться вся корпоративная почта, контакты и календарь. Да, интерфейс Google Mail будет отличаться от привычного интерфейса Exchange, но, на мой взгляд, с этим можно смириться в условиях ЧС. В качестве дополнительного бонуса организация получает все функции Google Message Security. IMHO, можно рассматривать как опцию при построении стратегии обеспечения непрерывности ИТ-сервисов.

%d такие блоггеры, как: