12.2 चेकलिस्ट

ये चेकलिस्ट व्यावहारिक, तुरंत उपयोग में लाने योग्य त्वरित संदर्भ हैं। किसी भी चेकलिस्ट को पुल रिक्वेस्ट टेम्पलेट, विकी पेज, टिकट, या समीक्षा बैठक के एजेंडे में कॉपी करें, और आइटम को अपने संदर्भ के अनुसार अनुकूलित करें। हर आइटम को ऐसी चीज़ मानें जिसे कोई व्यक्ति सत्यापित कर सके और हाँ या नहीं में जवाब दे सके। एक चेकलिस्ट एक स्मृति सहायक और एक साझा मानक है, निर्णय-क्षमता का विकल्प नहीं; जो आइटम लागू नहीं होते उन्हें हटाएँ और जो आपके डोमेन को चाहिए उन्हें जोड़ें।

इन्हें अच्छी तरह उपयोग करने के लिए मार्गदर्शन:

• चेकलिस्ट को इतना छोटा रखें कि लोग वास्तव में उन्हें पूरा करें। यदि किसी चेकलिस्ट को नियमित रूप से छोड़ दिया जाता है, तो यह बहुत लंबी या बहुत सामान्य है।
• किसी भी ऐसे आइटम को स्वचालित करें जिसे मशीन सत्यापित कर सकती है (फ़ॉर्मैटिंग, टेस्ट, स्कैन) ताकि मनुष्य अपना ध्यान निर्णय-क्षमता वाले आइटम पर लगाएँ।
• अपनी चेकलिस्ट को वर्ज़न करें और उन्हें समय-समय पर समीक्षा करें। एक चेकलिस्ट जो कभी नहीं बदलती वह शायद उपयोग में नहीं है।
• जब यह अंतर आपकी प्रक्रिया के लिए मायने रखे तो अवरोधक (blocking) आइटम को सलाहकार आइटम से अलग करें।

कोड समीक्षा चेकलिस्ट

किसी और के परिवर्तन की जाँच करने वाले समीक्षक के लिए।

• परिवर्तन वही करता है जो इसका विवरण और जुड़ा हुआ टिकट कहता है।
• दायरा एक ही तार्किक विषय पर केंद्रित है; असंबंधित परिवर्तनों को अलग कर दिया गया है।
• डिज़ाइन मौजूदा आर्किटेक्चर में फ़िट बैठता है और ऐसा युग्मन पेश नहीं करता जिससे आसानी से बचा जा सकता था।
• केवल हैप्पी पाथ ही नहीं, बल्कि एज केस, एरर पाथ, और फेलियर मोड भी संभाले गए हैं।
• टेस्ट मौजूद हैं, सार्थक हैं, और यदि व्यवहार रिग्रेस होता तो विफल हो जाते।
• नामकरण, संरचना, और टिप्पणियाँ कोड को भविष्य के पाठक के लिए समझने योग्य बनाते हैं।
• कोई सीक्रेट्स, क्रेडेंशियल्स, टोकन, या व्यक्तिगत डेटा कमिट नहीं किया गया है।
• सुरक्षा-संवेदनशील इनपुट को उपयुक्त रूप से सत्यापित, एन्कोड, या पैरामीटराइज़ किया गया है।
• सार्वजनिक इंटरफ़ेस, कॉन्ट्रैक्ट, और पश्चगामी अनुकूलता को संरक्षित रखा गया है या जानबूझकर वर्ज़न किया गया है।
• प्रोडक्शन में परिवर्तन को संचालित करने के लिए लॉगिंग, मेट्रिक्स, और एरर रिपोर्टिंग पर्याप्त हैं।
• परिवर्तन से मेल खाने के लिए दस्तावेज़ीकरण, रनबुक, और कॉन्फ़िगरेशन को अपडेट किया गया है।
• फ़ीडबैक को अवरोधक मुद्दों बनाम सुझावों में अलग किया गया है, और इसे कोड के बारे में वाक्यबद्ध किया गया है।

पुल रिक्वेस्ट लेखक चेकलिस्ट

समीक्षा का अनुरोध करने से पहले लेखक के लिए।

