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 Online وتحديد موقع قسم حدود SharePoint Online الخاص به.
تأكد من الانتقال إلى استكشاف الأخطاء وإصلاحها مع فهم أن الأداء هو مقياس منزلق. لا يتعلق الأمر بتحقيق قيمة مثالية والحفاظ عليها بشكل دائم. ستكون المهام العرضية ذات النطاق الترددي العالي مثل إلحاق عدد كبير من المستخدمين، أو القيام بترحيلات كبيرة للبيانات مرهقة، لذا خطط لتأثيرات الأداء بعد ذلك. يجب أن يكون لديك فكرة تقريبية عن أهداف الأداء الخاصة بك، ولكن العديد من المتغيرات تلعب في الأداء، لذلك يختلف الأداء.
لا يتعلق استكشاف أخطاء الأداء وإصلاحها بتلبية أهداف محددة والحفاظ على هذه الأرقام إلى أجل غير مسمى، بل يتعلق بتحسين الأنشطة الحالية، نظرا لجميع المتغيرات.
حسنا، كيف تبدو مشكلة الأداء؟
أولا، تحتاج إلى التأكد من أن ما تواجهه هو في الواقع مشكلة في الأداء وليس حادث خدمة. تختلف مشكلة الأداء عن حادث الخدمة في Office 365. إليك كيفية فصلهم عن بعضهم البعض.
تحدث حوادث الخدمة عندما تواجه خدمة Office 365 نفسها مشكلات. قد ترى أيقونات حمراء أو صفراء ضمن الحماية الحالية في مركز مسؤولي Microsoft 365. قد تلاحظ أن الأداء على أجهزة الكمبيوتر العميلة المتصلة Office 365 بطيئ. على سبيل المثال، إذا أبلغت الحماية الحالية عن أيقونة حمراء وشاهدت التحقيق إلى جانب Exchange، فقد تتلقى أيضا مكالمات من أشخاص في مؤسستك يشكون من أن علب بريد العميل التي تستخدم Exchange Online بطيئة. في هذه الحالة، من المعقول افتراض أن أداء Exchange Online كان ضحية لمشكلات الخدمة.
في هذه المرحلة، يجب عليك أنت، مسؤول Office 365، التحقق من الصحة الحالية ثم عرض التفاصيل والمحفوظات، في كثير من الأحيان، لمواكبة الصيانة على النظام. تم إجراء لوحة معلومات الحماية الحالية لتحديثك حول التغييرات التي تم إدخالها على الخدمة والمشاكل فيها. الملاحظات والتفسيرات المكتوبة إلى محفوظات الصحة، المسؤول إلى المسؤول، موجودة لمساعدتك في القياس، ولإبقاءك منشورا حول العمل الجاري.
مشكلة الأداء ليست حادث خدمة، على الرغم من أن الحوادث يمكن أن تتسبب في بطء الأداء. تبدو مشكلة الأداء كما يلي:
تحدث مشكلة في الأداء بغض النظر عن مركز الإدارة الذي تقوم الحماية الحالية بالإبلاغ عنه للخدمة.
يستغرق السلوك المستخدم للتدفق وقتا طويلا لإكماله أو عدم اكتماله أبدا.
يمكنك نسخ المشكلة أيضا، أو معرفة أنها ستحدث إذا قمت بالسلسلة الصحيحة من الخطوات.
إذا كانت المشكلة متقطعة، فلا يزال هناك نمط. على سبيل المثال، أنت تعرف أنه بحلول الساعة 10:00 صباحا، سيكون لديك مكالمات من المستخدمين الذين لا يمكنهم دائما الوصول إلى Office 365. ستنتهي المكالمات حوالي الظهر.
ربما تبدو هذه القائمة مألوفة؛ ربما مألوفة جدا. بمجرد أن تدرك أنها مشكلة في الأداء، يصبح السؤال، "ماذا تفعل بعد ذلك؟" تساعدك بقية هذه المقالة على تحديد ذلك بالضبط.
كيفية تحديد مشكلة الأداء واختبارها
غالبا ما تظهر مشكلات الأداء بمرور الوقت، لذلك قد يكون من الصعب تحديد المشكلة الفعلية. أنشئ عبارة مشكلة جيدة مع فكرة جيدة عن سياق المشكلة، ثم تحتاج إلى خطوات اختبار قابلة للتكرار. فيما يلي بعض الأمثلة على عبارات المشاكل التي لا توفر معلومات كافية:
كان التبديل من علبة الوارد إلى التقويم الخاص بي شيئا لم ألاحظه، والآن هو استراحة للقهوة. هل يمكنك أن تجعله يتصرف كما كان؟
يستغرق تحميل ملفاتي إلى SharePoint Online وقتا طويلا. لماذا يكون بطيئا في فترة ما بعد الظهر، ولكن في أي وقت آخر، هو سريع؟ ألا يمكن أن يكون الأمر سريعا؟
هناك العديد من التحديات الكبيرة التي تطرحها بيانات المشكلة أعلاه. على وجه التحديد، هناك الكثير من الغموض الذي يجب التعامل معه. على سبيل المثال:
من غير الواضح كيفية التبديل بين علبة الوارد والتقويم المستخدم للعمل على الكمبيوتر المحمول.
عندما يقول المستخدم، "ألا يمكن أن يكون الأمر سريعا"، ما هو "سريع"؟
كم من الوقت هو "إلى الأبد"؟ هل هذا عدة ثوان؟ أو عدة دقائق؟ أو هل يمكن للمستخدم تناول الغداء وسينتهي الإجراء بعد 10 دقائق من عودته؟
لا يمكن للمسؤول ومستكشف الأخطاء ومصلحها أن يكون على دراية بتفاصيل المشكلة من عبارات عامة مثل هذه. على سبيل المثال، لا يعرفون متى بدأت المشكلة في الحدوث. قد لا يعرف مستكشف الأخطاء ومصلحها أن المستخدم يعمل من المنزل ولا يرى سوى التبديل البطيء أثناء العمل على شبكته المنزلية. أو أن المستخدم يقوم بتشغيل تطبيقات ذاكرة الوصول العشوائي المكثفة الأخرى على العميل المحلي. قد لا يعرف المسؤولون أن المستخدم يقوم بتشغيل نظام تشغيل أقدم أو لم يقم بتشغيل التحديثات الأخيرة.
عندما يبلغ المستخدمون عن مشكلة في الأداء، هناك الكثير من المعلومات التي يجب جمعها. يسمى الحصول على المعلومات وتسجيلها تحديد نطاق المشكلة. فيما يلي قائمة تحديد النطاق الأساسية التي يمكنك استخدامها لجمع معلومات حول مشكلات الأداء. هذه القائمة ليست شاملة، ولكنها مكان للبدء:
في أي تاريخ حدثت المشكلة، وحول أي وقت من النهار أو الليل؟
ما نوع كمبيوتر العميل الذي كنت تستخدمه، وكيف يتصل بشبكة الأعمال (VPN، Wired، Wireless)؟
هل كنت تعمل عن بعد أم كنت في المكتب؟
هل جربت نفس الإجراءات على كمبيوتر آخر وشاهدت نفس السلوك؟
اطلع على الخطوات التي تمنحك المتاعب حتى تتمكن من كتابة الإجراءات التي تتخذها.
ما مدى بطء الأداء في الثوان أو الدقائق؟
أين توجد في العالم؟
بعض هذه الأسئلة أكثر وضوحا من غيرها. سيفهم معظم الجميع أن مستكشف الأخطاء ومصلحها يحتاج إلى الخطوات الدقيقة لإعادة إنتاج المشكلة. بعد كل شيء، كيف يمكنك تسجيل الخطأ، وكيف يمكنك أيضا اختبار ما إذا كانت المشكلة قد تم إصلاحها؟ أقل وضوحا هي أشياء مثل "ما التاريخ والوقت الذي رأيت فيه المشكلة؟"، و"أين توجد في العالم؟"، المعلومات التي يمكن استخدامها جنبا إلى جنب. اعتمادا على وقت عمل المستخدم، قد يعني اختلاف الوقت بضع ساعات أن الصيانة جارية بالفعل على أجزاء من شبكة شركتك. على سبيل المثال، لدى شركتك تطبيق مختلط، مثل بحث 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><ما يحدث في الاختبار> هو مكان جيد للبدء. سيساعدك الاجتهاد في هذا الأمر كثيرا عندما تحاول استكشاف المشكلات وإصلاحها لاحقا. في وقت لاحق، سوف تكون قادرة على القول "أخذت اثنين من آثار في 8 فبراير، واحد أظهر أداء جيدا واحد أظهر سيئة، حتى نتمكن من مقارنتها". هذا مفيد لاستكشاف الأخطاء وإصلاحها.
تحتاج إلى طريقة منظمة للحفاظ على خطوط الأساس التاريخية الخاصة بك. في هذا المثال، أنتجت الأساليب البسيطة ثلاثة مخرجات سطر الأوامر وتم جمع النتائج كقطات شاشة، ولكن قد يكون لديك ملفات التقاط الشبكة بدلا من ذلك. استخدم الأسلوب الذي يناسبك بشكل أفضل. قم بتخزين خطوط الأساس التاريخية والرجوع إليها في نقاط تلاحظ فيها تغييرات في سلوك خدمات الإنترنت.
لماذا تجمع بيانات الأداء أثناء الإصدار التجريبي؟
لا يوجد وقت أفضل لبدء إنشاء خطوط أساسية من خلال إصدار تجريبي لخدمة Office 365. قد يحتوي مكتبك على آلاف المستخدمين أو مئات الآلاف أو قد يكون لديه خمسة مستخدمين، ولكن حتى مع عدد قليل من المستخدمين، يمكنك إجراء اختبارات لقياس التقلبات في الأداء. في حالة شركة كبيرة، يمكن عرض عينة تمثيلية من عدة مئات من المستخدمين الذين يقومون بتجربة Office 365 إلى الخارج إلى عدة آلاف حتى تعرف أين قد تنشأ المشكلات قبل حدوثها.
في حالة شركة صغيرة، حيث يعني الصعود إلى الطائرة أن جميع المستخدمين يذهبون إلى الخدمة في نفس الوقت وليس هناك إصدار تجريبي، فاحتفظ بمقاييس الأداء بحيث يكون لديك بيانات لإظهارها لأي شخص قد تضطر إلى استكشاف أخطاء عملية ذات أداء سيئ وإصلاحها. على سبيل المثال، إذا لاحظت أنه فجأة يمكنك التجول في المبنى الخاص بك في الوقت الذي يستغرقه تحميل رسم متوسط الحجم حيث كان يحدث بسرعة.
كيفية جمع الخطوط الأساسية
بالنسبة لجميع خطط استكشاف الأخطاء وإصلاحها، تحتاج إلى تحديد هذه الأشياء كحد أدنى:
كمبيوتر العميل الذي تستخدمه (نوع الكمبيوتر أو الجهاز وعنوان IP والإجراءات التي تسببت في المشكلة)
حيث يوجد كمبيوتر العميل في العالم (على سبيل المثال، ما إذا كان هذا المستخدم على VPN إلى الشبكة، أو يعمل عن بعد، أو على إنترانت الشركة)
نقطة الخروج التي يستخدمها كمبيوتر العميل من شبكتك (النقطة التي تترك فيها نسبة استخدام الشبكة عملك لمورد خدمة الإنترنت أو الإنترنت)
يمكنك معرفة تخطيط الشبكة من مسؤول الشبكة. إذا كنت تستخدم شبكة صغيرة، فقم بإلقاء نظرة على الأجهزة التي تربطك بالإنترنت، واستدع موفر خدمة الإنترنت إذا كانت لديك أسئلة حول التخطيط. إنشاء رسم تخطيط نهائي للمرجع الخاص بك.
يتم تقسيم هذا القسم إلى أدوات وأساليب سطر الأوامر البسيطة وخيارات الأدوات الأكثر تقدما. سنغطي الأساليب البسيطة أولا. ولكن إذا كان لديك مشكلة في الأداء الآن، فيجب عليك الانتقال إلى الأساليب المتقدمة وتجربة نموذج خطة عمل استكشاف أخطاء الأداء وإصلاحها.
أساليب بسيطة
الهدف من هذه الأساليب البسيطة هو تعلم أخذ خطوط أساس الأداء البسيطة وفهمها وتخزينها بشكل صحيح بمرور الوقت بحيث يتم إعلامك 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 الخاص بك، للوصول إلى الزر خيارات متقدمة . ستحتاج إلى التأكد من التحقق من تجاوز خادم الوكيل للعناوين المحلية . بمجرد النقر فوق خيارات متقدمة، سترى مربع نص حيث يمكنك إدخال استثناءات. افصل عناوين 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
-
تأكد من تضمين رقم المنفذ 443. تذكر أن Office 365 يعمل على قناة مشفرة. إذا قمت ب PsPing بدون رقم المنفذ، فسيفشل طلبك. بمجرد اختبار اتصال قائمتك القصيرة، ابحث عن متوسط الوقت بالمللي ثانية (مللي ثانية). هذا ما تريد تسجيله!
إذا لم تكن على دراية بتجاوز الوكيل، وتفضل اتخاذ الأشياء خطوة بخطوة، فستحتاج أولا إلى معرفة اسم الخادم الوكيل. في Internet Explorer، انتقل إلى أدوات>خيارات>الإنترنتإعدادات الشبكة المحلية للاتصالات>>المتقدمة. علامة التبويب خيارات متقدمة هي المكان الذي سترى فيه الخادم الوكيل مدرجا. اختبار اتصال خادم الوكيل هذا في موجه الأوامر عن طريق إكمال هذه المهمة:
اختبار اتصال الخادم الوكيل والحصول على قيمة رحلة ذهابا وإيابا بالمللي ثانية للمرحلة من 1 إلى 2
قم بتشغيل موجه أوامر غير مقيد عن طريق إكمال الخطوات التالية:
انقر فوق بدء.
في مربع بدء البحث ، اكتب cmd، ثم اضغط على CTRL+SHIFT+ENTER.
إذا ظهر مربع الحوار التحكم في حساب المستخدم ، فتأكد من أن الإجراء الذي يعرضه هو ما تريده، ثم انقر فوق متابعة.
اكتب ping <اسم الخادم الوكيل الذي يستخدمه المستعرض، أو عنوان IP للخادم> الوكيل ثم اضغط على 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: قم بتحميل ملف كبير إلى مكتبة مستندات SharePoint Online وقم بتتبع الشبكة. حفظ التتبع.
قائمة الأساس ل SPO - الخطوة 4: استعرض الصفحة الرئيسية لموقع OneDrive على الويب وقم بتتبع الشبكة. حفظ التتبع.
يجب أن تتضمن هذه القائمة أهم الإجراءات الشائعة التي يتخذها المستخدمون مقابل SharePoint Online. لاحظ أن الخطوة الأخيرة، لتتبع الانتقال إلى OneDrive for Business، تقوم بإنشاء مقارنة بين تحميل صفحة SharePoint Online الرئيسية (التي غالبا ما يتم تخصيصها من قبل الشركات) والصفحة الرئيسية OneDrive for Business، والتي نادرا ما يتم تخصيصها. هذا اختبار أساسي عندما يتعلق الأمر بموقع SharePoint Online يتم تحميله ببطء. يمكنك إنشاء سجل لهذا الاختلاف في الاختبار الخاص بك.
إذا كنت في وسط مشكلة في الأداء، فإن العديد من الخطوات هي نفسها عند اتخاذ خط أساسي. تصبح تتبعات الشبكة بالغة الأهمية، لذلك سنتعامل مع كيفية أخذ التتبعات المهمة بعد ذلك.
لمعالجة مشكلة في الأداء، في الوقت الحالي، تحتاج إلى تتبع الوقت الذي تواجه فيه مشكلة الأداء. تحتاج إلى توفر الأدوات المناسبة لجمع السجلات، وتحتاج إلى خطة عمل، أي قائمة بإجراءات استكشاف الأخطاء وإصلاحها التي يجب اتخاذها لجمع أفضل المعلومات التي يمكنك القيام بها. أول شيء يجب القيام به هو تسجيل تاريخ الاختبار ووقته بحيث يمكن حفظ الملفات في مجلد يعكس التوقيت. بعد ذلك، قم بتضييق نطاق خطوات المشكلة نفسها. هذه هي الخطوات الدقيقة التي ستستخدمها للاختبار. لا تنس الأساسيات: إذا كانت المشكلة تتعلق ب Outlook فقط، فتأكد من تسجيل أن سلوك المشكلة يحدث في خدمة Office 365 واحدة فقط. سيساعدك تضييق نطاق هذه المشكلة على التركيز على شيء يمكنك حله.
راجع أيضًا
الملاحظات
قريبًا: خلال عام 2024، سنتخلص تدريجيًا من GitHub Issues بوصفها آلية إرسال ملاحظات للمحتوى ونستبدلها بنظام ملاحظات جديد. لمزيد من المعلومات، راجع https://aka.ms/ContentUserFeedback.
إرسال الملاحظات وعرضها المتعلقة بـ