11.3 क्यूइंग थ्योरी

अवलोकन और प्रेरणा

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

यहाँ प्रेरणा है: कतारों के बारे में अंतर्ज्ञान भरोसे से ग़लत है, और महँगे तरीक़ों से ग़लत है। लोग मान लेते हैं कि 90% उपयोग पर चलता कोई सर्वर “मुसीबत से 10% दूर” है, जबकि असल में उपयोग 100% के क़रीब पहुँचते ही प्रतीक्षा-समय ग़ैर-रैखिक रूप से फट पड़ता है। वे मान लेते हैं कि प्रगति-में-काम (डब्ल्यूआईपी) जोड़ने से डिलीवरी तेज़ होती है, जबकि यह लीड-टाइम बढ़ाता है। वे औसतों के इर्द-गिर्द क्षमता की योजना बनाते हैं, फिर परिवर्तनशीलता से बर्बाद हो जाते हैं। थोड़ी सी क्यूइंग थ्योरी इन महँगे अंतर्ज्ञानों को थोड़े-से मज़बूत संबंधों से बदल देती है, सबसे महत्वपूर्ण लिटल का नियम, जो ग्राहक-कतारों, कार्य-बोर्डों, और सीआई/सीडी पाइपलाइनों में समान रूप से लागू होते हैं।

बड़ी टीमों, उद्यम, और सरकार के लिए, क्यूइंग थ्योरी क्षमता और फ़्लो के लिए एक साझा भाषा है, जो उन भूमिकाओं को जोड़ती है जो अन्यथा एक-दूसरे से बेमेल बात करतीं। उत्पाद-प्रबंधक विचार से ग्राहक तक लीड-टाइम की परवाह करते हैं। एसआरई सर्वर-उपयोग और विलंब की परवाह करते हैं। डेवऑप्स टीमें डिप्लॉयमेंट-आवृत्ति की परवाह करती हैं। सहायता-नेता प्रतिक्रिया-समय की परवाह करते हैं। ये सब कतार-मेट्रिक्स हैं, और इन्हें एक ढाँचे (आगमन-दर, सेवा-दर, उपयोग, प्रतीक्षा-समय) में व्यक्त करना किसी संगठन को क्षमता की योजना बनाने, वास्तविक एसएलओ (सेवा-स्तर उद्देश्य) तय करने, और किस्से के बजाय गणित से निवेश उचित ठहराने देता है।

मुख्य सिद्धांत

• प्रतीक्षा वाली हर चीज़ एक कतार है: टिकट, कार्य, संदेश, और डिप्लॉय शामिल।
• लिटल का नियम लंगर है: प्रणाली में मदें = आगमन-दर × प्रणाली में समय (κ = λτ)।
• उपयोग और प्रतीक्षा-समय ग़ैर-रैखिक हैं: क्षमता का आख़िरी 15% सबसे महँगा है।
• परिवर्तनशीलता फ़्लो की दुश्मन है: औसत दर्द छुपाते हैं; विचरण कतारें बनाता है।
• प्रगति-में-काम घटाना लीड-टाइम घटाता है: लक्ष्य फ़्लो है, व्यस्तता नहीं।
• पूरे फ़्लो को मापें: आगमन, सेवा, सफलताएँ, विफलताएँ, छोड़ना, और प्रतीक्षाएँ।
• कोई प्रक्रिया कतारों की एक कतार है: चरणों को मॉडल करें, फिर बाधक चरण को अनुकूलित करें।

सिफ़ारिशें

मुख्य संकेतन सीखें और इसे संगत रूप से इस्तेमाल करें

मुट्ठी भर मात्राएँ किसी भी कतार का वर्णन करती हैं। इन्हें मानकीकृत करना (ग्रीक अक्षर पारंपरिक हैं) टीमों में अस्पष्टता हटाता है:

• λ (लैम्ब्डा), आगमन-दर: नई मदें कितनी तेज़ी से आती हैं।
• μ (म्यू), सेवा-दर: मदें कितनी तेज़ी से संभाली जाती हैं। चूँकि “सेवा-दर” अस्पष्ट रूप से इस्तेमाल होती है, अक्सर थ्रूपुट को स्पष्ट रूप से कुल दर (χ), सफलता-दर (α), विफलता-दर (β), और छोड़ना-दर (σ) में विभाजित करना लायक़ है, जहाँ χ = α + β + σ।
• ρ (रो), उपयोग / ट्रैफ़िक-तीव्रता = λ / μ: सबसे महत्वपूर्ण अकेला सारांश। ρ < 1 का मतलब कतार निकल जाती है; ρ ≥ 1 का मतलब यह बिना सीमा बढ़ती है।
• समय: लीड-टाइम (τ, शुरू से अंत तक), काम-समय (φ, वास्तविक प्रोसेसिंग), प्रतीक्षा-समय (ω, लंबित), और क़दम-समय (θ, पूर्णताओं के बीच)।
• ε (एप्सिलॉन), त्रुटि-अनुपात: विफलताएँ ÷ कुल।

