Настройка производительности Office 365 с помощью базовых показателей и истории производительности

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

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

Важно : У вашего клиента прямо сейчас возникла проблема с производительностью Office 365? Выполните действия, описанные в статье План устранения проблем с производительностью Office 365.

Необходимые сведения о производительности Office 365

Система Office 365 работает на базе высокопроизводительной выделенной сети Майкрософт, которая находится под постоянным контролем не только автоматических инструментов, но и живых людей. Одна из задач, связанных с обеспечением работы облачной среды Office 365, связана с использованием встроенных средств для настройки и оптимизации производительности там, где это возможно. Поскольку клиенты облачной среды Office 365 подключаются к ней через Интернет, необходимо также постоянно следить за работоспособностью служб Office 365 и проводить их точную настройку. Улучшения с целью повышения производительности вносятся в облачную среду постоянно, и это позволило накопить богатый опыт в вопросах обеспечения ее работоспособности и высокой скорости. Если у вас возникает проблема с производительностью при подключении к среде Office 365 с рабочего места, не стоит сразу обращаться в службу поддержки и ждать, пока вашу заявку обработают. Вместо этого имеет смысл проанализировать проблему изнутри, то есть из пределов вашей сети, чтобы выяснить, на каком этапе подключения к Office 365 она возникает. Прежде чем регистрировать обращение в службу поддержки Office 365, вы можете собрать необходимые данные и выполнить ряд действий, которые помогут вам проанализировать и, возможно, устранить возникшую неполадку.

Важно : Помните о планировании загрузки и ограничениях, связанных с Office 365. Эта информация существенно поможет вам при анализе проблем с производительностью. Вот ссылка на описание службы Office 365. Это страница, на которой вы можете найти ссылку на описание каждой службы в Office 365. Например, если вам нужно просмотреть стандартные ограничения для SharePoint Online, перейдите по ссылке Описание службы SharePoint Online и найдите раздел о ее ограничениях.

Приступая к поиску и устранению неполадок, вы должны понимать, что показатели производительности меняются: добиться идеального результата и поддерживать его постоянно невозможно. Если вы не верите в это, то периодические задачи, связанные с повышенной загрузкой пропускного канала (например, добавление в систему большого числа пользователей или перенос объемных данных), всегда будут для вас серьезным испытанием, и вам придется заблаговременно планировать последствия своих действий для производительности вашей среды. У вас могут и должны быть ориентировочные целевые показатели производительности, однако на нее влияет множество факторов, вследствие чего она не может быть постоянной. Таково ее неотъемлемое свойство.

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

Итак, каковы признаки проблемы с производительностью?

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

Если проблема связана со службой Office 365, это инцидент обслуживания. В этом случае вы увидите красные или желтые значки в разделе Текущее состояние Центра администрирования Office 365, а также, возможно, обнаружите замедление работы на клиентских компьютерах, которые подключаются к Office 365. Например, если в разделе "Текущее состояние" отображается красный значок и для службы Exchange указано, что для нее ведется исследование, вы также можете столкнуться с валом обращений от пользователей организации, которые жалуются на неполадки при работе с клиентскими почтовыми ящиками на базе Exchange Online. В такой ситуации можно предположить, что ваши проблемы с производительностью Exchange связаны с неполадками в наших службах.

Панель мониторинга работоспособности Office 365 с отображением всех рабочих нагрузок зеленым цветом, за исключением Exchange, для которого отображается состояние "Служба восстановлена".

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

Изображение панели мониторинга работоспособности служб Office 365 со сведениями о том, что служба Exchange Online была восстановлена, с указанием причины сбоя.

Проблема с производительностью не является инцидентом обслуживания несмотря на то, что инциденты часто приводят к замедлению работы. Ниже перечислены признаки проблемы с производительностью.

  • Проблема возникает независимо от текущего состояния службы в Центре администрирования Office 365.

  • Действия, которые раньше выполнялись сравнительно быстро, теперь занимают много времени или вообще не выполняются.

  • Проблему также можно воспроизвести (то есть вы знаете, какая последовательность действий ее вызывает).

  • Если проблема периодически возникает и пропадает, существует определенная закономерность (то есть, например, вы знаете, что примерно в 10 часов утра вам начнут звонить пользователи с жалобами на проблемы с подключением к Office 365, а к полудню поток таких звонков ослабеет).

