विषय 3.6 — DevOps और इंजीनियरिंग उत्कृष्टता

एक वाक्य में: क्लिनिकल सिस्टमों में, अनुशासित इंजीनियरिंग — स्वचालित पाइपलाइन, छोटी उलटने योग्य रिलीज़, इंफ्रास्ट्रक्चर-एज़-कोड, और अवलोकन-योग्यता — ही है जो परिवर्तन को अधिक सुरक्षित बनाती है, अधिक जोखिम भरा नहीं, और "हम सॉफ़्टवेयर कैसे बनाते और चलाते हैं" को एक सुरक्षा, समानता, और सार्वजनिक-विश्वास चिंता के रूप में मानना एक परिपक्व डिजिटल स्वास्थ्य संगठन की निशानी है।

यह स्वास्थ्य और देखभाल में क्यों महत्वपूर्ण है#

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

विनियमित डोमेन में एक स्थायी और खतरनाक मिथक है कि परिवर्तन जोखिम है, इसलिए सबसे सुरक्षित सिस्टम वह है जिसे आप सबसे कम छूते हैं। साक्ष्य दूसरी दिशा में इशारा करता है। सिस्टम जिन्हें शायद ही कभी बदला जाता है वे बिना-पैच किए भेद्यताएं, नाजुक मैनुअल तैनाती कदम, और अदस्तावेज़ीकृत जनजातीय ज्ञान जमा करते हैं; जब परिवर्तन अंततः अपरिहार्य हो जाता है — एक सुरक्षा पैच, एक नियामक समय सीमा, एक आपूर्तिकर्ता वापसी — यह एक बड़े, जोखिम भरे, खराब समझे गए "बिग बैंग" के रूप में आता है। जो संगठन छोटे परिवर्तनों को बार-बार, स्वचालन और तेज़ रोलबैक के साथ तैनात करते हैं, वे कम विफलताओं का अनुभव करते हैं और उनसे तेज़ी से उबरते हैं। स्वास्थ्य और देखभाल में, वह अंतर रोगी सुरक्षा में मापा जाता है।

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

मुख्य अवधारणाएं#

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

निरंतर एकीकरण और निरंतर डिलीवरी (CI/CD)। निरंतर एकीकरण (CI) का अर्थ है कि हर डेवलपर छोटे परिवर्तनों को बार-बार एक साझा मुख्य शाखा में मर्ज करता है, हर एक एक स्वचालित बिल्ड और परीक्षण रन को ट्रिगर करता है ताकि समस्याएं मिनटों के भीतर सामने आएं। निरंतर डिलीवरी (CD) इसे विस्तारित करती है ताकि सॉफ़्टवेयर हमेशा एक रिलीज़ योग्य स्थिति में हो और एक स्वचालित, दोहराने योग्य पाइपलाइन के माध्यम से प्रोडक्शन में तैनात किया जा सके। निरंतर तैनाती एक कदम आगे जाती है, पाइपलाइन को पास करने वाले हर परिवर्तन को स्वचालित रूप से जारी करती है। परीक्षण पाइपलाइन के द्वारों की सामग्री है — विषय 3.7 — परीक्षण और गुणवत्ता आश्वासन में गहराई से कवर किया गया।

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

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

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

DORA मीट्रिक। DevOps Research and Assessment (DORA) ने चार माप पहचाने जो उच्च-प्रदर्शन करने वाली टीमों को अलग करते हैं: तैनाती आवृत्ति (आप कितनी बार जारी करते हैं), परिवर्तनों के लिए लीड समय (कमिट से प्रोडक्शन तक कितना समय), परिवर्तन-विफलता दर (कितने अनुपात परिवर्तन एक समस्या का कारण बनते हैं), और सेवा बहाल करने का समय (आप कितनी तेज़ी से ठीक होते हैं)। साथ में वे प्रकट करते हैं कि गति और स्थिरता एक साथ बढ़ती हैं — जो टीमें सबसे अधिक बार तैनात करती हैं वे भी सबसे कम विफल होती हैं और सबसे तेज़ ठीक होती हैं।

