Налаштування продуктивності Office 365 за допомогою базових планів і журналу продуктивності

Є кілька простих способів перевірити продуктивність з’єднання між службою Office 365 і вашим бізнесом, що допоможе створити підґрунтя для вашої досяжності. Знаючи історію продуктивності з’єднань свого клієнтського комп’ютера, можна прогнозувати виникнення помилок, вчасно виявляти їх і запобігати їх появі.

Якщо ви ще не знайомі з проблемами продуктивності, див. цю статтю, щоб отримати відповіді на поширені запитання, наприклад дізнатися, що проблема пов’язана з продуктивністю та не є подією служби Office 365. Як спланувати тривалу підтримку високої продуктивності? Як відстежувати продуктивність? Якщо вас цікавить відповідь на будь-яке з цих запитань, а робоча група або клієнти стикаються з низькою продуктивністю під час використання служби Office 365, читайте далі.

Увага! : Саме зараз сталася неполадка продуктивності між клієнтом і службою Office 365? Дотримуйтесь інструкцій зі статті План усунення неполадок продуктивності для Office 365.

Корисні відомості про продуктивність служби Office 365

Службу Office 365 розташовано у виділеній мережі Microsoft із високою пропускною здатністю, за станом якої постійно стежать не автоматичні засоби, а реальні люди. Частина ролі підтримки хмари 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 відобразиться червона або жовта піктограма, також може знизитися продуктивність роботи клієнтських комп’ютерів під час підключення до служби Office 365. Так, якщо в розділі "Поточний стан справності" відображається червона піктограма, а поряд з елементом Exchange – текст Триває дослідження, можливо, надалі вам зателефонують кілька людей з організації, які скаржитимуться на низьку продуктивність клієнтських поштових скриньок, що використовують службу Exchange Online. У такому випадку доцільно припустити, що на продуктивність служби Exchange Online просто негативно вплинули неполадки в роботі служби.

Приладна дошка справності в Office 365, на якій усі робочі навантаження показано зеленим, за винятком рішення Exchange, для якого відображається повідомлення про те, що роботу служби відновлено.

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

Зображення приладної дошки справності в службі Office 365, на якій відображається повідомлення про відновлення служби Exchange Online і пояснюються причини такого відновлення.

Неполадка продуктивності – це не подія служби, хоча такі події можуть зумовлювати зниження продуктивності. Неполадка продуктивності виглядає ось так:

  • Неполадка продуктивності відбувається незалежно від того, що звітує Центр адміністрування Office 365 про службу в розділі Поточний стан справності.

  • Відносно безпроблемні раніше дії тривають довго або ніколи не завершуються.

  • Також можна відтворити неполадку або принаймні усвідомлювати, що це станеться, якщо виконати ряд певних дій.

  • Якщо неполадка виникає періодично, є певна схема, наприклад, відомо, що до 10:00 телефонують користувачі, які не можуть отримати надійний доступ до служби Office 365, і приблизно опівдні дзвінки припиняють надходити.

Можливо, це чи не занадто щось нагадує. Щойно ви дізналися, що це неполадка продуктивності, виникає запитання про подальші дії. Саме про це йдеться в решті цієї статті.

Визначення й перевірка неполадки продуктивності

Зазвичай неполадки продуктивності виявляються з часом, тому виявити фактичну неполадку може бути складно. Потрібно точно сформулювати проблему, докладно вивчити контекст неполадки, а потім, щоб досягти успіху, створити дії з перевірки, які можна повторити. У протилежному випадку ви можете зазнати поразки не через власну провину. Навіщо? Нижче наведено кілька прикладів формулювання проблем, які не надають достатньо відомостей.

  • Перехід із поштової скриньки до календаря раніше був непомітний, а став суттєвою перервою в роботі. Чи можна повернути все як було раніше?

  • Передавання файлів до служби SharePoint Online триває цілу вічність. Чому після обіду ця дія виконується повільно, а в будь-який інший час – швидко? Чи можна просто зробити цей процес швидким?

