सेल्फ-होस्टिंग के लिए प्रोडक्शन-तैयार ऐप हैंडऑफ चेकलिस्ट

प्रैक्टिकल रूप में “प्रोडक्शन-तैयार हैंडऑफ” का क्या मतलब है

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

हैंडऑफ को एक पैकेज की तरह समझें जो एक सवाल का जवाब दे: अगर मूल बिल्डर्स एक हफ्ते के लिए गायब हो जाएँ, तो क्या ops सिस्टम को सुरक्षित और उपलब्ध रख सकता है?

एक सॉलिड पैकेज आम तौर पर बताता है कि ऐप क्या करता है, “हेल्दी” कैसा दिखता है, रिलीज़ कैसे काम करती है (डिप्लॉय, वेरिफाई, रोलबैक), कॉन्फ़िग कहाँ रहती है, सीक्रेट्स कैसे हैंडल होते हैं, और मॉनिटरिंग, बैकअप और incidents का जवाब कैसे दिया जाता है।

इतना ही महत्वपूर्ण है कि हैंडऑफ क्या कवर नहीं करता। हैंडऑफ किसी फ़ीचर को जोड़ने, रिफैक्टर करने, स्क्रीन को री-डिज़ाइन करने या “बाद में साफ़ करने” का वादा नहीं है। ये अलग प्रोजेक्ट हैं जिनकी अपनी सीमा (स्कोप) होती है।

इसे पूरा कहने से पहले, ओनरशिप और रिस्पॉन्स टाइम्स पर सहमति बनाएं। उदाहरण के लिए: ops uptime और डिप्लॉय का मालिक है; प्रोडक्ट टीम रोडमैप चेंज की जिम्मेदारी लेती है; और डेवलप टीम पोस्ट-हैंडऑफ सपोर्ट की एक परिभाषित विंडो प्रदान करती है फिक्स और सवालों के लिए।

एक साधारण सिस्टम इन्वेंटरी बनाएं (क्या कहाँ चलता है)

Ops केवल वही चीज़ें संभाल सकता है जो वे देख सकता है। एक सरल एक-पेज इन्वेंटरी डिप्लॉय, घटनाओं और ऑडिट के समय अनुमान लगाने से बचाती है। इसे साधारण अंग्रेज़ी में और विशिष्ट रखें।

सिस्टम का हर चल रहा भाग और उसका स्थान सूचीबद्ध करें: बैकएंड API, वेब ऐप, बैकग्राउंड वर्कर्स, शेड्यूल किए गए जॉब्स, और मोबाइल ऐप्स कैसे कनेक्ट करते हैं। भले ही iOS/Android स्टोर्स के माध्यम से वितरित हों, वे अभी भी उसी बैकएंड पर निर्भर होते हैं।

उन बाहरी सेवाओं को शामिल करें जिनके बिना ऐप नहीं चल सकता। अगर आप PostgreSQL, कोई क्यू, ऑब्जेक्ट स्टोरेज, या थर्ड-पार्टी APIs (जैसे Stripe, मैसेजिंग, ईमेल/SMS, Telegram) इस्तेमाल करते हैं, तो सही सेवा का नाम और उसका उपयोग क्या है लिखें।

होस्टिंग trial-and-error न बने, इसलिए नेटवर्क आवश्यकताएँ कैप्चर करें: आवश्यक डोमेन्स (app, api, admin), पोर्ट और प्रोटोकॉल, TLS सर्टिफिकेट कौन रिन्यू करता है, DNS कहाँ मैनेज होता है, और कोई इनबाउंड/आउटबाउंड allowlists।

आखिर में अपेक्षित लोड असली संख्याओं में लिखें: पीक requests प्रति मिनट, एक्टिव यूज़र्स, सामान्य payload साइज, वर्तमान डेटाबेस साइज, और अपेक्षित वृद्धि। यहां मोटे अनुमान भी ops को लिमिट और अलर्ट सेट करने में मदद करते हैं।

