Playbooks ოპერაციები

1) რა არის playbook და რით განსხვავდება იგი runbook- ისგან

Runbook არის ხაზოვანი ეტაპობრივი ინსტრუქცია ტიპიური ოპერაციისთვის/ალერტისთვის („გააკეთე ერთხელ, ორი, სამი“).
პლეიბუკი არის ჩანგლის სკრიპტების გამოსავალი: სხვადასხვა სიმპტომები, სხვადასხვა ჰიპოთეზა და მოქმედების სხვადასხვა ფილიალი. მოიცავს არჩევანის კრიტერიუმებს, კარიბჭის პირობებს და fallback ფილიალებს.
პლეიბუკის დანიშნულებაა შეამციროს MTTA/MTTR და იმპროვიზაციის დონე გაურკვევლობით.

2) სადაც პირველ რიგში საჭიროა პლეიბუსები

ინციდენტები: SLO- ს ვარდნა (ავიაკომპანიის/ლატარიის/success), ბიზნეს SLI- ს წარუმატებლობა (გადახდის კონვერტაცია/წარმატება).
ცვლილებები: გამოშვებები, მიგრაცია, ფიგურის დროშები, კონფიგურაცია.
მომსახურების ფანჯრები: BD/ბროკერების განახლება, სერთიფიკატების როტაცია.
პროვაიდერები: PSP/KYC/CDN/IDP - დეგრადაცია და სასტვენის ოვერი.
უსაფრთხოება: კომპრომისული გასაღები, საეჭვო საქმიანობა.
DataOps: შეფერხება სიახლის, სქემის დრიფტის, დიაპაზონის დეგრადაცია.

3) პლეიბუკის სტანდარტები (მინიმალური შემადგენლობა)

1. ბარათი: იდენტიფიკატორი, ვერსია/თარიღი, მფლობელი (გუნდი/როლი), მომსახურება/რეგიონები/ტენანტები, დაკავშირებული პოლიტიკა/სტანდარტები.
2. გაშვების მიზანი და პირობები: რომელი SLO/SLI ვიცავთ, რომელი ალერტები/ტრიგერები გამოიყენება.
3. ჰიპოთეზის სიმპტომები: შესაბამისობის ცხრილი, თუ როგორ სწრაფად შეწყვიტეთ არასწორი ჰიპოთეზები.
4. გადაწყვეტილებების ხე: ჩანგალი, უსაფრთხოების კარიბჭეები, გაჩერების/გაგრძელების კრიტერიუმები.
5. მოქმედებები: ეტაპობრივი ბლოკები ბრძანებებით/ბმულები runbook- ზე.
6. კომუნიკაციები: Apdate შაბლონი (Impact - დიაგნოზი - მოქმედება - კვალი. apdate), არხები და სიხშირეები.
7. გამოტოვება/folback: მკაფიო backout გეგმა, ლიმიტები და UX დეგრადაციის დროშა.
8. დასრულების კრიტერიუმები: მეტრიკა, დროებითი სათვალთვალო ფანჯრები.
9. Evidence: რა უნდა დაზოგოთ (ლოგოები, გრაფიკა, ეკრანის კადრები, ID თიკეტები).
10. ცვლილებების ისტორია: changelog, ცნობილი შეზღუდვები.

4) პლეიბუკების ტაქსონომია (კატალოგის მაგალითი)

INC - ინციდენტები (SLO/SLI, პროვაიდერები, ინფრასტრუქტურა).
REL- - გამოშვებები, გამოტოვება, კონფიგურაცია/დროშები.
MW- - მომსახურების ფანჯრები (DB/queue/cert/OS).
SEC- - უსაფრთხოება (წვდომა, გასაღებები, საეჭვო ქმედებები).
DATA- - ახალი/ხარისხი/სქემები.
PROV - გარე პროვაიდერები (PSP/KYC/CDN/Email/SMS).

5) ცხოვრების ციკლი და საკუთრება

1. ინიცირება: ინციდენტის/სიმულაციის/ცვლილებების შედეგების მიხედვით.
2. პროექტი: ავტორი = სამსახურის მფლობელი; შურისძიება: SRE/უსაფრთხოება/მონაცემები (დომენის მიხედვით).
3. მფრინავი: tabletop/game-day; გავლის დროისა და დეფექტების დაფიქსირება.
4. პუბლიკაცია: რეპოში (Docs-as-Code), ვერსია, ჭდეები, დაშბორდის ბმულები.
5. განახლება: RCA/CAPA- ს მიხედვით, კვარტალში ერთხელ მაინც; SLA ახალი.
6. არქივი/დეპრესია: აქტუალობის შეცვლისას/დაკარგვისას.