• PR इतना छोटा और केंद्रित है कि इसे एक ही बैठक में सावधानी से समीक्षा किया जा सके।
• विवरण बताता है कि क्या बदला, क्यों, और इसे कैसे सत्यापित किया गया।
• जुड़ा हुआ टिकट, इश्यू, या डिज़ाइन दस्तावेज़ समीक्षकों को आवश्यक संदर्भ देता है।
• सभी स्वचालित जाँच स्थानीय रूप से या CI में पास होती हैं (बिल्ड, लिंट, फ़ॉर्मैट, टेस्ट, स्कैन)।
• नया और बदला हुआ व्यवहार टेस्ट द्वारा कवर किया गया है।
• यांत्रिक रीफ़ैक्टर को व्यवहार परिवर्तनों से अलग किया गया है।
• स्व-समीक्षा पूर्ण है: आपने अपने स्वयं के डिफ़ को लाइन दर लाइन पढ़ा है।
• कोई डीबग कोड, कमेंट किए गए ब्लॉक, सीक्रेट्स, या भटकी हुई फ़ाइलें शेष नहीं हैं।
• डेटाबेस माइग्रेशन, फ़ीचर फ़्लैग, और कॉन्फ़िग परिवर्तन दस्तावेज़ीकृत और प्रतिवर्तनीय हैं।
• तोड़ने वाले परिवर्तनों को एक माइग्रेशन पथ के साथ स्पष्ट रूप से इंगित किया गया है।
• जहाँ वे समीक्षा में सहायक हों वहाँ स्क्रीनशॉट, रिकॉर्डिंग, या नमूना आउटपुट शामिल किए गए हैं।
• सही समीक्षकों और किसी भी आवश्यक भूमिका-आधारित अनुमोदकों का अनुरोध किया गया है।

डेफ़िनिशन ऑफ़ डन (Definition of Done)

साझा मानक जिसे किसी कार्य आइटम को पूर्ण माने जाने से पहले पूरा करना चाहिए।

• टिकट में सभी स्वीकृति मानदंड पूरे किए गए हैं और प्रदर्शनीय हैं।
• कोड की आवश्यक समीक्षकों द्वारा पीयर समीक्षा और अनुमोदन किया गया है।
• स्वचालित टेस्ट लिखे गए हैं, पास हो रहे हैं, और परिवर्तन के साथ मर्ज किए गए हैं।
• कोड मेननलाइन में मर्ज किया गया है और पाइपलाइन के माध्यम से साफ़-सुथरे ढंग से डिप्लॉय होता है।
• सहमत गंभीरता सीमा के कोई ज्ञात दोष खुले नहीं रहते।
• दस्तावेज़ीकरण, हेल्प टेक्स्ट, और रनबुक अपडेट किए गए हैं।
• ऑब्ज़र्वेबिलिटी मौजूद है: प्रासंगिक लॉग, मेट्रिक्स, और अलर्ट मौजूद हैं।
• सुरक्षा और गोपनीयता के प्रभावों पर विचार किया गया है और उन्हें संबोधित किया गया है।
• जहाँ उपयोगकर्ता-सामना है वहाँ परिवर्तन के लिए एक्सेसिबिलिटी आवश्यकताएँ पूरी की गई हैं।
• फ़ीचर फ़्लैग कॉन्फ़िगर किए गए हैं और रोलआउट योजना पर सहमति है।
• प्रोडक्ट ओनर या हितधारक ने परिणाम को स्वीकार किया है।
• किसी भी अनुवर्ती कार्य को निहित नहीं छोड़ा गया, बल्कि ट्रैक किए गए टिकट के रूप में दर्ज किया गया है।

प्रोडक्शन लॉन्च / गो-लाइव तैयारी

प्रोडक्शन में कोई महत्वपूर्ण परिवर्तन या नई सेवा भेजने से पहले।

• चरणबद्ध या कैनरी चरणों और सफलता मानदंडों सहित रोलआउट योजना दस्तावेज़ीकृत है।
• रोलबैक योजना दस्तावेज़ीकृत, परीक्षित है, और इसे जल्दी से निष्पादित किया जा सकता है।
• क्षमता और लोड टेस्टिंग दिखाती है कि सिस्टम अपेक्षित और चरम माँग को पूरा करता है।
• निगरानी, डैशबोर्ड, और अलर्ट लॉन्च से पहले लाइव और सत्यापित हैं।
• ऑन-कॉल कवरेज निर्धारित है और प्रतिक्रियादाता सिस्टम को जानते हैं।
• सबसे संभावित विफलता और परिचालन परिदृश्यों के लिए रनबुक मौजूद हैं।
• निर्भरताएँ, इंटीग्रेशन, और थर्ड पार्टी तैयार होने की पुष्टि की गई है और रेट सीमाएँ समझी गई हैं।
• सुरक्षा समीक्षा और आवश्यक साइन-ऑफ़ पूर्ण हैं।
• यदि कोई डेटा माइग्रेशन है, तो उसे सत्यापित बैकआउट के साथ आरंभ से अंत तक परीक्षित किया गया है।
• फ़ीचर फ़्लैग बिना पुनः-डिप्लॉय के परिवर्तन को अक्षम करने की अनुमति देते हैं।
• जहाँ आवश्यक हो वहाँ कानूनी, गोपनीयता, और अनुपालन अनुमोदन प्राप्त किए गए हैं।
• संचार योजना हितधारकों, सहायता, और ग्राहकों को कवर करती है।
• एक गो/नो-गो निर्णय नामित स्वामियों द्वारा स्पष्ट मानदंडों के विरुद्ध लिया जाता है।