सॉफ़्टवेयर में विफलताओं और छोड़ने को स्पष्ट रूप से नाम देना मायने रखता है: कोई मद जिसे छोड़ दिया जाता है (कोई ग्राहक जो हार मान लेता है, कोई कार्ट जो छोड़ दी जाती है, कोई अस्वीकृत कार्य-टिकट) बिना सेवा किए कतार छोड़ देती है, और यह दिखावा करना कि इसकी “सेवा हुई” आपके मेट्रिक्स को भ्रष्ट करता है। बॉकिंग (शामिल न होने का फ़ैसला), रिनेगिंग (प्रतीक्षा के बाद हार मानना), और जॉकीइंग (कतारें बदलना) को प्रथम-श्रेणी नतीजों के रूप में ट्रैक करें।

लिटल के नियम पर योजना का लंगर डालें

लिटल का नियम कहता है कि किसी स्थिर प्रणाली में दीर्घकालिक औसत मदों की संख्या औसत आगमन-दर गुणा हर मद द्वारा प्रणाली में बिताए औसत समय के बराबर है: κ = λ τ (क्लासिक रूप से L = λW)। यह आश्चर्यजनक रूप से सामान्य है (इसे आगमन-वितरण या सेवा-क्रम के बारे में किसी धारणा की ज़रूरत नहीं), जो इसे फ़्लो-योजना का मुख्य औज़ार बनाता है। फिर से व्यवस्थित करने पर, यह आपको बताता है कि लीड-टाइम = प्रगति-में-काम ÷ थ्रूपुट। यही कनबान और लीन का गणितीय आधार है: अगर आप छोटा लीड-टाइम चाहते हैं और थ्रूपुट नहीं बढ़ा सकते, तो आपको डब्ल्यूआईपी घटाना ही होगा। यह त्वरित समझदारी-जाँच भी देता है। अगर 40 टिकट खुले हैं और आप रोज़ाना 8 बंद करते हैं, तो औसत टिकट लगभग 5 दिन लेता है, चाहे किसी को कितना भी व्यस्त महसूस हो। इसकी एक शर्त है स्थिरता: आगमन को स्थायी रूप से प्रस्थान से अधिक नहीं होना चाहिए (ρ < 1), वरना कतार, और नियम की धारणाएँ, टूट जाती हैं।

उपयोग की ग़ैर-रैखिकता का सम्मान करें

क्यूइंग थ्योरी का सबसे महत्वपूर्ण परिचालन-सबक यह है कि उपयोग 100% के क़रीब पहुँचते ही प्रतिक्रिया-समय धीरे-धीरे नहीं, तेज़ी से बढ़ता है। बॉब वेस्कॉट की सेवन इनसाइट्स इनटू क्यूइंग थ्योरी व्यावहारिक परिणामों को जीवंत रूप से पकड़ती है:

1. सेवा-केंद्र जितना धीमा, उतना ही कम चोटी-उपयोग जिसकी आपको योजना बनानी चाहिए।
2. किसी भी चीज़ के आख़िरी 15% का इस्तेमाल करना बहुत कठिन है।
3. आप जितना किनारे के क़रीब चलते हैं, ग़लत होने की क़ीमत उतनी ज़्यादा है।
4. प्रतिक्रिया-समय की वृद्धि इससे सीमित है कि कितनी मदें प्रतीक्षा कर सकती हैं।
5. ये औसत हैं, अधिकतम नहीं: पूँछ के लिए योजना बनाएँ।
6. कई सेवा-केंद्रों में मानवीय अस्वीकृति-प्रभाव से सावधान रहें।
7. छोटे सुधारों को उनकी सबसे अच्छी रोशनी में दिखाएँ।

डिज़ाइन-निहितार्थ: जान-बूझकर गुंजाइश प्रावधान करें। विलंब-संवेदनशील प्रणालियों के लिए 70-80% उपयोग को लक्ष्य बनाना बर्बादी नहीं है; यह भविष्यवाणी-योग्य प्रतिक्रिया-समय ख़रीदना है। यह सीधे क्षमता-योजना और एसएलओ (अध्याय 3.5 और 9.1) को सूचित करता है।

प्रक्रियाओं को कतारों की एक कतार के रूप में मॉडल करें

असली काम चरणों से होकर बहता है, और कोई बहु-चरण प्रक्रिया बस एक ऐसी कतार है जिसकी मदें ख़ुद हर क़दम पर कतारबद्ध हैं। इसे उसी तरह मॉडल करें: प्रक्रिया की आगमन-दर चरण 1 की आगमन-दर है; प्रक्रिया की सफलता-दर अंतिम चरण की सफलता-दर है; प्रक्रिया की त्रुटि और छोड़ना गिनती चरणों में योग हैं। दो आम आकार दोहराते हैं:

