चेतावनी और असफलता प्रतिक्रिया

(धारा: प्रौद्योगिकी और बुनियादी ढांचा)

संक्षिप्त सारांश

मजबूत अलर्टिंग उपयोगकर्ता मूल्य के उल्लंघन का संकेत है, न कि केवल "लाल मीट्रिक"। "IGaming के लिए, SLO गेट्स (विलंबता, उपलब्धता, भुगतान रूपांतरण, टाइम-टू-वॉलेट), मल्टी-बर्न नियम, स्पष्ट ऑन-कॉल, एस्केलेशन, चैटोप्स और रनबुक भूमिकाएं महत्वपूर्ण हैं। लक्ष्य जल्दी से विचलन को देखना है, उन लोगों को सूचित करना है जो सही कर सकते हैं, और अगली बार और भी तेजी से और सस्ता प्रतिक्रिया करने के लिए ज्ञान को ठीक कर सकते हैं।

1) मूल बातें: मेट्रिक्स से एक्शन तक

SLI → SLO → अलर्ट - मापा गुणवत्ता → लक्ष्य स्तर → "बजट" स्थिति पर है।

गंभीरता (SEV): SEV1 - महत्वपूर्ण (राजस्व/जोखिम में GGR), SEV2 - गंभीर, SEV3 - मध्यम, SEV4 - नाबालिग।

प्रभाव/आग्रह: कौन पीड़ित है (सभी/क्षेत्र/किरायेदार/चैनल) और कितना तत्काल (TTW↑, p99↑, त्रुट- rate↑)।

एक्शन क्षमता: प्रत्येक अलार्म के लिए - एक विशिष्ट क्रिया (रनबुक + मालिक)।

2) सिग्नल टैक्सोनॉमी

ТехSLO: p95/p99 लेटेंसी एपीआई, त्रुटि-दर, संतृप्ति (सीपीयू/आईओ/जीपीयू), कतार अंतराल।

BusinesSLO: भुगतान रूपांतरण (attempt→success), टाइम-टू-वॉलेट (TTW), सट्टेबाजी की सफलता, गेम लॉन्च।

भुगतान मार्ग: पीएसपी-विशिष्ट मैट्रिक्स (टाइमआउट/गिरावट स्पाइक्स)।

फ्रंट/मोबाइल: RUM मेट्रिक्स (LCP/INP), क्रैश-रेट, परिदृश्य सिंथेटिक्स (लॉगिन/डिपॉजिट/रेट/आउटपुट)।

3) अलर्टिंग नीति: एसएलओ और बर्न-रेट

SLI/SLO उदाहरण

भुगतान-आपी उपलब्धता ≥ 99। 9 %/30d p95 '/जमा '≤ 250 ms/30d

'payments_attempt→success ≥ बेसलाइन − 0 का रूपांतरण। 3 %/24h

TTW p95 ≤ 3 मिनट/24h

मल्टी-विंडो/मल्टी-बर्न (идея PromQL)

फास्ट बर्न: एसएलओ उल्लंघन सामान्य से 5-10 × तेज (5-15 मिनट में अलर्ट पेज)।

धीमी गति से जलना: धीमा बजट बर्नआउट (टिकट + 1-3 घंटे में विश्लेषण)।

yaml
API success proxy metric (recording rule in advance)
record: job:http:success_ratio expr:
sum(rate(http_requests_total{status=~"2..    3.."}[5m]))
/ sum(rate(http_requests_total[5m]))
Fast burn (99. 9% SLO)
alert: PaymentsSLOFastBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 14 for: 10m labels: { severity: "page", service: "payments-api" }
annotations:
summary: "SLO fast burn (payments-api)"
runbook: "https://runbooks/payments/slo"
Slow burn alert: PaymentsSLOSlowBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 6 for: 1h labels: { severity: "ticket", service: "payments-api" }

4) शोर में कमी और सिग्नल की गुणवत्ता

सत्य का सही स्रोत: समुच्चय (रिकॉर्डिंग नियम) द्वारा परिवर्तित करना, न कि भारी "कच्चे" भावों द्वारा।

Deduplication - Alertmanager समूह 'सेवा/क्षेत्र/गंभीरता' द्वारा।

पदानुक्रम: व्यवसाय/एसएलआई के लिए पहला अलर्ट, नीचे - निदान के रूप में तकनीकी मैट्रिक्स।

दमन: नियोजित-रखरखाव/रिलीज़ (एनोटेशन) के दौरान, ऊपर की घटनाओं के दौरान।

कार्डिनैलिटी: 'user _ id/session _ id' का प्रयोग अलर्ट लेबल में न करें.

टेस्ट अलर्ट: नियमित "प्रशिक्षण" ट्रिगर (चैनल, भूमिकाएं, रनबुक लिंक की जाँच)।

