कंपोजिट SLA / संयुक्त अपटाइम कैलकुलेटर

गणना दर्ज करें

टोपोलॉजी Serial (dependency chain) Parallel (redundant)

कॉम्पोनेंट 1 का अपटाइम (%)

कॉम्पोनेंट 2 का अपटाइम (%)

Component 3 uptime (%) वैकल्पिक

Component 4 uptime (%) वैकल्पिक

परिणाम

कंपोजिट उपलब्धता

99.8001%

across 2 components

डाउनटाइम (%)	0.1999%
हर साल डाउनटाइम	17.51 hours
हर महीने डाउनटाइम	87.56 min
हर दिन डाउनटाइम	2.8786 min

कंपोजिट SLA क्या होता है?

आज के सिस्टम कई हिस्सों से मिलकर बनते हैं — लोड बैलेंसर, डेटाबेस, थर्ड-पार्टी API, CDN और बहुत कुछ। हर हिस्से का अपना Service Level Agreement (SLA) होता है, जिसे 99.9% जैसे अपटाइम प्रतिशत में बताया जाता है। कंपोजिट (संयुक्त) SLA वह वास्तविक उपलब्धता है जो इन सभी हिस्सों के आपस में जुड़ने के बाद पूरे सिस्टम को मिलती है। यह कैलकुलेटर हर कॉम्पोनेंट के अपटाइम को मिलाकर एक एंड-टू-एंड उपलब्धता का आँकड़ा बनाता है और उसे हर दिन, महीने और साल के ठोस डाउनटाइम में बदल देता है।

उच्च उपलब्धता प्रतिशत का मतलब है प्रति वर्ष बहुत कम डाउनटाइम।

सीरियल बनाम पैरेलल टोपोलॉजी

कॉम्पोनेंट्स किस तरह जुड़े हैं, इससे नतीजा बहुत बदल जाता है। सीरियल (निर्भरता की चेन) में किसी भी रिक्वेस्ट के सफल होने के लिए हर कॉम्पोनेंट का चालू होना ज़रूरी है, इसलिए सभी उपलब्धताएँ आपस में गुणा होती हैं — कुल आँकड़ा हमेशा सबसे कमज़ोर कड़ी से भी कम रहता है। सीरियल टोपोलॉजी के लिए सूत्र है:

$$A_{\text{total}} = \text{A}_1 \times \text{A}_2 \times \text{A}_3 \times \text{A}_4$$

वहीं पैरेलल (रिडंडंट) सेटअप में जब तक कम-से-कम एक रास्ता काम कर रहा है, सिस्टम चालू रहता है, इसलिए यहाँ विफलता की संभावनाओं को गुणा किया जाता है; रिडंडंसी उपलब्धता को किसी भी अकेले कॉम्पोनेंट से ज़्यादा ऊपर ले जाती है।

$$A_{\text{total}} = 1 - \left(1-\text{A}_1\right)\left(1-\text{A}_2\right)\left(1-\text{A}_3\right)\left(1-\text{A}_4\right)$$

श्रृंखला (आश्रित) घटक उपलब्धता को गुणा करते हैं, जबकि समानांतर (अतिरिक्त) घटक मिलकर इसे बढ़ाते हैं।

इसका इस्तेमाल कैसे करें

पहले अपनी टोपोलॉजी चुनें, फिर हर कॉम्पोनेंट का अपटाइम प्रतिशत डालें (जैसे 99.95)। इसमें चार कॉम्पोनेंट तक जोड़े जा सकते हैं; कम कॉम्पोनेंट मिलाने हों तो वैकल्पिक फ़ील्ड खाली छोड़ दें। नतीजे में कंपोजिट उपलब्धता के साथ-साथ आम समयावधियों में अनुमानित डाउनटाइम भी दिखता है।

एक उदाहरण से समझें

मान लीजिए आपका ऐप तीन सीरियल कॉम्पोनेंट्स पर निर्भर है और हर एक का अपटाइम 99.9% है। इन्हें भिन्न में बदलें:

$$0.999 \times 0.999 \times 0.999 = 0.997002999$$

यानी 99.7003%। यह करीब 0.2997% का डाउनटाइम है — यानी साल भर में लगभग 26.26 घंटे। "तीन नाइन" वाली सेवाओं को सीरियल में जोड़ने पर कुल मिलाकर सिर्फ़ "दो नाइन" ही मिल पाते हैं, और ठीक यही वजह है कि रिडंडंसी इतनी मायने रखती है।

अक्सर पूछे जाने वाले सवाल

मेरा सीरियल नतीजा हर इनपुट से कम क्यों आ रहा है? क्योंकि हर निर्भरता विफलता की एक और संभावना जोड़ देती है; 1 से कम संख्याओं को आपस में गुणा करने पर कुल हमेशा घटता है।

क्या पैरेलल सचमुच इतना अपटाइम बढ़ा देता है? हाँ — दो स्वतंत्र 99% रास्ते मिलकर \(1 - (0.01 \times 0.01) = 99.99\%\) देते हैं, बशर्ते दोनों की विफलताएँ सचमुच एक-दूसरे से स्वतंत्र हों।

99.9% का समय में क्या मतलब है? साल भर में करीब 8.77 घंटे का डाउनटाइम, या हर महीने लगभग 43.8 मिनट।