"आप इसे बनाते हैं, आप इसे चलाते हैं," SRE, और अवलोकन-योग्यता। Amazon में लोकप्रिय बनाया गया, "आप इसे बनाते हैं, आप इसे चलाते हैं" का अर्थ है कि जो टीम एक सेवा लिखती है वह इसे संचालित भी करती है, पेजर रखती है, और इसकी विफलताओं को महसूस करती है — इंजीनियरिंग विकल्पों और परिचालन वास्तविकता के बीच फीडबैक लूप को बंद करते हुए (देखें विषय 3.8 — सेवा प्रबंधन और लाइव संचालन)। Site reliability engineering (SRE) एक विशिष्ट कार्यान्वयन है जो संचालन में इंजीनियरिंग लागू करता है, स्पष्ट विश्वसनीयता लक्ष्यों और त्रुटि बजट के साथ। अवलोकन-योग्यता — एक सिस्टम की आंतरिक स्थिति को इसके आउटपुट (मीट्रिक, लॉग, ट्रेस) से समझने की क्षमता — वह है जो आपको रोगियों और क्लिनिशियनों से पहले समस्याओं का पता लगाने और निदान करने देती है।

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

खुले में कोडिंग और ओपन-सोर्स सॉफ़्टवेयर। यूके सरकार नीति — GDS Service Standard और NHS Service Standard में व्यक्त — टीमों से नए स्रोत कोड को डिफ़ॉल्ट रूप से खुला बनाने और खुले मानकों का उपयोग करने के लिए कहती है। सार्वजनिक रूप से वित्तपोषित स्वास्थ्य सॉफ़्टवेयर के लिए यह जांच, पुनः उपयोग, और विश्वास में सुधार करता है, बशर्ते रोगी डेटा और वास्तविक रहस्य कठोरता से सार्वजनिक भंडारों से बाहर रखे जाएं।

सर्वोत्तम प्रथाएं#

1. सेवा बनाने से पहले एक CI/CD पाइपलाइन बनाएं। पहले हफ्ते से स्वचालित बिल्ड, परीक्षण, और तैनाती स्थापित करें, ताकि हर परिवर्तन प्रोडक्शन के लिए उसी दोहराने योग्य, ऑडिट योग्य मार्ग से बहे। पाइपलाइन वह जगह है जहां आपके क्लिनिकल-सुरक्षा, सुरक्षा, और अभिगम्यता द्वार स्वचालित जांच के रूप में रहते हैं, आपको यह ठीक-ठीक क्या तैनात किया गया था और कब का एक दस्तावेज़ीकृत, छेड़छाड़-स्पष्ट रिकॉर्ड देते हुए। एक विनियमित सिस्टम में यह ऑडिट ट्रेल ओवरहेड नहीं है — यह आपके क्लिनिकल सुरक्षा मामले के लिए साक्ष्य है (देखें विषय 1.6 — क्लिनिकल सुरक्षा और जोखिम प्रबंधन)।

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

3. तेज़, साफ़ रोलबैक को एक प्रथम-श्रेणी सुरक्षा नियंत्रण बनाएं। रोलबैक का उसी तरह पूर्वाभ्यास करें जैसे आप एक आग अभ्यास का करते हैं, और मापें कि वास्तव में इसमें कितना समय लगता है। एक क्लिनिकल सिस्टम में सबसे मूल्यवान एकल परिचालन क्षमता तब मिनटों के भीतर एक ज्ञात-अच्छी स्थिति में वापस आने की क्षमता है जब एक परिवर्तन नुकसान पहुंचाता है। रोलबैक जिसे कभी परखा नहीं गया वह एक आशा है, नियंत्रण नहीं; साबित करें कि यह काम करता है और इसे साबित करते रहें।

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

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

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

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

