경고 및 알림: PagerDuty, Opsgenie

경고 및 알림: PagerDuty, Opsgenie

1) 별도의 경고 플랫폼 인 이유

목표는 올바른 사람/팀에게 즉각적이고 관련성있는 신호를 전달하고 인식 (ack), 에스컬레이션, 통신, 사후 사고 프로세스를 시작하는 것입니다. PagerDuty와 Opsgenie는 다음을 제공합니다

서비스/태그/환경별 라우팅.
확대 및 일정 (근무 중, 태양 추적).
이벤트 중복/상관.
조용한 창 (유지 보수/동결) 및 음악 규칙.

모니터링, CI/CD 및 ChatOps와의 통합

지원: SLO- 임계 값 → 경고 → 사람/기계 → 런북 → 롤백/수정 → 사후.

2) 신호 모델 및 심각도

• 중요 (페이지) -SLO 위반/화폐 경로 오류 (예금/인출), 가용성 감소, 연소율.
• 높음 (페이지/티켓) -명백한 SLO 고장없이 현저한 저하.
• 중간 (티켓) - 용량, 등의 열화, 다시 트레이.
• 낮음 (알림) -트렌드, 경고.

규칙: SLO 또는 명시 적 비즈니스 트리거 만 페이지.

3) 라우팅 아키텍처

1. 출처 (Prometheus/Alertmanner, Grafana, 클라우드 모니터링, 자체 웹 후크).
2. 지그재그 (PagerDuty/Opsgenie 서비스/통합).
3. 정책: 태그 별 경로 ('서비스', 'env', '지역'), 심각도, 페이로드.
4. 에스컬레이션: 일련의 듀티 레벨 (L1 → L2 → menedzher).
5. 커뮤니케이션: ChatOps 채널, 상태 페이지, 메일 링.

키 태그의 예 (표준화)

'서비스', 'env', 'region', 'version', 'runbook', 'release _ id', 'route', 'tenit' (B2B/multi- 테넌트 인 경우).

4) 통화 중 및 에스컬레이션 일정

스케줄: 1 차/2 차, ро독일 (SRE, DBRE, Sec).
회전: 낮/밤, 추종자, 주말.
오버 라이드: 휴가/질병.
에스컬레이션: ck- 타임 아웃 5-10 분 → 다음 레이어. 근무 시간-프로필 부서로; 외부-통화 중 플랫폼.

팁: 밤에는 짧은 에스컬레이션 단계 (피로 감소) 를 유지하고 낮에는 더 길게 (컨텍스트가 있음).

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 (웹 후크)

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) 소음, 데드 업 및 상관 관계

디드 업 키: 안정적인 지문 (예: 서비스 + 경로 + 코드) 을 사용하십시오.
그룹화: 서비스/환경별 'group _ by' 는 5xx 캐스케이드가 수십 페이지를 생성하지 않도록합니다.
음소거/조용한 창: 마이그레이션/릴리스/로드 테스트 중.
이유에 대한 억제: 'api-gateway @ prod' 에 대한 P1 사고가 이미 발생한 경우 어린이 P2/P3를 억제하십시오.

패턴 방지: SLO에 영향을 미치지 않는 CPU/메모리 별 페이지.

7) 릴리스 및 자동 작업과의 연결

카나리아 우울증으로 PagerDuty/Opsgenie는 CI/CD → 일시 정지/롤백 (Argo Rollouts/Helm) 의 SLO 게이트 → 웹 후크로부터 경고를받습니다.
경고에는 'release _ id', '이미지가 포함됩니다. 태그 ', 파이프 라인 및 롤백 런북에 대한 참조.

주석에서 런북 링크의 예

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

8) 대화 및 커뮤니케이션

슬랙/팀에서 사건 채널을 자동으로 만들어 티켓에 연결합니다.

슬래시-치 (Slash-ко

상태 페이지-P1/P2에서 자동으로 업데이트됩니다.

9) 사고 수명주기 (최소)

