नो-कोड ऐप्स के लिए इंसिडेंट रनबुक: पहचानें, ट्रायज करें, रिकवर करें

यह रनबुक क्या है और इसे कब इस्तेमाल करें

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

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

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

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

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

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

कुछ भी टूटने से पहले: अपना बेसलाइन और भूमिकाएँ सेट करें

जब आप "सामान्य" नहीं जानते तो इंसिडेंट्स अराजक लगते हैं। अपनी बेसलाइन परिभाषित करें ताकि टीम असली समस्याओं को जल्दी पहचान सके। No-code ऐप के लिए शुरुआती संकेत आमतौर पर प्लेटफ़ॉर्म हेल्थ, बिजनेस मीट्रिक्स, और लोगों के मिश्रण से आते हैं।

हर दिन जिन सिग्नलों को आप देखेंगे उन्हें लिखें, सिर्फ़ आउटेज के समय नहीं। सामान्य संकेतों में uptime, error rate, धीमी स्क्रीन, फेल हुए लॉगिन, पेमेंट फेलियर, और सपोर्ट टिकट्स या उपयोगकर्ता संदेशों में spike शामिल हैं।

Severity को सामान्य भाषा में परिभाषित करें ताकि कोई भी इसका उपयोग कर सके:

• SEV1: अधिकांश उपयोगकर्ता ऐप का उपयोग नहीं कर पाते, या पैसा/सुरक्षा जोखिम में है।
• SEV2: एक प्रमुख फीचर टूट गया है, पर workaround मौजूद है।
• SEV3: मामूली समस्याएँ, सीमित उपयोगकर्ता, या cosmetic बग।

Momentum बनाने के लिए response targets सेट करें। उदाहरण लक्ष्य: 5 मिनट में acknowledge करें, 15 मिनट में पहला अपडेट पोस्ट करें, और 60 मिनट के भीतर स्थिर करने का लक्ष्य रखें (भले ही पूर्ण फिक्स में अधिक समय लगे)।

भूमिकाएँ पहले तय करें। तय करें कि कौन इंसिडेंट घोषित कर सकता है, कौन नेतृत्व करता है, और अगर वह व्यक्ति ऑफ़लाइन है तो कौन बैकअप है। AppMaster टीमों में अक्सर यह Business Process लॉजिक का मालिक होता है, साथ में एक बैकअप जो डिप्लॉयमेंट या एक्सपोर्ट संभाल सके।

अंत में, इंसिडेंट नोट्स के लिए एक साझा जगह रखें। हर कार्रवाई के लिए टाइमस्टैम्प्स रखें (क्या बदला, कब, किसने) ताकि बाद में अनुमान लगाए बिना कहानी reconstruct की जा सके।

पता लगाना और पुष्टि करना: क्या यह असली है और कितना बुरा है

डैशबोर्ड घूरने से पहले प्रभाव की पुष्टि करें। एक स्पष्ट प्रश्न पूछें: अभी कौन क्या नहीं कर पा रहा है? "सपोर्ट टीम टिकट खोल नहीं पा रही" कहना "ऐप धीमा है" से अधिक उपयोगी है। यदि हो सके तो प्रभावित उपयोगकर्ता के समान रोल और डिवाइस का उपयोग करके समस्या reproduce करें।

अगला, यह पता लगाएं कि यह कितना व्यापक है। क्या यह एक अकाउंट है, एक ग्राहक सेक्शन है, या सभी को प्रभावित कर रहा है? तेज़ विभाजन करें: क्षेत्र, अकाउंट प्रकार, वेब बनाम मोबाइल, और एक फीचर बनाम पूरे ऐप। No-code टूल्स में कुछ ग्लोबल दिख सकता है जबकि असल में यह permission rule या एक टूटे हुए स्क्रीन की वजह से होता है।

फिर देखें क्या बदला था। 1-2 घंटे पीछे देखें—एक रिलीज, किसी config toggle, डेटाबेस स्कीमा संपादन, या डेटा इम्पोर्ट। AppMaster जैसी प्लेटफॉर्म पर Business Processes, डेटा मॉडल, या auth सेटिंग्स में बदलाव कई फ्लो को एक साथ प्रभावित कर सकते हैं, भले ही UI ठीक दिखे।

