SLA, SLO 및 신뢰성 KPI

1) 이용 약관

SLI (서비스 수준 지표) - 측정 가능한 품질 지표 (예: 성공적인 요청 비율, p95 대기 시간).
SLO (서비스 수준 목표) - 시간당 SLI 값을 목표로합니다 (예: "성공 99 이상). 28 일 만에 9% ").
오류 예산-허용되는 SLO 실패율은 '1-SLO' 입니다.
SLA (서비스 수준 계약) - 벌금/크레딧이있는 계약 의무 (외부).
신뢰성 KPI-운영 프로세스 메트릭 (MTTD/MTTA/MTTR/MTBF,% 자동 완화, 경고 범위 등).

2) SLI 선택 방법 (골든 신호 기반)

1. 대기 시간-주요 엔드 포인트의 경우 p95/p99.
2. 트래픽 - RPS/RPM/메시지 흐름.
3. 오류-5xx/비즈니스 오류의 비율 (예: PSP 오류로 인한 지불 감소 제외).
4. 포화 - 자원 채도 (CPU/RAM/IO/lag).

• 사용자 인식 경험과 관련이 있습니다.
• 기술적으로 사용 가능하고 측정이 안정적입
• 우리는 통제합니다 (개선 조치가 가능합니다).
• 낮은 수집 비용.

3) 공식과 예

3. 1 가용성

Availability = Успешные запросы / Все запросы
Error Budget (за период) = 1 − SLO

예: SLO 99. 30 일 만에 9% → 오류 예산 = 0. 1% 로 43 분 12 초의 사용 불가능에 해당합니다.

3. 2 대기 시간

대기 시간별 SLO는 임계 값에 맞는 요청의 비율로 공식화됩니다

Latency SLI = доля запросов с duration ≤ T
SLO пример: 99% запросов ≤ 300 мс (rolling 28d)

3. 3 지불 (비즈니스 수준)

Payment Success SLI = (успешные проводки — внешние отказы PSP) / все попытки

4) 예산과 연소율 완화

예산 오류-혁신을위한 "연료 탱크" (릴리스, 실험).

• 빠른 채널 (~ 1 시간 감지),
• 느린 채널 (~ 6-12 h/24 시간 이상 추세).

• 연소 속도> 14 인 경우. 1 시간 4 분-SEV-1 (~ 100 분 안에 일일 예산을 먹을 것입니다).
• 6 시간 만에 화상 속도> 6-SEV-2 (빠른 저하).

5) SLO 경고 (멀티 윈도, 멀티 번)

오류 표시기: 5xx 또는 대기 시간 위반 비율.

promql
Доля ошибок за 5 минут sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

Быстрый burn (1m окно)
(
sum(rate(http_requests_total{status=~"5.."}[1m])) /
sum(rate(http_requests_total[1m]))
) / (1 - SLO) > 14.4

Медленный burn (30m окно)
(
sum(rate(http_requests_total{status=~"5.."}[30m])) /
sum(rate(http_requests_total[30m]))
) / (1 - SLO) > 2

대기 시간별 SLO의 경우 백분위 수 히스토그램을 사용하십시오

promql p95 latency histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

6) 도메인 별 SLI/SLO 예

6. 1 API 게이트웨이/엣지

SLI 오류: 5xx 응답률 <0. 1% (28d).
SLI-Latency: p95 λ250 ms (일).
SLO: 가용성 95% (분기).

6. 2 지불

SLI-Success: 성공적인 (클라이언트 오류 제외) 지불 8% (28d).

SLI-Latency: 99% (일) 에 대한 인증

SLO: Times-to-Wallet p95

6. 데이터베이스 3 개 (PostgreSQL)

SLI-Lag: 복제 지연 p95 체 1 초 (일).
SLI 오류: 쿼리 오류율 05% (28d).
SLO 클러스터 가용성 95%.

6. 4 대기열/스트리밍 (카프카)

SLI-Lag: 소비자 지연 p95 소 메시지 (시간).
SLI 내구성-99 항목을 확인하십시오. 99% (28d).
SLO: 중개인의 가용성은 99 이상입니다. 9%.

7) 신뢰성 프로세스 KPI

MTTD (탐지 할 평균 시간)

MTTA (... 인정하기 위해)

MTTR (... 복원하려면)

MTBF (... 실패 사이)

자동 완화 사고의%

최상위 트래픽 경로의 SLO/경고 범위 (대상 95% 이상)

카나리아 단계의 릴리스 공유

팀/기능별로 잘못된 예산의 소비

8) SLO를 현실적으로 만드는 방법

1. 측정 전류 기준 안정성 (3-4 주).
2. "민감한" 사용자 경로 (로그인, 예금, 게임) 를 정의하십시오.
3. 각 편차 비용 (시간, 돈, 평판) 을 고려하십시오.
4. 야심적이지만 달성 가능한 목표를 선택하십시오 (기준선에서 10-30% 개선).
5. 분기별로 검토하십시오.

