알람 및 알림 시스템

1) 역할과 목표

신호 시스템은 "메시지 전송" 이 아니라 의사 결정 회로입니다. 시간의 편차를 강조하고 행동을 제공하며 적시성과 침묵 사이의 균형을 유지합니다.

• 우선 순위 지정 및 명확한 플레이 북을 통해 MTTD/MTTR을 줄입니다.
• 소음 제거를 통한 경고 피로를 줄입니다.
• 알림 (ack, snooze, runbook, 자동 작동) 에서 직접 작업을 수행하십시오.
• 개인 정보 보호 및 동의를 준수하십시오 (옵트 인/옵트 아웃, 로그 스토리지).

2) 사건 및 수준의 분류

2. 이벤트 유형 1 개

지표/이상 (SRE, 제품, 금융).
비즈니스 규칙 (제한, 사기, KYC, 지불).
시스템 (배치, 저하, 라이센스).
사용자 (행동 트리거, RG/책임 게임).

2. 2 심각도 수준

중요한-즉각적인 대응, 손실/안전의 위험.
KPI/SLO가 크게 악화되었습니다.
영업 시간 동안 필요한 중간 조치.
낮은/정보-관찰/컨텍스트, 다이제스트로의 자동 컨볼 루션.

2. 3 우선 순위

'충격 × 긴급' 행렬 → P1.. P4. 채널 및 SLA 반응에 연결합니다.

3) 아키텍처 및 스레드

신호 생산자 → 이벤트의 Sheena → 정규화 (풍부, 결정) → 상관 → 교정 (정책 엔진) → 라우팅 → Canala 전달 → 선호 센터 → 통나무/분석.

• 풍부한: 테넌트, 역할, 지역, 플레이 북 링크를 추가합니다.
• 키별로 Deduper-Group 되풀이 이벤트.
• 상관기: 접착제 관련 신호가 사고와 관련이 있습니다.
• 정책 엔진: YAML/DSL 규칙, 조용한 시간, 에스컬레이션.
• 배송: 인앱, 이메일, 푸시, SMS, 웹 후크, 채팅 통합.

4) 규칙 및 정책 (YAML 예)

yaml policies:
- id: p_sre_critical match: { domain: "infra", severity: "critical" }
route:
primary: { channel: "pager", targets: ["oncall_sre"] }
fallback: { channel: "sms", delay: "2m" }
suppress:
flapping: {window: "10m," threshold: 5} # suppressing frequent twitching duplicates: {key: ["service, ""cluster,"" error _ code"], ttl: "15m"}
escalate:
after: "10m"
to: ["sre_manager"]
auto_assign: true
- id: p_product_medium match: { domain: "product", severity: "medium", kpi: "conversion" }
route:
primary: { channel: "inapp", audience: "product_owners" }
digest:
window: "1h"
max_items: 10 quiet_hours:
tz: "Europe/Kyiv"
ranges: ["22: 00-07: 00"] # only P1 digests/pager at this time

5) 중복 제거, 상관 관계, 플 래핑 억제

Dedup: 그룹 ID 'dedup _ key = hash (서비스' metric 'dim)'; TTL 소 플래핑 창.

상관 관계: 관련 신호를 토폴로지 (servis → zavisimost), 시간 (

플래핑: 임계 값 "M 분 당 N 이벤트" → 히스테리시스를 높이거나 억제하기위한 제안으로 하나의 신호 "플래핑 감지".

6) 경로 및 RACI

책임: 누가 첫 번째 알림/드래그를받습니까?
책임: SLA 이후 누가 에스컬레이션합니까?
상담: 스레드/채팅 채널에서 언급 할 사람.
정보: 누가 다이제스트/결과를 떠날 것인가.
역할 및 컨텍스트별로 할당 (테넌트, 지역, 제품 스트림).

7) 배달 채널 및 뉘앙스

Retrai: 5xx/429/타임 아웃 → 백오프 + 지터; '재생 후' 존중. 이데올로기: 웹 후크의 'X-Almunication-ID'.

8) 환경 설정 센터

이벤트 유형, 레벨, 채널별로 옵트 인/옵트 아웃.
조용한 시간, 15/30/60 분 동안 수동 스누즈.