• फ़नल, जहाँ हर चरण मद-गिनती सिकोड़ती है (भर्ती: पहुँच → साक्षात्कार → प्रस्ताव; ख़रीदारी: ब्राउज़ → कार्ट → भुगतान; डिलीवरी: एकीकरण → यूएटी → उत्पादन)। सबसे ज़्यादा मायने रखने वाले चरण को अनुकूलित करें: फ़नल-शीर्ष आगमन को अधिकतम करें, मध्य-फ़नल छोड़ना (कार्ट-त्याग) कम से कम करें, या अंतिम-चरण त्रुटियाँ (ख़राब उत्पादन-रोलआउट) कम से कम करें।
• डबल-डायमंड खोज-और-डिलीवरी फ़्लो (खोजें → परिभाषित करें → विकसित करें → डिलीवर करें), जिसे इस किताब का फ़्लो हिस्सा सीधे संभालता है (अध्याय 11.1)।

बाधक चरण (बॉटलनेक) को ढूँढना और राहत देना वह जगह है जहाँ फ़्लो-सुधार फल देता है; ग़ैर-बाधाओं को अनुकूलित करना सिर्फ़ कतार को कहीं और ले जाता है।

कतार-मेट्रिक्स को उन केपीआई से जोड़ें जो टीमें पहले से इस्तेमाल करती हैं

क्यूइंग मात्राएँ इस किताब में कहीं और के डिलीवरी और विश्वसनीयता मेट्रिक्स पर साफ़ तरीक़े से मैप होती हैं, जो इस थ्योरी को अकादमिक के बजाय व्यावहारिक बनाता है:

• डिलीवरी लीड-टाइम (Dτ), “विचार से ग्राहक तक,” एक लीड-टाइम (τ) माप है और एक DORA (डेवऑप्स रिसर्च एंड असेसमेंट) मेट्रिक (अध्याय 11.2)।
• डिप्लॉयमेंट-आवृत्ति (Dμ) एक सेवा-दर माप है।
• बदलाव-विफलता-दर (Dε) एक त्रुटि-अनुपात है।
• पुनर्स्थापन-समय (Rτ) एक पुनर्स्थापन-लीड-टाइम है, यानी एमटीटीआर (अध्याय 9.3)।

कई एमटीटीआर को अलग करें (औसत प्रतिक्रिया, मरम्मत, पुनर्प्राप्ति, और समाधान का समय) क्योंकि वे घटना-कतार के अलग खंड मापते हैं और नियमित रूप से गड्डमड्ड किए जाते हैं। एसएलआई/एसएलओ/एसएलए (अध्याय 9.1) को कतार-शब्दों में आधारित करना लक्ष्यों को ईमानदार और तुलना-योग्य रखता है।

ट्रेड-ऑफ़: फ़ायदे और नुक़सान

फ़ैसला	फ़ायदे	नुक़सान
उच्च उपयोग पर प्रणालियाँ चलाना	प्रति-इकाई कम हार्डवेयर/लागत	ग़ैर-रैखिक विलंब-विस्फोट; उछालों में भंगुर
उदार गुंजाइश प्रावधान करना	भविष्यवाणी-योग्य विलंब; विचरण के प्रति लचीला	ऊँची स्थिर-स्थिति लागत; “कम-उपयोग” दिखता है
डब्ल्यूआईपी सीमित करना (कनबान)	छोटा लीड-टाइम; कम संदर्भ-स्विचिंग	धीमा महसूस होता है; सीमा थामने के लिए अनुशासन चाहिए
औपचारिक कतार-मॉडलिंग	परिमाणित क्षमता-फ़ैसले; कम आश्चर्य	सीखने का वक्र; मॉडल गड़बड़ वास्तविकता को सरल करते हैं
सिर्फ़ अंगूठे के नियम	तेज़, कोई गणित नहीं	ठीक वहाँ ग़लत जहाँ यह सबसे महँगा है (क्षमता के क़रीब)

बार-बार आने वाला ट्रेड-ऑफ़ है दक्षता बनाम भविष्यवाणी-क्षमता: उपयोग बढ़ाना पैसा बचाता है जब तक अचानक नहीं बचाता, उस बिंदु पर विलंब, विफलता, और आग-बुझाने की लागतें बचत को बौना कर देती हैं। क्यूइंग थ्योरी का योगदान आपको बताना है कि वह चट्टान कहाँ है ताकि ट्रेड-ऑफ़ एक चुनाव हो, कोई दुर्घटना न हो।

अपनी टीम के साथ चर्चा के लिए प्रश्न

