जब आपका प्रदाता डाउन हो जाए
अंतिम अपडेट:
प्रदाता स्थिति पृष्ठ वह सार्वजनिक डैशबोर्ड है जिसे क्लाउड, होस्टिंग, कोड या भुगतान प्रदाता अपने स्वयं के स्वास्थ्य की घोषणा करने के लिए बनाए रखता है: एक समग्र संकेतक, घटकों की एक सूची, और घटनाओं की एक समयरेखा जो प्रदाता स्वयं तब लिखता है जब वे घटनाएँ अभी भी चल रही होती हैं। इसे अच्छी तरह पढ़ना एक ऑपरेटर कौशल है, क्योंकि शीर्षक एक सारांश है और सत्य उसके नीचे रहता है — किस घटक को प्रभावित किया गया है, किस क्षेत्र में, किस घोषित प्रभाव पर, और घटना प्रदाता के अपने वर्कफ़्लो में कितनी आगे बढ़ चुकी है। यह लेख वह पढ़ना सिखाता है, और अंत में बताता है कि जब प्रश्नगत प्रदाता वह हो जिस पर आप निर्भर हैं, तो पहले दस मिनटों में क्या करना है। प्रदाता स्थिति बोर्ड से शुरू करें, जो प्रमुख प्रदाताओं के पृष्ठों को एक स्नैपशॉट में इकट्ठा करता है, और पूरे समय क्या यह डाउन है, या यह सिर्फ़ आप हैं? के प्रश्न को मन में रखें: दोनों उपकरण एक ही संदेह के विपरीत आधों का उत्तर देते हैं।
दो अलग-अलग चीज़ें: संकेतक और घटना की स्थिति
हर परिपक्व स्थिति पृष्ठ दो अलग-अलग संकेत लिए होता है जिन्हें पाठक लगातार भ्रमित करते हैं। पहला है समग्र संकेतक: पूरी सेवा के लिए एक एकल सारांशित स्थिति, पृष्ठ के पीछे के मशीन-पठनीय फ़ीड में आम तौर पर none, minor, major, critical या maintenance में से एक — वह मॉडल जो Statuspage डेवलपर दस्तावेज़ में दर्ज है, जिसे अधिकांश बड़े प्रदाता या तो सीधे उपयोग करते हैं या बारीकी से अनुकरण करते हैं। संकेतक जानबूझकर मोटा है। यह इसलिए मौजूद है ताकि एक व्यस्त पाठक — या हमारी स्थिति बोर्ड जैसी मशीन — एक सेकंड में उत्तर दे सके कि “क्या वहाँ कुछ गड़बड़ है?”, और इसकी गणना सबसे अधिक प्रभावित घटक, प्रदाता के अपने निर्णय, या दोनों से की जाती है।
दूसरा संकेत है स्वयं घटना, और इसका अपना जीवनचक्र है जिसे संकेतक चपटा कर देता है। कोई घटना एक नाम, एक घोषित प्रभाव और वर्कफ़्लो से ली गई एक स्थिति के साथ खुलती है: जाँच चल रही है (हम लक्षण देखते हैं और कारण अभी नहीं जानते), पहचाना गया (हम कारण जानते हैं और उस पर काम कर रहे हैं), निगरानी में (एक सुधार बाहर आ गया है और हम देख रहे हैं कि वह टिकता है या नहीं) और हल हो गया (हम मानते हैं कि यह समाप्त हो गया है, पोस्टमॉर्टम के अधीन)। ये स्थितियाँ वह जानकारी लिए होती हैं जो संकेतक नहीं ले सकता। दो घंटे से निगरानी में चल रही एक गंभीर घटना आम तौर पर समाप्त हो रही होती है; चार मिनट पहले जाँच में गई एक minor घटना अभी कुछ भी बन सकती है।
दोनों को, उसी क्रम में पढ़ें, और उनके बीच के अपडेट पढ़ें। घटना के नीचे छोटी अपडेटों की समयरेखा वह जगह है जहाँ प्रदाता आपको वे बातें बताता है जो शीर्षक कभी नहीं बताएगा: कौन-सा उपतंत्र विफल हुआ, कौन-सा वैकल्पिक उपाय मौजूद है, क्या प्रभावित डेटा है या केवल उपलब्धता, और अगला अपडेट बीस मिनट में वादा किया गया है या दो घंटे में। जिस घटना के अपडेट आना बंद हो जाएँ, वह स्वयं एक संकेत है — या तो टीम अभिभूत है, जो लंबे आउटेज से सहसंबंधित है, या घटना चुपचाप एक बड़ी घटना में समा गई है। शीर्षक का स्क्रीनशॉट लेकर पढ़ना बंद कर देने वाले ऑपरेटर नियमित रूप से पृष्ठ के सबसे कम सूचनात्मक वाक्य पर कार्य करते हैं।
क्यों “सभी सिस्टम चालू” का अर्थ फिर भी यह हो सकता है कि आप डाउन हैं
संकेतक पूरी सेवा का सारांश देता है, और आधुनिक सेवाएँ एक चीज़ नहीं होतीं। कोई प्रदाता वैश्विक स्तर पर ईमानदारी से हरा हो सकता है जबकि वह क्षेत्र जहाँ आप डिप्लॉय करते हैं, वह एक उत्पाद सतह जिसे आप कॉल करते हैं, वह विरासत API संस्करण जिससे आप बँधे हैं, या वह नियंत्रण तल जिसकी आपको डिप्लॉय के लिए ज़रूरत है, उसे छूने वाले हर ग्राहक के लिए विफल हो रहा हो। घटक सूचियाँ ठीक इसी कारण मौजूद हैं: GitHub का स्थिति पृष्ठ जैसी कोई पृष्ठ सेवा को Git संचालन, API अनुरोध, Actions, Pages और अधिक में तोड़ती है, और उनमें से कोई भी उस समय गिरावट में हो सकता है जब समग्र बैनर आश्वस्त करने वाला बना रहे — या इसका उल्टा, किसी ऐसे घटक के लिए बैनर लाल हो जिसे आपने कभी उपयोग ही नहीं किया।
तीन और शांत अंतराल भी हैं। पहला, घोषणा में विलंब: प्रदाता किसी घटना की घोषणा तब करता है जब उसने उसकी पुष्टि कर ली हो, न कि तब जब पहली त्रुटि हुई हो, इसलिए कई आउटेज के पहले मिनट हरा पृष्ठ और जलती हुई सोशल फ़ीड दिखाते हैं; पृष्ठ झूठ नहीं बोल रहा, वह बस पीछे है। दूसरा, दहलीज़ें: कोई प्रदाता एक स्तर पर दो प्रतिशत त्रुटि दर को सामान्य पृष्ठभूमि मान सकता है और कभी कुछ घोषित नहीं करता, जबकि वह दो प्रतिशत ठीक आपके ट्रैफ़िक पैटर्न पर केंद्रित है। तीसरा, दायरा: स्थिति पृष्ठ तार के प्रदाता वाले पक्ष का वर्णन करते हैं। आपके उपयोगकर्ताओं और एक स्वस्थ प्रदाता के बीच DNS विफलता, रूटिंग समस्या या अवरुद्ध पथ हरे संकेतक के नीचे आपके लिए पूर्ण आउटेज पैदा करता है — और यही कारण है कि साथी प्रश्न, क्या यह डाउन है या यह सिर्फ़ आप हैं, का उत्तर स्वतंत्र सुविधाजनक बिंदुओं से दिया जाना चाहिए, प्रदाता के अपने पृष्ठ से नहीं।
कार्य नियम है कि हरे को “कोई घोषित घटना नहीं” के रूप में मानें, कभी “स्वास्थ्य सिद्ध” के रूप में नहीं। जब आपकी अपनी निगरानी कहती है कि उपयोगकर्ता विफल हो रहे हैं और प्रदाता कहता है चालू, तो अपने उपयोगकर्ताओं के संबंध में अपनी निगरानी पर विश्वास करें और स्थिति पृष्ठ का उपयोग दूसरे काम के लिए करें: यह जाँचना कि क्या बाद में कोई घोषणा आती है, जो कारण की पूर्वव्यापी पुष्टि करती है, और क्या जिस घटक पर आप निर्भर हैं उसके पास उसी आकार की घटनाओं का इतिहास है जिससे आप गुज़र रहे हैं।
पृष्ठों के नहीं, घटकों के सदस्य बनें
अधिकांश ऑपरेटर स्थिति पृष्ठ की सदस्यता उसी तरह लेते हैं जैसे वे किसी न्यूज़लेटर की लेते हैं: एक सदस्यता, हर घटना, हमेशा के लिए — और फिर, अनुमानतः, मेल को नज़रअंदाज़ करना शुरू कर देते हैं, क्योंकि किसी बड़े प्रदाता की वैश्विक फ़ीड उन घटकों के लिए घटनाओं की स्थिर बूँदाबाँदी पैदा करती है जिनका वे उपयोग नहीं करते, उन क्षेत्रों में जिनकी वे सेवा नहीं करते। अलर्ट थकान चरित्र की खामी नहीं है; यह ख़राब दायरे वाले संकेत की सही प्रतिक्रिया है। सुधार यांत्रिक है और लगभग हर परिपक्व स्थिति पृष्ठ पर उपलब्ध है: घटक स्तर पर सदस्यता लें। वही Statuspage मॉडल जो संकेतकों को परिभाषित करता है, सदस्यों को घटक द्वारा फ़िल्टर करने भी देता है, और अपनी प्रणालियाँ चलाने वाले प्रदाता, जैसे Cloudflare का स्थिति पृष्ठ, अपनी सदस्यता प्रवाहों के माध्यम से वही विकल्प देते हैं।
प्रत्येक सदस्यता का दायरा उस तक सीमित रखें जो रात के 3 बजे वास्तव में आपके व्यवहार को बदलेगा। जिन घटकों को आपका उत्पादन ट्रैफ़िक कॉल करता है वे शोर वाले चैनल से संबंधित हैं — वह जो पेज करता है, संदेश भेजता है या कम से कम कुछ ऐसा चिह्नित करता है जिसे आप मिनटों के भीतर देखेंगे। जिन घटकों का आप केवल बिल्ड, विश्लेषण या आंतरिक उपकरणों के लिए उपयोग करते हैं वे एक शांत चैनल से संबंधित हैं जिसकी आप कार्य घंटों में समीक्षा करते हैं। जिन घटकों का आप उपयोग नहीं करते वे कहीं से संबंधित नहीं हैं: हर सूचना जिसे आप सही ढंग से नज़रअंदाज़ करते हैं, अगली को नज़रअंदाज़ करना आसान बनाती है, उस समेत जो मायने रखती है। जब भी स्टैक बदले सूची को फिर से देखें, क्योंकि सदस्यताएँ दोनों दिशाओं में सड़ती हैं — नई निर्भरताएँ जिनकी किसी ने सदस्यता नहीं ली, और मृत निर्भरताएँ जो अभी भी ऐसे चैनल को पेज कर रही हैं जिसे कोई नहीं देखता।
जहाँ संभव हो मशीन-पठनीय फ़ीड पसंद करें। ईमेल स्थिति पृष्ठ द्वारा दिया जाने वाला सबसे धीमा और सबसे अधिक नज़रअंदाज़ किया जाने वाला चैनल है; वेबहुक और फ़ीड आपके अपने डैशबोर्ड को चला सकते हैं, एक आंतरिक टिकट खोल सकते हैं, या पहले उपयोगकर्ता शिकायत के आने से पहले आपकी सहायता टीम के तैयार रखे गए पृष्ठ को पलट सकते हैं। हल्का संस्करण भी लाभ देता है: हमारे प्रदाता स्थिति बोर्ड पर स्नैपशॉट ठीक इन्हीं सार्वजनिक फ़ीड से बनाया गया है, जो साबित करता है कि डेटा वहाँ प्रोग्राम द्वारा उपभोग किए जाने के लिए है, किसी ऐसे ब्राउज़र टैब में सराहे जाने के लिए नहीं जिसे खोलना आपको याद रखना पड़े।
अपनी स्वयं की निर्भरता सूची बनाएँ
ऊपर की कोई भी सलाह सूची के बिना काम नहीं करती, और अधिकांश टीमों को आउटेज के दौरान पता चलता है कि उनके पास सूची नहीं है। निर्भरता सूची बस एक ऐसे प्रश्न का लिखित उत्तर है जो तुच्छ लगता है और है नहीं: कौन-सी बाहरी सेवाएँ, यदि वे आज रात रुक जाएँ, तो हमें रोक देंगी — और कौन-सी केवल हमें शर्मिंदा करेंगी? इसे शांत मौसम में बनाएँ। अपनी वास्तुकला को सतह दर सतह चलें — होस्टिंग, DNS, कोड होस्टिंग और CI, डेटाबेस और संग्रहण प्रदाता, भुगतान प्रोसेसर, ईमेल और SMS भेजने वाले, पहचान प्रदाता, त्रुटि ट्रैकर, विश्लेषण टैग, वे फ़ॉन्ट और स्क्रिप्ट जिन्हें आपके पृष्ठ किसी और के CDN से लोड करते हैं — और प्रत्येक के लिए लिखें: प्रदाता, वह घटक जिसका आप वास्तव में उपभोग करते हैं, उसका स्थिति पृष्ठ कहाँ रहता है, और जब वह विफल होता है तो आपके उपयोगकर्ता क्या अनुभव करते हैं।
प्रत्येक प्रविष्टि को उसके विफल होने के आकार के अनुसार रैंक करें, न कि इस अनुसार कि आप विक्रेता को कितना पसंद करते हैं। कुछ निर्भरताएँ कठोर होती हैं: यदि वे रुकती हैं, तो आप रुकते हैं, और उपलब्ध एकमात्र काम संचार और प्रतीक्षा है। कुछ नरम होती हैं: साइट उनके बिना चलती है, गिरावट के साथ — कोई विश्लेषण नहीं, कोई चैट विजेट नहीं, कोई निजीकरण नहीं — और उनके लिए, सूची को यह कहना चाहिए कि उन्हें कौन बंद कर सकता है और कैसे। और कुछ छिपी होती हैं: वे सकर्मक निर्भरताएँ जिन्हें आपने नहीं चुना, जैसे उस क्लाउड क्षेत्र की स्थिति जिसमें आपका अपना SaaS डेटाबेस चलता है, या हर चीज़ के नीचे प्रमाणपत्र और DNS बुनियादी ढाँचा। छिपी निर्भरताएँ वे हैं जो “सब कुछ डाउन है और जिस किसी चीज़ के लिए हम भुगतान करते हैं वह सूची में नहीं है” वाला आउटेज पैदा करती हैं, और आप उन्हें प्रत्येक विक्रेता से एक बार यह पूछकर खोजते हैं कि वे किस पर निर्भर हैं।
सूची को वहाँ रखें जहाँ कोई घटना उस तक पहुँच सके: रनबुक में, एस्केलेशन सूची के बगल में, किसी ऐसे विकी पृष्ठ पर नहीं जिसे तब कोई नहीं खोल सकता जब पहचान प्रदाता ही वह चीज़ हो जो डाउन है। एक पृष्ठ पर्याप्त है। आउटेज के दौरान इसका काम “कुछ गड़बड़ है” को एक चेकलिस्ट में बदलना है — प्रत्येक कठोर निर्भरता के लिए, तीस सेकंड में, ऊपर या नीचे — और उसके बाद इसका काम सुधारा जाना है, क्योंकि हर वास्तविक घटना आपको किसी ऐसी निर्भरता के बारे में कुछ सिखाती है जिसे आपने ग़लत रैंक किया था। जो सूची कभी सुधारी नहीं जाती वह एक ऐतिहासिक दस्तावेज़ है, परिचालन दस्तावेज़ नहीं।
प्रदाता आउटेज के पहले दस मिनट
मिनट शून्य से दो: पुष्टि करें और पता लगाएँ। अपनी स्वयं की निगरानी जाँचें ताकि सुनिश्चित हो कि विफलता वास्तविक है और घोषणा करना आपकी है, फिर स्थिति बोर्ड और संदिग्ध प्रदाता का पृष्ठ खोलें। आप एक प्रश्न का उत्तर दे रहे हैं: क्या कोई घोषित घटना है जो उस चीज़ से ओवरलैप करती है जिसका आप उपयोग करते हैं — घटक, क्षेत्र, उत्पाद? यदि हाँ, तो आपके पास आपका कारण और आपका पहला संदेश है। यदि नहीं, तो जाँच को चौड़ा करें: आपकी सूची का कोई और प्रदाता, आपका अपना अंतिम डिप्लॉय, आपका DNS। अधिकांश झूठे नाटक इन दो मिनटों में मर जाते हैं, और अधिकांश वास्तविक नाटक यहीं अपना आकार लेते हैं।
मिनट दो से पाँच: संचार करें, स्पष्ट रूप से और जल्दी। अपने उपयोगकर्ताओं को, उन चैनलों में जिन्हें वे वास्तव में पढ़ते हैं, बताएँ कि एक नामित अपस्ट्रीम प्रदाता में घटना चल रही है, इसका उनके लिए व्यावहारिक अर्थ क्या है — क्या काम नहीं करता, क्या अभी भी काम करता है, क्या उनका डेटा सुरक्षित है — और आप उन्हें अगली बार कब अपडेट करेंगे। मिनट चार पर भेजा गया एक ईमानदार रखे जाने वाला संदेश मिनट चालीस पर भेजी गई एक सटीक व्याख्या को हराता है, क्योंकि मौन वह है जिसे उपयोगकर्ता अपनी सबसे बुरी अटकलों और आपके प्रतिस्पर्धियों के नामों से भरते हैं। आंतरिक रूप से, एक घटना थ्रेड खोलें, बोलने के लिए एक व्यक्ति नियुक्त करें, और हर चीज़ पर समय की मुहर लगाएँ; आप पोस्टमॉर्टम में स्वयं को धन्यवाद देंगे, और प्रदाता की सहायता टीम भी, यदि आपको उनकी ज़रूरत पड़े।
मिनट पाँच से दस: इसे और बुरा बनाना बंद करें, और नरम लैंडिंग तैयार करें। डिप्लॉय को स्थिर करें — एक सक्रिय अपस्ट्रीम घटना के भीतर किया गया परिवर्तन मूल्यांकित नहीं किया जा सकता और शायद वापस भी न लिया जा सके। विफल हो रहे प्रदाता पर हमला करने वाले आक्रामक पुनः प्रयासों और अनावश्यक कार्यों को बंद करें; रिकवरी मापने योग्य रूप से धीमी होती है जब दस हज़ार क्लाइंट एक साथ पुनः प्रयास करते हैं, और कुछ प्रदाता आपको दर-सीमा करके दूसरी, स्वयं-थोपी गई आउटेज में डाल देंगे। उन नरम निर्भरताओं को बंद या गिरावट करें जिन्हें आपकी सूची ने छोड़ने योग्य चिह्नित किया था, यदि आपके पास रखा जाने वाला पृष्ठ है तो उसे पोस्ट करें, और फिर उस लय में स्थिर हो जाएँ जो घटना निर्धारित करती है: प्रदाता के अपडेटों की निगरानी करें, चाहे समाचार हो या न हो वादा किए गए समयों पर अपने उपयोगकर्ताओं को अपडेट करें, और तथ्य बदलने तक और कुछ न बदलें। आउटेज प्रदाता के कार्यक्रम पर समाप्त होगा, आपके पर नहीं; आपके दस मिनट तय करते हैं कि आपके उपयोगकर्ता इसे अपने प्रदाता के बुरे दिन के रूप में याद रखेंगे या आपके बुरे दिन के रूप में।