कॉन्फ़िगरेशन संस्करण नियंत्रण

1) क्यों वर्शनिंग कॉन्फ़िगरेशन

कॉन्फ़िगरेशन एक निष्पादन योग्य नीति है: यह रूटिंग, सीमा, फ़ीचर फ़्लैग, एक्सेस, डेटा स्कीमा को परिभाषित करता है। संस्करण नियंत्रण परिवर्तनों को दोहराने योग्य, अवलोकनीय और प्रतिवर्ती बनाता है: एमटीटीआर और परिवर्तन-विफलता दर को कम करता है, "बिक्री में जादू" को समाप्त करता है, सुरक्षा और अनुपालन के लिए ऑडिट देता है।

2) कॉन्फ़िगरेशन टैक्सोनॉमी

बुनियादी ढांचा (IaC): समूह, नेटवर्क, LB, DB, कतारें।

सेवा: एप्लिकेशन पैरामीटर, संसाधन, सीमा, टाइमआउट, रिट्रे।

उत्पाद/व्यावसायिक तर्क: टैरिफ, एबी प्रयोग, सामग्री नियम।

डेटा/डेटाऑप्स: अनुबंध योजनाएं, एसएलए ताजगी, परिवर्तन।

सुरक्षा: नीतियों, भूमिकाओं, कुंजियों/प्रमाणपत्रों तक पहुंच (रहस्य स्वयं रेपो के बाहर हैं)।

अवलोकन: SLI/SLO, अलर्ट, डैशबोर्ड।

नियम: सिस्टम के व्यवहार को प्रभावित करने वाली सब कुछ कॉन्फ़िगरेशन है और इसे वर्शनिंग के तहत रहना चाहिए।

3) सत्याग्रहकारी सिद्धांत

1. GitOps: सत्य का एकमात्र स्रोत भंडार है; पीआर और स्वचालित पाइपलाइनों के माध्यम से परिवर्

2. घोषणात्मक: लक्ष्य स्थिति का विवरण, चरण स्क्रिप्ट नहीं।

3. कलाकृतियों की अपरिपक्वता: कॉन्फिग - अस्पष्ट रूप से भौतिक रूप से स्नैपशॉट।

4. स्कीमा और सत्यापन: JSON/YAML-स्कीमा, सख्त प्रकार की कास्टिंग, आवश्यक क्षेत्र।

5. कोड की तरह वातावरण: 'env' - फ़ोल्डर/ओवरले (dev/stage/prod), अंतर न्यूनतम और स्पष्ट हैं।

6. पहचान और रोलबैक: किसी भी कॉन्फ़िगरेशन रिलीज़ को वापस/रोलबैक करें।

7. ऑडिट और ट्रेसबिलिटी: लेखक, कारण, टिकट/आरएफसी, हस्ताक्षर बदलें।

4) वर्शनिंग रणनीतियाँ

• प्रमुख - असंगत स्कीमा/नीति परिवर्तन।
• माइनर - नए क्षेत्र/नियम, पिछड़ी संगतता।
• PATCH - योजनाओं को बदले बिना मूल्यों को ठीक करता है।
• टैग जारी करता है और नोट जारी करता है: क्या बदल गया है, कैसे वापस रोल करें, चौकियां।
• पिनिंग/लॉक फ़ाइलें: निर्भरता संस्करण ठीक करें (मॉड्यूल, चार्ट)।
• मैट्रिक्स संस्करण: एक्स एप्लिकेशन की कलाकृति वाई कॉन्फिग (सेवा कैटलॉग में मैट्रिक्स) के साथ संगत है।

5) भंडार संगठन

config-repo/
policies/     # общие политики (RBAC, SLO, алерты)
services/
checkout/
schema/    # JSON/YAML схемы конфигов base/     # дефолтные значения overlays/
dev/
stage/
prod/
data-contracts/  # схемы данных, SLA свежести releases/     # теги, changelog, артефакты валидации tools/      # линтеры, генераторы, тесты

शाखा: ट्रंक-आधारित (मुख्य) + लघु सुविधा शाखाएं। विलय - पीआर के माध्यम से केवल अनिवार्य सीआई के साथ।

6) मान्यता और परीक्षण

स्कीमा: प्रत्येक परिवर्तन स्कीमा सत्यापन (आवश्यक, एनम, रेंज) पास करता है।

स्थिर लिंटर्स: प्रारूप, कुंजी, डुप्लिकेट, निषिद्ध क्षेत्र।

संगतता परीक्षण: कॉन्फिग + सेवा/चार्ट संस्करण सैंडबॉक्स में ऊपर जाते हैं।

टेस्ट रन: ड्राई-रन एप्लिकेशन, "व्हाट-इफ" डिफ टारगेट स्थिति।

