ჭარბი ალერტის თავიდან აცილება

1) პრობლემა და მიზანი

Alert fatigue წარმოიქმნება მაშინ, როდესაც სისტემა ძალიან ბევრ არარელევანტურ ან არააქტიური შეტყობინებებს ატარებს. შედეგი არის პეიჯების უგულებელყოფა, MTTA/MTTR- ის ზრდა და რეალური ინციდენტების გამოტოვება.
მიზანი: სიგნალები გახადოს იშვიათი, მნიშვნელოვანი და შესრულებული, მიბმული SLO და playbooks.

2) სიგნალის ტაქსონომია (არხი = შედეგები)

გვერდი (P0/P1) - გაიღვიძებს ადამიანი; მხოლოდ მაშინ, როდესაც სახელმძღვანელო ეფექტი საჭიროა ახლა არის runbook.
Ticket (P2) - ასინქრონული სამუშაო საათებში/დღეს; არ გაიღვიძებს, მაგრამ SLA ტრიალებს.
Dash-only (P3) - დაკვირვება/ტენდენცია აქტიური მოქმედებების გარეშე; არ ქმნის ხმაურს.
Silent Sentry - ფონი/აუდიტი (RCA/პოსტ-mortem- ისთვის).

3) „სწორი“ ალერტის დიზაინი

• მიზანი/ჰიპოთეზა (რომელსაც ჩვენ ვიცავთ: SLO, უსაფრთხოება, ფული, შესაბამისობა).
• სამუშაო პირობები (ბარიერი, ფანჯარა, წყაროების კვორუმი).
• Runbook/Playbook (მოკლე ID ნაბიჯი + ბმული).
• მფლობელი (გუნდი/როლური ჯგუფი).
• დასრულების კრიტერიუმები (როდესაც დახურვა, მანქანის საჭრელი).
• დაუცველობის კლასი (user-impact/platform/უსაფრთხოების/cost).

4) SLO ორიენტირებული მონიტორინგი

SLI/SLO არის პირველადი სიგნალები: წვდომა, ლატენტობა, ბიზნეს ოპერაციების წარმატება.

• მოკლე: ბიუჯეტის 5% 1 საათში Page.
• გრძელი: ბიუჯეტის 2% 6 საათში Ticket.
• კოჰორტიზმი: ალერტები რეგიონების/პროვაიდერების/VIP სეგმენტების მიხედვით - ნაკლები ცრუ გლობალური შფოთვა.

5) ხმაურის შემცირების ტექნიკა

1. ზონდის კვორუმი: მხოლოდ იმ შემთხვევაში, თუ 2 დამოუკიდებელი წყარო (სხვადასხვა რეგიონები/პროვაიდერები) დაადასტურებს პრობლემას.
2. დედუპლიკაცია: იგივე მოვლენების ჯგუფი (gregation keys: service + region + code).
3. ჰისტერეზი/ხანგრძლივობა: „წითელ ზონაში N წუთი“ ხერხემლის გაფილტვრისთვის.
4. Rate-limit: არაუმეტეს X შეტყობინებები/საათი/მომსახურება; ჭარბი - ერთი პეიჯი + ანგარიში.
5. Auto-snooze/ინტელექტუალური ჩახშობა: განმეორებითი ალერტი ფანჯარაში T - თარგმნა Ticket- ში ფესვის აღმოსაფხვრელად.
6. მოვლენების კორელაცია: ერთი „სამაგისტრო ალერტი“ ათეულობით სიმპტომის ნაცვლად (მაგალითად, „BD მიუწვდომელია“ მიკრო სერვისებიდან 5xx).
7. Maintenance ფანჯრები: დაგეგმილი სამუშაოები ავტომატურად თრგუნავს მოსალოდნელ სიგნალებს.
8. Anomaly + guardrails: ანომალიები - მხოლოდ როგორც Ticket, თუ SLO სიგნალის დადასტურება არ არსებობს.

6) მარშრუტიზაცია და პრიორიტეტები

