ინციდენტები და SRE ფლეიბუკები

1) რა არის ინციდენტი და როგორ უკავშირდება იგი SLO- ს

ინციდენტი არის მოვლენა, რომელიც არღვევს SLO/ოფიციალურ ფუნქციას ან ქმნის დარღვევის რისკს (არასწორი ბიუჯეტი მიუღებელია სწრაფად).
კლასიკური მეტრიკა: MTTD, MTTA, MTTR, MTBF.
ბიუჯეტის შეცდომა და გამშვები პუნქტი განსაზღვრავს ესკალაციის პრიორიტეტსა და ფანჯრებს.

2) სერიოზულობის დონე (SEV) და კრიტერიუმები

SEV გამომწვევები: ჭარბი 5xx%, p95> ბარიერი, გადახდის decline spike, Kafka-lag> ბარიერი, NodeNotReady> X წუთი, TLS იწურება <7 დღე, DDoS/გაჟონვა.

3) როლები და პასუხისმგებლობა (RACI)

Incident Commander (IC) - ერთადერთი გადაწყვეტილების მიღება, დავალებების ნაკადის მენეჯმენტი, SEV სტატუსის შეცვლა.
Ops Lead (Tech Lead) - ტექნიკური სტრატეგია, ჰიპოთეზა, ფიქრების კოორდინაცია.
კომუნიკაციები Lead (Comms) - სტატუსის გაფართოება (შიდა/გარე), StatusPage/chat/ფოსტა.
Scribe (მემატიანე) - დრო, გადაწყვეტილებები, არტეფაქტები, ბმულები გრაფიკულ/ლოგიკაზე.
On-call Engineers/SMEs - პლეიბუკების მოქმედებების შესრულება.
უსაფრთხოება/პირადი - ჩართულია უსაფრთხოების ინციდენტებში ან PII.
FinOps/Payments - ბილინგზე გავლენის მოხდენისას/PSP/ღირებულება.

4) ინციდენტის სასიცოცხლო ციკლი

1. დეტაჟი (ალერტი/რეპორტაჟი/სინთეტიკა) - ინციდენტის ბარათის მანქანის შექმნა.
2. სამჯერ (IC დაინიშნა, SEV- ს ენიჭება მინიმალური კონტექსტის შეგროვება).
3. სტაბილიზაცია (mitigation: გამორთეთ fick/rollback/rate-limit/failover).
4. გამოძიება (RCA ჰიპოთეზები, ფაქტების შეგროვება).
5. მომსახურების აღდგენა (validate SLO, დაკვირვება).
6. კომუნიკაცია (შიგნით/გარეთ, საბოლოო ანგარიში).
7. პოსტმორტემი (ბრალდების გარეშე, CAPA გეგმა, მფლობელები, ვადები).
8. Prevention (ტესტები/ალერტები/playbuks/დროშები, გუნდის მომზადება).

5) კომუნიკაციები და „ომის ოთახი“

ინციდენტის ერთი არხი ('# inc-sev1-YYYMMDD-hmm'), მხოლოდ ფაქტები და მოქმედებები.

რადიო პროტოკოლის გუნდები: "IC: მე დანიშნავს rollback ვერსიას 1. 24 - ETA 10 წუთი."

სტატუსი: SEV-1 ყოველ 15 წუთში, SEV-2 - ყოველ 30-60 წუთში.
Status Page/გარე კომუნიკაცია - Comms Lead- ის მეშვეობით შაბლონის მიხედვით.
აკრძალულია: პარალელური „მშვიდი“ ოთახები, გადამოწმებული ჰიპოთეზები საერთო არხში.

6) ალერტინგი და SLO-burn (წესების მაგალითი)

სწრაფი არხი (1-5 წუთი) და ნელი არხი (1-2 საათი) ქარიშხალი.
მულტფილმის სიგნალები: ბიუჯეტის შეცდომა, 5xx%, p95, Kafka-lag, გადახდის decline, სინთეზური.
ძირითადი მიზეზის ძიება მხოლოდ სიმპტომების სტაბილიზაციის შემდეგ ხდება.

