الأدلة

كيف تبني صفحة حالة الخدمة: المكونات والحوادث وفحوص التشغيل

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

ما الغاية من صفحة الحالة

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

هي ليست سجل تغييرات. فالميزات الجديدة تُنشر في صفحة سجل التغييرات، أما الأعطال والصيانة فتُنشر هنا.

ما تحتاجه الصفحة

البيانات

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

عادةً ما تكون حالات المكونات قائمة ثابتة وقصيرة: تعمل، أداء متدهور، تعطل جزئي، تعطل كبير، تحت الصيانة.

الصفحات

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

الصلاحيات

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

القرار الأهم: اجعلها مستقلة

هنا تفشل معظم صفحات الحالة المبنية يدوياً. إذا كانت صفحة الحالة:

  • تعمل على الخادم نفسه أو حساب الاستضافة نفسه لتطبيقك،
  • أو تقرأ من قاعدة البيانات نفسها،
  • أو تقع خلف إعداد النطاق أو شبكة توصيل المحتوى نفسها،
  • أو يتم نشرها عبر خط النشر نفسه،

فإن كثيراً من الانقطاعات ستُسقطها هي أيضاً، في اللحظة التي يحتاج فيها الناس إليها أكثر. خطوات عملية:

  • استضافة منفصلة. مشروع أو مزود مختلف عن التطبيق الرئيسي.
  • نطاق فرعي خاص بها، مثل status.example.com، يُوجَّه بشكل مستقل في DNS. راجع كيف تعمل النطاقات وDNS.
  • بيانات خاصة بها. تُحفظ الحوادث في تخزين صفحة الحالة نفسها، لا في قاعدة بيانات تطبيقك.
  • نسخة احتياطية ثابتة. بعض الفرق تجعل الصفحة العامة ثابتة وتعيد بناءها عند كل تحديث، فلا يبقى الكثير مما يمكن أن ينكسر.

التحديث اليدوي أم الفحوص الآلية

يدوي (ابدأ من هنا)

ينشر فريقك الحوادث ويغيّر حالات المكونات يدوياً من صفحة الإدارة. وهذه هي الطريقة التي تعمل بها كثير من صفحات الحالة عملياً، لأن تقدير إنسان («الدفع بطيء لبعض أنواع البطاقات») أنفع من نقطة حمراء تلقائية.

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

آلي

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

  • أداة مراقبة خارجية تستدعي صفحة الحالة عبر webhook عندما يفشل فحص أو يتعافى، فتحدّث صفحة الحالة المكون.
  • مهمة مجدولة في استضافة صفحة الحالة نفسها تفحص كل مكون وتسجل النتيجة. تحقق من طريقة استضافتك للمهام المجدولة قبل الاعتماد عليها؛ ويشرح دليلنا عن تشغيل المهام الخلفية الخيارات المتاحة.

قد تتذبذب التغييرات الآلية (تعمل ثم تتعطل ثم تعمل) على شبكة بطيئة. اشترط فشل فحصين أو ثلاثة قبل تغيير الحالة، ودع إنساناً يؤكد الأمر قبل الإعلان عن انقطاع كبير.

كتابة تحديثات الحوادث

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

مطالبة أولى تنجح

ابنِ صفحة حالة مستقلة لتطبيقنا Parcelio، وتُستضاف بشكل منفصل على status.parcelio.com. المكونات: الموقع، وواجهة برمجة التتبع، والإشعارات، والمدفوعات، ولكل منها حالة من: تعمل، أداء متدهور، تعطل جزئي، تعطل كبير، أو تحت الصيانة. تعرض الصفحة العامة شريطاً عاماً يستخدم أسوأ حالة حالية، وكل مكون مع حالته، وأي حوادث نشطة مع تحديثات مؤرخة بالوقت من الأحدث إلى الأقدم، والصيانة القادمة، وقائمة بالحوادث السابقة مرتبة حسب الشهر. ولكل حادثة صفحتها الخاصة. أضف صفحة إدارة محمية بكلمة مرور لإنشاء الحوادث (العنوان، والتأثير، والمكونات المتأثرة)، ونشر التحديثات (الرسالة والحالة: قيد التحقيق، تم تحديد السبب، قيد المراقبة، تم الحل)، وتغيير حالات المكونات، وجدولة الصيانة. أضف نقطة نهاية POST /api/check-result تقبل اسم مكون وحالة صاعد أو هابط من أداة مراقبة خارجية، ومحمية برمز سري، وتضع المكون في حالة أداء متدهور فقط بعد ثلاثة إخفاقات متتالية. خزّن كل شيء في قاعدة بيانات هذا التطبيق. تصميم بسيط وهادئ يُحمَّل بسرعة على الهواتف.

