संचालन प्लेबुक

1) प्लेबुक क्या है और यह एक रनबुक से कैसे भिन्न है

रनबुक एक विशिष्ट ऑपरेशन/अलर्ट ("एक, दो, तीन") के लिए एक रैखिक चरण-दर-चरण निर्देश है।

प्लेबुक कांटे के साथ परिदृश्यों के लिए एक निर्णय पेड़ है: विभिन्न लक्षण - विभिन्न परिकल्पनाएं - क्रियाओं की विभिन्न शाखाएं। चयन मानदंड, गेट की स्थिति और फॉलबैक शाखाएं शामिल हैं।

प्लेबुक का उद्देश्य एमटीटीए/एमटीटीआर को कम करना और अनिश्चितता के तहत आशुरचना के स्तर को कम करना है।

2) जहां पहले प्लेबुक की जरूरत होती है

घटनाएं: एसएलओ ड्रॉप (उपलब्धता/विलंबता/सफलता), व्यवसाय एसएलआई विफलता (भुगतान की रूपांतरण/सफलता)।

परिवर्तन: रिलीज, माइग्रेशन, फ्लैग, कॉन्फ्रेंस (कैनरी/रोलबैक)।

रखरखाव विंडो: डेटाबेस/ब्रोकर उन्नयन, प्रमाणपत्र घूर्णन।

प्रदाता: PSP/KYC/CDN/IDP - गिरावट और स्विंग ओवर।

सुरक्षा: समझौता कुंजी, संदिग्ध गतिविधि।

DataOps: देरी से ताजगी, सर्किट का बहाव, पाइपलाइन का क्षरण।

3) प्लेबुक मानक (न्यूनतम संरचना)

1. कार्ड: आईडी, संस्करण/तिथि, मालिक (टीम/भूमिका), सेवाएं/क्षेत्र/किरायेदार, संबंधित नीतियां/मानक।

2. उद्देश्य और प्रक्षेपण की स्थिति: जो एसएलओ/एसएलआई हम रक्षा करते हैं, जो अलर्ट/ट्रिगर लागू होते हैं।

3. लक्षण - परिकल्पना: पत्राचार तालिका, गलत परिकल्पनाओं को जल्दी से कैसे काटें।

4. निर्णय पेड़: कांटे, सुरक्षा द्वार, स्टॉप/जारी मानदंड।

5. क्रियाएँ: कमांड/लिंक के साथ कदम ब्लॉक रनबुक 'और।

6. संचार: अद्यतन टेम्पलेट (Impakt→Diagnostika→Deystviya→Sled। अद्यतन), चैनल और आवृत्तियाँ।

7. रोलबैक/फोलबैक: स्पष्ट बैकआउट योजना, सीमा और यूएक्स गिरावट ध्वज।

8. पूर्णता मानदंड: मैट्रिक्स, अवलोकन समय खिड़कियां।

9. साक्ष्य: क्या बचाना है (लॉग, ग्राफ, स्क्रीनशॉट, टिकट आईडी)।

10. परिवर्तनों का इतिहास: चेंजलॉग, ज्ञात सीमाएं।

4) प्लेबुक टैक्सोनॉमी (उदाहरण कैटलॉग)

INC- घटनाएं (SLO/SLI, प्रदाता, बुनियादी ढांचा)।

REL- रिलीज, रोलबैक, कॉन्फ्रेंस/फ्लैग।

MW- - रखरखाव विंडो (DB/कतार/सर्टिफिकेट/OS)।

SEC- सुरक्षा (पहुँच, कुंजी, संदिग्ध क्रियाएँ)।

DATA- - ताजगी/गुणवत्ता/योजनाएं।

PROV- - बाहरी प्रदाता (PSP/KYC/CDN/ईमेल/SMS)।

5) जीवन चक्र और स्वामित्व

1. दीक्षा: घटना/सिमुलेशन/परिवर्तन पर आधारित।

2. ड्राफ्ट: लेखक = सेवा स्वामी; समीक्षा: SRE/सुरक्षा/डेटा (डोमेन द्वारा)।

3. पायलट: टेबलटॉप/गेम-डे; मार्ग समय और दोषों की रिकॉर्डिंग।

4. प्रकाशन: रेपो (डॉक्स-ए-कोड), संस्करण, टैग, डैशबोर्ड के लिंक में।