პრიორიტეტები: P0 (Page, 15 წუთი განახლება), P1 (Page, 30 წუთი), P2 (Ticket, 4-8 საათი), P3 (დაკვირვება).
ეტიკეტების როტინგი: მომსახურება/env/region/tenant - შესაბამისი on-call.
დროის ესკალაცია: 5 წუთში არ არის ack - P2 - Duty Manager/IC.
Quiet Hours: ღამის საათები არაკრიტიკულისთვის; გვერდი აკრძალულია P2/P3- სთვის.
Fatigue პოლიტიკა: თუ ინჟინერს აქვს> N padgey/ცვლა - გადანაწილება P2- ზე, სიგნალის დაბინძურების ესკალაცია.

7) ალერტების ხარისხი: შეთანხმებები

Actionability - 80%: პეიზაჟების უმეტესი ნაწილი იწვევს runbook- ის მოქმედებას.
False Positive 5% Page სიგნალებისთვის.
დრო Fix-Alert 7 დღე - დეფექტური ალერტი უნდა გამოსწორდეს/წაშლა.
Ownership 100% - თითოეულ ალერტს აქვს მფლობელი და საცავი მისი განმარტებით.

8) ალერტის სასიცოცხლო ციკლი (Alert as Code)

1. შექმენით PR (მიზნის აღწერა, პირობები, runbook, მფლობელი, ტესტის გეგმა).
2. ქვიშის ყუთი/Shadow: ჩრდილის ალერტი წერს ჩეთ/ლოგში, მაგრამ არა პეიჯი.
3. კანარიკა: შეზღუდული აუდიტორია on-call, იზომება FP/TP.
4. პროდი: ჩართვა საბაზო-ლიმიტით + დაკვირვება 2-4 კვირის განმავლობაში.
5. ყოველკვირეული მიმოხილვა: ხარისხის მეტრიკა, კორექტირება/ამოღება.
6. დეპრესია: თუ სიგნალი დუბლირდება უფრო მაღალი ან არა აქტუალურია.

9) სიმწიფის მეტრიკა (აჩვენეთ დაშბორდზე)

Alerts per on-call hour (საშუალო/95-percentil).
% actionable (არსებობს გადადგმული ნაბიჯები) და false-positive rate.
MTTA/MTTR პეიჯების გარშემო და page ticket- ის წილი (არ უნდა იყოს მაღალი).
Top-talkers (სერვისები/წესები, რომლებიც წარმოქმნის 20% ხმაურს).
Mean to fix alert (პირველი FP- დან წესების შეცვლამდე).
Burn-rate coverage: სერვისების წილი SLO ალერტებით ორ ფანჯარაში.

10) სიის „ალერტის ჰიგიენა“

• ალერტი უკავშირდება SLO/SLI ან ბიზნესს/უსაფრთხოებას.
• არის runbook და მფლობელი; ასევე მითითებულია ომის ოთახი.
• ორი ფანჯარა (მოკლე/გრძელი) და წყაროების კვორუმი განლაგებულია.
• შედის დედაპლატა, საბინაო-ლიმიტი, auto-resolve და auto-snooze.
• მითითებულია maintenance ფანჯრები და მხარდაჭერა გამოშვებების/მიგრაციის დროს.
• გაიარა Shadow/Canary; იზომება FP/TP.
• მოხსენება ალერტის ხარისხის მეტრიკებზე.

11) მინი შაბლონები

ალერტის სპეციფიკაცია (YAML იდეა)

yaml id: payments-slo-burn severity: P1 owner: team-payments@sre purpose: "Защитить SLO успеха платежей"
signal:
type: burn_rate sli: payment_success_ratio windows:
short: {duration: 1h, threshold: 5%}
long: {duration: 6h, threshold: 2%}
confirmations:
quorum:
- synthetic_probe: eu,us
- rum: conversion_funnel routing:
page: oncall-payments escalate_after: 5m controls:
dedup_key: "service=payments,region={{region}}"
rate_limit: "1/10m"
auto_snooze_after: "3 pages/1h"
runbook: "rb://payments/slo-burn"
maintenance:
suppress_when: [ "release:payments", "db_migration" ]

