पथ 04पाठ 3 / 10

AI development के लिए platform engineering

लोगों और agents को services बनाने, बदलने और चलाने के समर्थित तरीके दें। Platform को रखरखाव किए जाने वाले product की तरह लें।

उन्नत12 minसमीक्षा की गई

प्रकाशक हम कैसे लिखते हैं

अपनी समझ जाँचेंPlatform सुरक्षित project template बनाता है। Applications बदलने पर क्या अब भी जरूरी है?अभ्यास करें
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 lifecycleApplication roles और business authorization
Database serviceProvisioning interface और तय service operationData 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)
अपनी समझ जाँचें ↑

सीखना जारी रखें

स्रोत और आगे पढ़ें

Taiga से संबंधित सामग्री पढ़ें

← पिछला पाठ: Software बदलने पर requirements की traceability बनाए रखें