Wpisy i powiadomienia: PagerDuty, Opsgenie

Wpisy i powiadomienia: PagerDuty, Opsgenie

1) Dlaczego oddzielna platforma wpisów

• Routing według usług/tagów/środowisk.
• Eskalacja i harmonogram (dyżur, follow-the-sun).
• Deduplikacja/korelacja zdarzeń.
• Ciche okna (konserwacja/zamrażanie) i zasady muzyki.
• Integracja z monitoringiem, CI/CD i ChatOps.

Wsparcie: SLO-threshold → alert → osoba/maszyna → runbook → rollback/fix → postmortem.

2) Model sygnału i ciężkość

• krytyczny (strona) - naruszenie SLO/błąd ścieżki pieniężnej (depozyt/wypłata), spadek dostępności, oprocentowanie.
• wysoka (strona/bilet) - znacząca degradacja bez oczywistego załamania SLO.
• średni (bilet) - pojemność, degradacja pleców, przekaźnik.
• niskie (informacja) - trendy, ostrzeżenia.

Reguła: strona przez SLO lub tylko wyraźny wyzwalacz biznesowy.

3) Architektura routingu

1. Źródło (Prometheus/Alertmanager, Grafana, monitoring chmury, własne haki internetowe).
2. Клин (PagerDuty/Opsgate service/integration).
3. Zasady: trasy według tagów („usługa”, „na”, „region”), dotkliwość, ładunek.
4. Eskalacja: kolejność poziomów służby (L1 → L2 → menedzher).
5. Komunikacja: kanały ChatOps, strony stanu, mailingi.

Przykład znaczników kluczowych (standaryzuj)

„usługobiorca”, „,” region „,” wersja „,” runbook „,” release _ id', „trasa”, „najemca” (jeżeli B2B/wielopoziomowy).

4) Harmonogram dyżurów i eskalacji

Harmonogram: pierwotny/wtórny, рола (SRE, DBRE, Sec).
Obroty: dzień/noc, follow-the-sun, weekend.
Nadjazdy: Urlop/choroba.
Eskalacja: ack-timeout 5-10 min → następna warstwa. Przez godziny pracy - do działu profilu; na zewnątrz - platforma dyżurna.

Wskazówka: Zachować krótkie kroki eskalacji w nocy (mniej zmęczenia), a dłużej w ciągu dnia (jest kontekst).

5) Integracja z Alertmanager (podstawowy wzór)

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) Hałas, deadup i korelacja

Klucz Dedup: użyj stabilnego odcisku palca (na przykład usługi + trasa + kod).
Grupowanie: 'group _ by' przez serwis/środowisko, dzięki czemu kaskada 5xx nie spawn dziesiątki stron.
Mutes/ciche okna: podczas migracji/zwolnień/testów obciążenia.
Tłumienie z jakiegoś powodu: jeśli istnieje już incydent P1 dla 'api-gateway @ prod', tłumić P2/P3 dziecka.

Anty-wzór: Strona przez procesor/pamięć bez potwierdzenia wpływu na SLO.

7) Połączenie z zwolnieniami i automatycznymi akcjami

Z depresją kanaryjską, PagerDuty/Opsgenie otrzymać alert z bramy SLO → webhook w CI/CD → pauza/rollback (Argo Rollouts/Helm).
Alert zawiera: 'release _ id',' image. znacznik ", odniesienie do rurociągu i książeczki startowej.

Przykład linku do książki startowej w adnotacjach

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

8) Chatopy i komunikacja

Automatyczne tworzenie kanału incydentu w Slack/Teams, łącząc się z biletem.
Slash-команна: 'ack', 'assign @ user', 'status set', 'postmortem start'.
Strona statusu - Aktualizacje automatycznie na P1/P2.

9) Cykl życia incydentu (minimum)

1. Wyzwalacz (alert ze SLO/czujników).
2. Strona (podstawowy dyżur).
3. Ack (potwierdzenie, TTA).
4. Komunikacja (kanał/stan).
5. Zminimalizuj (rollback/feature-flag/isolation).
6. Rozstrzygnięcie (TTR).
7. Postmortem (linia czasu, powody, działania, lekcje, właściciel zadania).