У згаданих вище формулюваннях проблем міститься кілька важких завдань. Так, потрібно мати справу з великою кількістю неясностей. Нижче наведено приклади.

  • Невідомо, як перехід із поштової скриньки до календаря відбувається на ноутбуку.

  • Що означає слово "швидкий", коли користувач каже: "Чи можна просто зробити цей процес швидким"?

  • Скільки часу передбачає поняття "цілу вічність"? Це кілька секунд або хвилин, чи користувач може піти на обід, і процес буде завершено через десять хвилин після його повернення?

Усе це так, якщо не брати до уваги, що адміністратор і засіб усунення неполадок не можуть дізнатися багато подробиць із таких формулювань проблем. Наприклад, коли саме неполадка почала виникати. Що користувач працює вдома та помічає повільний перехід лише під час роботи в домашній мережі. Що користувач повинен запустити на локальному клієнтському комп’ютері кілька інших програм, які потребують значного обсягу оперативної пам’яті, або користувач працює в старішій версії операційної системи чи не виконав останні оновлення.

Коли користувачі повідомляють про наявність неполадок продуктивності, можна зібрати значний обсяг відомостей. Збирання таких відомостей – це частина процесу визначення або дослідження проблеми. Нижче наведено список основних запитань, який полегшує збирання відомостей про неполадку продуктивності. Цей список не вичерпний, однак із нього можна почати складати власний перелік:

  • У яку дату й час сталася неполадка?

  • Який використовувався тип клієнтського комп’ютера і тип підключення до корпоративної мережі (VPN, проводове, безпровідне)?

  • Ви працювали віддалено чи в офісі?

  • Чи призводило виконання аналогічних дій на іншому комп’ютері до таких самих наслідків?

  • Повторіть кроки, які призводять до виникнення неполадки, щоб записати ці дії.

  • Наскільки низька продуктивність роботи (у секундах або хвилинах)?

  • Яке у вас географічне розташування?

Певні запитання з цього переліку більш явні за інші. Майже всі розуміють, що людині, яка виправляє неполадки, потрібно знати точні дії, щоб відтворити неполадку. Зрештою, як інакше можна записати, що сталося, і перевірити, чи вирішено неполадку? Менш очевидні запитання "У яку дату й час сталася неполадка?" та "Яке у вас географічне розташування?", відповіді на них можна використовувати разом. Час роботи користувача також впливає: кілька годин різниці в часі можуть означати, що вже відбувається технічне обслуговування певних частин мережі компанії. Так, якщо компанія застосовує гібридне розгортання, наприклад гібридний пошук SharePoint, який може запитувати індекси пошуку водночас у компонентах служби SharePoint Online і локального сервера SharePoint Server 2013, то під час пошуку на локальній фермі можуть тривати оновлення. Якщо компанію повністю розташовано в хмарі, обслуговування системи може охоплювати додавання або видалення мережевого обладнання, упровадження оновлень на рівні компанії чи внесення змін до служби DNS або іншої базової інфраструктури.

Діагностика неполадки продуктивності дещо нагадує вивчення місця злочину: потрібно бути точним і спостережливим, щоб на основі отриманих даних зробити правильні висновки. Щоб це зробити, потрібно точно сформулювати визначення проблеми, зібравши необхідні докази. Визначення проблеми має містити контексти комп’ютера та користувача, час початку проблеми й точні дії, які спричинили неполадку продуктивності. Це визначення проблеми має бути та залишатися найважливішою сторінкою у ваших нотатках. Аналізуючи визначення проблеми після роботи над вирішенням, ви виконуєте дії з перевірки й доведення того, що виконані дії виправили цю неполадку. Це вкрай важливо знати під час роботи над проблемою.

Ви знаєте, яка була продуктивність, коли все було добре?

Якщо відповідь вам невідома, ніхто про це не знає. Ні в кого не було точних цифр. Це означає, що ніхто не зможе відповісти на просте запитання "Скільки секунд зазвичай потрібно для відображення поштової скриньки в службі Office 365?" або "Скільки зазвичай потрібно часу для початку наради керівників організації в Lync Online?". Це часто трапляється в багатьох компаніях.