6) ინსტრუმენტებთან ინტეგრაცია

Alert - Playbook: თითოეული Page წესები ეხება ზუსტად ერთ საბაზო ფლეიბუკს.
ChatOps: '/play start <id> "ხსნის ბარათს, აფიქსირებს evidence, აყენებს apdate ტაიმერებს.
CMDB/კატალოგი: მომსახურებას აქვს შესაბამისი პლეიბუკების სია, მფლობელები, SLO, დაშბორდები.
GitOps: playbooks და runbook 'და ცხოვრობენ Git- ში, გადის PR რევიუმი და ლინტერი.

7) პლეიბუკების ხარისხის მეტრიკა

მოქმედება: გაშვების 90% -ზე მეტი იწვევს კონკრეტულ მოქმედებებს ესკალაციის გარეშე „უგულებელყოფით“.
დრო პირველი მოქმედება: წუთი ან ორი Page- დან პირველი მნიშვნელოვანი ნაბიჯი.
Coverage:% Page-Alerts, რომელსაც აქვს დამაკავშირებელი playbuk (მიზანი 100%).
ფრეშნესი: პლეიბუკების წილი 90 დღეზე მეტია.
Edect rate: კომენტარები შურისძიების/სიმულაციების შესახებ 100 playbuck- ზე.
Reuse: რამდენჯერ გამოიყენეს ფლეიბუკი სინამდვილეში (და რა შედეგებამდე მიიყვანა).

8) ანტი შაბლონები

„ფლეიბუკის ენციკლოპედია“ 20 გვერდიანი გადაწყვეტილების ხის გარეშე.
ბრძანებები შედეგის მოლოდინის გარეშე („შესრულება X“ - და რა უნდა შეიცვალოს?).
არ არსებობს backout გეგმა და შეზღუდვები - პრობლემის ესკალაციის რისკი.
არ არის მითითებული არხები/კომუნიკაციების ინტერვალები - PR რისკების ზრდა.
პლეიბუკი მფლობელის გარეშე/განახლების თარიღი - არავის სჯერა მისი აქტუალობის.
ათობით მსგავსი პლეიბუკი ერთი პარამეტრის ნაცვლად.

9) Playbook- ის მინი შაბლონი (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) მზა მაგალითები (ფრაგმენტები)

ა) გადახდა: „პროვაიდერი ამცირებს ერთ რეგიონში“

სიმპტომები: success _ ratio TR კოჰორტის დაქვეითება, PSP-A. ტაიმაუტების ზრდა

გადაწყვეტილებები: შეამციროთ PSP-A წონა TR- სთვის, ჩართოთ degrade-UX, გააძლიეროთ SLA ბიუჯეტი და მოამზადოთ კლიენტის განახლება.
Backout: წონის დაბრუნება მწვანე SLI 60 წუთის განმავლობაში.

B) BD: „ზრდა p99 და კავშირი errors“

სიმპტომები: p99, საკომუნიკაციო შეცდომები, wait events ზრდა.
გადაწყვეტილებები: ჩართეთ read-only სცენარი, შეუზღუდავი დატვირთვა, გააფართოვეთ აუზები/შენიშვნები, საჭიროების შემთხვევაში - ცხელი ფეილოვერი.
Backout: პარამეტრების გამოტოვება, რეპლიკა პრემიერ.

C) Cash: „Miss rate- ის დატვირთვა BD- ზე“

სიმპტომები: miss rate> 40%, CPU BD ზრდა.
გადაწყვეტილებები: დაბალანსება ღონისძიების პოლიტიკაში, გაზარდოს მეხსიერება/შარდვა, დროებით ჩართოთ read-through, შეზღუდეთ RPS ცხელ კლავიშებზე.
Backout: დააბრუნეთ პოლიტიკა, გადააკეთეთ პრობლემური shard.

დ) CDN: „შინაარსის რეგიონალური დეგრადაცია“

