운영 및 → 감사 메트릭 및 SLA 관리

감사 메트릭 및 SLA

1) 왜 필요한가

지표가 잘못된 경우-결정이 잘못되거나 SLA가 "종이에" 위반되거나 그 반대로 문제를 숨길 수 있습니다. 감사 지표 및 SLA는 사용자와 파트너에게 약속이 비슷하고 신뢰할 수 있으며 법적으로 안전하다는 것을 보장합니다.

• 단일 "진리의 원천" (SSOT) 및 재현 가능한 계산을 제공하십시오.
• 대시 보드/보고서/청구 간의 불일치를 줄입니다.
• SLA의 증거를 기반으로합니다.
• 서비스 초기에 측정에서 열화를 감지합니다.

2) 기본 개념과 책임 경계

메트릭: 측정 된 수량 (RPS, p95, CR, GGR, 성공률).
KPI/ODVD: 메트릭이 연결된 대상입니다.
SLO: 서비스 품질을 목표로합니다 (예: "p99 λ400 ms 99. 시간의 9% ").
SLA: 외부 약속; SLO를 기반으로 법적으로 중요합니다.
OLA: 팀/공급 업체 간의 내부 계약은 SLA를 지원합니다.
SSOT: 데이터가보고 참조로 간주되는 시스템/스토리지.

3) 지표 분류 (레이어)

1. 인프라: CPU/Memory/IO/Net, 포드/노드, HPA/VPA.
2. 플랫폼: 대기열/스트림 (지연, 처리량), DB/캐시 (연결, 적중), API (p95/p99, 5xx).
3. 비즈니스 흐름: 예금/인출, 베팅, 게임 출시, 승인, KYC.
4. 제품/마케팅: 전환, ARPPU/LTV, 캠페인.
5. 프로세스 품질: MTTA/MTTR, 실패율 변경, 목록 적용 범위 확인.

규칙: 각 메트릭에는 계층, 소유자 및 공식이 있어야합니다.

4) 데이터 소스 및 "참"

온라인 원격 측정: Prometheus/OTel, 로그 (ELK/ClickHouse), 흔적.
이벤트 및 회계: Kafka/전송률, DWH/데이터 마트 (Bigquery/ClickHouse).
수동 아티팩트: 사후 사후, 티켓, 사고 기록.
외부 등록: 공급자 보고서 (PSP/KYC/스튜디오), 청구.

충돌 해결: "온라인 대 DWH" 불일치의 경우 우선 순위 규정이 적용됩니다 (예: SLA-소스 추적 성이있는 DWH의 집계).

5) 측정 감사 프로세스 (제어 루프)

1. 인벤토리: 메트릭 카탈로그/SLO/SLA (이름, 소유자, 계층, 공식, 소스, 계산 빈도).
2. 공식 검증: SQL/프로모션 쿼리를 정의와 조정 (계산 단위 테스트).
3. 샘플링 및 재확인: 이벤트/로그 라인 샘플링 및 수동 조정.
4. 컨투어 매핑: 온라인 대시 보드 및 DWH 보고서 비교.
5. 제어 변경: 스키마/논리 릴리스에 대한 공식 검토.
6. SLA 감사: 어셈블리 및 예외의 정확성 검증 (계획된 유지 보수, 힘 전공).
7. 보고 및 개선: 마감일이있는 감지 된 불일치 및 수정 목록.

6) 정의 및 공식 (샘플)

• '성공 = 요청- (5xx + 타임 아웃 + 회로 _ 오픈)'
• 'success _ rate = 성공/요청'

• SSOT는 창 (롤링 5m/1h) 및 집계 (HDR/TDigest) 의 단일 정의를 기록합니다.

• (PHP 3 = 3.0.6, PHP 4)

• 'SLA _ month = 99. 계획된 창 (T-48 알림), 대중 교통 사업자 (문서) 의 입증 가능한 사고를 제외하고 UTC 창으로 90% 가동 시간. '

7) 데이터 품질: 검사 및 경고

