स्टेटस पेज कैसे बनाएं: कंपोनेंट, इंसिडेंट और अपटाइम चेक

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

स्टेटस पेज किसलिए है

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

यह चेंजलॉग नहीं है। नए फीचर चेंजलॉग पेज पर जाते हैं; आउटेज और मेंटेनेंस यहां।

पेज को क्या चाहिए

डेटा

कंपोनेंट स्टेटस आमतौर पर एक छोटी तय सूची होती है: Operational, Degraded performance, Partial outage, Major outage, Under maintenance।

पेज

• पब्लिक स्टेटस पेज: एक समग्र बैनर ("सभी सिस्टम चालू हैं" या सबसे खराब मौजूदा स्टेटस), हर कंपोनेंट का स्टेटस, कोई सक्रिय इंसिडेंट उसके अपडेट के साथ, आगामी मेंटेनेंस, और अगर चेक डेटा है तो 90 दिन की हिस्ट्री स्ट्रिप।
• इंसिडेंट पेज: एक इंसिडेंट के सभी अपडेट की पूरी टाइमलाइन, जिसका अपना URL हो ताकि सपोर्ट उसे लिंक कर सके।
• इतिहास: पिछले इंसिडेंट महीने के हिसाब से।
• सब्सक्राइब: कन्फर्मेशन और हर कंपोनेंट की पसंद के साथ ईमेल साइन-अप।
• एडमिन: इंसिडेंट बनाएं, अपडेट पोस्ट करें, कंपोनेंट स्टेटस बदलें, मेंटेनेंस शेड्यूल करें।

अनुमतियां

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

मुख्य फैसला: इसे स्वतंत्र रखें

ज़्यादातर घर पर बने स्टेटस पेज यहीं फेल होते हैं। अगर आपका स्टेटस पेज:

• आपके ऐप वाले ही सर्वर या होस्टिंग अकाउंट पर चलता है,
• आपके ही डेटाबेस से पढ़ता है,
• वही डोमेन सेटअप या CDN कॉन्फ़िगरेशन इस्तेमाल करता है,
• या उसी पाइपलाइन से डिप्लॉय होता है,

तो कई आउटेज उसे भी ले डूबेंगे, ठीक तब जब लोगों को उसकी ज़रूरत होगी। व्यावहारिक कदम:

• अलग होस्टिंग। मुख्य ऐप से अलग प्रोजेक्ट या प्रोवाइडर।
• अपना सबडोमेन, जैसे status.example.com, DNS में अलग से पॉइंट किया हुआ। देखें डोमेन और DNS कैसे काम करते हैं।
• अपना डेटा। इंसिडेंट स्टेटस पेज के अपने स्टोरेज में रहें, आपके ऐप के डेटाबेस में नहीं।
• स्टेटिक फॉलबैक। कुछ टीमें पब्लिक पेज को स्टेटिक बनाती हैं और हर अपडेट पर दोबारा बनाती हैं, ताकि टूटने को लगभग कुछ न बचे।

मैनुअल अपडेट या ऑटोमेटेड चेक

मैनुअल (यहां से शुरू करें)

आपकी टीम एडमिन पेज से हाथ से इंसिडेंट पोस्ट करती है और कंपोनेंट स्टेटस बदलती है। असल में कई स्टेटस पेज ऐसे ही चलते हैं, क्योंकि इंसान का आकलन ("कुछ कार्ड प्रकार के लिए पेमेंट धीमे हैं") एक ऑटोमेटिक लाल बिंदु से ज़्यादा उपयोगी होता है।

समस्याओं का जल्दी पता चले, इसके लिए एक बाहरी अपटाइम मॉनिटर इस्तेमाल करें जो आपके ऐप को हर मिनट के आसपास जांचे और ईमेल, SMS या चैट पर अलर्ट करे। कई मॉनिटरिंग सेवाओं में फ्री टियर होता है।

ऑटोमेटेड

ऑटोमेशन का मतलब है कि कोई नियमित रूप से हर कंपोनेंट की जांच करे और उसका स्टेटस अपडेट करे। इसके लिए ऐसा कोड चाहिए जो शेड्यूल पर चले और आपके मुख्य ऐप के इन्फ्रास्ट्रक्चर से बाहर से चले। दो आम तरीके:

• एक बाहरी मॉनिटर आपके स्टेटस पेज को webhook के ज़रिए कॉल करता है जब कोई जांच फेल हो या ठीक हो, और स्टेटस पेज कंपोनेंट अपडेट कर देता है।
• स्टेटस पेज की अपनी होस्टिंग में एक शेड्यूल्ड जॉब हर कंपोनेंट को पिंग करता है और नतीजा दर्ज करता है। भरोसा करने से पहले जांचें कि आपकी होस्टिंग शेड्यूल्ड टास्क कैसे संभालती है; बैकग्राउंड जॉब चलाने पर हमारी गाइड विकल्प समझाती है।