Возможно, все это вам уже знакомо (и даже, к сожалению, слишком хорошо). Когда выяснится, что у вас проблема с производительностью, у вас наверняка возникнет вопрос: что дальше? В оставшейся части этой статьи подробно описаны ваши действия в этом случае.

Как определить и протестировать проблемы с производительностью

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

  • Раньше из входящих в Календарь можно было перейти за секунду, а теперь я за это время успеваю выпить кофе. Можно сделать так, чтобы все работало как раньше?

  • Отправка файлов в SharePoint Online занимает вечность. Почему к полудню она так замедляется, хотя в любое другое время работает быстро? Можно сделать так, чтобы она всегда работала быстро?

В приведенных выше формулировках проблем есть серьезные недостатки. В частности, они содержат целый ряд неоднозначных моментов.

  • Непонятно, насколько быстро раньше происходил переход из входящих в Календарь на ноутбуке.

  • Когда пользователь говорит "чтобы она всегда работала быстро", что для него означает "быстро"?

  • И сколько именно длится вечность? Это несколько секунд или минут? Или пользователь успевает сходить позавтракать, а когда возвращается, вынужден ждать еще десять минут, пока загрузка не завершится?

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

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

  • Когда проблема возникла в первый раз, и в какое время суток это произошло?

  • Какой клиентский компьютер вы используете, и как он подключается к рабочей сети (через VPN, проводное или беспроводное соединение)?

  • Вы работали в удаленном режиме или из офиса?

  • Удавалось ли вам воспроизвести проблему на другом компьютере с помощью того же набора действий?

  • Подробно опишите действия, вызывающие проблему, и запишите их точную последовательность.

  • Насколько долго выполняется проблемная операция (в секундах или минутах)?

  • В какой точке мира вы находитесь?

Некоторые из этих вопросов более очевидны, чем остальные. Практически любой пользователь понимает, что для диагностики необходима точная последовательность действий, позволяющая воспроизвести проблему. Без нее не получится зафиксировать неполадку и проверить, устранена ли она. Менее очевидны вопросы наподобие "Когда именно и в какое время суток возникла проблема?" и "В какой точке мира вы находитесь" (ответы на них часто дополняют друг друга). Разница в несколько часов в зависимости от времени работы пользователя может означать, что в корпоративной сети или ее отдельных компонентах в соответствующий момент проводилось техническое обслуживание. Если, например, в организации развернута гибридная среда, такая как гибридная служба поиска SharePoint, которая отправляет запросы к поисковым индексам как в среде SharePoint Online, так и на локальном сервере SharePoint Server 2013, возможно, на локальной ферме в данный момент производятся обновления. Если организация работает только с облачными службами, обновления системы могут включать добавление и удаление сетевого оборудования, развертывание обновлений в масштабах всего предприятия, внесение изменений в DNS или другие базовые элементы инфраструктуры.

Анализ проблемы с производительностью чем-то напоминает расследование преступления: чтобы сделать выводы на основании доступных данных, необходимы предельная точность и наблюдательность. Для этого нужна точная формулировка проблемы, которую можно получить путем сбора информации. В ней должен быть учтен контекст компьютера и пользователя, время возникновения проблемы, а также подробная последовательность действий, которые вызвали неполадку. Формулировка проблемы должна лежать в основе всех принимаемых вами мер. На основе содержащихся в ней данных вы, подобрав то или иное решение, выполняете определенные действия, позволяющие проверить работоспособность системы и выяснить, помогли ли принятые вами меры устранить неполадку. Точная формулировка крайне важна для понимания того, удалось ли вам справиться с проблемой.