promql
Error rate 5xx> SLO sum (rate (http_requests_total{status=~"5"..}[5m]) )/sum (rate (http_requests_total[5m]))> 0. 01

Burn-rate fast (example)
(sum(rate(http_requests_total{status=~"5.."}[1m])) / sum(rate(http_requests_total[1m])))
/ (1 - SLO) > 14. 4

7) Playbooks vs ranbooks

პლეიბუკი - მოქმედების სცენარი ინციდენტის ტიპის მიხედვით (ფილიალი, პირობები, რისკები).
რანბუკი - ნაბიჯების/ბრძანებების კონკრეტული „რუკა“ (შემოწმება, ფიქსაცია, გადამოწმება).
წესი: ფლეიბუკი ეხება რამდენიმე რანბუკს (rollbacks, feature-flags, failover, სკალირება, ტრაფიკის დაბლოკვა და ა.შ.).

8) ინციდენტის ბარათის შაბლონი

yaml id: INC-YYYYMMDD-XXXX title: "[SEV-1] Рост 5xx на API /payments"
status: active    monitoring    resolved sev: 1 reported_at: 2025-11-03T17:42Z ic: <ФИО>
ops_lead: <name>
comms_lead: <name>
scope: regions: [eu-west-1], tenants: [prod], services: [api, payments]
impact: "5xx = 12% (usually <0. 5%), deposit conversion -20%"
mitigation: "rollback to 1. 23. 4, rate-limit 2k rps on, feature X off"
timeline:
- "17:42: alert SLO burn-rate fast"
- "17:46: IC appointed, war-room open"
- "17:52: release 1 found. 24 as a candidate"
- "18:02: Rollback complete, 5xx back to 0. 3%"
artifacts:
dashboards: [...]
logs: [...]
traces: [...]
risk: "another surge is possible when turning on feature X"
next_steps: "canary release, tests, postmortem until 2025-11-05"

9) შაბლონი SRE playbook (Markdown)

markdown
Playbook: <title>
Area/symptoms
List of detectors, signatures in metrics/logs/traces.

Triage & Mitigation
- [] Restrict traffic/enable WAF rule/OFF feature
- [] Rollback/canary release/roll out configuration fix
- [] Enable degradation mode (read-only, cache force)

Diagnostics (RCA hints)
- Metrics:... Logs:... Trails:...
- Common Root Causes/Hypothesis Checklist

Risks and communications
- Internal/external updates, SLA obligations

Verification
- [] SLO restored (threshold/window time)
- [] No recourse for related services

Follow-up
- CAPA, tasks in backlog, updating alerts/dashboards/playbook

10) ტიპიური ფლეიბუკები

10. 1 API 5xx Spike

სტაბილიზაცია: გამორთეთ პრობლემური ძაფები; გაზარდეთ API შენიშვნები; ქეშირების ჩართვა; გამოშვების დაბრუნება.
დიაგნოზი: diff გამოშვება, შეცდომები ლოგოებში, ზრდა p95, pressure BD/kesh.
რისკები: კასკადი გადახდებში/ზურგჩანთებში.

10. 2 БД: replication lag / lock storm

სტაბილიზაცია: მძიმე ჯობების/რეპორტების შეჩერება; კითხვის გადამისამართება ოსტატზე; გაზარდეთ wal _ buffers/რეპლიკა.
დიაგნოზი: გრძელი გარიგებები, ბლოკირების მოთხოვნები, გეგმის ცვლილებები.
ფიქსაცია: ინდექსები/ჰინტები, ჯობების ხელახალი განვითარება, მოთხოვნების დაყოფა.

10. 3 Kafka consumer lag