5. अद्यतन: आरसीए/सीएपीए के अनुसार, कम से कम एक बार एक तिमाही; एसएलए ताजगी।

6. संग्रह/कमी: प्रासंगिकता के प्रतिस्थापन/हानि के मामले में।

6) उपकरणों के साथ एकीकरण

अलर्ट → Playbook: प्रत्येक पृष्ठ नियम बिल्कुल एक मूल प्लेबुक का संदर्भ देता है।

ChatOps: '/play start 'कार्ड खोलता है, सबूत ठीक करता है, अपडेट टाइमर सेट करता है।

CMDB/कैटलॉग: सेवा में प्रासंगिक प्लेबुक, मालिकों, SLO, डैशबोर्ड की एक सूची है।

GitOps: प्लेबुक और रनबुक गिट में रहते हैं, पीआर समीक्षा और लिंटर्स हैं।

7) प्लेबुक गुणवत्ता मैट्रिक्स

कार्रवाई: ≥ 90% रन अनजाने में आगे बढ़ ने के बिना विशिष्ट क्रियाओं में परिणाम देते हैं।

टाइम-टू-फर्स्ट-एक्शन: पेज से पहले सार्थक चरण में एक या दो मिनट।

कवरेज: % पृष्ठ अलर्ट जिसमें एक बाउंड प्लेबुक (100% लक्ष्य) है।

ताजगी: प्लेबुक का अनुपात 90 दिनों से अधिक ताज़ा है।

दोष दर: 100 प्लेबुक के लिए समीक्षाओं/सिमुलेशन पर टिप्पणी।

पुन: उपयोग: कितनी बार प्लेबुक वास्तव में लागू किया गया है (और इसके किस परिणाम का नेतृत्व किया)।

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

निर्णय पेड़ के बिना 20 पृष्ठों के साथ "प्लेबुक इनसाइक्लोपीडिया"।

परिणाम की अपेक्षाओं के बिना कमांड ("एक्स निष्पादित करें" - क्या बदलना चाहिए?)।

कोई बैकआउट योजना और सीमा नहीं है - समस्या को बढ़ाने का जोखिम।

संचार चैनलों/अंतराल को इंगित नहीं किया गया है - पीआर जोखिमों की वृद्धि।

मालिक/अद्यतन तिथि के बिना प्लेबुक - कोई भी इसकी प्रासंगिकता में विश्वास नहीं करता है।

एक पैरामीटर के बजाय दर्जनों समान प्लेबुक।

9) प्लेबुक मिनी-टेम्पलेट (YAML विचार)

yaml id: INC-PAY-001 name: "Payment Success Down"
version: 2. 4 (2025-10-15)
owner: team-payments@sre scope: [prod, region: eu, tenants: all]
goal: "Restore success_ratio ≥ 98% without violating SLA"
triggers:
- alert: slo. burn. payment_success_ratio
- external_status: psp-a partial outage symptoms:
- "5xx growth in payments-api"
- "p95 latency> 400ms on PSP-A"
decision_tree:
- if: "quorum(eu,us) confirms drop AND PSP-A status=partial"
then:
- action: "Reduce PSP-A weight to 30%"
runbook: rb://payments/traffic-shift guardrails: ["success_ratio improving 10m", "p95<300ms"]
- action: "Enable degrade_payments_ux"
runbook: rb://payments/feature-flags
- action: "Status update (30m) by template"
comms: statuspage://payments else:
- action: "Check database/cache/queue"
runbook: rb://payments/diag-stack fallback:
- action: "Failover на PSP-B 70%"
guardrails: ["fraud_rate stable", "chargeback risk noted"]
rollback:
- condition: "PSP-A green 60m"
- steps:
- "Weight of PSP-A 30→70→80 (every 30 m at green SLI)"
evidence:
- "SLI screenshots, p95/5xx graphs, links to logs/trails"
completion:
- "success_ratio ≥98% during 30 m, no burn in 6 h"

10) तैयार किए गए उदाहरण (टुकड़े)

ए) भुगतान: "प्रदाता एक क्षेत्र में नीचा दिखाता है"

लक्षण: TR cohort की कमी, PSP-A टाइमआउट में वृद्धि हुई।