ऐप को दोष देने से पहले बाहरी dependencies को बाहर करें। Email/SMS प्रोवाइडर, पेमेंट्स (जैसे Stripe), और इंटीग्रेशन्स (Telegram, AWS सेवाएँ, AI APIs) फेल या rate-limit हो सकते हैं। अगर ऐप केवल तब टूटता है जब संदेश भेजे जा रहे हों या कार्ड चार्ज किए जा रहे हों, तो मूल समस्या अपस्ट्रीम हो सकती है।

एक सरल निर्णय चेकलिस्ट का उपयोग करें:

• Monitor अगर प्रभाव कम है और त्रुटियाँ बढ़ नहीं रहीं।
• Mitigate now अगर उपयोगकर्ता मूल कार्यों से ब्लॉक हैं या डेटा जोखिम में है।
• Declare an incident अगर मुद्दा व्यापक, समय-संवेदी, या अस्पष्ट है।
• Escalate अगर समस्या पेमेंट्स, authentication, या प्रोडक्शन डेटा को छू रही है।
• Set a check-in time (उदाहरण के लिए हर 15 मिनट) ताकि टीम भटक न जाए।

एक बार जब आप severity और scope classify कर लें, तो आप "क्या असली है?" से "पहले क्या करें?" पर बिना अनुमान लगाए आगे बढ़ सकते हैं।

ट्रायज चरण-दर-चरण (पहले 30 मिनट)

तुरंत एक इंसिडेंट रिकॉर्ड खोलें। इसे एक सादा शीर्षक दें जो उपयोगकर्ता प्रभाव को नामित करे, न कि संदेहित कारण को (उदाहरण: "EU ग्राहकों के लिए Checkout fail हो रहा है")। शुरूआती समय लिखें (पहला अलर्ट या पहला रिपोर्ट)। यह निर्णयों, टाइमस्टैम्प्स, और क्या बदला का एकल स्थान बन जाता है।

भूमिकाएँ असाइन करें ताकि काम ओवरलैप न हो। छोटी टीम में भी मालिकों को नामित करने से तनाव के समय गलतियाँ कम होती हैं। कम से कम आपको चाहिए:

• Incident lead: फोकस रखता है, प्राथमिकताएँ सेट करता है, contain बनाम rollback का निर्णय लेता है
• Fixer: जांच करता है और बदलाव लागू करता है
• Comms: स्टेकहोल्डर्स और सपोर्ट को अपडेट पोस्ट करता है
• Note taker: क्रियाएँ, समय और परिणाम लॉग करता है

लिखित दो बातें लिखें: जो आप निश्चित रूप से जानते हैं, और आपकी वर्तमान अनुमानी व्याख्या (hypothesis)। "जानकारी" में हो सकता है: error rate spike हुई, एक विशिष्ट endpoint fail कर रहा है, केवल मोबाइल प्रभावित है। hypothesis गलत हो सकती है, पर यह अगला टेस्ट मार्गदर्शित करनी चाहिए। दोनों को सीखने के साथ अपडेट रखें।

जब चीजें अस्थिर हों, 15-मिनट अपडेट कैडेंस सेट करें। अगर कुछ नहीं बदला, तो वह बताइए। नियमित अपडेट साइड चर्चाओं को रोकते हैं और duplicate "कोई खबर?" पिंग्स को टालते हैं।

पहली containment कार्रवाई चुनें। लक्ष्य तेज़ी से नुकसान कम करना है, भले ही root cause स्पष्ट न हो। सामान्य शुरुआती कदमों में बैकग्राउंड जॉब्स रोकना, रिस्की फीचर फ्लैग डिसेबल करना, किसी मॉड्यूल के लिए ट्रैफ़िक सीमित करना, या ज्ञात-सुरक्षित कॉन्फ़िगरेशन पर स्विच करना शामिल है। AppMaster में यह अक्सर Business Process Editor में किसी विशिष्ट फ्लो को बंद करना या ऐसे UI पाथ को अस्थायी रूप से छिपाना होता है जो विफलताओं को ट्रिगर कर रहा हो।