სტაბილიზაცია: დროებით განაწილება consumer's; შეამცირეთ წარმოება არაკრიტიკული სერვისებიდან; გაზარდოს წვეულებები/კვოტები.
დიაგნოზი: rebalances, ნელი დესერალიზაცია, GC პაუზები.
გადამოწმება: lag - მიზნობრივი მნიშვნელობისკენ, არ არსებობს ფრაგმენტები.

10. 4 K8s NodeNotReady/რესურსების ქარიშხალი

სტაბილიზაცია: cordon + drain; დატვირთვის გადანაწილება; შეამოწმეთ CNI/overlay; გამორთეთ ხმაურიანი DaemonSet.
დიაგნოზი: disk pressure, OOM, throttling, ქსელი drops.
პრევენცია: pod disruption budgets, რესურსების ლიმიტები/requests.

10. 5 TLS/სერთიფიკატები იწურება

სტაბილიზაცია: საიდუმლოების იძულებითი განახლება; დროებითი override.
დიაგნოზი: ნდობის ჯაჭვი, clock-skew.
პრევენცია: ალერტები T-30/T-7/T-1, ავტო-რენუალი.

10. 6 DDoS/არანორმალური ტრაფიკი

სტაბილიზაცია: WAF/bot წესები, rate-limit/geo ფილტრები, upstream shed load.
დიაგნოზი: შეტევის პროფილები (L3/4/7), წყაროები, „ქოლგები“.
პრევენცია: anycast, autoscaling, ქეშირება, პლეი-ნიზი პროვაიდერთან.

10. 7 გადახდის PSP გარეთ

სტაბილიზაცია: ჭკვიანი როტინგი ალტერნატიული PSP/მეთოდებისთვის; გაზარდეთ retry ერთად jitter; UI- ს „რბილი“ დეგრადაცია.
დიაგნოზი: spike უარი კოდებზე, API სტატუსები/PSP სტატუსის გვერდები.
კომუნიკაციები: გამჭვირვალე აფდეიტები ბიზნესისა და საფორტეპიანოსთვის, სწორი ND/კონვერტაციის სტატისტიკა.

10. 8 უსაფრთხოების ინციდენტი/PII გაჟონვა

სტაბილიზაცია: კვანძების იზოლაცია/საიდუმლო როტაცია, გამოთვლების დაბლოკვა, ლეგალური ჰოლდი.
დიაგნოზი: დაშვების დრო, დაზარალებული საგნები/ველები.
შეტყობინებები: რეგულატორები/პარტნიორები/იურისდიქციის მომხმარებლები.
პრევენცია: DLP/სეგმენტის გაძლიერება, „გრძელი პირადი“.

11) ფლეიბუკების ავტომატიზაცია

ChatOps ბრძანებები: '/ic set sev 1 ', '/deploy rollback ap1. 23. 4`, `/feature off X`.
Runbook bots: ნახევრად ავტომატური ნაბიჯები (დარტყმა, მფრინავი ტრაფიკი, purge cache).
Self-healing huks: დეტექტორი სტანდარტული mitigation (rate-limit, restart, scale).
მანქანის შექმნა/დრო ალერტებისა და გუნდებიდან.

12) პლეიბუკების ხარისხი: ჩეკების სია

• მკაფიო სიმპტომები და დეტექტორები (მეტრიკა/ლოგები/ბილიკები).
• სწრაფი სტაბილიზაციის ნაბიჯები რისკის შეფასებით.
• ბრძანებები/სკრიპტები აქტუალურია, შემოწმებულია staging.
• SLO აღდგენის გადამოწმება.
• საკომუნიკაციო შაბლონები და გარე აფდიტების კრიტერიუმები.
• postmortem ბმული და CAPA დახურვის შემდეგ.

13) პოსტმორთემი და CAPA