यदि आपने AppMaster के साथ बनाया है, तो जनरेटेड बैकएंड, वेब ऐप, और इंटीग्रेशन की इन्वेंटरी दें ताकि ops जान सके कौन सी चीज़ें साथ में डिप्लॉय करनी हैं।

पर्यावरण कॉन्फ़िग पैकेज करें (सीक्रेट्स दिखाए बिना)

प्रोडक्शन सेटअप अक्सर उस बोरिंग भाग पर फेल होते हैं: कॉन्फ़िग जो किसी के दिमाग में ही रहती है। कॉन्फ़िग को एक डिलिवरेबल की तरह ट्रीट करें। ops को यह दिखना चाहिए कि कौन-कौन सी सेटिंग्स हैं, विभिन्न एनवायरनमेंट में क्या अलग है, और उन्हें सुरक्षित तरीके से कैसे बदलना है।

शुरू करें हर उस वातावरण का नाम लिखकर जो आज मौजूद है, भले ही वह अस्थायी लगे। ज़्यादातर टीमों के पास dev, staging, और production होते हैं, साथ में कॉपियाँ जैसे “production-eu” या “staging-us” भी हो सकती हैं। नोट करें कौन सा वातावरण रिलीज़ टेस्टिंग, डेटा माइग्रेशन और incident drills के लिए उपयोग होता है।

एक सिंगल कॉन्फ़िग रेफरेंस दें जो वेरिएबल नाम और सुरक्षित उदाहरण मान (कभी भी वास्तविक क्रेडेंशियल नहीं) सूचीबद्ध करे। प्लेसहोल्डर्स स्पष्ट रखें।

आपके हैंडऑफ पैकेज में होना चाहिए:

• एनवायरनमेंट्स की सूची और हर एक का उपयोग
• कॉन्फ़िग की चाबियों (env vars या कॉन्फ़िग फ़ाइल की चाबियाँ), उम्मीद किए गए टाइप, और गैर-सीक्रेट उदाहरण मान
• एनवायरनमेंट्स के बीच ज्ञात अंतर (फीचर फ्लैग, रेट लिमिट्स, कैश साइज, ईमेल मोड, लॉगिंग लेवल)
• डिफॉल्ट्स और अगर कोई की गायब हो तो क्या होता है
• कॉन्फ़िग कहाँ स्टोर होती है और डिप्लॉय के दौरान कैसे लागू होती है

एक सरल चेंज प्रोसेस भी जोड़ें। उदाहरण: टिकट में रिक्वेस्ट, सर्विस ओनर द्वारा रिव्यू, पहले staging में लागू करें, फिर प्रोडक्शन में शेड्यूल्ड विंडो में प्रमोट करें और अगर एरर रेट बढ़े तो रोलबैक प्लान रखें।

यदि आप AppMaster ऐप को एक्सपोर्ट करके self-host कर रहे हैं, तो वही नियम रखें: जनरेटेड सोर्स के साथ साफ़, डॉक्यूमेंटेड कॉन्फ़िग की चाबियों का सेट भेजें ताकि ops इसे अलग-अलग एनवायरनमेंट में लगातार चला सके।

सीक्रेट्स और क्रेडेंशियल: स्टोरेज, रोटेशन और एक्सेस

सीक्रेट्स सबसे तेज़ तरीका हैं जिससे एक साफ हैंडऑफ सुरक्षा घटना में बदल सकता है। लक्ष्य सीधा है: ops को हर यह जानना चाहिए कि ऐप को कौन-कौन से सीक्रेट्स चाहिए, वे कहाँ हैं, कौन पढ़ सकता है, और बिना डाउनटाइम के उन्हें कैसे बदलें।

एक छोटा सीक्रेट्स लिस्ट बनाकर शुरू करें जिसे ops एक मिनट में स्कैन कर सके। हर आइटम के लिए बताएं कि यह क्या अनलॉक करता है (डेटाबेस, SMTP, Stripe, JWT साइनिंग की), यह कहाँ रहता है (vault, क्लाउड सीक्रेट स्टोर, Kubernetes Secret, एन्क्रिप्टेड फ़ाइल), और रोटेशन किसका है।