अगर containment एक कैडेंस विंडो के भीतर मेट्रिक्स में सुधार नहीं करता, तो समानांतर में रोलबैक प्लानिंग शुरू करें।

पहले स्थिर करें: प्रभाव को सीमित करें

एक बार पुष्टि हो जाने पर कि यह वास्तविक इंसिडेंट है, "बग ढूँढना" से "खून रोकना" पर स्विच करें। स्थिरीकरण आपको समय खरीदता है। यह उपयोगकर्ताओं, राजस्व, और डेटा की रक्षा करता है जबकि आप जांच करते हैं।

सबसे छोटे बदलाव से शुरू करें जो नुकसान कम करे। containment अक्सर फ़ुल फिक्स से तेज़ होता है क्योंकि आप नई फीचर को डिसेबल कर सकते हैं, वर्कफ़्लो को रोक सकते हैं, या बिना री-बिल्ड के किसी रिस्की इनपुट पाथ को ब्लॉक कर सकते हैं।

अगर आपको संदेह है कि डेटा करप्ट हो रहा है तो पहले लिखावटें रोकें। इसका मतलब अस्थायी रूप से फॉर्म्स डिसेबल करना, रिकॉर्ड अपडेट करने वाली ऑटोमेशन्स को pause करना, या अपडेट स्वीकार करने वाले API endpoint को ब्लॉक करना हो सकता है। बुरा डेटा पढ़ना पीड़ा देता है, पर बुरा डेटा लिखना साफ़ करने को गुणा कर देता है।

अगर उपयोगकर्ता लॉक आउट हैं, तो लॉगिन को शीर्ष प्राथमिकता मानें। किसी भी अन्य फिक्स से पहले authentication सेटिंग्स और login फ्लो जाँचें। आपकी और आपकी टीम की पहुंच के बिना बाकी सब धीमा हो जाएगा।

अगर ऐप धीमा है या टाइमआउट हो रहा है, तो लोड कम करें और महँगे पाथ हटाएँ। भारी स्क्रीन बंद करें, बैच जॉब्स रोकें, और नए इंटीग्रेशन disable करें जो अनुरोधों की संख्या बढ़ा रहे हों। AppMaster में containment अक्सर समस्या करने वाले बिज़नेस प्रोसेस को डिसेबल करने या उस UI एक्शन को अस्थायी रूप से हटाने जितना सरल हो सकता है जो महँगी चेन ट्रिगर करता है।

कार्रवाइयाँ सोच-समझ कर और दस्तावेज़ के साथ रखें। दबाव में टीमें कदम दोहराती हैं या गलती से फिक्स undo कर देती हैं। हर बदलाव और परिणाम लिखें।

एक सरल स्थिरीकरण क्रम:

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

आपका लक्ष्य "सुरक्षित और उपयोग योग्य" है, न कि "पूरी तरह से हल"। एक बार जब प्रभाव सीमित हो जाए, तो आप शांतिपूर्वक निदान कर सकते हैं और सही रोलबैक या फिक्स चुन सकते हैं।

रोलबैक विकल्प और जोखिम जाँच

जब कुछ टूटता है तो स्पीड मायने रखती है, पर सबसे सुरक्षित कदम जीतता है। सामान्यतः आपके पास तीन व्यावहारिक विकल्प होते हैं: रोलबैक, आगे फिक्स भेजना, या पार्टियल रिवर्ट (एक फीचर बंद कर देना जबकि बाकी रहने देना)।

पहले स्पष्ट करें कि आपके सेटअप में "रोलबैक" का मतलब क्या है। यह पिछले ऐप वर्शन को डिप्लॉय करना हो सकता है, किसी कॉन्फ़िग बदलाव को revert करना हो सकता है, या डेटाबेस स्थिति को restore करना हो सकता है। AppMaster जैसी प्लेटफ़ॉर्म पर एक "वर्शन" में बैकएंड लॉजिक, वेब UI, मोबाइल बिल्ड्स, और एनवायरनमेंट सेटिंग्स शामिल हो सकती हैं।

इन जोखिम चेक्स का उपयोग करें यह तय करने के लिए कि रोलबैक सुरक्षित है या नहीं:

• डेटाबेस स्कीमा परिवर्तन: अगर पुराना वर्शन अलग तालिकाएँ या फ़ील्ड्स अपेक्षित करता है तो रोलबैक फेल हो सकता है।
• अपरिवर्तनीय डेटा लिखावटें: refunds, status changes, या भेजे गए संदेश वापस नहीं किए जा सकते।
• Queued जॉब्स और webhooks: पुराना लॉजिक आइटम्स को फिर से प्रोसेस कर सकता है या नए payloads पर फेल हो सकता है।
• बाहरी निर्भरताएँ: पेमेंट, ईमेल/SMS, या Telegram इंटीग्रेशन व्यवहार बदल चुके हो सकते हैं।

कुछ छेड़छाड़ करने से पहले एक सरल go/no-go नियम सेट करें। 2-3 मेट्रिक्स चुनें जो कार्रवाई के 10-15 मिनट में सुधरनी चाहिए, जैसे error rate, login success, checkout completion, या API latency। अगर वे सही दिशा में नहीं गए तो रुकें और रणनीति बदलें।

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

इंसिडेंट के दौरान संचार

चुप्पी इंसिडेंट्स को और बुरा बनाती है। टीम जांच करते समय लोगों को सूचित रखने के लिए एक सरल, दोहराने योग्य तरीका अपनाएँ।

आंतरिक अपडेट्स से शुरू करें। उन लोगों को बताएं जो पहले प्रश्न पूछेंगे, और जो blockers हटा सकते हैं। इसे संक्षेप और तथ्यात्मक रखें। आमतौर पर आपको चाहिए:

• सपोर्ट/कस्टमर सक्सेस: उपयोगकर्ता क्या देख रहे हैं और अभी क्या कहना है
• सेल्स/अकाउंट टीमें: कौन से अकाउंट प्रभावित हैं और क्या वादे न करें
• बिल्डर्स/इंजीनियरिंग: क्या बदला, क्या रोलबैक हो रहा है, कौन काम कर रहा है
• एक exec संपर्क बिंदु: प्रभाव, जोखिम, अगला अपडेट समय
• बाहरी संदेश के लिए एक अनुमति देने वाला मालिक

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

सरल संदेश टेम्पलेट्स

एक स्टेटस लाइन सभी चैनलों में एकसमान रखें:

• Status: Investigating | Identified | Mitigating | Monitoring | Resolved
• Impact: "कुछ उपयोगकर्ता लॉग इन नहीं कर पा रहे" या "नए ऑर्डर्स के लिए भुगतान फेल हो रहे हैं"
• Workaround: "10 मिनट बाद पुन: प्रयास करें" या "वेब डाउन है तो मोबाइल ऐप उपयोग करें" (सिर्फ़ अगर सच हो)
• Next update: "अगला अपडेट 14:30 UTC पर"

अगर उपयोगकर्ता नाराज़ हों, तो पहले स्वीकार करें, फिर विशेष बनें: "हम जानते हैं कि कुछ ग्राहकों के लिए चेकआउट fail हो रहा है। हम अभी अंतिम बदलाव को रोलबैक कर रहे हैं। अगला अपडेट 30 मिनट में मिलेगा।" इंसिडेंट के दौरान समयसीमा, क्रेडिट्स, या स्थायी फिक्स का वादा न करें।

Resolved बनाम Monitoring

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

कारण का निदान: जल्दी किए जाने वाले चेक जो संदेह घटाते हैं

एक बार चीजें स्थिर हो गईं, firefighting से हटकर उन सबसे छोटे तथ्यों को इकट्ठा करना शुरू करें जो लक्षणों की व्याख्या करते हैं। लक्ष्य परफेक्ट रूट कॉज़ नहीं है—यह एक संभावित कारण है जिस पर आप बिना इंसिडेंट को बिगाड़े कार्रवाई कर सकें।

विभिन्न लक्षण अलग शकियों की ओर संकेत करते हैं। धीमे पेज अक्सर धीमी DB क्वेरी, अचानक ट्रैफ़िक spike, या बाहरी सर्विस लेट होने का संकेत देते हैं। टाइमआउट्स किसी अटकी प्रक्रिया, ओवरलोडेड बैकएंड, या लम्बे इंतज़ार वाली इंटीग्रेशन से आ सकते हैं। एरर या retries में spike अक्सर हालिया बदलाव, खराब इनपुट, या अपस्ट्रीम आउटेज से जुड़ा होता है।

