CNPA परीक्षा द्वारा परखे जाने वाले architectural patterns का स्कैन-योग्य संदर्भ। ऊपर से नीचे पढ़ें या किसी section पर जाएं।
प्लेटफ़ॉर्म इंजीनियरिंग के मुख्य सिद्धांत
प्लेटफ़ॉर्म टीम के लिए एक मुख्य सिद्धांत स्थापित करें ताकि अपनाने को सुनिश्चित किया जा सके और डेवलपर घर्षण को कम किया जा सके।
आंतरिक प्लेटफ़ॉर्म को एक उत्पाद के रूप में मानें। आंतरिक डेवलपर्स को ग्राहकों के रूप में मानें, उपयोगकर्ता अनुसंधान करें, प्रतिक्रिया एकत्र करें और उनकी संज्ञानात्मक भार को कम करने के लिए सुविधाओं पर पुनरावृति करें।
क्यों: यह मानसिकता बुनियादी ढांचे के निर्माण से मूल्य प्रदान करने की ओर ध्यान केंद्रित करती है, यह सुनिश्चित करती है कि प्लेटफ़ॉर्म डेवलपर्स की वास्तविक समस्याओं को हल करता है और इसे बाईपास नहीं किया जाता है ("शैडो IT")।
सभी बुनियादी ढांचे और अनुप्रयोगों की वांछित स्थिति के लिए सत्य का एक एकल स्रोत स्थापित करें।
Git रिपॉजिटरी को सत्य के एकल स्रोत के रूप में उपयोग करें। एक इन-क्लस्टर एजेंट (ArgoCD, Flux) तैनात करें जो Git के विरुद्ध क्लस्टर स्थिति की तुलना करने के लिए एक सतत सुलह लूप चलाता है।
क्यों: यह एक पूर्ण ऑडिट ट्रेल प्रदान करता है, आसान रोलबैक को सक्षम बनाता है, और आउट-ऑफ-बैंड परिवर्तनों को स्वचालित रूप से वापस करके कॉन्फ़िगरेशन ड्रिफ्ट को रोकता है।
कॉन्फ़िगरेशन ड्रिफ्ट को रोकें और सभी वातावरणों में तैनात आर्टिफैक्ट्स की निरंतरता सुनिश्चित करें।
बुनियादी ढांचे को अपरिवर्तनीय मानें। चल रहे संसाधनों को कभी संशोधित न करें। इसके बजाय, नए, संस्करणित आर्टिफैक्ट्स (कंटेनर इमेज, VM इमेज) बनाएं और पुराने को बदल दें। इसे रीड-ओनली कंटेनर फ़ाइलसिस्टम (`readOnlyRootFilesystem: true`) के साथ लागू करें।
क्यों: अपरिवर्तनीयता कॉन्फ़िगरेशन ड्रिफ्ट को समाप्त करती है और डिप्लॉयमेंट को अनुमानित और दोहराने योग्य बनाती है। "बदलें, मरम्मत न करें।
एक सुरक्षित GitOps डिप्लॉयमेंट मॉडल चुनें, खासकर मल्टी-क्लस्टर या प्रतिबंधित नेटवर्क वातावरण में।
एक पुल-आधारित मॉडल लागू करें। क्लस्टर के अंदर चल रहा एक एजेंट (ArgoCD, Flux) Git से मैनिफेस्ट खींचता है। पुश-आधारित मॉडल से बचें जहां एक बाहरी CI सिस्टम Kubernetes API पर धकेलता है।
क्यों: पुल-आधारित मॉडल अधिक सुरक्षित होते हैं क्योंकि उन्हें Kubernetes API सर्वर को बाहरी रूप से उजागर करने या CI में कई क्लस्टर के लिए क्रेडेंशियल्स का प्रबंधन करने की आवश्यकता नहीं होती है।
अनुभवी टीमों को अत्यधिक प्रतिबंधित किए बिना विकास में तेजी लाएं और सर्वोत्तम प्रथाओं को सुनिश्चित करें।
"गोल्डन पाथ" (या पक्की सड़कें) परिभाषित करें: सामान्य कार्यों के लिए पूर्व-कॉन्फ़िगर किए गए, अच्छी तरह से समर्थित टेम्पलेट और वर्कफ़्लो (जैसे, एक नई माइक्रोसेवा बनाना)।
क्यों: गोल्डन पाथ 80% मामलों के लिए संज्ञानात्मक भार और निर्णय थकान को कम करते हैं, लेकिन फिर भी अद्वितीय आवश्यकताओं वाली विशेषज्ञ टीमों के लिए "एस्केप हैच" की अनुमति देनी चाहिए।
एक साझा Kubernetes प्लेटफ़ॉर्म में उचित अलगाव स्तरों के साथ मल्टी-टेनेंसी प्रदान करें।
सबसे मजबूत अलगाव के लिए, अलग-अलग क्लस्टर का उपयोग करें। मजबूत अलगाव और दक्षता के संतुलन के लिए, वर्चुअल क्लस्टर (vClusters) का उपयोग करें। बुनियादी, सॉफ्ट मल्टी-टेनेंसी के लिए, RBAC, NetworkPolicies, और ResourceQuotas के साथ नेमस्पेस-स्तरीय अलगाव का उपयोग करें।
क्यों: चुनाव सुरक्षा और "शोरगुल वाले पड़ोसी" जोखिम पर निर्भर करता है। वर्चुअल क्लस्टर पूर्ण भौतिक क्लस्टर की लागत के बिना कंट्रोल प्लेन अलगाव प्रदान करते हैं।
प्लेटफ़ॉर्म टीम और स्ट्रीम-एलाइंड (उत्पाद) टीमों के बीच प्राथमिक इंटरेक्शन मोड को परिभाषित करें।
प्लेटफ़ॉर्म टीम को मुख्य रूप से "X-एज़-ए-सर्विस" मोड में काम करना चाहिए, जो स्व-सेवा उपकरण, API और दस्तावेज़ प्रदान करता है।
क्यों: बड़े पैमाने पर, एक प्लेटफ़ॉर्म टीम हर टीम के साथ उच्च-स्पर्श सहयोग मॉडल का उपयोग नहीं कर सकती। एज़-ए-सर्विस मॉडल स्केलिंग और डेवलपर स्वायत्तता को सक्षम बनाता है।
प्लेटफ़ॉर्म प्रेक्षणीयता (Observability), सुरक्षा और अनुरूपता (Conformance)
एक वितरित सिस्टम के लिए एक व्यापक प्रेक्षणीयता रणनीति (observability strategy) लागू करें।
तीन स्तंभों को एकत्र और सहसंबंधित करें: Metrics (Prometheus के माध्यम से संख्यात्मक समय-श्रृंखला डेटा), Logs (Fluent Bit के माध्यम से संरचित घटनाएँ), और Traces (OpenTelemetry के माध्यम से अनुरोध प्रवाह)।
क्यों: कोई भी एक स्तंभ पर्याप्त नहीं है। जटिल माइक्रोसेवा आर्किटेक्चर में समस्याओं का त्वरित निदान करने के लिए उन्हें सहसंबंधित करना (उदाहरण के लिए, लॉग में ट्रेस IDs एम्बेड करना) आवश्यक है।
सभी Kubernetes क्लस्टर में सुरक्षा और संगठनात्मक नीतियों को स्वचालित रूप से लागू करें।
OPA/Gatekeeper या Kyverno जैसे एक नीति इंजन का उपयोग करें, जिसे एक वैलिडेटिंग/म्यूटेटिंग एडमिशन कंट्रोलर के रूप में एकीकृत किया गया हो। नीतियों को Git में स्टोर करें और उन्हें GitOps के माध्यम से सिंक करें।
क्यों: यह स्वचालित, निवारक सुरक्षा प्रदान करता है, जिससे डेवलपर्स को उनकी CI/CD पाइपलाइन में तेजी से प्रतिक्रिया मिलती है, बजाय धीमी, मैन्युअल समीक्षा गेट्स के।
टीम के कौशल सेट और नीति की जटिलता के आधार पर Kubernetes के लिए एक नीति इंजन का चयन करें।
Kyverno का उपयोग उन नीतियों के लिए करें जिन्हें परिचित Kubernetes-शैली YAML में व्यक्त किया जा सकता है। OPA/Gatekeeper का उपयोग जटिल नीतियों के लिए करें जिनके लिए एक अधिक शक्तिशाली, उद्देश्य-निर्मित भाषा (Rego) और बाहरी डेटा एकीकरण की आवश्यकता होती है।
क्यों: Kyverno का Kubernetes अभ्यासकर्ताओं के लिए सीखने का वक्र कम है। OPA/Rego अधिक शक्तिशाली है लेकिन एक नई भाषा सीखने की आवश्यकता है।
उत्पादन में तैनात कंटेनर इमेज की अखंडता और प्रामाणिकता सुनिश्चित करें।
Sigstore/Cosign का उपयोग करके CI पाइपलाइन में इमेज साइनिंग लागू करें। एक नीति नियंत्रक (Kyverno, Gatekeeper) का उपयोग करके एक एडमिशन नीति बनाएं जो पॉड को बनने की अनुमति देने से पहले इमेज हस्ताक्षरों को सत्यापित करती है।
क्यों: यह सुनिश्चित करता है कि केवल विश्वसनीय CI पाइपलाइन द्वारा बनाई गई इमेज और जिनके साथ छेड़छाड़ नहीं की गई है, वे ही क्लस्टर में चल सकते हैं, जिससे अनधिकृत कोड निष्पादन को रोका जा सकता है।
क्लस्टर के भीतर सभी सेवा-से-सेवा संचार को शून्य-विश्वास दृष्टिकोण के साथ सुरक्षित करें।
एक सर्विस मेश (जैसे Istio, Linkerd) तैनात करें और सभी इन-मेश ट्रैफ़िक के लिए सख्त म्यूचुअल TLS (mTLS) सक्षम करें।
क्यों: mTLS ट्रांज़िट में एन्क्रिप्शन और क्लाइंट और सर्वर दोनों के लिए मजबूत, क्रिप्टोग्राफ़िक रूप से सत्यापन योग्य पहचान प्रदान करता है, जिससे क्लस्टर के अंदर स्पूफिंग और मैन-इन-द-मिडल हमलों को रोका जा सकता है।
क्लस्टर में चल रहे सभी वर्कलोड के लिए सुरक्षा सर्वोत्तम प्रथाओं को लागू करें।
बिल्ट-इन पॉड सुरक्षा एडमिशन कंट्रोलर सक्षम करें। वर्कलोड के लिए `restricted` प्रोफ़ाइल और प्लेटफ़ॉर्म घटकों के लिए `baseline` लागू करने के लिए नेमस्पेस कॉन्फ़िगर करें।
क्यों: `restricted` प्रोफ़ाइल महत्वपूर्ण सुरक्षा को सख्त करती है (जैसे, गैर-रूट के रूप में चलाएँ, सभी क्षमताओं को छोड़ दें, विशेषाधिकार वृद्धि की अनुमति न दें) और यह एक मूलभूत सुरक्षा उपाय है।
OS स्तर पर चल रहे कंटेनरों के अंदर असामान्य या दुर्भावनापूर्ण व्यवहार का पता लगाएं।
एक रनटाइम सुरक्षा टूल तैनात करें जो eBPF का उपयोग करता है, जैसे Falco या Tetragon। संदिग्ध सिस्टम कॉल, फ़ाइल एक्सेस और प्रक्रिया निष्पादन का पता लगाने के लिए नियम परिभाषित करें।
क्यों: पारंपरिक सुरक्षा उपकरण कंटेनरों के अंदर की गतिविधि के प्रति अंधे होते हैं। eBPF कर्नेल-स्तरीय घटनाओं में गहरी, कम-ओवरहेड दृश्यता प्रदान करता है, जिससे उन खतरों का पता लगाने में मदद मिलती है जिन्हें अन्य उपकरण अनदेखा करते हैं।
एक स्केलेबल और लचीली प्रेक्षणीयता डेटा पाइपलाइन (observability data pipeline) बनाएं।
OpenTelemetry (OTel) कलेक्टर का उपयोग करें। डेटा को बदलने के लिए प्रोसेसर को चेन करें (जैसे, PII हटाने के लिए `attributes` प्रोसेसर, दक्षता के लिए `batch` प्रोसेसर)। OOMs को रोकने के लिए पाइपलाइन में जल्दी `memory_limiter` प्रोसेसर का उपयोग करें।
क्यों: कलेक्टर इंस्ट्रूमेंटेशन को बैकएंड से अलग करता है और टेलीमेट्री डेटा को निर्यात करने से पहले संसाधित करने, फ़िल्टर करने और रूट करने का एक लचीला, विक्रेता-तटस्थ तरीका प्रदान करता है।
जोखिम और ब्लास्ट रेडियस को कम करते हुए उत्पादन में नए एप्लिकेशन संस्करणों को तैनात करें।
Flagger या Argo Rollouts जैसे टूल का उपयोग करके स्वचालित कैनरी डिप्लॉयमेंट लागू करें। प्रमुख मेट्रिक्स (सफलता दर, विलंबता) का स्वचालित रूप से विश्लेषण करते हुए धीरे-धीरे ट्रैफ़िक को नए संस्करण में स्थानांतरित करें। SLO उल्लंघन पर स्वचालित रूप से रोल बैक करें।
क्यों: स्वचालित कैनरी विश्लेषण वास्तविक उत्पादन ट्रैफ़िक के साथ नए संस्करणों को मान्य करता है, जो साधारण रोलिंग अपडेट की तुलना में सुरक्षा की बहुत अधिक डिग्री प्रदान करता है।
एक एप्लिकेशन का नया संस्करण तैनात करें जिसमें तत्काल रोलबैक करने की क्षमता हो।
दो समान उत्पादन वातावरण ("ब्लू" और "ग्रीन") बनाए रखें। नए संस्करण को निष्क्रिय (ग्रीन) वातावरण में तैनात करें। सत्यापन के बाद, सभी ट्रैफ़िक को ग्रीन पर रूट करने के लिए लोड बैलेंसर स्विच करें। तत्काल रोलबैक के लिए ब्लू को निष्क्रिय रखें।
क्यों: यह पैटर्न शून्य-डाउनटाइम डिप्लॉयमेंट और सबसे तेज़ संभव रोलबैक प्रदान करता है, लेकिन आमतौर पर दोगुने बुनियादी ढांचे संसाधनों की आवश्यकता होती है।
Git में प्लेनटेक्स्ट क्रेडेंशियल्स को स्टोर किए बिना एक GitOps वर्कफ़्लो में गुप्त (secrets) को घोषणात्मक रूप से प्रबंधित करें।
एक समर्पित गुप्त ऑपरेटर (secrets operator) का उपयोग करें। या तो कमिट करने से पहले गुप्त (secrets) को एन्क्रिप्ट करें (Bitnami Sealed Secrets, Mozilla SOPS) या बाहरी वॉल्ट (External Secrets Operator) से गुप्त (secrets) को संदर्भित करें।
क्यों: यह संवेदनशील डेटा को Git से बाहर रखता है, जबकि गुप्त (secrets) को एप्लिकेशन कॉन्फ़िगरेशन के साथ घोषणात्मक रूप से प्रबंधित करने की अनुमति देता है, GitOps वर्कफ़्लो को बनाए रखता है।
कई वातावरणों (देव, स्टेजिंग, उत्पादन) में एप्लिकेशन कॉन्फ़िगरेशन को डुप्लिकेट किए बिना प्रबंधित करें।
Kustomize जैसे टूल का उपयोग आधार-और-ओवरले संरचना के साथ करें, या पर्यावरण-विशिष्ट मान फ़ाइलों के साथ Helm का उपयोग करें। लक्ष्य वातावरण के ओवरले/मान फ़ाइल में इमेज टैग या कॉन्फ़िगरेशन को अपडेट करके परिवर्तनों को बढ़ावा दें, आमतौर पर एक पुल अनुरोध के माध्यम से।
क्यों: यह "Don't Repeat Yourself" (DRY) दृष्टिकोण वातावरणों के बीच कॉन्फ़िगरेशन ड्रिफ्ट को रोकता है और अंतरों को स्पष्ट और ऑडिट योग्य बनाता है।
क्लस्टरों के एक बड़े, गतिशील बेड़े में एक ही एप्लिकेशन के डिप्लॉयमेंट को प्रबंधित करें।
क्लस्टर जनरेटर के साथ ArgoCD ApplicationSets का उपयोग करें। जनरेटर लेबल के आधार पर क्लस्टर को गतिशील रूप से खोजता है और प्रत्येक मिलान वाले क्लस्टर के लिए एक एप्लिकेशन संसाधन उत्पन्न करने के लिए एक टेम्पलेट का उपयोग करता है।
क्यों: यह नए क्लस्टर के लिए एप्लिकेशन बूटस्ट्रैपिंग को स्वचालित करता है और बड़े पैमाने पर कॉन्फ़िगरेशन का प्रबंधन करता है, जिससे मैन्युअल रूप से सैकड़ों एप्लिकेशन संसाधन बनाने की आवश्यकता से बचा जाता है।
उपयोगकर्ताओं के लिए नई सुविधाओं की रिलीज़ को नियंत्रित करते हुए उत्पादन में सतत तैनाती (continuous deployment) को सक्षम करें।
एक फीचर फ़्लैगिंग सिस्टम को एकीकृत करें। नए कोड को एक अक्षम फीचर फ्लैग के पीछे उत्पादन में तैनात करें। विशिष्ट उपयोगकर्ता खंडों के लिए फ्लैग को सक्षम करके सुविधा को रिलीज़ करें, तैनाती को रिलीज़ से अलग करें।
क्यों: यह तकनीकी जोखिम (तैनाती) को व्यावसायिक जोखिम (रिलीज़) से अलग करता है, जिससे उच्च-वेग तैनाती, A/B परीक्षण और "किल स्विच" क्षमताएं सक्षम होती हैं।
नए कंटेनर इमेज को जैसे ही वे रजिस्ट्री में धकेले जाते हैं, स्वचालित रूप से तैनात करें।
FluxCD के इमेज ऑटोमेशन घटकों का उपयोग करें। `ImageRepository` रजिस्ट्री को स्कैन करता है, `ImagePolicy` नए टैग का चयन करता है (जैसे, सेमेवर के आधार पर), और `ImageUpdateAutomation` टैग परिवर्तन को Git रिपॉजिटरी में वापस कमिट करता है।
क्यों: यह CI (इमेज पुश) से CD (तैनाती) तक के लूप को पूरी तरह से स्वचालित GitOps वर्कफ़्लो के लिए बंद करता है, जिसमें CI सिस्टम को क्लस्टर तक पहुंच की आवश्यकता नहीं होती है।
प्लेटफ़ॉर्म API और प्रोविज़निंग इंफ्रास्ट्रक्चर
डेवलपर्स को Kubernetes और क्लाउड इंफ्रास्ट्रक्चर संसाधनों (जैसे, डेटाबेस, मैसेज क्यू) दोनों को स्वयं-सेवा प्रदान करने के लिए एक एकीकृत, घोषणात्मक API प्रदान करें।
Crossplane का उपयोग करें। क्लाउड प्रोवाइडर प्लगइन्स स्थापित करें और डेवलपर्स के लिए उच्च-स्तरीय CompositeResourceDefinitions (XRDs) परिभाषित करें (जैसे, `kind: PostgresSQLInstance`)। इन्हें Compositions का उपयोग करके अंतर्निहित क्लाउड संसाधनों पर मैप करें।
क्यों: यह Kubernetes कंट्रोल प्लेन को बाहरी संसाधनों को प्रबंधित करने के लिए विस्तारित करता है, जिससे डेवलपर्स को प्लेटफ़ॉर्म-परिभाषित पैटर्न द्वारा शासित, अपने सभी एप्लिकेशन निर्भरताओं के लिए परिचित `kubectl` और GitOps वर्कफ़्लो का उपयोग करने की अनुमति मिलती है।
Kubernetes-नेटिव तरीके से जटिल, स्टेटफुल एप्लिकेशन लाइफसाइकिल प्रबंधन (जैसे, इंस्टॉलेशन, अपग्रेड, बैकअप, विफलता रिकवरी) को स्वचालित करें।
एक Kubernetes ऑपरेटर बनाएं। अपने एप्लिकेशन के लिए एक Custom Resource Definition (CRD) परिभाषित करें और एक कस्टम कंट्रोलर लागू करें जो एप्लिकेशन की स्थिति को प्रबंधित करने के लिए एक सुलह लूप चलाता है।
क्यों: ऑपरेटर मानव परिचालन ज्ञान को सॉफ्टवेयर में एन्कोड करते हैं, जिससे मजबूत स्वचालन सक्षम होता है और जटिल अनुप्रयोगों को प्रथम-श्रेणी Kubernetes संसाधनों के रूप में माना जाता है।
सुनिश्चित करें कि एक ऑपरेटर Kubernetes से अपने संबद्ध Custom Resource को हटाने से पहले बाहरी संसाधनों (जैसे, एक क्लाउड लोड बैलेंसर) की सफाई कर सके।
Custom Resource मेटाडेटा में एक फाइनलइज़र जोड़ें। जब कोई उपयोगकर्ता CR को हटाता है, तो यह `Terminating` स्थिति में प्रवेश करता है। ऑपरेटर का सुलह तर्क इसे पहचानता है, सफाई करता है, और फिर फाइनलइज़र को हटा देता है, जिससे K8s API सर्वर को विलोपन पूरा करने की अनुमति मिलती है।
क्यों: फाइनलइज़र के बिना, ऑपरेटर को बाहरी संसाधनों को साफ करने का समय मिलने से पहले CR को हटाया जा सकता है, जिससे अनाथ, महंगे बुनियादी ढांचे का निर्माण हो सकता है।
घोषणात्मक, GitOps-अनुकूल टूलिंग का उपयोग करके Kubernetes क्लस्टरों के एक बेड़े के जीवनचक्र का प्रबंधन करें।
Cluster API (CAPI) का उपयोग करें। एक प्रबंधन क्लस्टर CAPI नियंत्रक चलाता है जो विभिन्न क्लाउड प्रदाताओं में वर्कलोड क्लस्टर को प्रोविज़न और कॉन्फ़िगर करने के लिए `Cluster` और `Machine` संसाधनों का सुलह करता है।
क्यों: CAPI क्लस्टर प्रबंधन को एक घोषणात्मक Kubernetes वर्कफ़्लो में बदल देता है, जिससे पूरे क्लस्टर के सुसंगत, स्वचालित और संस्करण-नियंत्रित प्रोविज़निंग और अपग्रेड सक्षम होते हैं।
मौजूदा उपयोगकर्ताओं को तोड़े बिना या "बिग बैंग" माइग्रेशन की आवश्यकता के बिना प्लेटफ़ॉर्म API (CRDs के रूप में परिभाषित) को विकसित करें।
CRD परिभाषा में कई संस्करणों (जैसे, v1beta1, v1) का समर्थन करें। संस्करणों के बीच अनुवाद करने के लिए एक रूपांतरण वेबहुक लागू करें, जिससे नए क्लाइंट v1 का उपयोग कर सकें जबकि पुराने क्लाइंट उसी संग्रहीत ऑब्जेक्ट के विरुद्ध v1beta1 का उपयोग करना जारी रखें।
क्यों: रूपांतरण वेबहुक गैर-विघटनकारी API विकास को सक्षम करने के लिए मूल Kubernetes तंत्र हैं, जो एक स्थिर प्लेटफ़ॉर्म उत्पाद के लिए महत्वपूर्ण है।
IDP और डेवलपर अनुभव
उपकरणों, दस्तावेज़ों और सॉफ्टवेयर परिसंपत्तियों को केंद्रीकृत करके डेवलपर के संज्ञानात्मक भार को कम करें और खोज योग्यता में सुधार करें।
CNCF Backstage जैसे एक फ्रेमवर्क का उपयोग करके एक आंतरिक डेवलपर पोर्टल (IDP) लागू करें। इसके सॉफ्टवेयर कैटलॉग को पॉपुलेट करें, नई सेवाओं के लिए स्कैफोल्डिंग के लिए सॉफ्टवेयर टेम्पलेट प्रदान करें, और "docs-as-code" के लिए TechDocs को एकीकृत करें।
क्यों: एक IDP डेवलपर्स के लिए एक "सिंगल पेन ऑफ़ ग्लास" के रूप में कार्य करता है, जो प्लेटफ़ॉर्म की जटिलता को अमूर्त करने और ऑनबोर्डिंग और विकास में तेजी लाने वाली गोल्डन पाथ और स्व-सेवा क्षमताएं प्रदान करता है।
संगठन में सभी सॉफ़्टवेयर की एक एकल, विश्वसनीय सूची प्रदान करें, जिसमें स्वामित्व, निर्भरता और परिचालन स्थिति शामिल हो।
Git रिपॉजिटरी में `catalog-info.yaml` फ़ाइलों के माध्यम से पॉपुलेटेड एक सॉफ्टवेयर कैटलॉग (जैसे, Backstage सॉफ्टवेयर कैटलॉग) लागू करें। यह सेवाओं, पुस्तकालयों, API आदि का एक केंद्रीय, खोज योग्य रजिस्ट्री बनाता है।
क्यों: एक कैटलॉग खोज योग्यता ("कौन सी सेवाएं मौजूद हैं?") और स्वामित्व ("इस सेवा के बारे में मैं किससे बात करूँ?") की समस्या को हल करता है, जो माइक्रोसेवा आर्किटेक्चर को स्केल करने के लिए महत्वपूर्ण है।
डेवलपर्स को कुछ ही मिनटों में संगठनात्मक मानकों का पालन करने वाली नई, उत्पादन-तैयार सेवाएं बनाने में सक्षम करें।
Backstage सॉफ्टवेयर टेम्पलेट जैसे स्कैफोल्डिंग टूल का उपयोग करें। ऐसे टेम्पलेट परिभाषित करें जो मानक प्रोजेक्ट संरचना, CI/CD पाइपलाइन कॉन्फ़िगरेशन, प्रेक्षणीयता डैशबोर्ड (observability dashboards), और `catalog-info.yaml` के साथ एक नई Git रेपो उत्पन्न करते हैं।
क्यों: टेम्पलेट सर्वोत्तम प्रथाओं को कोडिफ़ाई करते हैं और डेवलपर्स के लिए एक "पक्की सड़क" प्रदान करते हैं, पहले कमिट तक के समय को नाटकीय रूप से कम करते हैं और यह सुनिश्चित करते हैं कि नई सेवाएं सुरक्षा, प्रेक्षणीयता (observability) और अनुपालन के साथ बनाई गई हैं।
सुनिश्चित करें कि तकनीकी दस्तावेज़ अद्यतित, संस्करणित और उस सॉफ़्टवेयर के साथ सह-स्थित हैं जिसका वह वर्णन करता है।
एक "docs-as-code" दृष्टिकोण अपनाएं। सेवा के Git रिपॉजिटरी के भीतर Markdown फ़ाइलों में दस्तावेज़ स्टोर करें। IDP में इस दस्तावेज़ को स्वचालित रूप से बनाने और प्रस्तुत करने के लिए Backstage TechDocs जैसे टूल का उपयोग करें।
क्यों: यह मॉडल दस्तावेज़ को कोड की तरह मानता है-इसे पुल अनुरोधों में समीक्षा की जा सकती है और इसे वर्णित सुविधा के साथ संस्करणित किया जाता है, जिससे बासी या पुराने दस्तावेज़ों को रोका जा सकता है।
अपने प्लेटफ़ॉर्म को मापना
प्लेटफ़ॉर्म की प्रभावशीलता और सॉफ्टवेयर डिलीवरी प्रदर्शन पर इसके प्रभाव को मापें।
चार DORA मेट्रिक्स को ट्रैक करें: डिप्लॉयमेंट फ्रीक्वेंसी (वेग), लीड टाइम फॉर चेंज (वेग), चेंज फेलियर रेट (स्थिरता), और टाइम टू रिस्टोर सर्विस (MTTR, स्थिरता)।
क्यों: DORA मेट्रिक्स उद्योग-मानक, परिणाम-उन्मुख माप हैं जो संगठनात्मक प्रदर्शन से सहसंबंधित होने के लिए सिद्ध हुए हैं। वे गति और स्थिरता दोनों का संतुलित दृष्टिकोण प्रदान करते हैं।
एक साझा Kubernetes प्लेटफ़ॉर्म का उपयोग करने वाली टीमों को सटीक, बारीक लागत दृश्यता प्रदान करें।
OpenCost या Kubecost जैसे FinOps टूल को तैनात करें। समय के साथ उनके वास्तविक संसाधन खपत के आधार पर वर्कलोड को लागत दें। साझा क्लस्टर लागत (जैसे, सिस्टम घटक, नोड ओवरहेड) को आनुपातिक रूप से आवंटित करें।
क्यों: सटीक चार्जबैक/शोबैक जवाबदेही को बढ़ावा देता है और टीमों को संसाधन उपयोग को अनुकूलित करने के लिए प्रोत्साहित करता है। इसके बिना, साझा प्लेटफ़ॉर्म लागत अपारदर्शी और प्रबंधित करने में मुश्किल होती है।
मापें कि क्या प्लेटफ़ॉर्म वास्तव में मूल्य प्रदान कर रहा है और विकास टीमों द्वारा उपयोग किया जा रहा है।
प्रमुख प्लेटफ़ॉर्म सुविधाओं, विशेष रूप से गोल्डन पाथ टेम्पलेट्स और साझा CI/CD पाइपलाइन के अपनाने की दर को ट्रैक करें। डेवलपर संतुष्टि सर्वेक्षण (NPS-शैली) के साथ पूरक करें।
क्यों: वैकल्पिक, राय वाले प्लेटफ़ॉर्म सुविधाओं का उच्च अपनाना एक मजबूत संकेत है कि प्लेटफ़ॉर्म वास्तविक समस्याओं को हल कर रहा है। कम अपनाना डेवलपर की जरूरतों के साथ बेमेल को इंगित करता है।
प्लेटफ़ॉर्म की वर्तमान स्थिति का आकलन करें और सुधार के लिए एक रोडमैप बनाएं।
कई आयामों में क्षमताओं का मूल्यांकन करने के लिए एक प्लेटफ़ॉर्म मैच्योरिटी मॉडल का उपयोग करें: जैसे, स्व-सेवा, प्रेक्षणीयता (Observability), सुरक्षा, विश्वसनीयता और शासन। ऐड-हॉक/मैनुअल से लेकर पूरी तरह से स्वचालित और अनुकूलित तक के स्तरों को परिभाषित करें।
क्यों: एक मैच्योरिटी मॉडल आत्म-मूल्यांकन के लिए एक संरचित ढांचा प्रदान करता है, कमजोरियों की पहचान करने में मदद करता है, और प्लेटफ़ॉर्म के विकास के लिए एक रणनीतिक दृष्टि पर टीम को संरेखित करता है।