В декабре европейские корпоративные пользователи Office 365 обнаружили, что некоторые сотрудники не могут получить доступ к своим почтовым ящикам или сайтам SharePoint. На самом деле проблема не имела отношения к инфраструктуре Office 365: ошибка настройки в Azure Active Directory привела к сбоям проверки подлинности для веб-протоколов. В результате клиенты Outlook Web App (OWA), панель мониторинга работоспособности службы Office 365 и консоли администрирования не могли выполнить проверку подлинности и потому не подключались к Office 365. Та же проблема наделала много бед с другими «облачными» службами Microsoft, которые зависят от Azure Active Directory, и все это вызвало массу хлопот. Компании Microsoft потребовалось несколько часов, чтобы исправить положение. Коренная причина пока точно не известна, но ясно, что Office 365 в огромной степени зависит от Azure Active Directory — настолько, что эту уязвимость назвали ахиллесовой пятой. Специалистам Microsoft предстоит разрешить эту загадку, а также организовать оповещение клиентов Office 365 об отказах.

Последствия сбоя, произошедшего 3 декабря, были различными и, похоже, ограничивались территорией Северной и Западной Европы. Однако обстоятельства, окружающие эту проблему, заслуживают комментария.

В первую очередь факты. Отключение произошло в 8:59 (время в формате UTC). Сайт DownDetecter в Велико­британии (http://downdetector.co.uk/problems/office-365), который регистрирует отказы, располагает отличным графическим представлением, отражающим развитие ситуации. Спустя примерно пять часов, около 13:15 UTC, острота проблемы начала спадать. В первоначальном анализе, опубликованном Microsoft, указывалось, что ошибка настройки привела к выбору неправильного маршрута для производственного трафика: «Результатом стала невозможность доступа к службам, зависящим от проверки подлинности и Azure Active Directory».

Ошибкой настройки можно назвать много неисправностей, от ошибки при редактировании файла XML до фундаментального изъяна в инфраструктуре, который проявился при изменении обстоятельств. В любом случае инфраструктура Azure Active Directory оказалась перегружена, когда спрос клиентов на проверку подлинности начал расти. Попытки проверки подлинности заканчивались неудачей, и клиенты не могли подключиться к службам. Проблема была наиболее очевидной в Европе, так как нагрузка на Office 365 увеличилась там в начале рабочего дня. Авария, похоже, не повлияла на клиентов в Северной Америке и Азии.

Microsoft предоставила потребителям заключительный анализ инцидента (PIR IS34783). Как в любом документе для клиентов, некоторые детали не разглашаются, но все же в PIR можно найти много интересного.

Согласно отчету, первоначально в качестве причины была названа ошибка настройки, приводящая к неверной маршрутизации производственного трафика. По мере роста спроса ситуация ухудшалась и становилась аварийной. После того как специалисты Microsoft осознали происходящее, ошибочная настройка была изменена и функционирование службы восстановлено. В PIR говорится, что изменение настройки произошло в 11:49. Вскоре после этого были отмечены некоторые улучшения, но потребовалось еще около часа, прежде чем службы удалось восстановить полностью.

Из информации, содержащейся в PIR, можно выделить два основных фактора, которые влияют на коренную причину и мешают пользователям выполнить регистрацию в Office 365.

Во-первых, после недавнего обновления была обнаружена необъяснимая проблема настройки между производственной и подготовительной средами Azure Active Directory (проверка подлинности). Подготовительная среда представляет собой тестовую инфраструктуру, которая позволяет компании Microsoft оценить изменения и новые функции, прежде чем программный код будет использоваться для практических целей. Ошибка настройки привела к тому, что некоторые запросы пользователей были направлены в подготовительную среду (куда они никогда не должны поступать) и задержали проверку подлинности на внешнем сервере Azure Active Directory.

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

Среди вопросов, на которые нет ответа в послеаварийном отчете: какая ошибка настройки произошла и как она повлияла на центральный элемент «облачной» инфраструктуры Microsoft в самое напряженное время рабочего дня в Европе?

Очевидно, что коренной причиной инцидента 3 декабря стала ошибка оператора в управлении Azure Active Directory. Специалисты, которые проектируют и эксплуатируют службу, действуют очень профессионально, но, как известно, человеку свойственно ошибаться. В отчете PIR говорится, что Microsoft решила проблему настройки и добавит дополнительные «методы выявления сбоев» для более надежного тестирования и дополнительные механизмы отработки отказов, обеспечивающие применение старой версии службы проверки подлинности в случае сбоя в новой версии. Кроме того, компания планирует улучшить изоляцию конечных точек службы, чтобы предотвратить каскадирование отказов.

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

Примечательно, что клиенты Outlook и ActiveSync продолжали подключаться к Exchange Online во время сбоя, так как использовались кэшированные учетные данные для базовой проверки подлинности, в том числе учетных записей, настроенных для многофакторной проверки подлинности. Согласно отчету PIR, 1% запросов Outlook и 35% Outlook Web App были затронуты во время инцидента. Это не вызывает сильного удивления, если учесть, что такие клиенты, как OWA, должны проходить проверку подлинности с надежными учетными данными и потому более уязвимы, поскольку их запросы проверки подлинности оказываются неудачными. Причины различного поведения клиентов — отдельная тема, заслуживающая исследования в послеаварийном отчете.

Многие администраторы Office 365, чьи клиенты пострадали, выражали в Twitter и других социальных сетях недовольство недостатком информации о клиентах, отображаемой на панели мониторинга работоспособности службы (SHD) во время сбоя. Судя по информации на панелях мониторинга, все с Office 365 было в порядке. Не было никаких указаний на то, что проблемы, очевидно испытываемые пользователями, связаны с Azure Active Directory. Дополнительную информацию можно получить через панель мониторинга состояния Azure (https://azure.microsoft.com/en-us/status/#current), но интеграция между двумя панелями явно оставляет желать лучшего. К сожалению, панель мониторинга работоспособности Office 365 зависит от того же пути проверки подлинности, что и веб-клиенты, и потому подверглась воздействию аварии, и состояние таких служб, как Exchange, SharePoint, Yammer и Skype для бизнеса, могло быть обновлено, чтобы отражать реальное положение.

В действительности специалисты Microsoft предполагали, что сбой может привести к проблемам с Office 365 SHD и встроенной аварийной широковещательной системой (EBS), которая функционирует на другой инфраструктуре и доступна через status.office.com. Идея состоит в том, что система EBS должна включиться автоматически, если возникают проблемы с SHD, кроме ситуаций отказа уровня проверки подлинности, что и произошло 3 декабря. Однако, похоже, проявилась другая ошибка в сети доставки содержимого (CDN), которая мешала европейским клиентам увидеть данные EBS, хотя клиенты в других регионах видели их. Согласно отчету PIR, Microsoft работает над этой проблемой.

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

Хотя это не соответствовало действительности, естественно, и потребители, и комментаторы считали причиной сбоя Office 365. На самом деле авария повлияла на многие другие службы (https://azure.microsoft.com/en-us/status/#history), в том числе Azure Management Portal, Dynamics CRM, Azure Data Catalog и портал Operational Insights, Stream Analytics, Remote App, Visual Studio Team Services и SQL Database. Значительная часть всей «облачной» номенклатуры Microsoft в Европе оказалась недоступной.

Функционирование Office 365 зависит от Azure Active Directory, но это не изъян инфраструктуры Office 365. Аналогично на Outlook часто возлагается вина, когда происходят сбои Exchange Online и локального экземпляра Exchange. Пользователи обращают внимание на то, что у них перед глазами, не замечая внутренних компонентов.

Надежность системы определяется ее самым слабым элементом. Сложные «облачные» службы, такие как Office 365, зависят от многих компонентов, самый важный из которых — Azure Active Directory. В основном благодаря автоматизированному управлению и развертыванию со значительной избыточностью в нескольких центрах обработки данных компания Microsoft успешно решает задачу доступа к Office 365 по сети, но, когда случается авария, масштаб функционирования существующей инфраструктуры приводит к тому, что последствия ощущают многие компании.

К счастью, после выпуска Office 365 в июне 2011 года произошло сравнительно немного крупных аварий. Это означает, что Office 365 имеет высокий уровень функциональной зрелости. Данная авария принесла ущерб, но в целом итоги работы впечатляют, учитывая рост нагрузки на Office 365 до текущего уровня, когда ежемесячно подключается более 60 млн активных пользователей.

Несомненно, Microsoft укажет на соглашение об уровне обслуживания (SLA) для Office 365 с гарантией 99,9% и его успешное выполнение в последние четыре года. Действительно, за последние шесть кварталов уровень SLA для Office 365 держался в диапазоне от 99,95% до 99,99%, но, как я отмечал раньше, из-за огромных масштабов Office 365 изменение показателей SLA оказывается незначительным даже при крупных авариях.

Помимо проблем с Azure Active Directory, невозможность панели мониторинга работоспособности службы Office 365 информировать клиентов во время крупных отключений говорит о том, что мониторинг всей «экосистемы» Office 365 находится на ненадлежащем уровне.

Панель мониторинга работоспособности службы позволяет администраторам узнать, что происходит, когда проблемы Office 365 распознаны и компания Microsoft работает над их устранением. Однако она не столь хороша для отслеживания быстро развивающихся проблем вне строгих границ Office 365, например связанных с компонентами Azure Active Directory или компонентами, участвующими в синхронизации каталогов и едином входе для гибридной среды.

Очевидно, что Microsoft может улучшить методы оповещения об отказах по всему спектру «облачных» служб, предоставив клиентам исчерпывающую картину. Это особенно актуально, поскольку «вычислительное облако» все шире используется крупными компаниями, такими как ABB, которая недавно перевела 125 тыс. пользователей с Lotus Notes на Office 365 (http://www.cio.com/article/3008518/collaboration/cio-describes-how-he-moved-125k-workers-to-office-365-in-6-months.html). Пока этого не произошло, зонды и искусственные транзакции, применяемые в таких решениях мониторинга, как Mailscape 365 компании ENow Software (https://enowsoftware.com/office-365-reporting-monitoring/) и Exoprise CloudReady (http://www.exoprise.com/solutions/), позволяют обнаружить отключения Office 365 на ранних стадиях. Office365 Mon (http://www.office365 mon.com/) также отслеживает работу службы и позволяет администраторам Office 365 собирать и измерять показатели SLA для своих клиентов.

Конечно, другой способ получить информацию о происходящем в случае сбоев — постоянно отслеживать хештег #Office365 в Twitter, но это занятие может быстро наскучить. Компании Microsoft необходимо укрепить Azure Active Directory, чтобы она не стала ахиллесовой пятой Office 365 и других «облачных» служб. Не помешает также усовершенствовать панель мониторинга.