तेज़ चेक (15 मिनट)

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

कुछ मुख्य चेक्स पर ध्यान दें:

• एक यात्रा reproduce करें: साइन इन करें, मुख्य क्रिया करें, परिणाम की पुष्टि करें।
• धीमे/फेल हो रहे स्टेप को चिन्हित करें: पेज लोड, API कॉल, डेटाबेस सेव, webhook।
• हाल के डेटा की जाँच करें: पिछले 20-50 रिकॉर्ड्स स्कैन करें duplicate, missing fields, या totals के लिए।
• इंटीग्रेशन्स validate करें: हालिया पेमेंट प्रयास (उदाहरण के लिए, Stripe), webhook delivery, और कोई भी मैसेजिंग (ईमेल/SMS या Telegram)।
• चेंज संदर्भ की पुष्टि करें: स्पाइक से ठीक पहले क्या रिलीज़ हुआ, कॉन्फ़िग किया गया, या माइग्रेट किया गया?

अगर आप AppMaster पर हैं, तो यह अक्सर Business Process स्टेप, Data Designer बदलाव, या डिप्लॉयमेंट कॉन्फ़िग बदलाव से सीधा जुड़ता है।

निर्णय: mitigation बनाए रखें या आगे फिक्स करें

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

उदाहरण परिदृश्य: व्यावसायिक घंटे में विफल रिलीज

यह मंगलवार की सुबह 10:15 है। टीम ने AppMaster पर बने कस्टमर पोर्टल में एक छोटा बदलाव भेजा। कुछ ही मिनटों में, उपयोगकर्ताओं को लॉगिन के बाद खाली पेज दिखने लगे, और नए ऑर्डर आना बंद हो गए।

सपोर्ट को तीन टिकट मिले जिनमें वही संदेश था: "लॉगिन होता है, फिर पोर्टल लोड ही नहीं होता।" साथ ही मॉनिटरिंग में वेब ऐप पर 500 त्रुटियों का spike और सफल API कॉल्स में गिरावट दिखी। आप इसे एक वास्तविक इंसिडेंट मानते हैं।

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

पहले 30 मिनट इस तरह दिख सकते हैं:

• Contain: पोर्टल को मेंटेनेंस मोड में रखें (या प्रभावित फीचर फ्लैग अस्थायी रूप से डिसेबल करें) ताकि और उपयोगकर्ता टूटे हुए फ्लो को न मारें।
• Decide rollback: अगर विफलता रिलीज़ के ठीक बाद शुरू हुई और अनेक उपयोगकर्ता प्रभावित हैं, तो पहले रोलबैक करें।
• Communicate: एक छोटा आंतरिक अपडेट पोस्ट करें (क्या टूटा, प्रभाव, वर्तमान कार्रवाई, अगला अपडेट समय)। एक संक्षेप ग्राहक संदेश भेजें कि हम aware हैं और काम कर रहे हैं।
• Recover: अंतिम ज्ञात अच्छे वर्शन को redeploy करें (या विशिष्ट मॉड्यूल revert करें)। लॉगिन, डैशबोर्ड लोड, और एक मुख्य क्रिया जैसे "टिकट बनाना" या "ऑर्डर देना" का फिर से परीक्षण करें।
• Monitor: 10-15 मिनट के लिए error rate, login success, और सपोर्ट टिकट वॉल्यूम देखें इससे पहले कि इसे स्थिर घोषित करें।

10:40 तक त्रुटियाँ सामान्य पर लौट आती हैं। आप मेट्रिक्स पर नजर रखते हैं जबकि सपोर्ट पुष्टि करता है कि नए टिकट धीमे हो गए हैं।

बाद में, टीम एक छोटा रिव्यू करती है: किसने सबसे पहले पकड़ा (alerts बनाम सपोर्ट), क्या धीमा किया (मालिक का अभाव, अस्पष्ट रोलबैक स्टेप्स), और क्या बदलना है। एक सामान्य सुधार पोर्टल के शीर्ष तीन फ्लोज़ के लिए रिलीज़ स्मोक-टेस्ट चेकलिस्ट जोड़ना और रोलबैक को एक दस्तावेजीकृत, एक-एक्शन स्टेप बनाना होता है।

सामान्य गलतियाँ जो इंसिडेंट्स को और बुरा बनाती हैं

अधिकांश इंसिडेंट्स दो कारणों से बिगड़ते हैं: लोग सिस्टम को नुकसान पहुंचाने देते हैं जबकि वे जांच कर रहे होते हैं, या वे बहुत जल्दी बहुत सारे बदलाव कर देते हैं। यह रनबुक इन दोनों से आपको बचाने के लिए है।

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

एक और जाल अनुमान लगाकर "फिक्स" करना है। जब कई लोग इधर-उधर क्लिक करते हैं और सेटिंग्स बदलते हैं, तो आप टाइमलाइन खो देते हैं। छोटी-छोटी संपादना भी इंसिडेंट के दौरान मायने रखती हैं। एक ड्राइवर पर सहमत हों, एक सरल चेंज लॉग रखें, और अज्ञातों के ऊपर कई बदलाव stacking से बचें।

बार-बार होने वाली गलतियाँ जो लंबे आउटेज पैदा करती हैं:

• पहले containment किए बिना जांच करना, जबकि खराब writes या duplicate actions जारी हैं
• बिना नोट्स के एक साथ कई बदलाव करना, ताकि यह पता न चले कि क्या मदद किया या नुकसान पहुँचाया
• संचार में देरी करना, या vague अपडेट भेजना जो अधिक प्रश्न और भरोसा कमजोर कर देते हैं
• डेटाबेस स्थिति और queued jobs, emails, या webhooks की जांच किए बिना अन्धाधुंध रोलबैक करना
• सत्यापन चरण के बिना इंसिडेंट समाप्त करना

संचार रिकवरी का हिस्सा है। जो आप जानते हैं, जो आप नहीं जानते, और अगला अपडेट कब होगा, यह शेयर करें। "हम रोलबैक कर रहे हैं और 15 मिनट में बिलिंग ईवेंट्स सही हैं यह पुष्टि करेंगे" कहना "हम इसे देख रहे हैं" से बेहतर है।

केवल इसलिए कि त्रुटियाँ रुक गईं, इंसिडेंट बंद न करें। एक छोटा चेकलिस्ट के साथ सत्यापित करें: प्रमुख स्क्रीन लोड होती हैं, नए रिकॉर्ड सही तरीके से सेव होते हैं, महत्वपूर्ण ऑटोमेशन्स एक बार चलते हैं, और बैकलॉग (queues, retries, scheduled jobs) drained या सुरक्षित रूप से paused हैं।

दबाव में चलाने योग्य तेज़ चेकलिस्ट

जब चीजें टूटें, आपका दिमाग एक साथ दस कार्य करने की कोशिश करेगा। इसका उपयोग करके शांत रहें, लोगों को सुरक्षित रखें, और सेवा वापस लाएँ।

इस अनुभाग को उस जगह पिन करें जहाँ आपकी टीम वास्तव में इसे देख सके।

• पुष्टि करें कि यह वास्तविक है और प्रभाव स्कोप करें (5 मिनट): जाँचें क्या alerts उपयोगकर्ता रिपोर्ट से मिलते हैं। लिखें कि क्या fail हो रहा है (लॉगिन, चेकआउट, एडमिन पैनल), कौन प्रभावित है, और कब से। अगर हो सके तो एक clean session में reproduce करें (incognito या टेस्ट अकाउंट)।

एक मिनट लें और एक इंसिडेंट मालिक नाम दें। एक व्यक्ति निर्णय लेता है, बाकी लोग सपोर्ट करते हैं।

• स्थिर करें और contain करें (10 मिनट): रूट कारण खोजने से पहले खून रोकें। रिस्की पाथ (feature toggle, अस्थायी बैनर, queue pauses) को disable करें और एक प्रमुख यात्रा end-to-end टेस्ट करें। व्यवसाय के लिए सबसे ज्यादा मायने रखने वाली यात्रा चुनें, न कि जो सबसे आसान है।

