जानिए वर्नर वोगेल्स द्वारा कही गई “You Build It, You Run It” का क्या मतलब है और इसे कैसे लागू करें: स्वामित्व, ऑन‑कॉल, SLOs, घटना प्रतिक्रिया और सुरक्षित शिपिंग।
“You build it, you run it” एक ऐसी पंक्ति है जो सीधे और प्रभावी है। यह प्रेरक पोस्टर्स या “ज़्यादा DevOps बनो” जैसी बातें नहीं हैं। यह जिम्मेदारी के बारे में एक स्पष्ट कथन है: जो टीम किसी सेवा को शिप करती है, वही प्रोडक्शन में उस सेवा के व्यवहार के लिए जवाबदेह रहती है।
व्यवहार में इसका मतलब यह है कि वही प्रोडक्ट टीम जो फीचर डिज़ाइन और कोड लिखती है, वही भी:
इसका मतलब यह नहीं कि हर कोई रातों‑रात इंफ्रा एक्सपर्ट बन जाए। इसका मतलब है कि फीडबैक लूप वास्तविक हो: अगर आप कुछ रिलीज़ करते हैं जिससे आउटेज, पेजर शोर, या कस्टमर पेन बढ़ता है, तो आपकी टीम इसे सीधे महसूस करती है—और तेजी से सीखती है।
यह दर्शन बोलना आसान है पर लागू करना मुश्किल, जब तक कि आप इसे स्पष्ट अपेक्षाओं वाले ऑपरेटिंग मॉडल के रूप में न लें। “Run it” आमतौर पर ऑन‑कॉल होने, घटना प्रतिक्रिया का स्वामित्व लेने, रनबुक लिखने, डैशबोर्ड बनाए रखने और सेवा में लगातार सुधार करने को शामिल करता है।
यह भी संकेत करता है कि टीमों से “run it” करने की मांग तब तक नहीं करनी चाहिए जब तक उन्हें समस्याएँ ठीक करने के लिए टूल, एक्सेस और अधिकार न दिए जाएँ—और उनके रोडमैप में उस काम के लिए समय भी न हो।
“You Build It, You Run It” से पहले कई कंपनियाँ सॉफ़्टवेयर को रिले रेस की तरह ऑर्गनाइज़ करती थीं: डेवलपर्स कोड लिखते, फिर उसे डिप्लॉय और रन करने के लिए “दीवार के पार” ops टीम को दे देते थे।
वह हैंडऑफ़ अल्पकालिक समस्या तो सुलझाता था—कोई अनुभवी प्रोडक्शन देख रहा था—पर उसने बड़े मुद्दे पैदा किए।
जब अलग ops टीम प्रोडक्शन का स्वामित्व रखती है, तो डेवलपर्स अक्सर समस्याएँ देर से (या कभी नहीं) जान पाते। बग कई दिन बाद एक अस्पष्ट टिकट के रूप में दिख सकता है: “सर्विस धीमी है” या “CPU अधिक है।” तब तक संदर्भ गायब हो चुका होता है, लॉग रोटेट हो चुके होते हैं, और बदलाव करने वाले लोग आगे बढ़ चुके होते हैं।
हैंडऑफ़्स ownership को भी धुंधला करते हैं। अगर आउटेज होता है, तो डेवलप शायद सोचेगा “ops पकड़ेगा,” जबकि ops अनुमान लगाएगा “dev ने कुछ रिस्की शिप किया।” परिणाम अपेक्षित है: लंबी घटना समाधान अवधि, दोहराए जाने वाले फेल्योर मोड, और ऐसी संस्कृति जहाँ टीमें स्थानीय रूप से ऑप्टिमाइज़ करती हैं बजाय कस्टमर एक्सपीरियंस के।
“You Build It, You Run It” लूप को कसता है। वही टीम जो बदलाव शिप करती है, प्रोडक्शन में उसके व्यवहार के लिए जवाबदेह रहती है। इससे व्यवहारिक सुधार ऊपर की ओर आते हैं: स्पष्ट अलर्ट, सुरक्षित रोलआउट, बेहतर डैशबोर्ड्स, और ऑपरेट करने में आसान कोड।
पैराडॉक्सल्ली, यह अक्सर तेज़ डिलीवरी की ओर ले जाता है। जब टीमें अपनी रिलीज़ प्रक्रिया पर भरोसा करती हैं और प्रोडक्शन व्यवहार समझती हैं, तो वे छोटे बदलावों को अधिक बार शिप कर सकती हैं—जिससे गलतियों का ब्लास्ट रेडियस कम होता है और समस्याएँ निदान में आसान होती हैं।
हर संगठन समान स्टाफिंग, अनुपालन आवश्यकताएँ या लेगेसी सिस्टम के साथ शुरू नहीं करता। यह दर्शन एक दिशा है, स्विच नहीं। कई टीमें इसे धीरे‑धीरे अपनाती हैं—शेयरड ऑन‑कॉल, बेहतर ऑब्ज़रवबिलिटी, और स्पष्ट सेवा सीमाओं से शुरुआत कर के—फिर पूरा end‑to‑end स्वामित्व लेती हैं।
वर्नर वोगेल्स, अमेज़न के CTO, ने “You build it, you run it” वाक्यांश को लोकप्रिय बनाया जब वे बताते थे कि कैसे अमेज़न (और बाद में AWS) चाहती थी कि टीमें सॉफ़्टवेयर को एक प्रोजेक्ट के रूप में न देखें जिसे आगे फेंक दिया जाए, बल्कि एक सर्विस के रूप में देखें जिसे आप ऑपरेट करते हैं।
मुख्य बदलाव तकनीकी के साथ‑साथ मनोवैज्ञानिक भी था। जब टीम जानती है कि उसे फेल्यर्स के लिये पेज किया जाएगा, तो डिजाइन निर्णय बदल जाते हैं। आप सेंसिबल डिफ़ॉल्ट्स, स्पष्ट अलर्टिंग, ग्रेसफुल डीग्रेडेशन और ऐसे डिप्लॉय पाथ की परवाह करेंगे जिन्हें आप रोलबैक कर सकें। यानी, बिल्डिंग में जीवन के गंदे हिस्सों की योजना भी शामिल होती है।
AWS‑युग का सर्विस सोच ने विश्वसनीयता और गति को गैर‑बाजार्य बना दिया। क्लाउड ग्राहक उम्मीद करते हैं कि APIs चौबीसों घंटे उपलब्ध हों, और सुधार लगातार आएँ—क्वार्टरली "बिग रिलीज" की तरह नहीं।
उस दबाव ने प्रोत्साहित किया:
यह दर्शन व्यापक DevOps मूवमेंट से ओवरलैप करता है: “dev” और “ops” के बीच की खाई को बंद करें, हैंडऑफ़्स घटाएँ, और आउटपुट (उपलब्धता, लेटेंसी, सपोर्ट लोड) को डेवेलपमेंट लूप का हिस्सा बनाएं। यह छोटे स्वायत्त टीमों के विचार से भी मेल खाता है जो स्वतंत्र रूप से शिप कर सकें।
Amazon के दृष्टिकोण को टेम्पलेट की तरह कॉपी करना आकर्षक है। पर “You Build It, You Run It” एक दिशा है, सख्त ऑर्ग चार्ट नहीं। आपकी टीम का आकार, नियम‑व्यवस्था, उत्पाद परिपक्वता और अपटाइम आवश्यकताएँ अनुकूलन मांग सकती हैं—शेयरड ऑन‑कॉल रोटेशन, प्लेटफ़ॉर्म सपोर्ट, या चरणबद्ध अपनाना।
यदि आप इस माइंडसेट को कार्य में बदलने का व्यावहारिक तरीका चाहते हैं, तो /blog/how-to-adopt-you-build-it-you-run-it-step-by-step पर जाएँ।
“You Build It, You Run It” वास्तव में स्वामित्व के बारे में एक कथन है। अगर आपकी टीम कोई सेवा शिप करती है, तो आपकी टीम इसके वास्तविक दुनिया में व्यवहार के लिए जिम्मेदार है—सिर्फ रिलीज़‑डे पर टेस्ट पास होने तक नहीं।
एक सेवा चलाने का मतलब है एंड‑टू‑एंड परिणामों की परवाह करना:
साधारण सप्ताह में, “run it” हीरोइक्स से कम और रूटीन ऑपरेशन्स से ज्यादा जुड़ा होता है:
यह मॉडल तभी काम करता है जब जवाबदेही का अर्थ हो “हम फिक्स का जिम्मा लेते हैं,” न कि “किसी को दंडित करने की खोज।” जब कुछ टूटता है, तो लक्ष्य यह समझना है कि सिस्टम में क्या कमी थी—गुम अलर्ट, अस्पष्ट लिमिट्स, रिस्की डिप्लॉयमेंट—और उन स्थितियों को सुधारना।
जब सर्विसेज अस्पष्ट हों तो स्वामित्व गँदला हो जाता है। सर्विस बॉउंड्रीज़ (यह क्या करती है, किस पर निर्भर है, क्या वादा करती है) और एक नामित ओनिंग टीम असाइन करें। यह स्पष्टता हैंडऑफ़ घटाती है, घटना प्रतिक्रिया तेज़ बनाती है, और जब विश्वसनीयता और फीचर्स टकराते हैं तो प्राथमिकताएँ स्पष्ट कर देती है।
ऑन‑कॉल “You Build It, You Run It” का केंद्र है क्योंकि यह फीडबैक लूप को बंद करता है। जब वही टीम जो बदलाव शिप करती है ऑपरेशनल प्रभाव भी महसूस करती है (लेटेंसी स्पाइक्स, फ्लॉप्ड डिप्लॉय्स, कस्टमर शिकायतें), तो प्राथमिकताएँ स्पष्ट हो जाती हैं: रिलायबिलिटी का काम अब “किसी और की समस्या” नहीं रहती, और ज्यादा शिप करने का सबसे तेज़ रास्ता अक्सर सिस्टम को शांत करना होता है।
हेल्दी ऑन‑कॉल ज्यादातर पूर्वानुमेयता और समर्थन के बारे में है।
सिस्टम को हर खराबी पर पेज करने से रोकने के लिए गंभीरता स्तर परिभाषित करें।
सरल नियम: अगर किसी को जगाने से नतीजा नहीं बदलेगा, तो उसे टिकट बनाइए, पेज नहीं।
ऑन‑कॉल सज़ा नहीं है; यह एक संकेत है। हर शोरदार अलर्ट, दोहराई जाने वाली विफलता, या मैन्युअल फिक्स इंजीनियरिंग वर्क में फीडबैक होना चाहिए: बेहतर अलर्ट्स, ऑटोमेशन, सुरक्षित रिलीज़, और सिस्टम बदलाव जो पेजिंग की जरूरत को ही खत्म कर दें।
अगर “you run it” असली है, तो टीमों को बिना बहस के रिलायबिलिटी पर बात करने का साझा तरीका चाहिए। यही SLIs, SLOs, और एरर‑बजेट देते हैं: स्पष्ट लक्ष्य और टिक‑बैलेंस्ड ट्रेड‑ऑफ तेज़ी से आगे बढ़ने और स्थिर रखने के बीच।
याद रखने का उपयोगी तरीका: SLI = मेट्रिक, SLO = लक्ष्य, SLA = बाहरी प्रतिज्ञा।
अच्छे SLIs विशिष्ट होते हैं और उपयोगकर्ता अनुभव से जुड़े होते हैं, जैसे:
एरर बजेट वह मात्रा है जिसे आप अपने SLO को पूरा रखते हुए ‘‘खर्च’’ कर सकते हैं (उदा., 99.9% उपलब्धता पर मासिक एरर बजेट 0.1% डाउन‑टाइम)।
जब सेवा स्वस्थ होती है और आप बजट के भीतर हैं, तो टीमें अधिक डिलीवरी रिस्क ले सकती हैं। जब बजट जल्दी जल रहा हो, तो रिलायबिलिटी वर्क प्राथमिकता पाता है।
SLOs विश्वसनीयता को योजना‑इन्पुट बनाते हैं। अगर आपका एरर बजेट कम है, तो अगला स्प्रिंट रेट‑लिमिटिंग, सुरक्षित रोलआउट, या फ्लीकी निर्भरताओं को ठीक करने पर जोर दे सकता है—क्योंकि SLO चूकने की स्पष्ट लागत है। अगर बजट पर्याप्त है, तो आप निश्चिंत होकर प्रोडक्ट वर्क प्राथमिकता कर सकते हैं।
“You build it, you run it” तभी काम करेगा जब प्रोडक्शन पर शिप करना रोज़मर्रा का काम हो—न कि हाई‑स्टेक इवेंट। लक्ष्य लॉन्च से पहले अनिश्चितता को कम करना और लॉन्च के बाद ब्लास्ट रेडियस को सीमित करना है।
किसी सेवा को “रेडी” मानने से पहले टीमें आमतौर पर कुछ ऑपरेशनल बेसिक्स चाहिए:
सबको एक साथ रिलीज करने के बजाय, प्रोग्रेसिव डिलीवरी प्रभाव को सीमित करती है:
अगर आपकी टीम रोलबैक को मानक क्षमता मान रही है, तो उसे पहले‑कक्षा क्षमता के रूप में ट्रीट करें: जितना तेज़ आप सुरक्षित रूप से रिवर्ट कर सकenge, उतना ही वास्तविक “you run it” व्यवहारिक होगा।
दो परीक्षण “अज्ञात अज्ञातों” को कम करते हैं:
इसे हल्का रखें: अपने रेपो या टिकट टेम्पलेट में एक पृष्ठीय चेकलिस्ट (उदा., “Observability,” “On‑call readiness,” “Data protection,” “Rollback plan,” “Capacity tested,” “Runbooks linked”)। “नॉट रीडी” को सामान्य स्थिति बनाना बेहतर है—प्रोडक्शन में सीखने से बेहतर।
घटनाएँ वह जगह हैं जहाँ “you run it” वास्तविक बनता है: सेवा प्रभावित होती है, ग्राहक नोटिस करते हैं, और टीम को तेज़ी से स्पष्ट रूप से रिस्पॉन्ड करना होता है। लक्ष्य हीरोइक्स नहीं—एक दोहराने योग्य वर्कफ़्लो है जो प्रभाव घटाए और सुधार उत्पन्न करे।
अधिकांश टीमें एक ही चरणों पर पहुँचती हैं:
यदि आप इस फ्लो के लिए व्यावहारिक टेम्पलेट चाहते हैं, तो हल्का चेकलिस्ट तैयार रखें (देखें /blog/incident-response-checklist)।
ब्लेमलेस पोस्टमॉर्टम का मतलब यह नहीं कि “किसी ने गलत नहीं किया।” इसका मतलब यह है कि आप उस पर फोकस करते हैं कि सिस्टम और प्रक्रिया ने कैसे उस गलती को प्रोडक्शन तक आने दिया, न कि व्यक्तियों को शर्मिंदा करना। इससे लोग जल्दी विवरण साझा करते हैं, जो सीखने के लिए जरूरी है।
दस्तावेज़ करें:
अच्छे पोस्टमॉर्टम ठोस, ओन्ड फॉलो‑अप के साथ समाप्त होते हैं, आमतौर पर चार बकेट में: टूलिंग सुधार (बेहतर अलर्ट/डैशबोर्ड), टेस्ट्स (रिग्रेशन और किनारे‑केस), ऑटोमेशन (सुरक्षित डिप्लॉय/रोलबैक, गार्डरिल्स), और डॉक्यूमेंटेशन (रनबुक्स, स्पष्ट ऑपरेशनल स्टेप्स)। मालिक और ड्यू‑डेट असाइन करें—नहीं तो सीख केवल सैद्धांतिक रहती है।
टूलिंग वह लीवर है जो “You Build It, You Run It” को टिकाऊ बनाती है—पर यह असली स्वामित्व का विकल्प नहीं हो सकती। अगर टीम ऑपरेशन्स को “किसी और की समस्या” मानती है, तो सबसे शानदार डैशबोर्ड भी केवल अराजकता का दस्तावेज बनेगा। अच्छे टूल त्रुटि को कम करते हैं: वे सही काम (ऑब्ज़र्व करना, रिस्पॉन्ड करना, सीखना) करना गलत काम (अनुमान लगाना, दोषारोपण, अनदेखा करना) से आसान बनाते हैं।
कम से कम, सेवा ओनर्स को एक सुसंगत तरीका चाहिए जिससे वे अपनी सॉफ़्टवेयर के प्रोडक्शन व्यवहार को देख सकें और जब कुछ गलत हो तो तेजी से कार्रवाई कर सकें:
यदि आपकी मॉनिटरिंग कहानी बिखरी हुई है, तो टीमें शिकार करने में अधिक समय खर्च करती हैं बजाय फिक्स करने के। एक एकीकृत ऑब्ज़रवबिलिटी अप्रोच मदद करती है; देखें /product/observability।
जैसे-जैसे संगठन बढ़ता है, “यह किसका है?” एक रिस्क बन जाता है। एक सर्विस कैटलॉग (या आंतरिक डेवलपर पोर्टल) इस समस्या को हल करता है: ओनरशिप और ऑपरेशनल संदर्भ एक जगह रखें: टीम नाम, ऑन‑कॉल रोटेशन, एस्केलेशन पाथ, रनबुक्स, निर्भरताएँ, और डैशबोर्ड के लिंक।
कुंजी है ओनरशिप मेटाडेटा जो अपडेट रहता है। इसे वर्कफ़्लो का हिस्सा बनाएं: नई सर्विस लाइव नहीं जा सकती बिना ओनर के, और ओनरशिप परिवर्तन कोड परिवर्तन की तरह (रिव्यू, ट्रैक) माना जाए।
सबसे अच्छे सेटअप टीमों को स्वस्थ व्यवहार की ओर धकेलते हैं: रनबुक टेम्पलेट्स, SLO‑लिंकेड ऑटोमेटेड अलर्ट, और ऐसे डैशबोर्ड जो कुछ सेकंड में “क्या उपयोगकर्ता प्रभावित हैं?” का उत्तर देते हैं। पर मानव सिस्टम अभी भी मायने रखता—टीमों को इन टूल्स को बनाए रखने, अलर्ट्स छाँटने, और लगातार ऑपरेटिंग तरीकों को सुधारने के लिए समय चाहिए।
प्लेटफ़ॉर्म टीमें “You Build It, You Run It” को जीना आसान बनाती हैं। उनका काम सभी के लिए प्रोडक्शन चलाना नहीं है—बल्कि वे एक अच्छी तरह प्रकाशित पाथ ("paved roads") प्रदान करते हैं ताकि प्रोडक्ट टीमें हर स्प्रिंट नया ऑपरेशंस चक्र न बनाना पड़े।
अच्छा प्लेटफ़ॉर्म ऐसे डिफ़ॉल्ट देता है जो गलती से करना कठिन और अपनाना आसान हो:
गार्डरिल्स जोखिमपूर्ण व्यवहार को रोकें बिना शिपिंग ब्लॉक किए—"डिफ़ॉल्ट रूप से सुरक्षित" सोचें बजाय "टिकट खोलो और इंतज़ार करो।"
प्लेटफ़ॉर्म टीमें साझा सेवाएँ चला सकती हैं—बिना प्रोडक्ट सेवाओं का स्वामित्व ले लिए।
सीमा सरल है: प्लेटफ़ॉर्म टीम प्लेटफ़ॉर्म की अपटाइम और सपोर्ट की जिम्मेदार है; प्रोडक्ट टीमें यह तय करती हैं कि वे प्लेटफ़ॉर्म का उपयोग कैसे कर के अपने लक्ष्य प्राप्त करती हैं।
जब टीमों को पहले दिन CI/CD, auth, या secrets की विशेषज्ञता की ज़रूरत नहीं होती, तो वे सर्विस के व्यवहार और उपयोगकर्ता प्रभाव पर ध्यान केंद्रित कर सकती हैं।
नमूने जो व्यस्त‑काम हटाते हैं:
फल यह है: तेज़ डिलीवरी और कम "कस्टम ऑप्स स्नोफ्लेक्स", जबकि मूल वादा बना रहता है: जो टीम सर्विस बनाती है वही उसे चलाती है।
“You build it, you run it” विश्वसनीयता और गति सुधार सकता है—पर तभी जब संगठन टीम के चारों ओर शर्तें बदले। कई विफलताएँ इस तरह दिखती हैं: स्लोगन अपनाया गया पर सहायक आदते नहीं बदलीं।
कुछ पैटर्न बार‑बार उभरते हैं:
कुछ परिस्थितियाँ अनुकूल दृष्टिकोण मांगती हैं:
यह दर्शन सबसे जल्दी तब नाकाम होता है जब रिलायबिलिटी वर्क को "अतिरिक्त" माना जाए। नेतृत्व को स्पष्ट रूप से क्षमता आरक्षित करनी चाहिए:
बिना उस सुरक्षा के, ऑन‑कॉल टैक्स बन जाता है—न कि वह फीडबैक लूप जो सिस्टम को बेहतर बनाता है।
इसे रोल‑आउट करना सबसे अच्छा है एक चरणबद्ध परिवर्तन के रूप में, न कि कंपनी‑वाइड घोषणा के रूप में। छोटा शुरू करें, स्वामित्व को दृश्य बनाएं, और फिर विस्तार करें।
एक एकल, अच्छी तरह सीमाबद्ध सेवा चुनें (आदर्श रूप से स्पष्ट उपयोगकर्ताओं और प्रबंधनीय जोखिम वाली)।
परिभाषित करें:
कुंजी: जो टीम बदलाव शिप करती है वही उस सेवा के ऑपरेशनल नतीजों के लिए भी जिम्मेदार हो।
अधिक सेवाओं पर बढ़ने से पहले सुनिश्चित करें कि पायलट टीम हीरोइक्स के बिना ऑपरेट कर सके:
कुछ संकेतक उपयोग करें जो दिखाएँ कि स्वामित्व शिपिंग और स्थिरता में सुधार ला रहा है:
अगर आप “you build it, you run it” अपना रहे हैं और साथ ही डिलीवरी तेज़ करना चाह रहे हैं, तो बाधा अक्सर वही रहती है: आइडिया → प्रोडक्शन‑रेडी सेवा, स्पष्ट स्वामित्व और सुरक्षित रोलबैक स्टोरी तक पहुँचना।
Koder.ai एक vibe‑coding प्लेटफ़ॉर्म है जो टीमों को चैट इंटरफेस के जरिये वेब, बैकएंड और मोबाइल ऐप बनाने में मदद करता है (वेब पर React, बैकएंड में Go + PostgreSQL, मोबाइल के लिए Flutter)। सेवा स्वामित्व की ओर झुकाव रखने वाली टीमों के लिए कुछ फीचर ऑपरेटिंग मॉडल के साथ सीधे मेल खाते हैं:
इस सप्ताह अपना पायलट सेवा चुनें और 60‑मिनट का किकऑफ शेड्यूल करें ताकि पहला SLO, ऑन‑कॉल रोटेशन, और रनबुक मालिक सेट हों। अगर आप इसको सपोर्ट करने वाली टूलिंग (शिपिंग, रोलबैक, और स्वामित्व के चारों ओर वर्कफ़्लो) का मूल्यांकन कर रहे हैं, तो Koder.ai के फ्री, प्रो, बिज़नेस और एंटरप्राइज़ टियर देखें—होस्टिंग, डिप्लॉयमेंट और कस्टम डोमेन जैसे विकल्पों के साथ।
इसका मतलब है कि जो टीम किसी सेवा को डिज़ाइन, बिल्ड और डिप्लॉय करती है, वही लाइव होने के बाद भी उसकी जिम्मेदारी उठाती है: मॉनिटरिंग, ऑन‑कॉल रिस्पॉन्स, घटनाओं के अनुवर्ती काम और विश्वसनीयता में सुधार।
यह एक जिम्मेदारी मॉडल है (स्पष्ट स्वामित्व), न कि सिर्फ कोई टूल चुनना या नौकरी‑टाइटल बदलना।
इसका मतलब यह नहीं कि हर इंजीनियर को पूरा‑समय इंफ्रा विशेषज्ञ बनना होगा।
यह अर्थ रखता है:
जब अलग ops टीम होती है तो फ़ीडबैक देर से मिलता है और ज़िम्मेदारी धुंधली हो जाती है: डेवलपर्स प्रोडक्शन दर्द महसूस नहीं करते, और ops के पास हालिया बदलावों का संदर्भ नहीं होता।
एंड‑टू‑एंड स्वामित्व आम तौर पर सुधारता है:
“Run it” में आम तौर पर शामिल होता है:
मानवसुलभ ऑन‑कॉल के लिए शुरूआत के सिद्धांत:
अच्छा ऑन‑कॉल सिस्टम अगली महीने पेजेस घटाने का लक्ष्य रखता है, न कि हीरोइक्स को सामान्य बनाना।
सरल नियम: अगर किसी को जगाने से नतीजा नहीं बदलेगा, तो उसे टिकट बनाइए, पेज नहीं।
व्यावहारिक रूप से:
वे SLI/SLO/एरर‑बजेट reliability को मापने और व्यापार‑कैलिब्रेट करने के लिए टूल देते हैं:
जब बजट तेज़ी से जल रहा हो तो रिलायबिलिटी वर्क प्राथमिकता पाता है; बजट अच्छा हो तो आप रिस्क लेकर फीचर शिप कर सकते हैं।
रिलीज़ प्रैक्टिसेज जो मॉडल को टिकाऊ बनाती हैं:
घटनाओं के लिए दोहराने योग्य वर्कफ़्लो:
फिर ब्लेमलेस पोस्टमॉर्टम लिखें जो सिस्टम और प्रोसेस गैप्स पर फोकस करे, और फॉलो‑अप हो जो:
प्लेटफ़ॉर्म टीमों का रोल “पेव्ड रोड्स” और टेम्पलेट्स देना है ताकि प्रोडक्ट टीमें हर बार ऑपरेशन्स को फिर से न खोजें, परन्तु प्लेटफ़ॉर्म स्वामित्व प्रोडक्ट स्वामित्व को न छीनें।
व्यवहारिक सीमा:
