ალერტები და შეტყობინებები: PagerDuty, Opsgenie

ალერტები და შეტყობინებები: PagerDuty, Opsgenie

1) რატომ არის ალერტის ცალკეული პლატფორმა

• მარშრუტიზაცია სერვისებზე/ტეგებზე/გარემოზე.
• ესკალაცია და გრაფიკი (მოვალეობა, follow-the-sun).
• დედუპლიკაცია/მოვლენების კორელაცია.
• მშვიდი ფანჯრები (maintenance/freeze) და Myut წესები.
• მონიტორინგთან ინტეგრაცია, CI/CD და ChatOps.

მხარდაჭერა: SLO ბარიერი - ალერტის ბარიერი - ადამიანი/ავტომატი - runbook - გამოტოვება/ფიქსი პოსტმორტით.

2) სიგნალის მოდელი და სერიოზულობა

• critical (page) - SLO- ს დარღვევა/ფულადი გზის შეცდომა (ანაბარი/გამომავალი), წვდომის ვარდნა, burn-rate.
• high (page/tiket) მნიშვნელოვანი დეგრადაციაა აშკარა SLO ავარიის გარეშე.
• medium (ticet) - კონტეინერი, ბეკის დეგრადაცია, retrai.
• დაბალი (ინფო) - ტენდენციები, გაფრთხილებები.

წესი: page მხოლოდ SLO ან აშკარა ბიზნეს გამომწვევი.

3) მარშრუტიზაციის არქიტექტურა

1. წყარო (Prometheus/Alertmanager, Grafana, ღრუბლის მონიტორინგი, საკუთარი ვებჰუკები).
2. Шлюз (PagerDuty/Opsgenie service/integration).
3. პოლიტიკოსები: ტეგების მარშრუტები ('სერვისის', 'env', 'region'), severity, payload.
4. ესკალაცია: მორიგე დონის თანმიმდევრობა (L1 - L2 - მენეჯერი).
5. კომუნიკაციები: ChatOps არხები, სტატუსის გვერდები, შეტყობინებები.

საკვანძო ჭდეების მაგალითი (სტანდარტიზებული)

'სერვისი', 'env', 'region', 'version', 'runbook', 'release _ id', 'route', 'tenant' (თუ B2V/მულტფილმის ტენანტი).

4) გრაფიკი და ესკალაცია

Schedules: primary/secondary, роли (SRE, DBRE, Sec).
Rotations: დღე/ღამე, follow-the-sun, შაბათ.
Overrides: შვებულება/დაავადება.
ესკალაცია: ack-taimaut 5-10 წუთი - შემდეგი ფენა. სამუშაო საათებში - პროფილის განყოფილებაში; გარეთ - პლატფორმა.

რჩევა: ღამით მოკლე ესკალაციის ნაბიჯები (ნაკლები დაღლილობა) და დღისით გრძელი (არსებობს კონტექსტი).

5) ინტეგრაცია ალერტმანაგერთან (ძირითადი ნიმუში)

yaml receivers:
- name: pagerduty pagerduty_configs:
- routing_key: ${PAGERDUTY_ROUTING_KEY}
severity: '{{ if eq. Labels. severity "critical" }}critical{{ else }}error{{ end }}'
class: '{{.Labels. service }}'
component: '{{.Labels. env }}'
group: '{{.Labels. region }}'
description: '{{.Annotations. summary }}'
details:
service: '{{.Labels. service }}'
env: '{{.Labels. env }}'
runbook: '{{.Annotations. runbook }}'
release: '{{.Annotations. release }}'
route:
receiver: pagerduty group_by: ["service","env","region"]
group_wait: 30s group_interval: 5m repeat_interval: 2h

Opsgenie (webhook)

yaml receivers:
- name: opsgenie opsgenie_configs:
- api_key: ${OPSGENIE_API_KEY}
responders:
- name: "SRE Primary"
type: team priority: '{{ if eq. Labels. severity "critical" }}P1{{ else }}P3{{ end }}'
details:
trace: '{{.Labels. trace_id }}'
runbook: '{{.Annotations. runbook }}'

6) ხმაური, დედობა და კორელაცია

