SLO, SLA 및 신뢰성 모니터링
(섹션: 기술 및 인프라)
간략한 요약
SLO는 내부 품질 목표이고 SLA는 고객에 대한 외부 약속이며 SLI는 품질을 측정하는 방법입니다. iGaming에서 주요 SLI: API 및 결제 가용성, 중요 경로의 p95/p99 대기 시간, TTW (Time-to-Wallet), 결제 변환, 게임 시작 및 대기열 지표. 신뢰성 관리는 주석이 달린 예산의 오류, 멀티 번 경고, 명확한 릴리스 게이트 및 비주얼 대시 보드를 중심으로 구축됩니다.
1) 이용 약관
SLI (서비스 수준 표시기) - 측정 된 표시기 (예: 시간당 성공적인 요청 비율).
SLO (서비스 수준 목표) - 대상 SLI 값 (예: "가용성 99. 30 일 만에 9% ").
SLA (서비스 수준 계약) - 보상에 대한 계약/책임; 실제 SLO를 기반으로하지만 법적 조항 및 계획된 유지 보수 창이 포함됩니다.
규칙: 먼저 SLI/SLO 내부를 안정화 한 다음 SLA 외부에서만 수정하십시오.
2) iGaming을위한 SLI 프레임 워크
텍사스
가용성: 성공적인 2xx/3xx/모든 요청.
대기 시간: 주요 경로 별 p95/p99 ('/deposition ', '/bet', '/game/init ').
오류: 5xx 공유/타임 아웃.
포화/대기열: 지연된 지불/거래 대기열.
비즈니스 SLI
결제 변환: '성공/시도'.
TTW p95: 철회 요청에서 등록까지의 시간.
게임 시작 성공: 게임 세션, 제공자 초기화.
KYC/AML 흐름 성공.
3) 오류 예산: 계산 방법
오류 예산 = 1-SLO.
예: 가용성 99 SLO. 9 %/30d 오류 예산 = 0. 30 일 동안 시간의 1%, 43 분 12 초.
success_ratio = success_requests / all_requests error_ratio = 1 - success_ratioSLO는 슬라이딩 윈도우 (30/7/1 일) 에 포함되며 대시 보드에서 볼 수 있습니다.
사용 정책:- 예산 → 동결 방출의 빠른 "연소", 우리는 카나리아를 멈추고 안정성을 위해 노력하고 있습니다.
- 예산 주식 → 보다 빈번한 변경 (제어) 을 허용합니다.
4) 키 흐름에 대한 SLO 예
결제 API:- 가용성은 99 이상입니다. 9 %/30d
- 대기 시간 p95 '/예금 '
- 지불 변환은 기준선 -0입니다. 3 %/24 시간
- TTW p95 (출력) λ3 분/24 시간
- 게임 초기 성공 5 %/7% p95 게임 init
- 작업 성공 이상 99 %/7e, 지연 <5 분 (개별적으로 피크 창).
5) 측정: 공식 및 PromQL (아이디어)
요청 성공:promql sum(rate(http_requests_total{status=~"2.. 3..",service="payments-api"}[5m]))
/
sum(rate(http_requests_total{service="payments-api"}[5m]))promql histogram_quantile(0. 95,
sum by (le) (rate(http_request_duration_seconds_bucket{service="payments-api",route="/deposit"}[5m])))promql histogram_quantile(0. 95,
sum by (le) (rate(ttw_seconds_bucket{flow="withdrawal"}[15m])))promql sum(rate(payments_success_total[15m])) / sum(rate(payments_attempt_total[15m]))6) 화상 경보 (다중 창)
아이디어: 우리는 현재 예산 소비율을 허용되는 것과 비교합니다.
SLO 99의 예. 9%:- 빠른 연소: 1 시간 → 페이지의 14 예산 × 5-15 분.
- 느린 화상: 24 시간 → 티켓 6 개 예산 ×, 이유 분석.
yaml recording rule: job:http:success_ratio — заранее alert: SLOFastBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 14 for: 10m labels: { severity: "page" }
alert: SLOSlowBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 6 for: 1h labels: { severity: "ticket" }7) 대시 보드 "SLO 카드" 및 운영 체제
최상위 레벨 (지도):- 서비스 카드: 가용성, p95, 오류율, 번 레이트, 오류 예산 잔액.
- 필터: 'env', 'region', 'tentin', 'version'.
- 릴리스 주석: Git Ś, 유형 (카나리아/청록색), 전환 시간.
- 안정적인 대 카나리아 비교.
- PSP/게임 제공 업체별 섹션.
- 예제 (trace _ id) 및 관련 로그로 이동하십시오.
- 대기열 지연 및 채도 (USE 메트릭).
8) SLO 프로세스: 게이트, 동결, 에스컬레이션
CD 게이트: 카나리아 프로모션은 SLO 프록시 (가용성, p95, conv) 를 수행 할 때만 허용됩니다.
동결: 빠른 연소 또는 예산 균형없이 복구 할 때까지 릴리스를 중지하십시오.
에스컬레이션: SEV- 매트릭스 (SEV1 지불/예금, SEV2 게임, SEV3 백호).
RCA: 무료 분석, 테스트/제한/phicheflags 업데이트.
9) 데이터/ML-SLO (추천자/LLM 용)
대기 시간: p95 응답 모델
품질 프록시: 유효한 반응의 비율/낮은 독성, 도움이되는 비율.
신선도: 기능의 연령/데이터
1k 이벤트 당 비용: 예산 지출.
SLO 게이트는 모델 릴리스 (A/B/카나리아 롤아웃) 에 통합되어 있습니다.
10) SLO 기반 SLA 디자인
SLA의 기초로 보수적 인 SLO를 선택하십시오.
예외 (계획된 활동, 외부 종속 공급자, 사고 절차) 를 정의하십시오.
위반 수준 (신용/할인), 보고 및 검증 메커니즘으로 오프셋을 입력하십시오.
11) 빈번한 오류 및 패턴 방지
SLO는 없으며 "업타임 100%" 만이 비현실적이고 동기를 부여하며 위험을 숨 깁니다.
연소율 대신 "모든 메트릭" 에 대한 경고-경고 피로 및 무시.
SLO에 대한 메트릭/로그의 PII 혼합-규정 준수 위험.
카디널리티는 레이블로 'user _ id/setion _ id' 로 폭발합니다.
릴리스 주석이 부족합니다-저하를 변화와 연관시키는 것은 어렵습니다.
Opaque 오류 예산-팀은 언제 "당신이" 위험을 감수 할 수 있는지 이해하지 못합니다.
SLO는 비즈니스와 관련이 없습니다. 기술 지표는 "녹색" 이고 수익은 "빨간색" 입니다.
12) 구현 점검표
1. 기본 SLI 승인 (가용성, p95/p99, 오류율, TTW, 변환).
2. 30/7/1 일 창에 SLO를 설정하고 오류 예산을 계산하십시오.
3. 레코딩 규칙과 번 레이트 경고 (빠른/느린) 를 추가하십시오.
4. 릴리스 주석 및 카나리아/안정적인 비교가 포함 된 SLO 맵을 작성하십시오.
5. CD에 게이트를 포함 시키십시오: SLO-ok없이-프로모션없이.
6. 동결 절차와 에스컬레이션 SEV 매트릭스를 입력하십시오.
7. SLO를 비즈니스 메트릭 (conv, TTW) 및 결제 경로에 링크하십시오.
8. 데이터/ML의 경우 대기 시간/품질/신선도 -SLO를 정의하십시오.
9. 정규 RCA 및 SLO/임계 값 개정 (분기 별).
10. SLO가 안정된 후에 만 문서 SLA.
13) "준비된" 목표의 예 (시작)
API 일반: 가용성 99. 9 %/30d; p95 λ250 ms/30d; 오류율 3 %/30d
지불: 변환은 기준선 -0입니다. 3 %/24 시간; TTW p95 체 3 분/24 시간
게임 초기: 성공 99 이상. 5 %/7d; p95 λ600 ms/7e
백 오피스 작업: 성공 99 %/7/7 이상; 지연 5 분/7d
LLM/Reco: 토큰/s 5 %/7d, 신선도
요약
SLO/SLA 접근 방식은 신뢰성을 "어제보다 더 나은" 측정 가능한 분야로 전환합니다. 투명한 SLI, 이해할 수있는 오류 예산, 연소 속도 경고, 이해할 수있는 대시 보드 및 릴리스에 내장 된 품질 게이트. 이 윤곽은 iGaming 플랫폼에 예측 가능한 p95/p99, 안정적인 결제 및 TTW를 제공하므로 가장 뜨거운 시간 동안 더 나은 수익과 더 적은 사건을 의미합니다.