सिस्टम क्षमता द्वारा संचालन और चेतावनी → प्रबंधन

सिस्टम क्षमता अलर्ट

1) आपको इसकी आवश्यकता क्यों है

कैपेसिटिव अलर्ट घटना से बहुत पहले तकनीकी सीमा तक पहुंचने की चेतावनी देते हैं: "हम छत के 80% हैं - यह पैमाने पर समय है। "किराने के व्यवसायों के लिए, यह सीधे पैसे के बारे में है: मिस्ड दांव/डिपॉजिट, सेशन ड्रॉप, लाइव गेम देरी और प्रदाता विफलताएं = खोए हुए राजस्व, प्रतिष्ठा, जुर्माना और किकबैक।

• मुख्य रूप से पीक लोड (घटनाएं, टूर्नामेंट, धाराएं, बड़े अभियान) का सामना करना पड़ ता है।
• समय पर ऑटो-स्केलिंग चालू करें और क्षमता बढ़ाएं।
• एसएलओ/पैसा जोखिम में होने पर शोर कम करें और "व्यापार पर" जागें।
• इंजीनियरों को रनबुक के माध्यम से सटीक सिफारिशें दें।

2) बुनियादी अवधारणाएं

क्षमता: अधिकतम स्थिर थ्रूपुट (आरपीएस/टीपीएस, कनेक्शन, आईओपीएस, थ्रूपुट)।

हेडरूम: वर्तमान लोड और सीमा के बीच मार्जिन।

एसएलओ/एसएलए: उपलब्धता/प्रतिक्रिया समय के लक्ष्य स्तर; अलर्ट "एसएलओ-जागरूक" होना चाहिए।

बर्न-रेट: त्रुटियों/विलंबता के एसएलओ बजट को "जलने" की गति।

उच्च/कम वाटरमार्क: सक्रियताओं और ऑटो-रिकवरी के लिए ऊपरी/निचले स्तर।

3) सिग्नल वास्तुकला और डेटा स्रोत

टेलीमेट्री: मेट्रिक्स (प्रोमेथियस/ओटीएल), लॉग (ईएलके/क्लिकहाउस), निशान (ओटेल/जैगर)।

परत दृष्टिकोण: परतों द्वारा अलर्ट (एज → एपीआई → व्यावसायिक सेवाएं → कतारें/धाराएं → डेटाबेस/कैश → फ़ाइल/ऑब्जेक्ट स्टोर्स → बाहरी प्रदाता)।

संदर्भ: झंडे, रिलीज, विपणन अभियान, टूर्नामेंट, भू-संरेखण की सुविधा।

हादसा टायर: Alertmanager/PagerDuty/Opsgenie/Slack; रनबुक और एस्केलेशन मैट्रिक्स के लिए बाध्यकारी।

4) परत द्वारा कुंजी मैट्रिक्स (क्या निगरानी करना है और क्यों)

किनारा/L7

आरपीएस, 95-/99-प्रतिशत विलंबता, त्रुटि दर (5xx/4xx), खुले कनेक्शन।

रेट-लिमिट/कोटा, ड्रॉप्स на सीडीएन/डब्ल्यूएएफ/फ़ायरवॉल।

API- шлюз/बैकेंड-फॉर-फ्रंटेंड

कार्यकर्ता/कार्य पूल द्वारा संतृप्ति, अनुरोध कतार, नीचे की ओर समय।

गिरावट अंश (फॉलबैक, सर्किट-ब्रेकर्स)।

कतार/स्ट्रीमिंग (काफ्का/खरगोश/पल्सर)

लैग/उपभोक्ता देरी, बैकलॉग वृद्धि दर, थ्रूपुट (msg/s, MB/s)।

विभाजन तिरछा, पुनर्संतुलन मंथन, आईएसआर (काफ्का के लिए), रिट्रे/दादा-बाद में।

अतुल्यकालिक श्रमिक

कार्य समय समाप्ति, कतार लंबाई, समाप्त एसएलए कार्यों का प्रतिशत।

पूल में संतृप्ति सीपीयू/मेमोरी/एफडी।

कैश (Redis/Memcacked)

हिट अनुपात, विलंबता, निष्कासन, प्रयुक्त मेमोरी, कनेक्टेड क्लाइंट/ऑप्स/एस।

समूह: स्लॉट/प्रतिकृतियाँ, विफल घटनाएँ।

(PostgreSQL/MySQL/ClickHouse)

सक्रिय कनेक्शन बनाम अधिकतम, लॉक वेट, प्रतिकृति लैग, बफर/कैश हिट।

IOPS, पढ़ें/लिखें विलंबता, चेकपॉइंट/फ्लश, ब्लोट/विखंडन।

वस्तु/फ़ाइल भंडारण

पुट/GET विलंबता, 4xx/5xx, egress, अनुरोध/सेकंड, प्रदाता सीमा।