सुरक्षा समीक्षा / थ्रेट-मॉडल चेकलिस्ट

किसी परिवर्तन या सिस्टम की सुरक्षा स्थिति का आकलन करने के लिए।

• ट्रस्ट सीमाएँ और डेटा प्रवाह की पहचान की गई है और दस्तावेज़ीकृत हैं।
• हर उस प्रवेश बिंदु पर प्रमाणीकरण लागू किया गया है जिसे इसकी ज़रूरत है।
• प्राधिकरण जाँच हर कार्रवाई और संसाधन के लिए न्यूनतम विशेषाधिकार लागू करती है।
• सभी बाहरी इनपुट सत्यापित है, और आउटपुट को इसके सिंक के लिए एन्कोड किया गया है।
• सीक्रेट्स एक प्रबंधित वॉल्ट में संग्रहित हैं, कभी कोड या कॉन्फ़िग में नहीं, और घुमाने योग्य हैं।
• डेटा वर्गीकरण की आवश्यकता के अनुसार ट्रांज़िट और रेस्ट में एन्क्रिप्टेड है।
• निर्भरताओं को ज्ञात भेद्यताओं के लिए स्कैन किया जाता है और अद्यतन रखा जाता है।
• अविश्वसनीय इनपुट के लिए इंजेक्शन, डीसीरियलाइज़ेशन, और SSRF जोखिमों को कम किया गया है।
• संवेदनशील डेटा दर्ज किए बिना सुरक्षा-प्रासंगिक घटनाओं को लॉग किया जाता है।
• रेट लिमिटिंग, कोटा, और दुरुपयोग सुरक्षा उजागर एंडपॉइंट की रक्षा करती हैं।
• एरर संदेश स्टैक ट्रेस, आंतरिक जानकारी, या संवेदनशील विवरण लीक नहीं करते।
• STRIDE या समान माध्यम से पहचाने गए खतरों को शमन उपायों या स्वीकृत जोखिम के साथ दर्ज किया जाता है।
• सुरक्षा टेस्टिंग (SAST, DAST, या पेनिट्रेशन टेस्टिंग) की योजना बनाई गई है या पूर्ण है।

गोपनीयता और डेटा-सुरक्षा (DPIA-शैली) चेकलिस्ट

ऐसी प्रोसेसिंग के लिए जिसमें व्यक्तिगत या संवेदनशील डेटा शामिल हो।

• एकत्रित व्यक्तिगत डेटा की सूची बनाई गई है, वर्गीकृत किया गया है, और आवश्यकता तक न्यूनतम किया गया है।
• हर प्रोसेसिंग उद्देश्य के लिए कानूनी आधार या प्राधिकार दस्तावेज़ीकृत है।
• उद्देश्य सीमा लागू की गई है: डेटा का उपयोग केवल बताए गए उद्देश्यों के लिए किया जाता है।
• प्रतिधारण अवधि परिभाषित है और डिलीशन या अनाम-करण स्वचालित है।
• डेटा विषय के अधिकार (एक्सेस, सुधार, डिलीशन, पोर्टेबिलिटी) पूरे किए जा सकते हैं।
• जहाँ सहमति पर निर्भर किया जाता है, वह स्वतंत्र रूप से दी गई, विशिष्ट, और वापस लेने योग्य है।
• थर्ड पार्टी और प्रोसेसर पर्याप्त डेटा-सुरक्षा शर्तों से बंधे हैं।
• सीमा-पार स्थानांतरण में एक उपयुक्त कानूनी स्थानांतरण तंत्र है।
• व्यक्तिगत डेटा तक पहुँच प्रतिबंधित, लॉग की गई, और समीक्षित है।
• व्यक्तियों के लिए गोपनीयता जोखिमों का आकलन किया गया है और उन्हें कम किया गया है या एस्केलेट किया गया है।
• डेटा उल्लंघन पहचान और सूचना प्रक्रियाएँ परिभाषित हैं।
• सुविधा के लिए प्राइवेसी बाय डिज़ाइन और डिफ़ॉल्ट विकल्प दस्तावेज़ीकृत हैं।
• जहाँ आवश्यक हो वहाँ डेटा सुरक्षा अधिकारी या गोपनीयता समीक्षक ने साइन-ऑफ़ दिया है।

एक्सेसिबिलिटी (WCAG) चेकलिस्ट

WCAG सिद्धांतों के अनुरूप, उपयोगकर्ता-सामना इंटरफ़ेस के लिए।