1. हर विलंब-संवेदनशील प्रणाली के लिए आपका स्पष्ट उपयोग-लक्ष्य क्या है, और इस पर किसने मंज़ूरी दी? गुंजाइश भविष्यवाणी-योग्य विलंब की जान-बूझकर ख़रीद है, इसलिए यह एक बताई गई नीति होनी चाहिए, जो भी लोड आ गया उसकी दुर्घटना नहीं। चूँकि प्रतिक्रिया-समय ग़ैर-रैखिक रूप से बढ़ता है, 85% पर चलना पहले से ऊँचा पूँछ-विलंब मतलब हो सकता है, फिर भी वित्त गुंजाइश को बर्बादी मानता है और उपयोग बढ़ाने पर ज़ोर देता है। संख्याएँ लाएँ: वर्तमान उपयोग, मापा गया विलंब-वक्र, और आपकी आख़िरी विलंब-घटना की लागत, फिर हर सेवा के लिए दिखाएँ कि चट्टान कहाँ बैठती है। मौसमी चोटियों (फ़ाइलिंग-सीज़न, नामांकन-खिड़कियाँ) वाली उद्यम और सरकारी प्रणालियों के लिए, लक्ष्य को औसत के बजाय चोटी के लिए चट्टान से दूर तय करें। अगर उपयोग-लक्ष्य का कोई मालिक नहीं, विलंब-घटनाएँ “कहीं से भी” प्रकट होती रहेंगी।

2. आपकी प्रणालियों में कहाँ कोई कतार असीमित है, अभिभूत होने पर लोड कम करने के लिए कोई बैक-प्रेशर नहीं? कोई असीमित कतार शालीनता से विफल नहीं होती; यह पतन में बिगड़ती है, क्योंकि आगमन का स्थायी रूप से प्रस्थान से अधिक होना (रो >= 1) मतलब है कतार बिना सीमा बढ़ती है। अपनी संदेश-कतारों, थ्रेड-पूल, और अनुरोध-बफ़रों की सूची बनाएँ, और पूछें कि हर एक में क्या होता है जब आगमन-दर सेवा-दर से आगे निकल जाए: क्या यह लोड कम करता है, बैक-प्रेशर लगाता है, या गिर जाता है? यह उद्यम-पैमाने पर तीव्रता से मायने रखता है, जहाँ एक संतृप्त डाउनस्ट्रीम सेवाओं में झरने की तरह फैल सकता है। कोई लोड-टेस्ट नतीजा या कोई पिछली घटना लाएँ जहाँ कोई कतार जमा हो गई, और जाँचें कि क्या प्रणाली ने अतिरिक्त काम अस्वीकार किया या इसे सब थामने की कोशिश की। समाधान है लिटल के नियम से निकाले गए स्पष्ट बैक-प्रेशर और टाइमआउट वाली सीमित कतारें, ताकि कोई ओवरलोड गिरने के बजाय हल्का हो जाए।

3. क्या आप अपने विचार-से-उत्पादन फ़्लो को कतारों की कतार के रूप में मॉडल कर रहे हैं, और क्या आपके सुधार असली बाधा पर निशाना साध रहे हैं? कोई बहु-चरण प्रक्रिया एक कतार है जिसकी मदें हर चरण पर कतारबद्ध हैं, और बाधक चरण के अलावा कुछ भी अनुकूलित करना सिर्फ़ कतार को कहीं और ले जाता है। अपना डिलीवरी-फ़नल मैप करें (एकीकरण से यूएटी से उत्पादन तक, या खोज से परिभाषा से विकास से डिलीवरी तक) और हर चरण पर आगमन, सेवा, प्रतीक्षा, और छोड़ना-दर मापें ताकि पता चले काम वाक़ई कहाँ जमा होता है। टीमें नियमित रूप से बॉटलनेक के बजाय जिस चरण को वे सबसे अच्छी तरह समझती हैं उसे अनुकूलित करती हैं, जो प्रयास ख़र्च करता है और कुछ नहीं हिलाता। भाव के बजाय प्रति-चरण प्रतीक्षा-समय डेटा लाएँ, क्योंकि बॉटलनेक अक्सर कोई काम-स्थिति के बजाय कोई प्रतीक्षा-स्थिति (समीक्षा, मंज़ूरी, वातावरण-उपलब्धता) होती है। एक बार आप बाधा जान लें, वहाँ निशाना साधें और ग़ैर-बाधाओं को अकेला छोड़ दें।

4. क्या आप डब्ल्यूआईपी सीमाएँ तय करने के लिए लिटल के नियम का इस्तेमाल कर रहे हैं, या आप उन लीड-टाइम को ठीक करने के लिए क्षमता जोड़ रहे हैं जिन्हें सिर्फ़ और अनुशासन ठीक करता? लिटल का नियम कहता है लीड-टाइम प्रगति-में-काम को थ्रूपुट से विभाजित करने के बराबर है, इसलिए अगर आप थ्रूपुट नहीं बढ़ा सकते, छोटे लीड-टाइम के लिए बचा इकलौता लीवर डब्ल्यूआईपी घटाना है, जिसकी संयम के अलावा कोई क़ीमत नहीं है। प्रतिस्पर्धी खिंचाव असली है: प्रगति-में-काम सीमित करना धीमा और निष्क्रिय महसूस होता है, और दबाव में प्रबंधक टीमों को कम शुरू करने और ज़्यादा ख़त्म करने के बजाय भर्ती या हार्डवेयर ख़रीदना पसंद करेंगे। कठोर संख्याएँ लाएँ, प्रति-चरण वर्तमान खुली मदें और पूर्णता-दर, और निहित औसत लीड-टाइम की गणना करें, फिर इसकी तुलना उससे करें जो लोग मानते हैं; अंतराल आमतौर पर बड़ा और शर्मनाक होता है। किसी बड़े उद्यम या एजेंसी में, लीड-टाइम-फ़िक्स के रूप में उचित ठहराई गई कोई भर्ती या ख़रीद-माँग पहले इस अंकगणित के मुक़ाबले परीक्षित होनी चाहिए, क्योंकि हेडकाउंट-वृद्धि जो डब्ल्यूआईपी बढ़ाती है वह ठीक उन्हीं लीड-टाइम को लंबा कर सकती है जिन्हें यह छोटा करने के लिए थी।

