Как узнать, в каком состоянии находится клиент Office 365? Достаточно ли того, что программа работает, или вы то и дело обращаетесь к панели мониторинга служб, чтобы получить от Microsoft отчеты о любом снижении производительности службы? На сегодня в распоряжении разработчиков, похоже, имеются все необходимые инструменты для построения средств, обнаруживающих проблему спустя примерно минуту после ее возникновения. Эту задачу выполняет Office 365 Mon, один из независимых поставщиков программного обеспечения, работающих в «экосистеме» Office 365 и использующих преимущества новых API-интерфейсов на основе REST.

Каждый, кто достаточно долго работал с Exchange, знает, что проектирование одновременно мощных и простых в применениии API-интерфейсов — не самая сильная сторона Microsoft. MAPI, предшественник API-интерфейсов Exchange, отличается богатой функциональностью, но только специалисты, вынужденные проработать с ним несколько лет, назовут его простым. Веб-службы Exchange (EWS), используемые клиентом Outlook для Mac, проще в применении, только если вы Глен Скейлз (http://gsexdev.blogspot.ie/#!) и вам нравится решать головоломки. Опустим занавес перед другими API-интерфейсами Exchange, такими как CDO Routing Objects (http://www.cdolive.com/agent8.htm), поскольку ни один из них не был признан эффективным.

Наличие непонятных API-интерфейсов не способствует успеху в современном стремительно меняющемся мире. У программистов просто нет времени и сил для освоения архаичных ритуалов, поэтому Microsoft выпустила набор API-интерфейсов на основе REST (https://msdn.microsoft.com/

en-us/office/office365/api/api-catalog) для доступа к службам Office 365 (http://winsupersite.com/office-365), в том числе «объединенные» API-интерфейсы для обработки содержимого почтовых ящиков Exchange и других данных, таких как группы Office 365 и базы данных Graph. Другие API-интерфейсы REST обеспечивают доступ к службам отчетов Office 365 (https://msdn.microsoft.com/en-us/library/office/jj984325.aspx), действиям по управлению Office 365 (https://msdn.microsoft.com/EN-US/library/office/mt227394.aspx) и данными коммуникаций служб Office 365 (https://msdn.microsoft.com/EN-US/library/dn707386.aspx).

REST означает «передача репрезентативного состояния». Этот метод подходит для взаимодействия между клиентом и сервером по протоколу HTTPS. Преимущество выбора REST как основы для API-интерфейсов Office 365 в том, что его формат и использование знакомы многим программистам, строившим веб-службы. Клиенты подключаются к известным конечным точкам, проходят проверку подлинности (с использованием протокола OAuth) и совершают транзакции. Результаты возвращаются в формате JSON. Одним словом, никакой черной магии.

Мощная функциональность API-интерфейсов для Office 365 важна, так как способствует быстрому росту «экосистемы» вокруг службы. Ни один продукт, даже «облачные» службы, стремительно эволюционирующие, не способен удовлетворить все требования каждого клиента. Локальные версии Exchange и SharePoint стали источником миллиардных оборотов для Microsoft благодаря мощной «экосистеме», окружающей и поддерживающей базовую технологию. Сегодня Microsoft пытается повторить успех с Office 365.

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

Мониторинг Office 365 всегда играл важную роль. После того как в 2011 году был устранен ряд ошибок, относительная стабильность службы заставила некоторых клиентов поверить, что все компоненты будут всегда функционировать безупречно. Но после нескольких отключений, произошедших в последнее время, интерес к мониторингу вернулся, а уровень обслуживания (SLA) Microsoft упал с 99,99% в первом квартале 2015 года до 99,95% во втором квартале (https://products.office.com/en-us/business/office-365-trust-center-cloud-computing-security? tab=d1f6ec18-0f9b-0fef-3203-3d7d52bc1437).

Конечно, нелегко связать показатель SLA с впечатлениями отдельного клиента, а падение уровня обслуживания на 0,04% за квартал не кажется проблемой, особенно если учесть огромную армию пользователей Office 365. Однако каждый сбой важен, если он затрагивает вашу работу, и справиться с неполадками помогут такие компании, как Office365 Mon (office365mon.com/). Задача компании, возглавляемой Стивом Пешкой, за плечами которого 18-летний опыт работы в Microsoft, — как можно быстрее известить администраторов о сбое, затронувшем клиентов. Для достижения этой цели в Office365 Mon используются синтетические зонды, чтобы проверить, подключены ли почтовые ящики Exchange и сайты SharePoint к сети, и сообщить об обнаруженных проблемах по электронной почте или через SMS-сообщения.

Использование синтетических транзакций для поиска проблем — прием не новый. Система управляемой доступности в Exchange 2013 и Exchange 2016 использует аналогичные транзакции, чтобы обнаружить проблемы с локальными серверами и при необходимости принять меры для восстановления службы, вплоть для принудительной перезагрузки сервера.

Программа Office365 Mon не слишком мощная, но довольно успешно определяет неполадки. Иногда даже слишком успешно, как я выяснил, когда настроил клиент на использование Office365 Mon и получил несколько уведомлений о потенциальных отключениях на следующий день. Ни одно из них не вызвало никаких проблем для моего клиента, а объяснялись они, похоже, переходными условиями где-то между физическим сервером, на котором размещен контролируемый почтовый ящик или сайт, и сервером Azure, запросившим целевой ресурс в синтетической транзакции. Как показано на приведенном экране, большинство отказов, о которых сообщает мой клиент, были довольно короткими, и пользователи, запускавшие Outlook в режиме кэширования данных Exchange, скорее всего, не заметили никаких проблем.

 

Уведомления о потенциальных отключениях
Экран. Уведомления о потенциальных отключениях

К счастью, Office365 Mon позволяет клиентам настроить «интервал беспокойства» для уведомлений, чтобы получать их, только если потенциальное отключение превращается в перерыв в работе длительностью 2-3 минуты (или больше). Возможность настроить «интервал беспокойства» — пример быстрого изменения приложений в «облаке» в соответствии с отзывами потребителей. По крайней мере, хороших приложений! Можно также настроить Office365 Mon таким образом, чтобы получать сообщения об определенных событиях, в частности о восстановлении службы после отключения.

Раннее обнаружение проблемы дает много преимуществ. Microsoft пытается сообщать о неполадках на панели управления службы Office 365, но информация о проблемах поступает клиентам не так быстро, как от средства мониторинга. Главное достоинство базовой версии Office365 Mon в том, что она бесплатная (https://office365mon.com/Products/Pricing). Вы платите только за дополнительные функции, например расширенные отчеты и аналитику, в том числе точные сведения о показателях SLA, обеспечиваемых компанией Microsoft вашему клиенту. Эта служба определенно должна заинтересовать пользователей, работающих только в «облаке».

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

Если требуются мониторинг и отчеты для гибридного развертывания, то следует обратиться к другим инструментам, таким как Mailscape 365 компании ENow Software (http://enowsoftware.com/products-and-solutions/exchange-management-tools/hybrid-exchange-and-office-365/) или Exoprise CloudReady (http://www.exoprise.com/solutions/office-365-performance-monitoring/). Масштабы и сложность гибридных сред Exchange изменяются в очень широких пределах, поэтому лучше сначала опробовать продукт, проверив его эффективность на практике.

Отрадно, что Microsoft уделяет внимание тому, чтобы сделать Office 365 удобным для разработчиков. Все заинтересованы в том, чтобы независимые поставщики программного обеспечения заполнили пробелы, по каким-то причинам оставленные Microsoft. Будет интересно посмотреть, какими путями пойдет использование этих API-интерфейсов.