• सारी सामग्री केवल कीबोर्ड का उपयोग करके पहुँच योग्य और संचालन योग्य है।
• फ़ोकस क्रम तार्किक है और एक दृश्यमान फ़ोकस संकेतक मौजूद है।
• टेक्स्ट रंग कंट्रास्ट लक्षित अनुपात को पूरा करता है (आमतौर पर बॉडी टेक्स्ट के लिए 4.5:1)।
• छवियों और गैर-टेक्स्ट सामग्री में सार्थक वैकल्पिक टेक्स्ट है।
• फ़ॉर्म फ़ील्ड में संबद्ध लेबल और स्पष्ट एरर संदेश हैं।
• हेडिंग, लैंडमार्क, और संरचना को अर्थपूर्ण ढंग से मार्कअप किया गया है।
• इंटरैक्टिव कंपोनेंट सहायक तकनीक को सही नाम, भूमिका, और स्थिति उजागर करते हैं।
• सामग्री 200% ज़ूम पर और छोटी स्क्रीन पर फिर से प्रवाहित होती है और उपयोग योग्य बनी रहती है।
• समय सीमाएँ समायोज्य हैं, और गति या ऑटो-प्ले होने वाली सामग्री को रोका जा सकता है।
• रंग जानकारी बताने का एकमात्र साधन नहीं है।
• मीडिया में कैप्शन हैं और, जहाँ आवश्यक हो, ट्रांसक्रिप्ट या ऑडियो विवरण हैं।
• इंटरफ़ेस का परीक्षण स्क्रीन रीडर और स्वचालित एक्सेसिबिलिटी टूलिंग से किया गया है।

API डिज़ाइन समीक्षा चेकलिस्ट

किसी API को प्रकाशित या परिवर्तित करने से पहले।

• संसाधन और संचालन नामकरण सुसंगत और अनुमानित है।
• कॉन्ट्रैक्ट को एक मशीन-पठनीय स्कीमा में निर्दिष्ट किया गया है (उदाहरण के लिए OpenAPI)।
• वर्ज़निंग रणनीति परिभाषित है और पश्चगामी अनुकूलता संरक्षित या प्रबंधित है।
• पेजिनेशन, फ़िल्टरिंग, और सॉर्टिंग सुसंगत परंपराओं का पालन करते हैं।
• एरर प्रतिक्रियाएँ सुसंगत संरचना, कोड, और कार्रवाई योग्य संदेशों का उपयोग करती हैं।
• हर संचालन के लिए प्रमाणीकरण और प्राधिकरण निर्दिष्ट है।
• इनपुट सत्यापन और आकार सीमाएँ परिभाषित और लागू हैं।
• जहाँ रीट्राई की अपेक्षा हो वहाँ संचालन के लिए आइडेम्पोटेंसी परिभाषित है।
• रेट सीमाएँ, कोटा, और थ्रॉटलिंग व्यवहार दस्तावेज़ीकृत हैं।
• टाइमआउट, रीट्राई, और फेलियर सिमैंटिक्स क्लाइंट के लिए स्पष्ट हैं।
• प्रतिक्रियाओं में संवेदनशील डेटा का उजागर होना न्यूनतम और उचित है।
• दस्तावेज़ीकरण में हर संचालन और एरर मामले के उदाहरण शामिल हैं।
• डेप्रिकेशन नीति और सनसेट समय-सीमाएँ परिभाषित हैं।

आर्किटेक्चर निर्णय (ADR) समीक्षा चेकलिस्ट

एक प्रस्तावित आर्किटेक्चर निर्णय रिकॉर्ड की समीक्षा के लिए।

• हल की जा रही समस्या और संदर्भ स्पष्ट रूप से बताए गए हैं।
• निर्णय को एक ही विकल्प के रूप में स्पष्ट रूप से बताया गया है।
• कम से कम दो यथार्थवादी विकल्पों पर विचार किया गया और उनकी तुलना की गई।
• सकारात्मक और नकारात्मक दोनों परिणाम दस्तावेज़ीकृत हैं।
• गैर-कार्यात्मक प्रभावों (प्रदर्शन, सुरक्षा, लागत, संचालन-क्षमता) को संबोधित किया गया है।
• निर्णय मौजूदा सिद्धांतों और पिछले ADR के अनुरूप है, या उन्हें स्पष्ट रूप से प्रतिस्थापित करता है।
• प्रभावित टीमों और हितधारकों से परामर्श किया गया था।
• परिवर्तन की प्रतिवर्तनीयता और लागत का आकलन किया गया है।
• धारणाओं और बाधाओं को स्पष्ट किया गया है।
• स्थिति (प्रस्तावित, स्वीकृत, प्रतिस्थापित) निर्धारित और दिनांकित है।
• निर्णय खोजने योग्य है और प्रासंगिक सिस्टम से जुड़ा हुआ है।
• किसी भी अनुवर्ती कार्रवाई या माइग्रेशन को ट्रैक किए गए कार्य के रूप में दर्ज किया गया है।

घटना प्रतिक्रिया चेकलिस्ट

एक सक्रिय प्रोडक्शन घटना के दौरान।

