სიგნალებისა და შეტყობინებების სისტემა

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

სიგნალის სისტემა არ არის „შეტყობინებების გაგზავნა“, არამედ გადაწყვეტილების მიღების კონტური: იგი დროულად ანათებს გადახრებს, გთავაზობთ მოქმედებებს და აკმაყოფილებს ბალანსს დროულ და დუმილს შორის.

• შეამცირეთ MTTD/MTTR პრიორიტეტიზაციისა და მკაფიო ფლეიბუკების გამო.
• ხმაურის შემცირების გზით შეამცირეთ ალერტ ფატიგუ (შეტყობინებების დაღლილობა).
• მისცეს მოქმედებები პირდაპირ შეტყობინებიდან (ack, snooze, runbook, ავტო მოქმედება).
• დაიცავით კონფიდენციალურობა და თანხმობა (opt-in/opt-out, ლოგოს შენახვა).

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

2. 1 მოვლენების ტიპები

მეტრიკა/ანომალიები (SRE, პროდუქტი, ფინანსები).
ბიზნეს წესები (შეზღუდვები, ფროდი, KYC, გადახდები).
სისტემური (დეგრადაცია, დეგრადაცია, ლიცენზია).
მომხმარებლის (ქცევითი გამომწვევები, RG/საპასუხისმგებლო თამაში).

2. 2 მნიშვნელოვნების დონე

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

2. 3 პრიორიტეტი

მატრიცა 'Impact × Urgency' P1.. P4. არხები და SLA რეაქციები.

3) არქიტექტურა და ნაკადები

სიგნალის მწარმოებლები - მოვლენების შინა - ნორმალიზაცია (Enrich, dedup) - კორელაცია - წესები (პოლიტიკა ძრავა), მარშრუტის გადაზიდვა, მიწოდების არხები და პრეფერენციების ცენტრი - Loga/Analytics.

• Enricher: დასძენს ჩრდილს, როლს, რეგიონს, ბმულებს პლეიბუკებზე.
• Deduper: გაიმეორეთ განმეორებითი მოვლენები.
• Correlator: შეავსეთ დაკავშირებული სიგნალები ინციდენტში.
• Policy Engine: YAML/DSL წესები, quiet hours, ესკალაცია.
• Delivery: app, email, push, SMS, webhook, ჩატის ინტეგრაცია.

4) წესები და პოლიტიკა (მაგალითი YAML)

yaml policies:
- id: p_sre_critical match: { domain: "infra", severity: "critical" }
route:
primary: { channel: "pager", targets: ["oncall_sre"] }
fallback: { channel: "sms", delay: "2m" }
suppress:
flapping: {window: "10m," threshold: 5} # suppressing frequent twitching duplicates: {key: ["service, ""cluster,"" error _ code"], ttl: "15m"}
escalate:
after: "10m"
to: ["sre_manager"]
auto_assign: true
- id: p_product_medium match: { domain: "product", severity: "medium", kpi: "conversion" }
route:
primary: { channel: "inapp", audience: "product_owners" }
digest:
window: "1h"
max_items: 10 quiet_hours:
tz: "Europe/Kyiv"
ranges: ["22: 00-07: 00"] # only P1 digests/pager at this time

5) დედუპლიკაცია, კორელაცია, ფუფუნების ჩახშობა

დედოპი: ჯგუფის იდენტიფიკატორი 'dedup _ key = hash (სერვისი' metric 'dim)'; TTL არის ფუფუნების ფანჯარა.
კორელაცია: დააკავშიროთ დაკავშირებული სიგნალები ტოპოლოგიის (დამოკიდებულების სერვისი), დროის (± N წთ) და კონტექსტის (გამოშვება, ინციდენტი) შესახებ.
Flapping: „N მოვლენების ბარიერები M წუთში“ - ერთი „flapping detectected“ სიგნალი, რომლის შეთავაზებაა ჰისტერეზის ან სუპერპროდის ამაღლება.

