80% उपयोग से आगे विलंबता क्यों विस्फोटक होती है

क्षमता नियोजन में सबसे महत्वपूर्ण वक्र

x-अक्ष पर उपयोग (0% से 100% तक) और y-अक्ष पर औसत विलंबता को प्लॉट करें। जो आकार उभरता है वह संचालन में सबसे महत्वपूर्ण वक्रों में से एक है: यह समझाता है कि टीमें उपयोग को 100% से कम क्यों लक्षित करती हैं, आरक्षित हेडरूम क्यों बर्बादी नहीं है, और 'कुशलतापूर्वक' उच्च उपयोग पर चलने वाले सिस्टम बिना चेतावनी के क्यों गिरते हैं।

M/M/1 queueing curve: Poisson arrivals (यादृच्छिक) और exponential service times (यादृच्छिक) वाले सिस्टम के लिए, औसत प्रतीक्षा समय निम्नानुसार होता है:

W_q = ρ / (μ(1-ρ))

जहां ρ (rho) उपयोग (0 से 1) है और μ सेवा दर है। हर (1-ρ) मुख्य बिंदु है: जैसे-जैसे ρ 1 के करीब पहुंचता है, हर 0 के करीब पहुंचता है, और प्रतीक्षा समय अनंत तक पहुंचता है।

संख्यात्मक उदाहरण (M/M/1 के लिए ρ के विरुद्ध विलंबता गुणक):

- ρ = 0.5: विलंबता अनुपात 1.0 (आधारभूत)

- ρ = 0.7: विलंबता अनुपात ~2.3

- ρ = 0.8: विलंबता अनुपात ~4.0

- ρ = 0.9: विलंबता अनुपात ~9.0

- ρ = 0.95: विलंबता अनुपात ~19.0

- ρ = 0.99: विलंबता अनुपात ~99.0

कोहनी लगभग 70-80% उपयोग पर बैठी है। कोहनी के नीचे, भार जोड़ने से विलंबता धीरे-धीरे बढ़ती है। कोहनी के ऊपर, विलंबता गैर-रैखिक रूप से विस्फोटक होती है। यह है कि canonical SRE नियम क्यों है: स्थिर-अवस्था उपयोग को 80% से नीचे लक्षित करें, कभी भी 90% से ऊपर sustained न चलाएं।

पारंपरिक ops टीमें इसको क्यों कम आंकती हैं: 60% CPU पर एक सर्वर 'व्यस्त दिखता है' लेकिन आरामदायक विलंबता हेडरूम है। 90% CPU पर एक सर्वर 'उत्पादक दिखता है' लेकिन एक कार्यभार में केवल एक टक्कर दूर विलंबता आपदा से है। ज्यामितीय सत्य: वक्र की ढलान वास्तविक खतरा है, इसका वर्तमान y-मान नहीं।

वक्र को पढ़ना

एक टीम 85% CPU उपयोग steady state पर एक सेवा चलाती है। वर्तमान p99 विलंबता 200 मिलीसेकंड है। वे एक अन्य सेवा से कार्यभार को consolidate करने के लिए 30% अधिक ट्रैफ़िक जोड़ने पर विचार कर रहे हैं जिसे हटाया जा रहा है।

ढलान, Intercept, & Forecast Cone

एक ढलान से विकास को पढ़ना

मांग की भविष्यवाणी (कई मामलों में) ऐतिहासिक डेटा के माध्यम से सही रेखा खींचने के लिए कम हो जाती है। उस रेखा के ज्यामितीय गुण: ढलान, intercept, और uncertainty cone, संपूर्ण पूर्वानुमान को encode करते हैं।

Linear trend (y = mx + b): छोटी windows या genuinely linear processes के लिए उपयुक्त। ढलान m समय yunit के प्रति विकास दर है। Intercept b प्रारंभिक मान है। उपयोगी जब विकास स्थिर हो। आमतौर पर underestimate करता है जब प्रक्रिया actually compounding है।

Exponential trend (y = b × e^(mx)): compound विकास के लिए उपयुक्त: viral adoption, user-network effects, multiplicative seasonality। log-scale y-अक्ष पर, exponential विकास linear हो जाता है, जो ढलान अनुमान को आसान बनाता है। log-scale पर ढलान m समय unit के प्रति विकास दर है।

Piecewise linear: जब विकास में distinct regimes होती हैं के लिए उपयुक्त। एक startup 18 महीने के लिए धीरे-धीरे बढ़ सकता है, फिर एक viral inflection हो सकता है जो 6 महीने की explosive विकास का उत्पादन करता है, फिर plateau। तीन linear segments किसी भी एक curve से बेहतर fit करता है।