रोटेशन स्टेप्स नीतियों की तरह नहीं बल्कि रेसिपी की तरह लिखें। सटीक क्रम, पुरानी कुंजी कितनी देर वैध रहनी चाहिए, और वह एक चेक जो साबित करे कि यह काम किया — यह सब शामिल करें।

रोटेशन चेकलिस्ट (उदाहरण)

प्रत्येक सीक्रेट के लिए इस पैटर्न का उपयोग करें:

• नया सीक्रेट मान बनाएं और अनुमोदित सीक्रेट मैनेजर में स्टोर करें।
• कॉन्फ़िग बदलकर डिप्लॉय करें ताकि ऐप नया मान उपयोग करे।
• सत्यापित करें: लॉगिन, पेमेंट या API कॉल सफल हों और एरर रेट सामान्य रहे।
• पुराना सीक्रेट रिवोक करें और पक्का करें कि यह अब काम नहीं करता।
• रोटेशन की तिथि, किसने की, और अगली नियत तिथि रिकॉर्ड करें।

एन्क्रिप्शन अपेक्षाओं के बारे में स्पष्ट रहें। सीक्रेट्स को स्टोर में एट-रेस्ट एन्क्रिप्ट होना चाहिए और ऐप और उसकी निर्भरताओं के बीच ट्रांज़िट में TLS से सुरक्षित होना चाहिए। कभी भी सीक्रेट्स को सोर्स कंट्रोल, बिल्ड आर्टिफैक्ट्स, या साझा डॉक्‍यूमेंट्स में न रखें।

ब्रेक-ग्लास एक्सेस परिभाषित करें। यदि आउटेज सामान्य एक्सेस को ब्लॉक करता है, तो बताएं कि इमरजेंसी एक्सेस कौन अप्रूव कर सकता है, यह कितनी देर के लिए रहेगा, और उसके बाद क्या ऑडिट होना चाहिए।

डिप्लॉयमेंट पैकेज: आर्टिफैक्ट्स, वर्ज़न और रोलबैक

Ops केवल वही चीज़ें संभाल सकता है जिन्हें वे दोहराकर बना सकें। एक अच्छा डिप्लॉयमेंट पैकेज तीन सवालों के जवाब आसान बनाता है: हम वास्तव में क्या चला रहे हैं, इसे फिर से कैसे डिप्लॉय करें, और अगर कुछ टूटे तो जल्दी कैसे वापस जाएँ।

बिल्ड के लिए एक स्पष्ट “बिल ऑफ़ मैटेरियल्स” शामिल करें। केवल यह न बताएं कि यह कहाँ रहता है, बल्कि किस तरह के आर्टिफैक्ट हैं और उन्हें कैसे वेरिफाई करें:

• आर्टिफैक्ट विवरण: कंटेनर इमेज नाम/टैग (या बाइनरी/पैकेज नाम), ऐप वर्शन, बिल्ड तारीख, चेकसम
• सोर्स रेफरेंस: रिलीज टैग या कमिट हैश जिसका उपयोग बिल्ड करने में हुआ, साथ में कोई महत्वपूर्ण बिल्ड फ़्लैग
• समर्थित लक्ष्य: VM, कंटेनर्स (Docker), या Kubernetes, और कौन सा डिफ़ॉल्ट सुझाया गया है
• डिप्लॉय स्टेप्स: प्रीरेक्विज़ाइट्स (रनटाइम, डेटाबेस, स्टोरेज), सटीक क्रम, और सामान्य डिप्लॉय समय
• डेटाबेस माइग्रेशन्स: कैसे चलती हैं (स्टार्टअप पर ऑटो या मैन्युअल), लॉग कहाँ हैं, और सफलता कैसे पुष्टि करें

एक छोटा सा ठोस उदाहरण जोड़ें। उदाहरण के तौर पर: “v1.8.2 डिप्लॉय करने के लिए इमेज टैग अपडेट करें, माइग्रेशन्स चलाएँ, फिर वेब वर्कर्स रीस्टार्ट करें। यदि 10 मिनट के भीतर हेल्थ चेक फेल होते हैं, तो v1.8.1 पर revert करें और माइग्रेशन जॉब बंद कर दें।”

