توليف أداء 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‏ والعثور على مقطع قيود 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.

  • أصبح السلوك الذي كان سلساً بشكل نسبي يتطلب الكثير من الوقت لاستكماله أو لا يستكمل إطلاقًا.

  • يمكنك تكرار المشكلة أيضاً، أو أنت تعلم، على الأقل، أنها ستحصل إذا نفّذت مجموعة الخطوات الصحيحة.

  • إذا كانت المشكلة متقطعة، فهناك نمط لحدوثها، على سبيل المثال، أنت تعرف أنه بحلول الساعة العاشرة صباحاً سوف تتلقى مكالمات من مستخدمين لا يمكنهم الوصول إلى Office 365 بطريقة موثوقة، وأن المكالمات سوف تهدأ ظهراً.

يبدو ذلك مألوفاً، وربما مألوفاً جداً. عندما تعلم أن هذا الأمر عبارة عن مشكلة في الأداء، يصبح السؤال "ما هي الخطوة التالية"؟ تساعدك الأقسام المتبقية في هذه المقالة على تحديد ذلك بدقة.

كيفية تعريف مشكلة الأداء واختبارها

تبرز المشاكل في الأداء في كثير من الأحيان مع مرور الوقت، وبالتالي قد يكون تحديد المشكلة الفعلية أمراً صعباً. إنك تحتاج إلى إنشاء بيان جيد حول المشكلة، والحصول على فكرة جيدة حول سياق المشكلة، ثم تحتاج إلى خطوات اختبارية قابلة للتكرار للنجاح في مهمتك. وخلاف ذلك، ومن دون أي خطأ ترتكبه بنفسك، فقد تكون مربكاً. لماذا؟ حسناً، في ما يلي بعض الأمثلة عن بيانات المشاكل التي لا توفر المعلومات الكافية:

  • لم أكن ألاحظ من قبل التبديل من علبة الوارد إلى التقويم، أما الآن فهو يتم ببطء شديد. هل يمكنك إرجاع ذلك كما كان من قبل؟

  • يستغرق تحميل الملفات إلى SharePoint Online وقتاً لا نهاية له. ما سبب بطء هذه العملية في فترة بعد الظهر، على الرغم من أنها تتم بسرعة في أوقات أخرى؟ ألا يمكنها أن تتم بسرعة؟

هناك عدد كبير من التحديات المهمة التي تفرضها البيانات حول المشاكل أعلاه. وعلى وجه التحديد، هناك الكثير من الأمور المبهمة التي يجب التعامل معها. على سبيل المثال:

  • من غير الواضح كيف كانت عملية التبديل بين علبة الوارد والتقويم تتم على الكمبيوتر المحمول.

  • عندما يقول المستخدم "ألا يمكنها أن تتم بسرعة؟، ماذا يقصد بكلمة "بسرعة"؟

  • ما طول فترة "الوقت الذي لا نهاية له"؟ هل هو ثوانٍ أو دقائق عديدة، أو هل يستطيع المستخدم الذهاب لتناول طعام الغداء وسينتهي الأمر بعد مرور عشر دقائق على عودته؟

كل هذا من دون الأخذ في الاعتبار أن المسؤول أو الشخص الذي يعمل على استكشاف المشاكل وإصلاحها قد لا يكون على علم بالكثير من التفاصيل من بيانات المشاكل المماثلة لتلك التي أوردناها. على سبيل المثال، عندما بدأت المشكلة في الحدوث؛ المستخدم يعمل من المنزل ويرى أن عملية التبديل أصبحت بطيئة عند عمله على الشبكة المنزلية فقط؛ أو يتعينّ على المستخدم تشغيل عدة تطبيقات أخرى تستخدم RAM بشكل مكثّف على العميل المحلي، أو أن المستخدم الآخر يستخدم نظام تشغيل قديمًا أو لم يقم بتشغيل آخر التحديثات.