8. इंजीनियरिंग मानक सेट और लागू करें, और तकनीकी ऋण को सोच-समझकर प्रबंधित करें। कोडिंग मानकों, स्वचालित लिंटिंग, कोड समीक्षा, और एक स्पष्ट "पूर्णता की परिभाषा" पर सहमत हों, ताकि गुणवत्ता बाद में निरीक्षित होने के बजाय शामिल की जाए। तकनीकी ऋण को स्पष्ट रूप से ट्रैक करें और इसे नियोजित काम के रूप में चुकाएं, क्योंकि एक क्लिनिकल सिस्टम में अप्रबंधित ऋण चुपचाप हर भविष्य के परिवर्तन की लागत और जोखिम बढ़ाता है। मानक कोड को अगले इंजीनियर के लिए पठनीय बनाते हैं — और उन ऑडिटरों, सुरक्षा अधिकारियों, और ओपन-सोर्स समीक्षकों के लिए जिन्हें इसे पढ़ने की आवश्यकता हो सकती है।

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

आपकी टीम के साथ चर्चा करने के लिए प्रश्न#

1. क्या हम वास्तव में मानते हैं कि अपने क्लिनिकल सिस्टमों को अधिक बार बदलना उन्हें अधिक सुरक्षित बनाता है — और क्या हमारा व्यवहार उस विश्वास से मेल खाता है? यह प्रश्न एक टीम को साक्ष्य और प्रवृत्ति के बीच अंतर का सामना करने के लिए मजबूर करता है। DORA अनुसंधान स्पष्ट है कि छोटे परिवर्तनों को बार-बार तैनात करने वाली टीमों की विफलता दरें कम होती हैं और वे तेज़ी से ठीक होती हैं, फिर भी कई स्वास्थ्य संगठन अभी भी सुरक्षा के नाम पर परिवर्तनों को दुर्लभ, भारी द्वारित रिलीज़ में बैच करते हैं, अनजाने में हर एक को बड़ा और जोखिम भरा बनाते हुए। बहस करें कि आपकी परिवर्तन-सलाहकार प्रक्रियाएं वास्तव में जोखिम कहां कम करती हैं बनाम कहां वे केवल विलंब जोड़ती हैं जो टीमों को बिग-बैंग रिलीज़ की ओर धकेलती हैं। अपनी पिछली कुछ घटनाओं को ईमानदारी से देखें: क्या वे बार-बार छोटे परिवर्तनों के कारण थीं, या दुर्लभ बड़ी और बिना-पैच उपेक्षा के कारण? विचार करें कि क्या आपकी रोलबैक क्षमता वास्तविक और अभ्यास की गई है, क्योंकि बार-बार परिवर्तन का मामला पूरी तरह से इसे तेज़ी से उलटने में सक्षम होने पर टिका है। एक अच्छा उत्तर वैचारिक नहीं है; यह उन विशिष्ट नियंत्रणों को नाम देता है — स्वचालित परीक्षण, कैनरी रिलीज़, परखा गया रोलबैक — जो आपको परिवर्तन आवृत्ति बढ़ाने और साथ ही अपने क्लिनिकल-सुरक्षा और आश्वासन दायित्वों को पूरा करने देगा।

2. रात 2 बजे प्रोडक्शन में हमारी सेवाएं कौन चलाता है, और यह हमारे इंजीनियरिंग विकल्पों के बारे में हमें क्या बताता है? "आप इसे बनाते हैं, आप इसे चलाते हैं" का समर्थन करना आसान है और जीना कठिन है। यह प्रश्न सामने लाता है कि क्या वास्तुशिल्प और डिलीवरी निर्णय लेने वाले लोग वास्तव में परिचालन परिणाम महसूस करते हैं, या क्या पीड़ा एक अलग संचालन या सेवा-डेस्क टीम पर उतार दी जाती है जो मूल कारणों को ठीक नहीं कर सकती। अपनी अवलोकन-योग्यता की स्थिति खोजें: जब एक साझा देखभाल रिकॉर्ड धीमा हो जाता है, तो क्या आप इसे डैशबोर्ड और अलर्ट से सीखते हैं, या एक क्रोधित क्लिनिशियन से? मानवीय लागत पर भी चर्चा करें — ऑन-कॉल मानवीय, वित्तपोषित, और साझा होना चाहिए, या यह एक बर्नआउट और प्रतिधारण समस्या बन जाती है, जो एक कार्यबल-सीमित NHS में एक गंभीर जोखिम है (देखें विषय 7.2 — कार्यबल योजना)। पूर्ण टीम स्वामित्व और इस वास्तविकता के बीच एक वास्तविक समझौता है कि कुछ छोटे संगठनों और आपूर्तिकर्ताओं को चीज़ों को विश्वसनीय रूप से चलाने के लिए वास्तव में एक साझा प्लेटफ़ॉर्म या प्रबंधित सेवा की आवश्यकता है। एक मज़बूत उत्तर परिचालन ज़िम्मेदारी को डिज़ाइन से वापस जोड़ता है: यह पहचानता है कि निर्माण और चलाने के बीच फीडबैक लूप कहां टूटा है, और आप क्या बदलेंगे ताकि इंजीनियरिंग विकल्प लाइव संचालन की वास्तविकता से सूचित हों।

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

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