• घटना की घोषणा करें और एक ही इंसिडेंट कमांडर नियुक्त करें।
• गंभीरता, दायरे, और ग्राहक प्रभाव का आकलन करें और संप्रेषित करें।
• एक समर्पित संचार चैनल और घटना रिकॉर्ड खोलें।
• स्पष्ट भूमिकाएँ नियुक्त करें: कमांडर, संचार लीड, और संचालन लीड।
• रूट-कॉज़ विश्लेषण की तुलना में शमन और सेवा पुनर्स्थापना को प्राथमिकता दें।
• एक निर्धारित लय पर हितधारकों को नियमित स्थिति अपडेट पोस्ट करें।
• घटनाओं, कार्रवाइयों, और निर्णयों की एक समयरेखा को जैसे ही वे होते हैं दर्ज करें।
• ज़रूरत पड़ने पर अतिरिक्त प्रतिक्रियादाताओं या विक्रेताओं तक एस्केलेट करें।
• यदि डेटा या विनियमन शामिल है तो कानूनी, सुरक्षा, और अनुपालन को सूचित करें।
• सुधार को सत्यापित करें और पुष्टि करें कि सिस्टम पूरी तरह से उबर चुका है।
• औपचारिक रूप से घटना को बंद करें और समाधान को संप्रेषित करें।
• लोगों के तितर-बितर होने से पहले दोषरहित पोस्टमॉर्टम शेड्यूल करें।

पोस्टमॉर्टम चेकलिस्ट

किसी घटना के बाद की रेट्रोस्पेक्टिव समीक्षा के लिए।

• समीक्षा दोषरहित है और सिस्टम तथा योगदान देने वाले कारकों पर केंद्रित है।
• घटना की एक तथ्यात्मक, टाइमस्टैम्प्ड समयरेखा दस्तावेज़ीकृत है।
• ग्राहक और व्यावसायिक प्रभाव को मापा गया है (अवधि, दायरा, लागत)।
• पहचान का विश्लेषण किया गया है: मुद्दे को कैसे और कब देखा गया।
• प्रतिक्रिया का विश्लेषण किया गया है: किसने मदद की और किसने पुनर्प्राप्ति को धीमा किया।
• केवल एक ही रूट कॉज़ नहीं, बल्कि योगदान देने वाले कारणों की पहचान की गई है।
• क्या अच्छा हुआ, इसे भी दर्ज किया गया है, साथ ही क्या गलत हुआ।
• कार्रवाई आइटम विशिष्ट हैं, स्वामियों को सौंपे गए हैं, और उनकी नियत तारीखें हैं।
• कार्रवाई आइटम रोकथाम, पहचान, और शमन को संबोधित करते हैं।
• अनुवर्ती आइटम को सामान्य बैकलॉग में पूर्णता तक ट्रैक किया जाता है।
• पोस्टमॉर्टम को व्यापक रूप से साझा किया जाता है ताकि अन्य लोग इससे सीख सकें।
• घटनाओं में व्यवस्थागत पैटर्न की समय-समय पर समीक्षा की जाती है।

ऑन-कॉल तैयारी चेकलिस्ट

किसी के ऑन-कॉल शिफ्ट लेने से पहले।

• प्रतिक्रियादाता के पास उन सभी सिस्टम, डैशबोर्ड, और टूल तक पहुँच है जिनकी उन्हें ज़रूरत है।
• अलर्टिंग विश्वसनीय रूप से प्रतिक्रियादाता तक पहुँचती है और परीक्षित है।
• एस्केलेशन पथ और द्वितीयक ऑन-कॉल संपर्क ज्ञात और अद्यतन हैं।
• सबसे सामान्य और सबसे गंभीर अलर्ट के लिए रनबुक मौजूद हैं।
• प्रतिक्रियादाता ने इन सिस्टम के लिए ऑनबोर्डिंग या शैडोइंग पूरी कर ली है।
• हाल के परिवर्तन, चल रही घटनाएँ, और ज्ञात मुद्दे सौंपे गए हैं।
• शोर और गलत पेज को कम करने के लिए अलर्ट सीमाओं को ट्यून किया गया है।
• प्रतिक्रियादाता जानता है कि घटना कैसे घोषित करें और कमांडर तक कैसे पहुँचें।
• प्रतिक्रियादाता के कार्य वातावरण से प्रोडक्शन तक पहुँच संभव है।
• संचार चैनल और हितधारक संपर्क दस्तावेज़ीकृत हैं।
• ऑन-कॉल शेड्यूल प्रकाशित है और कवरेज में कोई अंतराल नहीं है।
• ऑन-कॉल के लिए मुआवज़ा, अपेक्षाएँ, और कार्यभार सीमाएँ स्पष्ट हैं।

SLO परिभाषा चेकलिस्ट

एक सर्विस लेवल ऑब्जेक्टिव परिभाषित करते समय।