अटकलों के बिना रोलबैक

एक रोलबैक प्लान ऐसा होना चाहिए जैसे आप 2 बजे रात को निर्देशों का पालन कर सकें। इसमें बताना चाहिए:

• वह संकेत जो रोलबैक ट्रिगर करेगा (एरर रेट, फेलिंग हेल्थ चेक, लॉगिन टूटना)
• आखिरी ज्ञात अच्छी वर्ज़न और वह कहाँ स्टोर है
• क्या डेटाबेस बदलाव उलटने योग्य हैं, और अगर नहीं तो क्या करना है

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

मॉनिटरिंग और अलर्टिंग: क्या मापें और कब पेज करें

हैंडऑफ तब तक पूरा नहीं होता जब तक ops नहीं देख सकता कि ऐप क्या कर रहा है और यूज़र्स शिकायत करने से पहले उन्हें चेतावनी नहीं मिलती।

सहमति बनाएं कि किन लॉग्स का अस्तित्व अनिवार्य है और वे कहाँ जाते हैं (फ़ाइल, syslog, लॉग प्लेटफ़ॉर्म)। सुनिश्चित करें कि लॉग्स टाइम-सिंक्ड हों और एक रिक्वेस्ट या कॉरिलेशन ID शामिल हो ताकि घटनाएँ एंड-टू-एंड ट्रेस हो सकें।

आमतौर पर आपको चाहिए application logs (मुख्य इवेंट्स और फेल्यर्स), error logs (स्टैक ट्रेसेज़ और फेल्ड जॉब्स), access logs (रिक्वेस्ट और स्टेटस कोड), audit logs (एडमिन एक्शन्स और एक्सपोर्ट्स), और infrastructure logs (रीस्टार्ट, नोड प्रेसर, डिस्क इश्यू)।

फिर उन मीट्रिक्स का छोटा सेट परिभाषित करें जो यूज़र इम्पैक्ट और सिस्टम हेल्थ दिखाते हैं। अगर आप केवल पाँच चुनें: लेटेंसी (p95/p99), एरर रेट, सैचुरेशन (CPU/memory/disk), क्यू डेप्थ, और आपकी नेटवर्क के बाहर से availability चेक।

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

बैकअप और रिकवरी: रिस्टोर्स को दोहराने योग्य बनाएं

बैकअप कोई ऐसी चीज़ नहीं है जो आप “पास” कहते हैं; बैकअप वह चीज़ है जिससे आप मांग पर रिस्टोर कर सकें।

सटीक स्कोप लिखें: डेटाबेस, फ़ाइल स्टोरेज (अपलोड्स, रिपोर्ट्स, इनवॉइस), और वे हिस्से जो लोग भूल जाते हैं — जैसे कोड में न रहने वाला कॉन्फ़िग और उन एन्क्रिप्शन कीज़ जिनसे प्रोटेक्टेड डेटा पढ़ा जा सके।

लक्ष्य सीधे शब्दों में रखें। RPO बताता है कि आप कितना डेटा खो सकते हैं (उदाहरण: 15 मिनट)। RTO बताता है कि आप कितना समय डाउन रह सकते हैं (उदाहरण: 1 घंटे)। वह संख्या बिज़नेस के साथ सहमति पर चुनें क्योंकि वे लागत और प्रयास को प्रभावित करती हैं।

शामिल करें:

• क्या बैकअप होता है, कहाँ स्टोर होता है और रिटेंशन
• कौन बैकअप और रिस्टोर चला सकता है, और एक्सेस कैसे अप्रूव होता है
• स्टेप-बाय-स्टेप रिस्टोर प्रक्रिया साथ वेरिफिकेशन चेक
• रिस्टोर लॉग कहाँ रहते हैं, और “सफलता” कैसा दिखती है
• आम फेल्योर मोड (गलत की, गायब बकेट, स्कीमा मismatch) और उनका समाधान

यदि आप AppMaster से एक्सपोर्ट कर self-host कर रहे हैं, तो PostgreSQL रिस्टोर स्टेप्स और किसी भी बाहरी स्टोरेज बकेट और एन्क्रिप्टेड फ़ील्ड्स के लिए प्रयुक्त कीज़ शामिल करें।