बाहरी प्रदाता (भुगतान/एलसीसी/खेल प्रदाता)

टीपीएस सीमा, क्यूपीएस विंडो, त्रुटि दर/टाइमआउट, रिट्रे कतार, "प्रति कॉल लागत"।

बुनियादी ढांचा

नोड्स/पॉड्स/एएसजी पर सीपीयू/मेमोरी/एफडी/आईओपीएस/नेटवर्क संतृप्ति।

HPA/VPA इवेंट्स, लंबित पॉड्स, कंटेनर OOM/थ्रॉटलिंग।

5) कैपेसिटिव अलर्ट के प्रकार

1. स्थिर थ्रेसहोल्ड

सरल और सीधा: 'db _ connections> 80% max'. बीकन सिग्नल के रूप में अच्छा है।

2. अनुकूली (गतिशील) थ्रेसहोल्ड

मौसमी और प्रवृत्ति (रोलिंग विंडो, एसटीएल अपघटन) के आधार पर। "सप्ताह के इस घंटे/दिन के लिए असामान्य रूप से उच्च" को पकड़ ने की अनुमति दें।

3. एसएलओ-उन्मुख (बर्न-रेट)

जब त्रुटि-बजट खाने की दर एक्स घंटे के क्षितिज में एसएलओ को खतरे में डाल देगी, तो वे ट्रिगर हो जाते हैं।

4. पूर्वानुमानित (पूर्वानुमान-अलर्ट)

"वर्तमान प्रवृत्ति में 20 मिनट के बाद, कतार 90% तक पहुंच जाएगी।" छोटी खिड़कियों पर रैखिक/मजबूत/पैगंबर जैसी भविष्यवाणी का उपयोग किया जाता है।

5. मल्टी-सिग्नल

संयोजन के साथ ट्रिगर करें: 'कतार _ लैग ' + 'उपभोक्ता _ cpu 85%' + 'ऑटोस्कलिंग एट मैक्स' - "मैनुअल हस्तक्षेप की आवश्यकता है।"

6) थ्रेसहोल्ड नीतियां और शोर-विरोधी

• ऊपर: चेतावनी 70-75%, क्रेते 85-90%। नीचे: हिस्टेरिसिस 5-10 पीपी ताकि "दहलीज पर न देखा जाए।"

• 'for: 5m' for मानदंड, 'के लिए: 10-15m' for चेतावनी। नाइट-मोड: पेजिंग के बिना चैट करने के लिए गैर-महत्वपूर्ण मार्ग।

• सेवा/क्लस्टर/जियो द्वारा समूह ताकि घटना कार्ड का उत्पादन न हो।

• यदि केवाईसी प्रदाता बाहर है और एपीआई त्रुटियां एकीकरण स्वामी को पेज करने के कारण हैं, न कि सभी उपभोक्ताओं को।

• स्टॉक अवधि के दौरान, "अपेक्षित वृद्धि" के लिए शोर थ्रेसहोल्ड बढ़ाएं, लेकिन एसएलओ अलर्ट बरकरार रखें।

7) नियम उदाहरण (छद्म-प्रोमेथियस)

ALERT PostgresConnectionsHigh
IF (pg_stat_activity_active / pg_max_connections) > 0. 85
FOR 5m
LABELS {severity="critical", team="core-db"}
ANNOTATIONS {summary="Postgres connections >85%"}

ALERT StreamBacklogAtRisk
IF (kafka_consumer_lag > 5_000_000 AND rate(kafka_consumer_lag[5m]) > 50_000)
AND (hpa_desired_replicas == hpa_max_replicas)
FOR 10m
LABELS {severity="critical", team="streaming"}

ALERT ApiLatencySLOBurn
IF slo_latency_budget_burnrate{le="300ms"} > 4
FOR 15m
LABELS {severity="page", team="api"}
ANNOTATIONS {runbook="wiki://runbooks/api-latency"}

ALERT RedisEvictions
IF rate(redis_evicted_keys_total[5m]) > 0
AND (redis_used_memory / redis_maxmemory) > 0. 8
FOR 5m
LABELS {severity="warning", team="caching"}

ALERT PSPThroughputLimitNear
IF increase(psp_calls_total[10m]) > 0. 9 psp_rate_limit_window
FOR 5m
LABELS {severity="warning", team="payments", provider="PSP-X"}

8) एसएलओ दृष्टिकोण और व्यवसाय प्राथमिकता

सिग्नल से लेकर व्यावसायिक प्रभाव तक: क्षमता अलर्ट को एसएलओ (विशिष्ट गेम/जियो/जीजीआर मैट्रिक्स, जमा रूपांतरण) को जोखिम का संदर्भ देना चाहिए।

