Декабрь прошлого года выдался не очень праздничным для подписчиков Office 365 в Западной Европе, поскольку имели место два инцидента, произошедшие в пиковое время утром 3 и 18 декабря. Они никак не связаны между собой, за исключением того, что оба наглядно демонстрируют, насколько все-таки службы, подобные Office 365, зависят от прочих элементов «облачной» инфраструктуры Microsoft. На этот раз неисправный сетевой компонент стал причиной потери некоторых сетевых пакетов в хранилище Azure, что в свою очередь сделало невозможным подключение к порталу Office 365 для администраторов.
В одной из недавних статей я уже рассуждал о том, является ли проблема, которая повлекла за собой невозможность для пользователей авторизоваться в Office 365, наглядной демонстрацией того факта, что Azure Active Directory (AAD) становится ахиллесовой пятой «облачных» служб Microsoft. Сбой, произошедший 3 декабря, еще раз подчеркнул, как сильно Office 365 зависит от работоспособности прочих компонентов «облачной» инфраструктуры.
18 декабря возникла другая проблема, которая затронула некоторых пользователей Office 365 и Azure в Западной Европе. Естественной реакцией тех, кто не смог подключиться к Office 365, было предположение, что это всего лишь повторение предыдущей проблемы, и именно такая версия обсуждалась тогда в прессе. Однако, как оказалось, причина в данном случае не имела никакого отношения к AAD.
Инцидент, произошедший 18 декабря, был относительно недолгим, общей продолжительностью около 140 минут (с 9:15 до 11:25, а первый инцидент длился 316 минут). Оба события доставили значительные неудобства тем пользователям, которые не могли работать, пока инциденты расследовались и устранялись, но, как показывает практика, обнаружение и ликвидация корневой причины любой проблемы, возникшей в сложной инфраструктуре, может потребовать значительного времени.
Оба инцидента имели место во время утреннего пика в Западной Европе. Главное различие между ними состоит в том, какие именно сложности в работе они доставили пользователям. Сбой 3 декабря повлек за собой невозможность доступа к Office 365 для большого числа пользователей. Последствия же события 18 декабря ощутили на себе только те, кто пытался подключиться к порталу Office 365 (portal.office.com) для выполнения административных задач.
Я запросил информацию о данном инциденте у компании Microsoft (ссылка PIR MO36910, датированная 30 декабря). Если вы являетесь подписчиком, который мог пострадать от этого сбоя, то можете получить копию постсообщения о происшествии (PIR) в разделе истории происшествий, охватывающем 30-дневный период, в панели мониторинга работоспособности службы Service Health Dashboard (SHD) в Office 365. Данное сообщение описывает воздействие произошедшего инцидента на пользователей следующим образом:
«Пользователи и администраторы, которых это коснулось, были неспособны зарегистрироваться на портале Office 365 по ссылкам office.com или portal.office.com. Доступ конечных пользователей к Outlook в Интернете, SharePoint Online, OneDrive для бизнеса и другим к службам Office 365 данным происшествием затронут не был; однако пострадавшие пользователи не могли получить доступ к данным службам через портал Office 365».
Суть в том, что большинство конечных пользователей смогло продолжить нормальную работу, поскольку они использовали клиенты (такие, как Outlook или мобильные устройства), которые не подключаются к порталу либо используют закладки (прямые URL-ссылки) для получения доступа к веб-приложениям, вроде Delve или видеопортала Office 365.
Например, если вы наберете outlook.office365.com, Outlook Web App запустится без необходимости использовать сначала ссылку portal.office.com. Я не совсем понимаю, зачем конечному пользователю сначала заходить на портал, а уже потом переходить к конкретному приложению (например, к тому же Outlook Web App), но технически это вполне осуществимо, и некоторые пользователи, возможно, так и поступают. В любом случае, поскольку были затронуты администраторы, проблема была выявлена довольно быстро и в Microsoft посыпались вопросы — а что же все-таки произошло?
Корневая причина ситуации описывается в PIR следующим образом:
«Проблема в коде драйвера сетевого интерфейса при определенных условиях вызывала неявную потерю пакетов. При возрастании нагрузки это привело к задержкам и значительному снижению доступности инфраструктуры, на которой размещены службы портала Office 365».
Как заявляют в Microsoft, данный инцидент был локализован в той части инфраструктуры хранилища Azure, которая используется Office 365 для своих служб портала. Небольшой сетевой сбой привел к потере пакетов, и, как следствие, к частичной неспособности службы хранилища Azure отвечать на некоторые запросы. Как только указанная проблема была идентифицирована, трафик портала был перенаправлен таким образом, чтобы избежать ее дальнейшего воздействия. Кроме того, указанная потеря пакетов привела к некоторым сложностям в работе администраторов.
Таким образом, в реальности ни AAD, ни Office 365 не были причиной инцидента, однако подключения к Office 365 были значительно затруднены из-за потери пакетов, происходившей в компоненте, который относится к совершенно другой части полной «облачной» инфраструктуры Microsoft.
Другой факт, требующий дополнительного внимания, который выявил PIR, состоит в том, что Office 365 SHD не спешил сообщать о проблеме. Пользователи обнаружили ее раньше, чем инженеры Microsoft поняли, что что-то не так и это «что-то» нужно отметить посредством SHD. Компания Microsoft сейчас пересматривает инфраструктуру мониторинга Office 365, с целью оптимизации ее способности своевременно реагировать в будущем на проблемы подобного рода.
Как я уже отмечал, SHD подсказывает администраторам подписки, когда что-то идет не так. Между появлением проблемы и завершением ее изучения, результатом которого, возможно, станет вывод о необходимости инженерных работ, неизбежно проходит некоторое время. Вряд ли вы хотели бы видеть множество сообщений в SHD о событиях, которые могут и не быть реальными проблемами. Даже квалифицированные специалисты по диагностике и устранению проблем следуют определенным процедурам при изучении симптомов и других данных, прежде чем они смогут сделать однозначный вывод о корневой причине тех или иных неполадок. Но так или иначе, Microsoft могла бы и более оперативно информировать пользователей о том, что именно происходит.
Возможно, компанией Microsoft движет всего лишь нежелание бросать тень на доброе имя своих «облачных» служб, когда она не торопится подтверждать те или иные проблемы. Что ж, подобная позиция имеет право на существование, поскольку многие неполадки проявляются лишь время от времени, являются специфическими для какого-либо подписчика, исчезают сами по себе или уже находятся в процессе исправления. Отображение же всех инцидентов подряд в SHD без применения качественного фильтра вполне может вызвать панику у некоторых администраторов.
Конечно, администраторы подписчиков могут развернуть программное обеспечение для мониторинга и в реальном времени оценивать, какое именно количество служб предоставляется их пользователям. Понятно, что такие решения не покажут, что именно делает Microsoft в своих центрах обработки данных, но они, по крайней мере, позволят быть в курсе, когда что-то не работает так, как должно, и пользователи (да и администраторы тоже) будут спокойны, а о любой возникшей проблеме будет своевременно проинформирован разработчик. Так ведь гораздо лучше, чем находиться в подвешенном состоянии, не понимая, что происходит, хотя порой кажется, что именно это и является основным принципом работы SHD.