ალერტინგი და რეაგირება წარუმატებლობაზე

(განყოფილება: ტექნოლოგიები და ინფრასტრუქტურა)

მოკლე რეზიუმე

ძლიერი ალერტინგი არის სიგნალი მომხმარებლის ღირებულების დარღვევის შესახებ და არა მხოლოდ „წითელი მეტრიკა“. IGaming- ისთვის მნიშვნელოვანია SLO კარიბჭეები (ლატენტობა, წვდომა, გადახდის კონვერტაცია, Time-to-Wallet), მრავალფუნქციური წესები, აშკარა როლები on-call, ესკალაცია, ChatOps და runbooks. მიზანია სწრაფად დაინახოს გადახრა, აცნობოს მათ, ვისაც შეუძლია გამოსწორება და ცოდნის დაფიქსირება, რათა შემდეგჯერ რეაგირება მოახდინოს კიდევ უფრო სწრაფად და იაფი.

1) საფუძვლები: მეტრიკიდან მოქმედებამდე

SLI - SLO - Alert: გაზომილი ხარისხი, მიზნობრივი დონე და პირობები „ბიუჯეტი იწვის“.
Severity (SEV): SEV1 - კრიტიკული (შემოსავალი/GGR საფრთხის ქვეშ), SEV2 - სერიოზული, SEV3 - ზომიერი, SEV4 - უმცირესობა.
Impact/Urgency: ვინ იტანჯება (ყველა/რეგიონი/ტენანტი/არხი) და რამდენად სასწრაფოდ (TTW, p99, error-rate).
Actionability: თითოეული განგაში - კონკრეტული მოქმედება (runbook + მფლობელი).

2) სიგნალების ტაქსონომია

ТехSLO: p95/p99 latency API, error-rate, saturation (CPU/IO/GPU), queue lag.
BusinesSLO: გადახდის კონვერტაცია (attempt-success), Time-to-Wallet (TTW), ფსონების წარმატება, თამაშების გაშვება.
გადახდის მარშრუტები: PSP სპეციფიკური მეტრიკა (Timeout/decline spikes).
წინა/მობილური: RUM მეტრიკა (LCP/INP), crash-rate, სცენარის სინთეზური (ლოგინი/დეპოზიტი/განაკვეთი/გამომავალი).

3) ალერტინგის პოლიტიკა: SLO და burn-rate

SLI/SLO მაგალითები

„payments-api“ - 99 ხელმისაწვდომობა. 9% / 30d p95 `/deposit` ≤ 250 ms / 30d

კონვერტაცია 'payments _ attempt' success '- baseline − 0. 3% / 24h

TTW p95-3 წთ/24h

Multi-window / Multi-burn (идея PromQL)

Fast burn: SLO დარღვევა 5-10 × უფრო სწრაფია, ვიდრე ნორმალური (ალერტული პეიჯი 5-15 წუთში).
Slow burn: ნელი ბიუჯეტის დამწვრობა (თიკეტი + ანალიზი 1-3 საათისთვის).

yaml
API success proxy metric (recording rule in advance)
record: job:http:success_ratio expr:
sum(rate(http_requests_total{status=~"2..    3.."}[5m]))
/ sum(rate(http_requests_total[5m]))
Fast burn (99. 9% SLO)
alert: PaymentsSLOFastBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 14 for: 10m labels: { severity: "page", service: "payments-api" }
annotations:
summary: "SLO fast burn (payments-api)"
runbook: "https://runbooks/payments/slo"
Slow burn alert: PaymentsSLOSlowBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 6 for: 1h labels: { severity: "ticket", service: "payments-api" }

4) ხმაურის შემცირება და სიგნალის ხარისხი

ჭეშმარიტების სწორი წყარო: დანაყოფების (ჩანაწერების) ალერტირება და არა მძიმე „ნედლეული“ გამონათქვამები.
დედუპლიკაცია: Alertmanager დაჯგუფებს 'სერვისს/მომსახურებას/გადაკეთებას/დაბრუნებას'.
იერარქია: პირველი ალერტი ბიზნესისთვის/SLI, ქვემოთ - ტექნოლოგია, როგორც დიაგნოზი.
Supressia: planned-maintenance/გამოშვების დროს (ვიდეო), upstream ინციდენტებით.
კარდინალობა: ნუ გამოიყენებთ 'user _ id/session _ id' ალერტის ეტიკეტებში.
ტესტის ალერტები: რეგულარული „სასწავლო“ ტრიგერები (არხების შემოწმება, როლები, რუნაბუკის ბმულები).

