उपयोगकर्ता को दिखने वाले फ़ंक्शन की निगरानी करें, उसके निदान के लिए पर्याप्त संसाधन और एप्लिकेशन साक्ष्य जोड़ें, और केवल उन स्थितियों के लिए पेज करें जिनके लिए समय पर मानवीय कार्रवाई आवश्यक हो। प्रत्येक अलर्ट के साथ एक ज़िम्मेदार व्यक्ति, पहला कदम और एस्केलेशन जोड़ें। इंसिडेंट के दौरान, शमन का समन्वय करें, साक्ष्य की सुरक्षा करें और वास्तविक उपयोगकर्ता यात्रा के माध्यम से रिकवरी सत्यापित करें।
उस फ़ंक्शन से शुरू करें जो मायने रखता है
किसी सर्वर का पिंग पर प्रतिक्रिया देना यह सिद्ध नहीं करता कि उसका एप्लिकेशन काम करता है। एक प्रतिनिधि, हानिरहित उपयोगकर्ता यात्रा चुनें, जैसे कोई सार्वजनिक पृष्ठ प्राप्त करना या किसी नियंत्रित परीक्षण एंडपॉइंट तक पहुँचना। परिभाषित करें कि सफलता कैसी दिखती है और ऐसी सिंथेटिक जाँचों से बचें जो हर रन में वास्तविक ऑर्डर बनाएँ, सामग्री प्रकाशित करें या ग्राहक सूचनाएँ भेजें।
एप्लिकेशन के भीतर के साथ-साथ उपयुक्त बाहरी दृष्टिकोण से भी निगरानी करें। बाहरी अवलोकन उन एक्सेस या रूटिंग समस्याओं को उजागर कर सकता है जो सर्वर नहीं देखता। आंतरिक माप बता सकते हैं कि यात्रा क्यों विफल हुई। दोनों दृष्टिकोणों को फ़ंक्शन से जोड़े रखें, न कि केवल इसलिए बड़ा डैशबोर्ड एकत्र करें कि हर मेट्रिक उपलब्ध है।
नैदानिक मूल्य वाले सिग्नल चुनें
Google का SRE मार्गदर्शन उपयोगकर्ता-मुखी सिस्टम के लिए लेटेंसी, ट्रैफ़िक, त्रुटियों और सैचुरेशन को उपयोगी सिग्नल के रूप में रेखांकित करता है। इनका उपयोग व्यवहार का वर्णन करने के लिए करें: प्रतिक्रिया समय, अनुरोध मात्रा, असफल अनुरोध और सीमित संसाधनों पर दबाव। एप्लिकेशन के अनुकूल माप चुनें, यह न मानें कि एक मेट्रिक परिभाषा किसी वेबसाइट, ट्रांसफ़र सेवा और बैकग्राउंड वर्कर—सभी के लिए काम करती है।
जहाँ मायने रखे वहाँ सफल और असफल अनुरोध व्यवहार को अलग करें, और केवल औसत के बजाय धीमे-टेल परिणामों की जाँच करें। जब वे सेवा को समझाते हों तो मेमोरी दबाव, डिस्क स्थान, क्यू डेप्थ या एप्लिकेशन-विशिष्ट सीमाएँ जोड़ें। उपयोगी बैच कार्य के दौरान उच्च CPU रीडिंग सामान्य हो सकती है; उपयोगकर्ता को दिखने वाला प्रभाव तय करता है कि तत्काल कार्रवाई आवश्यक है या नहीं।
हर अलर्ट को एक कार्रवाई और एक ज़िम्मेदार व्यक्ति दें
अलर्ट में प्रभावित फ़ंक्शन, देखी गई स्थिति और उपयोगी पहली जाँच बताई जानी चाहिए। इसे तैनात करने से पहले एक ज़िम्मेदार व्यक्ति और एस्केलेशन मार्ग निर्धारित करें। तत्काल रुकावट चाहने वाली स्थितियों को निर्धारित समीक्षा के लिए उपयुक्त मदों से अलग करें। बार-बार आने वाले कम-मूल्य वाले पेज ऑपरेटरों को सिस्टम अनदेखा करना सिखाते हैं और महत्वपूर्ण सिग्नल पहचानना कठिन बनाते हैं।
अस्पष्टता दूर करने के लिए एक छोटी अलर्ट समीक्षा करें। यह उदाहरणात्मक तालिका संभावित मॉनिटरिंग निर्णयों का वर्णन करती है, SwissOctet सपोर्ट कवरेज या उपलब्धता प्रतिबद्धता का नहीं। थ्रेशोल्ड को वास्तविक एप्लिकेशन की बेसलाइन के विरुद्ध परीक्षण करना आवश्यक है। एक रिकवरी शर्त शामिल करें ताकि ऑपरेटर जान सके कि अलर्ट कब हटा है और अभी क्या सत्यापित करना बाकी है।
| देखी गई स्थिति | उपयोगी प्रतिक्रिया | शामिल करने योग्य संदर्भ |
|---|---|---|
| प्रतिनिधि उपयोगकर्ता यात्रा विफल होती है | प्रभाव का आकलन करें और शमन करें | प्रभावित एंडपॉइंट, अवधि और हालिया परिवर्तन |
| डिस्क नियोजित सीमा के निकट पहुँच रही है | वृद्धि और रिटेंशन की समीक्षा करें | वॉल्यूम, वृद्धि दर और सुरक्षित हेडरूम |
| बैकअप सत्यापन विफल होता है | रिकवरी मार्ग की सुरक्षा करें | जॉब, अंतिम उपयोगी बिंदु और त्रुटि |
| रिलीज़ के दौरान लेटेंसी बढ़ती है | परिवर्तन की जाँच करें या रोल बैक करें | बेसलाइन, रिलीज़ समय और प्रभावित अनुरोध |
एक छोटी इंसिडेंट संरचना तैयार करें
प्रतिक्रिया प्रक्रिया दबाव में समझने योग्य होनी चाहिए। एक समन्वयक, तकनीकी काम संभालने वाला व्यक्ति और जब इंसिडेंट अलग भूमिकाओं की आवश्यकता जितना बड़ा हो तो अपडेट के लिए ज़िम्मेदार व्यक्ति नामित करें। छोटी परियोजना भूमिकाएँ संयोजित कर सकती है, पर फिर भी उसे एक स्पष्ट निर्णय-बिंदु से लाभ होता है। सेवा विफल होने से पहले संचार चैनल पर सहमति बनाएँ।
Google की इंसिडेंट-रिस्पॉन्स सामग्री समन्वय और शमन-प्रथम दृष्टिकोण पर ज़ोर देती है। इसे परियोजना के अनुकूल पैमाने पर लागू करें: प्रभाव स्थापित करें, सुरक्षित कार्रवाइयाँ चुनें और कई ऑपरेटरों को परस्पर विरोधी परिवर्तन करने से रोकें। एक टाइमलाइन और निर्णय रिकॉर्ड करें। सही व्याख्या की खोज किसी सुरक्षित उपाय को नहीं रोकनी चाहिए जो प्रभावित फ़ंक्शन बहाल करता है।
एक ठोस गिरावट से गुज़रें
कल्पना करें कि किसी रिलीज़ के बाद कोई साइट धीमी हो जाती है। बाहरी जाँच बढ़ा हुआ पूर्णता समय दिखाती है, जबकि आंतरिक माप एप्लिकेशन त्रुटियाँ और बढ़ता डेटाबेस कार्य दिखाते हैं। समन्वयक एक सीमित इंसिडेंट घोषित करता है, साक्ष्य की सुरक्षा करता है और एक व्यक्ति को रिलीज़ की बेसलाइन से तुलना करने का काम सौंपता है। दूसरा व्यक्ति असंबंधित इन्फ्रास्ट्रक्चर परिवर्तन करने के बजाय परीक्षित रोलबैक मार्ग तैयार करता है।
यदि एप्लिकेशन की डेटा स्थिति के लिए रोलबैक सुरक्षित है, तो उसका उपयोग करें और परिणाम देखें। यदि यह सुरक्षित नहीं है, तो परिचालन योजना द्वारा समर्थित कोई संकीर्ण शमन चुनें। क्या बदला और कब, यह दस्तावेज़ित करें। बड़े VPS या पोर्ट का मूल्यांकन बाद में किया जा सकता है, पर तत्काल निर्णय साक्ष्य को संबोधित करना चाहिए, यह मानने के बजाय कि इन्फ्रास्ट्रक्चर का आकार कारण है।
साक्ष्य की सुरक्षा करें और रिकवरी सत्यापित करें
परिचालन लॉग और इंसिडेंट नोट्स में पते, पहचानकर्ता और ग्राहक जानकारी हो सकती है। जाँच को जो चाहिए वही एकत्र करें, एक्सेस सीमित करें और क्रेडेंशियल या निजी ऑर्डर टोकन को साझा रिपोर्ट से बाहर रखें। संदिग्ध सुरक्षा इंसिडेंट के लिए, उपयुक्त साक्ष्य सुरक्षित रखें और परियोजना की प्रतिक्रिया नीति का पालन करें, न कि जल्दबाज़ी में सफ़ाई करके जानकारी नष्ट करें।
NIST का इंसिडेंट-रिस्पॉन्स मार्गदर्शन प्रतिक्रिया को व्यापक साइबरसुरक्षा जोखिम प्रबंधन के भीतर रखता है। रिकवरी में इच्छित फ़ंक्शन की जाँच और उस स्थिति का समाधान शामिल है जिसने इंसिडेंट संभव बनाया। प्रतिक्रिया बंद करने से पहले उपयोगकर्ता यात्रा का परीक्षण करें, संसाधन व्यवहार की समीक्षा करें और बैकग्राउंड कार्य जाँचें। केवल अलर्ट हटना या प्रक्रिया पुनःआरंभ होना उपयोगी सेवा में पूर्ण वापसी प्रदर्शित नहीं कर सकता।
इंसिडेंट को एक मापनीय सुधार में बदलें
प्रभाव, टाइमलाइन, योगदान देने वाली स्थितियों और की गई कार्रवाइयों की एक छोटी समीक्षा लिखें। उन परिवर्तनों पर ध्यान दें जिन्हें सत्यापित किया जा सके: कोई जाँच सुधारें, कोई अनुमति ठीक करें, रोलबैक का अभ्यास करें या छूटी हुई रिकवरी निर्भरता जोड़ें। ज़िम्मेदार व्यक्ति और पूर्णता मानदंड निर्धारित करें। अस्पष्ट इरादों की लंबी सूची से बचें जिन्हें बाद में कोई पुष्ट न कर सके कि लागू किए गए थे।
SwissOctet पर डिप्लॉय करते समय, मॉनिटरिंग और प्रतिक्रिया की योजना एप्लिकेशन के संचालन के हिस्से के रूप में बनाएँ, चुने गए हार्डवेयर और किसी पुष्ट प्रबंधन व्यवस्था से अलग। कैटलॉग किसी स्टाफयुक्त इंसिडेंट टीम या निरंतर सपोर्ट घंटों की पुष्टि नहीं करता। प्रोडक्शन वातावरण पर निर्भर होने से पहले तय करें कि अलर्ट कौन प्राप्त करता है, कौन कार्रवाई कर सकता है और वास्तविक सेवा शर्तें क्या कवर करती हैं।
आपकी व्यावहारिक चेकलिस्ट।
- एक हानिरहित प्रतिनिधि उपयोगकर्ता यात्रा की निगरानी करें।
- ऐसे सिग्नल चुनें जो एप्लिकेशन व्यवहार समझाएँ।
- अलर्ट को एक कार्रवाई, ज़िम्मेदार व्यक्ति और रिकवरी शर्त दें।
- इंसिडेंट से पहले समन्वय और एस्केलेशन पर सहमति बनाएँ।
- साक्ष्य की सुरक्षा करें और पूर्ण रिकवरी सत्यापित करें।
- समीक्षा के बाद परीक्षण-योग्य सुधार सौंपें।
महत्वपूर्ण विवरण।
क्या सर्वर अपटाइम मॉनिटरिंग पर्याप्त है?+
नहीं। पहुँच-योग्य मशीन पर टूटा एप्लिकेशन भी हो सकता है। उस फ़ंक्शन की निगरानी करें जिस पर उपयोगकर्ता निर्भर हैं और विफलताओं के निदान के लिए संसाधन साक्ष्य जोड़ें।
क्या हर मेट्रिक थ्रेशोल्ड पर किसी को तुरंत पेज करना चाहिए?+
नहीं। तत्काल रुकावटें उन कार्रवाई-योग्य स्थितियों के लिए रखें जिन पर समय पर ध्यान आवश्यक हो। कम प्राथमिकता वाले काम को स्पष्ट ज़िम्मेदार व्यक्ति के साथ समीक्षा प्रक्रिया में भेजें।
इंसिडेंट कब समाप्त होता है?+
प्रभावित फ़ंक्शन और प्रासंगिक बैकग्राउंड कार्य सत्यापित होने, तत्काल जोखिम संभाले जाने और अनुवर्ती कार्रवाइयाँ दर्ज होने के बाद। केवल प्रक्रिया पुनःआरंभ करना पर्याप्त नहीं है।
स्रोत पर जाएं।
ये संदर्भ इस गाइड में तकनीकी अवधारणाओं का समर्थन करते हैं। उत्पादन प्रणाली बदलने से पहले वर्तमान दस्तावेज़ का पालन करें।
- Google SRE: Monitoring distributed systems sre.google
- Google SRE Workbook: Incident response sre.google
- NIST SP 800-61 Rev. 3: Incident response csrc.nist.gov
SwissOctet द्वारा संपादकीय मार्गदर्शन। उदाहरण केवल दृष्टांत हैं। सेवा विशिष्टताएं, उपलब्ध विकल्प और संविदात्मक शर्तें अलग से सत्यापित की जानी चाहिए।