صفحات وضعیت سیستم
1) چرا ما به صفحات وضعیت نیاز داریم
صفحات وضعیت یک منبع عمومی و داخلی اطلاعات واقعی در مورد دسترسی و تخریب است. افراد:- کاهش بار پشتیبانی و هرج و مرج در ارتباطات ؛
- حفظ اعتماد کاربران و شرکا
- کمک به مسئولیت های قانونی ؛
- ایجاد یک ردیابی قابل اثبات برای تجزیه و تحلیل پس از حادثه.
2) مخاطبان و نیازهای آنها
بازیکنان: نشانه ساده «کار می کند/مشکلات وجود دارد»، ETA/ETR، متن قابل فهم بدون اصطلاحات مخصوص یک صنف.
VIP/Affiliates/Partners: تاثیر بر سپرده/نرخ/گزارش، پنجره زمان، توصیه ها (کمپین های تعلیق).
دستورات داخلی: تجزیه دقیق توسط جزء/منطقه، همبستگی با KRI/SLO.
تنظیم کننده ها و بانک ها/خریداران: واقعیت حادثه، تاثیر بر بازیکنان/معاملات، لینک به اطلاعیه های رسمی.
3) حجم صفحه نمایش (مدل جزء)
اجزای محصول: احراز هویت، سپرده، شرط، نتیجه گیری، مشخصات، پاداش، بازی های زنده، جریان.
زیرساخت: دروازه API، پایگاه داده، حافظه پنهان، کارگزار پیام، CDN/WAF، ارائه دهندگان پرداخت، KYC/AML.
مناطق/خوشه ها: GEO (EU/MEA/LATAM/APAC)، مناطق ابر، مراکز داده.
وضعیت: OK/تخریب/عدم دسترسی جزئی/فعالیت های در دسترس/برنامه ریزی شده.
4) معماری پلت فرم وضعیت
4. 1 عمومی در مقابل خصوصی
عمومی: ویترین استاتیک (SPA/SSG) + ذخیره سازی، CDN، API فقط خواندنی.
خصوصی (داخلی): معیارهای گسترده، KRI، پیوند به اتاق var.
4. 2 منابع داده
نظارت و SLO: معیارها (Prometheus/OTel)، چک های مصنوعی، پینگ ارائه دهندگان خارجی.
مدیریت حادثه: کارت حادثه، جدول زمانی، وضعیت حل و فصل.
Webhooks از PSP/KYC/ارائه دهندگان بازی: سیگنال های دسترسی/خطا.
به روز رسانی دستی Comms سرب از طریق یک کنسول امن (با ورود به سیستم حسابرسی).
4. 3 جریان به روز رسانی
Metrics/KRI → قوانین تشخیص → ایجاد/به روز رسانی یک حادثه → Comms Lead یک کارت/به روز رسانی → تکرار را به یک صفحه عمومی و کانال ها (ایمیل/Telegram/Twitter/چت داخلی) منتشر می کند.
5) SLO در مورد به روز رسانی و رفتار حادثه
P1: اولین به روز رسانی 10 دقیقه ≤، سپس هر 15-30 دقیقه تا تثبیت.
P2: اولین به روز رسانی 20 دقیقه ≤، سپس هر 45-60 دقیقه.
P3/P4: اولین به روز رسانی ≤ 60-1440 دقیقه، سپس با نقاط عطف.
قانون: اگر هیچ جدید وجود ندارد، ما هنوز «بدون تغییر» را منتشر می کنیم، زمان به روز رسانی بعدی را نشان می دهد.
6) کارهای برنامه ریزی شده
قالب اعلان با پنجره، مناطق ضربه، خطر گسترش، مراحل برگشت.
محلی سازی اجباری، مناطق زمانی محلی + UTC.
فعال سازی «یخ» در کانال های مجاور در طول پنجره.
7) قالب های بلوک در صفحه
کارت حادثه:- هدر، سطح (P1-P4)، اجزای/مناطق آسیب دیده.
- خوراک به روز رسانی (زمان، نویسنده/ربات، واقعیت کوتاه، به روز رسانی بعدی).
- تاثیر فعلی (درصد/متریک)، راه حل (در صورت وجود).
- ETA/ETR (در صورت موجود بودن)، مخاطبین پشتیبانی، پیوندها برای شرکا/تنظیم کننده ها.
کارت کار برنامه ریزی شده: پنجره، خطر، چک لیست قبل/بعد، معیارهای لغو.
تاریخچه: آرشیو جستجو بر اساس تاریخ/اجزای (≥ 12 ماه)، صادرات به PDF/CSV.
8) محلی سازی و در دسترس بودن
زبان ها: EN + بازارهای کلیدی (به عنوان مثال TR/ES/PT-BR/PL/RO).
زمان: محلی کاربر + UTC.
A11y: شاخص های کنتراست، متن Alt، نشانه گذاری معنایی.
نسخه موبایل اجباری است.
9) ایمنی و انطباق
حداقل جزئیات فنی لازم ؛ IP/توپولوژی داخلی را افشا نکنید.
تمام تغییرات از طریق Comms Lead/Legal تحت موضوعات PII/پرداخت انجام می شود.
کنسول انتشار برای SSO/MFA، حقوق JIT، گزارش حسابرسی (چه کسی/چه/چه زمانی/چرا).
ذخیره سازی تاریخچه WORM/تغییر ناپذیر ؛ حفاظت در برابر جایگزینی و حذف جرم.
10) ادغام با عملیات و داده ها
اتاق جنگ: ارتباط دو طرفه، جمع آوری خودکار حقایق از کارت حادثه.
SLO/SLI: در صفحه شما می توانید نمودارهای آپتایم جمع شده (30/90 روز) را نشان دهید.
PSP/KYC: نشان های وضعیت ارائه دهنده خارجی (روشن/خاموش/تخریب) با آخرین زمان پاسخ.
KPI های تجاری: سهم اختیاری سپرده ها/نرخ های موفق در ساعت گذشته (بدون افشای حجم محرمانه).
11) ضد اسپم و حفاظت از سر و صدا
تقسیم رویداد ؛ دسته بندی حوادث مرتبط
قبل از انتشار به روز رسانی خودکار (به عنوان مثال، 2-3 دقیقه) برای فیلتر کردن «flapping» نگه دارید.
سیاست اصلاح گذشته نگر (ویرایش تنها با توجه داشته باشید و تفاوت مرجع).
12) معیارهای کیفیت ارتباطات وضعیت
MTTA-Comms: قبل از اولین به روز رسانی عمومی.
پایبندی کادنس: پایبندی به فرکانس به روز رسانی.
سازگاری: تطبیق جمله بندی بین کانال ها (0 اختلاف - هدف).
Coverage: نسبت حوادث منعکس شده در صفحه وضعیت.
تماسهای تکراری: کاهش تماسهای مکرر برای پشتیبانی.
نمایش → انحراف: ارتباط از نمایش صفحه با سقوط بلیط های ورودی.
13) نقشه راه پیاده سازی (6-8 هفته)
«ند». 1–2:- کاتالوگ قطعات/مناطق، نمودار طراحی صفحه P1-P4 سطح ؛ SSG/SPA و نقش انتخاب CDN (IC/Comms سرب).
- ادغام با کارت های نظارت و حوادث ؛ انتشار کنسول (SSO/MFA، حسابرسی) قالب پیام و محلی سازی.
- چک های مصنوعی ارائه دهندگان خارجی، نشان های وضعیت PSP/KYC ؛ تاریخ و صادرات ؛ سیاست کار برنامه ریزی شده
- تمرینات (tabletop) با تایمر ؛ راه اندازی KPI ؛ قوانین بازنگری گذشته ؛ راهنمای عمومی «چگونه به خواندن وضعیت».
14) مصنوعات و الگوهای
Component matrix: component → regions → مالکان → SLO → کانالهای افزایش
قالب اولین به روز رسانی: چه اتفاقی می افتد، چه کسی تحت تاثیر قرار می گیرد، چه کاری انجام می دهیم، به روز رسانی بعدی.
بسته شدن الگو: زمان بهبودی، علت، پیشگیری، جبران خسارت (در صورت وجود).
سیاست ویرایش: چه کسی می تواند منتشر/ویرایش چگونه اصلاحات مشخص شده اند، SLAs محلی سازی.
Runbook «آثار برنامه ریزی شده»: چک لیست قبل/بعد، معیارهای «برو/بدون رفتن»، بسته ارتباطی.
15) سناریوهای ویژه
حوادث امنیتی/داده ها: انتشار تنها پس از توافق با قانونی/انطباق ؛ احتمالا یک جریان خصوصی جداگانه برای تنظیم کننده ها/بانک ها.
مشکلات خاص جغرافیایی: صفحه به طور خودکار GEO کاربر را تشخیص می دهد و بلوک های اولویت را نمایش می دهد.
چند مستاجر: فیلتر وضعیت فردی/زیر دامنه در هر نام تجاری/اپراتور ؛ زیرساخت های مشترک - نوار جداگانه.
16) ضد گلوله
سکوت> 30 دقیقه در P1.
شماره های مختلف/جمله بندی در کانال ها و در صفحه وضعیت.
جزئیات بیش از حد فنی بدون ترجمه به زبان کاربر.
تاریخچه حوادث را به جای فلش بک ها حذف کنید.
انتشارات دستی بدون گزارش حسابرسی و کنترل حقوق.
17) خط پایین
صفحه وضعیت فقط یک سایت با نقاط سبز و قرمز نیست. این یک پلت فرم ارتباطی مدیریت شده است که عمیقا با نظارت، فرآیند حادثه و وابستگی های خارجی یکپارچه شده است. با معماری صحیح و نظم و انضباط انتشار، صفحه وضعیت را کاهش می دهد عدم اطمینان، محافظت از شهرت و صرفه جویی در منابع پشتیبانی - به خصوص در زمان اوج در کسب و کار iGaming.