5) Alertmanager: მარშრუტიზაცია და ესკალაცია

yaml route:
group_by: [service, region]
group_wait: 30s group_interval: 5m repeat_interval: 2h receiver: sre-slack routes:
- matchers: [ severity="page" ]
receiver: pagerduty-sre continue: true
- matchers: [ service="payments-api" ]
receiver: payments-slack

receivers:
- name: pagerduty-sre pagerduty_configs:
- routing_key: <PD_KEY>
severity: "critical"
- name: sre-slack slack_configs:
- channel: "#alerts-sre"
send_resolved: true title: "{{.CommonLabels. service }} {{.CommonLabels. severity }}"
text: "Runbook: {{.CommonAnnotations. runbook }}"

inhibit_rules:
- source_matchers: [ severity="page" ]
target_matchers: [ severity="ticket" ]
equal: [ "service" ]

იდეა: SEV = PagerDuty/SMS; დანარჩენი არის Slack/ticket. ინგიბია თრგუნავს ქვედა დონის „ჰიპს“ აქტიური SEV ზემოთ.

6) Grafana Alerting (როგორც ფენა)

ცენტრალიზებული Alert rules დაშბორდებზე (Prometheus/Loki/Cloud).
Contact points: PagerDuty/Slack/Email, Notification policies per folder.
Silences: დაგეგმილი სამუშაოები, მიგრაცია, გამოშვებები.
Snapshots მანქანის ეკრანის ანაბეჭდით ტიკეტში.

7) On-call და „ცოცხალი“ პროცესები

როტაცია: 1 ხაზი (SRE/პლატფორმა), მე -2 ხაზი (სამსახურის მფლობელი), მე -3 (DB/Payments/Sec).
SLA რეაქცია: 5 წუთი (SEV1) აღიარება, დიაგნოზი 15 წუთი, კომუნიკაცია ყოველ 15-30 წუთში.
მორიგე არხები: '# incident-warroom', '# status-განახლებები' (მხოლოდ ფაქტები).
Runbooks: ბმული ყველა ალერტში + სწრაფი ChatOps ბრძანებები ('/rollback ', '/freeze', '/scale ').
ტრენინგის განგაში: ყოველთვიურად (ხალხის შემოწმება, არხები, აქტუალობა).

8) ინციდენტები: სასიცოცხლო ციკლი

1. დეტაჟი (ალერტი/რეპორტაჟი/სინთეზური) - Acknowledge on-call.
2. სამჯერ: განსაზღვროთ SEV/დაზარალებული/ჰიპოთეზა, გახსნათ ომის ოთახი.
3. სტაბილიზაცია: რულონები/გამოტოვება/სკალირება/ფიჩეფლაგები.
4. კომუნიკაციები: სტატუსის შაბლონი (იხ. ქვემოთ), ETA/შემდეგი ნაბიჯები.
5. დახურვა: SLO აღდგენის დადასტურება.
6. Post-Incident Review (RCA): 24-72 საათის შემდეგ, ბრალდების გარეშე, მოქმედება items.

• რა არის გატეხილი/ვინ დაზარალდა (რეგიონი/ტენანტი/არხი)
• როდესაც დაიწყო/SEV
• დროებითი ზომები
• სტატუსის შემდეგი განახლება N წუთში
• კონტაქტი (ინციდენტის მენეჯერი)

9) iGaming სპეციფიკა: „ტკივილი“ ზონები და ალერტები

Payments/TTW: PSP ტაიმაუტების წილი, კოდის უკმარისობის ზრდა, TTW r95> 3 მ.
ტურნირების მწვერვალები: p99 API/თამაშის დაწყების დრო/queue lag; ლიმიტების/მანქანის სკალირების პროპაგანდა.
სახსრების დასკვნები: SLA bacofis/სახელმძღვანელო შემოწმება, ქვეყნის ლიმიტები.
თამაშების პროვაიდერები: სტუდიაში წვდომა, სესიის ინიციალიზაციის დრო, გაშვების ვარდნა.
RG/Compliance: გრძელი სესიების წამოწყება/“ დოგონი“, ბარიერების ჭარბი რაოდენობა არ არის პეიჯი, არამედ ticet + შეტყობინება RG გუნდისთვის.

10) წესების მაგალითები (დამატებითი)

მაღალი ლატენტობა p95 (API)