Apdate ტექსტი სტანდარტის შესაბამისად (ხმაურის შემცირება)

Импакт: падение success_ratio платежей в EU (-3.2% к SLO, 20 мин).
Диагностика: подтвержден кворумом (EU+US синтетика), RUM — рост отказов на 2 шаге.
Действия: переключили 30% трафика на PSP-B, включили degrade-UX, след. апдейт 20:30.

12) პროცესები: ყოველკვირეული Alert Review

1. ტოპ ხმაურიანი წესები (top-talkers) მარჯვნივ/წაშლა.

2. FP/TP Page სიგნალების საშუალებით, ჩვენ ვასწორებთ ბარიერებს/ფანჯრებს/კვორუმს.

3. არხის შემცირების მსურველები (Page - Ticket) და პირიქით.

4. „დრო Fix-Alert“ სტატუსი - შეფერხებები ესკალირებულია მომსახურების მფლობელებისთვის.

5. შემოწმება SLO ალერტებით და runbook- ის არსებობით.

13) კომუნიკაცია გამოშვებებთან და ოპერაციებთან

გამოშვებების პრეზენტაციებს ავტომატურად ემატება დროებითი ჩახშობა.
Windows Change: გამოშვების შემდეგ პირველ 30 წუთში - მხოლოდ SLO სიგნალები.
Playbooks შეიცავს ნაბიჯს „უსარგებლო ალერტების შემცირება/ჩახშობა“ ფესვზე კონცენტრირებისთვის.

14) უსაფრთხოება და შესაბამისობა

უსაფრთხოების სიგნალები (ჰაკერი/გაჟონვა/არანორმალური წვდომა) - ცალკეული არხები, quiet hours- ის გარეშე.
ყველა ჩახშობის/მშვიდი ფანჯრის აუდიტს: ვინ, როდის, რატომ, ვადა.
კრიტიკული ალარმებისთვის უცვლელი მოთხოვნა (ღონისძიების ხელმოწერა).

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

„თითოეული გრაფიკი = ალერტი“ ზვავი.
ბარიერი „! = 0 შეცდომა“ გაყიდვაში.
ერთი ზონდი/ერთი რეგიონი, როგორც ჭეშმარიტების წყარო.
გვერდი runbook/მფლობელის გარეშე.
მარადიული „დროებითი ჩახშობა“ ვადის გარეშე.
დეფექტური ალერტები „მოგვიანებით გაასუფთავეთ“ - წლების განმავლობაში გროვდება.
გამოშვების ხმაურის შერევა პროდუქტიულ ინციდენტებთან.

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

1. ინვენტარიზაცია: გადმოტვირთეთ ყველა ალერტა, განათავსეთ მფლობელები და არხები.
2. SLO ბირთვი: შემოიღეთ ორმაგი კრიტიკული სერვისების ფანჯრები.
3. ხმაურის კონტროლი: ჩართეთ კვორუმი, დედაპლატი და საბინაო-ლიმიტი, დაიწყეთ შაბათ-მიმოხილვა.
4. Runbook საფარი: 100% Page სიგნალის დახურვა playbucks.
5. ფატიგის პოლიტიკა: პეიჯის/ცვლის ლიმიტები, Quiet Hours, დატვირთვის გადანაწილება.
6. ავტომატიზაცია: Alert-as-Code, Shadow/Canary, მოხსენებები ხარისხის მეტრიკებზე.

17) შედეგი

სიჩუმე არ არის მონიტორინგის ნაკლებობა, არამედ თვისობრივად შემუშავებული სიგნალები, რომლებიც დაკავშირებულია SLO- სთან და პროცესებთან. კვორუმი, ორმაგი ფანჯარა, დედაპლატი და მკაცრი მარშრუტიზაცია ალერტებს იშვიათ, ზუსტი და შესრულებად აქცევს. გუნდი სძინავს, მომხმარებლები კმაყოფილი არიან, ინციდენტები კონტროლდება.