Тут бракує опорної точки продуктивності.

Опорні точки містять контекст для вашої продуктивності. Ви маєте вимірювати опорну точку іноді або часто залежно від потреб вашої компанії. Якщо у вас велика компанія, то експлуатаційна група може виміряти опорні точки для наявного локального середовища. Наприклад, якщо ви інсталюєте оновлення системи безпеки на всі сервери Exchange у перший понеділок місяця і на всі сервери SharePoint у третій понеділок місяця, ваша експлуатаційна група, можливо, має список завдань і сценаріїв, які виконуються після інсталяції оновлень системи безпеки, щоб забезпечити робочий стан критично важливих функцій. Такими завданнями можуть бути, наприклад, відкриття поштової скриньки, натискання кнопки "Надіслати/отримати" та перевірка оновлення папок. На сайті SharePoint це може бути перегляд головної сторінки сайту, перехід на сторінку корпоративного пошуку та здійснення пошуку, який повертає результати.

Якщо ваші програми знаходяться в Office 365, то однією з основних опорних точок, яку можна виміряти, є час (у мілісекундах) проходження пакетів від клієнтського комп’ютера всередині мережі до вихідної точки чи точки, в якій ви залишаєте локальну мережу та переходите в Office 365. Нижче наведено кілька корисних опорних точок, які можна дослідити та записати.

  • Визначте пристрої між клієнтським комп’ютером і вихідною точкою, наприклад проксі-сервер.

    • Знадобиться отримати деякі відомості про свої пристрої (IP-адреса, тип пристрою тощо), щоб полегшити виявлення проблем, які виникають.

    • Проксі-сервери – це поширені вихідні точки. У браузері можна перевірити, який проксі-сервер використовується.

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

  • Визначте свого інтернет-провайдера (ISP), запишіть його контактну інформацію та запитайте в нього, скільки каналів і смуг пропускання у вас є.

  • Визначте у своїй компанії ресурси для пристроїв між своїм клієнтським комп’ютером і вихідною точкою або визначте контакт для критичних ситуацій, з яким можна обговорити неполадки в мережі.

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

  • Час проходження пакетів від вашого клієнтського комп’ютера до вихідної точки в мілісекундах

  • Час проходження пакетів від вихідної точки до 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_02_2015_0900EET_PerfBaseline_Netmon_ClientToEgress_Normal

  • 10_01_2015_1500EET_PerfBaseline_PsPing_ClientToO365_bypassProxy_SLOW

  • 08_02_2015_1400EET_PerfBaseline_BADPerf

  • 08_02_2015_0830EET_PerfBaseline_GoodPerf

Для цього є багато різних способів, але використання формату <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 можна завантажити безкоштовно, однак вона використовує у своїй роботі програму WinPcap. WinPcap – це засіб, який також використовує й інсталює програма Netmon. Програма Netmon також використовується в розділі додаткових методів.

Якщо у вас є кілька робочих місць, набір клієнтських даних потрібно зберігати в кожному з цих розташувань. Таке тестування визначає затримку, виражену в цьому випадку числовим значенням, яке описує часовий проміжок між моментом, коли клієнт надсилає запит у службу Office 365, і моментом, коли служба надає відповідь на цей запит. Тестування починається в домені на клієнтському комп’ютері та має за мету виміряти час кругового обходу, за який запит проходить із мережі через вихідну точку, Інтернет до служби Office 365 і назад.

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

  • Порти 80 і 443

  • Протоколи TCP й HTTP

  • Підключення з виходом до будь-якої з таких 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. Наступний крок – тестування перевірки зв’язку з адресою outlook.office365.com. Якщо ж використовується службова програма PsPing або інший засіб, який дає змогу долучити номер порту до команди, виконайте перевірку зв’язку PsPing з адресою portal.microsoftonline.com:443, щоб визначити середній час кругового обходу в мілісекундах.

