كيفية مراقبة صفحات حالة الموردين لتلقي تنبيهات الأعطال

قبيل منتصف الليل بتوقيت المحيط الهادئ في 19 أكتوبر 2025، تسببت حالة تسابق (race condition) في أتمتة نظام DNS الخاص بـ Amazon DynamoDB في بقاء سجل DNS فارغ لنقطة النهاية الإقليمية للخدمة في us-east-1. وبدأ أي تطبيق يحتاج إلى DynamoDB في تلك المنطقة بالفشل، وامتد الضرر سريعاً إلى خدمات AWS الأخرى التي تعتمد عليها. ووفقاً للتقرير الرسمي الصادر عن AWS نفسها، استمر هذا العطل لنحو أربع عشرة ساعة ونصف.

في ذلك الصباح، كانت خوادم العديد من الفرق البرمجية تعمل بكفاءة تامة. وظلت مؤشرات وقت التشغيل (Uptime) لديهم خضراء بالكامل في حين كانت خدمة تسجيل الدخول أو معالج المدفوعات أو مزود البريد الإلكتروني المتعاقد معهم يعانون من انهيار شبه كامل. ومع ذلك، فإن معظم الأعطال تكون أقل ضخامة من ذلك: يتأخر مورد البريد الإلكتروني في إرسال الرسائل لمدة أربعين دقيقة، ويتلقى فريق الدعم سيلاً من تذاكر «لم يصلني رابط إعادة تعيين كلمة المرور»، وأخيراً يكتشف أحدهم صفحة حالة المورد التي كانت تعرض تنبيه «أداء منخفض (Degraded performance)» منذ نصف ساعة.

أعمل في Page Deltas، وهي أداة تراقب صفحات الويب العامة وتخبرك عندما تتغير بطريقة تهمك؛ لذا ضع ذلك في اعتبارك عندما أقارنها بالأدوات الأخرى أدناه. يستعرض هذا المقال كيفية توجيه الأداة نحو صفحات حالة الموردين الذين تعتمد عليهم: أي رابط URL تختار، وكيفية كتابة توجيه موجز (Brief) يتجاهل الضجيج، وأين ترسل التنبيهات، والحدود التي تتوقف عندها هذه الآلية.

لماذا تظل شاشات المراقبة لديك خضراء؟

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

إذن، لماذا لا تشترك مباشرة في صفحة المورد؟ ينبغي لك فعل ذلك إن كانت تغطي احتياجاتك تماماً. تعمل العديد من صفحات الحالة على Atlassian Statuspage وتتيح الاشتراك عبر البريد الإلكتروني أو الرسائل القصيرة أو Slack أو Teams أو Webhooks، وفقاً لما فعّله المورد. تظهر المشكلة الحقيقية عند وصولك إلى المورد الثامن: كل اشتراك يمثل إعداداً مستقلاً ينتهي غالباً في صندوق بريد موظف واحد، وكل مورد ينسق رسائله بأسلوب مختلف، وخاصية التصفية للاقتصار على المكونات التي تستخدمها فقط ليست متاحة دائماً. كما أن بعض الموردين يديرون صفحات مبنية ذاتياً دون زر اشتراك على الإطلاق.

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

أي صفحة يجب أن تراقبها؟

اختر الصفحة التي تعرض الحالة التشغيلية الحالية، وعادة ما تكون status.vendor.com. تجنب الصفحة الرئيسية للمورد أو صفحة «الثقة والموثوقية (Trust)» التسويقية. تشترك معظم صفحات حالة خدمات SaaS في التصميم نفسه: قائمة بالمكونات مع حالة كل منها، وشريط بارز للأعطال النشطة، وجدول أعمال الصيانة المجدولة، وقائمة موجزة بالحوادث الأخيرة مع رابط للأرشيف الكامل.

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

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

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

خطوات الإعداد

يستغرق الإعداد حوالي خمس دقائق، ويتبع المسار ذاته الموضح في دليل مراقبة سجل التغييرات ولكن بتوجيه موجز مختلف.

1. إنشاء حساب وتحديد قناة التنبيهات

سجل للحصول على حساب مجاني، وافتح «Channels (القنوات)»، وأضف الوجهة التي ترغب في وصول التنبيهات إليها. أنصح بإنشاء قناة مخصصة مثل #vendor-status بدلاً من إرسالها إلى #engineering حيث تضيع وسط المحادثات. تدعم منصات Slack و Discord و Microsoft Teams روابط الـ Webhook الواردة. وفي Teams، انقر بزر الفأرة الأيمن على القناة، واختر «Connectors»، ثم «Incoming Webhook»، ثم «Configure»، والصق الرابط في Page Deltas. أما خيار البريد الإلكتروني فيتطلب من المستلم تأكيد رسالة التحقق أولاً. انقر على «Send test» بجوار كل قناة للتأكد من وصول التنبيه بنجاح.

2. إضافة مراقب مع كتابة التوجيه الموجز (Brief)

انقر على «New monitor» والصق رابط صفحة الحالة. خصص مراقباً واحداً لكل مورد حتى يتسنى لك تسمية مكونات ذلك المورد بدقة في التوجيه؛ وإذا كانت هناك فرق مختلفة تهتم بموردين مختلفين، فاربط قناة تنبيه مخصصة بكل مراقب.

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

يمثل «الوصف (Description)» الخاص بالمراقب التوجيه الذي يقرؤه نموذج الذكاء الاصطناعي (LLM) لتحديد ما إذا كان التغيير يستحق التنبيه. اكتبه كأنك تترك ملاحظة لزميل يراقب الصفحة نيابة عنك. بالنسبة لمزود بريد إلكتروني، يمكنك كتابة صيغة مثل هذه:

