एकसमान शब्दावली
शब्दावली
इस मार्गदर्शिका के terms की छोटी व्याख्याएँ। हर term से संबंधित पाठ का link मिलता है।
शब्द: 46
- खुद बनाना या खरीदनाBuild vs buy
किन क्षमताओं को आंतरिक रूप से बनाना है और किन्हें suppliers से लेना है, इसका निर्णय। लागत के साथ जिम्मेदारियों की भी तुलना करें।
पाठ पढ़ें →- प्रमाणEvidence
जाँचा जा सकने वाला record जो किसी दावे का समर्थन करे। उदाहरणों में test results, configuration, approvals और release identifiers शामिल हैं।
पाठ पढ़ें →- मूल्यांकनEvaluation
प्रतिनिधि tasks और स्वीकृति मानदंडों के आधार पर किसी model या workflow को परखने की तय विधि।
पाठ पढ़ें →- स्वायत्तताAutonomy
उन कार्रवाइयों का दायरा जो system किसी नए मानवीय निर्णय के बिना कर सकता है। कार्रवाई और परिणाम के आधार पर सीमाएँ तय करें।
पाठ पढ़ें →- स्वीकृति मानदंडAcceptance criteria
वे शर्तें जिन्हें किसी बदलाव को पूरा करना चाहिए। Implementation से पहले इन्हें तय करें, ताकि reviewer परिणाम का आकलन कर सके।
पाठ पढ़ें →- Agent
ऐसा system जो किसी लक्ष्य के लिए कार्रवाई करने में model और tools का उपयोग करता है। उसकी permissions तय करती हैं कि वह कौन-सी कार्रवाइयाँ कर सकता है।
पाठ पढ़ें →- AI software factory
संचालन का ऐसा मॉडल जो पूरे lifecycle में AI-सहायता वाले software कार्य को जोड़ता है। Code generation के अलावा उसकी जिम्मेदारियों, controls और प्रमाणों का आकलन करें।
पाठ पढ़ें →- Authentication
किसी पहचान का सत्यापन। केवल authentication से किसी record को खोलने या कोई कार्रवाई करने की permission नहीं मिलती।
पाठ पढ़ें →- CI/CD
Continuous integration और continuous delivery या deployment। तय policies के अनुसार automated workflows software build करते हैं, जाँचते हैं और तैयार या release करते हैं।
पाठ पढ़ें →- Cloud native
बदलते environments में development और operations को दोहराने योग्य बनाने के तरीके। Container packaging के अलावा automation, state, resilience और observability का आकलन करें।
पाठ पढ़ें →- Code review
प्रस्तावित code बदलाव की जाँच। स्वीकृति से पहले reviewer व्यवहार, दायरा, जोखिम और संबंधित प्रमाण जाँचता है।
पाठ पढ़ें →- Context (संदर्भ)Context
मौजूदा कार्य के लिए model को उपलब्ध जानकारी। इसमें instructions, files, conversation और tools के परिणाम शामिल हो सकते हैं।
पाठ पढ़ें →- Data की सीमाData boundary
Data कहाँ जा सकता है, किसे उसका access मिल सकता है और किन उद्देश्यों की अनुमति है, इसकी तय सीमा।
पाठ पढ़ें →- Deployment
Software के किसी version को एक environment में स्थापित करना। Deployment और users के लिए release अलग निर्णय हो सकते हैं।
पाठ पढ़ें →- Diff
ऐसी तुलना जो versions के बीच बदलाव दिखाती है। Configuration और dependencies के बदलावों सहित वास्तविक diff की समीक्षा करें।
पाठ पढ़ें →- Disaster recovery (DR)
किसी बाधा डालने वाली घटना के बाद उपयोगी service और recover किए जा सकने वाले data को वापस लाना। Plan में dependencies, निर्णय और जाँची गई प्रक्रियाएँ शामिल होती हैं।
पाठ पढ़ें →- DORA research
Software delivery और संगठन के प्रदर्शन पर research। यह research EU के Digital Operational Resilience Act से अलग है।
पाठ पढ़ें →- DPIA
Data protection impact assessment। Processing से लोगों को होने वाले जोखिमों और उन्हें कम करने के उपायों का व्यवस्थित आकलन।
पाठ पढ़ें →- Frontier model
ऐसा model जिसे मौजूदा क्षमताओं की सीमा के करीब बताया जाता है। यह नाम किसी खास कार्य में सही परिणाम की गारंटी नहीं देता।
पाठ पढ़ें →- Governance
काम को दिशा देने और जवाबदेही तय करने के लिए इस्तेमाल होने वाले निर्णय के अधिकार, policies, controls और प्रमाण।
पाठ पढ़ें →- Hallucination
ऐसी generated सामग्री जो गलत या बिना आधार की हो, लेकिन विश्वसनीय दिख सकती हो। महत्वपूर्ण परिणाम वाले दावों को स्वतंत्र प्रमाण से सत्यापित करें।
पाठ पढ़ें →- High availability (HA)
ऐसा design जो तय component failures के बावजूद उपयोगी service जारी रखने में मदद करे। पूरे request path और बची हुई capacity को सत्यापित करें।
पाठ पढ़ें →- Infrastructure as code
Infrastructure resources और configuration की version control में रखी परिभाषाएँ। Review किया गया plan resources में प्रस्तावित बदलाव दिखाता है।
पाठ पढ़ें →- Least privilege
किसी तय कार्य के लिए जितनी permissions जरूरी हों, केवल उतनी दें। जहाँ संभव हो, resources, कार्रवाइयों और अवधि को सीमित करें।
पाठ पढ़ें →- Multi-AZ
एक AWS Region के भीतर कई Availability Zones में deployment। पूरे design के आधार पर यह AZ failure के प्रभाव का जोखिम कम कर सकता है।
पाठ पढ़ें →- Multi-region
कई cloud Regions में deployment। जिस failure scenario के लिए तैयारी चाहिए, उसके लिए routing, data consistency, recovery और संचालन की जिम्मेदारियाँ तय करें।
पाठ पढ़ें →- Observability
Logs, metrics और traces जैसे signals से system के व्यवहार की जाँच करने की क्षमता। उपयोगी signals संचालन से जुड़े किसी खास सवाल का जवाब देने में मदद करते हैं।
पाठ पढ़ें →- Prompt injection
Model से untrusted सामग्री को instructions के रूप में स्वीकार कराने की कोशिश। Tools की permissions संभावित परिणामों को प्रभावित करती हैं।
पाठ पढ़ें →- Pull request
एक branch को दूसरी branch में merge करने का प्रस्ताव। इसमें diff, चर्चा, review और checks के परिणाम एक जगह मिलते हैं।
पाठ पढ़ें →- RAG
Retrieval-augmented generation। System जानकारी खोजकर उसे model को context के रूप में देता है। Retrieval से सामग्री भरोसेमंद नहीं हो जाती।
पाठ पढ़ें →- Regression test
ऐसा test जिसका उद्देश्य किसी ज्ञात defect की वापसी या मौजूदा व्यवहार में अनचाहा बदलाव पहचानना है।
पाठ पढ़ें →- Rollback
Software या configuration का पिछला version वापस लाना। Data compatibility यह सीमित कर सकती है कि rollback सुरक्षित है या नहीं।
पाठ पढ़ें →- RPO
Recovery Point Objective: समय के रूप में मापा गया अधिकतम स्वीकार्य data loss। उपयोग योग्य recovery point की तुलना बाधा आने के समय से करें।
पाठ पढ़ें →- RTO
Recovery Time Objective: उपयोगी service वापस आने से पहले बाधा की अधिकतम स्वीकार्य अवधि। इसमें पहचान, निर्णय, restore और validation शामिल करें।
पाठ पढ़ें →- SBOM
Software bill of materials। Software components की सूची। इससे जाँच में मदद मिलती है, लेकिन यह vulnerabilities न होने का प्रमाण नहीं है।
पाठ पढ़ें →- SCA
Software composition analysis। पहचानी गई software dependencies का विश्लेषण, अक्सर ज्ञात vulnerabilities की जानकारी के आधार पर। Coverage tools और scan किए गए inputs पर निर्भर है।
पाठ पढ़ें →- SDLC
Software development lifecycle। Software को परिभाषित करने, बनाने, release करने, चलाने, बदलने और सेवा से हटाने के लिए जरूरी गतिविधियाँ।
पाठ पढ़ें →- Self-healing
स्वीकृत कार्रवाइयों, सत्यापन और रुकने की शर्तों से किसी तय failure के बाद अपने-आप recovery करना। इससे मूल software defect हमेशा ठीक नहीं होता।
पाठ पढ़ें →- Self-improvement
Feedback के आधार पर system बदलना और बेहतर परिणाम सत्यापित करना। स्पष्ट करें कि code, configuration, instructions, workflow या model parameters में से क्या बदलता है।
पाठ पढ़ें →- SIRT / CSIRT
Security incident response team। यह तय अधिकार और संगठन की जिम्मेदारियों के भीतर incident की जाँच और response का समन्वय करती है।
पाठ पढ़ें →- SLO
Service level objective। किसी तय अवधि में service के व्यवहार के एक परिभाषित माप के लिए लक्ष्य।
पाठ पढ़ें →- SOC
Security operations center। यह कार्य आम तौर पर security signals की निगरानी, alerts की जाँच और संदिग्ध incidents को आगे भेजने से जुड़ा होता है। इसके वास्तविक दायरे पर सहमति जरूरी है।
पाठ पढ़ें →- Threat model
किसी system या workflow के assets, trust boundaries, threats और controls का व्यवस्थित विवरण।
पाठ पढ़ें →- Traceability
किसी जरूरत को उसके implementation, checks, approval और released version से जोड़ने की क्षमता।
पाठ पढ़ें →- Vibe coding
खोजपरक तरीका जिसमें prompts और दिखाई देने वाले व्यवहार से generated code को दिशा दी जाती है। इसमें अक्सर implementation के हर निर्णय की जाँच नहीं की जाती।
पाठ पढ़ें →
कोई term नहीं मिला। दूसरी वर्तनी आजमाएँ।