كيفية قياس زمن الانتقال بطريقة صحيحة في سبع دقائق

يتطلب قياس زمن الانتقال بطريقة صحيحة أن تكون لديك بيانات عالية الجودة. توصل تقرير KPMG العالمي حول توقعات الرؤساء التنفيذيين لعام 2016 (محتوى الرابط موجود خارج موقع ibm.com) إلى أن 84% من الرؤساء التنفيذيين يشعرون بالقلق إزاء جودة البيانات التي يستندون إليها في اتخاذ القرارات، وذلك لأن البيانات قد تكون مضللة في كثير من الأحيان.

هناك فرق كبير بين الشركات التي تهتم ببياناتها والشركات التي لا تهتم ببياناتها. توصل باحثو معهد ماساتشوستس للتكنولوجيا (محتوى الرابط موجود خارج موقع ibm.com) إلى أن الشركات التي تبنت تصميمًا قائمًا على البيانات تحقق إنتاجًا أعلى بنسبة 5%–6% مما كان متوقعًا نظرًا إلى استثماراتها الأخرى واستخدامها للتكنولوجيا. هذا السبب وحده يجعل فهم زمن الانتقال أمرًا حساسًا لنجاح الأعمال.

في غضون سبع دقائق فقط، ستتعلم كل ما تحتاج إلى معرفته حول قياس زمن الانتقال:

• كيفية قياس زمن الانتقال
• أهمية قياسه بطريقة صحيحة
• الأخطاء الشائعة عند النظر إلى بيانات زمن الانتقال لديك
• أهمية التعليقات الفورية
• أهمية البيانات غير المستندة إلى عينات مطلوبة

يعرف موقع Dictionary.com (محتوى الرابط موجود خارج موقع ibm.com) زمن الانتقال بأنه "فترة التأخير عندما ينتظر عنصر من مكونات نظام الأجهزة تنفيذ إجراء بواسطة عنصر آخر". بعبارات أبسط، يعني مقدار الوقت بين استدعاء دالة وتنفيذها الفعلي. زمن الانتقال متأصل في جميع الأنظمة، فحتى لو كان لدينا نظام مثالي، وهو أمر غير موجود، فإن مقدار الوقت الذي تستغرقه الإلكترونات في الكمبيوتر لتحويل الترانزستورات من التشغيل إلى الإيقاف أو العكس سيكون زمن الانتقال.

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

يمكن أن يكون لزمن الانتقال تأثير كبير في عملك. على سبيل المثال (محتوى الرابط موجود خارج موقع ibm.com): "عندما يتعلق الأمر بسرعة الهاتف المحمول، فإن كل ثانية مهمة —فلكل ثانية إضافية تستغرقها صفحة الهاتف المحمول للتحميل، يمكن أن تنخفض التحويلات بنسبة تصل إلى 20%."

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

في هذه المرحلة، ربما تسأل نفسك إذا لم نستخدم أي انحراف معياري، فكيف يمكننا وصف أزمنة الانتقال بشكل هادف؟ الإجابة هي أنه يجب أن ننظر إلى النسب المئوية والحد الأقصى. معظم الأشخاص يميلون للتفكير: بالنظر إلى P95 سأتمكن من فهم "الحالة الشائعة". المشكلة في هذه الطريقة هي أن P95 ستخفي كل الأشياء السيئة. كما يقول Gil Tene، كبير مسؤولي التكنولوجيا في Azul Systems: "إنه "نظام تسويق". شخص ما يتعرض للخداع".

خذ، على سبيل المثال، هذا الرسم البياني:

عندما ترى هذا الرسم البياني، يمكنك أن ترى بوضوح سبب عدم وجود أهمية حقيقية للوسيط والمتوسط—فإنهما لا يظهران منطقة المشكلة. عندما ترى النسبة المئوية 95 ترتفع فجأة إلى اليسار، ستعتقد أنك ترى جوهر المشكلة. بالطبع، هذا ليس صحيحًا. عندما تتحقق من سبب تعرض برنامجك لعطل مؤقت، فإنك لا ترى أسوأ 5% مما حدث. يتطلب الحصول على هذا النوع من الارتفاع أن تكون أعلى 5% من البيانات أسوأ بكثير.

انظر الآن إلى نفس الرسم البياني الذي يوضح أيضًا النسبة المئوية 99.99:

هذا الخط الأحمر هو النسبة المئوية 95، في حين أن الخط الأخضر هو النسبة المئوية 99.99. كما ترى بوضوح، تظهر النسبة المئوية 95 فقط 2 من أصل 22 من مشكلاتك ولماذا يجب عليك إلقاء نظرة على الطيف الكامل لبياناتك.

قد يفكر الكثير من الناس أن آخر 5% من البيانات لا تحمل أهمية كبيرة. بالتأكيد، قد يكون الأمر مجرد إعادة تشغيل لجهاز افتراضي (VM)، أو عطل في نظامك أو شيء من هذا القبيل، ولكن بتجاهلك لذلك، فأنت تقول إنه لا يحدث في حين أنه قد يكون أحد أهم الأشياء التي يجب أن تستهدفها.

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

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

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

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

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

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

سواء كنت تعرف ذلك أم لا، عند مشاركة أداة المراقبة في أخذ عينات البيانات، فإنها تنتج بيانات متوسطة. تقوم كل أدوات المراقبة تقريبًا بأخذ عينات من بياناتها. خذ، على سبيل المثال، Datadog—حيث ينتج عنه فقدان كبير للبيانات. إذا أرسلت إليهم 3 ملايين نقطة في دقيقة واحدة، فلن يأخذها كلها. بدلاً من ذلك، سيقوم بأخذ عينات عشوائية من النقاط ثم تجميعها في نقطة واحدة في الدقيقة.

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

عند أخذ عينات من البيانات، فإنك تحذف البيانات. لنفترض، على سبيل المثال، أن لديك 10000 عملية تحدث في دقيقة واحدة، وترسل نقطتي بيانات لكل منهما إلى نظام المراقبة الخاص بك. لنفترض أن لديك خطأً في نظامك وأن إحدى نقاط البيانات هذه تظهر هذا الخطأ لكل 10,000 عملية. نظام المراقبة الخاص بك لديه فرصة 1/20,000 فقط لاختيار هذا الخطأ كنقطة بيانات يظهرها لك كحد أقصى.

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

لا تدع أداة المراقبة الخاصة بك تخدعك وتجعلك تعتقد أنك تعرف ما يحدث مع زمن الانتقال. تتمثل السمة الرئيسية لبرنامج ™IBM Instana في قدرته على قياس زمن الانتقال بكفاءة. يستخدم برنامج Instana من IBM تحليلات متقدمة والتعلم الآلي (ML) للكشف التلقائي عن مشكلات زمن الانتقال في الوقت الفعلي، ما يسمح للمطورين وفرق تكنولوجيا المعلومات بتحديد السبب الجذري لأي مشكلات في الأداء بسرعة واتخاذ إجراءات تصحيحية قبل أن تؤثر في المستخدمين.

اختر أداة لا تقدم عينة من البيانات. اختر أداة لا تحدد متوسط النسب المئوية العالمية.