नीतियां-जैसा-कोड: प्रवेश नियम (रेगो/सीईएल) - कौन बदल सकता है।

7) अनविंड एंड रोल बैक कॉन्फ़िगरेशन

प्रगतिशील वितरण: एसएलओ-माली के साथ कैनरी%।

तैनाती द्वार: कोई सक्रिय SEV-1, अलर्ट हरे रंग के हैं, हस्ताक्षर वैध हैं, रोलबैक तैयार है।

रोलबैक: 'टैग vX वापस करें। Y.Z 'या पिछले स्नैपशॉट पर स्विच करना; रोलबैक कमांड रनबुक में प्रलेखित हैं।

रिलीज एनोटेशन: कॉन्फिग संस्करण को मेट्रिक्स/लॉग में प्रकाशित किया जाता है ताकि घटनाओं के साथ जल्दी सहसंबंध हो सके।

8) गतिशील और दूरस्थ विन्यास

रिमोट कॉन्फिग/फ़ीचर फ्लैग्स: बिना पुनः आरंभ किए पैरामीटर बदलें; सभी झंडे GitOps के अधीन भी हैं।

सीमाएँ: कौन से पैरामीटर गतिशील रूप से बदलने की अनुमति है (श्वेतसूची की सूची)।

कैश और स्थिरता: टीटीएल, संस्करण, परमाणु सेट प्रतिस्थापन (दो-चरण प्रकाशन)।

सुरक्षित रेलिंग: रनटाइम परिवर्तन के लिए सीमा और रेंज, एसएलओ छोड़ ते समय ऑटो-रोलबैक।

9) रहस्य और संवेदनशील डेटा

रेपो में रहस्य कभी न रखें। विन्यास में - केवल लिंक/प्लेसहोल्डर्स।

कॉन्फ़िगरेशन फ़ाइलों का गोपन, यदि आवश्यक हो: गुप्त/कुंजी प्रबंधक के साथ एकीकरण।

रोटेशन और जेआईटी: पहुंच संचालन की अवधि के लिए जारी की जाती है; कार्रवाई का निशान अपरिवर्तनीय है।

फील्ड मास्किंग: सत्यापन पीआईआई/रहस्यों को कॉन्फिग में प्रवेश करने से रोकता है।

10) पर्यावरण प्रबंधन

आधार + ओवरले: dev/stage/prod के बीच अंतर न्यूनतम और पारदर्शी हैं।

कलाकृतियों पर प्रचार: वही स्नैपशॉट जो मंच से गुजरता है, उसे प्रोड में बढ़ावा दिया जाता है।

समय खिड़कियां: ड्यूटी के परिवर्तन के समय कॉन्फ़िग में परिवर्तन नहीं होते हैं; जोखिम-उच्च RFC और रखरखाव विंडो के लिए।

11) बहाव का पता लगाना और उन्मूलन

नियंत्रक लक्ष्य राज्य की तुलना वास्तविक स्थिति से करता है और डिफ की रिपोर्ट कर

बहाव अलर्ट: पृष्ठ केवल महत्वपूर्ण विसंगतियों के लिए; अन्य टिकट हैं।

ऑटो-रिमेडिएशन: संकल्प पर - लक्ष्य राज्य में वापसी।

ऑडिट मैनुअल संपादन: कोई भी "कुबेक्टल संपादित/ssh" → प्रक्रिया घटना और CAPA।

12) कॉन्फ़िगरेशन कैटलॉग और स्वामित्व

सेवा सूची: मालिक, एसएलओ, संबंधित नीतियां, स्कीमा, संस्करण, संगतता।

RACI: कौन प्रदान करता है, कौन समीक्षा करता है, जो अनुमोदित करता है; उच्च जोखिम के लिए सीएबी।

पारदर्शिता: प्रत्येक प्रविष्टि का एक संस्करण इतिहास और पीआर/टिकट/एएआर से लिंक है।

13) परिपक्वता मैट्रिक्स

कवरेज: GitOps के लिए सेवाओं/नीतियों का% (लक्ष्य ≥ 95%)।

लीड टाइम कॉन्फ़िग परिवर्तन: पीआर से प्रोड तक औसत।

परिवर्तन विफलता दर: रोलबैक/घटना के साथ कॉन्फिग रिलीज का अनुपात।

बहाव दर: विसंगतियों/सप्ताह की संख्या और उन्मूलन का समय।

रोलबैक समय: पिछले संस्करण में औसत वसूली।

ऑडिट पूर्णता: पूर्ण साक्ष्य के साथ परिवर्तनों का अनुपात (सत्यापन, शुष्क-रन, समीक्षा)।

14) चेकलिस्ट

कॉन्फ़िगरेशन बदलने से पहले