एक रिस्टोर ड्रिल शेड्यूल करें। समय, क्या टूटा, और आपने क्या बदला यह रिकॉर्ड करें ताकि अगली बार रिस्टोर तेज़ और कम तनावपूर्ण हो।

रनबुक और ऑन-कॉल: असली घटनाओं को ops कैसे हैंडल करता है

हैंडऑफ तब तक असली नहीं होता जब तक किसी को 2 बजे के नोटिफ़िकेशन पर बिना अनुमान के समस्या ठीक करने के लिए कहा जा सके। रनबुक जनजातीय ज्ञान को ऐसे स्टेप्स में बदल देती है जिन्हें ऑन-कॉल व्यक्ति फॉलो कर सके।

शुरू करें उन घटनाओं से जिन्हें आप जल्द ही होने की उम्मीद करते हैं: पूरी तरह आउटेज, धीमे रिक्वेस्ट और वह डिप्लॉय जो कुछ तोड़ दे। हर रनबुक को छोटा रखें। सबसे तेज़ चेक ऊपर रखें ताकि रिस्पॉन्डर मिनटों में संकेत पा सकें।

एक अच्छा रनबुक क्या शामिल करता है

ढाँचे को सुसंगत रखें ताकि दबाव में भी स्कैन करना आसान हो:

• उपयोगकर्ता क्या देखते हैं और इसे कैसे सुनिश्चित करें (उदा: एरर रेट X% से ऊपर, चेकआउट फेल होना)
• पहले चेक्स (सर्विस स्टेटस, हाल की डिप्लॉय, निर्भरता हेल्थ, डिस्क/CPU, DB कनेक्शन)
• अगले चेक्स (कौन से लॉग खोलने हैं, मुख्य डैशबोर्ड, हाल की कॉन्फ़िग चेंज, क्यू डेप्थ)
• निर्णय बिंदु (कब रोलबैक करें, कब स्केल करें, कब फीचर डिसेबल करें)
• एस्केलेशन (कौन ऐप का मालिक है, कौन इंफ्रा का मालिक है, और कब किसे पेज करें)

यदि ऐप AppMaster से एक्सपोर्ट या self-host किया गया है, तो बताएं कि जनरेटेड सर्विसेज कहाँ चलते हैं, उन्हें सुरक्षित तरीके से कैसे रीस्टार्ट करें, और प्रत्येक एनवायरनमेंट के लिए कौन से कॉन्फ़िग वैल्यू अपेक्षित हैं।

घटना के बाद: सही तथ्य कैप्चर करें

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

एक्सेस कंट्रोल और परमिशन्स: कौन क्या कर सकता है

Ops तभी सिस्टम का मालिक बन सकता है जब स्पष्ट हो कि कौन क्या छू सकता है और एक्सेस कैसे ट्रैक होता है।

वह भूमिकाएँ लिखें जो आप वास्तव में इस्तेमाल करते हैं। कई टीमों के लिए ये भूमिकाएँ काफी होती हैं:

• Deployer: अप्रूव्ड वर्ज़न डिप्लॉय करना और रोलबैक ट्रिगर करना
• DB admin: स्कीमा चेंज और बैकअप रिस्टोर चलाना
• Read-only: डैशबोर्ड, लॉग्स और कॉन्फ़िग देखना बिना एडिट के
• Incident commander: आउटेज के दौरान इमरजेंसी क्रियाओं को अप्रूव करना

“डोर पॉलिसी” को सरल स्टेप्स में दस्तावेज़ करें: एक्सेस कौन देता है, कहाँ दिया जाता है (SSO, क्लाउड IAM, DB यूज़र्स, CI/CD, एडमिन पैनल), कौन रिवॉक कर सकता है, और ऑफबोर्डिंग पर कैसे पुष्टि होती है कि इसे हटाया गया है।