5. क्या आप औसतों के इर्द-गिर्द क्षमता की योजना बनाते हैं, या आपने उस परिवर्तनशीलता को परिमाणित किया है जो वाक़ई आपकी कतारें बनाती है? कतारें विचरण से बनती हैं, माध्य से नहीं, इसलिए एक ही औसत लोड वाली दो प्रणालियाँ पूरी तरह अलग व्यवहार कर सकती हैं अगर एक में फुहार-भरे आगमन या लंबी-पूँछ वाला सेवा-समय हो। तनाव यह है कि औसत इकट्ठा करना आसान और रिपोर्ट करना आश्वस्त करने वाला है, जबकि विचरण और पूँछ मापना कठिन और किसी स्टेटस-अपडेट में अवांछित हैं। माध्य नहीं, वितरण लाएँ: आगमन-फुहार, 95वाँ और 99वाँ प्रतिशतक सेवा और प्रतीक्षा-समय, और वे बैच-आकार जो काम को उछालों में केंद्रित करते हैं। भविष्यवाणी-योग्य उछाल (फ़ाइलिंग-सीज़न, वेतन-रन, नामांकन-खिड़कियाँ, तिमाही-अंत लोड) वाली उद्यम और सरकारी प्रणालियों के लिए, बफ़र और उपयोग-लक्ष्य को चोटी-अवधि विचरण से तय करें, क्योंकि वार्षिक औसत के आकार का कोई डिज़ाइन ठीक तब विफल होगा जब जनता देख रही हो।

6. आपकी कौन-सी कतारें त्याग और अस्वीकृति को चुपचाप ऐसे गिनती हैं मानो काम की सेवा हुई हो, और वह कौन-सी अपूर्ण माँग छुपाती है? कोई मद जो बॉक करती है, रिनेग करती है, या अस्वीकृत होती है वह बिना संभाले कतार छोड़ती है, और इसे “सेवित” के रूप में दर्ज करना एक साथ आपके थ्रूपुट, आपके त्रुटि-अनुपात, और आपकी क्षमता-योजना को भ्रष्ट करता है। प्रतिस्पर्धी विचार यह है कि “जवाब दी गई कॉल” या “बंद किए टिकट” किसी डैशबोर्ड पर “हार मान चुके कॉल करने वाले” से बेहतर दिखते हैं, इसलिए ईमानदार संख्या वह है जिसे कोई स्वेच्छा से उजागर नहीं करता। छोड़ना-दर (σ), बॉकिंग और रिनेगिंग गिनती, और पेश किए गए लोड व सेवित लोड के बीच का अंतर लाएँ, ताकि असली माँग दृश्यमान हो जाए। यह सरकारी सेवा-डिलीवरी में तीखे तौर पर मायने रखता है, जहाँ फ़ोन-कतार या लाभ-आवेदन छोड़ने वाले नागरिक हल किए गए मामलों के बजाय अपूर्ण दायित्व हैं, और उन्हें संभाला हुआ रिपोर्ट करना प्रदर्शन दोनों को ग़लत बताता है और जनता के हक़दार क्षमता को कम आँकता है।

क्षेत्र-लेंस

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

छोटा व्यवसाय। बिना किसी क्यूइंग-विशेषज्ञ के, मॉडल बनाने के बजाय मेट्रिक्स ख़रीदें। ऐसा हेल्प-डेस्क, मैसेज-ब्रोकर, या होस्टिंग-प्लेटफ़ॉर्म चुनें जो पहले से आगमन-दर, प्रतीक्षा-समय, और त्याग रिपोर्ट करता है, और उन्हें निकालने के बजाय उन संख्याओं को पढ़ें। फ़ैसले को दो लक्षणों पर नज़र रखने के रूप में फ़्रेम करें: जैसे-जैसे आप व्यस्त होते हैं ग़ैर-रैखिक रूप से चढ़ती प्रतीक्षाएँ, और सेवा मिलने से पहले हार मानने वाले ग्राहक, क्योंकि खोया हुआ ग्राहक ही वह कतार-लागत है जो किसी छोटे व्यवसाय को सबसे ज़्यादा चोट पहुँचाती है।