Час кругового обходу (RTT) – це числове значення, за допомогою якого вимірюється час, потрібний для надсилання запиту HTTP на сервер, наприклад outlook.office365.com, і отримання відповіді, яка свідчить, що сервер підтверджує отримання запиту. Інколи цей термін подається скорочено як абревіатура RTT. Бажано, щоб це був відносно невеликий проміжок часу.

Для виконання цього тестування потрібно використовувати службову програму PsPing або інший засіб, який не застосовує пакети ICMP, заблоковані службою Office 365.

Використання службової програми PsPing для отримання даних про загальний час кругового обходу в мілісекундах безпосередньо за URL-адресою Office 365

  1. Запустіть командний рядок у режимі адміністратора, виконавши наведені нижче дії.

    1. Натисніть кнопку Пуск.

    2. У полі Розпочати пошук введіть cmd, потім натисніть сполучення клавіш Ctrl+Shift+Enter.

    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, що передається на порт 443 сайту microsoft-my.sharepoint.com.

Переконайтеся, що долучено номер порту 443. Пам’ятайте, що служба Office 365 використовує зашифрований канал. Якщо службова програма PsPing використовується без номера порту, надіслати запит не вдасться. Перевіривши зв’язок із коротким списком, визначте середній час у мілісекундах (мс). Це саме те, що потрібно записати!

Схема, що ілюструє виконання команди PSPing, яка надсилається з клієнта на проксі-сервер, з часом приймання-передавання 2,8 мілісекунди.

Якщо для вас зручніше не обходити проксі-сервер і виконувати дії поступово, спочатку потрібно визначити ім’я проксі-сервера. У браузері Internet Explorer послідовно виберіть елементи Знаряддя > Властивості браузера > Підключення > Настройки локальної мережі > Додатково. На вкладці Додатково можна також знайти в списку свій проксі-сервер. Перевірте зв’язок із цим проксі-сервером у командному рядку, виконавши наведене нижче завдання.

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

  1. Запустіть командний рядок у режимі адміністратора, виконавши наведені нижче дії.

    1. Натисніть кнопку Пуск.

    2. У полі Розпочати пошук введіть cmd, потім натисніть сполучення клавіш Ctrl+Shift+Enter.

    3. Якщо відображається діалогове вікно Служба захисту користувачів, підтвердьте, що вам потрібно виконати цю дію, потім натисніть кнопку Продовжити.

  2. Введіть ping <ім’я проксі-сервера, який використовує браузер, або IP-адреса проксі-сервера>, потім натисніть клавішу Enter. Якщо інстальовано службову програму 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 мілісекунди, а між клієнтським комп’ютером і URL-адресою Office 365 – 62,01 мілісекунди, то середнє значення часу для проходження пакетів між вихідною точкою проксі-сервера та URL-адресою Office 365, становить 49,76 мілісекунди.

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

Якщо у вас просто збережені ці опорні точки, ви вже маєте певні відомості, корисні для виправлення неполадок. Наприклад, якщо зазвичай значення затримки від проксі-сервера або вихідної точки до URL-адреси Office 365 становить близько 40–59 мілісекунд, а від клієнтського комп’ютера до проксі-сервера або вихідної точки – приблизно 3–7 мілісекунд (залежно від обсягу мережевого трафіку в цей час доби), то можна бути впевненим у наявності неполадки за умови, що в останніх трьох опорних точках між клієнтським комп’ютером і проксі-сервером або вихідною точкою значення затримки дорівнює 45 мілісекундам.

Додаткові методи

Якщо вас справді цікавить, що відбувається з інтернет-запитами до служби Office 365, вам потрібно ознайомитись із поняттям "трасування мережі". Незалежно від того, який засіб ви виберете для трасування (HTTPWatch, Netmon, Message Analyzer, Wireshark, Fiddler, Приладна дошка розробника тощо), він працюватиме, якщо зможе записувати та фільтрувати мережевий трафік. З цього розділу видно, що зручніше користуватися кількома такими засобами, щоб отримати повнішу картину неполадки. Під час тестування деякі з цих засобів також діють як повноправні проксі-сервери. Засоби, які згадуються в статті порівняння, План усунення неполадок продуктивності для 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, з яким ми вас можемо з’єднати.

×