경보 및 실패 대응
(섹션: 기술 및 인프라)
간략한 요약
강력한 경고는 "빨간색 지표 '가 아니라 사용자 가치를 침해하는 신호다. "iGaming의 경우 SLO 게이트 (대기 시간, 가용성, 결제 변환, Time-to-Wallet), 멀티 번 규칙, 명확한 통화, 에스컬레이션, ChatOps 및 런북 역할이 중요합니다. 목표는 편차를 신속하게 확인하고 수정할 수있는 사람들에게 알리고 다음에 더 빠르고 저렴하게 대응하기 위해 지식을 수정하는 것입니다.
1) 기본: 지표에서 행동까지
SLI → SLO → Alert-측정 된 품질 → 목표 수준 → "예산이 있습니다" 조건.
심각도 (SEV): SEV1-중요 (위험에 처한 수익/GGR), SEV2-심각한, SEV3-보통, SEV4-미성년자.
영향/긴급 성: 누가 고통 받고 있으며 (모든/지역/테넌트/채널) 얼마나 시급한 지 (TTW q, p99 얼마나, 오류 -rate).
작동 성: 각 알람에 대해-특정 작업 (런북 + 소유자).
2) 신호 분류법
체크아웃: p95/p99 대기 시간 API, 오류율, 채도 (CPU/IO/GPU), 대기열 지연.
BusinessSLO: 결제 변환 (시도 → 성공), TTW (Time-to-Wallet), 베팅 성공, 게임 시작.
지불 경로: PSP 특정 지표 (타임 아웃/감소 스파이크).
전면/모바일: RUM 메트릭 (LCP/INP), 충돌 속도, 시나리오 합성 (로그인/예금/속도/출력).
3) 경고 정책: SLO 및 연소율
SLI/SLO 예
결제-api 가용성은 99 이상입니다. 9 %/30d p95 '/예금 'λ250 ms/30d
(PHP 3 = 3.0.6, PHP 4) 3 %/24 시간
TTW p95 체 3 분/24 시간
다중 창/멀티 번 (и
빠른 화상: SLO 위반이 정상보다 5-10 배 빠릅니다 (5-15 분 안에 경고 페이지).
느린 화상: 저예산 소진 (1-3 시간 동안의 티켓 + 분석).
yaml
API success proxy metric (recording rule in advance)
record: job:http:success_ratio expr:
sum(rate(http_requests_total{status=~"2.. 3.."}[5m]))
/ sum(rate(http_requests_total[5m]))
Fast burn (99. 9% SLO)
alert: PaymentsSLOFastBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 14 for: 10m labels: { severity: "page", service: "payments-api" }
annotations:
summary: "SLO fast burn (payments-api)"
runbook: "https://runbooks/payments/slo"
Slow burn alert: PaymentsSLOSlowBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 6 for: 1h labels: { severity: "ticket", service: "payments-api" }4) 소음 감소 및 신호 품질
올바른 진실의 원천: 무거운 "원시" 표현이 아닌 집계 (기록 규칙) 로 변경합니다.
중복 제거-' 서비스/지역/심각도 '별 Alertmanner 그룹.
계층: 아래의 비즈니스/SLI에 먼저 경고-진단과 같은 기술 지표.
억제: 계획된 유지 보수/릴리스 (주석) 동안, 업스트림 사고 동안.
카디널리티: 경고 라벨에 'user _ id/setion _ id' 를 사용하지 마십시오.
테스트 경고: 정기적 인 "교육" 트리거 (채널, 역할, runabook 링크 확인).
5) 경보 관리자 라우팅 및 에스컬레이션
yaml route:
group_by: [service, region]
group_wait: 30s group_interval: 5m repeat_interval: 2h receiver: sre-slack routes:
- matchers: [ severity="page" ]
receiver: pagerduty-sre continue: true
- matchers: [ service="payments-api" ]
receiver: payments-slack
receivers:
- name: pagerduty-sre pagerduty_configs:
- routing_key: <PD_KEY>
severity: "critical"
- name: sre-slack slack_configs:
- channel: "#alerts-sre"
send_resolved: true title: "{{.CommonLabels. service }} {{.CommonLabels. severity }}"
text: "Runbook: {{.CommonAnnotations. runbook }}"
inhibit_rules:
- source_matchers: [ severity="page" ]
target_matchers: [ severity="ticket" ]
equal: [ "service" ]아이디어: SEV = 페이지 → PagerDuty/SMS; 나머지는 슬랙/티켓입니다. 억제는 위의 활성 SEV로 더 낮은 수준의 "과대 광고" 를 억제합니다.
6) Grafana Alerting (추가 레이어)
대시 보드의 중앙 집중식 경보 규칙 (Prometheus/Loki/Cloud).
연락처: PagerDuty/Slack/이메일, 폴더 당 알림 정책.
침묵: 계획된 작업, 마이그레이션, 릴리스.
티켓에서 패널의 자동 스크린 샷이있는 스냅 샷.
7) 통화 중 및 실시간 프로세스
회전: 첫 번째 줄 (SRE/플랫폼), 두 번째 줄 (서비스 소유자), 세 번째 (DB/지불/Sec).
SLA 반응: 인식
면세 채널: '# insument-warroom', '# state-Updates' (사실 만 해당).
런북: 각 경고 + ChatOps 빠른 명령 ('/롤백 ', '/프리즈', '/스케일 ') 에 링크합니다.
교육 경보: 월별 (사람, 채널, runabook 관련성 확인).
8) 사건: 생명주기
1. 탐지 (경고/보고/합성) → 통화 인정.
2. 심사: SEV/영향/가설, 열린 전쟁 실 결정.
3. 안정화: 롤/롤백/스케일링/피체 플래그.
4. 통신: 상태 템플릿 (아래 참조), ETA/다음 단계.
5. 폐쇄: SLO 복구 확인.
6. 사건 후 검토 (RCA): 24-72 시간 후에는 요금이없고 조치 항목이 없습니다.
- 파손/영향을받는 것 (지역/테넌트/채널)
- 시작할 때/SEV
- 임시 조치 (완화)
- N 분의 다음 상태 업데이트
- 연락처 (사고 관리자)
9) iGaming의 세부 사항: "통증" 영역 및 경고
결제/TTW: PSP 타임 아웃 점유율, 코드 오류 증가, TTW p95> 3m.
토너먼트 피크: p99 API/게임 시작 시간/큐 지연; 한계/자동 규모 홍보.
자금의 결론: 백호/수동 수표의 SLA, 국가 별 제한.
게임 제공 업체: 스튜디오 별 가용성, 세션 초기화 시간, 런칭 드롭.
RG/규정 준수: 페이지가 아니라 RG 팀에 대한 티켓 + 알림 인 임계 값을 초과하는 긴 세션/" 도곤 "버스트.
10) 규칙 예 (선택 사항)
높은 대기 시간 p95 (API)
promql alert: HighLatencyP95 expr: histogram_quantile(0. 95,
sum by (le, service) (rate(http_request_duration_seconds_bucket{service="api"}[5m]))) > 0. 25 for: 10m labels: { severity: "page", service: "api" }
annotations:
summary: "p95 latency > 250ms"
runbook: "https://runbooks/api/latency"리드 큐 "on"
promql alert: WithdrawalsQueueLag expr: max_over_time(queue_lag_seconds{queue="withdrawals"}[10m]) > 300 for: 10m labels: { severity: "page", service: "payments-worker" }
annotations:
summary: "Withdrawals lag >5m"
runbook: "https://runbooks/payments/queue"결제 전환 삭제
promql alert: PaymentConversionDrop expr:
(sum(rate(payments_success_total[15m])) / sum(rate(payments_attempt_total[15m])))
< (payment_conv_baseline - 0. 003)
for: 20m labels: { severity: "page", domain: "payments" }
annotations:
summary: "Payment conversion below baseline -0. 3%"
runbook: "https://runbooks/payments/conversion"11) 채팅 및 자동화
동작 버튼이있는 자동 게시 경고: 카나리아 중지, 롤백, 스케일 + N.
명령 약어: '/사건 시작 ', '/상태 업데이트', '/호출
봇은 최신 배치, 종속 그래프, 예제, 관련 티켓 등 컨텍스트를 강화합니다.
12) 사후 작업 (RCA)
Factbox: 타임 라인, 보고 시도한 것, 효과가있는 것.
근본 원인: 기술적 및 조직적 이유.
탐지 및 방어: 어떤 신호가 도움이되거나 실패했는지.
작업 항목: 특정 작업 (SLO/경고/코드/제한/테스트/runabook).
마감일 및 소유자: 조건 및 책임; 2-4 주 후속 세션.
13) 구현 점검표
1. 주요 스트림 (API/Payments/Games/TTW) 에 대한 SLI/SLO를 정의하십시오.
2. 기록 규칙 및 멀티 번 경고 + Alertmanger 라우팅을 설정하십시오.
3. 회전, 반응 SLO 및 에스컬레이션으로 통화를 시작하십시오.
4. 런북 및 ChatOps 명령에 대한 링크 알림.
5. 억제/조용한 창, 릴리스/작업 주석 설정.
6. 학습 경보 및 게임 데이 시나리오 만들기 (PSP 드롭, p99 상승, 대기열 지연 상승).
7. 측정 경보 품질: SLO의 MTTA/MTTR,% 잡음/거짓, 적용 범위.
8. 정규 RCA 및 임계 값/프로세스 개정.
9. 비즈니스/지원 커뮤니케이션 상태 (템플릿) 를 입력하십시오.
10. 규칙, 경로, runabook 링크 등 모든 것을 코드로 문서화하십시오.
14) 반 패턴
"모든 메트릭 →" 경고 페티그로 경고하면 무시하십시오.
SLO → "정상" 이 무엇인지, "화재 중" 이 무엇인지 명확하지 않습니다.
억제/억제 → 눈사태가 발생하지 않습니다.
사소한 이벤트에 대한 밤의 페이지 (SEV는 Impact와 비교할 수 없습니다).
런북/소유자가없는 경고.
ChatOps/감사없이 "수동" 작업.
RCA/액션 항목 → 반복 사건이 없습니다.
요약
경고 및 응답은 일련의 규칙이 아닌 프로세스입니다. 멀티 번 경고가있는 SLO를 링크하고, 명확한 통화 중 에스컬레이션을 구축하고, ChatOps와 라이브 runabook을 추가하고, 정기적으로 RCA 및 교육 세션을 수행하십시오. 그런 다음 사고는 덜 빈번하고 짧으며 저렴하며 iGaming의 더운 시간에도 릴리스가 더 예측 가능합니다.