Alerty жана билдирүүлөр: PagerDuty, Opsgenie

Alerty жана билдирүүлөр: PagerDuty, Opsgenie

1) Эмне үчүн өзүнчө платформа alertov

• Тейлөө/тегдер/чөйрөлөр боюнча багыттоо.
• Эскалация жана расписание (нөөмөт, follow-the-sun).
• Дедупликация/корреляция.
• Тынч терезелер (maintenance/freeze) жана мют эрежелери.
• мониторинг менен бириктирүү, CI/CD жана ChatOps.

Колдоо: SLO-босого → alert → адам/автоматтык → runbook → артка/fix → postmortem.

2) Сигнал модели жана олуттуу (severity)

• critical (page) - SLOнун бузулушу/акча жолунун катасы (депозит/чыгарып кетүү), жеткиликтүүлүктүн төмөндөшү, burn-rate.
• high (page/тикет) - так SLO тешиги жок олуттуу деградация.
• medium (тикет) - сыйымдуулугу, бэк деградациясы, ретрациясы.
• low (маалымат) - тренддер, эскертүүлөр.

Эреже: page SLO же ачык бизнес триггер боюнча гана.

3) багыттоо архитектурасы

1. Булак (Prometheus/Alertmanager, Grafana, булут мониторинг, өз Webhucks).
2. Шлюз (PagerDuty/Opsgenie service/integration).
3. Саясат: тегдер боюнча каттамдар ('service', 'env', 'region'), severity, payload.
4. Эскалация: нөөмөт деңгээл ырааттуулугу (L1 → L2 → менеджер).
5. Байланыш: ChatOps каналдары, статус-беттер, жөнөтүү.

Негизги тегдердин үлгүсү (стандартташтыруу)

'service', 'env', 'region', 'version', 'runbook', 'release _ id', 'route', 'tenant' (эгерде B2B/multi-tenant).

4) On-call тартиби жана эскалация

Schedules: primary/secondary, роли (SRE, DBRE, Sec).
Rotations: күндүзгү/түнкү, күн-күн, дем алыш.
Overrides: эс алуу/оору.
Эскалация: ack-убакыт 5-10 мүнөт → кийинки катмар. Иш сааттары боюнча - профилдик бөлүмгө; - on-call аянтча.

Кеңеш: түнкү кыска эскалация кадамдарын (азыраак чарчоо) жана күндүзү узакка созулган (контексти бар).

5) Alertmanager менен бириктирүү (негизги үлгү)

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 (мисалы, service + route + code) колдонуу.
Топ: 'group _ by' кызматы/айлана-чөйрө боюнча, 5xx каскадынын ондогон барактарды пайда кылбашы үчүн.
Мьют/тынч терезелер: миграция/релиздер/жүктөө тесттери учурунда.
Suppression себеби: буга чейин P1 окуясы 'api-gateway @prod' үчүн болсо, туунду P2/P3 басуу.

Анти-үлгү: SLO боюнча тастыкталган таасири жок CPU/Memory боюнча пейдж.

7) Releases жана auto-аракет менен байланыш

PagerDuty/Opsgenie канареялык деплейлерде алар SLO-гейтинен алерт алышат → webhook в CI/CD → pause/rollback (Argo Rollouts/Helm).
Alert камтыйт: 'release _ id', 'image. tag ', pipline шилтеме жана runbook кадам кайра.

Мисал runbook шилтемелер аннотациялар

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

8) ChatOps жана байланыш

Slack/Teams-жылы Auto-түзүү окуя канал, тикет байлап.
Slash-команды: `ack`, `assign @user`, `status set`, `postmortem start`.
Статус-бет: P1/P2 автоматтык түрдө жаңыртуу.

9) Окуя жашоо цикли (минималдуу)

1. Trigger (SLO/сенсорлордун алерт).
2. Page (primary on-call).
3. Ack (ырастоо, TTA).
4. Communicate (канал/статус).
5. Mitigate (rollback/feature-flag/изоляция).
6. Resolve (TTR).
7. Postmortem (таймлайн, себептер, иш-аракеттер, сабактар, тапшырмалардын ээси).

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