• 정당화없이 즉시 "5 아홉".
• 사용자가 볼 수없는 메트릭으로 SLO (예: UX와 통신하지 않은 CPU).
• SLO → 포커스 스프레이가 너무 많습니다.

9) SLO 및 예산보고

• SLO 당 완료: 실제 대 목표, 추세, 자신감.
• 오류 소비 요약: 예산이 누구보다 "연소" 되는지 (릴리스/사고).
• 성능 저하의 5 가지 원인, CAPA 계획 및 작업 상태.
• 비즈니스 영향: 전환, ND, 유지, LTV.

10) 릴리스 정책과의 커뮤니케이션

오류 예산 <50% → 무료 릴리스.
50-80% → "주의 모드": 저 위험/카나리아 계산 만.

11) SLA (계약) -항목 템플릿

가용성 의무: 예를 들어 99. 9 %/월.
Force Majeure: 합리적인 통제를 넘어서는 DDoS, 타사 제공 업체.
측정 창 및 책임 영역: 지표 소스, 계산 방법.
크레딧/페널티: 레벨 테이블 (예: 60-120 분 → 크레딧 X%).
확대 및 알림 절차: 마감일, 채널.
데이터 및 개인 정보 보호: 마스킹, 스토리지, 법적 보류.
위반시 반복 예방 계획 (CAPA).

12) 측정 도구

수동 측정 항목: Prometheus/Mimir/Thanos, 수출 업체.
로그: 비즈니스 수준에서 성공/오류를 계산하기위한 Loki/ELK.
합성: cron에 의하여 활성 샘플 (로그인/예금/게임).
추적: p99 병목 현상을위한 Tempo/Jaeger.
지불/금융: 지불 SLI의 기본 진실 소스.

13) 쿼리 예 (템플릿)

promql
1 - (
sum(rate(http_requests_total{status=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m]))
)

yaml slo:
name: "API Availability"
window: "28d"
target: 0.999 sli: "1 - 5xx%"
owner: "Platform SRE"
alerting:
fast_burn: {window: "1h", factor: 14.4}
slow_burn: {window: "6h", factor: 6}

success_rate = (count_over_time({app="payments"}     = "status=success"[5m]))
/ (count_over_time({app="payments"}     ~ "status=(success    fail)"[5m]))

키> "고객 감소" 를 제외하는 필터 참조.

14) FinOps 및 신뢰성

9 당 비용: 9 개를 추가하는 비용이 기하 급수적으로 증가하고 있습니다.
혜택 곡선: 수익 증가/손실 감소가 추가 "9" 의 비용을 초과하는 최적의 경우.
SLO 포트폴리오: 경로마다 수준이 다릅니다 (중요 결제는 "더 비싸다", 보고는 "더 저렴하다").

15) SLO/경고 품질-점검표

• SLI는 UX 및 비즈니스 지표와 관련이 있습니다.
• 창과 집계는 일관됩니다 (28/4 분기 롤링).
• 다중 창 경고, 펄럭임 없음, 역할 기반 라우팅.
• 문서: 소유자, 공식, 소스, 런북.
• 잘못된 예산 및 화상 표시기가있는 SLO 데모 패널.
• 정기적으로 목표 검토 (분기 별).
• 주요 시나리오에 대한 합성 테스트.

16) 구현 계획 (4 회 반복)

1. 1 주차: 사용자 경로, SLI 초안, 기본 대시 보드 목록.
2. 둘째 주: SLO 공식화, 예산 책정, 경고 (빠른/느린 화상).
3. 셋째 주: 사고/릴리스 프로세스와의 통합, 동결 규칙.

4. 4 주차 이상: 계약 SLA, 분기 별 리뷰, "9 당 비용" Finops 모델

17) 미니 -FAQ

서비스 당 하나의 SLO가 필요합니까?
수십 개의 2 차 키 대신 2-3 개의 핵심 키 (성공 + 대기 시간) 가 더 좋습니다.

예산이 소진되면 어떻게됩니까?
안정화 및 CAPA에 중점을 둔 냉동 릴리스는 실험 기능을 제거합니다.

방출 속도와 신뢰성 사이의 충돌을 피하는 방법?
계획은 "예산에 따라" 출시되며 카나리아 계산 및 기능 플래그를 구현합니다.

결과

신뢰성은 일련의 서로 다른 지표에 의해 제어되는 것이 아니라 시스템에 의해 제어됩니다: SLI → SLO → 예산 오류 → 연소 경고 → 사고 프로세스 → CAPA → SLA. 정의, 데이터 소스 및보고를 표준화하고 목표를 사용자 경험 및 경제에 연결하며 실제 ROI를 기반으로 9 개를 정기적으로 검토합니다.