عملیات حادثه ربات و چت
1) هدف و ارزش
ربات حادثه یک رابط مدیریت حادثه به طور مستقیم از چت شرکت (Slack/Teams/Telegram) است: یک ورودی متن → اقدامات در ده ها تن از سیستم ها. آیا او:- MTTA/MTTR را با خودکار سازی روال کاهش می دهد.
- ایجاد یک حلقه واحد از حقایق (SoT) و ارتباطات ؛
- قابلیت اطمینان (ممیزی، جدول زمانی، به روز رسانی SLA) را فراهم می کند ؛
- بار بر روی تماس و «دفن» در کنسول را کاهش می دهد.
2) نقش ها و RACI در عملیات چت
فرمانده حادثه (IC) - مالک حادثه: باز/بسته شدن، اولویت، راه حل.
سرب Comms (CL) - متون و برنامه به روز رسانی (خارجی/داخلی).
فرصت های دامنه (پرداخت/بازی/هسته/Infra) - حقایق فنی و رفع.
Scribe - جدول زمانی، ورود به سیستم عمل.
ربات مدیر - حقوق ربات/سیاست/ادغام.
قاعده: یک حادثه دارای یک IC و یک CL است ؛ role reversal - با دستور صریح ربات.
3) سناریوهای پایان به پایان
1. شروع حادثه: alert → '/incident new p1 «Deposits EU down» → ربات یک کارت ایجاد می کند، var-room، اختصاص IC/CL، تایمر را برای اولین به روز رسانی تنظیم می کند.
2. Ведение: '/incident add-facts ', '/incident status set degraded', '/incident assign @payments -lead ', '/incident timer 20m'.
3. ارتباطات: '/incident publish status '(draft CL), '/incident partners notify', '/incident regulator draft '.
4. Действия: '/runbook psp-failover PSP1 → PSP2 ', '/feature toggle replay-center off 60m', '/traffic shift 30% eu → uk '.
5. بستن و پس از مرگ: «/حل حادثه »، جدول زمانی خودکار جمع آوری، «/postmortem تولید».
4) دستورات ربات (هسته)
ایجاد/طبقه بندی
'/incident new p {1 | 2 | 3 | 4} «
'/incident severity set p2 ', '/incident tag add payments, psp'
مالکیت و نقش ها
'/incident ic @user ', '/incident comms @user', '/incident assign @user [دامنه] '
تایمر و به روز رسانی SLO
'/incident next-update 15m ', '/incident remind' (bot pings CL), '/incident eta set 18: 30 '
حقایق و وضعیت
'/incident fact 'auth-success PSP1 -25% TR/EU', '/incident status {بررسی 'degraded' monitoring 'resolved}'
بسته های ارتباطی
'/حادثه پیش نویس عمومی 'partners' regulator '، '/حادثه انتشار عمومی'
یکپارچه سازی
'/runbook
بسته شدن/پس از مرگ
'/incident resolve [reason =...] ', '/postmortem generate', '/postmortem assign @owner '
5) ادغام (حداقل مورد نیاز)
نظارت: هشدار، SLI/SLO (نرخ سوختن)، لینک به داشبورد.
مدیر حادثه (ITSM): هماهنگ سازی وضعیت/دو طرفه.
صفحه وضعیت: پیش نویس و انتشار از طریق CL (سیاست دروازه).
ارائه دهندگان (PSP/KYC/Game Studios): دایرکتوری های تماس، نامه ها/کانال های سریع.
انتشار/ویژگی پرچم: قناری متوقف می شود/پولبک, لینک انتشار.
Runbooks/Auto-remediation: کاتالوگ اقدام ایمن با گارد محافظ.
CMDB/صاحبان: تخصیص خودکار دامنه منجر، تشدید.
ذخیره سازی جدول زمانی: WORM/غیر قابل تغییر برای حسابرسی/پس از مرگ.
6) معماری ربات
دروازه (آداپتور چت): رابط های Slack/Teams/Telegram.
تجزیه کننده فرمان + موتور سیاست: مجوز، اعتبار سنجی، SoD و تحمل.
ارکستر: سناریوهای حادثه، تایمر، یادآوری.
لایه ادغام: مشتریان به ITSM، نظارت، صفحه وضعیت، نسخه ها، کتاب های اجرا.
فروشگاه شواهد: رویدادها، حقایق، پخش پیام، پیوست ها (WORM).
Metrics & Audit: معیارهای کیفیت، سیاهههای مربوط به عمل، ردیابی فرمان.
7) سیاست ها، حقوق و امنیت
RBAC/ABAC: چه کسی می تواند ایجاد/بستن، تغییر شدت، انتشار در خارج.
SoD: Comms انتشار نیاز به نقش CL ؛ اقدامات پر خطر (مسیریابی PSP، صادرات PII) - کنترل دوگانه.
حقوق JIT: صدور موقت به رهبران دامنه در زمان حادثه.
امضا و رمزگذاری: وبهوک/درخواست به سیستم - HMAC/mTLS.
حفاظت از چربی انگشت: تایید دستورات خطرناک، خشک اجرا و TTL برای عمل.
بهداشت PII: ماسک در پیش نویس/سیاهههای مربوط ؛ مهار PII در کانال های باز.
8) جریان اتوماسیون (مثال)
هشدار P1 → ربات یک اتاق var («# inc-2025-11-01-001»)، پینگ در وظیفه (IC، CL، پرداخت/Infra) ایجاد می کند.
داشبورد/SLI را متصل می کند، یک بلیط را در ITSM باز می کند، یک قالب برای اولین به روز رسانی عمومی آماده می کند.
تنظیم تایمر: «به روز رسانی بعدی در 15 دقیقه»، یادآوری CL.
Предлагает runbooks: «تغییر مسیر PSP 30% → PSP2,» «تنزل پخش مرکز», «autoscale حل و فصل کارگران».
هنگام انتشار - نسخه متن را اصلاح می کند و آن را به صفحه وضعیت/شبکه اجتماعی (از طریق CL) منتشر می کند.
هنگامی که بسته شدن - جمع آوری جدول زمانی، معیارها، پیش نویس پس از مرگ، VIP/شریک پستی.
9) زمان بندی و قابلیت اثبات
هر رویداد ثبت می شود: 'T + mm: description, author/bot, command, result, links'.
ویرایش پیام ها (تفاوت)، اتصال به انتشار/پرچم ویژگی/کار برنامه ریزی شده پشتیبانی می شوند.
صادرات: PDF/CSV برای ممیزی و تنظیم کننده.
10) معیارها (KPI/KRI ChatOps)
MTTA (چت): هشدار به «/حادثه جدید ».
MTTS (راه اندازی): قبل از اتاق var آماده است و نقش ها اختصاص داده شده است.
پایبندی کادنس: پایبندی به فواصل به روز رسانی عمومی.
نرخ استفاده از Runbook: نسبت حوادث با فعالیت های خودکار.
نمره سازگاری: اختلاف بین کانال = 0 - هدف.
fatigue↓ پیجر: کاهش پیجرهای دستی با SLO مشابه/بهتر.
SLA پس از مرگ: نسبت مرگ و میر جمع آوری شده ≤ D + 5.
11) کاتالوگ قالب (قطعات)
ایجاد P1:
/incident new p1 "Deposits EU down" components=payments,deposits regions=EU
اولین به روز رسانی عمومی (از طریق CL):
/incident draft public
/incident publish public
مسیریابی PSP و تخریب ویژگی:
/runbook psp-failover PSP1→PSP2 30%
/feature toggle replay-center off 45m
پس از مرگ:
/postmortem generate
/postmortem assign @owner
12) جاسازی در فرآیندها
ارتباطات: پیوند به صفحات ارتباطات حادثه و وضعیت سیستم.
قابلیت مشاهده: لینک های سریع به SLO/SLI و مصنوعی ؛ پیوست خودکار نمودارها.
هشدار: ایجاد خودکار حادثه در هنگام P1/P2 ؛ یک جریان سیگنال.
رفع خودکار: یک دکمه runbooks با guardrails و rollbacks.
موتور گردش کار: وظایف انسانی (4 چشم)، تایمر تشدید، چک لیست.
13) نقشه راه پیاده سازی (4-8 هفته)
«ند». ۱-۲: تیمهای MVP: «/incident new »، نقشها (IC/CL)، اتاق var، تایمر بهروزرسانی، ارتباط با ITSM و نظارت.
«ند». 3-4: الگوهای پیام (عمومی/شرکا/تنظیم کننده ها)، صفحه وضعیت (chernovik → publikatsiya)، کاتالوگ 5-7 runbooks.
«ند». 5-6: سیاست به عنوان کد (RBAC/SoD/JIT)، کنترل دوگانه در معرض خطر، مجله WORM، داشبورد KPI ChatOps.
«ند». 7-8: تمرینات P1/P2 تبلت، ادغام با نسخه های منتشر شده/پرچم های ویژگی، جمع آوری خودکار پس از مرگ، محلی سازی.
14) ضد گلوله
«در سراسر ربات» بدون guardrails → اقدامات خطرناک تصادفی.
پست ها به صفحه وضعیت بدون CL/نقش بررسی حقوقی.
دستورات بدون سیاهههای مربوط/نسخه → غیر قابل اثبات.
فرم های پیچیده (زمینه های 20 +) در چت - افت سرعت ؛ دستورات کوتاه بهتر + لینک ها
هیچ تایمر به روز رسانی → «سکوت» در P1 وجود دارد.
عدم ادغام CMDB/مالک → هرج و مرج انتساب.
15) خط پایین
Incident-bot و ChatOps یک ربات با دستورات نیستند، بلکه یک پلت فرم عملیاتی هستند: شروع سریع یک حادثه، به روز رسانی نظم و انضباط، اقدامات خودکار با محدودیت های ایمن، قابلیت مشاهده و قابلیت اطمینان. چنین مدار قابل پیش بینی MTTR را کاهش می دهد، کیفیت ارتباطات را بهبود می بخشد و درآمد کسب و کار iGaming را در زمان های اوج محافظت می کند.