उद्यम। काम है कतार-सोच को कई टीमों में साझा अनुशासन बनाना: एक सहमत संकेतन (λ, μ, ρ, लीड-टाइम), संगत डब्ल्यूआईपी और उपयोग-गुंजाइश नीतियाँ, और बैक-प्रेशर मानक ताकि कोई संतृप्त डाउनस्ट्रीम सेवाओं में झरने की तरह न फैले। अंदाज़े के बजाय कतार-विश्लेषण से एसएलओ और क्षमता तय करें, और अपनी कतारों को आधार-रेखाओं व समीक्षाओं वाले पोर्टफ़ोलियो के रूप में प्रबंधित करें ताकि कोई एक टीम अलगाव में गर्म न चले। विश्लेषण को क्षमता-शासन और ऑडिट में पकाएँ, ताकि कोई गुंजाइश-लक्ष्य एक दस्तावेज़ित फ़ैसला हो जिसका कोई मालिक हो।

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

उदाहरण

स्टार्टअप। समर्थन-बैकलॉग में डूबी एक पाँच-सदस्यीय सास-टीम मान लेती है कि उन्हें एक और एजेंट भर्ती करना होगा। पैसा ख़र्च करने से पहले, वे लिटल का नियम लगाते हैं: 60 खुले टिकट और रोज़ाना 12 बंद का मतलब है औसत टिकट लगभग 5 दिन इंतज़ार करता है, जो नाराज़ ईमेलों से मेल खाता है। अपने कनबान-बोर्ड को देखते हुए, वे नोटिस करते हैं कि टिकट समर्थन के बजाय इंजीनियरिंग की प्रतीक्षा में जमा होते हैं, इसलिए वे प्रगति-में-काम सीमित करते हैं और बग-रिपोर्ट को कतार में लगने देने के बजाय सीधे स्प्रिंट में भेजते हैं। बिना किसी नई भर्ती के लीड-टाइम दो दिन से नीचे गिर जाता है, और वे बचा बजट असली बॉटलनेक पर इस्तेमाल करते हैं।

उद्यम। अपनी अनुमोदन-सेवा का आकार तय करता कोई भुगतान-प्लेटफ़ॉर्म λ ≈ 850 अनुरोध/सेकंड और प्रति-नोड μ ≈ 200/सेकंड मापता है। भोलेपन से यह ~5 नोड है (ρ = 0.85), पर यह जानते हुए कि ρ = 0.85 का मतलब पहले से तीखा ऊँचा पूँछ-विलंब है, टीम ρ ≈ 0.65 के लिए प्रावधान करती है और उड़ान-में अनुरोध-गिनती का पूर्वानुमान लगाने और कतार-गहराई व टाइमआउट तय करने के लिए लिटल के नियम का इस्तेमाल करती है। चोटी-सीज़न की घटनाएँ जो पहले “कहीं से भी” प्रकट होतीं, ग़ायब हो जाती हैं, क्योंकि टीम अब वक्र के तीखे हिस्से पर काम नहीं कर रही थी।

सरकार। किसी कर-एजेंसी का संपर्क-केंद्र फ़ाइलिंग-सीज़न समर्थन को एक कतार के रूप में मॉडल करता है: आगमन-उछाल (λ), एजेंट-क्षमता (μ), और, गंभीर रूप से, लंबी प्रतीक्षा के बाद हार मानने वाले नागरिकों की छोड़ना-दर (σ)। सिर्फ़ “जवाब दी गई कॉल” के बजाय बॉकिंग और रिनेगिंग ट्रैक करके, नेतृत्व असली अपूर्ण माँग देखता है, चोटियों के दौरान उपयोग को चट्टान से दूर रखने के लिए स्टाफ़ करता है, और अतिरिक्त क्षमता को प्रतीक्षा-समय के लिटल के नियम अनुमानों से उचित ठहराता है, सार्वजनिक ख़र्च के लिए एक किस्सागत मामले के बजाय एक सुरक्षित, गणित-समर्थित मामला।

व्यवसाय-मामला: प्रेरणाएँ, आरओआई, और टीसीओ

क्यूइंग थ्योरी दो महँगी ग़लतियों को रोककर फल देती है: अति-प्रावधान (ऐसी निष्क्रिय क्षमता के लिए चुकाना जिसकी आपको ज़रूरत नहीं थी) और, कहीं ज़्यादा हानिकारक, चट्टान के क़रीब कम-प्रावधान (जहाँ छोटी लोड-वृद्धि बड़े विलंब, टूटे एसएलए, त्याग दिए गए ग्राहक, और आपातकालीन ख़र्च का कारण बनती है)। चूँकि 100% उपयोग के क़रीब चलने की लागत ग़ैर-रैखिक है, “बस थोड़ा और लोड जोड़ो” की बचत छोटी है और नुक़सान विपत्तिपूर्ण, ठीक वही विषमता जिसे थोड़ा सा गणित एक जान-बूझकर लिए फ़ैसले में बदल देता है। रिटर्न टाली गई आउटेज, पूरे किए एसएलए, बनाए रखे वे ग्राहक जो अन्यथा बॉक करते, और शांत ऑन-कॉल-रोटेशन में मापा जाता है।

