ग्राहक परिणाम के आसपास रीडिनेस परिभाषित करें
इंफ्रास्ट्रक्चर लेबल से शुरू न करें—परिणामों से शुरू करें। एक पहुँच योग्य होमपेज पर्याप्त नहीं है अगर आगंतुक वह कार्य पूरा नहीं कर सकता जो मायने रखता है। प्रत्येक महत्वपूर्ण जर्नी के लिए बताएं कि कौन क्या करने की कोशिश कर रहा है, सफलता का क्या अर्थ है, और कौन सा परिणाम अस्वीकार्य होगा। टीम को वास्तविक निर्णय लेने लायक कुछ जर्नियों से शुरू करें।
प्रत्येक चरण को अनिवार्य, महत्वपूर्ण, या स्थग्येय के रूप में वर्गीकृत करें। अनिवार्य का अर्थ है कि बिना इसके जर्नी पूरी नहीं हो सकती; महत्वपूर्ण का अर्थ है कि एक सीमित-समय वर्कअराउंड पर जर्नी चलेगी; स्थग्येय को हटाया, विलंबित, या सरल किया जा सकता है। यह इंजीनियरिंग से सूचित एक उत्पाद निर्णय है, सार्वभौमिक तकनीकी रैंकिंग नहीं।
केवल पेज-रेस्पॉन्स लक्ष्य के बजाय एक उपयोगी परिणाम दर्ज करें — जैसे ऑर्डर स्वीकार हो गया और पुष्टि संग्रहीत हुई।
निर्भरताओं का मानचित्र बनाएं और तय करें क्या घटित हो सकता है
प्रत्येक क्रिटिकल पाथ के लिए होस्टिंग/डिलीवरी, DNS, एप्लिकेशन सेवाएँ, डेटाबेस, प्रमाणीकरण, ईमेल, पेमेंट, सर्च, टैग, सहमति टूलिंग, और बाहरी API का मानचित्र बनाएं। प्रत्येक के लिए मालिक, सपोर्ट मार्ग, प्रासंगिक सीमा, और उपयोगकर्ता प्रभाव दर्ज करें यदि वह अनुपलब्ध हो। OWASP सॉफ़्टवेयर निर्भरताओं में अंतर्दृष्टि की सिफारिश करता है; वही स्वामित्व अनुशासन परिचालन निर्भरताओं के साथ मदद करता है।
एक हार्ड निर्भरता वह है जो विफल होने पर कार्य को रोक देती है। एक सॉफ्ट निर्भरता अनुपस्थित या स्टेल हो सकती है जबकि मूल कार्य फिर भी काम करता है। AWS शालीन गिरावट (graceful degradation) के बारे में बताता है—जब निर्भरताएँ अनहेल्दी हों तब कोर फ़ंक्शन को उपलब्ध रखना। एक उत्पाद-विशिष्ट विकल्प पर निर्णय लें: गैर-आवश्यक विजेट छिपाएँ, रिपोर्ट विलंबित करें, या एक ईमानदार फालबैक प्रस्तुत करें। इन्वेंटरी, कीमतें, ऑर्डर स्टेट्स, या पेमेंट परिणाम का आविष्कार न करें।
प्रत्येक आइटम के लिए उद्देश्य, मालिक, ज्ञात सीमा, फॉलबैक, परिवर्तन संपर्क, और अंतिम परीक्षण तिथि दर्ज करें।
ट्रैफ़िक अनुमान को क्षमता प्रयोग में बदलें
एक अकेले ट्रैफ़िक नंबर की बजाय एक परिदृश्य का उपयोग करें। घटना, आगमन पैटर्न, अनुरोध मिश्रण (request mix), साइन-इन शेयर, भौगोलिक क्षेत्र, समवर्ती चेकआउट या लेखन गतिविधि, और पीक अवधि बताएं। उच्च केस और मान्यताओं को शामिल करें। Google बताता है कि अनुरोधों की संसाधन लागत बहुत भिन्न हो सकती है, इसलिए केवल requests per second जैसे मेट्रिक्स अक्सर खराब क्षमता मॉडल होते हैं।
उत्पादन के करीब कॉन्फ़िगरेशन पर, अनुमोदन और सुरक्षा उपायों के साथ नियंत्रित, प्रतिनिधि, एंड-टू-एंड ट्रैफ़िक का सतत परीक्षण करें। AWS केवल घटकों का परीक्षण करने, अनुरोधों के गैर-प्रतिनिधि उपसमुच्चय का उपयोग करने, या अपेक्षित लोड से मामूली ऊपर रुक जाने की चेतावनी देता है। पहला बाधा बिंदु या धीमा होना दस्तावेज़ करें। लाइव-प्रोडक्शन परीक्षण ग्राहक प्रभावित कर सकते हैं; जब तक नियोजित, स्टाफ्ड अभ्यास उपयुक्त न हो, नियंत्रित वातावरण का उपयोग करें।
परिदृश्य, कॉन्फ़िगरेशन, अनुरोध मिश्रण, अवधि, अवलोकित बाधा, क्षमता परिवर्तन, और अनुवर्ती मालिक रखें।
परिवर्तन, रोलबैक और रिकवरी विकल्प तैयार रखें
उच्च-जोखिम परिवर्तन से पहले उस आर्टिफैक्ट या कॉन्फ़िगरेशन की पहचान करें जिसे वापस लाया जाएगा, आवश्यकता होने वाला अनुमोदन, अधिकृत व्यक्ति, और सत्यापन विधि। रिलीज़ को रोकने, डिप्लॉयमेंट को रिवर्ट करने, फीचर फ्लैग को अक्षम करने, गैर-आवश्यक इंटीग्रेशन को घटाने, या अनुमोदित प्रक्रिया से डेटा बहाल करने के लिए छोटा रनबुक रखें। घटना से पहले मैकेनिक्स का परीक्षण करें; बिना अभ्यास किया गया बैकअप या रोलबैक योजना एक अनुमान है।
व्यापार प्रभाव से रिकवरी उद्देश्य (recovery objectives) सेट करें। Recovery Time Objective (RTO) वह अधिकतम स्वीकार्य विलंब है जब तक सेवा बहाल नहीं होती। Recovery Point Objective (RPO) अधिकतम स्वीकार्य डेटा हानि है, जो अंतिम रिकवरी प्वाइंट से मापी जाती है। AWS मनमाने या अवास्तविक लक्ष्यों के खिलाफ सावधान करता है और नोट करता है कि निर्भरता उद्देश्य जो कुछ प्राप्त किया जा सकता है उस पर प्रभाव डालते हैं। लक्ष्यों को ग्राहक-वादों के बजाय योजना लक्ष्य मानें।
सीमित, सुरक्षित रोलबैक या बहाली सत्यापित करें और क्या जांचा गया, किसने किया, और किसी भी अंतर को दर्ज करें।
निर्णय तात्कालिक होने से पहले स्वामित्व असाइन करें
संपर्क सूची अकेला स्वामित्व नहीं है। प्रत्येक क्रिटिकल पाथ के लिए स्वीकार्य परिणाम के लिए एक व्यवसायी मालिक, कार्यान्वयन के लिए एक तकनीकी मालिक, और एक निर्णय मालिक असाइन करें जिसे रक्षात्मक परिवर्तन करने का अधिकार हो। बैकअप नामित करें और स्पष्ट करें कि प्रदाता, एजेंसी, पेमेंट प्रोसेसर, या आंतरिक टीम अगला कदम कब लेगी।
ट्रैफ़िक आने से पहले एक छोटा रीडिनेस समीक्षा चलाएँ। एक निर्भरता विफलता के माध्यम से चलें: क्या उपलब्ध रहता है, कौन सा लीवर सुरक्षित है, कौन इसे मंजूरी देता है, और सफलता कैसे जाँची जाती है। यह सक्रिय अभ्यास है, लाइव-स्थिति रिपोर्ट नहीं। तिथिबद्ध कार्रवाइयाँ, मालिक, और नियत तिथियाँ दर्ज करें।
जहाँ उपयुक्त हो संकीर्ण सुरक्षित क्रियाओं को पूर्व- अधिकृत करें ताकि रक्षा अस्पष्ट अनुमोदन चेन पर न रुके।
पेमेंट और सुरक्षा-संवेदनशील पाथों को अतिरिक्त सावधानी दें
चेकआउट रीडिनेस में उपलब्धता के साथ-साथ सहीपन (correctness) की भी सुरक्षा आवश्यक है। प्राधिकरण को बायपास न करें, एक्सेस कंट्रोल कमजोर न करें, क्रेडेंशियल्स उजागर न करें, या पेमेंट-पेज स्क्रिप्ट्स को हल्के में बदलें। PCI SSC गाइडेंस पेमेंट-पेज स्क्रिप्ट्स और सुरक्षा-प्रभावित HTTP हेडर्स के लिए प्राधिकरण, अखंडता, और टेम्पर-डिटेक्शन पर दिशा-निर्देश देती है। यदि साइट कार्ड स्वीकार करती है या एम्बेडेड पेमेंट फ़्रेम का उपयोग करती है, तो मर्चेंट, प्रोसेसर, एक्वायरर और प्रमाणित सुरक्षा/अनुपालन सलाहकारों से सामग्री परिवर्तनों की समीक्षा कराएँ।
उत्पादन स्क्रिप्ट्स, इंटीग्रेशन, वर्शन, और अकाउंट स्वामित्व की इन्वेंटरी रखें और कौन उन्हें बदल सकता है उस पर प्रतिबंध लगाएँ। OWASP नोट करता है कि निर्भरता इन्वेंटरी और वर्शन पिनिंग यह कम कर सकते हैं कि क्या बिल में प्रवेश कर रहा है, जबकि स्वचालित निष्कर्षों को फिर भी मैनुअल सत्यापन की आवश्यकता होती है। ये प्रथाएँ रीडिनेस का समर्थन करती हैं पर PCI अनुपालन या सुरक्षा आकलन का स्थान नहीं लेतीं।
केवल प्रोसेसर-स्वीकृत, समीक्षित वैकल्पिक फ्लो का उपयोग करें; कभी भी अनौपचारिक चैनलों के माध्यम से कार्ड डेटा इकट्ठा न करें।