ضبط الأداء 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. هذه المعلومات سوف تضعك قبل المنحنى عند محاولة حل مشكلة في الأداء. فيما يلي ارتباط إلى أوصاف الخدمة Microsoft 365 Office 365. هذا مركز مركزي، وجميع الخدمات التي تقدمها Office 365 لديها ارتباط ينتقل إلى أوصاف الخدمة الخاصة بها من هنا. وهذا يعني، إذا كنت بحاجة إلى الاطلاع على الحدود القياسية ل SharePoint Online، على سبيل المثال، يمكنك النقر فوق SharePoint وصف الخدمة عبر الإنترنت وتحديد موقع قسم حدود SharePoint عبر الإنترنت.
تأكد من الانتقال إلى استكشاف الأخطاء وإصلاحها مع فهم أن الأداء هو مقياس منزلق. الأمر لا يتعلق بتحقيق قيمة مثالية والحفاظ عليها بشكل دائم. ستكون المهام ذات النطاق الترددي العالي أحيانا، مثل إلحاق عدد كبير من المستخدمين، أو إجراء عمليات ترحيل كبيرة للبيانات، مرهقة، لذا خطط لتأثيرات الأداء بعد ذلك. يجب أن تكون لديك فكرة تقريبية عن أهداف الأداء الخاصة بك، ولكن العديد من المتغيرات تلعب في الأداء، لذلك يختلف الأداء.
لا يتعلق استكشاف أخطاء الأداء وإصلاحها ببلوغ أهداف محددة والحفاظ على هذه الأرقام إلى أجل غير مسمى، بل يتعلق الأمر بتحسين الأنشطة الحالية، بالنظر إلى جميع المتغيرات.
حسنا، كيف تبدو مشكلة الأداء؟
أولا، تحتاج إلى التأكد من أن ما تواجهه هو بالفعل مشكلة في الأداء وليس حادث خدمة. تختلف مشكلة الأداء عن حادث الخدمة في Office 365. إليك كيفية التمييز بينهما.
تحدث أحداث الخدمة عندما تواجه خدمة Office 365 نفسها مشاكل. قد ترى أيقونات حمراء أو صفراء ضمن الحماية الحالية في مركز مسؤولي Microsoft 365. قد تلاحظ أن الأداء على أجهزة الكمبيوتر العميلة المتصلة Office 365 بطيئ. على سبيل المثال، إذا كانت الحالة الصحية الحالية تبلغ عن أيقونة حمراء وشاهدت التحقيق بجانب Exchange، فقد تتلقى أيضا مكالمات من أشخاص في مؤسستك يشكون من أن علب بريد العميل التي تستخدم Exchange Online بطيئة. في هذه الحالة، من المنطقي افتراض أن أداءك Exchange Online كان ضحية لمشكلات الخدمة.
في هذه المرحلة، يجب عليك، أنت المسؤول Office 365، التحقق من الحالة الحالية ثم عرض التفاصيل والمحفوظات، في كثير من الأحيان، لمواكبة الصيانة على النظام. تم إجراء لوحة معلومات الحماية الحالية لتحديثك حول التغييرات التي تمت على الخدمة والمشكلات فيها. الملاحظات والتفسيرات المكتوبة إلى محفوظات الصحة، المسؤول إلى المسؤول، موجودة لمساعدتك على القياس، وإبقائه منشورا حول العمل الجاري.
مشكلة الأداء ليست حادث خدمة، على الرغم من أن الحوادث يمكن أن تسبب أداء بطيئا. تبدو مشكلة الأداء كما يلي:
تحدث مشكلة في الأداء بغض النظر عن مركز الإدارة الذي تقوم الحماية الحالية بالإبلاغ عنه للخدمة.
يستغرق السلوك الذي كان يتدفق وقتا طويلا لإكماله أو عدم اكتماله أبدا.
يمكنك نسخ المشكلة نسخا متماثلا أيضا، أو معرفة أنه سيحدث إذا قمت بالسلسلة الصحيحة من الخطوات.
إذا كانت المشكلة متقطعة، فلا يزال هناك نمط. على سبيل المثال، أنت تعلم أنه بحلول الساعة 10:00 صباحا سيكون لديك مكالمات من المستخدمين الذين لا يمكنهم الوصول دائما إلى Office 365. ستنتهي المكالمات ظهرا.
قد تبدو هذه القائمة مألوفة؛ ربما مألوفة جدا. بمجرد أن تدرك أنها مشكلة في الأداء، يصبح السؤال، "ماذا تفعل بعد ذلك؟" تساعدك بقية هذه المقالة على تحديد ذلك بالضبط.
كيفية تعريف مشكلة الأداء واختبارها
غالبا ما تظهر مشكلات الأداء بمرور الوقت، لذلك قد يكون من الصعب تحديد المشكلة الفعلية. قم بإنشاء بيان مشكلة جيدة مع فكرة جيدة عن سياق المشكلة، ثم تحتاج إلى خطوات اختبار قابلة للتكرار. فيما يلي بعض الأمثلة على عبارات المشاكل التي لا توفر معلومات كافية:
كان التبديل من علبة الوارد إلى التقويم الخاص بي شيئا لم ألاحظه، والآن هو استراحة القهوة. هل يمكنك جعله يعمل كما كان؟
يستغرق تحميل ملفاتي إلى SharePoint Online وقتا طويلا. لماذا يكون بطيئا بعد ظهر اليوم، ولكن في أي وقت آخر، فهو سريع؟ ألا يمكن أن يكون الأمر سريعا؟
هناك العديد من التحديات الكبيرة التي تشكلها بيانات المشكلة أعلاه. وعلى وجه التحديد، هناك الكثير من حالات الغموض التي لا يمكن معالجتها. على سبيل المثال:
من غير الواضح كيف أن التبديل بين علبة الوارد والتقويم يستخدم للعمل على الكمبيوتر المحمول.
عندما يقول المستخدم، "ألا يمكن أن يكون الأمر سريعا"، ما هي "السريعة"؟
كم من الوقت "إلى الأبد"؟ هل هذه عدة ثوان؟ أو عدة دقائق؟ أو هل يمكن للمستخدم تناول الغداء وسينتهي الإجراء بعد 10 دقائق من العودة؟
لا يمكن للمسؤول ومستكشف الأخطاء ومصلحها أن يكون على دراية بتفاصيل المشكلة من عبارات عامة مثل هذه. على سبيل المثال، لا يعرفون متى بدأت المشكلة في الحدوث. قد لا يعرف مستكشف الأخطاء ومصلحها أن المستخدم يعمل من المنزل ولا يرى سوى التبديل البطيء أثناء العمل على شبكته المنزلية. أو أن المستخدم يقوم بتشغيل تطبيقات RAM مكثفة أخرى على العميل المحلي. قد لا يعرف المسؤولون أن المستخدم يقوم بتشغيل نظام تشغيل قديم أو لم يقم بتشغيل التحديثات الأخيرة.
عندما يبلغ المستخدمون عن مشكلة في الأداء، هناك الكثير من المعلومات التي يجب جمعها. يسمى الحصول على المعلومات وتسجيلها تحديد نطاق المشكلة. فيما يلي قائمة تحديد النطاق الأساسية التي يمكنك استخدامها لجمع معلومات حول مشكلات الأداء. هذه القائمة ليست شاملة، ولكنها مكان للبدء:
في أي تاريخ حدثت المشكلة، وما هو وقت اليوم أو الليل تقريبا؟
ما نوع كمبيوتر العميل الذي كنت تستخدمه، وكيف يتصل بشبكة الأعمال (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 ل ISP بالمللي ثانية، وحالات عدم التناسق في وصول حزم البيانات (تشويش الشبكة)، وتحميل أوقات التنزيل وتنزيلها بالمللي ثانية
إذا لم تكن على دراية بكيفية تنفيذ هذه الخطوات، فسنتناول المزيد من التفاصيل في هذه المقالة.
ما هو الأساس؟
ستعرف التأثير عندما يصبح سيئا، ولكن إذا كنت لا تعرف بيانات الأداء التاريخية الخاصة بك، فمن غير الممكن أن يكون لديك سياق لمدى سوءها، ومتى. لذلك بدون أساس، تفتقد الدليل الرئيسي لحل هذا الأمر: الصورة على مربع الألغاز. في استكشاف أخطاء الأداء وإصلاحها، تحتاج إلى نقطة مقارنة. ليس من الصعب أخذ أساسيات الأداء البسيطة. يمكن تكليف فريق العمليات بتنفيذ هذه المهام وفقا لجدول زمني. على سبيل المثال، لنفترض أن اتصالك يبدو كما يلي:
وهذا يعني أنك قمت بالتحقق من فريق الشبكة واكتشفت أنك تركت شركتك للإنترنت من خلال خادم وكيل، وأن الوكيل يعالج جميع الطلبات التي يرسلها الكمبيوتر العميل إلى السحابة. في هذه الحالة، يجب عليك رسم إصدار مبسط من اتصالك يسرد جميع الأجهزة المتداخلة. الآن، أدرج الأدوات التي يمكنك استخدامها لاختبار الأداء بين العميل ونقطة الخروج (حيث تترك شبكتك للإنترنت) وسحابة Office 365.
يتم سرد الخيارات على أنها بسيطة ومتقدمة بسبب مقدار الخبرة التي تحتاجها للعثور على بيانات الأداء. سيستغرق تتبع الشبكة الكثير من الوقت، مقارنة بتشغيل أدوات سطر الأوامر مثل PsPing و TraceTCP. تم اختيار أداتي سطر الأوامر هاتين لأنهما لا يستخدمان حزم ICMP، والتي سيتم حظرها بواسطة Office 365، ولأنهما يعطيان الوقت بالمللي ثانية الذي يستغرقه مغادرة كمبيوتر العميل أو الخادم الوكيل (إذا كان لديك حق الوصول) والوصول إلى Office 365. سينتهي كل وثب فردي من كمبيوتر إلى آخر بقيمة زمنية، وهذا رائع للخطوط الأساسية! بنفس القدر من الأهمية، تسمح لك أدوات سطر الأوامر هذه بإضافة رقم منفذ إلى الأمر، وهذا مفيد لأن Office 365 يتصل عبر المنفذ 443، وهو المنفذ المستخدم من قبل طبقة مآخذ التوصيل الآمنة وأمان طبقة النقل (SSL وTLS). ومع ذلك، قد تكون أدوات الجهات الخارجية الأخرى حلولا أفضل لحالتك. لا تدعم Microsoft كل هذه الأدوات، لذلك إذا لم تتمكن لسبب ما من الحصول على PsPing و TraceTCP للعمل، فانتقل إلى تتبع الشبكة باستخدام أداة مثل Netmon.
يمكنك أخذ خط أساسي قبل ساعات العمل، ومرة أخرى أثناء الاستخدام الكثيف، ثم مرة أخرى بعد ساعات العمل. وهذا يعني أنه قد يكون لديك بنية مجلد تبدو مثل هذا في النهاية:
يجب أيضا اختيار اصطلاح تسمية لملفاتك. فيما يلي بعض الأمثلة:
Feb_09_2015_9amPST_PerfBaseline_Netmon_ClientToEgress_Normal
Jan_10_2015_3pmCST_PerfBaseline_PsPing_ClientToO365_bypassProxy_SLOW
Feb_08_2015_2pmEST_PerfBaseline_BADPerf
30amEST_PerfBaseline_GoodPerf Feb_08_2015_8
هناك الكثير من الطرق المختلفة للقيام بذلك، ولكن استخدام التنسيق <dateTime><what's happening in the test> هو مكان جيد للبدء. سيساعدك الاجتهاد في هذا الأمر كثيرا عندما تحاول استكشاف المشكلات وإصلاحها لاحقا. في وقت لاحق، ستتمكن من القول "لقد أجريت تتبعين في 8 فبراير، واحدة أظهرت أداء جيدا والأخرى أظهرت سيئة، حتى نتمكن من مقارنتها". هذا مفيد لاستكشاف الأخطاء وإصلاحها.
تحتاج إلى طريقة منظمة للحفاظ على الخطوط الأساسية التاريخية الخاصة بك. في هذا المثال، أنتجت الأساليب البسيطة ثلاثة مخرجات لسطر الأوامر وتم جمع النتائج كلقطات شاشة، ولكن قد يكون لديك ملفات التقاط الشبكة بدلا من ذلك. استخدم الأسلوب الذي يناسبك بشكل أفضل. قم بتخزين الخطوط الأساسية التاريخية والرجوع إليها في نقاط تلاحظ فيها تغييرات في سلوك خدمات الإنترنت.
لماذا يتم جمع بيانات الأداء أثناء الإصدار التجريبي؟
لا يوجد وقت أفضل لبدء إنشاء الخطوط الأساسية من أثناء إصدار تجريبي لخدمة Office 365. قد يحتوي مكتبك على الآلاف من المستخدمين، أو مئات الآلاف، أو قد يكون لديه خمسة مستخدمين، ولكن حتى مع عدد قليل من المستخدمين، يمكنك إجراء اختبارات لقياس التقلبات في الأداء. في حالة شركة كبيرة، يمكن إسقاط عينة تمثيلية من عدة مئات من المستخدمين الذين يقومون با التجريبية Office 365 إلى الخارج لعدة آلاف حتى تعرف أين قد تنشأ المشكلات قبل حدوثها.
في حالة شركة صغيرة، حيث يعني الانتقال إلى الخدمة أن جميع المستخدمين ينتقلون إلى الخدمة في نفس الوقت ولا يوجد إصدار تجريبي، احتفظ بمقاييس الأداء بحيث يكون لديك بيانات لإظهارها لأي شخص قد يتعين عليه استكشاف أخطاء عملية ذات أداء سيئ وإصلاحها. على سبيل المثال، إذا لاحظت فجأة أنه يمكنك التنقل في المبنى في الوقت المستغرق لتحميل رسم متوسط الحجم حيث كان يحدث بسرعة.
كيفية جمع الخطوط الأساسية
بالنسبة إلى جميع خطط استكشاف الأخطاء وإصلاحها، تحتاج إلى تحديد هذه الأشياء كحد أدنى:
كمبيوتر العميل الذي تستخدمه (نوع الكمبيوتر أو الجهاز وعنوان IP والإجراءات التي تسببت في المشكلة)
حيث يوجد الكمبيوتر العميل في العالم (على سبيل المثال، سواء كان هذا المستخدم على VPN إلى الشبكة، أو يعمل عن بعد، أو على إنترانت الشركة)
نقطة الخروج التي يستخدمها كمبيوتر العميل من شبكتك (النقطة التي تترك فيها نسبة استخدام الشبكة أعمالك ل ISP أو الإنترنت)
يمكنك معرفة تخطيط الشبكة من مسؤول الشبكة. إذا كنت تستخدم شبكة صغيرة، فقم بإلقاء نظرة على الأجهزة التي تربطك بالإنترنت، ثم اتصل ب ISP إذا كانت لديك أسئلة حول التخطيط. إنشاء رسم للتخطيط النهائي للمرجع الخاص بك.
يتم تقسيم هذا القسم إلى أدوات وأساليب بسيطة لسطر الأوامر، وخيارات أدوات أكثر تقدما. سنغطي الأساليب البسيطة أولا. ولكن إذا كان لديك مشكلة في الأداء الآن، يجب الانتقال إلى الأساليب المتقدمة وتجربة نموذج خطة عمل استكشاف أخطاء الأداء وإصلاحها.
أساليب بسيطة
الهدف من هذه الأساليب البسيطة هو تعلم كيفية أخذ وفهم وتخزين أساسيات الأداء البسيطة بشكل صحيح بمرور الوقت بحيث تكون على علم بالأداء Office 365. فيما يلي الرسم التخطيطي البسيط للبساطة، كما رأيت من قبل:
ملاحظة
يتم تضمين TraceTCP في لقطة الشاشة هذه لأنها أداة مفيدة لإظهار، بالمللي ثانية، المدة التي يستغرقها الطلب للمعالجة، وعدد القفزات على الشبكة، أو الاتصالات من كمبيوتر إلى آخر، التي يستغرقها الطلب للوصول إلى الوجهة. يمكن ل TraceTCP أيضا إعطاء أسماء الخوادم المستخدمة أثناء القفزات، والتي يمكن أن تكون مفيدة لمستكشف أخطاء Microsoft Office 365 ومصلحها في الدعم. > يمكن أن تكون أوامر TraceTCP بسيطة جدا، مثل: > tracetcp.exe outlook.office365.com:443> تذكر تضمين رقم المنفذ في الأمر! > TraceTCP هو تنزيل مجاني، ولكنه يعتمد على Wincap. Wincap هي أداة يتم استخدامها وتثبيتها أيضا بواسطة Netmon. نستخدم أيضا Netmon في قسم الأساليب المتقدمة.
إذا كان لديك مكاتب متعددة، فستحتاج إلى الاحتفاظ بمجموعة من البيانات من عميل في كل موقع من هذه المواقع أيضا. يقيس هذا الاختبار زمن الانتقال، وهو، في هذه الحالة، قيمة رقمية تصف مقدار الوقت بين إرسال عميل لطلب إلى Office 365، Office 365 الاستجابة للطلب. ينشأ الاختبار داخل مجالك على كمبيوتر عميل، ويتطلع إلى قياس رحلة ذهابا وإيابا من داخل الشبكة، من خلال نقطة خروج، عبر الإنترنت Office 365، والعودة.
هناك بعض الطرق للتعامل مع نقطة الخروج، في هذه الحالة، الخادم الوكيل. يمكنك إما التتبع من 1 إلى 2 ثم من 2 إلى 3، ثم إضافة الأرقام بالمللي ثانية للحصول على الإجمالي النهائي إلى حافة الشبكة. أو يمكنك تكوين الاتصال لتجاوز الوكيل لعناوين Office 365. في شبكة أكبر مع جدار حماية أو وكيل عكسي أو مزيج من الاثنين، قد تحتاج إلى إجراء استثناءات على الخادم الوكيل الذي سيسمح بنسبة استخدام الشبكة لتمرير الكثير من عناوين URL. للحصول على قائمة بنقاط النهاية المستخدمة من قبل Office 365، راجع Office 365 نطاقات عناوين URL وعناوين IP. إذا كان لديك وكيل مصادقة، فابدأ باختبار الاستثناءات لما يلي:
المنفذان 80 و443
TCP وHTTPs
الاتصالات الصادرة إلى أي من عناوين URL هذه:
*.microsoftonline.com
*.microsoftonline-p.com
*.sharepoint.com
*.outlook.com
*.lync.com
osub.microsoft.com
يجب السماح لجميع المستخدمين ب الوصول إلى هذه العناوين دون أي تدخل وكيل أو مصادقة. على شبكة أصغر، يجب إضافة هذه إلى قائمة تجاوز الوكيل في مستعرض الويب الخاص بك.
لإضافة هذه إلى قائمة تجاوز الوكيل في Internet Explorer، انتقل إلى > الإعدادات > > المتقدمة لأدوات خيارات > الإنترنت لاتصالات LAN. علامة التبويب المتقدمة هي أيضا المكان الذي ستجد فيه الخادم الوكيل ومنفذ الخادم الوكيل. قد تحتاج إلى النقر فوق خانة الاختيار استخدام خادم وكيل ل LAN، للوصول إلى الزر "خيارات متقدمة ". ستحتاج إلى التأكد من تحديد تجاوز الخادم الوكيل للعناوين المحلية . بمجرد النقر فوق "خيارات متقدمة"، سترى مربع نص حيث يمكنك إدخال الاستثناءات. افصل عناوين URL لأحرف البدل المذكورة أعلاه بعلامات منقوطة، على سبيل المثال:
*.microsoftonline.com; *.sharepoint.com
بمجرد تجاوز الوكيل الخاص بك، يجب أن تكون قادرا على استخدام ping أو PsPing مباشرة على عنوان URL Office 365. الخطوة التالية هي اختبار outlook.office365.com ping. أو، إذا كنت تستخدم PsPing أو أداة أخرى تسمح لك بتوفير رقم منفذ للأمر، فإن PsPing مقابل portal.microsoftonline.com:443 لرؤية متوسط وقت الرحلة ذهابا وإيابا بالمللي ثانية.
وقت الرحلة ذهابا وإيابا، أو RTT، هو قيمة رقمية تقيس المدة التي يستغرقها إرسال طلب HTTP إلى خادم مثل outlook.office365.com والحصول على استجابة تقر بأن الخادم يعرف أنك قمت بذلك. سترى أحيانا هذا مختصرا ك RTT. يجب أن يكون هذا وقتا قصيرا نسبيا.
يجب عليك استخدام PSPing أو أداة أخرى لا تستخدم حزم ICMP المحظورة بواسطة Office 365 من أجل إجراء هذا الاختبار.
كيفية استخدام PsPing للحصول على وقت رحلة ذهابا وإيابا بالكامل بالمللي ثانية مباشرة من عنوان URL Office 365
تشغيل موجه أوامر غير مقيد عن طريق إكمال الخطوات التالية:
انقر فوق "ابدأ".
في مربع "بدء البحث "، اكتب cmd، ثم اضغط على CTRL+SHIFT+ENTER.
إذا ظهر مربع الحوار "التحكم في حساب المستخدم "، فتأكد من أن الإجراء الذي يعرضه هو ما تريده، ثم انقر فوق "متابعة".
انتقل إلى المجلد حيث تم تثبيت الأداة (PsPing في هذه الحالة) واختبر عناوين URL Office 365 هذه:
admin.microsoft.com:443 psping
microsoft-my.sharepoint.com:443 psping
outlook.office365.com:443 psping
www.yammer.com:443 psping
تأكد من تضمين رقم المنفذ 443. تذكر أن Office 365 يعمل على قناة مشفرة. إذا قمت باستخدام PsPing بدون رقم المنفذ، فسيفشل طلبك. بمجرد أن تقوم بالضغط على قائمتك القصيرة، ابحث عن متوسط الوقت بالمللي ثانية (مللي ثانية). هذا ما تريد تسجيله!
إذا لم تكن على دراية بتجاوز الوكيل، وتفضل تنفيذ المهام خطوة بخطوة، فستحتاج أولا إلى معرفة اسم الخادم الوكيل. في Internet Explorer، انتقل إلى إعدادات > خيارات إنترنت > لأدوات > الاتصال > ب LAN المتقدمة. علامة التبويب "خيارات متقدمة " هي المكان الذي سترى فيه الخادم الوكيل مدرجا. Ping هذا الخادم الوكيل في موجه الأوامر عن طريق إكمال هذه المهمة:
ل ping الخادم الوكيل والحصول على قيمة رحلة ذهابا وإيابا بالمللي ثانية للمرحلة من 1 إلى 2
تشغيل موجه أوامر غير مقيد عن طريق إكمال الخطوات التالية:
انقر فوق "ابدأ".
في مربع "بدء البحث "، اكتب cmd، ثم اضغط على CTRL+SHIFT+ENTER.
إذا ظهر مربع الحوار "التحكم في حساب المستخدم "، فتأكد من أن الإجراء الذي يعرضه هو ما تريده، ثم انقر فوق "متابعة".
اكتب ping <the name of the proxy server your browser uses, or the IP address of the proxy server> ثم اضغط على ENTER. إذا كان لديك PsPing، أو بعض الأدوات الأخرى، مثبتة، يمكنك اختيار استخدام هذه الأداة بدلا من ذلك.
قد يبدو الأمر الخاص بك مثل أي من هذه الأمثلة:
ourproxy.ourdomain.industry.business.com ping
ping 155.55.121.55
ping ourproxy
ourproxy.ourdomain.industry.business.com:80 psping
psping 155.55.121.55:80
psping ourproxy:80
- عندما يتوقف التتبع عن إرسال حزم الاختبار، ستحصل على ملخص صغير يسرد المتوسط بالمللي ثانية، وهذه هي القيمة التي تتبعها. التقط لقطة شاشة للمطالبة واحفظها باستخدام اصطلاح التسمية. عند هذه النقطة قد يساعد أيضا على تعبئة الرسم التخطيطي بالقيمة.
ربما قمت بالتتبع في الصباح المبكر، ويمكن للعميل الوصول إلى الوكيل (أو أي خادم خروج يخرج إلى الإنترنت) بسرعة. في هذه الحالة، قد تبدو الأرقام كما يلي:
إذا كان الكمبيوتر العميل الخاص بك أحد أجهزة الكمبيوتر القليلة المحددة التي يمكنها الوصول إلى خادم الوكيل (أو الخروج)، يمكنك تشغيل المرحلة التالية من الاختبار عن طريق الاتصال عن بعد بهذا الكمبيوتر، وتشغيل موجه الأوامر إلى PsPing إلى عنوان URL Office 365 من هناك. إذا لم يكن لديك حق الوصول إلى هذا الكمبيوتر، يمكنك الاتصال بموارد الشبكة للحصول على المساعدة في المحطة التالية والحصول على الأرقام الدقيقة بهذه الطريقة. إذا لم يكن ذلك ممكنا، فخذ PsPing مقابل عنوان URL Office 365 المعني وقم بمقارنته بوقت PsPing أو Ping مقابل الخادم الوكيل.
على سبيل المثال، إذا كان لديك 51.84 مللي ثانية من العميل إلى عنوان URL Office 365، وكان لديك 2.8 مللي ثانية من العميل إلى الوكيل (أو نقطة الخروج)، فسيكون لديك 49.04 مللي ثانية من الخروج إلى Office 365. وبالمثل، إذا كان لديك PsPing تبلغ قيمته 12.25 مللي ثانية من العميل إلى الوكيل خلال ارتفاع اليوم، و62.01 مللي ثانية من العميل إلى عنوان URL Office 365، فإن متوسط قيمة خروج الوكيل إلى عنوان URL Office 365 هي 49.76 مللي ثانية.
من حيث استكشاف الأخطاء وإصلاحها، قد تجد شيئا مثيرا للاهتمام فقط من الاحتفاظ بهذه الخطوط الأساسية. على سبيل المثال، إذا وجدت أن لديك بشكل عام حوالي 40 مللي ثانية إلى 59 مللي ثانية من زمن الانتقال من الوكيل أو يشير الخروج إلى عنوان URL Office 365، ويكون للعميل وكيل أو زمن انتقال نقطة خروج من حوالي 3 مللي ثانية إلى 7 مللي ثانية (اعتمادا على كمية نسبة استخدام الشبكة التي تراها خلال هذا الوقت من اليوم) ثم ستعرف بالتأكيد أن هناك مشكلة إذا كان العميل الثلاثة الأخير الخاص بك إلى الوكيل أو خطوط الأساس الخروج تظهر زمن انتقال يبلغ 45 مللي ثانية.
الأساليب المتقدمة
إذا كنت تريد حقا معرفة ما يحدث مع طلبات الإنترنت الخاصة بك Office 365، تحتاج إلى أن تصبح على دراية بتتبع الشبكة. لا يهم الأدوات التي تفضلها لهذه التتبعات، HTTPWatch، Netmon، محلل الرسائل، Wireshark، Fiddler، أداة لوحة معلومات المطور أو أي أداة أخرى ستفعلها طالما أن هذه الأداة يمكنها التقاط نسبة استخدام الشبكة وتصفيتها. سترى في هذا القسم أنه من المفيد تشغيل أكثر من واحدة من هذه الأدوات للحصول على صورة أكثر اكتمالا للمشكلة. عندما تختبر، تعمل بعض هذه الأدوات أيضا كوكلاء في حد ذاتها. تتضمن الأدوات المستخدمة في المقالة المصاحبة، خطة استكشاف أخطاء الأداء وإصلاحها Office 365، Netmon 3.4 أو HTTPWatch أو WireShark.
أخذ أساس الأداء هو الجزء البسيط من هذا الأسلوب، والعديد من الخطوات هي نفسها عند استكشاف مشكلة في الأداء وإصلاحها. تتطلب الأساليب الأكثر تقدما لإنشاء خطوط أساسية للأداء أخذ تتبعات الشبكة وتخزينها. تستخدم معظم الأمثلة في هذه المقالة SharePoint Online، ولكن يجب عليك تطوير قائمة بالإجراءات الشائعة عبر خدمات Office 365 التي اشتركت فيها للاختبار والسجل. فيما يلي مثال أساسي:
قائمة الأساسات ل SPO - ** الخطوة 1: ** استعرض الصفحة الرئيسية لموقع SPO على ويب وقم بتتبع الشبكة. احفظ التتبع.
قائمة الأساسات ل SPO - الخطوة 2: البحث عن مصطلح (مثل اسم شركتك) عبر Enterprise Search وإجراء تتبع للشبكة. احفظ التتبع.
قائمة الأساسات ل SPO - الخطوة 3: Upload ملفا كبيرا إلى مكتبة مستندات SharePoint Online وقم بتتبع الشبكة. احفظ التتبع.
قائمة الأساسات ل SPO - الخطوة 4: استعرض الصفحة الرئيسية لموقع ويب OneDrive وقم بتتبع الشبكة. احفظ التتبع.
يجب أن تتضمن هذه القائمة أهم الإجراءات الشائعة التي يتخذها المستخدمون مقابل SharePoint Online. لاحظ أن الخطوة الأخيرة، لتتبع الانتقال إلى OneDrive for Business، تبني مقارنة بين تحميل الصفحة الرئيسية SharePoint Online (التي غالبا ما يتم تخصيصها من قبل الشركات) والصفحة الرئيسية OneDrive for Business، والتي نادرا ما يتم تخصيصها. هذا اختبار أساسي عندما يتعلق الأمر بموقع SharePoint Online بطيء التحميل. يمكنك إنشاء سجل لهذا الاختلاف في الاختبار الخاص بك.
إذا كنت في منتصف مشكلة في الأداء، فإن العديد من الخطوات هي نفسها عند اتخاذ خط أساسي. تصبح تتبعات الشبكة مهمة، لذلك سنتعامل مع كيفية أخذ التتبعات المهمة بعد ذلك.
لمعالجة مشكلة في الأداء، في الوقت الحالي، تحتاج إلى إجراء تتبع في الوقت الذي تواجه فيه مشكلة الأداء. تحتاج إلى الأدوات المناسبة المتاحة لجمع السجلات، وتحتاج إلى خطة عمل، أي قائمة إجراءات استكشاف الأخطاء وإصلاحها التي يجب اتخاذها لجمع أفضل المعلومات التي يمكنك القيام بها. أول شيء يجب القيام به هو تسجيل تاريخ ووقت الاختبار بحيث يمكن حفظ الملفات في مجلد يعكس التوقيت. بعد ذلك، قم بتضييق نطاق خطوات المشكلة نفسها. هذه هي الخطوات الدقيقة التي ستستخدمها للاختبار. لا تنس الأساسيات: إذا كانت المشكلة تتعلق Outlook فقط، فتأكد من تسجيل أن سلوك المشكلة يحدث في خدمة Office 365 واحدة فقط. سيساعدك تضييق نطاق هذه المشكلة على التركيز على شيء يمكنك حله.
راجع أيضًا
الملاحظات
إرسال الملاحظات وعرضها المتعلقة بـ