नॉन-ह्यूमन एक्सेस न भूलें। हर सर्विस अकाउंट और टोकन की सूची बनाएं जो जॉब्स, इंटीग्रेशन और मॉनिटरिंग उपयोग करते हैं, साथ में प्रत्येक के लिए least-privilege नोट (उदा: “केवल बकेट X पढ़ सकता है”)। यदि आप AppMaster का सोर्स एक्सपोर्ट कर रहे हैं, तो बताएं कि ये आइडेंटिटीज कौन से env vars या कॉन्फ़िग फ़ाइलों से परिभाषित होती हैं, पर कभी भी सीक्रेट वैल्यूज़ हैंडऑफ डॉक में न पेस्ट करें।

ऑडिट लॉग अपेक्षाएँ भी सेट करें: क्या लॉग होना चाहिए (लॉगिन, डिप्लॉय, कॉन्फिग बदलाव, DB admin एक्सन), कौन लॉग पढ़ सकता है, रिटेंशन, कहाँ स्टोर होते हैं, और घटना या समीक्षा के दौरान लॉग कैसे अनुरोध करें।

सुरक्षा और अनुपालन की बुनियादी बातें (साधारण भाषा में)

सुरक्षा नोट्स गैर-विशेषज्ञों द्वारा पढ़ने लायक होने चाहिए, पर इतना विशिष्ट भी कि ops काम कर सके। एक एक-पेज सारांश जोड़ें जो उत्तर दे: हम कौन सा डेटा संग्रहीत करते हैं, वह कहाँ रहता है, और कौन उसे एक्सेस कर सकता है?

डेटा प्रकारों से शुरू करें: कस्टमर प्रोफाइल, सपोर्ट टिकट, पेमेंट मेटाडाटा, फाइलें। संवेदनशील श्रेणियाँ जैसे PII (नाम, ईमेल, फोन), क्रेडेंशियल्स, और कोई रेगुलेटेड डेटा को स्पष्ट करें। यदि आप सोर्स कोड एक्सपोर्ट करते हैं (AppMaster से शामिल), तो नोट करें कि वह डेटा डेटाबेस में कहाँ रहता है और कौन सी सेवाएँ उसे पढ़ सकती हैं।

फिर रिटेंशन और डिलीशन नियम व्यवहारिक शब्दों में लिखें। बताएं आप क्या रखते हैं, कितनी देर रखते हैं, और डिलीशन कैसे होता है (सॉफ्ट डिलीट बनाम हार्ड डिलीट, देरी से purge, बैकअप)। अगर कानूनी होल्ड या ऑडिट जरूरतें हैं, तो अपवाद को कौन अप्रूव करता है यह भी नोट करें।

लॉग्स अक्सर डेटाबेस से ज़्यादा लीक करते हैं। स्पष्ट रूप से बताएं कि PII कहाँ दिख सकता है (एक्सेस लॉग्स, एरर लॉग्स, एनालिटिक्स इवेंट्स) और इसे कैसे कम या मास्क किया जाता है। अगर कोई फील्ड लॉग में कभी नहीं आनी चाहिए, तो वह नियम लिखें।

स्वीकृतियाँ स्पष्ट रखें:

• ऑथेंटिकेशन बदलावों के लिए नामित अप्रूवर चाहिए।
• पेमेंट-संबंधी बदलाव (Stripe कीज़, वेबहुक एंडपॉइंट, रिफंड लॉजिक) के लिए नामित अप्रूवर चाहिए।
• रोल और परमिशन मॉडल बदलने के लिए नामित अप्रूवर चाहिए।
• सुरक्षा पैचिंग विंडो और इमरजेंसी चेंज नियम लिखे हों।

यदि आप केवल एक अतिरिक्त चीज़ जोड़ सकते हैं, तो एक एविडेंस नोट जोड़ें: ऑडिट लॉग्स कहाँ रखे जाते हैं और जब किसी ने साक्ष्य माँगा तो उन्हें कैसे एक्सपोर्ट करें।

उदाहरण हैंडऑफ परिदृश्य: ops एक हफ्ते में ओनरशिप लेता है