1. 방아쇠 (SLO/센서에서 경고).
2. 페이지 (기본 통화 중).
3. Ack (확인, TTA).
4. 의사 소통 (채널/상태).
5. Mitigate (롤백/기능 플래그/격리).
6. 해결 (TTR).
7. 사후 (타임 라인, 이유, 행동, 수업, 작업 소유자).

역할 키트: IC (사고 사령관), Ops 리드, Comms, Scribe.

10) 페이로드 필드 (정규화)

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/SpanMetrics-경로 별 대기 시간/오류.
K8 이벤트-클러스터 고장 (제어 평면, PDB 위반).
DB/대기열-지연/잠금/복제.
응용 프로그램 웹 후크-도메인 신호 (PSP 오류, 사기 급증).

12) 정책 및 준수

RBAC는 정책, 일정, 뮤타를 생성/수정합니다.
감사: 상태, 타임 스탬프를 인식/지정/변경 한 사람.
페이로드의 PII 최소화 (사용자의 이메일/전화 대신 티켓 ID).
DR 계획: PagerDuty/Opsgenie를 사용할 수 없을 때 어떻게해야합니까 (대체 채널).

13) 사례 연구 (PagerDuty vs Opsgenie)

14) 조용한 창문과 서리가 내린

동결: 계획된 릴리스 창에서 페이징 금지, P1 만 남음.
태그 암기: 'env = stage', 'region = dr', 'service = batch'.

임시 음소거: 명시 적 소유자와 함께 데이터베이스/로드 테스트를 마이그레이션 할 때

15) 성능 지표 (경고를위한 SRE/DORA)

MTTA/MTTR (팀/서비스/시프트로 분류).
런북에 대한 경고의% (대상 95% 이상).
SLO 별 페이지 알림 공유 (대상 90% 이상).
유용하거나 시끄러운 비율 (목표 3:1 이상).
자동 동작의% (웹 후크를 통한 일시 정지/롤백) -증가합니다.
14/30 일 내에 사후 조치 항목을 소각하십시오.

16) 반 패턴

사용자에게 영향을 미치지 않는 하드웨어 (CPU, 디스크) 별 페이

경고의 'group _ by' → "storm" 이 없습니다.

조용한 창문이 없습니다. 모든 것을 빨간색으로 칠하십시

'서비스/env/런북' 이없는 페이로드-라우팅/작동 할 수 없습니다.
단일 심각도 척도와 규칙이 없습니다 (각 소스는 다릅니다).
아무도 수리하지 않는다는 "영원한" 경고 (경고 부채).

17) 구현 점검표 (0-45 일)

0-10 일

심각도 척도를 정렬하고 태그/주석을 표준화하십시오.
PagerDuty/Opsgenie에서 서비스를 만들고 일정 및 기본 에스컬레이션을 구성하십시오.
Bind Alertmanner/Grafana는 'group _ by' 및 데드 업을 가능하게합니다.

11-25 일

SLO 알림 (다중 창 연소) 을 입력하고 링크 런북을 추가하십시오.
ChatOps 설정: 자동 채널, ack/admind 명령.

릴리스/마이그레이션에서 조용한 창을 사용합니다

26-45 일

카나리아 (웹 후크) 에 대한 자동 일시 정지/롤백을 통합합니다.
MTTA/MTTR 보고서를 입력하고 위생 경보 (소음 청소).
사후 부검을 표준화하고 행동 항목을 제어하십시오.

18) 준비된 스 니펫

Grafana Alerting → PagerDuty (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" }
]
}

경고에서 웹 후크 → Argo 롤아웃 일시 중지

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

Opsgenie-라우팅 규칙 (의사)

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

19) 결론

강력한 경고 윤곽은 SLO 지향 계층화, 유능한 라우팅 및 에스컬레이션, 균일 한 태그 및 페이로드, 조용한 창, ChatOps 및 자동 동작 (일시 정지/롤백) 과 같은 프로세스 + 분야입니다. 예산과 UX에서 PagerDuty 또는 Opsgenie를 선택하십시오. 그러나 동일한 소음, 의무 및 책임 규칙을 고수하십시오. 페이지는 드물고 정확하며 유용하며 사고는 짧고 관리 가능합니다.