• वह उपयोगकर्ता यात्रा या क्षमता जिसकी SLO रक्षा करता है, स्पष्ट रूप से पहचानी गई है।
• सर्विस लेवल इंडिकेटर (SLI) को स्पष्ट, मापने योग्य मात्राओं के रूप में परिभाषित किया गया है।
• जहाँ संभव हो वहाँ SLI को उपयोगकर्ता के दृष्टिकोण से मापा जाता है।
• लक्ष्य को 100% पर नहीं, बल्कि उस स्तर पर तय किया गया है जिसकी उपयोगकर्ताओं को वास्तव में ज़रूरत है।
• मापन विंडो (उदाहरण के लिए रोलिंग 28 दिन) निर्दिष्ट है।
• लक्ष्य से प्राप्त एरर बजट की गणना की गई है और उसे समझा गया है।
• एक नीति परिभाषित करती है कि एरर बजट समाप्त होने पर क्या होता है।
• SLI के लिए डेटा स्रोत विश्वसनीय और इंस्ट्रूमेंटेड हैं।
• अलर्टिंग केवल सीमा उल्लंघनों से नहीं, बल्कि बर्न रेट से जुड़ी है।
• स्वामी और हितधारक सहमत हैं कि SLO यथार्थवादी और सार्थक है।
• SLO दस्तावेज़ीकृत है और डैशबोर्ड पर दृश्यमान है।
• सेवा के विकसित होने पर SLO की समीक्षा और संशोधन के लिए एक शेड्यूल मौजूद है।

CI/CD पाइपलाइन चेकलिस्ट

एक कंटीन्यूअस इंटीग्रेशन और डिलीवरी पाइपलाइन के लिए।

• हर कमिट एक स्वचालित बिल्ड और टेस्ट रन को ट्रिगर करता है।
• पाइपलाइन तेज़ी से विफल होती है और लेखकों को स्पष्ट रूप से परिणाम रिपोर्ट करती है।
• लिंटिंग, फ़ॉर्मैटिंग, और स्टैटिक विश्लेषण स्वचालित रूप से चलते हैं।
• यूनिट, इंटीग्रेशन, और प्रासंगिक एंड-टू-एंड टेस्ट पाइपलाइन में चलते हैं।
• सुरक्षा और निर्भरता स्कैनिंग हर बिल्ड पर चलती है।
• बिल्ड आर्टिफ़ैक्ट वर्ज़नयुक्त, अपरिवर्तनीय हैं, और एक रजिस्ट्री में संग्रहित हैं।
• सीक्रेट्स को सुरक्षित रूप से इंजेक्ट किया जाता है और कभी लॉग में प्रिंट नहीं किया जाता।
• डिप्लॉयमेंट वातावरण में स्वचालित और दोहराए जाने योग्य हैं।
• डिप्लॉयमेंट रणनीति (कैनरी, ब्लू-ग्रीन, रोलिंग) परिभाषित और उपयोग की जाती है।
• रोलबैक स्वचालित है या एक ही दस्तावेज़ीकृत कार्रवाई है।
• पाइपलाइन अनुमतियाँ न्यूनतम विशेषाधिकार का पालन करती हैं और ऑडिट योग्य हैं।
• पाइपलाइन कॉन्फ़िगरेशन को कोड के रूप में वर्ज़न कंट्रोल में संग्रहित किया जाता है।
• जहाँ आवश्यक हो वहाँ बिल्ड प्रोवेनेंस और एक सॉफ़्टवेयर बिल ऑफ़ मैटेरियल्स तैयार किए जाते हैं।

इन्फ्रास्ट्रक्चर-एज़-कोड समीक्षा चेकलिस्ट

कोड के रूप में परिभाषित इन्फ्रास्ट्रक्चर की समीक्षा के लिए।

• परिवर्तनों को पूरी तरह से कोड में व्यक्त किया जाता है और पाइपलाइन के माध्यम से लागू किया जाता है।
• अप्लाई करने से पहले एक प्लान या ड्राई-रन आउटपुट की समीक्षा की जाती है।
• समवर्ती परिवर्तनों को रोकने के लिए स्टेट को लॉकिंग के साथ सुरक्षित रूप से संग्रहित किया जाता है।
• संसाधन नामकरण, टैगिंग, और स्वामित्व परंपराओं का पालन करते हैं।
• न्यूनतम-विशेषाधिकार वाली IAM भूमिकाओं और नीतियों का उपयोग किया जाता है, जहाँ बचा जा सकता है वहाँ कोई वाइल्डकार्ड नहीं।
• नेटवर्क उजागरण न्यूनतम है; कोई अनपेक्षित सार्वजनिक पहुँच नहीं।
• सीक्रेट्स और संवेदनशील मान एक वॉल्ट से संदर्भित होते हैं, हार्डकोड नहीं किए गए।
• स्टोरेज, डेटाबेस, और ट्रांज़िट के लिए एन्क्रिप्शन सक्षम है।
• परिवर्तन आइडेम्पोटेंट हैं और फिर से लागू करने के लिए सुरक्षित हैं।
• ब्लास्ट रेडियस समझा गया है; विनाशकारी परिवर्तनों को इंगित किया जाता है।
• परिवर्तन के लागत प्रभाव पर विचार किया जाता है।
• मॉड्यूल पुन: प्रयोज्य, वर्ज़नयुक्त, और परीक्षित हैं।
• आउट-ऑफ़-बैंड परिवर्तनों को पकड़ने के लिए ड्रिफ्ट डिटेक्शन मौजूद है।