promql alert: HighLatencyP95 expr: histogram_quantile(0. 95,
sum by (le, service) (rate(http_request_duration_seconds_bucket{service="api"}[5m]))) > 0. 25 for: 10m labels: { severity: "page", service: "api" }
annotations:
summary: "p95 latency > 250ms"
runbook: "https://runbooks/api/latency"

დასკვნების ხაზი „იწვის“

promql alert: WithdrawalsQueueLag expr: max_over_time(queue_lag_seconds{queue="withdrawals"}[10m]) > 300 for: 10m labels: { severity: "page", service: "payments-worker" }
annotations:
summary: "Withdrawals lag >5m"
runbook: "https://runbooks/payments/queue"

გადახდების კონვერტაცია დაეცა

promql alert: PaymentConversionDrop expr:
(sum(rate(payments_success_total[15m])) / sum(rate(payments_attempt_total[15m])))
< (payment_conv_baseline - 0. 003)
for: 20m labels: { severity: "page", domain: "payments" }
annotations:
summary: "Payment conversion below baseline -0. 3%"
runbook: "https://runbooks/payments/conversion"

11) ChatOps და ავტომატიზაცია

ალერტის მანქანის განთავსება ღილაკებით: Stop canary, Rollback, Scale + N.

ბრძანების შეკუმშვა: '/incident start ', '/status განახლება', '/call ', '/grafana '

ბოტები ამცირებენ კონტექსტს: ბოლო დეპოზიტები, დამოკიდებულების გრაფიკი, ტრეისის მაგალითები (exemplars), დაკავშირებული თიკეტები.

12) პოსტ-ინციდენტი (RCA)

ფაქტები: დრო, რაც დაინახა/რა სცადა, რა მუშაობდა.
Root cause: ტექნიკური და ორგანიზაციული მიზეზები.
Detections & Defenses: რა სიგნალები დაეხმარა/ვერ მოხერხდა.
Action items: კონკრეტული დავალებები (SLO/Alerty/კოდები/limites/ტესტები/runabuk).
Due dates & owners: ვადები და პასუხისმგებლობა; follow-up სესია 2-4 კვირაში.

13) განხორციელების შემოწმების სია

1. განსაზღვრეთ SLI/SLO საკვანძო ნაკადებისთვის (API/Payments/Games/TTW).
2. რეკორდული რულეტების და მრავალ-ბურნის ალერტების პარამეტრები + მარშრუტიზაცია Alertmanager.
3. შეიყვანეთ on-call როტაციით, SLO რეაქციებითა და ესკალაციებით.
4. ჩართეთ ალერტები runbooks და ChatOps გუნდები.
5. ჩახშობის/მშვიდი ფანჯრების პარამეტრები, გამოშვებების/ნამუშევრების სურათები.
6. გააკეთეთ ტრენინგი და თამაშის დღის სცენარი (შემცირება PSP, ზრდა p99, ზრდა queue lag).
7. გაზომეთ Alert Quality: MTTA/MTTR,% noisy/false, coverage on SLO.
8. რეგულარული RCA და ბარიერების/პროცესების გადასინჯვა.
9. შეიყვანეთ სტატუს კომუნიკაცია ბიზნესთან/საფორტეპიანოსთან (შაბლონები).
10. აღწერეთ ყველაფერი, როგორც კოდი: წესები, მარშრუტები, რუნაბუკის ბმულები.

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

ალერტინგი „ყველა მეტრიკისთვის“ - ალერტ-ფეტიგი, უგულებელყოფა.
არ არსებობს SLO - უცნობია რა არის „ნორმა“ და რა „იწვის“.
დეპრესიების/ინგიბირების არარსებობა - დუბლიკატების ზვავი.
პეიჯი ღამით უმცირესობის მოვლენებისთვის (SEV არ არის შედარებული Impact- სთან).
ალერტები runbook/მფლობელის გარეშე.
„სახელმძღვანელო“ მოქმედებები ChatOps/აუდიტის გარეშე.
არ არსებობს RCA/Action items ინციდენტების განმეორება.

შედეგები

ალერტინგი და რეაგირება არის პროცესი და არა წესების ერთობლიობა. დააკავშირეთ SLO მრავალფუნქციური ალერტებით, ააშენეთ მკაფიო on-call ესკალაცია, დაამატეთ ChatOps და ცოცხალი runabuk, რეგულარულად ჩაატარეთ RCA და ტრენინგი. შემდეგ ინციდენტები ნაკლებად, უფრო მოკლე და იაფი იქნება, ხოლო გამოშვებები პროგნოზირებულია iGaming- ის ცხელ საათებშიც კი.