დედაპლატის გასაღები: გამოიყენეთ სტაბილური fingerprint (მაგალითად, მომსახურება + მარშრუტი + კოდექსი).
ჯგუფი: 'ჯგუფი _ by' მომსახურებით/გარემოთი ისე, რომ 5xx კასკადი არ წარმოქმნას ათეულობით გვერდს.
შუქები/მშვიდი ფანჯრები: მიგრაციის/გამოშვებების/დატვირთვის ტესტების დროს.
Suppression იმის გამო: თუ ინციდენტი P1 უკვე მიმდინარეობს 'app-gateway @', თრგუნავთ ქალიშვილებს P2/P3.

ანტი პატრონი: CPU/Memory Page, SLO- ზე დადასტურებული გავლენის გარეშე.

7) კომუნიკაცია გამოშვებებთან და ავტო მოქმედებებთან

კანარის ამოფრქვევით, PagerDuty/Opsgenie იღებს ალერტს SLO კარიბჭედან - webhook CI/CD/pause/rollback (Argo Rollouts/Helm).
ალერტი შეიცავს: 'release _ id', 'image. tag ', ბმული pline და runbook გამოტოვების ნაბიჯი.

runbook ბმულის მაგალითი

runbook: https://runbooks. company/rollback/api-gateway#canary

8) ChatOps და კომუნიკაციები

ინციდენტის არხის შექმნა Slack/Teams- ში, თიკეტთან დაკავშირება.
Slash-команды: `ack`, `assign @user`, `status set`, `postmortem start`.
სტატუსის გვერდი: ავტომატური განახლება P1/P2.

9) ინციდენტის სასიცოცხლო ციკლი (მინიმალური)

1. Trigger (ალერტი SLO/სენსორიდან).
2. Page (primary on-call).
3. აკი (დადასტურება, TTA).
4. კომუნიკაცია (არხი/სტატუსი).
5. Mitigate (rollback/feature-flag/იზოლაცია).
6. Resolve (TTR).
7. Postmortem (დრო, მიზეზები, მოქმედებები, გაკვეთილები, დავალებების მფლობელი).

Role-kit: IC (incident commander), Ops lead, Comms, Scribe.

10) Payload სასარგებლო ველები (normalize)

json
{
"service": "payments-api",
"env": "prod",
"region": "eu-central-1",
"severity": "critical",
"event_class": "slo_burn",
"summary": "Withdraw 5xx > 0. 5% for 10m",
"runbook": "https://runbooks/payments/withdraw-5xx",
"release_id": "rel-2025-11-03-14-20",
"image": "ghcr. io/org/payments:1. 14. 2",
"trace_id": "8a4f0c2e9b1f42d7",
"annotations": { "canary": "25%" }
}

11) სიგნალის წყაროების ინტეგრაცია

Prometheus/Alertmanager არის SLO/RED- ის მთავარი წყარო.
Grafana Alerting უფრო ადვილია დაშბორდებისთვის/ბიზნეს მეტრიკისთვის.
OpenTelemetry/Security Metrics - latency/error მარშრუტებზე.
K8s მოვლენები - კლასტერის უბედური შემთხვევა (კონტროლი-თვითმფრინავი, PDB დარღვევები).
BD/რიგები - lag/locks/replication.
აპლიკაციების ვებჰუკი - დომენის სიგნალები (PSP შეცდომა, frod- ის ზრდა).

12) პოლიტიკა და შესაბამისობა

RBAC პოლიტიკოსის, გრაფიკის, სისულელეების შექმნაზე/შეცვლაზე.
აუდიტი: ვინ აღიარა/დანიშნა/შეცვალა სტატუსი, დრო.
PII მინიმიზაცია payloads- ში (მომხმარებლის ელ.ფოსტის/ტელეფონის ნაცვლად).
DR გეგმა: რას ვაკეთებთ PagerDuty/Opsgenie არხის მიუწვდომლობით.

13) პრაქტიკის მაგალითები (PagerDuty vs Opsgenie)

14) მშვიდი ფანჯრები და ყინვები

Freeze: პეიჯინგის აკრძალვა დაგეგმილ გამოშვების ფანჯარაში, დატოვა მხოლოდ P1.
Service = batch ',' region = dr ',' service = batch '.
დროებითი მუტი: BD/დატვირთვის მიგრაციის დროს - აშკარა მფლობელთან.