Ops एक कस्टमर पोर्टल ले रहा है जिसे एक छोटी प्रोडक्ट टीम ने बनाया है और उसे नए self-hosted इन्फ्रास्ट्रक्चर पर मूव कर रहा है। लक्ष्य केवल “यह चले” नहीं है, बल्कि “ops इसे बिना बिल्डर्स को बुलाए चला सके” है।

उस हफ्ते का क्या रूप होगा

Day 1: Ops एक नया वातावरण बनाकर पैकेज से पहली बार साफ़ डिप्लॉय करते हैं। ऐप उठता है, पर लॉगिन फेल होता है क्योंकि ईमेल प्रोवाइडर के लिए एक एनवायरनमेंट वेरिएबल गायब था। वह env टेम्पलेट में जोड़ दिया जाता है और डिप्लॉय तब तक दोहराया जाता है जब तक वह स्क्रैच से काम न करे।

Day 2: पहला अलर्ट जानबूझकर फायर किया जाता है। Ops एक नियंत्रित फ़ेलियर ट्रिगर करते हैं (एक सर्विस रोकें या आउटबाउंड ईमेल ब्लॉक करें) और पुष्टि करते हैं: मीट्रिक्स समस्या दिखाते हैं, अलर्ट सही चैनल तक पहुँचते हैं, और संदेश बताता है अगला कदम क्या है।

Day 3: पेमेंट सैंडबॉक्स में एक टोकन एक्सपायर होता है। चूँकि क्रेडेंशियल्स का स्थान और रोटेशन स्टेप्स डॉक्यूमेंट हैं, ops बिना अनुमान के उसे बदल लेते हैं और सीक्रेट्स उजागर नहीं होते।

Day 4: DNS कटओवर। एक गलत रिकॉर्ड पुराने IP की ओर इशारा करता है और कुछ यूज़र्स के लिए पोर्टल डाउन सा लगता है। Ops रनबुक का उपयोग करके DNS, TLS, और हेल्थ चेक्स सही क्रम में सत्यापित करते हैं।

Day 5: पहला बैकअप रिस्टोर टेस्ट। Ops एक ताज़ा डेटाबेस में रिस्टोर करते हैं और साबित करते हैं कि पोर्टल असली डेटा के साथ लोड हो सकता है।

एक हफ्ते के बाद “होना” कैसा दिखता है

ऐप 7 दिनों तक बिना रहस्यमयी फिक्स के चला, एक सफल रिस्टोर हुआ, स्पष्ट अलर्ट्स थे, और एक दोहराने योग्य डिप्लॉय था जो ops अकेले कर सकते थे।

अक्सर होने वाली हैंडऑफ गलतियाँ जो रात में जगाती हैं

हैंडऑफ को 2 बजे की आग में बदलने का सबसे तेज़ तरीका यह मानना है कि “हमने ops को सब कुछ बता दिया” और “ops इसे बिना हमारी मदद के चला सकता है” समान हैं।

सेल्फ-होस्टिंग हैंडऑफ के बाद सामान्य विफलता पैटर्न में शामिल हैं: स्प्रेडशीट या चैट में साझा किए गए सीक्रेट्स, रोलबैक जिनके लिए डेवलपर पर निर्भरता, बैकअप जो मौजूद हैं पर रिस्टोर कभी टेस्ट नहीं हुआ, ऐसे अलर्ट जो पूरे दिन बजते रहते हैं क्योंकि थ्रेशहोल्ड ठीक से सेट नहीं हुए, और एनवायरनमेंट विवरण जो केवल किसी के दिमाग में रहते हैं (पोर्ट्स, DNS नाम, क्रोन शेड्यूल, क्लाउड परमिशन)।

उदाहरण: आप AppMaster से सोर्स कोड एक्सपोर्ट कर self-host कर रहे हैं और पहली डिप्लॉय काम कर गई। दो हफ्ते बाद एक कॉन्फ़िग चेंज लॉगिन तोड़ देता है। अगर सीक्रेट्स चैट में पास किए गए थे और रोलबैक के लिए मूल बिल्डर की ज़रूरत है, तो ops घंटों खो देता है सिर्फ़ यह वापस लाने में कि “कल काम कर रहा था”।

