AI development के लिए platform engineering
पूरा हुआलोगों और agents को services बनाने, बदलने और चलाने के समर्थित तरीके दें। Platform को रखरखाव किए जाने वाले product की तरह लें।
प्रकाशक Taigaहम कैसे लिखते हैं
अपनी समझ जाँचेंPlatform सुरक्षित project template बनाता है। Applications बदलने पर क्या अब भी जरूरी है?अभ्यास करें
आप क्या सीखेंगे
- समझाएँ कि AI platform के उपयोगकर्ताओं को कैसे बदलता है।
- Controls और exception प्रक्रिया वाला समर्थित workflow तय करें।
- Project template और लगातार maintained platform capability का अंतर समझें।
Prototypes को production तक पहुँचने का रास्ता दें
लोग अलग AI tools से विचार परख सकते हैं, जबकि संगठन production का साझा रास्ता देता है। Platform team इस रास्ते को स्पष्ट, समर्थित और दोहराने योग्य बनाती है।
उपयोगी prototype के लिए उपयोगकर्ता का काम, workflow का उदाहरण, उपलब्ध source code और इच्छित डेटा जुटाएँ। आकलन करें कि code अनुकूलित करना है या सीखी requirements से दोबारा बनाना है। वास्तविक credentials या गोपनीय inputs से पहले application, development tools और runtime को जरूरी controls के अनुसार जाँचें।
Service को आपके infrastructure में चलना हो, तो cloud accounts या networks में समर्थित deployment दें। Identity, secret handling, release प्रमाण, monitoring और recovery शामिल करें। Model data flows अलग जाँचें; runtime पर अधिकार से हर development service नियंत्रित नहीं होती।
Platform को उसके उपयोगकर्ताओं के लिए product मानें
Platform teams को software बनाने और चलाने की समर्थित क्षमताएँ देता है। इनमें identity, environments, delivery pipelines, databases, monitoring और policy checks हो सकते हैं। उपयोगी इकाई पूरा workflow है जो बार-बार आने वाली जरूरत पूरी करे।
CNCF platforms को internal users के अनुसार design की गई क्षमताएँ बताता है, जिनमें समान interfaces और जहाँ उचित हो self-service होता है। Portal ये क्षमताएँ दिखा सकता है, लेकिन अकेला portal platform नहीं है। CNCF Platforms White Paper।
वास्तविक माँग से शुरू करें। काल्पनिक कंपनी में कई teams को employee sign-in और managed database वाली internal web service चाहिए। कम इस्तेमाल होने वाले features का बड़ा catalogue जोड़ने से पहले उस माँग के लिए समर्थित रास्ता बनाएँ।
Platform के उपयोगकर्ताओं में agents शामिल करें
AI agent जल्दी infrastructure code बना सकता है। वर्तमान platform context के बिना वह unsupported region, identity pattern या deployment method भी चुन सकता है। तेज generation से संगठन की छूटी सीमाएँ पूरी नहीं होतीं।
Agent को भरोसेमंद interface दें। Inputs, स्वीकार्य values, outputs और failure का व्यवहार तय करें। Installed version से मेल खाते उदाहरण दें। Secrets उजागर किए बिना कार्रवाई करने में मदद करने वाले errors लौटाएँ। Human और agent callers पर समान authorization checks लागू करें।
Internal service की request में जिम्मेदार व्यक्ति, data category, environment, recovery requirement और supported runtime हो सकते हैं। Platform इसके बाद reviewed configuration चुन सकता है या बता सकता है कि request के लिए अलग निर्णय क्यों चाहिए।
समर्थित रास्ता और उसकी सीमाएँ तय करें
| क्षमता | Platform की जिम्मेदारी | Product की जिम्मेदारी |
|---|---|---|
| Employee identity | समर्थित integration और identity lifecycle | Application roles और business authorization |
| Database service | Provisioning interface और तय service operation | Data model, query का व्यवहार और स्वीकार्य डेटा |
| Delivery pipeline | सुरक्षित execution और artifact handling | संबंधित tests और बदलाव की स्वीकृति |
| Monitoring | डेटा जुटाने और alerts की क्षमता | Service targets और कार्रवाई योग्य response |
यह बँटवारे का उदाहरण है। वास्तविक teams और providers से पुष्टि करें। Platform होने से ऐसी जिम्मेदारी गायब नहीं होती जिसका नाम नहीं दिया गया।
Default से बाहर की requirements के लिए exception प्रक्रिया प्रकाशित करें। निर्णय का जिम्मेदार व्यक्ति और जरूरी प्रमाण तय करें। कठिन exception प्रक्रिया teams को platform के बाहर unsupported systems बनाने की ओर ले जा सकती है।
बनने के बाद services का रखरखाव करें
Template शुरुआती version है। उससे बनी applications में वह अपने आप patch नहीं लगाता। तय करें कि platform के बदलाव मौजूदा services तक कैसे पहुँचेंगे और compatibility कैसे जाँची जाएगी।
Shared interfaces और modules का version रखें। हटाने की शर्तें बताएँ। जहाँ जरूरी हो, समर्थित migration दें। Security correction चाहिए हो तो track करें कि कौन-सी services प्रभावित versions पर हैं।
Platform team को हर नियमित operation की manual approval queue न बनाएँ। दोहराई जा सकने वाली checks automate करें और अनसुलझे असर वाले निर्णय लोगों के लिए रखें। सफल उपयोग, waiting time, recovery परिणाम और रखरखाव का प्रयास मापें।
Platform को software factory से जोड़ें
Platform engineering समर्थित क्षमताएँ और संचालन की सीमाएँ तय करती है। Software factory requirements, planning, implementation, प्रमाण और delivery जोड़ती है। Factory वास्तविक platform के अनुसार योजना बनाए तो दोनों एक-दूसरे की मदद कर सकते हैं।
Evaluation में लगातार संचालन शामिल करें। जाँचें कि नई vulnerabilities कौन scan करता है, corrections कौन deploy करता है, incidents का जवाब कौन देता है और compliance प्रमाण कौन बनाए रखता है। इन क्षमताओं का सहमत दायरा और जिम्मेदार लोग चाहिए; “software factory” शब्द इनकी गारंटी नहीं देता।
Integration को ठोस बिंदु पर जाँचें: क्या generated change मौजूदा deployment path इस्तेमाल करके उसके controls बनाए रख सकता है? क्या team जाँच सकती है कि exception क्यों चाहिए था? Platform बदलने पर shared context कौन update करता है?
DORA की research AI की क्षमता को उसके आसपास के संगठन के संदर्भ में देखती है। पूरे workflow का आकलन करने में यह दृष्टि अपनाएँ, जिसमें platform team के पास बचा काम भी शामिल हो। DORA 2025 report।
अभ्यास करें
Internal web service के लिए एक platform capability design करें। Inputs, outputs, स्वीकार्य identities, checks, failure response और जिम्मेदार व्यक्ति तय करें। मौजूदा services का upgrade path और default से पूरी न होने वाली requirement के लिए exception प्रक्रिया जोड़ें।
Worksheet डाउनलोड करें (Markdown)यह चयन हटाने से इस browser में सहेजी गई पूरी प्रगति मिट जाती है।
प्रगति इसी browser में रहती है। कोई account या tracking नहीं।