15) შესრულების მეტრიკა (SRE/DORA ალერტებისთვის)

MTTA/MTTR (ბრძანებების/სერვისების/ცვლების თვალსაზრისით).
% ალერტები runbook- ით (მიზანი 95%).
სურათის ალერტების წილი SLO- ში (მიზანი 90%).
Ratio სასარგებლო/ხმაურიანი (მიზანი - 3:1).
ავტომობილების% (pause/rollback ვებჰუკის საშუალებით) - ზრდა.
Burn-down postmortem მოქმედების items 14/30 დღეში.

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

„რკინის“ გვერდი (CPU, დისკი) მომხმარებელზე გავლენის გარეშე.
"ჯგუფის _ by '- ის" ქარიშხლის "არარსებობა.
არ არის მშვიდი ფანჯრები - გამოშვებები ხატავს ყველაფერს წითლად.
Payloads 'service/env/runbook' - შეუძლებელია მარშრუტირება/მოქმედება.
არ არსებობს ერთიანი მასშტაბები და წესები (თითოეული წყარო საკუთარი გზით).
„მარადიული“ გაფრთხილებები, რომელსაც არავინ ასრულებს (ალერტ-ვალი).

17) განხორციელების სიის სია (0-45 დღე)

0-10 დღე

კოორდინაცია გაუწიეთ მასშტაბს და სტანდარტიზდება ჭდეები/სურათები.
შექმენით სერვისები PagerDuty/Opsgenie- ში, ჩამოაყალიბეთ schedules და ძირითადი ესკალაციები.
მიბმული Alertmanager/Grafana, ჩართეთ 'group _ by' და დედაპლატი.

11-25 დღე

შეიყვანეთ SLO ალერტები (მრავალჯერადი ფანჯრის ბურნი), დაამატეთ ბმული runbook.
ChatOps- ის კონფიგურაცია: ავტო არხები, ack/assign ბრძანებები.
ჩართეთ მშვიდი ფანჯრები გამოშვებების/მიგრაციისთვის.

26-45 დღე

ინტეგრირებული მანქანა/rollback კანარებისთვის (ვებჰუკი).
შეიყვანეთ MTTA/MTTR და ალერტ ჰიგიენის ანგარიშები (ხმაურის გაწმენდა).
პოსტმორტის სტანდარტიზაცია და მოქმედების კონტროლი.

18) მზა snippets

Grafana Alerting PagerDuty (JSON body mapping)

json
{
"routing_key": "${PAGERDUTY_ROUTING_KEY}",
"event_action": "trigger",
"payload": {
"summary": "{{.RuleName }}: {{ index. Labels \"service\" }}",
"severity": "{{ if eq (index. Labels \"severity\") \"critical\" }}critical{{ else }}error{{ end }}",
"source": "grafana",
"component": "{{ index. Labels \"env\" }}",
"group": "{{ index. Labels \"region\" }}"
},
"links": [
{ "href": "{{.DashboardURL }}", "text": "Dashboard" },
{ "href": "{{ index. Labels \"runbook\" }}", "text": "Runbook" }
]
}

Webhook ალერტიდან Argo Rollouts pause

bash curl -X POST "$ARGO_API/rollouts/pause" \
-H "Authorization: Bearer $TOKEN" \
-d '{"name":"api-gateway","namespace":"prod"}'

Opsgenie - Routing Rule (ფსევდო)

yaml if:
tags: ["service:payments","env:prod"]
severity: ["P1","P2"]
then:
route_to: "SRE-Payments"
notify: ["Primary OnCall","Secondary"]

19) დასკვნა

ალერტების ძლიერი წრე არის + დისციპლინის პროცესი: SLO ორიენტირებული სტრატიფიკაცია, კომპეტენტური მარშრუტიზაცია და ესკალაცია, ერთიანი ჭდეები და payloads, მშვიდი ფანჯრები, ChatOps და ავტომატური მოქმედებები (pause/rollback). შეარჩიეთ PagerDuty ან Opsgenie ბიუჯეტის და UX, მაგრამ დაიცავით იგივე ხმაურის, მოვალეობების და პასუხისმგებლობის წესები - მაშინ პეიჯი იშვიათი, ზუსტი და სასარგებლო იქნება, ხოლო ინციდენტები მოკლე და კონტროლირებადი იქნება.