“हैंडऑफ पूरा” कहने से पहले त्वरित चेक

टिकट बंद करने से पहले एक छोटा fresh-start ड्रिल चलाएँ। हैंडऑफ पैकेज एक ops इंजीनियर और एक साफ एनवायरनमेंट (नया VM, नई Kubernetes namespace, या एक खाली क्लाउड प्रोजेक्ट) को दें। अगर वे पैकेज का उपयोग करके सेट समय के भीतर (उदा. 2 घंटे) डिप्लॉय, ऑब्जर्व और रिकवर कर सकें, तो आप करीब हैं।

इन चेक्स का उपयोग करें:

• केवल पैक किए गए आर्टिफैक्ट्स, कॉन्फ़िग डॉक और रनबुक्स का उपयोग करके स्क्रैच से रीबिल्ड और डिप्लॉय करें (एक रोलबैक सहित)
• सत्यापित करें कि हर सीक्रेट सहमति स्थान पर है, और रोटेशन स्टेप्स लिखे और टेस्ट किए गए हैं
• डैशबोर्ड खोलें और सुनिश्चित करें कि वे बुनियादी प्रश्नों का उत्तर देते हैं: क्या यह ऊपर है, क्या यह धीमा है, क्या एरर हो रहे हैं, क्या रीसोर्स ख़त्म हो रहे हैं?
• एक सुरक्षित टेस्ट अलर्ट ट्रिगर करें ताकि पेजिंग रूट्स, ओनर्स और शांत घंटे अपेक्षित रूप से काम करें
• एक अलग एनवायरनमेंट में असली रिस्टोर टेस्ट करें, फिर सटीक स्टेप्स और अपेक्षित परिणाम डॉक्यूमेंट करें

यदि आप जनरेटेड सोर्स को self-host करने के लिए एक्सपोर्ट कर रहे हैं, तो यह भी पुष्टि करें कि ops जानता है कि बिल्ड इनपुट्स, वर्ज़न और रिलीज टैग कहाँ रिकॉर्ड हैं ताकि भविष्य की रिलीज़ें दोहराने योग्य रहें।

अगले कदम: ओनरशिप फ़ाइनल करें और पैकेज को अद्यतन रखें

पेज़ संभालने वालों के साथ एक अंतिम walkthrough चलाएँ। इसे एक रिहर्सल की तरह ट्रीट करें। सिद्ध करें कि डिप्लॉय, रोलबैक, रिस्टोर और अलर्टिंग उसी पैकेज के साथ काम करते हैं जो आप हैंडऑफ कर रहे हैं।

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

ओनरशिप स्पष्ट करें। हर रनबुक (डिप्लॉय, इंसिडेंट, रिस्टोर) और हर अलर्ट रूट के लिए नामित ओनर असाइन करें (प्राइमरी ऑन-कॉल, बैकअप, आफ्टर-आवर्स व्यवहार)। अगर किसी अलर्ट का कोई मालिक नहीं है, तो या तो उसे अनसुना किया जाएगा या गलत व्यक्ति को जगाया जाएगा।

एक छोटा Day 2 प्लान लिखें ताकि ops पहले सप्ताह के बाद क्या सुधारें यह पता हो: थ्रेशहोल्ड्स ट्यून करना, लागत की जाँच, पुराने आर्टिफैक्ट्स की सफाई, और एक्सेस की समीक्षा। इसे छोटा और समय-सीमित रखें।

यदि आप AppMaster (appmaster.io) के साथ बनाए हैं, तो एक्सपोर्टेड सोर्स कोड या सटीक डिप्लॉयमेंट टार्गेट विवरण (क्लाउड, रीजन, बिल्ड सेटिंग्स, आवश्यक सेवाएँ) शामिल करें ताकि ops बिना मूल प्रोजेक्ट वर्कस्पेस पर निर्भर रहे ऐप को पुन: उत्पन्न कर सके। पैकेज को बदलते हुए नियमित अंतराल पर अपडेट करने की साधारण रूपरेखा रखें ताकि रनबुक वास्तविकता से drift न करें।