ინციდენტები და 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
Ошибочная доля 5xx > SLO sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 0.01

Burn-rate быстрый (пример)
(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: <ФИО>
comms_lead: <ФИО>
scope: regions: [eu-west-1], tenants: [prod], services: [api, payments]
impact: "5xx=12% (обычно <0.5%), конверсия депозитов -20%"
mitigation: "откат на 1.23.4, включен rate-limit 2k rps, фича X выключена"
timeline:
- "17:42: алерт SLO burn-rate быстрый"
- "17:46: назначен IC, открыт war-room"
- "17:52: найден релиз 1.24 как кандидат"
- "18:02: откат завершен, 5xx вернулись к 0.3%"
artifacts:
dashboards: [...]
logs: [...]
traces: [...]
risk: "возможен очередной всплеск при включении фичи X"
next_steps: "канареечный релиз, тесты, постмортем до 2025-11-05"

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

markdown
Плейбук: <название>
Область/симптомы
Список детекторов, сигнатуры в метриках/логах/трассах.

Быстрая стабилизация (Triage & Mitigation)
- [ ] Ограничить трафик/включить WAF-правило/фичефлаг OFF
- [ ] Роллбэк/канареечный релиз/выкатить фикс конфигурации
- [ ] Включить деградационный режим (read-only, кэш-форс)

Диагностика (RCA hints)
- Метрики: … Логи: … Трассы: …
- Частые первопричины/чек-лист гипотез

Риски и коммуникации
- Внутренние/внешние апдейты, SLA-обязательства

Верификация
- [ ] SLO восстановлено (порог/время окна)
- [ ] Нет регресса по смежным сервисам

Последующие действия
- CAPA, задачи в backlog, обновление алертов/дашбордов/плейбука

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
Верификация:
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/არასწორი ბიუჯეტი და მუდმივად გააუმჯობესეთ დეტექტორები და ფლეიბუქები - ეს პირდაპირ ამცირებს რისკებს და ხარჯების ღირებულებას.