ऑटोमेटिक बदलाव धीमे नेटवर्क पर फ्लैप कर सकते हैं (ऊपर, नीचे, फिर ऊपर)। स्टेटस बदलने से पहले दो-तीन लगातार फेल जांच रखें, और बड़े आउटेज की घोषणा से पहले इंसान से पुष्टि करवाएं।

इंसिडेंट अपडेट कैसे लिखें

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

पहला प्रॉम्प्ट जो काम करता है

Parcelio ऐप के लिए एक स्टैंडअलोन स्टेटस पेज बनाओ, जो status.parcelio.com पर अलग से होस्ट होगा। कंपोनेंट: Website, Tracking API, Notifications, Payments, हर एक का स्टेटस Operational, Degraded performance, Partial outage, Major outage या Under maintenance। पब्लिक पेज पर सबसे खराब मौजूदा स्टेटस वाला समग्र बैनर, हर कंपोनेंट का स्टेटस, सक्रिय इंसिडेंट समय-चिह्न वाले अपडेट के साथ (सबसे नए पहले), आगामी मेंटेनेंस, और महीने के हिसाब से पिछले इंसिडेंट की सूची दिखाओ। हर इंसिडेंट का अपना पेज हो। पासवर्ड-संरक्षित एडमिन पेज जोड़ो जिससे इंसिडेंट बनाए जा सकें (शीर्षक, प्रभाव, प्रभावित कंपोनेंट), अपडेट पोस्ट किए जा सकें (संदेश और स्टेटस: Investigating, Identified, Monitoring, Resolved), कंपोनेंट स्टेटस बदले जा सकें और मेंटेनेंस शेड्यूल किया जा सके। एक POST /api/check-result एंडपॉइंट जोड़ो जो बाहरी मॉनिटर से कंपोनेंट का नाम और up/down ले, एक सीक्रेट टोकन से सुरक्षित हो, और कंपोनेंट को Degraded तभी करे जब लगातार तीन down आएं। सब कुछ इसी ऐप के अपने डेटाबेस में रखो। सरल, शांत डिज़ाइन जो फोन पर तेज़ लोड हो।

बिल्ड स्टेप

1. पब्लिक पेज और मैनुअल इंसिडेंट वाला एडमिन। बस इतना भी एक काम करने वाला स्टेटस पेज है।
2. इसे अलग से होस्ट करें और एक सबडोमेन उस पर पॉइंट करें।
3. इंसिडेंट पेज और इतिहास।
4. मेंटेनेंस विंडो।
5. सब्सक्रिप्शन। डबल ऑप्ट-इन ईमेल साइन-अप और नए इंसिडेंट व अपडेट पर नोटिफिकेशन। ईमेल के लिए एक प्रोवाइडर चाहिए; देखें अपने ऐप से ईमेल कैसे भेजें।
6. मॉनिटर वेबहुक अगर आप ऑटोमेटिक स्टेटस बदलाव चाहते हैं।
7. ड्रिल चलाएं। एक नकली इंसिडेंट बनाएं, अपडेट पोस्ट करें, उसे हल करें, ईमेल जांचें, फिर उसे हटाएं।

आम गलतियां

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

कब तैयार होस्टेड स्टेटस पेज सेवा बेहतर है

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

अपना बनाएं जब आपको डिज़ाइन और शब्दों पर पूरा नियंत्रण चाहिए, जब ज़रूरतें सरल हों (कुछ कंपोनेंट, मैनुअल अपडेट), या जब स्टेटस पेज दूसरों के लिए बनाए जा रहे किसी प्रोडक्ट का हिस्सा हो।

Mythex पर इसे बनाना

Mythex पर आप स्टेटस पेज को अपने मुख्य ऐप से अलग प्रोजेक्ट के रूप में बना सकते हैं, जिससे उसकी अलग होस्टिंग और अपना डेटाबेस होगा। चैट में उसका वर्णन करें, लाइव प्रीव्यू में जांचें, फिर पब्लिश करें और status.yourdomain.com जैसा सबडोमेन जोड़ें (कस्टम डोमेन Pro पर उपलब्ध हैं)। ध्यान रखें कि पब्लिश्ड Mythex ऐप और उनके डेटाबेस इस्तेमाल न होने पर सो जाते हैं और अगली विज़िट पर जागते हैं, इसलिए शांत अवधि के बाद पहला लोड धीमा हो सकता है; एक सरल, हल्का पेज इसमें मदद करता है।

Mythex शेड्यूल्ड जॉब्स का दस्तावेज़ नहीं देता, इसलिए ऑटोमेटेड चेक के लिए अपने स्टेटस पेज में एक वेबहुक एंडपॉइंट कॉल करने वाला बाहरी अपटाइम मॉनिटर इस्तेमाल करें (webhooks रेसिपी देखें)। सब्सक्राइबर को ईमेल अलर्ट आपके अपने प्रोवाइडर से जाते हैं, जिसकी key प्रोजेक्ट सीक्रेट के रूप में रखी जाती है (ईमेल भेजने की रेसिपी)।

सवाल