25 декабря 2017 г.
Самые запомнившиеся в уходящем году истории, затронувшие пользователей в США и Европе.
Даунтайм — неизбежность?
Общий тренд таков, что случаев неработоспособности облачных услуг становится всё меньше — поставщики набираются опыта и совершенствуют свои средства управления этими крупнейшими и самыми сложными из когда-либо существовавших серверных кластеров.
В начале года казалось, что сообщения о катастрофических отказах облачных услуг стали почти анахронизмом. Да, у всех провайдеров бывают какие-то срывы, когда не работают те или иные сервисы, либо краткие периоды региональных сбоев, но масштабные отказы вроде тех, что случались на заре становления этого рынка, казалось, ушли в прошлое.
Но ближе к концу февраля мир вновь узнал, что даже самый крупный провайдер облака, оснащенный самыми передовыми средствами автоматизации, всё же не застрахован от случайностей, и масштаб этого отказа был беспрецедентным. Отказ облака AWS потряс отрасль и поубавил уверенность корпоративных заказчиков, уже потеплевших к облачным технологиям, из-за одного лишь количества бизнес-сервисов, ставших недоступными в этот день. GitHub, Slack, Zendesk, Heroku, Twilio, Mailchimp, Citrix, Expedia — вот лишь малая часть понесенных пользователями потерь. Уверенность заказчиков еще больше упала, когда крупнейший игрок рынка сообщил, что причиной был человеческий фактор — одна неверная строка команды, введенная инженером сопровождения.
Этот памятный многим отказ — и, в меньшей степени, девять других, затронувших пользователей облачных сервисов в США, — служат напоминанием для быстро входящей в стадию зрелости отрасли, что ставки тех, кто претендует на безупречность обслуживания, как никогда высоки.
Вот те самые отказы облачных сервисов, которые запомнились многим пользователям в США и Европе в уходящем году.
IBM: 26 января
В самом начале прошлого года уверенность в безотказности облака IBM была поколеблена, когда портал управления, используемый разработчиками для доступа к сервисам платформы Bluemix, оказался неработающим в течение нескольких часов.
В самой инфраструктуре не было отказа, но пользователи были раздосадованы, видя, что не могут управлять своими приложениями и добавить или удалить облачные ресурсы, обслуживающие рабочие нагрузки.
IBM сказала тогда, что неполадки возникали время от времени и были вызваны неудачно проведенным обновлением интерфейса.
GitLab: 31 января
В этот день случился
Часть готового кода некоторых заказчиков была безвозвратно потеряна, в том числе последние изменения в проектах, комментариях и аккаунтах.
«По нашей самой точной оценке, это затронуло примерно 5000 проектов, 5000 комментариев и 700 новых пользовательских аккаунтов», — сообщила компания пост-фактум.
Принося извинения клиентам, главный управляющий GitLab признал: «потеря готового кода недопустима».
Facebook: 24 февраля
В течение почти трех долгих, мучительных часов некоторые пользователи по всему миру не могли попасть в Facebook и опасались, что их аккаунты украдены.
Позднее гигант соцсетей объяснил, что функционал, призванный оградить от хакеров, ошибочно отправлял пользователей на экран восстановления, что создавало впечатление, будто кто-то другой вошел в их аккаунт. Механизм защиты запрещал этим пользователям повторный вход в свой аккаунт. Facebook заверил, что никакого реального нарушения безопасности не было.
Это был уже второй случай за неделю, когда у пользователей соцсети возникли проблемы. Несколькими днями ранее несколько человек сообщили, что не видят свою ленту новостей.
Amazon Web Services: 28 февраля
Это был отказ, потрясший отрасль.
Штатный инженер Amazon Web Services, занимавшийся отладкой облачного хранилища S3 в ЦОДе в Виргинии, по ошибке ввел неверную команду, и громадная часть Интернета, включая популярные корпоративные сервисы Slack, Quora и Trello, не работала в течение четырех часов.
В разборе происшествия, опубликованном компанией, говорилось, что сотрудник действовал «по утвержденному сценарию» и намеревался остановить небольшое количество серверов, на которых работали подсистемы, обслуживающие процесс биллинга, но по ошибке ввел не ту команду, что привело к гораздо более масштабному отключению серверов, в том числе одной подсистемы, необходимой для обслуживания определенных запросов к функциям хранения данных, и еще одной, выделяющей новые ресурсы хранения.
Отказ у провайдера, на долю которого приходится около трети глобального рынка облачных услуг, вновь подогрел споры о рисках общедоступного облака.
Microsoft Azure: 16 марта
Проблемы доступа к ресурсам хранения осаждали общедоступное облако Microsoft Azure более восьми часов, затронув заказчиков главным образом на Востоке США.
Некоторым пользователям в регионе не удавалось предоставить новые ресурсы хранения или получить доступ к имеющимся. Команда специалистов компании смогла всё же выявить виновника — им оказался кластер хранения, где отключилось питание и потому ставший недоступным.
Кроме этой проблемы, Microsoft сообщила также на странице статуса Azure об ошибке в ПО, более часа вызывавшей сбой предоставления хранения для многих услуг.
Microsoft Office 365: 21 марта
В этот день несколько коммерческих и потребительских облачных сервисов Microsoft, в том числе сервисы хранения и электронной почты в Office 365, стали недоступны из-за проблем с аутентификацией пользователей. Продолжавшийся сбой не позволял использовать хранилище OneDrive, а также Skype, Outlook и игровой сервис Xbox Live.
Apple iCloud: 28 июня
Многие ленты новостей в соцсетях сообщили о недоступности сервиса резервного копирования в iCloud. Страница статуса облака Apple сообщала, что iCloud Backup не работает лишь для 1% пользователей.
Проблема, при которой затронутые пользователи не могли провести восстановление своих iOS-устройств из предыдущих резервных копий, сохранялась в течение по меньшей мере 36 часов. Процесс восстановления зависал, при этом сохранение новых резервных копий с устройств выполнялось без проблем.
Amazon Web Services: 14 сентября
Этот, новый отказ AWS в сентябре не шел ни в какое сравнение с отказом февраля, но то, что он затронул сервис хранилища S3 и что проблемы возникли всё в том же регионе US-EAST-1, пробудило малоприятные воспоминания о катастрофическом сбое полугодичной давности. Ошибки доступа к персональным хранилищам (buckets) начали привлекать к себе внимание около полудня и были ликвидированы к 13 часам по Восточному времени.
Microsoft Azure: 29 сентября
Некоторые сервисы в общедоступном облаке Microsoft Azure были недоступны европейским пользователям в течение семи часов. Причиной неработоспособности сервисов этого, второго крупнейшего в мире поставщика облачных услуг в Северной Европе, было случайное срабатывание системы пожаротушения.
Компания объяснила, что при плановом техобслуживании системы произошел выпуск газообразующего реагента, что привело к автоматическому отключению системы кондиционирования воздуха, вызвавшему повышение температуры среды в ЦОДе и, как следствие, автоматический останов вычислительного оборудования.
Важные для клиентов облачные услуги — Virtual Machines, Cloud Services, Azure Backup и несколько других — не работали с 13:27 до 20:15 по местному времени.
Google Docs: 15 ноября
Тысячи пользователей Google Docs столкнулись со сбоем в работе сервиса, который сказался на их бизнесе.
Отказ начался чуть ранее 16:00 по Восточному времени и длился от 30 минут до чуть более часа для большинства пользователей, сообщила впоследствии компания. Во время отказа, затронувшего «значительное подмножество пользователей», этот популярный сервис создания и редактирования документов не давал доступа к файлам.
К ночи среды Google сообщила, что сервис Docs вновь работает для большинства пользователей.
Один из партнеров Google сказал CRN, что шесть из его 400 бизнес-клиентов пострадали от этого отказа. Сам поставщик решений, также использующий этот сервис, тоже пострадал.
© 2017. The Channel Company LLC. Initially published on CRN.com, a The Channel Company website, at https://www.crn.com. Reprinted with permission.
Источник: Джозеф Цыдулко, CRN/США