समाधान: TR के लिए PSP-A के वजन को कम करें, degrade-UX को सक्षम करें, बजट ≤ SLA के साथ रिट्रेस को मजबूत करें, एक क्लाइंट अपडेट तैयार करें।

बैकआउट: 60 मिनट के हरे SLI पर फिर से वजन।

B) DB: "ग्रोथ p99 और कनेक्शन त्रुटियां"

लक्षण: p99↑, कनेक्शन रीसेट त्रुटियों, विकास प्रतीक्षा घटनाओं।

समाधान: केवल पढ़ ने के लिए स्क्रिप्ट सक्षम करें, सीमित लेखन लोड, स्केल पूल/प्रतिकृतियां, यदि आवश्यक हो - गर्म विफलता

बैकआउट: पैरामीटर रोलबैक, प्रतिकृति-प्राइम।

C) कैश: "मिस रेट ↑ → डेटाबेस लोड"

लक्षण: मिस रेट> 40%, सीपीयू डीबी की वृद्धि।

समाधान: बेदखली नीति को संतुलित करें, मेमोरी/शार्डिंग बढ़ाएं, अस्थायी रूप से रीड-थ्रू सक्षम करें, गर्म कुंजी पर आरपीएस को सीमित करें।

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

डी) सीडीएन: "क्षेत्रीय सामग्री गिरावट"

लक्षण: एक देश में विलंबता/समय समाप्ति में वृद्धि, आरयूएम शिकायतें।

समाधान: रूटिंग मैप/जीएसएलबी बदलें, समस्याग्रस्त पीओपी को बायपास करें, टीटीएल को कम करें, मूल-ढाल सक्षम करें।

Comms: प्रभाव के भूगोल के साथ स्थिति अपडेट।

E) KYC: "असफल पहचान"

लक्षण: ड्रॉप अनुमोदन दर, vendor_error वृद्धि।

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

अनुपालन: यदि आवश्यक हो तो सभी परिवर्तनों, जोखिम/कानूनी सूचनाओं का लॉग।

11) संचार (अद्यतन टेम्पलेट)

Impact: EU payment success drop (-3. 1% to SLO, 25 min).
Diagnosis: confirmed by quorum; PSP-A partial outage; p95 = 420ms.
Action: PSP-A weight reduced to 30%, degrade-UX included; next update 18:30 UTC.

12) प्लेबुक लेखक चेकलिस्ट

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

13) चेकलिस्ट की समीक्षा करें

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

14) पैरामेटराइजेशन और पुन: उपयोग

चर (क्षेत्र, प्रदाता, थ्रेसहोल्ड) को 'values में ले जाएं। '.

सामान्य कदम (उदाहरण के लिए, "प्रदाता के वजन को कम करें", "डीग्रेड-यूएक्स को सक्षम करें") को अलग-अलग रनबुक में जारी किया जाना चाहिए।

टेम्पलेट से जनरेटर का समर्थन करें: 'plb नया --type = INC --service = payments'।

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

1. प्रत्येक मूल प्लेबुक के लिए पृष्ठ अलर्ट → नक्शा की एक सूची।

2. साँचा: YAML/मार्कडाउन संरचना, चेकलिस्ट और लिंटर्स को मंजूरी दें।

3. शीर्ष 5 परिदृश्य (भुगतान/डीबी/सीडीएन/केवाईसी/कैश) → टेबलटॉप पर वापस लिखें/रोल करें।

4. एकीकरण: अलर्ट, चैटोप्स कमांड, साक्ष्य-बॉट से लिंक।

5. ड्रिल: एक समय में साप्ताहिक मिनी-ड्रिल एक प्लेबुक; AAR→uluchsheniya।

6. ताजगी एसएलए और त्रैमासिक समीक्षा; गुणवत्ता मेट्रिक्स रिपोर्ट।

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

प्लेबुक कांटे और रेलिंग के साथ परिचालन परिदृश्य हैं जो "क्या करना है?!" निर्णयों के एक अनुमानित अनुक्रम में। जब प्लेबुक को मानकीकृत किया जाता है, अलर्ट के साथ एकीकृत किया जाता है और नियमित रूप से प्रशिक्षित किया जाता है, तो टीम तेजी से जवाब देती है, जोखिमों को नियंत्रित किया जाता है, और व्यवसाय शोषण की स्थिरता और परिपक्वता देख