10) Paiload пайдалуу талаалар (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 - dashboard/бизнес-метр үчүн жеңил.
OpenTelemetry/SpanMetrics - каттамдар боюнча latency/error.
K8s-окуялар - кырсык кластер (control-plane, PDB бузуулар).
BD/кезек - lag/locks/replication.
Webhook колдонмолор - домендик сигналдар (PSP ката, Frode жарк).

12) Саясат жана комплаенс

RBAC түзүү/саясат өзгөртүү, расписание, музыка.
Аудит: ким тааныган/дайындаган/статусун өзгөрткөн, таймстемптер.
PII-pailoads минималдаштыруу (колдонуучунун электрондук почта/телефон ордуна ID билети).
DR-план: PagerDuty/Opsgenie (fallback канал) жеткиликсиз болгондо эмне кылабыз.

13) Практикалык мисалдар (PagerDuty vs Opsgenie)

14) Тынч терезелер жана үшүк

Freeze: P1 гана калтырып, пландаштырылган чыгаруу терезелерде пейджинг тыюу.
'env = stage', 'region = dr', 'service = batch' деп аталат.
Убактылуу mute: DD/stresstestah көчүп жатканда - ачык ээси менен.

15) натыйжалуулугун Метрика (SRE/DORA Алерт үчүн)

MTTA/MTTR (командалар/кызматтар/сменалар боюнча).
runbook менен Алерт% (максаты ≥ 95%).
SLO боюнча page-алерттердин үлүшү (максаты ≥ 90%).
Ratio пайдалуу/ызы-чуу (максаты ≥ 3:1).
% autosports (веб-хук аркылуу pause/rollback) - өстүрүү.
14/30 күндүн ичинде Burn-down postmortem action items.

16) Анти-үлгүлөрү

"Темир" боюнча Пейдж (CPU, диск) колдонуучуга таасир этпейт.
Жок 'group _ by' → "бороон" alertov.
Тынч терезелер жок - релиздер баарын кызыл менен боёйт.
Pailoads жок 'service/env/runbook' - багыттоо/иш-аракет кылуу мүмкүн эмес.
severity жана эрежелердин бирдиктүү шкаласы жок (ар бир булак - өз жолу менен).
Эч ким оңдобогон "түбөлүк" эскертүүлөр (алерт-карыз).

17) киргизүү чек-тизмеси (0-45 күн)

0-10 күн

Сүйүү шкаласын макулдашуу жана тегтерди/аннотацияларды стандартташтыруу.
PagerDuty/Opsgenie кызматтарын түзүү, schedules жана негизги эскалацияларды орнотуу.
Alertmanager/Grafana байлап, 'group _ by' жана дедуп кирет.

11-25 күн

SLO-Алерт (multi-window burn) киргизүү, runbook шилтемелерди кошуу.
ChatOps орнотуу: Автомагистралдар, ack/assign буйруктары.
бошотуу/көчүрүү боюнча тынч терезелерди күйгүзүү.

26-45 күн

кошуу auto-pause/rollback үчүн канарейка (Webhuke).
MTTA/MTTR жана allert гигиена отчетторун киргизүү (ызы-чуу тазалоо).
Стандартташтыруу postmortem жана контролдоо action items.

18) Даяр сниппеттер

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 from alert → 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 багытталган стратификация, компетенттүү багыттоо жана эскалация, бирдиктүү теги жана pailoads, тынч терезелер, ChatOps жана автоматтык аракеттер (пауза/rollback). Бюджет жана UX боюнча PagerDuty же Opsgenie тандоо, бирок ошол эле ызы-чуу, милдети жана жоопкерчилик эрежелерин кармануу - анда пейдж сейрек, так жана пайдалуу болот, ал эми окуялар - кыска жана башкарылуучу.