6) მარშრუტიზაცია და RACI

Responsible: ვინ იღებს პირველ შეტყობინებას/ტასკს.
Accountable: ვინ არის ესკალაცია SLA- ს შემდეგ.
Consulted: ვინ უნდა აღინიშნოს ძაფში/ჩატის არხში.
Informed: ვინ დატოვებს დაიჯესტს/შედეგებს.
დანიშნეთ როლისა და კონტექსტის მიხედვით (ტენანტი, რეგიონი, პროდუქტი-ნაკადი).

7) მიწოდებისა და ნიუანსების არხები

Retrai: 5xx/429/timaut - backoff + jitter; 'Retry-After' პატივისცემა. Idempotence: „X-Notification-Id“ ვებჰუკებზე.

8) პრეფერენციების ცენტრი

Opt-in/Opt-out მოვლენების ტიპების, დონის, არხების მიხედვით.
დუმილის გრაფიკი (quiet hours), სახელმძღვანელო snooze 15/30/60.
ზღურბლს/მგრძნობელობას (მაგალითად, ანომალია - 3).
ენა/ლოკალი, დრო/ვალუტის ფორმატი.
როლების ბმული: პრესეტები SRE/Product/Finance.
გამჭვირვალობა: იმის ჩვენება, თუ რატომ მიიღო მომხმარებელმა სიგნალი (ბმული წესზე).

9) შინაარსის დიზაინი: შეტყობინებების სტრუქტურა

• სათაური: მოკლედ, ტრიგერით: „[P1] [PSP _ TR] უარის თქმის მკვეთრი მატებაა 3DS (+ 12%)“.
• კონტექსტი: სეგმენტების/რეგიონის მიერ დაზარალებული პერიოდი, მონაცემთა წყარო.
• მიზეზი/ჰიპოთეზა: „უკავშირდება PSP _ X 18:20 UTC- ს გამოშვებას“.
• SLA/ვადა: „ესკალაცია 10 წუთის შემდეგ“.
• CTA: „გახსენით ფლეიბუკი“, „ჩართეთ fallback PSP _ Y“, „Ack (30 წთ)“.
• ბმულები: გრაფიკი, ინციდენტი-ძაფი, მეტრიკა, runbook.
• მეტამონაცემები: 'trace _ id', 'incident _ id', 'dedup _ key'.

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

10) მოქმედებები შეტყობინებებიდან

Ack/Snooze დროის პარამეტრებით.
Assign/Invite ინციდენტის ნაწილში.
Runbook: გახსნათ გადაწყვეტილებების ნაბიჯები კონტექსტის შევსებით.
One-click remediation (სადაც უსაფრთხოა): გადართეთ მარშრუტი, აიღეთ ლიმიტი, განაახლეთ ჯობა (დადასტურებით და აუდიტით).
შექმენით ticet (Jira/GitHub) საველე ავსებით.

11) სიგნალების ხარისხი: მეტრიკა და მიზნები

Precision (გაგზავნილ პირთა შორის შესაბამისი წილი) 80% -ს შეადგენს P1/P2- სთვის.
Recall (ყველა ინციდენტის წილი) 70% -ს შეადგენს.
ხმაური: მომხმარებლის საშუალო სიგნალები/საათი (სამიზნე ჭერი).
Ack-time p50/p95, Escalation rate, Snooze rate (როგორც ხმაურის ინდიკატორი).
MTTD/MTTA/MTTR (დომენებისა და არხების ჭრილში).
Silenced-but-should-alert (გამოტოვება წესების გამო) ცალკე დაშბორდია.

12) ხმაურის მართვა: ხრიკები

