GH GambleHub

रखरखाव विंडो

1) "रखरखाव खिड़की" क्या है और इसकी आवश्यकता क्यों है

रखरखाव विंडो - गतिविधियों के लिए पूर्व-सहमत समय सीमा जो संभावित रूप से उपलब्धता/प्रदर्शन को प्रभावित करती है। लक्ष्य अनुमानित जोखिम, पारदर्शी संचार और साक्ष्य-आधारित रिपोर्टिंग के सा

प्रकार:
  • नियोजित: रिलीज, माइग्रेशन, सर्टिफिकेट/कुंजी रोटेशन, डेटाबेस/ब्रोकर अपग्रेड।
  • आपातकाल: तत्काल सुरक्षा सुधार/घटना रोलबैक।
  • साइलेंट/जीरो-इफेक्ट: कोई उपयोगकर्ता प्रभाव (छिपी हुई कैनरी, प्रतिकृतियां, समानांतर इनपुट)।
  • प्रदाता-नेतृत्व: बाहरी प्रदाताओं की खिड़कियां (PSP/KYC/CDN/Cloud)।

2) सिद्धांत

एसएलओ-पहला: खिड़की के समय/प्रारूप पर निर्णय एसएलआई और त्रुटि बजट पर प्रभाव के अनुसार किया जाता है।

न्यूनतम विस्फोटक त्रिज्या: कैनरी स्टेपवाइज - पूर्ण समावेश।

प्रतिवर्ती: प्रत्येक ऑपरेशन में एक बैकआउट योजना और एक सिद्ध रोलबैक है।

सत्य का एकल स्रोत: विंडो पंचांग + टिकट/पूर्ण डाटा पैकेज के साथ आरएफसी।

साक्ष्य: साक्ष्य संग्रह (लॉग, रेखांकन, स्क्रीनशॉट, कलाकृतियाँ हैश)।

एसएलए संचार: पहले से, काम के दौरान, पूरा होने पर।

3) योजना: समय और कवरेज

विंडो चयन: कम यातायात, प्रमुख सहकर्मियों के लिए न्यूनतम प्रभाव (क्षेत्र/वीआईपी/भागीदार)।

समय क्षेत्र: UTC + स्थानीय समय में रिकॉर्ड (उदाहरण के लिए, यूरोप/कीव)।

ब्लैकआउट अवधि: पीक सीज़न/इवेंट्स (मैच, बिक्री, रिलीज़ "डेथ की खिड़कियां") के दौरान काम पर प्रतिबंध।

विस्फोट त्रिज्या: स्पष्ट रूप से परिभाषित करें कि कौन प्रभावित होगा (सेवाएं, क्षेत्र, प

4) बातचीत प्रक्रिया (RFC/CAB लाइट)

1. प्रवर्तक जोखिम विश्लेषण और योजना के साथ एक टिकट/आरएफसी बनाता है (नीचे टेम्पलेट देखें)।

2. जोखिम मूल्यांकन (कम/मेड/उच्च) और सेवा के मालिक द्वारा अनुमोदन + एसआरई/सुरक्षा।

3. कैलेंडर: स्लॉट बुकिंग; विरोध जाँच (अन्य विंडो/प्रदाता)

4. कॉम प्लान: पूर्व-सहमत सूचनाएं और स्थिति पृष्ठ।

5. उच्च जोखिम वाले परिवर्तनों के लिए गो/नो-गो-मीटिंग (24-48 घंटे में)।

5) तैयारी: सुरक्षा द्वार

प्री-लॉन्च चेक: सफल चरण परीक्षण, कलाकृतियों पर हस्ताक्षर, कुल जोखिम - स्वीकार्य।

कैनरी: cohort/क्षेत्र द्वारा 1%→5%→25%; स्वचालित एसएलओ-माली और ऑटो-रोलबैक।

गिरावट के झंडे और सीमाएं तैयार हैं।

सैंडबॉक्स में जांच की गई रोलबैक/बैकआउट योजना; रोलबैक कमांड प्रलेखित हैं।

अलर्ट का दमन: केवल अपेक्षित शोर के लिए, एसएलओ संकेतों को मफल नहीं किया जाता है।

एक्सेस: JIT/JEA ऑपरेशन, अनिवार्य ऑडिट के लिए खाते हैं।

6) संचार (समय और सामग्री)

T-14/7/2 दिन (नियोजित): ग्राहकों/आंतरिक टीमों (क्या/जब/प्रभाव/संपर्क) के लिए हेड-अप।