عندما يقوم المستخدمون بالتبليغ عن مشكلة في الأداء، يجب تجميع الكثير من المعلومات. تُعد عملية تجميع المعلومات جزءاً من عملية تسمى فحص المشكلة التحقيق بشأنها. فيما يلي قائمة فحص أساسية يمكنك استخدامها لتجميع المعلومات حول المشكلة التي تواجهها في الأداء. هذه القائمة ليست شاملة، وإنما تمثل مكاناً من حيث يمكنك بدء قائمة خاصة بك:

  • ما تاريخ حدوث المشكلة، وفي أي وقت تقريباً في النهار أو الليل؟

  • ما نوع الكمبيوتر العميل الذي تستخدمه، وكيف يمكنه الاتصال بشبكة العمل (VPN أو شبكة سلكية أو لاسلكية)؟

  • هل كنت تعمل عن بُعد أو كنت موجوداً في المكتب؟

  • هل جرّبت الإجراءات نفسها على كمبيوتر آخر ورأيت السلوك نفسه؟

  • نفّذ الخطوات التي أدت إلى حدوث المشكلة بحيث يمكنك تدوين الإجراءات التي اتخذتها.

  • ما مدى بطء الأداء بالثواني أو الدقائق؟

  • في أي مكان في العالم أنت موجود؟

إن بعض هذه الأسئلة أكثر وضوحًا من البعض الآخر. يدرك الجمييع تقريباً أن الشخص الذي يستكشف المشكلة ويصلحها يحتاج إلى الاطلاع على الخطوات الدقيقة لإعادة إنتاج المشكلة. وفي النهاية، كيف يمكنك تسجيل الأخطاء وكيف يمكنك اختبار إن كانت المشكلة قد عثرت على حل لها؟ ثمة أشياء أقل وضوحاً مثل "ما تاريخ ووقت حدوث المشكلة؟"، و "في أي مكان في العالم أنت موجود؟"، وهي معلومات يمكن استخدامها في وقت واحد. بحسب الوقت الذي كان المستخدم يعمل فيه، تعني ساعات قليلة من فرق الوقت أن الصيانة جارية على أجزاء من شبكة الشركة. على سبيل المثال، إذا كان التطبيق في شركتك مختلطاً، مثل بحث SharePoint مختلط يمكنه الاستعلام عن فهارس البحث في كل من SharePoint Online ومثيل SharePoint Server 2013 محلي، فقد تكون التحديثات جارية في المجموعة المحلية. إذا كانت شركتك كلها في السحابة، فقد تشتمل عملية صيانة النظام على إضافة الأجهزة أو إزالتها أو نشر التحديثات على مستوى الشركة أو إدخال التغييرات على DNS أو بنية أساسية رئيسية أخرى.

عندما تعمل على استكشاف مشكلة في الأداء وإصلاحها، الأمر يشبه قليلاً مسرح الجريمة حيث يجب أن تكون دقيقاً وواعياً لاستخلاص النتائج من الدليل. ولكي تتمكّن من إجراء ذلك، يجب أن تحصل على بيان جيد حول المشكلة من خلال تجميع الأدلة. يجب أن يتضمّن هذا البيان سياق الكمبيوتر وسياق المستخدم والوقت الذي بدأت فيه المشكلة والخطوات الدقيقة التي أدت إلى إظهار مشكلة الأداء. يجب أن يكون بيان المشكلة الصفحة العلوية في ملاحظاتك ويجب أن يبقى كذلك. ومن خلال متابعة بيان المشكلة مرة أخرى بعد أن تعمل على الحل، ستنفذ الخطوات لإجراء الاختبار وإثبات ما إذا كانت الإجراءات التي اتخذتها قد أدت إلى حل المشكلة. يُعد هذا الأمر بالغ الأهمية لمعرفة متى ينتهي عملك هناك.

هل تعلم كيف كان الأداء عندما كان جيداً؟

إذا كنت قليل الحظ، فلا أحد يعلم. لا توجد أرقام لدى أحد. يعني هذا الأمر أنه لا يمكن لأحد الرد على السؤال البسيط "ما عدد الثواني التي كان يستغرقها إحضار علبة وارد في Office 365"؟ أو "ما فترة الوقت التي كان يستغرقها ذلك عندما كان التنفيذيون يعقدون اجتماعاً عبر Lync Online"؟، وهو سيناريو شائع في الكثير من الشركات.

ما نفتقده هنا هو الخط الأساسي للأداء.

توفر لك الخطوط الأساسية سياقاً للأداء. يجب عليك الاستعانة بخط أساسي من وقت إلى آخر أو بشكل متكرر، بحسب احتياجات شركتك. إذا كانت شركتك كبيرة، فقد يستعين فريق "العمليات" بالفعل بخطوط أساسية لبيئتك المحلية. على سبيل المثال، إذا كنت تصحح كل خوادم Exchange في يوم الاثنين الأول من كل شهر، وكل خوادم 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). ومع ذلك، قد تشكّل أدوات أخرى توفرها جهات خارجية أفضل الحلول للحالة التي تواجهها. لا تدعم 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

  • Feb_08_2015_8-30amEST_PerfBaseline_GoodPerf