• 언어/로케일, 시간/통화 형식.
• 역할 구속력: SRE/제품/금융에 대한 사전 설정.
• 투명성: 사용자가 신호를받은 이유를 보여줍니다 (규칙에 대한 링크).

9) 콘텐츠 디자인: 메시지 구조

• 제목: 간단한 트리거: "[P1] [PSP _ TR] 3DS 실패에서 급격한 상승 (+ 12%)".
• 상황: 기간, 영향을받는 세그먼트/지역, 데이터 소스.
• 이유/가설: "PSP _ X 18:20 UTC의 출시와 관련이 있습니다".
• SLA/마감일: "10 분 안에 확장".
• CTA: "오픈 플레이 북", "폴백 사용, PSP _ Y" "Ack (30 분)".
• 링크: 그래프, 사건 스레드, 메트릭, 런북.
• 메타 데이터: 'trace _ id', 'issue _ id', 'dedup _ key'.

톤: 사실, 극화 없음; 숫자와 단위는 디코딩없이 약어를 피합니다.
현지화: 변수 → 플레이스 홀더, 변환은 리소스에 저장됩니다. 숫자/날짜-로케일 별.

10) 알림의 동작 (실행 가능)

시간 매개 변수가있는 Ack/Snoes.
사건 스레드에 할당/초대.
컨텍스트 자동 완성 된 Runbook-Open 솔루션 단계.
원 클릭 치료 (안전한 경우): 경로 전환, 한도 상승, 작업 다시 시작 (확인 및 감사 포함).
자동 완성 필드로 티켓 (Jira/GitHub) 을 만듭니다.

11) 신호 품질: 지표 및 대상

P1/P2의 정밀도는 80% 이상입니다.
리콜 (모든 사건 중에서 감지 된 사건의 비율) 70% 이상.
소음: 사용자 당 평균 신호/시간 (대상 한도).
Ack-time p50/p95, 에스컬레이션 속도, 스누즈 속도 (잡음 표시기).
MTTD/MTTA/MTTR (도메인 및 채널 측면에서).
침묵했지만 경고해야합니다 (규칙으로 인한 간격) 는 별도의 대시 보드입니다.

12) 소음 제어: 기술

임계 값을위한 히스테레시 및 슬라이딩 윈도우.
탐지 전 EWMA (Anti-aliasing).
집계: 30 개의 작은 것들 대신-최고의 기여자들과 하나의 배치/다이제스트.
상황 제한: 최대 N 알림/시간/채널/사용자.
자동 피드백: 사용자가 3 배 연속으로 Snooze를 클릭하면 임계 값을 올리거나 채널을 변경하는 것이 좋습니다.

13) 보안, 개인 정보 보호, 규정 준수

웹 후크를위한 HMAC 서명, 비밀의 회전, 'X-Key-ID'.
RBAC/ABAC: 역할/테넌트 별 신호 가시성.
PII 최소화, 로그에 마스킹, 감사 작업 (ack/administry/runbook).
동의 및 알림 이유 (규칙/정책) -페이로드.
보존/TTL 알림 로그, 사건에 대한 법적 보류.

14) 계획 및 페이로드

이벤트 (내부)

json
{
"id": "sig_01HX",
"domain": "payments",
"severity": "high",
"priority": "P2",
"title": "The 3DS failure graph has grown to 8. 2% (+3. 1 pp), "
"occurred_at": "2025-11-03T17:55:00Z",
"context": { "psp": "PSP_X", "country": "TR", "release_id": "rel_241103_1820" },
"metrics": { "baseline": 5. 1, "current": 8. 2, "delta_pp": 3. 1 },
"dedup_key": "payments    PSP_X    TR    3DS_FAILURE",
"runbook": "rbk_psp_3ds_spike",
"slo": { "ack_deadline_sec": 600 }
}

알림 (불가지론 채널)

json
{
"notification_id": "ntf_91ab",
"signal_id": "sig_01HX",
"targets": ["oncall_payments"],
"channels": ["inapp","slack","webhook"],
"cta": [
{"id": "ack," "label": "Confirm (30 min)," "payload": {"ttl ":" 30m"}},
{"id": "runbook," "label": "Open playbook," "payload": {"id ": "rbk _ psp _ 3ds _ spike"}},
{"id": "fallback," "label": "Enable fallback, PSP_Y" "confirm": true}
],
"hmac": "sha256=AbCd..."
}