T-60/30/15 मिनट: स्थिति पृष्ठ के अंदर और पर अनुस्मारक।

काम के दौरान: टेम्पलेट के अनुसार हर 15-30 मिनट (एसईवी-निर्भर) को अपडेट करता है: इम्पैक्ट → स्टेज → नेक्स्ट अपडेट।

के बाद: अंतिम "पूरा/आंशिक रूप से पूरा/रोल्ड बैक", परिवर्तनों की सूची, एसएलओ जांच।

7) कार्यों का प्रदर्शन (संदर्भ परिदृश्य)

1. फ्रीज असंबंधित रिलीज।

2. कैनरी (प्रतिबंधित cohort) के लिए संक्रमण metrics का निरीक्षण करें।

3. हरे रंग के माली के साथ शेयर में स्टेपवाइज वृद्धि।

4. व्यवसाय एसएलआई का सत्यापन (रूपांतरण, भुगतान की सफलता/पंजीकरण)।

5. सूची कार्यक्षमता सत्यापन (खुश पथ + महत्वपूर्ण परिदृश्य) की जाँच करें।

6. रिलीज/नो-रिलीज समाधान (आईसी/एसआरई/सेवा स्वामी)।

7. दमन को हटाना, सतर्क नीतियों की वापसी।

8) विंडो के बाद: सत्यापन और रिपोर्टिंग

अवलोकन विंडो (उदाहरण के लिए, 1-24 घंटे): एसएलओ और त्रुटियों पर नज़र रखना।

विंडो रिपोर्ट: क्या किया गया था, मैट्रिक्स, विचलन, सबूत, कुल।

यदि समस्याएं थीं: AAR→RCA→CAPA (नियम, परीक्षण, प्रलेखन को ठीक करें)।

पुरालेख: टिकट, कलाकृतियाँ, हस्ताक्षर, चेकसम।

9) बाहरी प्रदाताओं के साथ समन्वय

पुष्टि किए गए स्लॉट और प्रदाता संपर्क; उनकी स्थिति प्रणाली में विंडो

कार्य की अवधि के लिए वैकल्पिक प्रदाता को फोलबैक/रूटिंग।

एक प्रदाता (चैट/ब्रिज) और एसएलए अपडेट के साथ एक एकल युद्ध-कक्ष।

10) प्रक्रिया परिपक्वता मेट्रिक्स

ऑन-टाइम दर: % विंडो समय पर शुरू/पूरी हुई।

विफलता दर बदलें: एसएलओ पर रोलबैक/प्रभाव के साथ विंडो का%।

हादसा-दौरान-मेगावाट: खिड़की के दौरान हुई घटनाएं।

संचार एसएलए: समय पर अपडेट का हिस्सा।

साक्ष्य पूर्णता: पूर्ण साक्ष्य पैकेज के साथ विंडो

ग्राहक प्रभाव: 1 खिड़की के लिए शिकायत/टिकट, प्रवृत्

7/30 दिनों के बाद: एसएलओ स्थिरता और कोई रिलेप्स नहीं।

11) चेकलिस्ट

विंडो से पहले

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

के दौरान

  • समय पर अपडेट; युद्ध-कक्ष सक्रिय है।
  • SLO/पीक त्रुटियों पर गार्डरेल का सम्मान किया जाता है; उल्लंघन के मामले में - ऑटो-रोलबैक।
  • साक्ष्य एकत्र किया जाता है (स्क्रीनशॉट, रेखांकन से पहले/बाद में, एक्शन लॉग)।

के बाद

  • अवलोकन विंडो के दौरान हरे क्षेत्र में एसएलओ।
  • सबूत के साथ अंतिम रिपोर्ट; स्थिति पृष्ठ अद्यतन
  • CAPA जारी किए जाते हैं (यदि विचलन थे); प्रलेखन अद्यतन।

12) साँचा

अनुरक्षण विंडो प्रति RFC टैम्पलेट


