23 दिस॰ 2025·8 मिनट
छोटी टीमों के लिए त्रुटि बजट: वास्तविक SLOs और रूटीन
छोटी टीमों के लिए त्रुटि बजट सीखें: शुरुआती उत्पादों के लिए वास्तविक SLO सेट करें, तय करें कौन से इन्सिडेंट मायने रखते हैं, और एक सरल साप्ताहिक विश्वसनीयता रूटीन चलाएँ।
छोटी टीमों के लिए त्रुटि बजट सीखें: शुरुआती उत्पादों के लिए वास्तविक SLO सेट करें, तय करें कौन से इन्सिडेंट मायने रखते हैं, और एक सरल साप्ताहिक विश्वसनीयता रूटीन चलाएँ।
छोटी टीमें तेज़ी से शिप करती हैं क्योंकि उन्हें करना पड़ता है। जोखिम आमतौर पर कोई एक बड़ा आउटेज नहीं होता—यह वही छोटी विफलता है जो बार-बार होती रहती है: कभी-कभी फेल होने वाला साइनअप, कभी-कभार फेल होने वाला चेकआउट, या कोई डिप्लॉय जो कभी-कभार एक स्क्रीन तोड़ देता है। हर बार यह घंटे चुरा लेता है, विश्वास को घटाता है, और रिलीज़ को सिक्का उछाल की तरह बना देता है।
त्रुटि बजट छोटी टीमों को तेज़ी बनाए रखने का एक सरल तरीका देता है बिना यह मानने के कि भरोसेमंदी "बस हो जाएगी"।
SLO (सेवा स्तर उद्देश्य) उपयोगकर्ता अनुभव के बारे में एक स्पष्ट वादा है, जिसे एक समय विंडो में संख्या के रूप में व्यक्त किया जाता है। उदाहरण: सफल चेकआउट कम से कम 99.5% हों पिछले 7 दिनों में। त्रुटि बजट उस वादे के भीतर की "खराब" चीज़ों की अनुमति है। यदि आपका SLO 99.5% है, तो आपका साप्ताहिक बजट 0.5% फेल हुए चेकआउट हैं।
यह परफेक्शन या अपटाइम थिएटर के बारे में नहीं है। यह भारी प्रक्रिया, अनंत बैठकें, या कोई स्प्रेडशीट नहीं है जिसे कोई अपडेट नहीं करता। यह तय करने का एक तरीका है कि "काफी अच्छा" क्या है, जब आप भटक रहे हों तो उसे नोट करना, और अगला कदम शांत तरीके से लेना।
छोटे से शुरू करें: 1 से 3 उपयोगकर्ता-सामना करने वाले SLO चुनें जो आपके सबसे महत्वपूर्ण यात्राओं से जुड़े हों, उन्हें उन संकेतों से मापें जो आपके पास पहले से हैं (errors, latency, failed payments), और एक छोटा साप्ताहिक रिव्यू करें जहाँ आप बजट बर्न देखें और एक फॉलो-अप कार्रवाई चुनें। आदत टूलिंग से ज़्यादा मायने रखती है।
भरोसेमंदी को एक डाइट प्लान की तरह सोचें। आपको परफेक्ट दिनों की ज़रूरत नहीं है। आपको एक लक्ष्य चाहिए, उसे मापने का तरीका चाहिए, और असली जीवन के लिए थोड़ी छूट चाहिए।
SLI (सेवा स्तर संकेतक) वह संख्या है जिसे आप देखते हैं, जैसे “सफल रिक्वेस्ट का %” या “p95 पेज लोड समय 2 सेकंड से कम।” SLO उस संख्या का लक्ष्य है, जैसे “99.9% रिक्वेस्ट सफल हों।” त्रुटि बजट यह है कि आप कितनी बार SLO से चूक सकते हैं और फिर भी ट्रैक पर माने जाएँ।
उदाहरण: अगर आपका SLO 99.9% उपलब्धता है, तो आपका बजट 0.1% डाउनटाइम है। एक सप्ताह (10,080 मिनट) में 0.1% लगभग 10 मिनट होता है। इसका मतलब यह नहीं कि आपको इन 10 मिनटों का उपयोग करने की कोशिश करनी चाहिए। इसका मतलब है कि जब आप इसे खर्च करते हैं, तो आप जानबूझकर विश्वसनीयता को गति, प्रयोगों, या फीचर काम के बदले लगा रहे हैं।
यह मूल्य है: यह विश्वसनीयता को रिपोर्टिंग अभ्यास बनने की बजाय निर्णय उपकरण बना देता है। अगर आप बुधवार तक अधिकांश बजट जला चुके हैं, तो आप जोखिमभरे बदलाव रोक देते हैं और जो टूट रहा है उसे ठीक करते हैं। अगर आप बहुत कम खर्च कर रहे हैं, तो आप अधिक आत्मविश्वास के साथ शिप कर सकते हैं।
सब कुछ समान SLO की जरूरत नहीं है। एक सार्वजनिक कस्टमर-फेसिंग ऐप को अक्सर 99.9% चाहिए होगा। एक आंतरिक एडमिन टूल अक्सर ढीला हो सकता है क्योंकि कम लोग नोटिस करते हैं और प्रभाव छोटा होता है।
सब कुछ मापने से शुरुआत मत करें। उन पलों की रक्षा करके शुरू करें जहाँ उपयोगकर्ता यह तय करता है कि आपका प्रोडक्ट काम कर रहा है या नहीं।
1 से 3 उपयोगकर्ता यात्राएँ चुनें जो सबसे अधिक भरोसा ले जाती हैं। अगर वे ठोस हैं, तो बाकी समस्याएँ छोटी लगेंगी। अच्छे उम्मीदवार हैं पहली छुवन (साइनअप या लॉगिन), पैसे का पल (चेकआउट या अपग्रेड), और मुख्य क्रिया (publish, create, send, upload, या कोई महत्वपूर्ण API कॉल)।
साफ़ शब्दों में लिखें कि "सफलता" का क्या अर्थ है। तकनीकी शब्दावली जैसे “200 OK” से बचें जब तक आपके उपयोगकर्ता डेवलपर्स न हों।
कुछ उदाहरण जिन्हें आप अनुकूलित कर सकते हैं:
ऐसा माप विंडो चुनें जो यह मैच करे कि आप कितनी तेज़ी से चीज़ें बदलते हैं। यदि आप दैनिक शिप करते हैं और त्वरित फीडबैक चाहते हैं तो 7-दिन की विंडो काम करती है। यदि रिलीज़ कम बार होते हैं या आपका डेटा शोरदार है तो 28-दिन का विंडो शांत रहता है।
प्रारंभिक उत्पादों की सीमाएँ होती हैं: ट्रैफिक कम हो सकता है (एक खराब डिप्लॉय आपके नंबर को विकृत कर सकता है), फ्लो जल्दी बदलते हैं, और टेलीमेट्री अक्सर पतली होती है। यह ठीक है। सरल काउंट्स से शुरू करें (प्रयास बनाम सफलता)। यात्रा खुद बदलना बंद करने के बाद परिभाषाएँ कड़ा करें।
आज जो आप शिप कर रहे हैं वही लेकर शुरू करें, उस पर नहीं जो आप चाहते हैं। एक या दो सप्ताह के लिए हर प्रमुख यात्रा के लिए बेसलाइन कैप्चर करें: यह कितनी बार सफल होती है और कितनी बार फेल होती है। यदि आपके पास रीयल ट्रैफिक है तो उसका उपयोग करें। नहीं तो अपने परीक्षण, सपोर्ट टिकट और लॉग का उपयोग करें। आप "सामान्य" का मोटा चित्र बना रहे हैं।
आपका पहला SLO वह होना चाहिए जिसे आप अधिकांश हफ्तों में पूरा कर सकें जबकि आप शिप भी कर रहे हों। यदि आपका बेसलाइन सफलता दर 98.5% है, तो 99.9% मत रखें और आशा करें। 98% या 98.5% सेट करें, फिर बाद में कड़ा करें।
लेटेंसी प्रलोभन देती है, लेकिन शुरुआती चरण में यह भ्रमित कर सकती है। बहुत सी टीमों को पहले सफलता-रेट SLO से अधिक लाभ मिलता है (रिक्वेस्ट बिना त्रुटि पूरे हों)। जब उपयोगकर्ता स्पष्ट रूप से इसे महसूस करें और आपके पास स्थिर डेटा हो तो लेटेंसी जोड़ें।
एक सहायक फॉर्मेट हर यात्रा के लिए एक लाइन: कौन, क्या, लक्ष्य, और समय विंडो।
पैसे और भरोसे के क्षणों के लिए विंडो लंबा रखें (बिलिंग, ऑथ)। रोज़मर्रा के फ्लो के लिए विंडो छोटा रखें। जब आप SLO आसानी से पूरा कर सकें, तो उसे थोड़ा बढ़ाएँ और जारी रखें।
छोटी टीमें तब बहुत समय गंवाती हैं जब हर झटका फायर ड्रिल बन जाता है। लक्ष्य सरल है: उपयोगकर्ता-दृश्य दर्द बजट खर्च करता है; बाकी सब सामान्य काम के रूप में निपटता है।
कुछ इन्सिडेंट टाइप काफी हैं: पूरा आउटेज, आंशिक आउटेज (एक प्रमुख फ्लो टूट गया), degraded performance (काम तो कर रहा है पर धीमा महसूस होता है), खराब डिप्लॉय (रिलीज़ से फेल होना), और डेटा इश्यू (गलत/गायब/डुप्लिकेट)।
स्केल छोटा रखें और हर बार उपयोग करें।
निर्धार करें कि क्या बजट के खिलाफ गिना जाएगा। उपयोगकर्ता-दृश्य विफलताओं को खर्च मानें: टूटा साइनअप या चेकआउट, उपयोगकर्ता द्वारा महसूस किए गए टाइमआउट, ऐसे 5xx स्पाइक्स जो यात्राओं को रोकते हैं। यदि आपने योजना बनाई हुई मेंटेनेंस की सूचना दे दी और ऐप अपेक्षित व्यवहार दिखाए, तो वह गिना नहीं जाना चाहिए।
एक नियम ज्यादातर बहस खत्म कर देता है: यदि कोई वास्तविक बाहरी उपयोगकर्ता नोटिस करेगा और एक संरक्षित यात्रा पूरा नहीं कर पाएगा, तो यह गिना जाता है। अन्यथा नहीं।
यह नियम सामान्य ग्रे क्षेत्रों को भी कवर करता है: किसी थर्ड-पार्टी आउटेज को केवल तब गिनें जब वह आपकी उपयोगकर्ता यात्रा तोड़ दे, कम ट्रैफिक घंटे भी गिने जाते हैं यदि उपयोगकर्ता प्रभावित होते हैं, और आंतरिक-केवल टेस्टर्स गिने नहीं जाते जब तक कि डॉगफूडिंग आपका प्राथमिक उपयोग न हो।
लक्ष्य परफेक्ट मापन नहीं है। यह एक साझा, दोहराने योग्य संकेत है जो बताता है कि विश्वसनीयता महंगी होती जा रही है या नहीं।
हर SLO के लिए एक सत्य स्रोत चुनें और उसी पर टिके रहें: एक मॉनिटरिंग डैशबोर्ड, ऐप लॉग, एक सिंथेटिक चेक जो एक एंडपॉइंट हिट करे, या एक सिंगल मेट्रिक जैसे सफल चेकआउट प्रति मिनट। यदि बाद में आप माप विधि बदलते हैं, तो तारीख लिख दें और उसे रीसेट मानें ताकि आप सेव और सेब की तुलना न कर रहे हों।
अलर्ट को हर झटके पर नहीं बल्कि बजट बर्न पर आधारित रखें। एक छोटा स्पाइक परेशान कर सकता है, पर अगर उसने महीने के बजट को थोड़ा ही छुआ है तो किसी को जगाना नहीं चाहिए। एक सरल पैटर्न काम करता है: “फास्ट बर्न” पर अलर्ट (आप एक दिन में महीने का बजट बर्न करने पर हैं) और “स्लो बर्न” पर नरम अलर्ट (सप्ताह में)।
एक छोटा रिलायबिलिटी लॉग रखें ताकि आप याद पर निर्भर न रहें। हर इन्सिडेंट के लिए एक लाइन काफी है: तारीख और अवधि, उपयोगकर्ता प्रभाव, संभावित कारण, आपने क्या बदला, और एक फॉलो-अप मालिक और ड्यू डेट।
उदाहरण: दो-व्यक्ति की टीम एक नया API लॉन्च करती है। उनका SLO है “99.5% सफल रिक्वेस्ट”, जो एक काउंटर से मापा जाता है। एक खराब डिप्लॉय ने सफलता 97% तक घटा दी 20 मिनट के लिए। फास्ट-बर्न अलर्ट ट्रिगर हुआ, उन्होंने रोलबैक किया, और फॉलो-अप है "डिप्लॉय से पहले एक कैनेरी चेक जोड़ें"।
आपको बड़ा प्रोसेस नहीं चाहिए। आपको एक छोटी आदत चाहिए जो विश्वसनीयता को दिखती रहे बिना बिल्ड समय चुरा लिए। 20 मिनट का चेक-इन काम करता है क्योंकि यह सब कुछ एक सवाल में बदल देता है: क्या हम अपनी योजना से तेज़ी से विश्वसनीयता खर्च कर रहे हैं?
हर हफ्ते वही कैलेंडर स्लॉट इस्तेमाल करें। एक साझा नोट रखें जिसे आप जोड़ते जाएँ (पुनः लेखना नहीं)। निरंतरता विवरण से ज़्यादा मायने रखती है।
एक सरल एजेंडा:
फॉलो-अप और प्रतिबद्धताओं के बीच, सप्ताह के लिए अपना रिलीज़ नियम तय करें और उसे साधारण रखें:
यदि आपका साइनअप फ्लो दो छोटे आउटेज का सामना करता है और अधिकांश बजट जला देता है, तो आप केवल साइनअप-संबंधी बदलाव फ्रीज कर सकते हैं जबकि बिना संबंधी काम शिप करते रहें।
एक त्रुटि बजट तभी मायने रखता है जब वह अगले हफ्ते आपके काम को बदल दे। मकसद परफेक्ट अपटाइम नहीं है; यह स्पष्ट तरीका है यह तय करने का: क्या हम फीचर शिप करें, या विश्वसनीयता कर्ज चुकाएँ?
एक नीति जिसे आप ज़ुबानी कह सकें:
यह सज़ा नहीं है। यह एक सार्वजनिक व्यापार है ताकि उपयोगकर्ता बाद में उसकी कीमत न चुकाएँ।
जब आप धीमे हों, तो अस्पष्ट टास्क जैसे “stability सुधारें” से बचें। ऐसे बदलाव चुनें जो अगले नतीजे को बदल दें: एक गार्डरेल जोड़ें (timeouts, input validation, rate limits), एक टेस्ट सुधारें जो बग पकड़ता, रोलबैक आसान बनाएं, शीर्ष एरर स्रोत ठीक करें, या एक अलर्ट जोड़ें जो उपयोगकर्ता यात्रा से जुड़ा हो।
रिपोर्टिंग को बदनाम करने से अलग रखें। तेज़ इन्सिडेंट लिखावटों को पुरस्कृत करें, भले ही विवरण गंदे हों। एकमात्र वास्तव में खराब इन्सिडेंट रिपोर्ट वह है जो देर से आती है, जब कोई याद नहीं कर पाता कि क्या बदला गया था।
एक सामान्य जाल है दिन एक पर सोने-चाँदी जैसा SLO (99.99% शानदार लगता है) सेट कर देना और जब वास्तविकता मिले तो चुपचाप उसे नज़रअंदाज़ कर देना। आपकी शुरुआती SLO वह होनी चाहिए जिसे आपके मौजूदा लोग और टूल मिलकर पूरा कर सकें, वरना वह बैकग्राउंड शोर बन जाएगी।
एक और गलती गलत चीज़ मापना है। टीमें पांच सर्विस और एक डेटाबेस ग्राफ़ देखती हैं, पर उस यात्रा को मिस कर देती हैं जिसे उपयोगकर्ता असल में महसूस करता है: साइनअप, चेकआउट, या "save changes"। यदि आप उपयोगकर्ता के नज़रिये से एक वाक्य में SLO समझा नहीं सकते, तो वह शायद बहुत आंतरिक है।
अलर्ट थकान उस एक व्यक्ति को जलाकर रख देती है जो प्रोडक्शन ठीक कर सकता है। यदि हर छोटे स्पाइक पर कोई पेज हो रहा है, तो पेजिंग सामान्य बन जाएगी और असली आग बुझी हुई लग जाएगी। उपयोगकर्ता प्रभाव पर पेज करें। बाक़ी को दैनिक चेक पर रूट करें।
एक और मौन वध्य है असंगत काउंटिंग। एक हफ्ता आप दो मिनट की स्लोडाउन को इन्सिडेंट मानते हैं, अगले हफ्ते नहीं। तब बजट बहस बन जाता है बजाय संकेत के। नियम एक बार लिखें और समान रूप से लागू रखें।
सहायक गार्डरेल:
यदि एक डेپلॉय लॉगिन को 3 मिनट के लिए तोड़ता है, तो हर बार उसे गिनो, भले ही जल्दी ठीक हो गया हो। निरंतरता वही चीज़ है जो बजट को उपयोगी बनाती है।
10 मिनट का टाइमर लगाएँ, एक साझा डॉक खोलें, और इन पाँच सवालों का जवाब दें:
यदि आप अभी माप नहीं कर सकते, तो एक प्रॉक्सी से शुरू करें जिसे आप जल्दी देख सकें: फेल्ड पेमेंट्स, 500 एरर, या “checkout” टैग वाले सपोर्ट टिकट। जब ट्रैकिंग सुधरे तो प्रॉक्सी बदलें।
उदाहरण: दो-व्यक्ति की टीम ने इस सप्ताह तीन "पासवर्ड रीसेट नहीं कर पा रहे" संदेश देखे। यदि पासवर्ड रीसेट एक संरक्षित यात्रा है, तो यह एक इन्सिडेंट है। वे एक छोटा नोट लिखते हैं (क्या हुआ, कितने उपयोगकर्ता, क्या किया) और एक फॉलो-अप चुनते हैं: रीसेट फेल्यर्स पर अलर्ट जोड़ना या retry जोड़ना।
Maya और Jon एक दो-व्यक्ति स्टार्टअप चलाते हैं और हर शुक्रवार शिप करते हैं। वे तेज़ चलते हैं, पर उनके पहले पेइंग उपयोगकर्ताओं को एक बात की परवाह है: क्या वे एक प्रोजेक्ट बना कर teammate को invite कर पाएँगे बिना टूटे?
पिछले हफ्ते उनका एक असली आउटेज हुआ: "Create project" एक खराब migration के बाद 22 मिनट तक फेल हुआ। उन्हें तीन बार "धीमा पर फंसना" भी हुआ जहाँ स्क्रीन 8–12 सेकंड स्पिन कर रही थी। उपयोगकर्ताओं ने शिकायत की, पर टीम बहस करती रही कि क्या स्लो का मतलब "डाउन" है।
उन्होंने एक यात्रा चुनी और उसे मापनयोग्य बनाया:
सोमवार को वे 20-मिनट रिव्यू चलाते हैं। वही समय, वही डॉक। वे चार सवालों के जवाब देते हैं: क्या हुआ, कितना बजट बर्न हुआ, क्या दोहराया, और कौन सा एकल बदलाव दोहराव रोकेगा।
विवाद आसानी से स्पष्ट हो गया: आउटेज और धीमे समय ने साप्ताहिक बजट का अधिकांश हिस्सा जला दिया। इसलिए अगले सप्ताह का "एक बड़ा फीचर" बन गया: "DB index जोड़ो, migrations को सुरक्षित बनाओ, और create-project फेल्यर्स पर अलर्ट जोड़ो।"
परिणाम परफेक्ट विश्वसनीयता नहीं था। परिणाम कम दोहराव वाली समस्याएँ थीं, स्पष्ट हाँ/न निर्णय, और कम रातों-रात घबराहट — क्योंकि उन्होंने पहले से तय कर रखा था कि "काफी खराब" का क्या अर्थ है।
एक उपयोगकर्ता यात्रा चुनें और उस पर एक साधारण विश्वसनीयता वादा करें। त्रुटि बजट तब सबसे अच्छा काम करते हैं जब वे उबाऊ और दोहराने योग्य हों, न कि परफेक्ट।
एक SLO और एक साप्ताहिक रूटीन से शुरू करें। यदि एक महीने बाद यह फिर भी आसान लगे तो दूसरा SLO जोड़ें। यदि यह भारी लगे तो इसे छोटा कर दें।
गणना सरल रखें (साप्ताहिक या मासिक)। लक्ष्य उस जगह के लिए यथार्थवादी रखें जहाँ आप अभी हैं। एक पृष्ठ का रिलायबिलिटी नोट लिखें जो बताए: SLO और उसे कैसे मापा जाता है, क्या इन्सिडेंट गिने जाएंगे, इस सप्ताह कौन ऑन-पॉइंट है, चेक-इन कब होता है, और जब बजट बहुत तेज़ी से जले तो आप डिफ़ॉल्ट रूप से क्या करते हैं।
यदि आप किसी प्लेटफ़ॉर्म पर बना रहे हैं जैसे Koder.ai (koder.ai), तो यह तेज़ इटरेशन को सुरक्षा आदतों के साथ जोड़ने में मदद कर सकता है, खासकर स्नैपशॉट्स और रोलबैक के मामले में, ताकि "पिछली अच्छी स्थिति में revert" एक सामान्य, अभ्यास की गई चाल बनी रहे।
लूप को तंग रखें: एक SLO, एक नोट, एक छोटा साप्ताहिक चेक-इन। लक्ष्य घटनाओं को समाप्त करना नहीं है। लक्ष्य जल्दी देखना, शांत निर्णय लेना, और उन कुछ चीज़ों की रक्षा करना है जिन्हें उपयोगकर्ता वास्तव में महसूस करते हैं।
एक SLO उपयोगकर्ता अनुभव के बारे में एक विश्वसनीयता वादा है, जिसे एक समय विंडो (जैसे 7 या 30 दिन) में मापा जाता है。
उदाहरण: 99.5% चेकआउट सफल हों पिछले 7 दिनों में।
एक त्रुटि बजट आपके SLO के भीतर की “खराब” चीज़ों की अनुमति है。
यदि आपका SLO 99.5% सफलता है, तो उस विंडो में आपका बजट 0.5% असफलताएँ हैं। यदि आप बजट बहुत तेज़ी से खर्च कर रहे हैं, तो आप जोखिम भरे बदलाव धीमे कर देते हैं और कारणों को ठीक करते हैं।
शुरुआत में 1–3 ऐसी यात्राएँ चुनें जिन्हें उपयोगकर्ता तुरंत महसूस करते हैं:
यदि ये भरोसेमंद हैं तो बाकी समस्याएँ छोटी लगती हैं और बाद में प्राथमिकता देना आसान होता है।
एक ऐसा बेसलाइन चुनें जिसे आप अधिकांश हफ्तों में सच मानकर पूरा कर सकें。
यदि आज आप 98.5% पर हैं, तो 98–98.5% से शुरू करना 99.9% कहना और उसे न मानना से बेहतर है।
सरल गणना करें: प्रयास बनाम सफलता (attempts vs successes)。
अच्छे शुरुआती डेटा स्रोत:
परफेक्ट अव्ज़रविबिलिटी का इंतजार मत करें; एक भरोसेमंद प्रॉक्सी से शुरू करें और उसे लगातार बनाए रखें।
गिनें अगर एक बाहरी उपयोगकर्ता ध्यान देगा और एक संरक्षित यात्रा पूरी नहीं कर पाएगा।
आम उदाहरण जो बजट के खिलाफ गिने जाते हैं:
आंतरिक-अधिक केवल असुविधा तब गिनी जाती है जब आंतरिक उपयोग ही मुख्य उपयोग हो।
नियम सीधी रखें: पेज तब करें जब बजट जल रहा हो, हर छोटी सी चूक पर नहीं。
दो उपयोगी अलर्ट प्रकार:
यह अलर्ट थकान कम करता है और ध्यान उन मुद्दों पर केंद्रित करता है जो शिपिंग निर्णय बदलेंगे।
20 मिनट का छोटा सेशन रखें, हर हफ्ते एक ही समय और एक ही डॉक:
सप्ताह के लिए एक रिलीज़ मोड चुनें: Normal, Cautious, या Freeze (सिर्फ़ प्रभावित क्षेत्र)।
एक आसान नीति बोलकर रखें:
यह सज़ा नहीं है; यह सार्वजनिक व्यापार है ताकि उपयोगकर्ता बाद में इसकी कीमत न चुकाएँ।
कुछ व्यावहारिक गार्डरेल मदद करते हैं:
यदि आप Koder.ai पर बना रहे हैं, तो "पिछली अच्छी स्थिति में revert" को एक सामान्य, अभ्यास की गई चाल बनाएं और बार-बार होने वाले रोलबैक को टेस्ट या सेफर deploy चेक में निवेश का संकेत मानें।