Знаете ли вы реальные показатели производительности в тот момент времени, когда она считалась хорошей?

В худшем случае может выясниться, что этого не знает никто: ведь никто не замерял показатели ее производительности. Это означает, что никто не сможет ответить на простые вопросы наподобие "Сколько секунд примерно занимал переход во входящие в Office 365" или "Сколько времени требовалось на подключение к конференции в Lync Online?" (типичные сценарии работы для множества организаций).

В данном случае у нас нет базовых показателей производительности.

Базовые показатели — это контекст, в котором выполняется оценка производительности. Их нужно периодически замерять, и частота такого замера зависит от потребностей вашей организации. Если ваша компания достаточно велика, возможно, специалисты операционного отдела уже определили базовые показатели для вашей среды. Например, если ваша организация устанавливает исправления на все серверы Exchange Server в первый понедельник месяца, а на серверы SharePoint — в третий понедельник, у вашего операционного отдела, вероятно, есть перечень задач и сценариев, выполняемых после их установки, чтобы проверить работоспособность всех функций. Это может быть открытие папки "Входящие", вызов команды отправки и получения почты с проверкой обновленного содержимого папок, переход на главную страницу сайта в SharePoint, вызов страницы поиска в корпоративной среде и проверка результатов, возвращаемых поисковым запросом.

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

  • Выясните, какие устройства расположены между клиентским компьютером и точкой выхода (например, прокси-сервер).

    • Эта информация необходима для оценки контекста (IP-адреса, тип устройства и т. д.), в котором возникает проблема с производительностью.

    • Прокси-серверы часто служат точками выхода, и вы можете проверить в настройках браузера, указан ли там такой сервер.

    • Существуют средства сторонних производителей, предназначенные для анализа сетей и составления их карт, однако проще и безопаснее всего запросить данные об устройствах у одного из специалистов, которые обслуживают вашу сеть.

  • Выясните, каким поставщиком услуг Интернета вы пользуетесь, найдите его контактную информацию и уточните, какова ваша пропускная способность.

  • Определите, какие ресурсы в вашей организации выделены для устройств, расположенных между клиентом и точкой выхода, и выясните, к кому можно обратиться по срочным вопросам, связанным с производительностью.

Ниже перечислены важные базовые показатели, которые можно определить с помощью простых инструментов.

  • Время доступа (в миллисекундах) с вашего клиентского компьютера к точке выхода

  • Время доступа (в миллисекундах) с точки выхода к службе Office 365

  • Географическое расположение сервера, который выполняет сопоставление URL-адресов, открываемых в среде Office 365

  • Скорость сопоставления DNS (в миллисекундах) вашего поставщика услуг Интернета, несоответствия во времени доставки пакетов (колебания сетевой задержки), время отправки и загрузки в миллисекундах

Если вы не знаете, как выполняются эти действия, мы предложим вам более подробные инструкции в этой статье.

Что такое базовые показатели?

Когда что-то пошло не так, это становится очевидно. Однако если у вас нет данных о производительности за прошлые периоды, то у вас нет контекста, позволяющего понять, насколько далеко могут зайти проблемы — и когда это случится. Поэтому без базовых показателей у вас нет ключа к решению паззла — картинки, состоящей из множества элементов. При поиске и устранении проблем важную роль играет база для сравнения. Определить простейшие базовые показатели несложно. Регулярное выполнение этой задачи можно поручить операционному отделу. Предположим, например, что у вас примерно такая схема подключения:

Схема сети с указанием клиента, прокси-сервера и облачной службы Office 365.

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

Основные сети, включая клиента, прокси-сервер и облачные службы, а также предлагаемые средства, включая PSPing, TraceTCP и сетевые трассировки.

