आजच्या रिलीझ सायकलसाठी घटना प्रतिसाद चरण

आधुनिक सॉफ्टवेअर गट पूर्वीपेक्षा जास्त वेळा अद्यतने पाठवतात. सतत एकत्रीकरण, चाचणी ऑटोमेशन, क्लाउड सेटअप, वैशिष्ट्य टॉगल आणि सतत वितरण या साधनांसह, संघ कमी विलंबाने कोड बदलांपासून उत्पादनापर्यंत जाऊ शकतात.

तो वेग एक नवीन धोका घेऊन येतो. जेव्हा रिलीझ त्वरीत होते, तेव्हा गोष्टी अयशस्वी होतात तेव्हा संघाला एक ठोस योजना देखील आवश्यक असते.

एक खराब उपयोजन, डेटाबेस समस्या, सुरक्षा सूचना, क्लाउड किंवा नेटवर्क आउटेज किंवा विषम ॲप वर्तन वापरकर्त्यांना झपाट्याने प्रभावित करू शकते. कोणतीही सामायिक प्रक्रिया नसल्यास, अभियंते एकाच वेळी समान मूळ कारणाचा पाठलाग करू शकतात. इतरांवरील अपडेट गमावले जाऊ शकतात किंवा चॅटमध्ये विभाजित होऊ शकतात. लोक योग्य संदर्भाची वाट पाहत असताना की कॉल थांबू शकतात.

त्यामुळे घटना प्रतिसाद वर्कफ्लो महत्त्वाचा आहे. ते पायऱ्यांचा स्पष्ट क्रम सांगतात. समस्या शोधून काढणे, ती किती पसरली आहे हे ठरवणे, कोण काय करते याचे समन्वय साधणे, तात्काळ हानी कमी करणे, सेवा परत आणणे आणि नंतर काय झाले याचे पुनरावलोकन करणे हे उद्दिष्ट आहे जेणेकरून कार्यसंघ सुधारू शकेल.

NIST कडील वर्तमान मार्गदर्शन, SP 800-61 पुनरावृत्ती 3, सायबरसुरक्षा जोखीम कार्याचा भाग म्हणून घटनेच्या प्रतिसादाला फ्रेम करते. हल्ला संपल्यानंतरच सुरू होते असे नाही. NIST मॉडेल घटना प्रतिसाद शोधणे, प्रतिसाद देणे आणि पुनर्प्राप्त करण्यासाठी देखील बसते. हे चालू सुधारणेवर देखील भर देते, एक वेळचे निराकरण नाही.

DevOps आणि रिलीझ संघांसाठी, समान कल्पना आहे. सॉफ्टवेअर कसे तयार केले जाते, बाहेर ढकलले जाते, निरीक्षण केले जाते आणि दिवसेंदिवस कसे चालवले जाते यावर घटनेचा प्रतिसाद विणलेला असावा.

घटना प्रतिसाद वर्कफ्लो म्हणजे काय?

घटना प्रतिसाद वर्कफ्लो एक सेट योजना आहे. सिस्टीम, ॲप, वापरकर्ते किंवा संपूर्ण org ला धडकणाऱ्या आश्चर्यकारक घटनेला सामोरे जाण्यासाठी ते संघांना मदत करते.

प्रत्येक घटना सारखी हाताळली जात नाही. काय चूक झाली आणि किती मोठा परिणाम झाला यावर काम अवलंबून आहे.

ही एक लहान ॲप समस्या असल्यास, अभियंता लॉग तपासू शकतो आणि अलीकडील बदल पूर्ववत करू शकतो. जर तो मोठा आउटेज असेल, तर अभियांत्रिकी, ऑपरेशन्स, सुरक्षा, ग्राहक समर्थन, संप्रेषण आणि नेते यांसारखे अनेक गट सामील होऊ शकतात.

या कार्यप्रवाहासह, गटांकडे त्यांचे कार्य आयोजित करण्याचा एक सामायिक मार्ग आहे.

रिलीझ-केंद्रित प्रक्रिया लिंक केलेल्या टप्प्यांप्रमाणे दर्शविली जाऊ शकते:

• संवाद
• शमन
• पुनर्प्राप्ती

हे टप्पे कठोर रेषा नसतात. जेव्हा नवीन तथ्ये दिसून येतात तेव्हा टीम पूर्वीच्या कामावर परत जाऊ शकतात, जसे की तपास आणि शमन दरम्यान एकापेक्षा जास्त वेळा जाणे.

ट्रायज: घटनेची क्रमवारी लावणे

डिटेक्शन सूचित करते की समस्या असू शकते. प्रथम काय पहावे आणि ते किती जलदपणे संबोधित केले जावे हे ट्रायज ठरवते.

प्रतिसादकर्ते सामान्यत: मुलभूत गोष्टी नखे करून प्रारंभ करतात:

• काय प्रभावित होत आहे?
• किती वापरकर्ते प्रभावित झाले आहेत?
• हे कधी सुरू झाले?

• कालांतराने हानी वाढत आहे का?
• हे सुरू होण्यापूर्वी काय बदलले?
• समस्या फक्त एकाच ठिकाणी आहे की ती सर्व प्रणालींमध्ये पसरली आहे?
• यामुळे सुरक्षिततेची चिंता निर्माण होते किंवा डेटा धोक्यात येतो?

तीव्रतेने वास्तविक किंवा अपेक्षित प्रभावाचे अनुसरण केले पाहिजे. तांत्रिक दृष्टिकोनातून निराकरण किती कठीण दिसते यावर अवलंबून राहू नये. उदाहरणार्थ, अंतर्गत कार्यसंघाद्वारे वापरल्या जाणाऱ्या साधनातील एक लहान बग हा हजारो ग्राहकांना प्रभावित करणाऱ्या साध्या चुकीच्या कॉन्फिगरेशनपेक्षा कमी प्राधान्य असू शकतो.

घटना कार्यप्रवाहांसाठी Microsoft मार्गदर्शन घटनांना रांगेत ठेवण्यास सांगते. मग तुम्ही त्यांची पोहोच, तीव्रता, कोणत्या मालमत्तेला फटका बसला आणि इशारा कुठून आला ते पहा.

मालकी नियुक्त करणे

जेव्हा बरेच लोक एकाच वेळी कृती करतात तेव्हा प्रतिसाद गोंधळून जातो, परंतु प्रयत्नांवर कोणाचेही नियंत्रण नसते.

त्यामुळे एखाद्या घटनेने मालकाचे नाव घेतले पाहिजे. काही अवयवांमध्ये, या भूमिकेला घटना कमांडर म्हणतात. कंपनी कशी चालते यावर ते अवलंबून आहे.

समन्वयक प्रत्येक तांत्रिक निराकरण करणारी व्यक्ती असणे आवश्यक नाही. ते वेगळे होण्यास मदत होते.

एक अभियंता ॲप लॉगमधून खोदून काढू शकतो. दुसरा पायाभूत सुविधांवर लक्ष केंद्रित करू शकतो. तिसरी व्यक्ती इतरांना अपडेट्स हाताळू शकते आणि टाइमलाइन व्यवस्थित ठेवू शकते. जेव्हा हाताशी काम करण्यापासून समन्वय दूर राहतो, तेव्हा तुम्ही एकट्या व्यक्तीला सर्व काही धरून ठेवण्याचे टाळता.

घटना संप्रेषण

संपूर्ण घटनेचा प्रतिसाद केवळ तांत्रिक निराकरण नाही. इतर गटांना बऱ्याचदा स्पष्ट अद्यतनांची देखील आवश्यकता असते. सपोर्ट टीम विचारू शकतात की ग्राहक प्रभावित झाले आहेत का. उत्पादन व्यवस्थापकांना व्यवसायावर किती परिणाम होतो हे जाणून घ्यायचे असेल.

नेत्यांना नवीनतम स्थिती आणि पुनर्प्राप्ती कशी होत आहे हे पहायचे असेल.

या घटनेने ग्राहक सेवेला खऱ्या अर्थाने फटका बसला, तर ग्राहकांनाही संदेशाची गरज आहे. चांगली अद्यतने तथ्यांवर टिकून राहिली पाहिजेत, संक्षिप्त रहा आणि वारंवार पाठवल्या पाहिजेत. काय ज्ञात आहे आणि अद्याप काय तपासले जात आहे यामधील स्पष्ट रेषा वापरा. उदाहरणार्थ, अद्याप सिद्ध न झालेल्या कारणाचा दावा करण्यापेक्षा संघ उच्च त्रुटी दर तपासत आहे असे म्हणणे चांगले आहे.