خطوات البناء

  1. الصفحة العامة والإدارة مع الحوادث اليدوية. هذا وحده يكفي لصفحة حالة تعمل.
  2. استضفها بشكل منفصل ووجّه نطاقاً فرعياً إليها.
  3. صفحات الحوادث والسجل.
  4. نوافذ الصيانة.
  5. الاشتراكات. تسجيل عبر البريد الإلكتروني بتأكيد مزدوج، وإشعارات عند الحوادث الجديدة والتحديثات. يحتاج البريد إلى مزود؛ راجع كيفية إرسال البريد الإلكتروني من تطبيقك.
  6. Webhook للمراقبة إذا أردت تغييرات حالة آلية.
  7. نفّذ تمريناً. أنشئ حادثة وهمية، وانشر تحديثات، واحلها، وتحقق من الرسائل، ثم احذفها.

الأخطاء الشائعة

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

متى تكون خدمة صفحة حالة مستضافة هي الخيار الأفضل

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

ابنِ صفحتك بنفسك عندما تريد تحكماً كاملاً في التصميم والصياغة، أو عندما تكون احتياجاتك بسيطة (عدد قليل من المكونات وتحديثات يدوية)، أو عندما تكون صفحة الحالة جزءاً من منتج تبنيه للآخرين.

بناؤها مع Mythex

في Mythex يمكنك بناء صفحة الحالة كمشروع مستقل عن تطبيقك الرئيسي، فتحصل على استضافة منفصلة وقاعدة بيانات خاصة بها. صِفها في الدردشة، وتحقق منها في المعاينة المباشرة، ثم انشرها واربط نطاقاً فرعياً مثل status.yourdomain.com (النطاقات المخصصة متاحة في باقة Pro). واعلم أن تطبيقات Mythex المنشورة وقواعد بياناتها تنام عند الخمول وتستيقظ عند الزيارة التالية، لذلك قد يكون التحميل الأول بعد فترة هدوء أبطأ؛ وصفحة بسيطة وخفيفة تساعد في ذلك.

لا توثّق Mythex المهام المجدولة حالياً، لذلك للفحوص الآلية استخدم أداة مراقبة تشغيل خارجية تستدعي نقطة نهاية webhook في صفحة الحالة (راجع وصفة الـ webhooks). وتمر تنبيهات البريد إلى المشتركين عبر مزودك الخاص، مع حفظ المفتاح كسرّ سري في المشروع (وصفة إرسال البريد).

الأسئلة

ما هي صفحة الحالة؟

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

هل يجب أن تُستضاف صفحة الحالة مع تطبيقي؟

لا. فإذا شاركت التطبيق في الاستضافة أو إعداد النطاق أو قاعدة البيانات، فقد تتوقف في الانقطاع نفسه الذي من المفترض أن تُبلغ عنه. استضفها بشكل منفصل، على نطاق فرعي مثل status.yourdomain.com.

هل أحتاج إلى مراقبة آلية؟

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

ماذا ينبغي أن يقول تحديث الحادثة؟

ما الذي تأثر، وما الذي سيلاحظه المستخدمون، وما الذي تفعله، ومتى سيأتي التحديث التالي. يجب أن يكون التحديث قصيراً وواضحاً ومؤرخاً بالوقت، حتى لو كان مجرد «ما زلنا نحقق في الأمر».

Mythex · Pricing · ابنِ أي شيء بالذكاء الاصطناعي · قوالب المواقع والتطبيقات · مقارنات Mythex · مصطلحات بناء التطبيقات بالذكاء الاصطناعي · أدوات مجانية لبناء التطبيقات بالذكاء الاصطناعي · English

English አማርኛ Български বাংলা Bosanski Català Čeština Dansk Deutsch Ελληνικά Español Español (España) Eesti فارسی Suomi Français Français (Canada) ગુજરાતી हिन्दी Hrvatski Magyar Հայերեն Bahasa Indonesia Íslenska Italiano 日本語 ქართული Қазақ тілі ಕನ್ನಡ 한국어 Lietuvių Latviešu Македонски മലയാളം Монгол मराठी Bahasa Melayu မြန်မာ Norsk bokmål Nederlands ਪੰਜਾਬੀ Polski Português (Brasil) Português (Portugal) Română Русский Slovenčina Slovenščina Soomaali Shqip Srpski Svenska Kiswahili தமிழ் తెలుగు ไทย Tagalog Türkçe Українська اردو Tiếng Việt 简体中文 繁體中文(香港) 繁體中文(台灣)