Варианты названы простым и сложным с учетом количества знаний и опыта, необходимых для получения данных о производительности. Сетевая трассировка занимает больше времени по сравнению с использованием средств командной строки, таких как PsPing и TraceTCP. Эти два инструмента были выбраны потому, что они не используют пакеты ICMP, которые блокируются службами Office 365, а также потому, что они возвращают время в миллисекундах, необходимое запросу на то, чтобы покинуть клиентский компьютер или прокси-сервер (при наличии соответствующего доступа) и добраться до среды Office 365. Для каждого отдельного участка маршрута от одного компьютера до другого указывается значение времени, которое затем суммируется, что очень удобно для замера базовых показателей. Также важен тот факт, что в этих средствах командной строки в команду можно добавить номер порта. Это необходимо, так как обмен данными с Office 365 осуществляется по порту 443, который используется протоколами SSL и TLS. В зависимости от ситуации более удобными могут оказаться и другие инструменты. Программное обеспечение Майкрософт может не поддерживать какие-то из них, поэтому если по какой-то причине у вас не получается воспользоваться PsPing и TraceTCP, выполните сетевую трассировку с помощью инструмента наподобие Netmon.

Замерить базовые показатели можно до начала рабочего дня, затем в момент, когда ресурсы активно используется, а также после завершения рабочего дня. В результате вы можете получить структуру папок наподобие следующей:

Способы упорядочения данных производительности по папкам.

Вам также следует выбрать схему именования для своих файлов. Вот несколько примеров.

  • 09_фев_2015_09_00MSK_Базовый_Netmon_клиент-выход_нормально

  • 10_янв_2015_15_00UTC_Базовый_PsPing_клиент-выход_в_обход_прокси_МЕДЛЕННО

  • 08_фев_2015_14_00UTS_Базовый_ПЛОХО

  • 08_фев_2015_08_30МСК_Базовый_Хорошо

Можно следовать разным схемам, однако для начала рекомендуем использовать формат <dateTime><what's happening in the test>. Точные и понятные имена файлов очень помогут вам, когда дело дойдет до поиска и устранения неполадок. Вы сможете сказать: 8 февраля мы провели два замера, один показал хорошую производительность, а второй плохую; сравним им. Это очень полезно при поиске неполадок.

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

Зачем собирать данные о производительности на этапе пилотного развертывания?

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

В небольшой компании, где пилотный проект не развертывается и все пользователи сразу приступают к работе с сервисами, также необходимо следить за показателями производительности: их можно будет продемонстрировать человеку, который будет заниматься поиском и устранением проблем (если они у вас возникнут). Например, вы можете заметить, что за время, которое занимает отправка небольшого изображения, вы теперь успеваете прогуляться по офису, хотя раньше все происходило моментально.

Способы сбора базовых показателей

Любой план действий для устранения проблем с производительностью основан как минимум на указанных ниже данных.

  • Клиентский компьютер, который вы используете (тип компьютера или другого устройства, IP-адрес, действия, приведшие к неполадкам).

  • Расположение клиентского компьютера (например, используется ли VPN-подключение пользователя к сети, работает ли он удаленно или расположен в интрасети организации).

  • Точка выхода клиентского компьютера из сети (точка, где трафик покидает пределы вашей организации и переходит к поставщику услуг Интернета или прямо в Интернет).

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

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

Простые методы

С помощью этих простых методов вы научитесь измерять, понимать и хранить простые базовые показатели производительности, которые позволяют понять, насколько эффективно работают у вас сервисы Office 365. Вот простая схема, которую мы уже рассматривали раньше:

Основные сети, включая клиента, прокси-сервер и облачные службы, а также предлагаемые средства, включая PSPing, TraceTCP и сетевые трассировки.

Примечания : 

  • На этом рисунке есть TraceTCP — полезный инструмент, позволяющий определить время (в миллисекундах) обработки запроса, а также количество сетевых переходов (подключений от одного компьютера к другому), которые необходимы запросу, чтобы добраться до точки назначения. TraceTCP также возвращает имена серверов, которые используются на этих переходах и могут быть полезны сотруднику службы поддержки Microsoft Office 365, с которым вы будете общаться.

  • Команды TraceTCP могут выглядеть очень просто:

  • tracetcp.exe outlook.office365.com:443

  • Не забудьте указать в команде номер порта.

  • Программу TraceTCP можно загрузить бесплатно, однако она работает на основе Wincap. Wincap — инструмент, который также используется и устанавливается средством Netmon. Мы используем Netmon в разделе, посвященном более сложным методам.

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

