صفحات حالة النظام

1) لماذا نحتاج إلى صفحات الحالة

• وتخفيف عبء الدعم والفوضى في الاتصالات ؛
• الاحتفاظ بثقة المستخدمين والشركاء
• والمساعدة في المسؤوليات التنظيمية ؛
• إنشاء أثر يمكن إثباته لتحليل ما بعد الحادث.

2) الجمهور واحتياجاتهم

اللاعبون: إشارة بسيطة إلى «العمل/هناك مشاكل»، ETA/ETR، نص مفهوم بدون مصطلحات.
VIP/المنتسبون/الشركاء: التأثير على الودائع/الأسعار/الإبلاغ، النوافذ الزمنية، التوصيات (تعليق الحملات).
الأوامر الداخلية: توزيع مفصل حسب المكون/المنطقة، والارتباط مع KRI/SLO.
المنظمون والبنوك/المشترون: حقيقة الحادث، والتأثير على اللاعبين/المعاملات، والروابط بالإخطارات الرسمية.

3) حجم العرض (نموذج المكون)

مكونات المنتج: المصادقة، الودائع، الرهانات، الاستنتاجات، الملف الشخصي، المكافآت، الألعاب الحية، البث.
البنية التحتية: بوابة API، قاعدة بيانات، ذاكرة التخزين المؤقت، وسيط الرسائل، CDN/WAF، مزودي الدفع، KYC/AML.
المناطق/المجموعات: توقعات البيئة العالمية (EU/MEA/LATAM/APAC)، المناطق السحابية، مراكز البيانات.
الحالة: موافق/تدهور/عدم توافر جزئي/أنشطة غير متاحة/مخطط لها.

4) بنية منصة الحالة

4. 1 عام مقابل خاص

الجمهور: عرض ثابت (SPA/SSG) + التخزين المؤقت، CDN، واجهة برمجة التطبيقات للقراءة فقط.
خاص (داخلي): مقاييس ممتدة، KRI، روابط إلى غرفة var.

4. 2 مصادر البيانات

الرصد و SLO: المقاييس (Prometheus/OTel)، الفحوصات الاصطناعية، أصوات مقدمي الخدمات الخارجيين.
إدارة الحوادث: بطاقة الحادث، الجدول الزمني، حالة الحل.
خطافات الويب من PSP/KYC/مزودي الألعاب: إمكانية الوصول/إشارات الخطأ.
يقوم يدويًا بتحديث Comms Lead من خلال وحدة تحكم آمنة (مع سجل تدقيق).

4. 3 تحديث التدفق

المقاييس/KRI → قواعد الكشف → إنشاء/تحديث حادث → تنشر Comms Lead بطاقة/تحديثات → تكرار إلى صفحة عامة وقنوات (البريد الإلكتروني/Telegram/Twitter/الدردشات الداخلية).

5) SLO على التحديثات وسلوك الحوادث

P1: التحديث الأول ≤ 10 دقائق، ثم كل 15-30 دقيقة حتى الاستقرار.
P2: التحديث الأول ≤ 20 دقيقة، ثم كل 45-60 دقيقة.
P3/P4: التحديث الأول ≤ 60-1440 دقيقة، ثم بالمعالم.
القاعدة: إذا لم يكن هناك جديد، ما زلنا ننشر «دون تغيير»، تشير إلى وقت التحديث التالي.

6) الأعمال المخطط لها

نموذج الإعلان مع النافذة، مناطق التأثير، مخاطر التمديد، خطوات التراجع.
التوطين الإلزامي، المناطق الزمنية المحلية + التوقيت العالمي المنسق.
تفعيل «التجميد» في القنوات المجاورة أثناء النافذة.

7) قوالب الكتلة في الصفحة

• الرأس، المستوى (ف-1-ف-4)، المكونات/المناطق المتأثرة.
• موجز التحديثات (الوقت، المؤلف/الروبوت، الحقيقة القصيرة، التحديث التالي).
• التأثير الحالي (بالمائة/المتري)، حل بديل (إن وجد).
• ETA/ETR (عندما تكون متاحة)، اتصالات الدعم، وصلات للشركاء/المنظمين.

بطاقة العمل المخطط لها: النافذة، المخاطر، قائمة التحقق قبل/بعد، معايير الإلغاء.

التاريخ: أرشيف قابل للبحث حسب التاريخ/المكونات (≥ 12 شهرا)، والتصدير إلى PDF/CSV.

8) التوطين والتوافر

اللغات: EN + الأسواق الرئيسية (على سبيل المثال TR/ES/PT-BR/PL/RO).
الوقت: موقع المستخدم + UTC.
A11y: مؤشرات التباين، النصوص البديلة، الترميز الدلالي.
نسخة الهاتف المحمول إلزامية.

9) السلامة والامتثال