सामायिक घटना चॅनेल, स्टेटस पेज, तिकीट किंवा घटना साधन मुख्य तपशील अनेक चॅटमध्ये पसरण्यापासून रोखू शकते.

पहिली पायरी: नुकसान मर्यादित करा

एखादी घटना अद्याप सक्रिय असताना, आपल्याला लगेच संपूर्ण मूळ कारणाची आवश्यकता असू शकत नाही. त्या क्षणी होणारी हानी कमी करणे हे मुख्य ध्येय आहे. तुम्ही काय करता ते केसवर अवलंबून असेल. काही संघ रिलीझ परत करतात. इतर एक वैशिष्ट्य बंद करतात.

तुम्ही रहदारी इतरत्र हलवू शकता, अतिरिक्त क्षमता जोडू शकता, सेवा विलग करू शकता किंवा आतासाठी सेटिंग समायोजित करू शकता. हे मार्गदर्शनाशी जुळते जे नियंत्रण आणि द्रुत प्रतिसाद निवडीवर जोर देते.

त्यामुळे जेव्हा बदलामुळे अनपेक्षित परिणाम होतात तेव्हा एक्सपोजर कमी करण्यासाठी तुमच्या रिलीझ प्रक्रियेमध्ये अंगभूत मार्गांचा समावेश असावा.

रोलबॅक आणि रिलीझ सेफगार्ड्स

आजची उपयोजन साधने संघांना जलद प्रतिक्रिया देण्यास मदत करू शकतात. रोलआउटनंतर लवकरच काहीतरी चूक होते तेव्हा, संघ भूतकाळातील बिल्डमध्ये परत येऊ शकतात. ती मागील आवृत्ती आहे जी आधीच कार्य करते.

दुसरा पर्याय वैशिष्ट्य ध्वज वापरणे आहे. ध्वजांसह, आपण फक्त खराब भाग बंद करू शकता. तुम्ही इतर बदल सुरक्षित असल्यास ते चालू ठेवता.

काही गट कॅनरी रिलीझ देखील वापरतात. ते अद्ययावत प्रथम एका लहान सेटवर पाठवतात. स्टेज केलेले रोलआउट्स अशाच प्रकारे कार्य करतात. ते टप्प्याटप्प्याने अधिक वापरकर्ते जोडतात, त्यामुळे पूर्ण प्रेक्षक एकाच वेळी हिट होत नाहीत. या चरणांमुळे सर्व अपयश थांबणार नाहीत.

तरीही, समस्या हाताळताना ते ऑन-कॉल टीमला अधिक पर्याय देऊ शकतात. कळीचा मुद्दा सोपा आहे. घटना घडण्यापूर्वी ही नियंत्रणे कशी कार्य करतात हे संघांनी शिकले पाहिजे.

दस्तऐवजीकरण आणि प्रतिसाद कार्य

ठोस दस्तऐवजीकरण संघांना घटनेदरम्यान अंदाज लावण्यात कमी वेळ घालवण्यास मदत करते. रनबुक्स काय करायचे ते स्टेप बाय स्टेप सांगतात. ते सेवा रीस्टार्ट करणे, रिलीझमधील बदल पूर्ववत करणे आणि क्रेडेन्शियल स्वॅप करणे यासारख्या गोष्टी समाविष्ट करतात. रांग कशी तपासायची, डेटाबेस परत कसा आणायचा आणि विशिष्ट प्रकारची घटना योग्य गटाकडे कशी वळवायची हे देखील ते लक्षात घेतात.

दस्तऐवज प्रतिसादकर्ते वापरत असलेल्या सिस्टमजवळ ठेवा.

जर लोकांना त्यांचा शोध घ्यावा लागला तर ते मदत करणार नाहीत. तसेच, वेळोवेळी रनबुकचे पुनरावलोकन आणि चाचणी करा. चालू नसलेले रनबुक वास्तविक समस्या निर्माण करू शकते. काही प्रकरणांमध्ये, रनबुक नसण्याइतकेच दुखते.

प्रतिसाद कसा चालतो याचा मागोवा घेणे

कार्यसंघ त्यांची प्रक्रिया कशी चालत आहे हे पाहण्यासाठी संख्या गोळा करू शकतात. काही उदाहरणांमध्ये एखादी घटना शोधण्यासाठी वेळ आणि ती मान्य करण्याची वेळ यांचा समावेश होतो.