मल्टीलेवल: ऑन-कॉल सेवा के लिए चेतावनी; क्रेते - डोमेन स्वामी पृष्ठ; एसएलओ-ड्रॉप - प्रमुख घटना और टीम "सारांश" चैनल।

गिरावट की विशेषताएं: स्वचालित लोड में कमी (आंशिक रीड-ओनली, भारी सुविधाओं को काटना, जैकपॉट प्रसारण की आवृत्ति को कम करना, लाइव गेम में "भारी" एनिमेशन को बंद करना)।

9) ऑटो-स्केलिंग और "सही" ट्रिगर

HPA/VPA: न केवल CPU/मेमोरी द्वारा लक्ष्य, बल्कि बिजनेस मैट्रिक्स (RPS, कतार लैग, p99 विलंबता) द्वारा भी।

वार्म-अप समय: ठंडी शुरुआत और प्रदाता सीमा (एएसजी स्पिन-अप, कंटेनर बिल्डर, वार्म-अप कैश) को ध्यान में रखें।

रेलिंग: हिमस्खलन जैसी त्रुटियों में वृद्धि को रोकें; "स्कैलिम समस्या" के खिलाफ सुरक्षा।

क्षमता-प्लेबुक: कहां और कैसे एक शार्ड/पार्टी/प्रतिकृति जोड़ें, क्षेत्र द्वारा यातायात को पुनर्वितरित कैसे करें।

10) प्रक्रिया: डिजाइन से संचालन तक

1. सीमित मानचित्रण: प्रत्येक परत (अधिकतम शंकु, आईओपीएस, टीपीएस, कोटा प्रदाता) के लिए "सही" अड़ चन सीमा एकत्र करें।

2. भविष्यवक्ता मैट्रिक्स का चयन: जो संकेत पहले "एन मिनट में आराम" का संकेत देते हैं।

3. थ्रेशोल्ड डिजाइन: उच्च/कम + SLO-burn + यौगिक।

4. प्रत्येक क्रेट के लिए रनबुक: नैदानिक कदम ("क्या खोलना है", "क्या आदेश देता है", "जहां आगे बढ़ ना है"), कार्रवाई के लिए तीन विकल्प: तेज ट्रैवर्सल, स्केलिंग, गिरावट।

5. परीक्षण: लोड सिमुलेशन (अराजकता/खेल के दिन), अलर्ट की शुरुआत, शोर-रोधी जाँच।

6. समीक्षा और गोद लेना: सिग्नल मालिक = सेवा स्वामी। कोई मालिक नहीं - कोई पृष्ठ नहीं

7. पूर्वव्यापी और ट्यूनिंग: झूठी/चूक का साप्ताहिक विश्लेषण; मीट्रिक "MTTA (ack), MTTD, MTTR, शोर/सिग्नल अनुपात"।

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

CPU> 90% ⇒ घबराहट: विलंबता/कतारों के साथ सहसंबंध के बिना, यह सामान्य हो सकता है।

"सभी के लिए एक सीमा": विभिन्न क्षेत्र/समय क्षेत्र - विभिन्न यातायात प्रोफाइल।

रनबुक के बिना अलर्ट: कॉल पर स्पष्ट एक्शन नालियों के बिना पृष्ठ।

प्रदाताओं को अंधापन: बाहरी कोटा/सीमाएं अक्सर "ब्रेक" स्क्रिप्ट (पीएसपी, केवाईसी, एंटी-फ्रॉड, गेम प्रदाता) के लिए पहली होती हैं।

कोई हिस्टेरिसिस नहीं: 80 %/79% सीमा पर "आरी"।

12) आईगेमिंग/वित्तीय प्लेटफार्मों की विशेषताएं

अनुसूची चोटियाँ: प्राइम टाइम, टूर्नामेंट फाइनल, प्रमु लक्ष्य प्रतिकृतियों को बढ़ावा देना और पहले से कैश भरना।

लाइव स्ट्रीम और जैकपॉट: प्रसारण घटनाओं के फटने - दलालों/वेब साइटों पर सीमाएं।

भुगतान और केवाईसी: प्रदाता खिड़कियां, धोखाधड़ी विरोधी स्कोरिंग; अतिरिक्त मार्ग और "अनुग्रह-मोड" जमा रखें।

भू-संतुलन: स्थानीय प्रदाता विफलता - एक पड़ोसी क्षेत्र में यातायात को मोड़ ने के लिए जहां एक हेडरूम है।

जिम्मेदारी: दांव/जैकपॉट खोने का जोखिम - डोमेन टीम + बिजनेस अलर्ट के लिए तत्काल पृष्ठ।

13) डैशबोर्ड (न्यूनतम सेट)

क्षमता अवलोकन: परत द्वारा हेडरूम, शीर्ष 3 जोखिम भरे क्षेत्र, बर्न-रेट एसएलओ।