მიზანი: სწავლა და არა დამნაშავე.
შინაარსი: რა მოხდა, როგორ დაადგინეს, რა იყო კარგი/ცუდი, ფაქტორების წვლილი (ეს + პროცესები), მოქმედებები თავიდან ასაცილებლად.
ვადა: SEV-1 - 48 საათის განმავლობაში; SEV-2 - 3 სამუშაო დღე.
CAPA: კონკრეტული მფლობელები, ვადები, გაზომილი ეფექტები (შემცირება MTTR/MTTD ზრდა).

14) იურიდიული ასპექტები და მტკიცებულებები

Legal Hold: ლოგოების/ბილიკების/ალერტების გაყინვა, write-once საცავი.
არტეფაქტების შენახვის ჯაჭვი: როლებისთვის წვდომა, მთლიანობის კონტროლი.
მარეგულირებელი შეტყობინებები: იურისდიქციების ვადები/შაბლონები (განსაკუთრებით დაზარალებული გადახდების/PII).
კონფიდენციალურობა: ანალიზის დროს PII- ის შემცირება და შენიღბვა.

15) ინციდენტების პროცესის ეფექტურობის მეტრიკა

MTTD/MTTA/MTTR კვარტლებისა და დომენების მიხედვით.
SEV- ის სისწორე.
ინციდენტების წილი მიტიგიტთან.
Playbucks დაფარავს ტოპ N სცენარებს (> 90%).
CAPA- ს განხორციელება დროულად.

16) ეტაპების განხორციელება

1. კვირა 1: SEV მატრიცა, on-call- ის როლი, ბარათის ზოგადი შაბლონი, ომის ოთახი რეგულირება.
2. კვირა 2: პლეიბუკი ტოპ 5 სიმპტომისთვის (5xx, BD-lag, Kafka-lag, NodeNotReady, TLS).
3. კვირა 3: ChatOps/bots, ბარათების მანქანის შექმნა, კომუნიკაციის შაბლონები/StatusPage.
4. კვირა 4 +: Playbooks, PSP autage, Legal Hold, რეგულარული drills/ქაოსის თამაშები.

17) სწრაფი რანბუკების მაგალითები (ფრაგმენტები)

Rollback API (K8s)

bash kubectl rollout undo deploy/api -n prod kubectl rollout status deploy/api -n prod --timeout=5m
Verification:
kubectl -n prod top pods -l app=api

Drain node

bash kubectl cordon $NODE && kubectl drain $NODE --ignore-daemonsets --delete-emptydir-data --timeout=10m

Feature-flag OFF (მაგალითი)

bash curl -X POST "$FF_URL/toggle" -H "Authorization: Bearer $TOKEN" -d '{"feature":"X","enabled":false}'

18) მინი-FAQ

როდის უნდა გაიზარდოს SEV-1?
როდესაც ძირითადი SLO/ბიზნეს ფუნქცია განიცდის (გადახდები, ლოგინი, თამაში) და ბურნი-თამაში „ჭამს“ ბიუჯეტს წინასწარ საათების განმავლობაში.

რა არის უფრო მნიშვნელოვანი - RCA ან აღდგენა?
ყოველთვის სტაბილიზაცია, შემდეგ RCA. სტაბილიზაციის დრო მთავარი მაჩვენებელია.

საჭიროა თუ არა ყველაფრის ავტომატიზაცია?
ავტომატური ხშირი და უსაფრთხო ნაბიჯები; იშვიათი/სარისკო - ნახევრად მანქანის მეშვეობით და IC დადასტურებით.

შედეგი

ინციდენტების საიმედო პროცესი ემყარება სამ სვეტს: მკაფიო როლებს და SEV წესებს, მაღალი ხარისხის ფლეიბუკებს/რანბუკებს ავტომატიზაციით და პოსტმორტემების კულტურას ბრალდების გარეშე. დააფიქსირეთ შაბლონები, გაწვრთნეთ on-call, გაზომეთ MTTR/არასწორი ბიუჯეტი და მუდმივად გააუმჯობესეთ დეტექტორები და ფლეიბუქები - ეს პირდაპირ ამცირებს რისკებს და ხარჯების ღირებულებას.