5) अलर्टमैनेजर रूटिंग और एस्केलेशन

yaml route:
group_by: [service, region]
group_wait: 30s group_interval: 5m repeat_interval: 2h receiver: sre-slack routes:
- matchers: [ severity="page" ]
receiver: pagerduty-sre continue: true
- matchers: [ service="payments-api" ]
receiver: payments-slack

receivers:
- name: pagerduty-sre pagerduty_configs:
- routing_key: <PD_KEY>
severity: "critical"
- name: sre-slack slack_configs:
- channel: "#alerts-sre"
send_resolved: true title: "{{.CommonLabels. service }} {{.CommonLabels. severity }}"
text: "Runbook: {{.CommonAnnotations. runbook }}"

inhibit_rules:
- source_matchers: [ severity="page" ]
target_matchers: [ severity="ticket" ]
equal: [ "service" ]

विचार: SEV = पृष्ठ → PagerDuty/SMS; बाकी स्लैक/टिकट है। निषेध ऊपर सक्रिय एसईवी के साथ निचले स्तरों के "प्रचार" को दबाता है।

6) ग्राफाना अलर्टिंग (अतिरिक्त परत के रूप में)

डैशबोर्ड पर केंद्रीकृत अलर्ट नियम (प्रोमेथियस/लोकी/क्लाउड)।

संपर्क बिंदु: PagerDuty/Slack/Email, अधिसूचना नीतियाँ प्रति फ़ोल्डर।

मौन: नियोजित कार्य, प्रवास, रिलीज।

टिकट में पैनल के ऑटो-स्क्रीनशॉट के साथ स्नैपशॉट।

7) ऑन-कॉल और लाइव प्रक्रियाएं

रोटेशन: प्रथम पंक्ति (एसआरई/प्लेटफ़ॉर्म), द्वितीय पंक्ति (सेवा स्वामी), तीसरा (डीबी/भुगतान/सेक)।

SLA प्रतिक्रियाएं: मान्यता ≤ 5 मिनट (SEV1), निदान ≤ 15 मिनट, प्रत्येक 15-30 मिनट में संचार।

ड्यूटी चैनल: '# घटना-वाररूम', '# स्थिति-अपडेट' (केवल तथ्य)।

रनबुक: प्रत्येक अलर्ट + चैटोप्स त्वरित कमांड ('/रोलबैक ', '/फ्रीज', '/स्केल ') में लिंक।

प्रशिक्षण अलार्म: मासिक (लोगों, चैनलों, रनबुक प्रासंगिकता की जाँच)।

8) घटनाएं: जीवन चक्र

1. डिटेक्शन (अलर्ट/रिपोर्ट/सिंथेटिक्स) → ऑन-कॉल स्वीकार करें।

2. ट्राइएज: एसईवी/प्रभावित/परिकल्पना, खुले युद्ध-कक्ष का निर्धारण करें।

3. स्थिरीकरण: रोल/रोलबैक/स्केलिंग/फिचफ्लैग।

4. संचार: स्थिति टेम्पलेट (नीचे देखें), ईटीए/अगले चरण।

5. समापन: एसएलओ वसूली की पुष्टि।

6. पोस्ट-इंसीडेंट रिव्यू (आरसीए): 24-72 घंटे के बाद, कोई शुल्क नहीं, एक्शन आइटम।

• क्या टूटा/प्रभावित है (क्षेत्र/किरायेदार/चैनल)
• जब प्रारंभ/एसईवी
• अस्थायी उपाय (शमन)
• एन मिनट में अगला स्थिति अद्यतन
• संपर्क (हादसा प्रबंधक)

9) iGaming की बारीकियाँ: "दर्द" क्षेत्र और अलर्ट

भुगतान/TTW: PSP टाइमआउट का हिस्सा, कोड विफलताओं में वृद्धि, TTW p95> 3m।

टूर्नामेंट की चोटियाँ: p99 एपीआई/गेम प्रारंभ समय/कतार अंतराल; सीमा/ऑटो-स्केल को बढ़ावा देना।

निधियों के निष्कर्ष: बैकहो/मैनुअल चेक का एसएलए, देश द्वारा सीमा।

खेल प्रदाता: स्टूडियो द्वारा उपलब्धता, सत्र आरंभकरण समय, लॉन्च ड्रॉप।

आरजी/अनुपालन: लंबे सत्रों/" डोगन" के फटने, थ्रेसहोल्ड से अधिक - एक पृष्ठ नहीं, बल्कि आरजी टीम के लिए एक टिकट + सूचना।

10) नियम उदाहरण (वैकल्पिक)

उच्च विलंबता p95 (एपीआई)

