Когда 28 февраля этого года веб-служба Amazon (AWS) прекратила свою работу на пять часов, многие клиенты данного провайдера «облачных» услуг и сайты потеряли соединение с Интернетом, в результате чего их сотрудники и клиенты остались без связи. Для компаний подобная ситуация может оказаться большой проблемой, приносящей серьезный финансовый ущерб. Для клиентов AWS отключение продолжалось около пяти часов, и причиной была простая ошибка (https://aws.amazon.com/message/41926/) оператора AWS при наборе строки ввода команды в процессе технического обслуживания, как утверждается на сайте компании. В результате из эксплуатации было выведено больше серверов, чем предполагалось в рамках процедуры, и это привело к сбою. Последствия этой небольшой ошибки для клиентов оказались серьезными.
nnЗатем Amazon сообщила, что после инцидента в ее процедуры были внесены изменения, в частности усовершенствован инструмент, используемый для удаления серверов. Ранее применявшийся инструмент позволял выполнять весьма масштабные действия слишком быстро, в результате чего ошибка в команде могла пройти незамеченной, как говорится в заявлении компании: «Мы изменили инструмент, чтобы замедлить удаление ресурсов, и добавили защитные меры, благодаря которым нельзя удалить ресурсы ниже минимально необходимого порога для функционирования любой подсистемы. Это исключает возможность подобных событий из-за ошибки ввода в будущем. Кроме того, мы проводим проверку других эксплуатационных инструментов, которые должны иметь аналогичные средства безопасности». Это, конечно, обнадеживает пользователей «облака» и Интернета, полагающихся на многочисленные службы и сайты, размещаемые на оборудовании AWS, но какие уроки следует извлечь компаниям, чтобы их клиенты и работники не пострадали при следующем сбое?nnПо мнению многих ИТ-аналитиков, самое важное — заранее составить план на случай аварии.nn«Компаниям настоятельно рекомендуется не складывать все свои ИТ-ресурсы в одну корзину,— коментирует Дэн Олдс, главный аналитики компании Gabriel Consulting Group. — Излишне полагаясь на одно «облако», вы подвергаетесь серьезной опасности». Что и произошло 28 февраля при сбое службы AWS. «Здесь все дело в избыточности. В центрах обработки данных имеются резервные системы и механизмы отработки отказа для устранения аварий на уровне центра обработки данных. Клиентам необходимо иметь механизмы такого же типа для ‘облачных’ рабочих нагрузок,— продолжает Олдс— В конечном итоге все, что зависит от человеческого фактора, любые продукты, разработанные и построенные людьми, могут дать сбой в какой-то момент, это неизбежно. И клиентам необходимо заранее подготовить план для продолжения работы в случае отказа одной системы, частного ‘облака*» или службы общедоступного ‘облака’». Другой аналитик, Чарльз Кинг из исследовательской фирмы Pund-IT, заметил, что даже службы повышенной доступности AWS не работали после аварии 28 февраля, что указывает на необходимость компаниям подумать о собственных планах резервирования, без оглядки на финансовые затраты. «Если вам необходимо увеличить гибкость и доступность, то разумно управлять приложениями и данными локально или зеркалировать их не в одно публичное ‘облако’, — считает Кинг. — Дорого? Возможно. Неприемлемо? Зависит от обстоятельств. В какую сумму обойдется отключение вашей компании от сети на 5 часов? Думаю, некоторые компании, пострадавшие от сбоя AWS, теперь пересматривают свои взгляды на ‘облачные’ вычисления». После аварии Кингу приходилось слышать о компаниях, которые создали зеркальные копии своих вебсайтов и запускали резервные приложения на локальных серверах. В результате они продолжали работу, когда другие компании, полагавшиеся исключительно на AWS, простаивали. «Если компания полностью вложилась в AWS или любую другую общедоступную ‘облачную’ службу, то она целиком зависит от поставщика», — поясняет аналитик.nnПо мнению Кинга, необходимо учитывать, что крупные авари и, подобн ые этой, происходят нечасто, но их помнят многие годы. «Не удивлюсь, если некоторые клиенты откажутся от услуг AWS, и конкуренты Amazon, вероятно, постараются использовать ее затруднения в своих интересах»,— заключает Кинг. С точки зрения этого аналитика, существует множество вариантов: «Microsoft Azure определенно позиционируется как передовой, надежный, удобный для бизнеса ‘облачный’ поставщик. IBM Cloud ориентируется на услуги корпоративного класса, с акцентом на гибридное развертывание, в рамках которого ресурсы и службы поставщика объединяются с данными и приложениями клиента». Для клиентов AWS — самый крупный поставщик «облачных» услуг на рынке, но существует ряд достойных альтернатив, как считает Кинг.nnДипак Мохан, аналитик исследовательской фирмы IDC, полагает, что значимость сбоя AWS 28 февраля обусловлена тем, что были нарушены чтение и запись в S3, одну из базовых инфраструктурных служб в AWS.nn«По этой причине «облачные» приложения, чувствительные к простоям, должны проектироваться с учетом возможных отключений или недоступности компонентов базового уровня инфраструктуры,— утверждает Мохан. — Хотя ошибки встречаются реже, в чувствительные приложения должна быть заложена устойчивость к недоступности инфраструктурных элементов. Это может быть сделано через зоны доступности, различные регионы или инфраструктурные платформы». По мнению Мохана, в большинстве случаев многосайтовая избыточность может быть организована без существенных затрат и обеспечивает необходимое аварийное восстановление: «По мере увеличения строгости критериев затраты, естественно, будут возрастать».nnВ конечном итоге повторные сбои любого поставщика будут отталкивать потребителей от дальнейшего использования платформы, как считает Мохан: «Это не уникальная ситуация для AWS, и в конце концов потребители «облачных» услуг внедрят подходы с резервированием, типичные для истинно «облачных» приложений, для всех важных приложений в «облаке»».nnМы также рекомендуем строить отказоустойчивые решения с разнесением между различными облачными серверами, обращайтесь [email protected]