С точкой выхода (в данном случае — прокси-сервером) можно действовать по-разному. Можно провести трассировку из точки 1 в точку 2 и из точки 2 в точку 3, а затем сложить числа в миллисекундах, чтобы получить общее время маршрута из вашей сети. Вы также можете настроить маршрут в обход прокси-сервера для адресов в среде Office 365. В крупных сетях, в которых есть брандмауэр, обратный прокси-сервер или то и другое, может потребоваться добавить на прокси-сервере исключения, которые пропускают трафик на определенные URL-адреса. Список конечных точек, используемых в Office 365, см. в статье Диапазоны IP-адресов и URL-адреса Office 365. Если ваш прокси-сервер выполняет проверку подлинности, начните с выполнения теста для перечисленных ниже исключений.

  • Порты 80 и 443

  • Протоколы TCP и HTTPS

  • Соединения, исходящие на любой из следующих URL-адресов:

  • *.microsoftonline.com

  • *.microsoftonline-p.com

  • *.sharepoint.com

  • *.outlook.com

  • *.lync.com

  • osub.microsoft.com

У пользователей должен быть доступ к этим адресам без участия прокси-сервера и проверки подлинности. В небольшой сети эти адреса можно добавить в список обхода прокси-сервера в веб-браузере.

В Internet Explorer выберите Сервис > Свойства браузера > Подключения > Настройка сети > Дополнительно. На вкладке дополнительных параметров также указываются прокси-сервер и его порт. Чтобы кнопка Дополнительно стала доступна, может потребоваться установить флажок Использовать прокси-сервер для локальной сети. Установите флажок Не использовать прокси-сервер для локальных адресов. Нажав кнопку Дополнительно, вы откроете текстовое поле, в котором можно задать исключения. Введите указанные выше URL-адреса с подстановочными знаками через точку с запятой:

*.microsoftonline.com; *.sharepoint.com

Настроив обход прокси-сервера, вы сможете использовать команду ping и программу PsPing для обращения непосредственно к URL-адресам Office 365. После этого необходимо отправить запрос ping на адрес outlook.office365.com. Если вы используете PsPing или другой инструмент, в котором в команду можно добавить номер порта, отправьте запрос на адрес portal.microsoftonline.com:443, чтобы узнать среднее время кругового пути в миллисекундах.

Время кругового пути — это числовое значение, определяющее, сколько миллисекунд необходимо HTTP-запросу, чтобы добраться до сервера (например, outlook.office365.com) и получить ответ, подтверждающий, что ваш запрос действительно поступил на сервер. Иногда этот показатель обозначается аббревиатурой RTT (round trip time). Как правило, это небольшое значение.

Эту проверку нужно проводить с помощью PsPing или другого инструмента, который не использует пакеты ICMP, потому что серверы Office 365 блокируют их.

Определение общего времени кругового пути в миллисекундах с помощью PsPing непосредственно для URL-адреса Office 365

  1. Откройте окно командной строки с повышенными правами с помощью перечисленных ниже действий.

    1. Нажмите кнопку Пуск.

    2. В поле Начать поиск введите cmd и нажмите клавиши CTRL+SHIFT+ВВОД.

    3. Если появится диалоговое окно Контроль учетных записей, подтвердите в нем выполняемое действие и нажмите кнопку Продолжить.

  2. Перейдите в папку, в которой установлена программа (в данном случае — PsPing), и отправьте запросы к следующим URL-адресам Office 365:

    • psping portal.office.com:443

    • psping microsoft-my.sharepoint.com:443

    • psping outlook.office365.com:443

    • psping www.yammer.com:443

      Команда PSPing переходит на microsoft-my.sharepoint.com через порт 443.