ثمة طرق مختلفة كثيرة لإجراء ذلك، ولكن استخدام التنسيق <dateTime><what's happening in the test> يُعد مكاناً جيداً للبدء منه. تؤدي المثابرة في هذا المجال إلى مساعدتك كثيراً عندما ستحاول استكشاف المشاكل وإصلاحها في وقت لاحق. ستتمكّن من القول لاحقاً "لقد أجريت عمليتي تتبع في الثامن من فبراير، كان الأداء جيداً في إحداهما وضعيفاً في الأخرى، ويمكننا الآن إجراء المقارنة". يُعد هذا الأمر مفيداً للغاية لاستكشاف المشاكل وإصلاحها.

يجب عليك اتباع طريقة منظمة للاحتفاظ بالخطوط الأساسية التاريخية. في هذا المثال، أدت الأساليب البسيطة إلى إنتاج ثلاثة إخراجات لسطر الأوامر وتم تجميع النتائج كلقطات شاشة، ولكن يمكنك الحصول على ملفات التقاط الشبكة بدلاً منها. استخدم الأسلوب الأنسب لك. يمكنك تخزين الخطوط الأساسية التاريخية والرجوع إليها في مراحل معينة تلاحظ فيها وجود تغييرات في سلوك الخدمات عبر الإنترنت.

ما السبب الذي يدعو إلى تجميع بيانات الأداء خلال المرحلة التجريبية؟

ما من وقت أفضل من المرحلة التجريبية لخدمة 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 على الطلب. يبدأ الاختبار داخل مجالك على كمبيوتر عميل، ويتطلع إلى قياس اختبار الإرسال ثم التلقي من داخل الشبكة، إلى الخارج عبر نقطة خروج، وعبر الإنترنت إلى 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، انتقل إلى أدوات > خيارات الإنترنت> اتصالات > إعدادات LAN > خيارات متقدمة. تمثّل أيضاً علامة التبويب "خيارات متقدمة" المكان حيث يمكنك العثور على الخادم الوكيل ومنفذ الخادم الوكيل. قد تحتاج إلى النقر فوق خانة الاختيار ‏‏استخدم خادماُ وكيلاً للشبكة المحلية، للوصول إلى الزر خيارات متقدمة. قد تحتاج إلى التأكد من تحديد الخيار تجاوز الخادم الوكيل للعناوين المحلية. بعد النقر فوق خيارات متقدمة، سترى مربع نص يمكنك إدخال الاستثناءات فيه. افصل عناوين URLs ذات أحرف بدل المذكورة أعلاه بالفواصل المنقوطة، على سبيل المثال:

*.microsoftonline.com; *.sharepoint.com

بعد أن تتجاوز الوكيل، من المفترض أن تتمكّن من استخدام أداة اختبار الاتصال ping أو PsPing مباشرةً على عنوان URL لـ Office 365. ستكون الخطوة التالية اختبار الاتصال ping في 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 إلى microsoft-my.sharepoint.com عبر المنفذ 443.

تأكد من تضمين رقم المنفذ 443. تذكّر أن Office 365 يعمل على قناة مشفرة. إذا استخدمت PsPing من دون رقم المنفذ، فسيفشل طلبك. وبعد اختبار اتصال القائمة القصيرة، ابحث عن متوسط الوقت بالمللي ثانية. هذا هو الوقت الذي تريد تسجيله!

يعرض الرسم توضيحاً لتطبيق PSPing من العميل إلى الوكيل مع وقت اختبار الإرسال ثم التلقي والذي يبلغ حوالي 2,8 مللي ثانية.

إذا لم تكن ملماً بتجاوز الوكيل، وكنت تفضل تنفيذ الأشياء خطوة بخطوة، فستحتاج أولاً إلى العثور على اسم الخادم الوكيل. في Internet Explorer، انتقل إلى أدوات > خيارات الإنترنت > اتصالات > إعدادات LAN > خيارات متقدمة. تمثّل علامة التبويب خيارات متقدمة المكان حيث سيتم إدراج الخادم الوكيل. اعمل على اختبار اتصال الخادم الوكيل عند موجه الأوامر بإكمال هذه المهمة:

لاختبار اتصال الخادم الوكيل والحصول على قيمة الجولة بالمللي ثانية للمرحلة من 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 مقابل الخادم الوكيل.