RFC: MW-2025-11-05-DB-Upgrade
Window: 2025-11-05 00: 00-02: 00 UTC (Europe/Kyiv 02: 00-04: 00)
Service/component: payments-db (PostgreSQL cluster A)
Type: Planned (High)
Target: Upgrade to 15. x for security/bugs
Blast radius: EU region, tenant EU, all write operations
Impact: up to 2 × p99 growth to 400 ms; short-term read-only (≤5 min)
Gardrails: error-rate <0. 5%, p99 <400 ms, SLO not impaired
План: expand→migrate→contract; canary 1 %/5 %/25%; 1..N steps (with commands)
Backout: rolling back replica/slots; TTL DNS does not change; rollback time ≤ 10 min
Suppression: noise of database/replica alerts; SLO alerts are active
Communications: T-7/T-2 days and T-60/15 minutes; war-room #mw-db-a
Owners: @ db-tl, @ sre-ic, @ payments-pm
Evidence: before/after p95/p99 graphs, migration logs, checksums
Risk: High (data) - confirmed by CAB

क्लाइंट सूचना साँचा (संक्षिप्त)


Topic: Planned work 05. 11. 2025 02:00–04:00 (Europe/Kyiv)
We will update the payment database. Short delays and read-only mode (up to 5 minutes) are possible.
On-call contacts: status. example. com      support@example. com

दमन नियम (विचार)

yaml suppress:
- name: db-maintenance when: window("2025-11-05T00:00Z","2025-11-05T02:00Z")
match: [ "db. replica. lag", "db. connection. reset", "migration. progress" ]
keep: [ "slo. payment. success", "api. availability" ]

13) विनियमित डोमेन के लिए सुविधाएँ

ऑडिट लॉग अपरिवर्तनीय: जिसने अनुमोदित किया, जिसने निष्पादित किया, क्या आदेश, कलाकृतियों के हैश।

पीआईआई/वित्त: साक्ष्य में मास्किंग, रिपोर्ट तक सीमित पहुंच।

ग्राहकों और भागीदारों को अधिसूचना की शर्तें - संविदाओं के अनुसार।

प्रदाता विंडो - बाहरी एसएलए और संपर्कों के साथ प्रलेखित।

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

बिना बैकआउट योजना और सत्यापित रोलबैक के विंडो।

एसएलओ का जैमिंग "सिर्फ मामले में।"

एक ही डोमेन/क्षेत्र में प्रतिस्पर्धा विंडो।

कॉम साइलेंस: अपडेट से पहले/दौरान/बाद में नहीं।

उत्पाद में लेखा परीक्षण और स्क्रिप्ट के बिना मैनुअल संपादन।

अनिश्चित सफलता मानदंडों के कारण "अनंत" खिड़कियां।

सबूतों की कमी - गुणवत्ता की पुष्टि करने के लिए कुछ भी नहीं।

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

1. नेड। 1-Enter एक एकल कैलेंडर और RFC टेम्पलेट ब्लैकआउट अवधि को परिभाषित करता है।

2. नेड। 2: गेट्स (कैनरी, एसएलओ-गार्डरेल्स, बैकआउट) का मानकीकरण करें।

3. नेड। 3: स्वचालित दमन/रिलीज एनोटेशन और स्थिति पृष्ठ।

4. नेड। 4: रिपोर्टिंग और परिपक्वता मैट्रिक्स; साप्ताहिक MW-समीक्षा।

5. नेड। 5-6: प्रदाताओं और ऑडिट संग्रह के साथ एकीकरण; उच्च जोखिम वाली खिड़की सिमुलेशन।

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

उचित रूप से संगठित सेवा विंडो प्रबंधनीय, प्रतिवर्ती और संभवतः सुरक्षित परिवर्तन हैं। एसएलओ-गार्डरेल, कैनरी रैप, सख्त संचार और सबूतों के एक पूर्ण सेट के साथ, खिड़की उपयोगकर्ताओं और भागीदारों के लिए आश्चर्य के बिना सुधार के एक नियमित तंत्र में "भयानक डाउनटाइम" से बदल जाती है।

Contact

हमसे संपर्क करें

किसी भी प्रश्न या सहायता के लिए हमसे संपर्क करें।हम हमेशा मदद के लिए तैयार हैं!

Telegram
@Gamble_GC
इंटीग्रेशन शुरू करें

Email — अनिवार्य है। Telegram या WhatsApp — वैकल्पिक हैं।

आपका नाम वैकल्पिक
Email वैकल्पिक
विषय वैकल्पिक
संदेश वैकल्पिक
Telegram वैकल्पिक
@
अगर आप Telegram डालते हैं — तो हम Email के साथ-साथ वहीं भी जवाब देंगे।
WhatsApp वैकल्पिक
फॉर्मैट: देश कोड और नंबर (उदा. +91XXXXXXXXXX)।

बटन दबाकर आप अपने डेटा की प्रोसेसिंग के लिए सहमति देते हैं।