promql alert: HighLatencyP95 expr: histogram_quantile(0. 95,
sum by (le, service) (rate(http_request_duration_seconds_bucket{service="api"}[5m]))) > 0. 25 for: 10m labels: { severity: "page", service: "api" }
annotations:
summary: "p95 latency > 250ms"
runbook: "https://runbooks/api/latency"

लीड कतार "ऑन"

promql alert: WithdrawalsQueueLag expr: max_over_time(queue_lag_seconds{queue="withdrawals"}[10m]) > 300 for: 10m labels: { severity: "page", service: "payments-worker" }
annotations:
summary: "Withdrawals lag >5m"
runbook: "https://runbooks/payments/queue"

भुगतान रूपांतरण डूबा

promql alert: PaymentConversionDrop expr:
(sum(rate(payments_success_total[15m])) / sum(rate(payments_attempt_total[15m])))
< (payment_conv_baseline - 0. 003)
for: 20m labels: { severity: "page", domain: "payments" }
annotations:
summary: "Payment conversion below baseline -0. 3%"
runbook: "https://runbooks/payments/conversion"

11) चाटोप्स एंड ऑटोमेशन

एक्शन बटन के साथ ऑटो-पोस्टिंग अलर्ट: कैनरी, रोलबैक, स्केल + एन।

कमांड संक्षिप्त विवरण: '/घटना प्रारंभ ', '/स्थिति अद्यतन', '/call <स्वामी> ', '/grafana '

बॉट्स संदर्भ को कसते हैं: नवीनतम deploi, निर्भरता ग्राफ, उदाहरण, संबद्ध टिकट।

12) पोस्ट-इंसीडेंट वर्क (आरसीए)

फैक्टबॉक्स: टाइमलाइन, क्या देखा/कोशिश की, क्या काम किया।

मूल कारण: तकनीकी और संगठनात्मक कारण।

डिटेक्शन और डिफेंस: कौन से संकेत मदद/असफल।

एक्शन आइटम: विशिष्ट कार्य (SLO/अलर्ट/कोड/लिमिट/परीक्षण/रनबुक)।

नियत तारीखें और मालिक: शर्तें और जिम्मेदारियां; 2-4 सप्ताह में अनुवर्ती सत्र।

13) कार्यान्वयन चेकलिस्ट

1. प्रमुख धाराओं (API/भुगतान/खेल/TTW) के लिए SLI/SLO को परिभाषित करें।

2. रिकॉर्डिंग नियम और मल्टी-बर्न अलर्ट + अलर्टमैनेजर रूटिंग सेट करें।

3. रोटेशन, रिएक्शन एसएलओ और एस्केलेशन के साथ ऑन-कॉल दर्ज करें।

4. रनबुक और चैटोप्स कमांड के लिए लिंक अलर्ट।

5. दमन/शांत विंडो, रिलीज/कार्य एनोटेशन कॉन्फ़िगर करें।

6. सीखने के अलार्म और गेम-डे परिदृश्य (PSP ड्रॉप, p99 वृद्धि, कतार अंतराल वृद्धि) बनाएं।

7. माप चेतावनी गुणवत्ता: MTTA/MTTR,% शोर/गलत, SLO द्वारा कवरेज।

8. नियमित आरसीए और थ्रेसहोल्ड/प्रक्रियाओं का संशोधन।

9. व्यवसाय/समर्थन संचार स्थिति (टेम्पलेट्स) भरें।

10. कोड के रूप में सब कुछ दस्तावेज़ करें: नियम, मार्ग, रनबुक लिंक।

14) एंटी-पैटर्न

"हर मीट्रिक →" अलर्ट-फेटिग द्वारा सचेत, अनदेखा करें।

कोई एसएलओ नहीं - यह स्पष्ट नहीं है कि "सामान्य" क्या है और "आग पर" क्या है।

कोई दमन/अवरोध नहीं - हिमस्खलन डुप्लिकेट।

मामूली घटनाओं के लिए रात में पृष्ठ (एसईवी प्रभाव के लिए तुलनीय नहीं है)।

रनबुक/मालिक के बिना अलर्ट।

चैटोप्स/ऑडिटिंग के बिना "मैनुअल" कार्रवाई।

कोई आरसीए/एक्शन आइटम नहीं → घटनाओं को दोहराएं।

सारांश

सतर्कता और प्रतिक्रिया एक प्रक्रिया है, नियमों का एक सेट नहीं। मल्टी-बर्न अलर्ट के साथ लिंक एसएलओ, एक स्पष्ट ऑन-कॉल एस्केलेशन का निर्माण करें, चैटोप्स और लाइव रनबुक जोड़ें, नियमित रूप से आरसीए और प्रशिक्षण सत्र आयोजित करें। फिर घटनाएं लगातार कम, छोटी और सस्ती होंगी, और आईगेमिंग के गर्म घंटों में भी रिलीज अधिक अनुमानित होगी।