صفحة الحالة الخاصة بمزود البريد الإلكتروني. نستخدم فقط مكوني Email API و Webhooks في منطقة الولايات المتحدة (US region).
أرسل تنبيهاً عند نشر حادث جديد يؤثر على هذين المكونين أو تلك المنطقة، أو عند تغير حالة العطل أو درجة خطورته، أو عند حله. أرسل تنبيهاً إذا تغيرت حالة أي من المكونين من وضع التشغيل Operational.
تجاهل نسب الجاهزية، والطوابع الزمنية لـ «آخر تحديث»، وسطور «لم يتم الإبلاغ عن أي حوادث» اليومية، والأعطال في المناطق الأخرى.
اذكر الصيانة المجدولة فقط إذا كانت ستبدأ في غضون 48 ساعة.
لخص المكون المتأثر، والحالة الحالية، وأحدث المستجدات.

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

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

3. ترك الفحص الأول لتحديد خط الأساس

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

4. الفحص الفوري «Check now» عند الشك في عطل

لا تحتاج إلى ضبط فترات فحص ثابتة بالثواني في Page Deltas؛ إذ يعمل الجدول بنظام تكيفي (Adaptive)، حيث تخضع الصفحات سريعة التغير لفحص أكثر تواتراً، وتحظى الخطط المدفوعة بالأولوية عند ازدحام طابور المعالجة. وتكون صفحة الحالة ساكنة في معظم الأوقات، لذا عندما يرتفع معدل الأخطاء لديك وتشتبه في عطل لدى المورد، انقر على «Check now» في المراقب الخاص به. الإجراء نفسه متاح عبر واجهة برمجة التطبيقات (API)، بحد أقصى مرة واحدة في الدقيقة لكل مراقب:

curl -X POST \
  -H "Authorization: Bearer $PAGEDELTAS_TOKEN" \
  https://api.pagedeltas.com/api/monitors/$MONITOR_ID/check-now

ماذا تفعل عند وصول التنبيه؟

عندما يطابق التغيير توجيهك، تتلقى رسالة واحدة تحتوي على ملخص بلغة واضحة مصحوباً بلقطتي شاشة للمقارنة قبل التغيير وبعده. وإذا كنت تستخدم Webhook موقّعاً، فإن البيانات المرسلة تبدو على النحو التالي (القيم هنا افتراضية للتوضيح):

{
  "event": "change.detected",
  "monitor_id": "01HX7Q...",
  "monitor_url": "https://status.example-mail.com/",
  "monitor_name": "حالة مزود البريد الإلكتروني",
  "change_id": "...",
  "detected_at": "2026-10-14T07:21:00Z",
  "summary": "عطل جديد: تأخر تسليم البريد الإلكتروني في منطقة الولايات المتحدة. تغيرت حالة Email API من Operational إلى Degraded Performance. الحالة: قيد التحقيق.",
  "before_screenshot_url": "https://.../before.png",
  "after_screenshot_url": "https://.../after.png",
  "dashboard_url": "https://app.pagedeltas.com/monitors/..."
}

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

إذا كان فريقك يعتمد على PagerDuty أو أي أداة إدارة حوادث أخرى، فيمكن لـ Webhook الموقّع تغذيتها عبر خادم ترحيل وسيط خفيف. وبما أن هيكل بياناتنا يختلف عن تنسيق PagerDuty، فكل ما تحتاجه هو بضعة أسطر برمجية في دالة سحابية (Serverless Function) للتحقق من التوقيع وإعادة توجيه الحدث:

import crypto from "node:crypto";

export async function handle(rawBody, signature) {
  const expected = "sha256=" + crypto
    .createHmac("sha256", process.env.PAGEDELTAS_WEBHOOK_SECRET)
    .update(rawBody).digest("hex");
  if (signature.length !== expected.length ||
      !crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expected))) {
    return 401;
  }
  const alert = JSON.parse(rawBody);
  await fetch("https://events.pagerduty.com/v2/enqueue", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      routing_key: process.env.PAGERDUTY_ROUTING_KEY,
      event_action: "trigger",
      dedup_key: alert.change_id,
      payload: { summary: alert.summary, source: alert.monitor_url, severity: "warning" },
      links: [{ href: alert.dashboard_url, text: "Open in Page Deltas" }],
    }),
  });
  return 200;
}

تأكد من حساب تجزئة (Hash) نص الطلب الخام (raw body) قبل تحويله إلى كائن JSON، وإلا فلن يتطابق التوقيع. وتغطي وثائق قنوات التنبيه كافة التفاصيل التقنية. يُرسل كل تنبيه مرة واحدة لكل قناة دون إعادة محاولة تلقائية؛ لذا بالنسبة للموردين الذين لا غنى عنهم إطلاقاً، اربط قناة ثانية من نوع مختلف (مثل Slack مع البريد الإلكتروني) تحسباً لتعطل خادم الترحيل أو مواجهة Slack لمشكلة تقنية.

حدود هذه الآلية

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

أولاً، غالباً ما يتأخر الموردون في إعلان الأعطال؛ ففي كثير من الأحيان ترصد رسومك البيانية للأخطاء الخلل قبل أن تعترف به صفحة الحالة بوقت طويل، لذا تعامل مع التنبيه كتأكيد رسمي لسبب المشكلة وليس كإنذار مبكر أولي. كما أنها ليست بديلاً عن الفحوصات الاصطناعية (Synthetic Checks) أو مراقبة الجاهزية لخدماتك؛ فهذه تخبرك بأن منتجك معطل، بينما توضح لك صفحة الحالة سبب ذلك.

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

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

ابدأ بأهم ثلاثة موردين

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

جوليان (Julien)، مدير المنتج في Page Deltas