5. क्या हमारे इंजीनियरिंग मीट्रिक हमें सच बताते हैं, या वे चुपचाप एक प्रदर्शन लक्ष्य बन गए हैं जिसे लोग ऊपर की ओर प्रबंधित करते हैं? DORA मीट्रिक केवल एक ईमानदार सिस्टम-स्तरीय संकेत के रूप में उपयोगी हैं, और यह प्रश्न जांचता है कि क्या आपके मीट्रिक संगठनात्मक प्रोत्साहनों के संपर्क में बच गए हैं। Goodhart का नियम निर्दयी है: जिस क्षण तैनाती आवृत्ति या परिवर्तन-विफलता दर एक संख्या बन जाती है जिस पर एक टीम को आंका जाता है, लोग अंतर्निहित वास्तविकता के बजाय संख्या का अनुकूलन करते हैं — आवृत्ति को फुलाने के लिए तैनाती को विभाजित करना, या घटनाओं को चुपचाप फिर से वर्गीकृत करना ताकि वे विफलताओं के रूप में गिनी न जाएं। बहस करें कि इन मीट्रिकों को कौन देखता है और क्यों, और क्या उनका उपयोग परीक्षण कवरेज या बैच आकार में निवेश को प्रेरित करने के लिए निदानात्मक रूप से किया जा रहा है, या खेल और छिपे हुए जोखिम को चलाने वाली एक लीग तालिका के रूप में। दूसरे पहलू पर भी विचार करें: टीमें जो कुछ नहीं मापतीं और उपाख्यान पर भरोसा करती हैं, इसलिए एक बढ़ती विफलता दर अदृश्य होती है जब तक यह एक क्लिनिकल घटना न बन जाए। बोर्ड की वैध आश्वासन आवश्यकता और इस तथ्य के बीच एक वास्तविक तनाव है कि सबसे उपयोगी मीट्रिक वे हैं जिन्हें टीमें ईमानदारी से रिपोर्ट करना सुरक्षित महसूस करती हैं। एक अच्छा उत्तर वर्णन करता है कि माप को कैसे तैयार और प्रशासित किया जाता है ताकि यह असुविधाजनक सच्चाइयों को जल्दी सामने लाए बजाय उन्हें छुपाने के लिए लोगों को पुरस्कृत करने के।

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

व्यवहार में: एक स्वास्थ्य और देखभाल उदाहरण#

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

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

छह महीने बाद, DORA मीट्रिक बोर्ड को सादे शब्दों में कहानी बताते हैं: एक फिक्स के लिए लीड समय छह हफ्तों से एक दिन से कम हो गया है, तैनाती आवृत्ति दस गुना बढ़ गई है, और परिवर्तन-विफलता दर गिर गई है क्योंकि परिवर्तन अब छोटे और अवलोकन योग्य हैं। जब एक सूक्ष्म रूटिंग त्रुटि फिर से आती है, तो अवलोकन-योग्यता डैशबोर्ड मिनटों के भीतर विसंगति फ्लैग करते हैं, टीम किसी भी रेफरल के गलत रूट होने से पहले वापस रोल करती है, अगली सुबह एक फिक्स शिप करती है, और एक दोष-मुक्त घटना-पश्चात समीक्षा दर्ज करती है। टीम गैर-संवेदनशील रूटिंग-नियम इंजन को NHS Service Standard के तहत ओपन सोर्स के रूप में भी प्रकाशित करती है, और एक पड़ोसी ICS इसका पुनः उपयोग करता है। सिस्टम को अधिक बार बदलने ने इसे प्रमाणित रूप से अधिक सुरक्षित बना दिया है।

क्षेत्र दृष्टिकोण#

स्टार्टअप#

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

छोटा व्यवसाय#

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

बड़ा संगठन#

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

सरकार#

NHS England या एक विकेंद्रीकृत स्वास्थ्य विभाग जैसा एक राष्ट्रीय निकाय वे मानक निर्धारित करता है जिनका दूसरे पालन करते हैं — NHS और GDS Service Standard, व्यय नियंत्रण, खुले में कोड करने की अपेक्षा — और सॉफ़्टवेयर कैसे बनाया और चलाया जाता है इसके लिए संसद और जनता के प्रति जवाबदेह है। इसके इंजीनियरिंग विकल्प पूरी प्रणाली में तरंगें फैलाते हैं: एक अच्छी तरह से चलाया गया राष्ट्रीय प्लेटफ़ॉर्म, प्रकाशित ओपन-सोर्स घटक, और स्पष्ट आपूर्ति-श्रृंखला मार्गदर्शन हर ट्रस्ट और आपूर्तिकर्ता के लिए फर्श उठाते हैं। बाधाएं वास्तविक हैं — बहु-वर्षीय वित्तपोषण, खरीद नियम, और राष्ट्रीय डेटा का विशुद्ध पैमाना और संवेदनशीलता का अर्थ है कि तैनाती गति एक स्टार्टअप की तुलना में अधिक मापी जाती है। सरकारी लेंस को अनुकरणीय पारदर्शिता और पुनः उपयोग को राष्ट्रीय महत्वपूर्ण सिस्टमों की सुरक्षा के विरुद्ध संतुलित करना चाहिए, सोच-समझकर तय करना चाहिए कि क्या खोला जाता है और क्या सुरक्षित किया जाता है, और दोनों ही मामलों में तर्क को दस्तावेज़ीकृत करना चाहिए।

सामान्य विफलता मोड#

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

परिपक्वता मॉडल#

जांच-सूची#

• एक CI/CD पाइपलाइन हर परिवर्तन को एक ऑडिट योग्य मार्ग से बनाती, परखती, और तैनात करती है, सुरक्षा/सुरक्षा/अभिगम्यता द्वार एनकोडेड के साथ।
• परिवर्तन छोटे, बार-बार, और स्वतंत्र रूप से उलटने योग्य हैं (फ़ीचर फ्लैग, कैनरी या ब्लू-ग्रीन रिलीज़)।
• एक ज्ञात-अच्छी स्थिति में रोलबैक नियमित रूप से परखा जाता है और एक दस्तावेज़ीकृत, छोटे समय के भीतर पूरा होता है।
• इंफ्रास्ट्रक्चर और कॉन्फ़िगरेशन संस्करण-नियंत्रित कोड के रूप में परिभाषित हैं; परीक्षण और प्रोडक्शन वातावरण मेल खाते हैं।
• चार DORA मीट्रिक को एक सिस्टम-स्तरीय संकेत के रूप में ट्रैक किया जाता है, व्यक्तियों या टीमों को रैंक करने के लिए उपयोग नहीं किया जाता।
• डिलीवरी टीमें प्रोडक्शन में अपनी सेवाओं का स्वामित्व रखती हैं, मानवीय, वित्तपोषित ऑन-कॉल और सार्थक अवलोकन-योग्यता (मीट्रिक, लॉग, ट्रेस, अलर्टिंग) के साथ।
• निर्भरताओं की सूची बनाई और स्वचालित रूप से स्कैन की जाती है; एक सॉफ़्टवेयर सामग्री सूची मौजूद है और रहस्य संरक्षित हैं।
• इंजीनियरिंग मानक, कोड समीक्षा, और पूर्णता की एक परिभाषा पर सहमति है; तकनीकी ऋण ट्रैक किया जाता है और नियोजित काम के रूप में चुकाया जाता है।
• नया स्रोत कोड जहां सुरक्षित हो वहां डिफ़ॉल्ट रूप से खुला है, कठोर जांच के साथ कि कोई रोगी डेटा या रहस्य उजागर नहीं हैं।
• इंजीनियरिंग अभ्यास दस्तावेज़ीकृत है ताकि एक नया इंजीनियर, ऑडिटर, या सुरक्षा अधिकारी समझ सके कि क्या चलता है और क्यों (देखें विषय 10.3)।

मुख्य स्रोत#

• Nicole Forsgren, Jez Humble & Gene Kim, Accelerate: The Science of Lean Software and Development and DevOps — DORA अनुसंधान और चार मुख्य मीट्रिक।
• DORA (DevOps Research and Assessment) — वार्षिक State of DevOps रिपोर्ट और क्षमता सूची — dora.dev।
• Jez Humble & David Farley, Continuous Delivery — तैनाती पाइपलाइन और रिलीज़ स्वचालन।
• Betsy Beyer et al. (eds.), Site Reliability Engineering — प्रोडक्शन सिस्टम चलाने पर Google की SRE पुस्तक।
• NHS England — NHS Service Standard और NHS Digital Service Manual (खुले में कोडिंग और खुले मानकों सहित)।
• GOV.UK Service Manual / Government Service Standard (GDS) — "नए स्रोत कोड को खुला बनाएं", निरंतर डिलीवरी, और एक सेवा संचालित करना।
• National Cyber Security Centre (NCSC) — सुरक्षित सॉफ़्टवेयर विकास और आपूर्ति श्रृंखला सुरक्षा पर मार्गदर्शन।
• NHS England — क्लिनिकल जोखिम प्रबंधन मानक DCB0129 और DCB0160 (क्लिनिकल सुरक्षा मामले के भाग के रूप में इंजीनियरिंग परिवर्तन)।

संदर्भ#

1. DevOps — Wikipedia — https://en.wikipedia.org/wiki/DevOps
2. CI/CD — Wikipedia — https://en.wikipedia.org/wiki/CI/CD
3. Continuous integration — Wikipedia — https://en.wikipedia.org/wiki/Continuous_integration
4. Continuous delivery — Wikipedia — https://en.wikipedia.org/wiki/Continuous_delivery
5. Version control — Wikipedia — https://en.wikipedia.org/wiki/Version_control
6. Infrastructure as code — Wikipedia — https://en.wikipedia.org/wiki/Infrastructure_as_code
7. Platform engineering — Wikipedia — https://en.wikipedia.org/wiki/Platform_engineering
8. DevOps Research and Assessment (DORA) — Wikipedia — https://en.wikipedia.org/wiki/DevOps_Research_and_Assessment
9. Site reliability engineering — Wikipedia — https://en.wikipedia.org/wiki/Site_reliability_engineering
10. Observability (software) — Wikipedia — https://en.wikipedia.org/wiki/Observability_(software)
11. Supply chain attack — Wikipedia — https://en.wikipedia.org/wiki/Supply_chain_attack
12. Open-source software — Wikipedia — https://en.wikipedia.org/wiki/Open-source_software
13. Accelerate: The Science of Lean Software and DevOps — Nicole Forsgren, Jez Humble & Gene Kim (IT Revolution) — https://itrevolution.com/product/accelerate/
14. DORA — DevOps Research and Assessment — Google Cloud / DORA — https://dora.dev/
15. Continuous Delivery — Jez Humble & David Farley — https://continuousdelivery.com/
16. Site Reliability Engineering — Google (O'Reilly) — https://sre.google/books/
17. NHS Service Standard — NHS England — https://service-manual.nhs.uk/standards-and-technology/service-standard-points
18. Making source code open and reusable — Government Digital Service, GOV.UK Service Manual — https://www.gov.uk/service-manual/technology/making-source-code-open-and-reusable
19. Secure software development and supply chain security — National Cyber Security Centre (NCSC) — https://www.ncsc.gov.uk/collection/developers-collection
20. Clinical risk management standards DCB0129 and DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety