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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Но в контексте нашего блога интерес представляет заявление LinkedIn, касающееся рисков, связанных с непрерывностью бизнеса.

В разделе «Факторы риска» LinkedIn абсолютно честно пишет (выделение мое):

We recently implemented a disaster recovery program, which allows us to move production to a back-up data center in the event of a catastrophe. Although this program is functional, it does not yet provide a real-time back-up data center, so if our primary data center shuts down, there will be a period of time that the website will remain shut down while the transition to the back-up data center takes place.

Our systems are also vulnerable to damage or interruption from catastrophic occurrences such as earthquakes, floods, fires, power loss, telecommunication failures, terrorist attacks and similar events. Our U.S. corporate offices and certain of the facilities we lease to house our computer and telecommunications equipment are located in the San Francisco Bay Area and Southern California, both regions known for seismic activity. Despite any precautions we may take, the occurrence of a natural disaster or other unanticipated problems at our hosting facilities could result in lengthy interruptions in our services.

We do not carry business interruption insurance sufficient to compensate us for the potentially significant losses, including the potential harm to the future growth of our business that may result from interruptions in our service as a result of system failures.

О чем нам это говорит?

Во первых, полезно знать, что в цивилизованном мире об этом принято говорить. Поэтому если вы планируете выводить свою компанию на IPO, у вас появляется еще один аргумент в пользу правильно построенной системы непрерывности бизнеса.

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

Отчет целиком можно загрузить с сайта SunGard.