تقول صفحة الحالة الخاصة بك أن كل شيء يعمل. يظهر APM الخاص بك باللون الأخضر. وفي الوقت نفسه، لا يستطيع عميل في سنغافورة تسجيل الدخول. وتخلى عميل محتمل في البرازيل عن الاشتراك. فشلت صفقة مؤسسية في ألمانيا بسبب "استمر العرض التوضيحي في انتهاء المهلة."
إن مراقبة وقت التشغيل العالمي لـ SaaS ليست اختيارية - إنها الطريقة التي ترى بها ما يختبره عملاؤك فعليًا.
لقد قمت ببناء منتج قوي. البنية التحتية موجودة على AWS أو GCP. أنت تستخدم Cloudflare أو Fastly. لديك مراقبة أساسية لوقت التشغيل - ربما تتحقق من موقع واحد أو موقعين كل بضع دقائق.
ثم تبدأ في الحصول على تذاكر الدعم من مناطق محددة. "لا يمكن الوصول إلى التطبيق." "يستمر تسجيل الدخول بالفشل." "لن يتم تحميل الصفحات." قمت بفحص لوحة القيادة الخاصة بك - كل شيء يبدو على ما يرام. تطلب منهم المحاولة مرة أخرى - أحيانًا ينجح الأمر، وأحيانًا لا ينجح.
أنت ترفض ذلك على أنه خطأ مستخدم، أو مشكلات في الشبكة، أو مشكلات عابرة. لكن التذاكر تستمر في القدوم. وأنت تدرك: ليس لديك طريقة للتحقق مما يختبره المستخدمون في سنغافورة أو ساو باولو أو جوهانسبرج فعليًا.
مراقبتك تكذب عليك، ليس عن قصد، ولكن عن طريق الإغفال. إنها تتحقق من مكان واحد وتفترض أن ذلك يمثل العالم بأكمله.
هذا هو المكان الذي تصبح فيه مراقبة وقت التشغيل العالمي لـ SaaS أمرًا بالغ الأهمية. ليس من الجميل أن تمتلكه، ولكن باعتبارها الطريقة الوحيدة لمعرفة ما إذا كان منتجك متاحًا بالفعل للعملاء الذين تحاول الوصول إليهم.
الإنترنت ليس موحدًا. الطلب من طوكيو إلى موطنك في شرق الولايات المتحدة يعبر بنية تحتية مختلفة تمامًا عن الطلب من لندن.
DNS ليس فوريًا أو عالميًا. إذا كانت أقرب عقدة Anycast لمزود DNS الخاص بك إلى المستخدم محملة بشكل زائد أو تم تكوينها بشكل خاطئ أو لا يمكن الوصول إليها، فلن يتمكن هذا المستخدم من حل المجال الخاص بك - على الرغم من أن خوادمك تعمل بشكل جيد. يمكن لمحللات DNS المختلفة عرض نتائج مختلفة، وقد يقوم بعضها بتخزين سجلات قديمة أو غير صحيحة.
السيناريو الحقيقي: تعرض أحد موفري خدمة DNS السحابية الرئيسية لانقطاع لمدة 4 ساعات مما أثر على خوادم الأسماء في منطقة آسيا والمحيط الهادئ فقط. أظهرت منتجات SaaS التي تستخدم هذا المزود وقت تشغيل بنسبة 100% في المراقبة في الولايات المتحدة بينما تكون غير متصلة بالإنترنت تمامًا لملياري مستخدم محتمل.
يمكن أن تتغير مسارات BGP أو تنقطع أو تصبح دون المستوى الأمثل دون سابق إنذار. يمكن أن يؤدي تسرب المسار، أو مسار AS الذي تم تكوينه بشكل خاطئ، أو انقطاع مزود النقل إلى جعل الخوادم الخاصة بك غير قابلة للوصول من بلدان بأكملها - مع إمكانية الوصول إليها تمامًا من الآخرين. تحدث هذه المشكلات بانتظام ويمكن أن تستمر لساعات.
السيناريو الحقيقي: أخطأ أحد مزودي خدمات الإنترنت الرئيسيين في البرازيل في تكوين التوجيه الخاص به، مما أدى إلى توجيه كل حركة المرور إلى SaaS ومقرها الولايات المتحدة عبر أوروبا قبل الوصول إلى الولايات المتحدة. قفز زمن الاستجابة من 120 مللي ثانية إلى 800 مللي ثانية - وهو عملي، ولكنه بطيء بشكل غير قابل للاستخدام بالنسبة لميزات الوقت الفعلي.
تحتوي شبكة CDN الخاصة بك على المئات من مواقع التخزين المؤقت، ولكن ليست جميعها سليمة في جميع الأوقات. قد تكون الحافة في جاكرتا منخفضة بينما تكون الحافة في سنغافورة جيدة. قد لا تعكس صفحة حالة CDN التدهور الإقليمي، ويواجه المستخدمون الذين تم توجيههم إلى الحافة التي بها مشكلات حالات فشل أو بطء شديد.
السيناريو الحقيقي: كانت حافة CDN في ساو باولو تقدم 502 خطأ لمدة 6 ساعات بسبب مشكلة في تكوين الواجهة الخلفية. أظهرت الحالة العالمية لـ CDN "تشغيلية" لأن 95% من الحواف كانت جيدة. رأى المستخدمون البرازيليون أن SaaS معطلة تمامًا.
لدى كبار مزودي خدمات الإنترنت ترتيبات نظير تؤثر على كيفية تدفق حركة المرور. إذا كانت نقطة النظير بين مزود خدمة الإنترنت الإقليمي وموفر السحابة الخاص بك مزدحمة أو تعاني من فقدان الحزم، فسيكون لدى المستخدمين الموجودين على مزود خدمة الإنترنت هذا وصول متدهور إلى SaaS الخاص بك - حتى لو لم يواجه المستخدمون على مزود خدمة إنترنت مختلف في نفس المدينة أي مشكلات.
السيناريو الحقيقي: كان هناك نزاع بين أحد مزودي خدمات الإنترنت الرئيسيين في الهند مع مزود خدمات سحابية أمريكي استمر لمدة 3 أسابيع. واجه المستخدمون على مزود خدمة الإنترنت هذا أوقات تحميل تزيد عن 5 ثوانٍ. خسرت شركة SaaS حصة كبيرة من السوق الهندية قبل أن تدرك وجود مشكلة.
المشكلة الأساسية: كل حالات الفشل هذه محددة بالموقع. البنية التحتية الخاصة بك تعمل. الكود الخاص بك على ما يرام. ولكن في مكان ما بين خوادمك والمستخدمين في مناطق معينة، يوجد شيء ما معطل - والطريقة الوحيدة لاكتشافه هي التحقق من المكان الفعلي لهؤلاء المستخدمين.
تم تصميم معظم أدوات مراقبة وقت التشغيل لعصر أبسط - عندما "يستجيب الخادم؟" كان سؤالا كافيا. بالنسبة إلى SaaS مع المستخدمين العالميين، لم يعد هذا كافيًا.
تتحقق العديد من إعدادات مراقبة SaaS من 1 إلى 5 مواقع، وغالبًا ما تتجمع في الولايات المتحدة وأوروبا. إذا كان المستخدمون لديك موجودين في منطقة آسيا والمحيط الهادئ، أو أمريكا اللاتينية، أو الشرق الأوسط، أو أفريقيا، فلن يكون لديك أي رؤية حول تجربتهم. ببساطة لن يتم تسجيل انقطاع إقليمي.
إن إجراء عمليات التحقق من مناطق AWS إلى البنية التحتية التي تستضيفها AWS يستفيد من الاتصال الأساسي السحابي المحسّن. يجتاز المستخدمون الحقيقيون على الشبكات السكنية أو شبكات المؤسسات مسارات مختلفة تمامًا مع أوضاع فشل مختلفة.
قد تستجيب SaaS لديك تقنيًا ولكن يستغرق تحميلها 15 ثانية. يشير فحص HTTP 200 البسيط إلى "أعلى" - ولكن بالنسبة للمستخدمين، فهو معطل فعليًا. بدون حدود زمن الوصول لكل منطقة، ستفوتك حالات الفشل البطيئة التي تحبط المستخدمين.
عندما يحدث انقطاع إقليمي، عليك أن تعرف: هل هو DNS؟ هل هو مسار الشبكة؟ هل انتهت مهلة مصافحة TLS؟ بدون تتبع المسار، وMTR، وتفاصيل وقت الاستجابة، لا يمكنك تشخيص السبب الجذري أو تقديم دليل إلى مزود الاستضافة الخاص بك.
عندما تقوم بالمراقبة من عدد قليل من المواقع فقط، فإنك لا ترى سوى جزء صغير مما يواجهه المستخدمون. والباقي عبارة عن نقطة عمياء حيث يحدث انقطاع التيار الكهربائي دون اكتشافه.
في كل دقيقة يتعذر فيها الوصول إلى SaaS الخاص بك في منطقة ما، فإنك تفقد المستخدمين والإيرادات والسمعة - غالبًا دون معرفة ذلك.
المستخدمون الذين لا يستطيعون الوصول إلى SaaS الخاص بك لا يشتكون دائمًا، بل يغادرون. إذا واجه المستخدم التجريبي انقطاعًا أثناء جلسته الأولى، فسيختفي. إذا واجه العميل الذي يدفع رسومًا مشكلات متكررة، فسيبدأ في البحث عن بدائل. ستشاهد تغيرًا في المقاييس ولكنك لن تعرف أن سبب ذلك هو مشكلات التوفر الإقليمي.
التسويق الخاص بك يجذب حركة المرور من جميع أنحاء العالم. إذا كان تدفق الاشتراك معطلاً أو بطيئًا بشكل مستحيل في مناطق معينة، فسترتد حركة المرور هذه. لقد دفعت مقابل الاستحواذ، لكن فشل التحويل بسبب مشكلة إقليمية لم تكن تعلم بوجودها. CAC ترتفع. القيمة الدائمة تنخفض.
يقوم Google بالزحف من مواقع عالمية متعددة. إذا واجه Googlebot استجابات بطيئة أو إخفاقات من مناطق معينة، فسيؤثر ذلك على نتائج مؤشرات أداء الويب الأساسية، وتكرار الزحف، وفي النهاية التصنيفات في تلك الأسواق. تنخفض حركة المرور العضوية الخاصة بك في بلدان معينة، وليس لديك أي فكرة عن السبب.
تنتشر الكلمة. "إن SaaS غير موثوق بها في منطقة آسيا والمحيط الهادئ." "لقد جربناها ولكن التطبيق لا يتم تحميله بشكل صحيح من مكتبنا في برلين." تعمل مراجعات G2 وخيوط Twitter ودردشة مجتمع Slack على تشكيل الإدراك بطرق يصعب عكسها. بحلول الوقت الذي تتعرف فيه على المشكلة، يكون الضرر قد حدث.
تتطلب المراقبة العالمية الفعالة لوقت التشغيل تنوعًا جغرافيًا وعمقًا تشخيصيًا وحدود التنبيه الصحيحة.
لا تقتصر التغطية على الكمية فحسب، بل تتعلق أيضًا بمطابقة الموقع الجغرافي للمستخدم. إذا كان لديك مستخدمين في جنوب شرق آسيا، فأنت بحاجة إلى عقد في سنغافورة وجاكرتا ومومباي وطوكيو وسيدني. إذا كنت تستهدف أمريكا اللاتينية، فأنت بحاجة إلى ساو باولو وبوينس آيرس ومكسيكو سيتي. يكشف كل موقع عن ظروف الشبكة المختلفة.
مواقع مراقبة الخريطة إلى حيث يتواجد عملاؤك الذين يدفعون.
عند حدوث انقطاع، تحتاج إلى معرفة مكان حدوث الفشل في مسار الشبكة. هل هو حل DNS؟ قفزة شبكة معينة؟ حافة CDN الخاصة بك؟ تمنحك بيانات Traceroute وMTR من المنطقة المتضررة الدليل لتشخيص السبب الجذري وتصعيده إلى مقدمي الخدمة بشكل فعال.
تعمل البيانات التشخيصية على تحويل "الأمر في مكان ما" إلى "هذا هو السبب بالضبط".
هل زمن الاستجابة 300 مللي ثانية من طوكيو طبيعي أم تدهور؟ بدون البيانات التاريخية، لا يمكنك معرفة ذلك. تعمل المراقبة المستمرة على إنشاء خطوط أساسية لكل موقع، حتى تتمكن من التنبيه بشأن الانحرافات عن الوضع الطبيعي - ورصد حالات التدهور البطيئة قبل أن تتحول إلى انقطاعات، والتمييز بين المشكلات الحقيقية والتغيرات المفاجئة لمرة واحدة.
تسمح لك الخطوط الأساسية بالتنبيه إلى "أسوأ من المعتاد" - وليس فقط "للأسفل".
دليل خطوة بخطوة لتنفيذ المراقبة التي تكتشف فعليًا الانقطاعات الإقليمية.
قم بمراجعة التحليلات لتحديد أفضل 20 دولة من حيث المستخدمين النشطين والإيرادات. تحقق من مصدر الاشتراكات، ومن أين يتم تحويل التجارب، ومن أين تنشأ إيرادات التوسع. هذه هي المناطق التي يجب عليك المراقبة منها.
لا تحتاج كل نقطة نهاية إلى مراقبة عالمية. التركيز على: عنوان URL الرئيسي للتطبيق، ونقاط نهاية تسجيل الدخول/المصادقة، وتدفق الاشتراك، ونقاط نهاية واجهة برمجة التطبيقات (API) التي يستخدمها العملاء، وأي صفحات عامة مهمة لتحسين محركات البحث أو التحويلات.
اختر خدمة مراقبة ذات تغطية جغرافية واسعة - 50 موقعًا على الأقل في جميع القارات. تأكد من أن التغطية تتوافق مع جغرافية المستخدم الخاصة بك. قم بتعيين فترات الفحص إلى دقيقة واحدة لنقاط النهاية الحرجة؛ 5 دقائق للصفحات الثانوية.
لا تكتفي بالتنبيه عند حدوث حالات الفشل، بل قم بالتنبيه عندما يتجاوز وقت الاستجابة الحدود المقبولة. بالنسبة إلى SaaS، ضع في اعتبارك ما يلي: <1s لصفحة تسجيل الدخول، <2s لعمليات تحميل لوحة المعلومات، <500ms لاستدعاءات واجهة برمجة التطبيقات (API). قد يلزم أن تكون العتبات الإقليمية أعلى قليلاً بالنسبة للمواقع البعيدة.
قم بتكوين التنبيهات للتشغيل عند فشل مناطق معينة أو تدهورها. توجيه التنبيهات الإقليمية ذات الأولوية العالية إلى المهندسين تحت الطلب. التكامل مع Slack، أو PagerDuty، أو سير عمل إدارة الحوادث الحالي لديك.
تأكد من أنه يمكنك تشغيل Traceroute وMTR من أي موقع مراقبة عند الطلب. عند إطلاق تنبيه، ستحتاج إلى بيانات تشخيصية فورية لتحديد ما إذا كانت المشكلة تتعلق بـ DNS أو توجيه الشبكة أو CDN أو الأصل.
قم بتعيين تذكير تقويمي متكرر لمراجعة اتجاهات وقت التشغيل ووقت الاستجابة الإقليمية. ابحث عن حالات التدهور البطيء التي لم تؤدي إلى إطلاق التنبيهات، والمناطق ذات زمن الاستجابة العالي باستمرار، والأنماط التي ترتبط بشكاوى المستخدمين أو البيانات المتقطعة.
قم بتوثيق ما يجب فعله عند اكتشاف انقطاع إقليمي: كيفية التحقق من المشكلة، ومن يجب الاتصال به في CDN أو موفر الاستضافة، وما هي البيانات التشخيصية التي يجب جمعها، وكيفية توصيل الحالة إلى العملاء المتأثرين.
تم إنشاء Latency Global خصيصًا لنوع الرؤية العالمية التي تحتاجها منتجات SaaS. نحن نراقب من أكثر من 70 موقعًا حقيقيًا عبر 6 قارات - ونغطي كل منطقة رئيسية قد يتواجد فيها المستخدمون.
يتضمن كل فحص تحليلًا كاملاً للتوقيت (DNS، TCP، TLS، TTFB)، ويمكنك تشغيل Traceroute وMTR من أي مكان عند التحقيق في المشكلات. تُظهر لك البيانات التاريخية الاتجاهات لكل منطقة، حتى تتمكن من اكتشاف حالات التدهور قبل أن تتحول إلى انقطاعات. السعر واضح ومباشر: 5 دولارات شهريًا لخمسة شاشات مع إمكانية الوصول إلى جميع المواقع.
تتطلب المراقبة العالمية بنية تحتية مكثفة - ولهذا السبب تتقاضى معظم الأدوات ما بين 50 إلى 500 دولار شهريًا. نحن نبقيها في متناول SaaS في المرحلة المبكرة من خلال التركيز على ما يهم: التغطية الجغرافية وعمق التشخيص.
عادةً ما تخدم منتجات SaaS المستخدمين في جميع أنحاء العالم، وليس فقط من منطقة جغرافية واحدة. على عكس البرامج التقليدية الموجودة داخل الشركة، يجب أن يكون من الممكن الوصول إلى SaaS الخاص بك من أي مكان يتواجد فيه عملاؤك. يمكن أن تؤدي الانقطاعات الإقليمية - الناجمة عن مشكلات DNS، أو مشكلات توجيه BGP، أو فشل CDN، أو مشكلات نظير مزود خدمة الإنترنت - إلى عدم إمكانية الوصول إلى منتجك في الأسواق بأكملها بينما يبدو أنه يعمل بكامل طاقته من موقع المراقبة الخاص بك. إن مراقبة وقت التشغيل العالمي هي الطريقة الوحيدة لمعرفة ما يختبره المستخدمون الدوليون فعليًا.
يعتمد ذلك على جغرافية المستخدم الخاصة بك، ولكن أكثر من 50 موقعًا يعد خطًا أساسيًا جيدًا للتغطية الشاملة. المفتاح هو ضمان حصولك على المراقبة في كل منطقة حيث يوجد عدد كبير من المستخدمين أو الإيرادات. إذا كان 15% من ARR الخاص بك يأتي من منطقة آسيا والمحيط الهادئ، فأنت بحاجة إلى عقد متعددة عبر منطقة آسيا والمحيط الهادئ. إذا كنت تتوسع في أمريكا اللاتينية، فأنت بحاجة إلى عقد في البرازيل والأرجنتين والمكسيك. قم بمطابقة تغطية المراقبة مع أهمية العمل، وليس فقط حجم المستخدم.
تعرض لوحات معلومات CDN وموفر الخدمة السحابية طريقة العرض الداخلية الخاصة بها - والتي غالبًا ما تكون محدودة. قد تظهر "جميع الأنظمة قيد التشغيل" بينما يواجه المستخدمون في مناطق معينة حالات فشل بسبب مشكلات النظير، أو مشكلات توجيه BGP، أو تدهور مستوى الحافة الذي لا يتم تسجيله على أنه انقطاع كامل. تمنحك المراقبة المستقلة من خارج البنية الأساسية لديك حقيقة أساسية حول ما يختبره المستخدمون النهائيون فعليًا، والذي غالبًا ما يختلف عما تظهره لوحات معلومات الموفر.
كلاهما، يتم تحديد أولوياتهما حسب تأثير الأعمال. ابدأ بـ: (1) عنوان URL/لوحة التحكم الرئيسية للتطبيق، (2) نقاط نهاية تسجيل الدخول/المصادقة، (3) تدفق الاشتراك، (4) نقاط نهاية واجهة برمجة التطبيقات التي يستخدمها العملاء، (5) الصفحة الرئيسية لموقع التسويق. بالنسبة إلى SaaS، يعد تدفق المصادقة أمرًا بالغ الأهمية بشكل خاص - إذا لم يتمكن المستخدمون من تسجيل الدخول من منطقة ما، فلن يتمكنوا من استخدام منتجك. تعتبر نقاط نهاية واجهة برمجة التطبيقات (API) مهمة إذا كان لديك نظام أساسي للتكامل أو عملاء يعتمدون على واجهة برمجة التطبيقات (API) الخاصة بك.
مع فواصل زمنية للفحص مدتها دقيقة واحدة، يمكنك اكتشاف انقطاع التيار الكهربائي خلال دقيقة أو دقيقتين. يجب أن يكون التنبيه فوريًا بمجرد تأكيد الفشل (عادةً بعد 2-3 حالات فشل متتالية لتجنب التنبيه عند الومضات العابرة). بالنسبة لنقاط النهاية المهمة في الأسواق الرئيسية، فأنت تريد أن تعرف ذلك في غضون 5 دقائق من بدء الانقطاع. كلما اكتشفت بشكل أسرع، كلما تمكنت من التشخيص والتخفيف بشكل أسرع - أو على الأقل، إبلاغ الحالة إلى العملاء المتأثرين.
حتى عندما تكون المشكلة في المنبع، تمنحك المراقبة ما يلي: (1) دليل على وجود المشكلة (لا يمكنك إصلاح ما لا يمكنك إثباته)، (2) بيانات تشخيصية (traceroute، MTR) لتحديد الموفر المحدد أو القفزة المسببة للمشكلات، (3) الوثائق للتصعيد بشكل فعال إلى CDN أو موفر الاستضافة، و(4) بيانات لإبلاغ ما إذا كنت بحاجة إلى إضافة التكرار أو تبديل موفري الخدمة أو إضافة مواقع مؤقتة في المناطق المتأثرة. إن معرفة المشكلة هي الخطوة الأولى لأي تخفيف.
توقف عن التساؤل عما إذا كان يمكن الوصول إلى SaaS الخاص بك بالفعل في سنغافورة أو ساو باولو أو سيدني. أضف نقاط النهاية الخاصة بك، وحدد مواقع المراقبة الخاصة بك، وشاهد ما يختبره المستخدمون العالميون فعليًا - قبل أن يخبروك عنه.
5 دولارات شهريًا • أكثر من 70 موقعًا (+40 موقعًا آخر قريبًا) • لا توجد عقود • قم بالإلغاء في أي وقت