სიმპტომები: მატება/დრო ერთ ქვეყანაში, საჩივრები RUM.
გადაწყვეტილებები: შეცვალეთ routing map/GSLB, გადალახეთ პრობლემური POP, შეამციროთ TTL, ჩართეთ origin shield.
კომსი: სტატუს აპდეიტი გავლენის გეოგრაფიით.

E) KYC: „იდენტიფიკაციის შეუსრულებლობა“

სიმპტომები: approve ვარდნა, vendor _ error ზრდა.
გადაწყვეტილებები: გადაიტანეთ ტრეფიკის ნაწილი ალტერნატიულ პროვაიდერზე, შეამციროთ წესების სიმძიმე (როგორც პოლიტიკის ნაწილი), დაიწყეთ სახელმძღვანელო მიმოხილვა VIP- სთვის.
კომპლექსი: ყველა ცვლილების ლოგო, Risk/Legal შეტყობინებები საჭიროების შემთხვევაში.

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) პლეიბუკის ავტორის ჩეკის სია

• მითითებულია მიზანი, მეპატრონეები, SLO/SLI და გამომწვევები.
• არსებობს ცხრილი „ჰიპოთეზის სიმპტომები“ და გადაწყვეტილებების ხე.
• შესრულებული ნაბიჯები მოსალოდნელი შედეგებითა და უსაფრთხოების კარიბჭეებით.
• რეგისტრირებულია backout/fallback და დაბრუნების პირობები.
• კომუნიკაციების შაბლონი და აპდეიტის სიხშირე.
• ბმულები დაშბორდები/ალერტები/ლოგის ძებნა/ტრეისი.
• სავალდებულო ღონისძიების განყოფილება და დასრულების კრიტერიუმები.
• ვერსია, თარიღი, SLA სიახლე, ცვლილებების ისტორია.

13) Revewer- ის ჩეკის სია

• ფლეიბუკი რეპროდუცირებულია tabletop/game-day.
• ნაბიჯები უსაფრთხოა (ლიმიტები/კანარი/მანქანა-გამოტოვება), საიდუმლოებები არ არის გამჟღავნებული.
• როლები და ესკალაცია ნათელია; მითითებულია IC/Comms.
• არ არსებობს დუბლირება მეზობელ ფლეიბუკებთან; პარამეტრები მიიღება.
• გასაგებია, როდის უნდა შეჩერდეს და გადავიდეს fallback/rollback.
• დოკუმენტი ხელმისაწვდომია ალერტიდან 1 დაწკაპუნებით.

14) პარამეტრიზაცია და ხელახალი გამოყენება

მოიტანეთ ცვლადი (რეგიონი, პროვაიდერი, ბარიერები) 'ვალუებში.'.
ზოგადი ნაბიჯები (მაგალითად, „შეამციროთ პროვაიდერის წონა“, „ჩართეთ degrade-UX“) შეიმუშავეთ ცალკეული runbook 'ami.
შეინარჩუნეთ შაბლონების გენერატორები: 'plb new -type = INC --service = payments'.

15) განხორციელების გზის რუკა (4-6 კვირა)

1. Page-Alert- ის ინვენტარიზაციამ თითოეული ძირითადი ფლეიბუკის შედარება შეიძლება.
2. შაბლონები: დაამტკიცეთ YAML/Markdown სტრუქტურა, ჩეკის ფურცლები და ლინტერები.
3. ტოპ 5 სცენარი (გადახდა/BD/CDN/KYC/ქეში) შეგიძლიათ დაწეროთ/გამოტოვოთ tabletop.
4. ინტეგრაცია: ბმულები ალერტიდან, ChatOps გუნდები, evidence-bot.
5. სწავლებები: ყოველკვირეული mini-drill თითო playbook; AAR გაუმჯობესება.
6. SLA ახალი და კვარტალური შურისძიება; ანგარიში ხარისხის მეტრიკებზე.

16) შედეგი

Playbooks არის ოპერაციული სცენარები ჩანგლებით და მოაჯირებით, რომლებიც თარგმნიან ქაოსს „და რა უნდა გააკეთოს?!“ გადაწყვეტილებების პროგნოზირებადი თანმიმდევრობით. როდესაც პლეიბუკები სტანდარტიზებულია, ინტეგრირებულია ალერტებთან და რეგულარულად ვარჯიშობენ, გუნდი უფრო სწრაფად რეაგირებს, რისკები კონტროლდება და ბიზნესი ხედავს სტაბილურობას და ექსპლუატაციის სიმწიფეს.