Zestaw ról: IC (dowódca incydentu), ołów operacyjny, Comms, Scribe.

10) Pola ładunkowe (normalizacja)

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) Integracja źródeł sygnału

Prometheus/Alertmanager jest głównym źródłem SLO/RED.
Grafana Alerting jest łatwiejszy dla desek rozdzielczych/mierników biznesowych.
OpenTelemetry/SpanMetrics - opóźnienie/błąd na trasie.
K8s zdarzenia - awarie klastra (sterownik, naruszenia PDB).
DB/Kolejki - lag/locks/replication.
Webhaki aplikacji - sygnały domeny (błąd PSP, przepięcie oszustwa).

12) Polityka i zgodność

RBAC do tworzenia/modyfikowania zasad, harmonogramów, mutas.
Audyt: kto rozpoznał/wyznaczył/zmienił status, znaczniki czasowe.
Minimalizacja PII w ładunkach (identyfikator biletu zamiast e-maila/telefonu użytkownika).
DR-plan: co robimy, gdy PagerDuty/Opsgenie jest niedostępny (kanał awaryjny).

13) Case Studies (PagerDuty vs Opsgenie)

14) Ciche okna i mrozy

Zamrażanie: Zakaz przywoływania w planowanych oknach wydania, pozostawiając tylko P1.
Zapamiętanie tagu: '= etap', 'region = dr', 'service = batch'.
Tymczasowa muta: podczas migracji baz danych/testów obciążenia - z wyraźnym właścicielem.

15) Wskaźniki wydajności (SRE/DORA dla wpisów)

MTTA/MTTR (w podziale na zespoły/usługi/zmiany).
% wpisów z książką startową (cel ≥ 95%).
Udział wpisów stron według SLO (cel ≥ 90%).
Stosunek użyteczności do hałasu (cel ≥ 3:1).
% akcji automatycznych (pauza/rollback poprzez webhook) - rośnie.
Elementy akcji po spaleniu w ciągu 14/30 dni.

16) Anty-wzory

Strona według sprzętu (procesor, dysk) bez wpływu na użytkownika.
Brak 'group _ by' → „burza” wpisów.
Nie ma cichych okien - zwalnia malować wszystko czerwone.
Ładunki użytkowe bez 'serwisu//Runbook' - nie można kierować/działać.
Nie ma jednej skali dotkliwości i reguł (każde źródło jest inne).
„Wieczne” ostrzeżenia, że nikt nie naprawia (dług alarmowy).

17) Lista kontrolna realizacji (0-45 dni)

0-10 dni

Wyrównać skalę ciężkości i ujednolicić znaczniki/adnotacje.
Tworzenie usług w PagerDuty/Opsgenie, konfiguracja harmonogramów i podstawowych eskalacji.
Powiązać Alertmanager/Grafana, włączyć 'group _ by' i deadup.

11-25 dni

Wprowadź wpisy SLO (multi-window burn), dodaj link runbook.
Konfiguracja ChatOps: auto kanały, ack/przypisać polecenia.
Włącz ciche okna w wersjach/migracjach.

26-45 dni

Zintegruj auto-pauza/rollback dla kanarków (webhooks).
Wprowadź raporty MTTA/MTTR i higienę ostrzegania (czyszczenie hałasu).
Standaryzuj postmortem i kontroluj elementy akcji.

18) Gotowe snippety

Grafana Alerting → PagerDuty (mapowanie ciała JSON)

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 od alarmu → Argo Rollouts pauza

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

Opsgenie - Reguła routingu (pseudo)

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

19) Wniosek

Silny kontur wpisów to proces + dyscyplina: stratyfikacja zorientowana na SLO, kompetentne routing i eskalacja, jednolite znaczniki i ładunki, ciche okna, ChatOps i automatyczne działania (pauza/rolka). Wybierz PagerDuty lub Opsgenie na budżet i UX, ale trzymać się tych samych zasad hałasu, obowiązków i odpowiedzialności - wtedy strona będzie rzadkie, dokładne i przydatne, a incydenty będą krótkie i zarządzalne.