स्वामित्व की कुल लागत पर, यह ढाँचा अपनाना सस्ता है (यह ज्ञान है, टूलिंग नहीं) और यह किसी बड़े संगठन द्वारा किसी प्रणाली के जीवन-काल में लिए जाने वाले लगभग हर क्षमता, विलंब, और फ़्लो-फ़ैसले को सुधारता है। लिटल का नियम और डब्ल्यूआईपी सीमाएँ बिना कुछ ख़रीदे लीड-टाइम घटाती हैं (एक शुद्ध प्रक्रिया-जीत), जबकि उपयोग-अनुशासन महँगी, अप्रत्याशित विफलताओं को ख़त्म करने के बदले एक मामूली, भविष्यवाणी-योग्य स्थिर-स्थिति लागत का व्यापार करता है। नेतृत्व के सामने मामला बनाने के लिए, किसी हालिया विलंब-घटना को उपयोग-वक्र में अनुवादित करें और दिखाएँ कि कोई गुंजाइश-लक्ष्य इसे कैसे रोकता, और डब्ल्यूआईपी-घटाव को सीधे तेज़ डिलीवरी से जोड़ने के लिए लिटल के नियम का इस्तेमाल करें।

एंटी-पैटर्न और नुक़सान

• औसतों के इर्द-गिर्द क्षमता की योजना बनाना: विचरण को अनदेखा करना, जो असल में कतारें बनाता है।
• गर्म चलना: विलंब-संवेदनशील प्रणालियों पर 90%+ उपयोग को लक्ष्य बनाना और पूँछ-विलंब से चौंकना।
• छोड़ने को सेवा के रूप में गिनना: त्याग दिए गए ग्राहकों या अस्वीकृत टिकटों को संभाला हुआ मानना, मेट्रिक्स भ्रष्ट करना।
• डब्ल्यूआईपी ढेर करना: व्यस्तता को थ्रूपुट समझने की ग़लती और लीड-टाइम लंबा करना।
• ग़ैर-बॉटलनेक को अनुकूलित करना: उन चरणों को सुधारना जो बाधा नहीं हैं और कतार को कहीं और ले जाना।
• एमटीटीआर को गड्डमड्ड करना: “मरम्मत” मापते हुए “पुनर्प्राप्ति” रिपोर्ट करना, या इसका उल्टा।
• असीमित कतारें: कोई बैक-प्रेशर नहीं, इसलिए कोई ओवरलोड प्रणाली लोड कम करने के बजाय पतन में बिगड़ती है।
• अधिकतम के रूप में औसत: माध्य के लिए डिज़ाइन करना और पूँछ से पेज होना।

परिपक्वता मॉडल

• स्तर 1, आरंभ: कतारें (टिकट, कार्य, संदेश, डिप्लॉय) अप्रबंधित और प्रतिक्रियात्मक हैं; क्षमता का अंदाज़ा लगाया जाता है; उपयोग जहाँ भी लोड उतरे वहाँ चलता है; विलंब-समस्याएँ टीम को चौंकाती हैं और बाद में आग बुझाई जाती है।
• स्तर 2, विकास: कुछ टीमें बुनियादी मेट्रिक्स (थ्रूपुट, औसत प्रतीक्षा) इकट्ठा करती हैं पर उन्हें औसत के रूप में पढ़ती हैं और असंगत रूप से लागू करती हैं; कुछ समूह डब्ल्यूआईपी सीमित करते हैं या गुंजाइश छोड़ते हैं जबकि दूसरे गर्म चलते हैं; कोई साझा संकेतन नहीं, इसलिए अभ्यास टीमों में यात्रा नहीं करते।
• स्तर 3, मानकीकरण: एक सामान्य संकेतन (λ, μ, ρ, लीड-टाइम) पूरे संगठन में दस्तावेज़ित और लागू है; हर विलंब-संवेदनशील प्रणाली के लिए डब्ल्यूआईपी सीमाएँ और उपयोग-गुंजाइश लक्ष्य जान-बूझकर तय हैं; कई एमटीटीआर अलग किए गए हैं; बैक-प्रेशर वाली सीमित कतारें सेवाओं में डिफ़ॉल्ट हैं।
• स्तर 4, प्रबंधन: कतारों को आधार-रेखाओं के मुक़ाबले मापा और नियंत्रित किया जाता है: आगमन-दर, सेवा-दर, उपयोग, पूँछ-विलंब (p95/p99), और लीड-टाइम को परिभाषित लक्ष्यों और एसएलओ के मुक़ाबले ट्रैक किया जाता है; कतार-गहराई, टाइमआउट, और गुंजाइश अंदाज़े के बजाय लिटल के नियम से निकाले जाते हैं; बॉकिंग, रिनेगिंग, और छोड़ना-दर गिनी जाती हैं ताकि पेश किए लोड को सेवित लोड से अलग किया जा सके; क्षमता-फ़ैसले इस प्रमाण पर समीक्षित होते हैं, भाव पर नहीं।
• स्तर 5, संयोजन: फ़्लो को कतारों की कतार के रूप में लगातार मॉडल किया जाता है; बॉटलनेक एक चालू अभ्यास के रूप में पहचाने और राहत दिए जाते हैं; क्षमता, एसएलओ, और बैक-प्रेशर बदलती माँग और विचरण के अनुसार अनुकूलित होते हैं; कतार-मेट्रिक्स सीधे DORA और व्यावसायिक केपीआई से जुड़ते हैं, और लोड व जोख़िम-तस्वीर बदलने के साथ संगठन पूरे फ़्लो में क्षमता को फिर से संतुलित करता है।

