Основные сбои в работе облачных сервисов в 2012 году, и какие выводы из этого можно извлечь

    Исходя из недавнего отчета IWGCR (International Working Group on Cloud Computing Resiliency) каждый год сервисы облачных вычислений недоступны, в среднем, в течение 7.5 часов. Компании, которые частично или полностью используют облака для своих приложений и сервисов, в этом году пострадали несколько раз. Давайте рассмотрим самые большие отказы в работе облачных сервисов в 2012 году.

    Microsoft Windows Azure
    Самый большой и обширный сбой Microsoft Windows Azure был в феврале, он затронул все географические локации, полное восстановление работоспособности сервиса длилось более 24-х часов. Microsoft заявил, что сбой вызван ошибкой в программном обеспечении связанной с неправильным вычислением времени и даты для високосного года. Проблема вызвала гневную реакцию со стороны пользователей сервиса, которые ожидали большего освещения проблемы и большей коммуникации со стороны Microsoft.
    В июле сервис облачных вычислений Microsoft Azure снова был недоступен, на этот раз в западной Европе, продолжительность отказа была 2.5 часа. Причина была в неправильно сконфигурированном сетевом устройстве, что повело за собой проблемы с подключением пользователей.
    Позднее осенью случился еще один сбой, связанный с работой Office365, во время которого были недоступны миллионы почтовых ящиков пользователей.

    Amazon Web Services
    Сбой питания Amazon Web Services в Июне отрезал пользователей от необходимых сервисов на 6 часов. Пострадали сервисы: Amazon Elastic Compute Cloud, Amazon Relational Database Service и AWS Elastic Beanstalk находящиеся в регионе U.S. East в датацентре Виржинии. Кроме этого пострадали компании предоставляющие сервисы по управления облаками и провайдеры PaaS такие, как: Stratalux, Digitaria, Heroku и сервис PaaS предоставляемый Salesforce.com. Популярные сайты: Netflix, Pinterest, Reddit, Forsquare и Instagram также пострадали из-за этого сбоя.
    Меньше чем через месяц случился второй сбой в работе AWS, после чего один из крупных клиентов публично заявил о том, что он прекращает пользоваться услугами Amazon и вынужден искать альтернативные варианты.

    Apple iCloud
    В сентябре большое количество пользователей этого облачного сервиса не могли получить доступ к своим почтовым ящикам. Проблема была связана с центральной службой iCloud, так что она была общая как для пользователей компьютеров под управлением Mac OS, пользователей iOS устройств так и для пользователей использующих Web интерфейс iCloud.com.

    Google Gmail
    В этом году сервис Google Gmail потерпел больше сбоев, чем в прошлом. Первый сбой произошел в апреле и длился один час. Проблема задела менее чем 10 процентов пользователей, основная причина была в неправильном конфигурировании при выполнении рутинной операции по обновлению системы. Второй сбой произошел в июне и задел менее чем 1.5 процента пользователей.

    Заключение
    Несмотря на все меры предосторожности, которые предпринимают провайдеры облачных сервисов, перебои в работе случаются регулярно по разным причинам, таким как человеческие ошибки, технические сбои или стихийные бедствия. Но это не повод отказываться от облаков. Все эти факторы могут контролироваться при помощи всеобъемлющего плана по аварийному восстановлению и такого же плана по отказоустойчивости. Со временем надежность облачных платформ будет расти, и отказоустойчивость будет стремиться к 100% (реальным, а не заявленным отделом маркетинга). Рано или поздно железный хостинг будет вытеснен облачным.

    Оригинал статьи: www.rickscloud.com/major-cloud-outages-of-2012-to-learn-from
    Автор: Rick Blaisdell
    Поделиться публикацией
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 11
    • +1
      Забыли про сбой Google Sync habrahabr.ru/company/apps4all/blog/162291/
      • +5
        Пост ниочём
        • +5
          Коммент ни о чем.
          • 0
            Если есть каике-то замечения по поводу статьи, что в ней не так, чего не хватает и так далее, милости прошу освещать это в комментариях. Критика должна быть конструктивной.
          • +3
            Все эти факторы могут контролироваться при помощи всеобъемлющего плана по аварийному восстановлению и такого же плана по отказоустойчивости.

            Всего не предусмотреть. Факап всегда найдет чем удивить. Растет сложность систем, и, соответственно, растет число гипотетических событий, способных всё сломать. В данной статье указаны как раз весьма нетривиальные события. Не сомневаюсь, что на самом деле факапов было несравнимо больше, но вот там как раз успешно отрабатывала отказоустойчивость.
            Вроде в прошлом году яндекс накрылся. Вся сеть легла, так как, судя по симптомам, кто-то сказал роутеру «redistribute bgp» под процессом OSPF. Опять же, и от такого можно застраховаться, но я уверен, что большинству сетевиков и в голову не приходило предусмотреть подобный косяк.
            отказоустойчивость будет стремиться к 100%

            Да не будет она повышаться. Останется на тех самых трех-четырех девятках. Дальнейшее повышение надежности будет стоить нецелесообразных денег.
            А тот, кому требуется абсолютная надежность сервиса, либо не станет полагаться на надежность одного хостера (или даже двух), либо вообще откажется от облаков, чтобы контролировать всё своими силами.
            • +7
              По моему на фоне падения русских облаков это мелочи жизни.
              • 0
                А есть где-нибудь подобная статистика по российским облачным сервисам?
                • +3
                  Думаю на Хабре подробно осветили падение каждого из них.
                • 0
                  Мне гораздо больше запомнилось как скалакси дважды за год угробил дисковую систему без возможности восстановления данных. Пришлось восстанавливаться из бекапов, и переезжать в хецнер.
                  • +1
                    Но падения российских провайдеров, хоть и часты, но всё же не влияют на интернет так. Пол-интернета лежит, когда лежит AWS.
                    • +1
                      Самое забавное, что когда падает авс это уважительная причина не работы сайта для заказчика.

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое