Prototype से आगे का infrastructure तय करें
पूरा हुआIdentity, networks, डेटा, recovery और संचालन का आकलन करें। Generated deployment को कंपनी की वास्तविक infrastructure requirements से जोड़ें।
प्रकाशक Taigaहम कैसे लिखते हैं
अपनी समझ जाँचेंGenerated application managed database के साथ सही चलता है। कंपनी के गोपनीय उपयोग से पहले कौन-सा कदम अब भी जरूरी है?अभ्यास करें
आप क्या सीखेंगे
- समझाएँ कि container और database अपने आप क्या सिद्ध नहीं करते।
- Cloud, platform, application और delivery systems की जिम्मेदारी पहचानें।
- Prototype में कंपनी का डेटा आने से पहले जरूरी प्रमाण तय करें।
Generated system से शुरू करें
काल्पनिक prototype platform लें। वह web container, managed PostgreSQL database और public URL बनाता है। उदाहरण वाले records से workflow सही चलता है। यह उपयोगी परिणाम है: बड़े implementation में पैसा लगाने से पहले लोग feature का आकलन कर सकते हैं।
अब कंपनी गोपनीय contracts रखना और अपना employee identity provider इस्तेमाल करना चाहती है। जरूरी system बदल गया है। Container का सफल deployment authorization, स्वीकृत डेटा उपयोग, recovery की क्षमता या service की जिम्मेदारी सिद्ध नहीं करता।
अलग development platforms अलग क्षमताएँ देते हैं। वास्तविक service और configuration जाँचें। यह न मानें कि हर prototype tool की सीमाएँ समान हैं या परिचित cloud का नाम कंपनी की policy पूरी करता है।
Production के सात प्रश्न पूछें
| क्षेत्र | प्रश्न | माँगा जाने वाला प्रमाण |
|---|---|---|
| Identity | Sign in, प्रशासन और deployment कौन कर सकता है? | Identity integration, role mapping और offboarding test |
| Network | कौन-सी services और data stores आपस में संचार कर सकते हैं? | Network design और सत्यापित access rules |
| डेटा | हर copy कहाँ process और retain होती है? | Data-flow map, service terms और configuration |
| Secrets | Credentials कैसे दिए और rotate किए जाते हैं? | Secret references, access rules और rotation प्रक्रिया |
| Delivery | Reviewed code release कैसे बनता है? | सुरक्षित pipeline और artifact identity |
| Recovery | क्या restore हो सकता है और किन सीमाओं के भीतर? | Recovery objectives और समय मापा गया restore अभ्यास |
| संचालन | विफलता पर कौन जवाब देता है और रखरखाव का खर्च कौन देता है? | Service का जिम्मेदार व्यक्ति, monitoring, incident प्रक्रिया और budget |
उत्तर मौजूदा enterprise services का उपयोग कर सकते हैं। हर application के लिए नया identity system या monitoring platform बनाना जरूरी नहीं है। स्वीकृत क्षमताओं से जोड़ें और बाकी कमियाँ दर्ज करें।
AWS Well-Architected संचालन, सुरक्षा, reliability, performance, लागत और sustainability को साथ देखता है। इससे याद रहता है कि काम करता deployment architecture के आकलन का केवल एक हिस्सा है। Framework पढ़ें।
Environments की सीमाएँ तय करें
Development, test और production resources पहचानें। तय करें कि कौन-सी identities इन सीमाओं को पार कर सकती हैं। स्वीकृत डेटा उपयोग प्रक्रिया के बिना सुविधाजनक preview environment में production records copy न करें।
Inbound access के साथ outbound connections भी देखें। Private database भी application के जरिए public logging service को डेटा भेज सकता है। Coding agent की model calls एक और flow हैं, जिसका अलग आकलन चाहिए।
दर्ज करें कि cloud account, DNS, certificate, encryption keys और billing संबंध की जिम्मेदारी किसकी है। नौकरी छोड़ रहे कर्मचारी के personal account पर निर्भर project में ownership की समस्या है, भले ही application code उपलब्ध हो।
जिम्मेदारियों का बँटवारा जाँचें
Managed database provider मूल service चला सकता है, जबकि आपका संगठन users, data access, schema changes और retention settings नियंत्रित करता है। सटीक बँटवारा service और contract पर निर्भर है। इसे स्पष्ट रूप से पूछें।
Contract application के लिए काल्पनिक restore अभ्यास करें। वास्तविक recovery time मापें और संभावित data loss पहचानें। परिणाम का business requirement से मिलान करें। “Backups enabled” label वाला checkbox वही प्रमाण नहीं है।
Offboarding भी जाँचें। Identity source से काल्पनिक कर्मचारी हटाएँ और इच्छित access change सत्यापित करें। Design में active sessions, administrator roles और automation identities शामिल करें।
Infrastructure को delivery system से जोड़ें
Infrastructure definitions, environment configuration, pipelines और application code में समन्वित बदलाव चाहिए। Agent को वास्तविक target environment के अनुसार योजना बनानी चाहिए। अन्यथा वह ऐसा deployment बना सकता है जो networking, identity या ownership requirements से टकराए।
यहाँ platform engineering और software factory साथ आते हैं। Platform समर्थित क्षमताएँ और सीमाएँ देता है। Delivery system को उनका उपयोग करना है, प्रमाण देना है और संचालन की जिम्मेदारी स्पष्ट रूप से सौंपनी है। आगे platform engineering पढ़ें।
अभ्यास करें
काल्पनिक tool public web container और managed PostgreSQL database बनाता है। कंपनी employee access और गोपनीय contract records चाहती है। इस पाठ के production संबंधी सात प्रश्न पूरे करें। हर उत्तर को कारण के साथ सत्यापित, अधूरा या लागू नहीं चिह्नित करें। हर कमी पूरी करने वाला व्यक्ति बताएँ।
Worksheet डाउनलोड करें (Markdown)यह चयन हटाने से इस browser में सहेजी गई पूरी प्रगति मिट जाती है।
प्रगति इसी browser में रहती है। कोई account या tracking नहीं।