Deployment के बाद service की जिम्मेदारी लें

वह service तय करें जिस पर उपयोगकर्ता निर्भर हैं

Deployment software उपलब्ध करता है। संचालन उसे उपयोगी रखता है, जबकि users, dependencies, traffic और requirements बदलते हैं। Code generator यह लगातार काम नहीं हटाता।

काल्पनिक customer export में उपयोगकर्ताओं को केवल उपलब्ध page से अधिक चाहिए। उन्हें स्वीकार्य records जरूरी format में और स्वीकार्य समय के भीतर चाहिए। Service को दूसरी organization के डेटा का access भी रोकना है।

Release से पहले जिम्मेदार व्यक्ति तय करें। Service commitment में शामिल हो तो दर्ज करें कि सामान्य काम के समय के बाहर कौन प्रतिक्रिया देता है। Supplier कुछ काम कर सकता है, लेकिन संगठन को decisions और communication का स्पष्ट रास्ता फिर भी चाहिए।

कार्रवाई में मदद करने वाले signals चुनें

Service-level indicator, या SLI, service के व्यवहार का तय गुण मापता है। Service-level objective, या SLO, बताई अवधि में उस indicator का target तय करता है। उपयोगकर्ता की जरूरत और संचालन की क्षमता के अनुसार target चुनें।

Google की SRE guidance यह तरीका और reliability के decisions में error budget का उपयोग समझाती है। अर्थ जाँचे बिना दूसरी service का target copy न करें। SLO guidance, error-budget policy का उदाहरण।

Export में तय करें कि योग्य request की सफलता किसे कहेंगे। अपेक्षित denials को system failures से अलग रखें। बाहर रखे cases दर्ज करें, ताकि कठिन requests छिपाने भर से metric बेहतर न हो जाए।

Visibility बढ़ाने के लिए पूरे exports logs में न रखें। समस्या समझने के लिए न्यूनतम जरूरी जानकारी जुटाएँ और उसका access सुरक्षित रखें।

Incident response तैयार करें

तय करें कि समन्वय, जाँच और communication कौन करता है। छोटी team में ये roles जोड़ी जा सकती हैं, लेकिन जिम्मेदारियाँ स्पष्ट रहें। Observations और कार्रवाइयों का record रखें।

Google की incident-response guidance technical mitigation के साथ coordination और communication पर जोर देती है। Technical रूप से सही fix के बाद भी उपयोगकर्ता अनजान रह सकते हैं या कई responders विरोधी बदलाव कर सकते हैं। Incident response।

Agent स्वीकृत data boundaries में logs का सारांश या धारणाओं की तुलना कर सकता है। Incident urgent होने से उसे असीमित production authority नहीं मिलनी चाहिए। असाधारण access के लिए तय escalation प्रक्रिया इस्तेमाल करें।

Recovery का अभ्यास करें और रखरखाव के लिए बजट रखें

प्रतिनिधि काल्पनिक डेटा के साथ recovery प्रक्रिया जाँचें। पहचानें कि code rollback क्या नहीं पलट सकता, जिसमें deleted records या पहले से भेजे messages शामिल हैं। Service बहाल करने के लिए जरूरी समय और जानकारी दर्ज करें।

लगातार काम की जिम्मेदारी तय करें: dependency updates, access reviews, जहाँ लागू हो certificate renewal, capacity changes और documentation corrections। Maintenance capacity के बिना service का launch budget खत्म होने के बाद दायित्व जमा होते रहते हैं।

Incident के बाद ऐसे सुधार चुनें जो देखे गए कारणों को हल करें। उन्हें implementation और verification से जोड़ें। इससे lifecycle पूरा होता है: संचालन का प्रमाण तय करता है कि team आगे क्या specify और build करेगी।