स्ट्रीम और कतारें: अंतराल, बैकलॉग वृद्धि, उपभोक्ता संतृप्ति, एचपीए राज्य।

DB & Cache: कनेक्शन, repl-lag, p95/p99 विलंबता, हिट अनुपात, निष्कासन।

प्रदाता: टीपीएस/विंडोज/कोटा, टाइमआउट/त्रुटियां, कॉल लागत।

रिलीज ़/फ़ीचर संदर्भ: घटता के बगल में रिलीज ़/फ़िचफ्लैग।

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

• "सच" सीमाओं और मालिकों की सूची।
• प्रिडिक्टर मैट्रिक्स मैप + इंटर-लेयर एसोसिएशन।
• स्थिर थ्रेसहोल्ड + हिस्टेरिसिस।
• महत्वपूर्ण रास्तों पर एसएलओ-बर्न-अलर्ट (जमा, शर्त, लाइव गेम लॉन्च)।
• कतार/धाराओं/कनेक्शन पर भविष्यवाणी अलर्ट।
• विंडो का दमन/रखरखाव; शोर विरोधी राजनीति।
• रनबुक 'और कमांड, रेखांकन, गिरावट फिल्टर के साथ।
• झूठी सकारात्मकता और ट्यूनिंग का साप्ताहिक विश्लेषण।
• विपणन अभियानों और घटना कैलेंडर के लिए खाता।

15) उदाहरण रनबुक पैटर्न (संक्षिप्त)

सिग्नल: 'StreemBacklogAtRisk'

उद्देश्य: अंतराल वृद्धि> 10 मिलियन और उपचार में देरी> 5 मिनट को रोकना।

1. गड्ढों में 'hpa _ वांछित/अधिकतम', गला/ऊम की जाँच करें।

2. 'रेट (अंतराल)' देखें, विभाजन (तिरछा)।

3. चेक ब्रोकर (आईएसआर, अंडर-प्रतिकृति, नेटवर्क)।

• + एन द्वारा उपभोक्ता-प्रतिकृतियों को बढ़ाएं, अधिकतम उड़ान बढ़ाएं।
• "महत्वपूर्ण विषयों" पर प्राथमिकता पूल सक्षम करें।
• अस्थायी रूप से द्वितीयक उपचार/संवर्धन की आवृत्ति को कम करना।
• यदि 'एएसजी एट मैक्स' - क्लाउड से अस्थायी उत्थान का अनुरोध करें; भारी कार्यों के समानांतर - सक्षम क्षरण में।
• रोलबैक: 'लैग <1 मिलियन' 15 मिनट के बाद सामान्य ट्रैफिक प्रोफाइल पर लौटें।
• वृद्धि: काफ्का क्लस्टर के मालिक, फिर एसआरई मंच।

16) केपीआई और सिग्नल क्वालिटी

कवरेज: कैपेसिटिव अलर्ट द्वारा बंद महत्वपूर्ण रास्तों का%।

शोर/संकेत: प्रति कॉल/सप्ताह 1 से अधिक गलत पृष्ठ नहीं।

MTTD/MTTR: SLO हमलों से पहले कैपेसिटिव घटनाओं का पता लगाया जाता है।

सक्रिय बचत: रोकी गई घटनाओं की संख्या (पोस्टमॉर्टम द्वारा)।

17) तेज शुरुआत (रूढ़िवादी चूक)

DB: कनेक्शन/IOPS/lat के 75% चेतावनी; क्रेते 85%, हिस्टेरिसिस 8-10 पीपी

कैश: 'हिट <0। 9 'और' निष्कासन> 0 '> 5 मिनट - चेतावनी;' प्रयुक्त _ mem> 85% '- क्रेते।

कतारें: 30 डी + 'hpa एट मैक्स' - क्रेते के लिए औसत का 3 'अंतराल।

API: 'p99> SLO1। 3 '10 मिनट - चेतावनी;' बर्न-रेट> 4 '15 मिनट - क्रेते।

प्रदाता: 'थ्रूपुट> 90% कोटा' - चेतावनी; 'टाइमआउट> 5%' - क्रेते।

18) एफएक्यू

प्रश्न: सिर्फ "सीपीयू> 80%" क्यों नहीं?

A: विलंबता/कतार के संदर्भ के बिना, यह शोर है। सीपीयू स्वयं जोखिम के बराबर नहीं है।

प्रश्न: क्या हमें अनुकूली थ्रेसहोल्ड की आवश्यकता है?

A: हाँ, दैनिक/साप्ताहिक मौसमी के लिए - झूठी सकारात्मकता को कम करें।

प्रश्न: विपणन/घटनाओं पर कैसे विचार करें?

A: अभियान कैलेंडर - रेखांकन + अस्थायी एंटी-शोर समायोजन पर एनोटेशन, लेकिन SLO अलर्ट को नहीं छूते हैं।