• सेवा रिकवर करें (10-20 मिनट): सबसे सुरक्षित कदम चुनें: अंतिम ज्ञात अच्छे वर्शन पर rollback करें या एक न्यूनतम फिक्स लागू करें। AppMaster जैसे प्लेटफ़ॉर्म पर यह पिछले बिल्ड को redeploy करना या अंतिम बदलाव को revert करना हो सकता है, फिर error rates और response times सामान्य होने की पुष्टि करें।

• संचार (लगातार): क्या प्रभावित है, उपयोगकर्ताओं को क्या करना चाहिए, और अगला अपडेट कब होगा यह बताते हुए संक्षेप status अपडेट पोस्ट करें। सपोर्ट को दो-लाइन स्क्रिप्ट दें ताकि सब एक ही बात कहें।

• साफ-सुथरा समापन (भूलने से पहले): क्या हुआ, आपने क्या बदला, और सेवा कब recovered हुई यह रिकॉर्ड करें। अगले कदम असाइन करें जिनके मालिक और ड्यू डेट हों (मॉनिटरिंग ट्वीक, टेस्ट गैप, डेटा क्लीनअप, फॉलो-अप फिक्स)।

इंसिडेंट के बाद: सीखें, फिक्स करें, और पुनरावृत्ति रोकें

जब ऐप वापस up हो जाए तब भी इंसिडेंट पूरी तरह "खत्म" नहीं माना जाता। भविष्य के डाउनटाइम को कम करने का सबसे तेज़ तरीका यह है कि घटना के ताज़ा होने पर जो हुआ उसे पकड़ें और फिर उस सीख को छोटे, वास्तविक बदलावों में बदल दें।

2-5 दिनों के भीतर एक छोटा पोस्ट-इंसिडेंट रिव्यू शेड्यूल करें। इसे blameless और व्यावहारिक रखें। लक्ष्य किसी को दोष देना नहीं है, बल्कि अगली बार इंसिडेंट को आसान बनाना है।

एक रिकॉर्ड लिखें जिसे कोई महीनों बाद पढ़ सके: उपयोगकर्ताओं ने क्या देखा, आपने कब इसका पता लगाया, क्या कोशिश की, क्या काम आया, और सेवा कब वापस आई। अगर आप रूट कॉज़ जानते हैं तो उसे शामिल करें, और योगदान कारक जैसे missing alerts, अस्पष्ट ownership, या भ्रमित करने वाले rollout steps को नोट करें।

सीखों को कार्यों में बदलें जिनके मालिक और ड्यू डेट हों। उन सबसे छोटे बदलावों पर ध्यान दें जो वही विफलता रोकते हैं:

• मॉनिटरिंग gaps बंद करें (एक अलर्ट या डैशबोर्ड चेक जोड़ें जो इसे पहले पकड़ लेता)
• एक गार्डरेल जोड़ें (वैलिडेशन नियम, rate limit, फीचर फ्लैग default, approval step)
• रिस्की एरिया के लिए टेस्ट बेहतर करें (लॉगिन, पेमेंट्स, डेटा इम्पोर्ट, permissions)
• रनबुक को उन सटीक स्टेप्स से अपडेट करें जो आप चाहते थे कि वो हों
• ऑन-कॉल या ऐप मालिकों के लिए एक छोटा प्रशिक्षण refresher करें

प्रति इंसिडेंट एक रोकथाम उपाय चुनें, भले ही यह छोटा हो। "रोल्स में किसी भी बदलाव के लिए दूसरा reviewer चाहिए" या "डेटा माइग्रेशन्स पहले स्टेजिंग कॉपी पर चलनी चाहिए" जैसी नीतियाँ दोबारा आउटेज रोक सकती हैं।

इस रनबुक को अपने बिल्ड और रिलीज़ प्रक्रिया के पास रखें। अगर आप AppMaster के साथ बना रहे हैं, तो लिखें कि हर ऐप कहाँ डिप्लॉय है (AppMaster Cloud, AWS, Azure, Google Cloud, या self-hosted), कौन जल्दी redeploy कर सकता है, और कौन रोलबैक कर सकता है। एक ही जगह यह दस्तावेज रखना आसान बनाता है ताकि मिनटों में मिल सके।