15) 제품의 UX 패턴

받은 편지함: 중요/높음/기타 탭, 수량 배지.
사고 피드: 상관 신호, 행동 일정, "수행 된 작업".
필터: 역할, 도메인, 지역, 시간, "답변되지 않은".
목록에서 빠른 동작 (ack/snooze/administry).
설명: "왜 보이는지" (규칙, 임계 값, 데이터).
Digestus: 아침/저녁, TZ에 의해 현지화 됨.

16) 테스트 계획

단위: 디드 업 키, 히스테리시스, 플 래핑, 페이로드 직렬화.
통합: 라우팅, 조용한 시간, 에스컬레이션, 채널 배상.
E2E: 이상에서 티켓 폐쇄까지의 시나리오 P1; 조용한 시간에 P2 → 소화.
혼돈: 링크 손실 (FS/SMS), 지연, 신호 눈사태, 시계 왜곡.
A11y/i18n: 스크린 리더, 키보드 팩/스누즈, 숫자/날짜의 현지화.

17) 품질의 대시 보드

도메인 별 정밀/리콜.
Ack time p50/p95 및시기 적절한 공유.
사용자 당 소음/시간 및 최고 소음 규칙.
에스컬레이션 속도 및 "거짓 에스컬레이션".
억압 대 배송 (얼마나 억제/소화되는지).
사용자 피드백 :/메시지, 소음에 대한 의견.

18) 점검표

디자인

• 이벤트 분류 및 수준은 일관됩니다
• 조용한 시간/에스컬레이션 정책이 설명됩니다
• 결제/상관/플래핑 구성
• 채널, Retras, Webhook Idempotency
• 선호 센터 (옵트 인/아웃, 스누즈)
• 콘텐츠 템플릿 및 현지화
• 플레이 북 및 원 클릭 작업 (감사)
• 품질 지표 및 대시 보드

작동

• 임계 값 최적화 분기 별
• A/B 규칙 (임계 값, 창, 다이제스트)
• 정기적 인 "최고 소음" 및 CAPA 리뷰
• 채널 비밀 회전 (HMAC, SMT, SMS)
• 예정된 게임 일 테스트

19) 구현 계획 (3 회 반복)

반복 1-기준 (2-3 주)

분류, 심각도/우선 순위, 우선 순위 센터 (in-app + 이메일).
데드 업, 간단한 키/시간 상관 관계, 조용한 시간.
메시지 템플릿, 플레이 북, ack/snooze/administry.

Iteration 2-신뢰성 및 소음 감소 (3-4 주)

플래핑/히스테리시스, 다이제스트, 채팅 통합 및 웹 후크 (HMAC, retrays).
SLA, 품질 대시 보드 (정밀/리콜, 노이즈) 에 따른 에스컬레이션.
한 번의 클릭 치료 (확인 및 감사 포함).

Iteration 3-최적화 및 규모 (연속)

토폴로지/릴리스에 의한 상관 관계, 임계 값의 자동 제안.
A/B 규칙은 "임계 값이 작동 할 때" 를 예측합니다.
소음 리뷰 및 정규 게임 일.

20) 미니 -FAQ

경보 피로를 다루는 방법?
결제, 상관 관계, 히스테리시스, 다이제스트 및 선호 센터 + 규칙적인 노이즈 및 A/B 임계 값 검토.

이상에 ML이 필요합니까?
유용하지만 결정 론적 규칙과 설명 가능한 임계 값으로 시작하십시오. ML은 항상 Explain과 함께 애드온과 같습니다.

사용자가 "추가" 이메일을받는 이유는 무엇입니까

규칙 일치, 조용한 시간, "전달 된 이유" 감사, 채널/시간 제한 및 다이제스트를 확인하십시오.

합계

강력한 신호 시스템은 스마트 필터링 및 올바른 우선 순위 지정 + 원 클릭 동작입니다. 분류 및 정책을 공식화하고, dedup/correlation/histeresis를 구현하고, 사용자에게 제어 (환경 설정, 스누즈) 를 제공하고, 안정적인 전달 및 투명성을 제공합니다. "그러면 신호는 노이즈 소스가 아닌 제어 도구가됩니다.