Не забудьте указать номер порта 443. Помните о том, что обмен данными с серверами Office 365 осуществляется по зашифрованному каналу. Если отправить с помощью PsPing запрос, не указав номер порта, он вернет ошибку. Проверив связь с этим небольшим списком адресов, обратите внимание на среднее время в миллисекундах (мс). Вам нужен именно этот показатель.

Иллюстрация выполнения команды PSPing между клиентом и прокси-сервером с указанием времени кругового пути, равного 2,8 миллисекунды.

Если вы не знаете, как настроить обход прокси-сервера, и предпочитаете пошаговые инструкции, сначала вам потребуется узнать имя прокси-сервера. В Internet Explorer выберите Сервис > Свойства браузера > Подключения > Настройка сети > Дополнительно. Прокси-сервер указан на вкладке Дополнительно. Проверьте с ним связь из командной строки, выполнив указанные ниже действия.

Проверка связи с прокси-сервером и определение времени кругового пути в миллисекундах для участка 1–2

  1. Откройте окно командной строки с повышенными правами с помощью перечисленных ниже действий.

    1. Нажмите кнопку Пуск.

    2. В поле Начать поиск введите cmd и нажмите клавиши CTRL+SHIFT+ВВОД.

    3. Если появится диалоговое окно Контроль учетных записей, подтвердите в нем выполняемое действие и нажмите кнопку Продолжить.

  2. Введите команду ping <имя или IP-адрес прокси-сервера из параметров браузера> и нажмите клавишу ВВОД. Если у вас установлена программа PsPing или другой инструмент, вы можете воспользоваться им.

    Вот несколько примеров команды:

    • ping ourproxy.ourdomain.industry.business.com

    • ping 155.55.121.55

    • ping ourproxy

    • psping ourproxy.ourdomain.industry.business.com:80

    • psping 155.55.121.55:80

    • psping ourproxy:80

  3. Когда программа трассировки прекратит отправлять тестовые пакеты, она выдаст краткие результаты, в которых будет указано среднее время в миллисекундах — именно то значение, которое вам необходимо. Создайте снимок экрана с окном командной строки и сохраните его, используя разработанную вами схему именования. На данном этапе это значение также имеет смысл добавить на схему.

Предположим, вы провели трассировку рано утром и запрос с вашего клиента достаточно быстро добрался до прокси-сервера (или до сервера, через который вы выходите в Интернет). В этом случае вы можете получить примерно такие значения:

Рисунок с указанием времени кругового пути от клиента на прокси-сервер, равного 2,8 миллисекунды.

Если у вашего клиентского компьютера есть непосредственный доступ к прокси-серверу (или точке выхода), вы можете выполнить проверку для следующего участка, удаленно подключившись к серверу и выполнив на нем команду PsPing для URL-адреса Office 365. Если у вас нет доступа к этому компьютеру, обратитесь за помощью к специалистам, обслуживающим вашу сеть, и попросите их сообщить вам полученные значения. Если это невозможно, выполните запрос PsPing для URL-адреса Office 365 и сравните его со значением времени, которое вернула программа PsPing или Ping для прокси-сервера.

Например, если время доставки пакета от клиента до URL-адреса Office 365 составляет 51,84 мс, а время доставки с клиента до прокси-сервера (или точки выхода) — 2,8 мс, это означает, что время доставки пакета с точки выхода до серверов Office 365 равно 49,04 мс. И аналогично: если во время рабочего дня программа PsPing вернула значение 12,25 мс для участка от клиента до прокси-сервера и 62,01 мс для участка от клиента до URL-адреса Office 365, то среднее значение для участка от прокси-сервера до сервера Office 365 составляет 49,76 мс.

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

С точки зрения поиска и устранения проблем иногда даже эти базовые показатели могут послужить источником полезной информации. Например, если выяснится, что задержка на маршруте от прокси-сервера или точки выхода до URL-адреса Office 365 обычно составляет от 40 до 59 миллисекунд, а задержка на участке от клиента до прокси-сервера или точки выхода — от 3 до 7 миллисекунд (в зависимости от загруженности сети в то или иное время дня), то вы поймете, что возникла какая-то проблема, если последние три проверки связи с клиента на прокси-сервер вернули значение 45 миллисекунд.