Forecast cone: central अनुमान plus upper और lower bounds, future में widening cone के रूप में खींचा गया। cone की width समय के साथ बढ़ता है क्योंकि uncertainty compounds। एक 4-सप्ताह का पूर्वानुमान ~10% bounds हो सकता है; एक 12-महीने का पूर्वानुमान अक्सर ±50% या अधिक होता है।

Seasonality decomposition: real मांग trend + seasonal cycle + noise को मिलाती है। Statistical libraries (statsmodels, Prophet) एक series को इन तीन components में decompose करते हैं, जिससे trend को seasonal pattern से अलग से project किया जा सकता है। ज्यामितीय रूप से, trend underlying drift है, seasonality periodic ripple है top पर, और noise residual jitter है।

एक प्रवृत्ति मॉडल चुनना

आपके पास 24 महीने की monthly request volumes है। महीने 1-12 1M से 2M तक बढ़े (linear-looking, +83K/month)। महीने 13-18 2M से 4M तक बढ़े (steeper, +330K/month)। महीने 19-24 4M से 12M तक बढ़े (much steeper still)। Marketing एक viral product feature की पुष्टि करता है जो महीने 13 में launched हुई inflection को drive कर रही है।

क्षमता बनाम 2डी ज्यामिति के रूप में मांग

हर क्षमता टीम जो प्लॉट के अंदर रहता है

x-अक्ष पर समय को plot करें। y-अक्ष पर मांग और क्षमता को दो separate लाइनों के रूप में plot करें। किसी भी समय उनके बीच vertical gap headroom है। दोनों curves के बीच 2डी area headroom envelope है।

तीन reference आकार:

- Healthy envelope: capacity line comfortably demand line से ऊपर रहता है। gap peaks के दौरान narrow हो सकता है लेकिन कभी vanish नहीं होता। envelope एक band of safety है।

- Closing envelope: capacity मांग से slower बढ़ता है। gap समय के साथ narrow होता है। future में intersection point वह date है जब सिस्टम headroom से बाहर runs: वह date जब टीम को क्षमता add करनी चाहिए।

- Inverted envelope: demand क्षमता को exceed करता है। सिस्टम incident territory में है। inversion की vertical magnitude वह deficit है जिसे किसी तरह serve किया जाना चाहिए (queue overflow, error rates, customer impact)।

Standard capacity planning chart plots करता है:

- Recent demand history (solid blue line)

- Forecast demand with bounds (dashed line + shaded cone)

- Current capacity (solid green line)

- Planned capacity additions with delivery dates (step function)

- वह intersection date जहां forecast demand current capacity को cross करता है: यह अगले provisioning के लिए deadline है

Visual decision rule: capacity step function को forecast cone के upper bound से ऊपर सभी समय keep करें। central estimate के लिए provision न करें; upper bound के लिए provision करें। over-provisioning की cost finite है (कुछ idle capacity); under-provisioning की cost unbounded है (lost users, cascade failure, reputation damage)।

लिफाफा को पढ़ना

आपके capacity chart दिखाते हैं: current demand 1,500 RPS है 20% प्रति महीने बढ़ रहा है। Current capacity 2,500 RPS है। एक नया server batch (+1,500 RPS capacity) 8 सप्ताह में arrives करता है। Forecast cone 8-सप्ताह horizon पर ±15% bounds है।

क्षमता की ज्यामिति: समाप्ति

भविष्य की भविष्यवाणी करने वाली आकृतियां

आप क्षमता नियोजन के अंतर्निहित चार ज्यामितीय संरचनाओं के माध्यम से चले गए हैं:

- लिटिल का नियम (L = λ × W) एक आयत के क्षेत्र के रूप में steady-state occupancy को परिभाषित करते हुए

- queueing curve इसकी 80% उपयोग पर कोहनी के साथ, उच्च चलाने की गैर-रैखिक लागत को encode करते हुए

- प्रवृत्ति ढलान और forecast cones जो ऐतिहासिक डेटा को कार्यक्षम प्रक्षेपण में बदलते हैं

- Headroom envelopes क्षमता बनाम समय के साथ प्लॉट किए गए मांग के रूप में, provisioning deadlines को चिह्नित करने वाली intersection dates के साथ

क्षमता नियोजन अपने visual core पर एक curve को समय के साथ दूसरे के ऊपर safely रखने की discipline है। संख्याएं पोशाक हैं; shapes सत्य carry करती हैं। एक capacity engineer जो queueing curve को सही तरीके से पढ़ता है समस्याओं को पकड़ेगा जो एक CPU dashboard hide करता है जब तक सिस्टम पहले से ही burning नहीं है।

Capacity planning पर companion lesson practices को covered करता है: measurement, forecasting, ceiling tests, headroom, and scaling। यह lesson उनके अंतर्निहित ज्यामिति को covered करता है। एक साथ वे running services के visual और analytical scaffolding बनाते हैं जो surprise के बिना scale करते हैं।