AI/ML मॉडल रिलीज़ चेकलिस्ट

किसी मशीन लर्निंग मॉडल को प्रोडक्शन में रिलीज़ करने से पहले।

• मॉडल का इच्छित उपयोग, दायरा, और सीमाएँ दस्तावेज़ीकृत हैं।
• प्रशिक्षण और मूल्यांकन डेटा की उत्पत्ति, लाइसेंसिंग, और सहमति सत्यापित हैं।
• डेटा और मॉडल वर्ज़नयुक्त और पुनरुत्पादनीय हैं।
• प्रदर्शन का मूल्यांकन प्रतिनिधिक, अलग रखे गए टेस्ट डेटा पर किया जाता है।
• प्रासंगिक उप-समूहों में निष्पक्षता और पूर्वाग्रह का आकलन किया जाता है।
• मॉडल का मूल्यांकन मौजूदा या एक बेसलाइन के विरुद्ध किया जाता है।
• फेलियर मोड, एज केस, और आउट-ऑफ़-डिस्ट्रीब्यूशन व्यवहार को समझा गया है।
• सुरक्षा, दुरुपयोग, और हानिकारक-आउटपुट जोखिमों का आकलन किया गया है और उन्हें कम किया गया है।
• ड्रिफ्ट, डेटा गुणवत्ता, और प्रदर्शन में गिरावट के लिए निगरानी मौजूद है।
• पिछले मॉडल या नियम-आधारित पथ पर एक रोलबैक या फ़ॉलबैक मौजूद है।
• महत्वपूर्ण निर्णयों के लिए मानव निरीक्षण या अपील प्रदान की जाती है।
• गोपनीयता समीक्षा प्रशिक्षण डेटा और इन्फरेंस इनपुट तथा आउटपुट को कवर करती है।
• हितधारकों के लिए एक मॉडल कार्ड या समकक्ष दस्तावेज़ीकरण प्रकाशित किया जाता है।

डेटा पाइपलाइन गुणवत्ता चेकलिस्ट

एक डेटा पाइपलाइन के लिए जो एनालिटिक्स या उत्पादों को फ़ीड करती है।

• स्रोत डेटा स्कीमा सत्यापित हैं और स्कीमा परिवर्तनों का पता लगाया जाता है।
• इंजेशन देर से आए, डुप्लिकेट, और क्रम से बाहर के रिकॉर्ड को सही ढंग से संभालता है।
• डेटा गुणवत्ता जाँच (पूर्णता, विशिष्टता, रेंज) स्वचालित रूप से चलती हैं।
• विफल रिकॉर्ड को चुपचाप गिराया नहीं जाता, बल्कि क्वारंटीन और उजागर किया जाता है।
• ट्रांसफ़ॉर्मेशन का परीक्षण प्रतिनिधिक और एज-केस इनपुट से किया जाता है।
• पाइपलाइन आइडेम्पोटेंट है और विफलता के बाद फिर से चलाने के लिए सुरक्षित है।
• आउटपुट की ताज़गी और लेटेंसी की अपेक्षाओं के विरुद्ध निगरानी की जाती है।
• लीनिएज दस्तावेज़ीकृत है ताकि उपभोक्ताओं को पता हो कि डेटा कहाँ से आता है।
• व्यक्तिगत और संवेदनशील डेटा को उपयुक्त रूप से वर्गीकृत, मास्क, या प्रतिबंधित किया जाता है।
• बैकफ़िल और पुनःप्रोसेसिंग समर्थित और दस्तावेज़ीकृत हैं।
• अलर्टिंग स्वामियों को विफलताओं और गुणवत्ता उल्लंघनों की सूचना देती है।
• संग्रहित डेटा पर प्रतिधारण और डिलीशन नीतियाँ लागू होती हैं।
• डाउनस्ट्रीम उपभोक्ता और SLA दस्तावेज़ीकृत हैं।

ओपन सोर्स इनटेक और लाइसेंस समीक्षा चेकलिस्ट

किसी ओपन सोर्स कंपोनेंट को अपनाने से पहले।