الحد الأدنى من التفاصيل التقنية اللازمة ؛ لا تكشف IP/الطوبولوجيا الداخلية.
تمر جميع التغييرات عبر Comms Lead/Legal ضمن مواضيع PII/الدفع.
وحدة النشر لـ SSO/MFA، حقوق JIT، سجل المراجعة (من/ماذا/متى/لماذا).
وورم/تخزين التاريخ غير القابل للتغيير ؛ والحماية من الاستبدال والحذف الشامل.

10) التكامل مع العمليات والبيانات

غرفة الحرب: اتصال ثنائي الاتجاه، جمع الحقائق تلقائيًا من بطاقة الحادث.
SLO/SLI: في الصفحة يمكنك عرض الرسوم البيانية المجمعة (30/90 يومًا).
PSP/KYC: شارات حالة المزود الخارجي (تشغيل/إيقاف/تدهور) مع آخر وقت استجابة.
مؤشرات أداء الأعمال: حصة اختيارية من الودائع/الأسعار الناجحة في الساعة الأخيرة (دون الكشف عن أحجام سرية).

11) Antispam وحماية الضوضاء

تفريغ الأحداث ؛ تجميع الحوادث ذات الصلة.
انتظر قبل نشر التحديثات التلقائية (على سبيل المثال، 2-3 دقائق) لتصفية «الخفقان».
سياسة الإصلاح بأثر رجعي (تحرير فقط مع ملاحظة ومرجع diff).

12) مقاييس جودة الاتصالات المتعلقة بالحالة

MTTA-Comms: قبل التحديث العام الأول.
الالتزام بالإيقاع: الالتزام بتواتر التحديثات.
الاتساق: مطابقة الصياغة بين القنوات (0 تناقضات - هدف).
التغطية: نسبة الحوادث الواردة في صفحة الحالة.
تكرار الاتصالات: تقليل الدعوات المتكررة للدعم.
View→Deflect: ارتباط مشاهدات الصفحات بسقوط التذاكر الواردة.

13) خارطة طريق التنفيذ (6-8 أسابيع)

• فهرس المكونات/المناطق، رسم بياني لتصميم صفحات المستويات P1-P4 ؛ أدوار اختيار SSG/SPA و CDN (IC/Comms Lead).

• وإدماج بطاقات الرصد والحوادث ؛ وحدة النشر (SSO/MFA، التدقيق) نماذج الرسائل والتوطين.

• الفحوصات الاصطناعية لمقدمي الخدمات الخارجيين، وشارات حالة PSP/KYC ؛ والتاريخ والتصدير ؛ سياسة العمل المقررة.

• وتمارين (الطاولة) بأجهزة توقيت ؛ بدء تشغيل المبادرة ؛ وقواعد المراجعة بأثر رجعي ؛ دليل عام «كيفية قراءة الحالة».

14) القطع الأثرية والأنماط

مصفوفة المكونات: المكونات → المناطق → المالكة → قنوات التصعيد → للمكاتب الفضائية.
نموذج التحديث الأول: ما يحدث، من يتأثر، ما نقوم به، التحديث التالي.
النموذج الختامي: وقت التعافي، والسبب، والوقاية، والتعويض (إن وجد).
سياسة التحرير: من يمكنه نشر/تحرير كيفية وضع العلامات على التصحيحات، وتوطين اتفاقيات SLAs.
Runbook "Planned works': قوائم مرجعية قبل/بعد، معايير" go/no-go "، حزمة اتصالات.

15) سيناريوهات خاصة

الحوادث الأمنية/حوادث البيانات: النشر فقط بعد الاتفاق مع القانون/الامتثال ؛ ربما تدفق خاص منفصل للمنظمين/المصارف.
مشاكل جغرافية محددة: تكتشف الصفحة تلقائيًا توقعات البيئة العالمية للمستخدم وتعرض كتل الأولوية.
متعدد المستأجرين: مرشحات/مناطق فرعية فردية لكل علامة تجارية/مشغل ؛ البنية التحتية المشتركة - شريط منفصل.

16) أنتيباترن

الصمت> 30 دقيقة في P1.
أرقام/صياغة مختلفة في القنوات وعلى صفحة الحالة.
تفاصيل تقنية للغاية دون ترجمة إلى لغة المستخدم.
احذف تاريخ الحادث بدلاً من ذكريات الماضي.
منشورات يدوية بدون سجل مراجعة ومراقبة للحقوق.

17) خلاصة القول

صفحة الحالة ليست مجرد موقع بنقاط خضراء وحمراء. إنه منصة اتصالات مُدارة مدمجة بعمق مع الرصد وعملية الحوادث والاعتمادات الخارجية. مع الهندسة المعمارية الصحيحة وانضباط النشر، تقلل صفحة الحالة من عدم اليقين وتحمي السمعة وتوفر موارد الدعم - خاصة في أوقات الذروة في أعمال iGaming.