لا تظهر دائمًا حالات انقطاع Cloudflare وفشل CDN الإقليمي وتدهور مستوى الحافة على صفحات الحالة. عندما يتعطل بروتوكول POP الخاص بـ CDN الخاص بك ولكن تظهر حالته العامة باللون الأخضر، لن تتمكن مراقبتك من فيرجينيا من التقاطه.
يتطلب اكتشاف الانقطاع الإقليمي المراقبة من المكان الذي يتواجد فيه المستخدمون فعليًا - وليس فقط من مكان تواجد البنية الأساسية لديك.
إنها الثالثة صباحًا. يتأثر مهندسك تحت الطلب بنجاح العميل: "أبلغ ثلاثة من عملاء المؤسسات في سنغافورة أنهم لا يستطيعون الوصول إلى التطبيق. بدأت العملية منذ حوالي ساعتين."
يمكنك التحقق من لوحة التحكم الخاصة بالمراقبة - كل شيء باللون الأخضر. صفحة حالة Cloudflare — جاهزة للعمل. AWS — لا توجد حوادث. APM الخاص بك - رسوم بيانية صغيرة سعيدة. لذلك تطلب من العملاء المحاولة مرة أخرى، ومسح ذاكرة التخزين المؤقت الخاصة بهم، والتحقق من شبكتهم.
لكنه يستمر في الحدوث. المزيد من التذاكر من نفس المنطقة. أخيرًا، يقوم شخص ما بتشغيل مسار تتبع من خادم VPS في سنغافورة ويكتشف: تصل حركة المرور إلى حافة Cloudflare التي تعيد 502s. تحتوي شبكة CDN على انقطاع إقليمي يؤثر على نقطة اتصال واحدة - ولا يتم التحقق من أي شيء في حزمة المراقبة الخاصة بك من تلك المنطقة.
ساعتين من التوقف. لجغرافية محددة. تنبيهات صفر. هذه هي النقطة العمياء التي تدور حولها هذه الصفحة.
سواء أكان ذلك انقطاع Cloudflare، أو فشل Fastly edge، أو تدهور Akamai الإقليمي - فإن اكتشاف هذه المشكلات يتطلب المراقبة من المناطق المتأثرة. هذه هي الطريقة التي تكتشف بها المشكلات قبل أن تتحول إلى تصعيد للعملاء.
الإنترنت ليس شبكة واحدة. ينتقل الطلب من سيدني عبر بنية تحتية مختلفة تمامًا عن الطلب من فرانكفورت. عندما يفشل أي جزء من هذا المسار الإقليمي، فإن المستخدمين في تلك المنطقة فقط هم الذين يتأثرون.
تقوم شبكات CDN مثل Cloudflare وFastly وAkamai بتشغيل مئات من نقاط التواجد (PoPs) على مستوى العالم. عندما يواجه خادم Edge معين أو PoP مشكلات - فشل الأجهزة أو التكوين الخاطئ أو مشكلات السعة - يتأثر فقط المستخدمون الذين تم توجيههم إلى تلك الحافة. تظل الحالة العالمية لـ CDN "عاملة" لأن 95% من الحواف جيدة.
مثال: في حزيران (يونيو) 2022، حدث انقطاع في Cloudflare لمدة 30 دقيقة مما أثر على 19 مركز بيانات بسبب تغيير في تكوين الشبكة. شاهد المستخدمون في تلك المناطق أخطاء؛ لم يواجه المستخدمون في أماكن أخرى شيئًا غير عادي.
DNS هو الخطوة الأولى في أي طلب. عندما يواجه الإصدار 1.1.1.1 من Cloudflare أو خوادم DNS الخاصة بـ CDN مشكلات في منطقة معينة - مسار Anycast تم تكوينه بشكل خاطئ، أو خادم أسماء مثقل بالأحمال - لا يمكن للمستخدمين في تلك المنطقة حل المجال الخاص بك. يعرض متصفحهم فقط "DNS_PROBE_FINISHED_NXDOMAIN."
مثال: يمكن أن تحدث مشكلات نظام أسماء النطاقات الإقليمية بسبب التصفية على مستوى مزود خدمة الإنترنت، أو مشكلات وحدة الحل المحلية، أو مشكلات توجيه البث التي تؤثر فقط على مناطق جغرافية معينة.
يمكن أن تؤدي عمليات التسريب والاختطاف والتكوينات الخاطئة في مسار BGP إلى إعادة توجيه حركة المرور من خلال مسارات دون المستوى الأمثل أو إتلافها بالكامل. عندما تواجه شركة نقل رئيسية في منطقة ما مشكلات في التوجيه، فقد تفشل حركة المرور من تلك المنطقة إلى CDN أو الأصل الخاص بك - على الرغم من أن كلا نقطتي النهاية تعملان بشكل مثالي.
مثال: تؤثر حوادث BGP على آلاف الشبكات بشكل منتظم. يمكن لمسار AS واحد تم تكوينه بشكل خاطئ أن يجعل موقعك غير قابل للوصول من بلدان بأكملها لساعات بينما يبدو جيدًا من موقع المراقبة الخاص بك.
قد يكون لدى مقدمي خدمات الإنترنت الرئيسيين في بلدان معينة اتصال منخفض بـ CDN الخاص بك بسبب النزاعات بين الأقران أو الازدحام أو مشكلات البنية التحتية. قد يواجه مستخدمو Telstra في أستراليا حالات فشل بينما لا يواجه مستخدمو Optus في نفس المدينة أي مشكلات - لأن حركة المرور تتدفق عبر مسارات مختلفة.
مثال: تسببت النزاعات بين مقدمي خدمة الإنترنت ومقدمي الخدمات السحابية تاريخيًا في حدوث تدهور لعدة أسابيع مما أثر على ملايين المستخدمين في أسواق معينة.
الموضوع المشترك: كل هذه الإخفاقات محددة جغرافيًا. أصلك يصل. تكوين CDN الخاص بك صحيح. ولكن في مكان ما بين حافتك والمستخدمين في منطقة معينة، انكسر شيء ما - ولا يمكن لمراقبتك التي تتحقق من موقع واحد في فيرجينيا اكتشافه.
تم تصميم معظم عمليات مراقبة وقت التشغيل لمشكلة أبسط: "هل يستجيب الخادم؟" بالنسبة للمواقع التي تعمل بنظام CDN والتي تخدم المستخدمين العالميين، لم يعد هذا هو السؤال الصحيح بعد الآن.
تقوم معظم خدمات المراقبة افتراضيًا بالتحقق من عدد قليل من المواقع في الولايات المتحدة أو الاتحاد الأوروبي. إذا تعطلت نقطة الاتصال الخاصة بـ Cloudflare في سنغافورة، فسيظل الشيك الخاص بك من ولاية أوريغون ناجحًا - وسيصل إلى حافة صحية مختلفة. وفي الوقت نفسه، يرى مستخدمو APAC خطأ 502.
يستخدم تشغيل عمليات التحقق من AWS إلى Cloudflare اتصالاً أساسيًا بالسحابة - وهي مسارات محسنة لا تمثل حركة مرور المستخدم الحقيقية. قد يتجاوز الفحص الاصطناعي الخاص بك من AWS ap-southeast-1 مسار الشبكة الدقيق الذي يفشل بالنسبة للمستخدمين على مزودي خدمة الإنترنت المحليين.
تعكس صفحات حالة CDN وجهة نظرهم الداخلية، وغالبًا ما يتم تجميعها عبر مئات النقاط المهمة. قد لا تؤدي المشكلة الإقليمية التي تؤثر على 5% من البنية التحتية الخاصة بهم إلى تحديث صفحة الحالة - ولكن قد تشمل هذه النسبة 5% جنوب شرق آسيا بالكامل.
تخبرك عمليات فحص HTTP ما إذا كان الطلب قد نجح أو فشل، ولكن ليس أين فشل الطلب. بدون تتبع المسار وبيانات تفصيل زمن الاستجابة من المنطقة المتأثرة، لا يمكنك تحديد ما إذا كانت المشكلة تتعلق بـ DNS، أو خطوة شبكة معينة، أو حافة CDN الخاصة بك.
يحتوي Cloudflare على أكثر من 310 نقطة تواجد. إذا كانت مراقبتك تتحقق من 3 مواقع، فأنت تتحقق من أقل من 1% من الحواف التي قد يصل إليها المستخدمون. هذا ليس اكتشافًا للانقطاع، بل هو أمل في الأفضل.
في كل دقيقة لا يتم اكتشاف انقطاع خدمة Cloudflare أو فشل CDN إقليمي فيها، فإنك تفقد المستخدمين والإيرادات والثقة في الأسواق التي قد لا تدرك حتى أنك تخدمها.
يمكن أن يؤدي الانقطاع الإقليمي أثناء ساعات العمل في تلك المنطقة الزمنية إلى تكلفة ساعات من المعاملات أو الاشتراكات أو مكالمات واجهة برمجة التطبيقات (API). لا يرسل المستخدمون رسائل بريد إلكتروني تقول "موقعك معطل بالنسبة لي" - بل يغادرون فقط. ستلاحظ انخفاضًا في المقاييس الإقليمية لاحقًا، مع عدم وجود سبب واضح.
عملاء المؤسسات لديهم اتفاقيات مستوى الخدمة. عندما لا يتمكنون من الوصول إلى النظام الأساسي الخاص بك ولم تكن تعلم حتى بوجود مشكلة، فهذه محادثة سيئة. إن عبارة "لم نكتشف الانقطاع" ليست استجابة لبناء الثقة - خاصة عندما يدفعون مقابل الموثوقية.
يزحف Googlebot من عدة مواقع عالمية. إذا كانت حافة CDN الخاصة بك في منطقة ما تعرض أخطاء أو استجابات بطيئة، فإن ذلك يؤثر على ميزانية الزحف، وتقييمات Core Web Vitals، والتصنيفات في النهاية. قد تلاحظ انخفاضًا في عدد الزيارات في أسواق معينة دون سبب واضح.
يبدأ متوسط وقت الاسترداد (MTTR) عندما تكتشف المشكلة. إذا أثر انقطاع Cloudflare الإقليمي على المستخدمين لمدة ساعتين قبل أن تعرفه من تذكرة العميل، فسيتم إضافة ساعتين إلى MTTR الفعال الخاص بك. الاكتشاف الاستباقي هو الطريقة الوحيدة لتقليل تأثير وقت التوقف الفعلي.
يتطلب اكتشاف الانقطاع الإقليمي مراقبة من مكان تواجد المستخدمين لديك، مع تشخيص متعمق لتحديد مكان حدوث الأعطال.
يصل كل موقع مراقبة إلى حواف CDN مختلفة ويجتاز مسارات شبكة مختلفة. لاكتشاف الانقطاعات الإقليمية، تحتاج إلى عقد في كل منطقة حيث لديك حركة مرور ذات معنى - آسيا والمحيط الهادئ، وأوروبا، والأمريكتين، والشرق الأوسط، وأفريقيا. ليس فقط "دوليًا" - وتحديدًا مكان تواجد المستخدمين لديك.
تغطي المراقبة من أكثر من 50 موقعًا نقاط CDN PoP الرئيسية ومسارات مزود خدمة الإنترنت.
عندما يفشل التحقق من سنغافورة ولكنه ينجح من أي مكان آخر، فأنت بحاجة إلى معرفة: هل هو DNS؟ قفزة شبكة معينة؟ حافة CDN؟ يوفر Traceroute وMTR من الموقع المتأثر الدليل الذي تحتاجه لتشخيص السبب الجذري والتصعيد إلى Cloudflare أو مزود خدمة الإنترنت أو موفر الاستضافة الخاص بك.
تعمل البيانات التشخيصية على تحويل "شيء ما معطل" إلى سبب جذري قابل للتنفيذ.
هل مسافة 400 مللي ثانية من طوكيو أمر طبيعي، أم أن هذا تدهور في حافة Cloudflare؟ تعمل البيانات التاريخية لكل موقع على إنشاء خطوط أساسية تتيح لك اكتشاف حالات الفشل البطيئة - حيث لا تؤدي زيادات زمن الوصول إلى حدوث حالات فشل جسيمة ولكنها تقلل من تجربة المستخدم. يمكنك اكتشاف مشكلة CDN إقليمية قبل أن تصبح انقطاعًا كاملاً.
تلتقط خطوط الأساس التدهور قبل أن تصبح انقطاعات.
دليل خطوة بخطوة لتنفيذ المراقبة التي تكتشف انقطاعات Cloudflare وفشل CDN الإقليمي قبل أن يقوم المستخدمون بالإبلاغ عنها.
تحقق من تحليلاتك لتحديد مكان تواجد المستخدمين لديك. إذا كانت نسبة 20% من حركة المرور تأتي من منطقة آسيا والمحيط الهادئ، فأنت بحاجة إلى عقد مراقبة متعددة هناك - سنغافورة وطوكيو وسيدني ومومباي. مطابقة تغطية المراقبة لتوزيع المستخدم الفعلي.
قم بإعداد أجهزة مراقبة HTTP لعناوين URL الأساسية الخاصة بك والتي تمر عبر Cloudflare أو CDN الخاص بك. يجب أن تصل هذه إلى حافة CDN، وليس إلى أصلك مباشرةً. قم بتضمين نطاق تطبيقك ونقاط نهاية واجهة برمجة التطبيقات وأي صفحات عامة مهمة.
تتمتع المناطق المختلفة بفترات استجابة أساسية مختلفة. قم بتكوين الحدود المنطقية: ربما يكون 500 مللي ثانية من أوروبا مقبولاً، ولكن 500 مللي ثانية من شرق الولايات المتحدة (عندما يكون أصلك هناك) يشير إلى وجود مشكلة في حافة CDN. استخدم البيانات التاريخية لوضع خطوط أساس واقعية.
قم بإعداد التنبيهات التي يتم إطلاقها عند فشل مناطق معينة - وليس فقط عند فشل جميع المواقع. ولا يزال الفشل في سنغافورة فقط يمثل انقطاعًا يستحق المعرفة. قم بتوجيه التنبيهات ذات الأولوية العالية إلى Slack أو PagerDuty أو نظام إدارة الحوادث لديك.
عند إطلاق تنبيه، عليك أن تحدد بسرعة: هل هذه مشكلة Cloudflare؟ مشكلة مسار الشبكة؟ DNS؟ قم بتمكين التتبع عند الطلب وMTR من مواقع المراقبة حتى تتمكن من جمع البيانات التشخيصية على الفور.
توثيق العملية: كيفية التحقق من انقطاع Cloudflare الإقليمي. مكان التحقق من واجهة برمجة التطبيقات لحالة Cloudflare. كيفية فتح تذكرة مع الأدلة. ما هي وسائل التخفيف التي يمكنك تطبيقها (تجاوز الفشل، وتجاوز ذاكرة التخزين المؤقت، وما إلى ذلك). إن جعل هذا جاهزًا يقلل من MTTR بشكل كبير.
قم بتعيين تذكير تقويمي أسبوعي لمراجعة زمن الوصول ووقت التشغيل لكل منطقة. ابحث عن الأنماط: هل منطقة آسيا والمحيط الهادئ أبطأ باستمرار؟ هل هناك تقلبات منتظمة في مكان محدد؟ تكتشف المراجعة الاستباقية حالات التدهور البطيئة قبل أن تؤثر على المستخدمين بشكل كبير.
بالنسبة للخدمات التي يكون فيها الانقطاع الإقليمي غير مقبول، فكر في استراتيجية CDN متعددة حيث يمكن لـ DNS تجاوز الفشل بين مقدمي الخدمة. يتطلب ذلك مراقبة كل CDN بشكل مستقل والحصول على أتمتة يمكنها تبديل حركة المرور. إنه تعقيد، لكنه مرن.
تم إنشاء Latency Global لاكتشاف هذا النوع من المشكلات بالضبط - انقطاع خدمة Cloudflare، وفشل CDN الإقليمي، ومشكلات الشبكة التي تفتقدها المراقبة في موقع واحد. نحن نراقب من أكثر من 70 موقعًا حقيقيًا عبر 6 قارات، ونغطي جميع مناطق CDN PoP الرئيسية.
يتضمن كل فحص تحليلًا كاملاً للتوقيت - دقة DNS، واتصال TCP، ومصافحة TLS، وTTFB، ووقت الاستجابة الإجمالي. عندما يفشل شيء ما في منطقة معينة، يمكنك تشغيل Traceroute وMTR من ذلك الموقع لتحديد مكان حدوث المشكلة بالضبط في مسار الشبكة. السعر واضح ومباشر: 5 دولارات شهريًا لخمس شاشات، بما في ذلك جميع المواقع.
يتطلب اكتشاف الانقطاع الإقليمي وجود بنية تحتية في العديد من المواقع - ولهذا السبب فإن معظم أدوات المراقبة إما لا توفرها أو تفرض أسعارًا مؤسسية. نحن نركز على ما يهم: التغطية وعمق التشخيص.
يحدث انقطاع CDN إقليمي عندما تفشل أو تتدهور خوادم حافة محددة أو نقاط تواجد (PoPs) في شبكة CDN، بينما تظل الحواف الأخرى قيد التشغيل. على سبيل المثال، قد تواجه Cloudflare مشكلات في نقطة الاتصال الخاصة بها في سنغافورة بينما تعمل حوافها الأمريكية والأوروبية بشكل جيد. يواجه المستخدمون الذين يقومون بالتوجيه عبر الحافة المتأثرة أخطاء أو أداء بطيئًا؛ لا يلاحظ المستخدمون في أي مكان آخر أي شيء. تكون حالات الانقطاع هذه غير مرئية للمراقبة التي تتحقق فقط من المناطق غير المتأثرة.
تعرض صفحات حالة CDN عادةً الحالة العامة الإجمالية، وليس صحة كل نقطة اتصال. عندما تتأثر 5% من الحواف، قد تظل الحالة العامة "قيد التشغيل" لأن 95% من البنية الأساسية تعمل. تتمتع صفحات الحالة أيضًا بزمن انتقال للتحديث، حيث يستغرق اكتشاف المشكلات والتحقق منها ونشرها وقتًا. بالإضافة إلى ذلك، لا تستوفي بعض المشكلات الحد الأدنى للإفصاح العام ولكنها لا تزال تؤثر على المستخدمين. إن المراقبة المستقلة من مواقع متعددة هي الطريقة الوحيدة للحصول على الحقيقة الأساسية حول التوفر الإقليمي.
على الأقل، تحتاج إلى مراقبة المواقع في كل منطقة رئيسية حيث لديك مستخدمين: أمريكا الشمالية وأوروبا وآسيا والمحيط الهادئ على الأقل. للحصول على تغطية أفضل، أكثر من 50 موقعًا موزعًا عالميًا سوف يتعامل مع معظم المشكلات الإقليمية. المفتاح هو مطابقة تغطية المراقبة لجغرافية المستخدم الخاصة بك - إذا كان 30% من المستخدمين لديك في منطقة آسيا والمحيط الهادئ، فأنت بحاجة إلى عقد متعددة هناك (سنغافورة وطوكيو وسيدني ومومباي). لا يتعلق الأمر بمطابقة كل نقاط اتصال CDN PoP، بل يتعلق بتغطية المجموعات الإقليمية الرئيسية.
أولاً، قم بجمع الأدلة التشخيصية: التتبع وMTR من الموقع المتأثر، وأكواد استجابة HTTP وبيانات التوقيت، والطوابع الزمنية. تحقق من صفحة حالة Cloudflare وTwitter بحثًا عن أي إقرار. إذا كانت المشكلة تتعلق بـ Cloudflare بشكل واضح، فافتح تذكرة دعم مع الأدلة الخاصة بك. للتخفيف الفوري، خذ بعين الاعتبار: تجاوز Cloudflare مؤقتًا للمنطقة المتأثرة (إذا كان مصدرك قادرًا على التعامل معها)، أو تمكين CDN احتياطيًا إذا كان لديك إمكانية CDN متعددة، أو تحديث صفحة الحالة الخاصة بك للإقرار بالمشكلة بينما يقوم Cloudflare بحلها. قم بتوثيق كل شيء لمراجعته بعد الحادث.
نعم، مع أجهزة المراقبة المناسبة. يظهر توقيت فحص HTTP الكامل: وقت تحليل DNS (إذا فشل DNS أو كان بطيئًا، فأنت تعلم أنها مشكلة DNS)، ووقت اتصال TCP (مشكلات مسار الشبكة)، ووقت مصافحة TLS (مشكلات الشهادة أو التشفير)، ووقت TTFB/الاستجابة (مشكلات معالجة الأصل أو الحافة). يعرض Traceroute مسار الشبكة ومكان إسقاط الحزم أو تأخيرها. ومن خلال مقارنة هذه البيانات من المنطقة المتأثرة بالمناطق السليمة، يمكنك تحديد مكان حدوث الفشل بالضبط في سلسلة الطلب.
مع فترات فحص مدتها دقيقة واحدة، يمكنك اكتشاف انقطاع التيار الكهربائي خلال دقيقة أو دقيقتين من بدايته. تؤكد معظم خدمات المراقبة حدوث انقطاع بعد 2-3 حالات فشل متتالية لتجنب التنبيه عند الومضات العابرة، لذا فإن وقت الاكتشاف الواقعي هو 2-5 دقائق. قارن ذلك بانقطاعات الخدمة التي أبلغ عنها العملاء، والتي قد تستغرق ساعات حتى تظهر من خلال تذاكر الدعم. الفرق في MTTR كبير - 5 دقائق مقابل ساعتين يعني تأثيرًا مختلفًا تمامًا على المستخدم.
قطعاً. وبسرعة، يمكن أن تواجه Akamai وAWS CloudFront وGoogle Cloud CDN وAzure CDN وأي CDN أخرى انقطاعات إقليمية. تنطبق نفس المبادئ: تتمتع شبكات CDN ببنية تحتية موزعة، وأي نظام موزع يمكن أن يتعرض لفشل جزئي. نهج الكشف هو نفسه — المراقبة من مواقع عالمية متعددة لاكتشاف المشكلات التي تؤثر على حواف أو مناطق معينة، بغض النظر عن شبكة CDN التي تستخدمها.
توقف عن الاعتماد على صفحات حالة CDN وتذاكر العملاء للتعرف على حالات انقطاع الخدمة الإقليمية. أضف نقاط النهاية الخاصة بك، وحدد مواقع المراقبة الخاصة بك، واعرف في غضون دقائق عندما يفشل Cloudflare، أو Fastly، أو أي جزء من مجموعتك في أي منطقة.
5 دولارات شهريًا • أكثر من 70 موقعًا (+40 موقعًا آخر قريبًا) • لا توجد عقود • قم بالإلغاء في أي وقت