चर्चा के लिए विचार

1. आपकी विलंब-संवेदनशील प्रणालियाँ वाक़ई किस उपयोग पर चल रही हैं, और उनकी चट्टान कहाँ है?
2. अपने वर्तमान बैकलॉग पर लिटल का नियम लगाएँ: आपका डब्ल्यूआईपी ÷ थ्रूपुट कौन-सा लीड-टाइम दर्शाता है, और क्या यह वास्तविकता से मेल खाता है?
3. आपकी कौन-सी कतारें “छोड़ने” (त्याग, अस्वीकृति) को चुपचाप ऐसे गिनती हैं मानो उनकी सेवा हुई हो?
4. कहाँ डब्ल्यूआईपी घटाना क्षमता जोड़ने से सस्ते में लीड-टाइम छोटा करेगा?
5. आपके विचार-से-उत्पादन फ़्लो में कौन-सा चरण असली बॉटलनेक है, और क्या आपके सुधार वहाँ निशाना साध रहे हैं?
6. क्या आपके डैशबोर्ड औसत दिखाते हैं जहाँ पूँछ ही आपको वाक़ई चोट पहुँचाती है?

मुख्य निष्कर्ष

• ग्राहक-कतारें, कनबान-बोर्ड, संदेश-कतारें, और डिप्लॉय-पाइपलाइन सब कतारें हैं जो एक ही नियमों से शासित हैं।
• लिटल का नियम (κ = λτ) फ़्लो-योजना का लंगर है: लीड-टाइम = डब्ल्यूआईपी ÷ थ्रूपुट।
• उपयोग और प्रतीक्षा-समय ग़ैर-रैखिक हैं: गुंजाइश प्रावधान करें; आख़िरी 15% सबसे महँगा है।
• पूरी तस्वीर ट्रैक करें: आगमन, सेवा, सफलताएँ, विफलताएँ और छोड़ना, और प्रतीक्षाएँ; त्याग को छुपने न दें।
• प्रक्रियाओं को कतारों की कतार के रूप में मॉडल करें और बॉटलनेक ठीक करें, व्यस्त-काम नहीं।
• कतार-मेट्रिक्स सीधे DORA/फ़्लो और एसएलआई/एसएलओ मापों (अध्याय 11.1, 11.2, 9.1) पर मैप होते हैं, पूरे संगठन को क्षमता और फ़्लो के लिए एक भाषा देते हुए।

संदर्भ और आगे पढ़ने के लिए

• बॉब वेस्कॉट, सेवन इनसाइट्स इनटू क्यूइंग थ्योरी (और द एवरी कंप्यूटर परफ़ॉर्मेंस बुक)।
• जॉन डी. सी. लिटल, “अ प्रूफ़ फ़ॉर द क्यूइंग फ़ॉर्मूला L = λW” (1961): लिटल का नियम।
• निकोल फ़ोर्सग्रेन, जेज़ हम्बल, जीन किम, एक्सेलेरेट: फ़्लो-आधारित DORA मेट्रिक्स जो कतार-केपीआई से संरेखित हैं।
• डोनाल्ड राइनर्टसन, द प्रिंसिपल्स ऑफ़ प्रोडक्ट डेवलपमेंट फ़्लो: कतारें, बैच-आकार, और डब्ल्यूआईपी-अर्थशास्त्र।
• डैनियल वकांती, एक्शनेबल एजाइल मेट्रिक्स फ़ॉर प्रेडिक्टेबिलिटी: कनबान पर लागू लिटल का नियम।
• जोएल पार्कर हेंडरसन, क्यूइंग थ्योरी: संकेतन, केपीआई, और कतार-की-कतार (github.com/joelparkerhenderson/queueing-theory)।
• डैन स्लिमन, “द मोस्ट इम्पोर्टेंट थिंग टू अंडरस्टैंड अबाउट क्यूज़” (2016)।
• विकिपीडिया: “क्यूइंग थ्योरी,” “M/M/1 क्यू,” “लिटल्स लॉ,” “मार्कोव चेन।”