• एक टिकट/RFC और एक परिवर्तन मालिक है।
• योजनाओं और लिंटर्स को मान्य किया गया है।
• रनबुक में एक रोलबैक योजना और कमांड है।
• गेट: परीक्षण हरा, हस्ताक्षर मान्य, कोई सक्रिय SEV-1।
• उच्च जोखिम के लिए, एक रखरखाव खिड़की सौंपी गई है।

खोलने के दौरान

• कैनरी और एसएलओ-माली सक्रिय हैं।
• रिलीज एनोटेशन प्रकाशित होते हैं।
• चैनल के लिए गूंज संदेश हैं; MW नियमों द्वारा सतर्क शोर।

बाद में

• अवलोकन खिड़की पारित, SLO हरा।
• कुल और सबूत (चार्ट से पहले/बाद में, ड्राई-रन रिपोर्ट) टिकट से जुड़े होते हैं।
• आवश्यकतानुसार अपडेटेड स्कीमैटिक्स/प्रलेखन।

15) मिनी टेम्पलेट्स

15. 1 कॉन्फ़िगरेशन आरेख (YAML-स्कीमा, टुकड़ा)

yaml type: object required: [service, timeouts, retries]
properties:
service: { type: string, pattern: "^[a-z0-9-]+$" }
timeouts:
type: object properties:
connect_ms: { type: integer, minimum: 50, maximum: 5000 }
request_ms: { type: integer, minimum: 100, maximum: 20000 }
retries:
type: object properties:
attempts: { type: integer, minimum: 0, maximum: 10 }
backoff_ms: { type: integer, minimum: 0, maximum: 5000 }

15. 2 बेसिक कॉन्फ़िग + ओवरले प्रोड

yaml services/checkout/base/config.yaml service: checkout timeouts: { connect_ms: 200, request_ms: 1500 }
retries: { attempts: 2, backoff_ms: 200 }
limits:  { rps: 500 }
features:
degrade_search: false psp_a_weight: 80 psp_b_weight: 20

yaml services/checkout/overlays/prod/config.yaml limits:  { rps: 1200 }
features:
psp_a_weight: 70 psp_b_weight: 30

15. 3 प्रवेश नीति (विचार)

yaml allow_change_when:
tests: passed schema_validation: passed active_incidents: none_of [SEV-0, SEV-1]
rollback_plan: present signed_by: ["owner:team-checkout","platform-sre"]

15. 4 कॉन्फ़िग रिलीज़ कार्ड

Release: checkout-config v2.3.1
Scope: prod EU
Changes: psp_b_weight 20→30, request_ms 1500→1300
Risk: Medium (маршрутизация платежей)
Canary: 1%→5%→25% (30/30/30 мин), guardrails: success_ratio, p95
Rollback: tag v2.3.0

16) एंटी-पैटर्न

GitOps ("जल्दी से मुड़") में संपादित करता है।

कॉन्फ़िग भंडार में रहस्य/पीआईआई।

आरेख और स्थैतिक जांच की कमी।

वातावरण का मजबूत विचलन (base≠prod)।

"लाइव" में संस्करणों और इतिहास के बिना झंडे हैं।

सर्वर पर बहाव और मैनुअल संपादन की अनदेखी।

रिलीज नोट्स और रोलबैक प्लान के बिना टैग।

17) कार्यान्वयन रोडमैप (4-6 सप्ताह)

1. नेड। 1: कॉन्फ्रेंस की सूची; अलग कैटलॉग, शीर्ष 10 सेवाओं के लिए योजनाएं।

2. नेड। 2: सीआई में लिंटर/सत्यापन और ड्राई-रन शामिल हैं; बिना ग्रीन चेक के विलय पर प्रतिबंध।

3. नेड। 3: GitOps रोल + कैनरी; टेलीमेट्री में संस्करण एनोटेशन।

4. नेड। 4 - नीति-ए-कोड और रोलबैक पैटर्न दर्ज करें। बहाव के लिए अलर्ट।

5. नेड। 5-6: 90% सेवाओं को कवर; ओवरले के लिए env अंतर को कम करें; परिपक्वता मेट्रिक्स और कॉन्फिग परिवर्तनों की साप्ताहिक समीक्षा जोड़ें।

18) नीचे की रेखा

कॉन्फ़िगरेशन संस्करण नियंत्रण एक सिस्टम है, सिर्फ गिट नहीं। स्कीमैटिक्स और सत्यापन, GitOps और एक्सेस नीतियां, कैनरी और रोलबैक, बहाव का पता लगाना और एक प्रबंधित कलाकृतियों में पूर्ण ऑडिटिंग टर्न कॉन्फिग। परिणाम त्वरित और सुरक्षित परिवर्तन, एसएलओ पूर्वानुमेयता और प्रत्येक रिलीज में टीम का विश्वास है