• कंपोनेंट का लाइसेंस पहचाना गया है और स्वीकृत सूची में है।
• लाइसेंस दायित्वों (एट्रिब्यूशन, कॉपीलेफ़्ट, नोटिस) को समझा और पूरा किया गया है।
• आपके वितरण मॉडल के साथ लाइसेंस अनुकूलता की पुष्टि की गई है।
• परियोजना सक्रिय रूप से अनुरक्षित है और इसका एक स्वस्थ समुदाय है।
• ज्ञात भेद्यताओं की जाँच की गई है और वर्ज़न अद्यतन है।
• निर्भरता और इसकी सकर्मक (transitive) निर्भरताओं की सूची बनाई गई है।
• सुरक्षा स्थिति और पिछली घटना इतिहास की समीक्षा की गई है।
• कंपोनेंट महत्वपूर्ण दोहराव के बिना एक वास्तविक ज़रूरत को पूरा करता है।
• कंपोनेंट की निकास लागत और प्रतिस्थापन-क्षमता पर विचार किया गया है।
• कंपोनेंट को सॉफ़्टवेयर बिल ऑफ़ मैटेरियल्स में दर्ज किया गया है।
• एक नामित स्वामी अपडेट और एडवाइज़री को ट्रैक करने के लिए ज़िम्मेदार है।
• यदि संशोधित किया गया है तो योगदान-वापसी और आंतरिक-फ़ोर्क नीतियों का पालन किया जाता है।

विक्रेता / थर्ड-पार्टी जोखिम चेकलिस्ट

किसी बाहरी विक्रेता या सेवा को ऑनबोर्ड करने से पहले।

• व्यावसायिक ज़रूरत और वह डेटा जिस तक विक्रेता की पहुँच होगी, स्पष्ट रूप से परिभाषित हैं।
• विक्रेता की सुरक्षा स्थिति का आकलन किया जाता है (प्रमाणन, ऑडिट, प्रश्नावली)।
• डेटा प्रोसेसिंग शर्तें, स्वामित्व, और निकास पर डिलीशन अनुबंधात्मक रूप से स्पष्ट हैं।
• विक्रेता के सब-प्रोसेसर और डेटा स्थान प्रकट किए गए हैं और स्वीकार्य हैं।
• प्रासंगिक विनियमों के साथ अनुपालन सत्यापित है।
• अपटाइम, सहायता, और SLA प्रतिबद्धताएँ दस्तावेज़ीकृत हैं।
• उल्लंघन-सूचना दायित्व और समय-सीमाएँ अनुबंध में हैं।
• पहुँच को न्यूनतम विशेषाधिकार तक सीमित किया गया है और यह वापस लेने योग्य है।
• व्यवसाय निरंतरता और विक्रेता की विफलता के प्रभाव का आकलन किया गया है।
• लॉक-इन से बचने के लिए एक निकास और डेटा-माइग्रेशन योजना मौजूद है।
• लागत, नवीनीकरण शर्तें, और मूल्य-परिवर्तन खंड समझे गए हैं।
• विक्रेता को एक समीक्षा तारीख के साथ जोखिम रजिस्टर में जोड़ा गया है।

सरकारी अनुपालन (ATO / FedRAMP-शैली) तैयारी चेकलिस्ट

संचालन के लिए औपचारिक प्राधिकरण की आवश्यकता वाले सिस्टम के लिए।

• सिस्टम सीमा और डेटा प्रवाह परिभाषित और आरेखित हैं।
• डेटा को प्रभाव स्तर और संवेदनशीलता के अनुसार वर्गीकृत किया गया है।
• लागू नियंत्रण बेसलाइन का चयन किया गया है और इसे अनुकूलित किया गया है।
• एक सिस्टम सुरक्षा योजना दस्तावेज़ीकृत करती है कि हर नियंत्रण को कैसे लागू किया जाता है।
• नियंत्रणों को लागू किया गया है, प्रमाणित किया गया है, और योजना से मैप किया गया है।
• सतत निगरानी और भेद्यता स्कैनिंग परिचालन में हैं।
• एक कार्य योजना और माइलस्टोन खुले निष्कर्षों को सुधार तक ट्रैक करते हैं।
• एक्सेस कंट्रोल, ऑडिट लॉगिंग, और पहचान प्रबंधन आवश्यकताओं को पूरा करते हैं।
• एन्क्रिप्शन स्वीकृत एल्गोरिद्म और सत्यापित मॉड्यूल का उपयोग करता है।
• एक घटना प्रतिक्रिया योजना दस्तावेज़ीकृत और परीक्षित है।
• एक कंटिनजेंसी और डिज़ास्टर रिकवरी योजना दस्तावेज़ीकृत और परीक्षित है।
• नियंत्रणों का एक स्वतंत्र मूल्यांकन या ऑडिट पूर्ण है।
• प्राधिकृत अधिकारी के पास प्राधिकरण प्रदान करने के लिए आवश्यक जोखिम मूल्यांकन है।
• पुनः-प्राधिकरण ट्रिगर और चल रही प्राधिकरण लय परिभाषित हैं।