• (PHP 3 = 3.0.6, PHP 4) 99`.
• 타임 라이스: 로드 레이그
• 독창성: 중복 키 없음 (demempotency-key).
• 일관성/통화/문자.
• 선형성-카운터는 "롤백" 되지 않습니다.

ALERT MetricsIngestionLagHigh
IF dwh_ingest_lag_minutes > 15 FOR 10m

ALERT EventsCompletenessDrop
IF (events_received / events_expected) < 0. 99 FOR 15m

ALERT DuplicateEventsSpike
IF rate(events_duplicates_total[10m]) > baseline_7d 2

8) SLA/OLA 감사: 방법론

1. 예외 일정 수집: 계획된 창, 합의 된 열화, 공급 업체의 행위.
2. 가동 시간 계산: SSOT를 기반으로 한 단일 시간대에 따라.
3. 사건과의 조정: 타임 라인, 티켓, 사후.
4. 기여: 자체 장애, 공급자, 대중 교통, DDoS, 정기 유지 보수.
5. SLA 경계: 사용자 경험 (E2E) 대 하나의 특정 API.
6. 보고: 월별/분기 별 보고서: 실제, 편차, 보상 (해당되는 경우), 수정 조치.

9) 계산 재현성 확인

공식 버전 지정: SQL/PromQL/dock 사양이있는 Git 저장소.
메트릭의 단위 테스트: 합성 데이터 (에지 케이스: 갭, 복제, 날짜 경계).
데이터 계보: 대시 보드에서 소스 테이블 및 이벤트까지.
스냅 샷: 다시 계산할 수 있도록 컷오프 데이터를 동결합니다.

10) 샘플링

매일: 키 흐름에 의한 10-20 이벤트 (예금/비율/CCL) -DWH 추적의 수동 검증.
주간: 집계에서 "온라인 대 DWH" 를 비교하는 1% 샘플.
월간: SLA 효과가있는 일련의 사건-자세한 재구성.

Date/Window: 2025-10-01.. 2025-10-07
Metric: SLO_api_p99
Source A: Prometheus (rolling 5m)
Source B: DWH snapshot (1h buckets)
Deviation: + 6. 2% (A above B)
Reason: different aggregation windows
Action: align window in both contours to 5m/rolling
Term/Owner: 2025-11-10/squad-observability

11) 대시 보드 및 경고 감사

통합 된 메트릭 사전: 대시 보드의 용어집.
릴리스/이벤트의 주석: 편차의 원인을 확인합니다.
사전/사후 릴리스 비교: 자동 회귀 패널.
복제/불일치: "두 개의 다른 p99" 식별 - 공식/창 편집.
패널 가용성: 권한, 예약, 링크/버전 제어.

12) 미터법 변경 관리

RFC 프로세스-공식/창/소스 변경-SLA/보고 영향 평가를 통한 RFC를 통해

마이그레이션 "확장 → 마이그레이션 → 계약": 일시적으로 두 버전을 모두 유지 한 다음 이전 버전을 끄십시오.
커뮤니케이션: "새로운 방법에 따라" 값이 바뀌기 전에 제품/비즈니스에 알리십시오.

13) 세부 사항 iGaming/fintech

수요 피크: 지표는 폭발성 하중을 견뎌야합니다 (집계는 "고착" 하지 않습니다).
제공자: SLA는 OLA 공급 업체에 따라 보고서, 사고 상태 및 할당량을 저장합니다.
비용: 'cost _ per _ 1k _ calls' 및 '성공 비용' 은 필수 패널입니다.
사기 방지/위험: 지연에 대한 민감성 및 지표의 "거짓 긍정".

14) 감사 대시 보드 (최소 세트)

메트릭 스 건강: 완전성/적시성/복제본, 지연 시간, 및 지연 요법 ETL.
SLO/SLA 증거: 계산 된 SLO, 실제 SLA, 예외, 사건/행위에 대한 참조.
온라인 vs DWH 비교: p95/p99/성공률, 편차 및 추세.
공급 업체 SLA: 공급자 별 가동 시간/할당량/타임 아웃/비용.
릴리스 영향: 기능의 계산/포함 후 메트릭의 회귀.

15) 감사 점검표 (운영)

• 소유자 및 공식이있는 메트릭/SLO/SLA 디렉토리가 최신입니다.
• SSOT는 각 보고서/패널에 대해 정의됩니다.
• 공식의 단위 테스트는 녹색이며 계산 파이프 라인이 문서화되어 있습니다.
• 데이터 품질 알림이 활성화되었습니다 (완전성/타임 라인/복제).
• "온라인 vs DWH" 불일치
• 합의 된 SLA 예외가 문서화되어 보고서에 첨부됩니다.
• 제어 샘플을 채취하고 인증서를 작성했습니다.
• 모든 공식 변경이 RFC와 마이그레이션을 통과했습니다.

16) 예 (조각)

api_p99_ms:release:ratio =
(api_latency_p99_ms{release="after"} / api_latency_p99_ms{release="before"})

sql
SELECT event_date,
COUNT() AS received,
SUM(expected_count) AS expected,
COUNT()::decimal / NULLIF(SUM(expected_count),0) AS completeness
FROM events
JOIN expected_events USING (event_date, event_type)
WHERE event_type IN ('deposit','bet_placed','kyc_completed')
AND event_date BETWEEN:from AND:to
GROUP BY 1;

ALERT DwhVsOnlineDrift
IF abs(dwh_kpis{metric="api_p99"} - online_kpis{metric="api_p99"}) > 0. 02 online_kpis
FOR 30m
LABELS {severity="warning", team="observability"}

17) 반 패턴

서로 다른 패널에서 두 개의 다른 "동일한" 메트릭 공식입니다.
마이그레이션 및 알림없이 메트릭을 변경하십시오 - ODVD/SLA에서 "점프".
로컬 Excel에서 "참" (재현 불가) 으로보고합니다.
SLA 계산에서 시간대와 달력 혼합.
SLA 예외는 문서화되어 있지 않습니다.
측정 품질에 대한 경고는 없습니다.

18) 측정 성숙도 KPI

드리프트 속도 온라인 DWH (대상

메트릭 건강 가동 시간.
수정 시간.
SLA 분쟁률.
적용 범위 SLO/SLA (공식적으로 설명 된 SLO/SLA 비율).

19) 역할과 책임

메트릭/서비스의 소유자: 공식, 소스, 대시 보드, 경고.
관찰 가능성/SRE: SSOT/플랫폼, 수식 테스트, 데이터 품질 경고.
데이터/BI: DWH, 재현성보고, 계보.
변호사/파트너 관리자: SLA 계약 및 예외.
사건 관리자: SLA 사건의 기여 및 연결.

20) 빠른 시작 (30 일)

1 주차: 인벤토리 메트릭/SLO/SLA 및 소유자; SSOT를 할당합니다.
2 주차: 데이터 품질 알림 및 "온라인 vs DWH" 패널이 포함됩니다.
3 주차: 제어 샘플을 수행하고 p95/p99 창을 정렬하십시오.
4 주차: 공식에 대한 RFC 프로세스를 공식화하고 첨부 파일이있는 월간 SLA 보고서를 준비하십시오.

21) FAQ

Q: SLA의 SSOT 란 무엇입니까?
A: 재현 가능한 계산 (DWH) 및 전체 계보가있는 스토리지; 온라인 패널-법적 행위가 아닌 운영 통제를위한 것입니다.

Q: "두 p99" 를 다루는 방법?
A: 메트릭 디렉토리에서 창/집계 방법을 수정하고 패널을 마이그레이션하며 드리프트에 경고를 추가하십시오.

Q: 계획된 작업을 고려하는 방법?
A: 예외 일정을 유지하고 계약 규칙에 따라 SLA에서 자동으로 공제하십시오. 확인 아티팩트를 저장합니다.