ჰისტერეზი და „მოცურების ფანჯრები“ რეიდებისთვის.
სიფრთხილე (EWMA) გამოვლენამდე.
აგრეგაცია: 30 მცირე ზომის ნაცვლად - ერთი ჯოხი/დაიჯესტი საუკეთესო ანაზღაურებით.
კონტექსტური ლიმიტები: არაუმეტეს N შეტყობინებები/საათი/არხი/მომხმარებელი.
მანქანის უკუკავშირი: თუ 3 × ზედიზედ მომხმარებელი დააჭერს Snooze- ს და შესთავაზებს ბარიერის გაზრდას/არხის შეცვლას.

13) უსაფრთხოება, კონფიდენციალურობა, შესაბამისობა

HMAC ხელმოწერა ვებჰუკებისთვის, საიდუმლოებების როტაცია, 'X-Key-Id'.
RBAC/ABAC: სიგნალების ხილვადობა როლების/ტენანტების მიხედვით.
PII მინიმიზაცია, ნიღბები ლოგებში, მოქმედების აუდიტი (ack/assign/runbook).
თანხმობა (თანხმობა) და შეტყობინების მიზეზები (წესი/პოლიტიკა) - payload- ში.
Retention/TTL შეტყობინებების ლოგოები, Legal Hold ინციდენტებისთვის.

14) სქემები და payload 'y

მოვლენა (შიდა)

json
{
"id": "sig_01HX",
"domain": "payments",
"severity": "high",
"priority": "P2",
"title": "The 3DS failure graph has grown to 8. 2% (+3. 1 pp), "
"occurred_at": "2025-11-03T17:55:00Z",
"context": { "psp": "PSP_X", "country": "TR", "release_id": "rel_241103_1820" },
"metrics": { "baseline": 5. 1, "current": 8. 2, "delta_pp": 3. 1 },
"dedup_key": "payments    PSP_X    TR    3DS_FAILURE",
"runbook": "rbk_psp_3ds_spike",
"slo": { "ack_deadline_sec": 600 }
}

შეტყობინება (აგნოსტიკური არხი)

json
{
"notification_id": "ntf_91ab",
"signal_id": "sig_01HX",
"targets": ["oncall_payments"],
"channels": ["inapp","slack","webhook"],
"cta": [
{"id": "ack," "label": "Confirm (30 min)," "payload": {"ttl ":" 30m"}},
{"id": "runbook," "label": "Open playbook," "payload": {"id ": "rbk _ psp _ 3ds _ spike"}},
{"id": "fallback," "label": "Enable fallback, PSP_Y" "confirm": true}
],
"hmac": "sha256=AbCd..."
}

15) UX ნიმუშები პროდუქტში

Inbox: ჩანართები Critical/High/Other, Badges რაოდენობა.
ინციდენტის ფირზე: კორელირებული სიგნალები, მოქმედების დრო, „რა გაკეთდა“.
ფილტრები: როლი, დომენი, რეგიონი, დრო, „მხოლოდ უპასუხოდ“.
სწრაფი მოქმედებები სიაში (ack/snooze/assign).
Explain: „რატომ ხედავთ ამას“ (წესი, ბარიერები, მონაცემები).
დაიჯესტები: დილა/საღამო, ლოკალიზებული TZ- ით.

16) ტესტის გეგმა

Unit: დედაპლატის გასაღებები, ჰისტესეზი, flapping, payload სერიალიზაცია.
Integration: მარშრუტიზაცია, quiet hours, ესკალაცია, არხის რელიეფი.
E2E: P1 სცენარი ანომალიიდან თიკეტის დახურვამდე; P2 quiet hours- ში.
ქაოსი: არხის დაკარგვა (SMTP/SMS), შეფერხებები, სიგნალის ზვავი, კლოკის ციკლი.
A11y/i18n: screen-readers, კლავიატურა ack/snooze, რიცხვების/თარიღების ლოკალიზაცია.

17) Dashbords ხარისხის