على سبيل المثال، إذا كان لديك 51.84 مللي ثانية من العميل إلى عنوان URL لـ Office 365، ولديك 2.8 مللي ثانية من العميل إلى الخادم (أو نقطة الخروج)، فسيكون لديك عندئذٍ 49.04 مللي ثانية من نقطة الخروج إلى Office 365. بطريقة مماثلة، إذا كان لديك PsPing من 12.25 مللي ثانية من العميل إلى الوكيل أثناء ذروة النهار، و 62.01 مللي ثانية من العميل إلى عنوان URL لـ Office 365، فستكون القيمة 49.76 مللي ثانية القيمة المتوسطة لنقطة الخروج إلى عنوان URL لـ Office 365.

رسم إضافي يعرض اختبار الاتصال وقم تم قياسه بالميلي ثوانٍ من العميل إلى الوكيل ومن العميل إلى Office 365 بحيث يمكن طرح القيم.

فيما يتعلق باستكشاف المشاكل وإصلاحها، قد تجد شيئاً مثيراً للاهتمام نتيجة الاحتفاظ بهذه الخطوط الأساسية. على سبيل المثال، إذا تبيّن أنه لديك عادةً زمن انتقال من 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: ابحث عن مصطلح (اسم شركتك مثلاً) بواسطة "البحث في المؤسسات" ونفّذ عملية تتبع الشبكة. احفظ التتبع.

  • قائمة الخطوط الأساسية لـ SPO - الخطوة 3: حمّل ملفاً كبيراً إلى مكتبة مستندات SharePoint Online ونفّذ عملية تتبع الشبكة. احفظ التتبع.

  • قائمة الخطوط الأساسية لـ SPO - الخطوة 4: استعرض الصفحة الرئيسية لموقع OneDrive على ويب ونفّذ عملية تتبع الشبكة. احفظ التتبع.

يجب أن تتضمّن هذه القائمة أهم الإجراءات الشائعة التي يتخذها المستخدمون مقابل SharePoint Online. تجدر الإشارة إلى أن الخطوة الأخيرة، لتتبع الانتقال إلى OneDrive for Business، تنشئ مقارنة بين تحميل صفحة SharePoint Online الرئيسية (التي يتم تخصيصها في أغلب الأحيان من قِبل الشركات) وصفحة OneDrive for Business، التي نادراً ما يتم تخصيصها. هذا اختبار أساسي جدًا عندما يتعلق الأمر بموقع SharePoint Online يتم تحميله ببطء. ويمكنك إنشاء سجل بهذا الفرق في اختبارك.

إذا كنت في وسط مشكلة في الأداء، فثمة خطوات كثيرة مماثلة للخطوات التي تقوم بها عند الاستعانة بخط أساسي. تصبح تتبعات الشبكة ضرورية، وبالتالي سنعالج كيفية تنفيذ التتبعات المهمة في المرحلة التالية.

لمعالجة مشكلة في الأداء في هذه اللحظة، يجب إجراء التتبع في الوقت الذي تواجه فيه هذه المشكلة. يجب أن تتوفر لديك الأدوات المناسبة لجمع السجلات، ويجب أن تكون لديك خطة إجرائية، أي قائمة تتضمّن إجراءات استكشاف المشاكل وإصلاحها التي يجب اتخاذها لجمع أفضل المعلومات التي يمكنك جمعها. أول شيء عليك القيام به هو تسجيل تاريخ الاختبار ووقته بحيث يمكن حفظ الملفات في مجلد يعكس التوقيت. بعد ذلك، يمكنك التضييق وصولاً إلى خطوات المشكلة بحد ذاتها. هذه هي الخطوات الدقيقة التي ستستخدمها لإجراء الاختبار. لا تنسَ الأساسيات: إذا كانت المشكلة تتعلق ببرنامج Outlook فقط، فتأكد من تسجيل معلومات تفيد أن سلوك المشكلة يحدث في خدمة واحدة فقط من خدمات Office 365. من شأن تضييق نطاق هذه المشكلة أن يساعدك على التركيز على شيء يمكنك حله.

انظر أيضاً

إدارة نقاط نهاية Office 365‏

توسيع المهارات
استكشاف التدريب
الحصول على الميزات الجديدة أولاً
الانضمام إلى Office Insider

هل كانت المعلومات مفيدة؟

نشكرك على ملاحظاتك!

شكراً لك على الملاحظات! يبدو أنه من المفيد إيصالك بأحد وكلاء دعم Office لدينا.

×