नुकसान मर्यादित करण्यासाठी वेळ, सेवा परत आणण्यासाठी वेळ आणि घटनांची पुनरावृत्ती किती वेळा होते. आणखी एक बाब म्हणजे अंतर्गत तपासणी विरुद्ध ग्राहकांकडून आलेल्या अहवालांमधून किती घटना दिसून येतात.

प्रत्येक मेट्रिकला साधा स्कोअर मानू नका. जलद प्रतिसाद चांगला असू शकतो, परंतु वाटेत केलेल्या निवडी योग्य असतील तरच. कमी संख्येने घटनांचा अर्थ असा होतो की प्रणाली स्थिर आहे.

याचा अर्थ असा देखील होऊ शकतो की अलर्ट त्यांचे कार्य करत नाहीत. कामाची गरज असलेले क्षेत्र शोधण्यासाठी या मेट्रिक्सचा वापर करा. लोकांना दोष देण्यासाठी किंवा रँक देण्याचा मार्ग म्हणून त्यांचा वापर करू नका. कार्यसंघ असामान्य वर्तन शोधण्यासाठी निरीक्षण आणि निरीक्षणक्षमता सुधारू शकतात आणि प्रतिसादकर्त्यांना काय झाले हे समजण्यास मदत करू शकतात.

एका घटनेनंतर, सुधारत रहा

घटनेचा सर्वात चांगला भाग म्हणजे तुम्ही पुढे काय करता. जेव्हा ॲलर्टमध्ये समस्या चुकते, तेव्हा ॲलर्ट सेटअप अपडेट करा. जेव्हा रोलबॅक करणे कठीण असते, तेव्हा तुम्ही कसे पाठवता ते बदला. हे टास्क कोणाच्या मालकीचे आहे हे अस्पष्ट असताना, वाढीच्या पायऱ्या लिहा. मेसेज लाइन अप नसताना, एक स्पष्ट घटना चॅट किंवा चॅनल सेट करा.

NIST त्याच्या मॉडेलमध्ये हे मांडते. हे संघ घटनांना कसे हाताळतात याच्या मध्यभागी चालू सुधारणा ठेवते. सायबरसुरक्षिततेच्या व्यापक जोखमीच्या कामात तुम्ही घटनांमधून काय शिकता ते देखील ते फीड करते. हा दृष्टिकोन घटना हाताळणीला शिकवणाऱ्या प्रक्रियेत बदलतो, त्याच संकटांचा लूप नाही. कार्यसंघ त्यांच्या पायाभूत सुविधांवरील क्रियाकलापांमध्ये दृश्यमानता सुधारण्यासाठी क्लाउड सुरक्षा निरीक्षण देखील मजबूत करू शकतात.

अंतिम विचार

घटना कार्यप्रवाह सॉफ्टवेअर कार्यसंघांना नियोजित पद्धतीने अपयशांना सामोरे जाण्यास मदत करतात. तुम्हाला या क्षणी केवळ सुधारणेवर अवलंबून राहण्याची गरज नाही. प्रथम, विचित्र किंवा धोकादायक वर्तन शोधणे.

पुढे, ट्रायज स्फोट त्रिज्या संकुचित करते आणि तीव्रतेची पातळी सेट करते. त्यानंतर, स्पष्ट मालकी आणि स्थिर संदेश सर्वांना समान ट्रॅकवर ठेवतात. त्यानंतर, शमन केल्याने वापरकर्ते आणि सिस्टमची हानी कमी होते. पुनर्प्राप्ती सेवा स्थिर स्थितीत परत आणते. नंतर पोस्टमॉर्टेम धडे कॅप्चर करतात आणि त्यांना वास्तविक निराकरणात बदलतात.

रिलीझ कामासाठी, घटनेच्या प्रतिसादाने खराब तैनातीची प्रतीक्षा करू नये. वितरण प्रक्रियेमध्ये देखरेख, रोलबॅक पथ, स्टेज केलेले प्रकाशन, रनबुक, स्पष्ट मालक आणि पहिल्या दिवसापासून संप्रेषण करण्याचे मार्ग समाविष्ट केले पाहिजेत.

सर्वात मजबूत संघ असे नसतात ज्यांना कोणतीही घटना नसते. तेच समस्या जलद शोधतात, एकत्र शांत राहतात, प्रभाव कमी करतात, सेवा पुनर्संचयित करतात आणि प्रत्येक वेळी सुधारणा करत असतात.

(स्त्रोत)