Сложные методы

Если вы хотите подробнее выяснить, что происходит с вашими интернет-запросами на серверы Office 365, вам потребуется выполнить сетевую трассировку. Для этого подойдет любая программа (HTTPWatch, Netmon, Message Analyzer, Wireshark, Fiddler, Developer Dashboard и т. п.), способная фиксировать и фильтровать сетевой трафик. В этом разделе объясняется, почему лучше использовать сразу несколько инструментов (они позволят получить более полное представление о возникшей проблеме). Во время проверок некоторые из этих инструментов сами по себе выступают в качестве прокси-серверов. В статье План устранения неполадок с производительностью для Office 365 перечислены следующие инструменты: Netmon 3.4, HTTPWatch или WireShark.

Определение базовых показателей производительности — простая часть этого метода, и основная часть действий здесь такая же, как и при поиске и устранении неполадок с производительностью. Более сложные методы замера базовых показателей производительности предполагают трассировку сети и сохранение полученных результатов. В большинстве примеров в этой статье фигурирует среда SharePoint Online, однако вам следует составить список стандартных действий для сервисов Office 365, входящих в вашу подписку, для которых вы хотите провести проверку. Ниже приведен пример определения базовых показателей.

  • Список базовых показателей для SPO, шаг 1. Откройте домашнюю страницу веб-сайта SPO и выполните сетевую трассировку. Сохраните результаты.

  • Список базовых показателей для SPO, шаг 2. Выполните поиск по какому-нибудь запросу (например, имени вашей организации) в службе поиска в корпоративной среде и проведите сетевую трассировку. Сохраните результаты.

  • Список базовых показателей для SPO, шаг 3. Отправьте большой файл в библиотеку документов SharePoint Online и выполните сетевую трассировку. Сохраните результаты.

  • Список базовых показателей для SPO, шаг 4. Откройте домашнюю страницу веб-сайта OneDrive и выполните сетевую трассировку. Сохраните результаты.

Этот список должен содержать наиболее важные стандартные действия, которые ваши пользователи выполняют со средой SharePoint Online. Обратите внимание на то, что на последнем шаге (трассировка маршрута до OneDrive для бизнеса) мы получаем значение, которое позволяет сравнить нагрузку на домашние страницы SharePoint Online (организации часто настраивают ее в соответствии со своими потребностями) и OneDrive для бизнеса (в которую, напротив, редко вносятся какие-либо изменения). Это простейшая проверка, которую можно выполнить в ситуации, когда сайт SharePoint Online загружается слишком долго. Полученную разницу в результатах можно сохранить.

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

Если вам нужно устранить проблему с производительностью прямо сейчас, вам потребуется выполнить сетевую трассировку в момент, когда проблема имеет место. Вам понадобится инструмент для сбора журналов, а также план действий по поиску и устранению неполадок, позволяющий получить всю необходимую информацию. Сначала необходимо зафиксировать дату и время проведения проверки, чтобы файлы, которые вы сохраняете в соответствующей папке, отражали момент тестирования. Далее нужно выбрать именно те действия, которые понадобятся вам для поиска и устранения возникшей проблемы. Помните о главном: если проблема связана только с Outlook, обязательно запишите, что неполадки возникают только с одним из сервисов Office 365. Точно определив масштаб проблемы, вы сможете акцентировать все внимание именно на той неполадке, которую способны устранить.

См. также

Управление конечными точками Office 365

Совершенствование навыков
Перейти к обучению
Первоочередный доступ к новым возможностям
Присоединиться к программе предварительной оценки Office

Были ли сведения полезными?

Спасибо за ваш отзыв!

Благодарим за отзыв! Возможно, будет полезно связать вас с одним из наших специалистов службы поддержки Office.

×