Detection से recovery तक incident सँभालें

असर के आधार पर incident घोषित करें

Incident वह घटना है जो service को इतना बाधित, कमजोर या जोखिम में डाले कि समन्वित response चाहिए। आपका संगठन severity levels और escalation rules तय करता है। उन्हें लागू करने के लिए users पर असर, प्रभावित डेटा, अवधि और दायरा देखें।

मदद माँगने से पहले root cause की पूरी व्याख्या का इंतजार न करें। देखा गया असर स्पष्ट बताना समन्वय शुरू करने के लिए पर्याप्त है। Security suspicion को पुष्टि किए निष्कर्ष से अलग रखें।

Release से पहले response का रास्ता तैयार करें। मुख्य service उपलब्ध न हो, तब भी contact details, access procedures, runbooks और communication channels उपलब्ध रहें। काल्पनिक incident से प्रक्रिया का अभ्यास करें।

विरोधी बदलाव करने से पहले जिम्मेदारियाँ तय करें

Incident coordination प्राथमिकताएँ और निर्णय सँभालता है। Technical responders जाँच और mitigation करते हैं। Communication प्रभावित लोगों को जानकारी देता है। Google SRE इन्हें अलग roles बताता है। छोटी teams roles जोड़ सकती हैं, लेकिन पूरा काम cover होना चाहिए। Incident response।

एक shared timeline रखें। समय, observation, कार्रवाई, कार्रवाई करने वाला और परिणाम दर्ज करें। Facts और hypotheses अलग रखें। एक ही time zone इस्तेमाल करें और अविश्वसनीय timestamps चिह्नित करें।

काल्पनिक incident पर काम करें

नीचे सभी समय UTC में हैं। Export failure कई customers को प्रभावित करे तो संगठन incident coordinator तय करता है।

उपयोगी पहला update प्रभावित function, ज्ञात दायरा, mitigation और अगले update का समय बताता है। वह बिना प्रमाण repair का समय नहीं बताता। Shared update में customer records शामिल न करें।

09:10 पर incident बदलता है। सफल exports बहाल करना अब पर्याप्त नहीं। Team को जानकारी उजागर होने की संभावना का आकलन करना, access नियंत्रित करना, प्रमाण सुरक्षित रखना और उचित निर्णयकर्ताओं को शामिल करना है।

नियंत्रण बनाए रखते हुए असर घटाएँ

जहाँ लागू हों, tested runbooks इस्तेमाल करें। Rollback, failover या credential changes से पहले preconditions जाँचें। Application का पिछला version वर्तमान database schema न समझे। Regional failover वही corrupted data दूसरी जगह ले जा सकता है।

AI assistant को स्वीकृत सीमाओं में, संवेदनशील जानकारी हटाने के बाद बचे प्रमाण व्यवस्थित करने या धारणाओं की तुलना करने दें। Responders को उसके निष्कर्ष जाँचने होंगे। Logs और tickets untrusted input हैं, उनकी सामग्री execute करने का अधिकार नहीं।

Emergency access का अधिकृत उद्देश्य, सीमित अवधि और audit record होना चाहिए। Urgency से agent की सुझाई command सही नहीं हो जाती।

Recovery और follow-up अलग बंद करें

Service recovery घोषित करने से पहले user workflow, data integrity, access boundaries और monitoring का वर्तमान होना जाँचें। बची restrictions दर्ज करें। Security investigation के प्रश्न अनसुलझे हों तो उसे खुला रखें।

बाद में उन स्थितियों को जाँचें जिनसे incident संभव हुआ। जिम्मेदार व्यक्ति और verification criteria के साथ ठोस follow-up काम सौंपें। Blameless review सही व्याख्या और उपयोगी बदलाव खोजता है। वह बदलाव पूरे करने की जवाबदेही नहीं हटाता। Postmortem practice।

आगे security operations और feedback loop पूरा करना पढ़ें।