Precision/Recall დომენების მიხედვით.
Ack time p50/p95 და წილი დროულად დადასტურებულია.
Noise per user/hour და ხმაურიანი წესები.
ესკალაცია და „ყალბი ესკალაცია“.
Suppressed vs Delivered (რამდენი თრგუნავს/შემცირებულია თხრილში).
მომხმარებელი feedback :/შეტყობინებები, ხმაურის კომენტარები.

18) ჩეკის ფურცლები

დიზაინი

• მოვლენების ტაქსონომია და დონეები შეთანხმებულია
• quiet hours/ესკალაციების პოლიტიკოსები
• დედაპი/კორელაცია/ფუფუნება
• არხები, რეტრაები, ვებჰუკების იდემპოტენტურობა
• პრეფერენციების ცენტრი (opt-in/out, snooze)
• შინაარსის შაბლონები და ლოკალიზაცია
• playbooks და on- click მოქმედებები (აუდიტით)
• ხარისხის და დაშბორდის მეტრიკა

ოპერაცია

• ბარიერი ოპტიმიზაცია კვარტალში ერთხელ
• A/B წესები (ბარიერი, ფანჯრები, digest)
• რეგულარული მიმოხილვები „ტოპ ხმაური“ და CAPA
• არხების საიდუმლოებების როტაცია (HMAC, SMTP, SMS)
• განგაშის ტესტი

19) განხორციელების გეგმა (3 გამეორება)

გამეორება 1 - ძირითადი წრე (2-3 კვირა)

ტაქსონომია, severity/priority, პრეფერენციების ცენტრი (in-app + email).
Dedup, მარტივი კორელაცია კლავიშზე/დროში, quiet hours.
შეტყობინებების შაბლონები, playbuks, ack/snooze/assign.

გამეორება 2 - საიმედოობა და ხმაურის შემცირება (3-4 კვირა)

Flapping/histeresis, dajests, chat ინტეგრაცია და ვებჰუკი (HMAC, retrai).
ესკალაცია SLA- ს მიხედვით, ხარისხის დაშლა (precision/recall, ხმაური).
One-click remediation (დადასტურებით და აუდიტით).

გამეორება 3 - ოპტიმიზაცია და მასშტაბები (მუდმივად)

კორელაცია ტოპოლოგიაში/რელიზებზე, რეიდების მანქანების შეთავაზება.
A/B წესები, პროგნოზი „როდესაც ბარიერი იმუშავებს“.
ხმაურის მიმოხილვები და რეგულარული თამაშები.

20) მინი-FAQ

როგორ გავუმკლავდეთ alert fatigue- ს?
დედოპი, კორელაცია, ჰისტერეზი, დაიჯესტები და პრეფერენციების ცენტრები + რეგულარული ხმაურის მიმოხილვები და A/B რეიდები.

საჭიროა ML ანომალიებისთვის?
სასარგებლოა, მაგრამ დაიწყეთ დეტერმინისტული წესებით და გასაგები რეიდებით. ML - როგორც სუპერსტრუქტურა, აუცილებლად Explain- ით.

რატომ იღებენ მომხმარებლები „დამატებით“ წერილებს?
შეამოწმეთ წესების მატჩები, quiet hours, აუდიტი „რატომ არის მიწოდებული“, არხის/საათის შეზღუდვები და დაიჯესტები.

შედეგი

ძლიერი სიგნალის სისტემა არის ჭკვიანი ფილტრაცია და სწორი პრიორიტეტიზაცია + ერთ დაჭერით. ჩამოაყალიბეთ ტაქსონომია და პოლიტიკოსები, გააცნეთ დედაპლატი/კორელაცია/ჰისტერეზი, მიეცით მომხმარებლებს კონტროლი (პრეფერენციები, სნოზა), უზრუნველყონ საიმედო მიწოდება და გამჭვირვალობა „რატომ მივიღე ეს“. შემდეგ სიგნალები გახდება საკონტროლო ინსტრუმენტი და არა ხმაურის წყარო.