Работа сотен тысяч сайтов была нарушена из-за сбоя в облачном сервисе Amazon.
Неполадки в работе крупнейшей облачной системы хранения данных Amazon Web Services S3 AWS, произошедшие в ночь на 1 марта, вызвали сбой в работе огромного количества сайтов и интернет-приложений по всему миру.
В числе пострадавших оказались некоторые сервисы Apple (App Store, Apple Music, FaceTime, iCloud, iTunes, Photo) и Adobe, сайты Комиссии по ценным бумагам и биржам США, платформа для разработчиков GitHub, ряд новостных ресурсов, краудфандинговая платформа Kickstarter, почтовый сервис Mailchimp, приложение Signal и пр.
Согласно сообщению Amazon в Twitter, неполадки возникли в работе сетевого хранилища S3 AWS, где содержится информация, которую использовало значительное количество сайтов и приложений. Проблемы с доступом к сайтам продолжались более 3,5 часов.
Сбой произошел в дата-центре Amazon в Вирджинии, проблему удалось устранить спустя порядка 4 часов. Компания не раскрывает причину нарушения в работе своего сервиса. В настоящее время Amazon Web Services функционирует в штатном режиме.
Владимир Лебедев, директор по развитию бизнеса Stack Group
Почему по вашему произошел сбой в сервисе с надежностью 99.9999% как они себя преподносят?
Такой SLA компании гарантируют зачастую на отдельные компоненты своего сервиса, например, на подсистему хранения данных, при этом при сбоях подсистем с меньшими гарантиями SLA страдает весь сервис заказчика, использующий данные подсистемы.
Насколько может пострадать репутация Амазон после произошедшего сбоя?
На мой взгляд, для компаний, предоставляющих технологичные сервисы всегда остается минимальная вероятность отказов оборудования, программного обеспечения, сетевой доступности ввиду огромного количества причин, начиная с ошибок производства и заканчивая человеческим фактором. Если и будет насколько-то заметный урон репутации, то, на мой взгляд, только для клиентов, которые понесли реальный ущерб от данного инцидента.
Дайте совет что делать текущим российским клиентам Amazon.
Если системы требуют высокого уровня отказо- и катастрофоустойчиваости, рекомендую резервировать критичные сервисы на уровне выбора не только географически разнесенных дата-центров и облачных решений одного провайдера, но и на уровне других независимых глобальных или локальных поставщиков сервисов.