인프라 KPI 및 가동 시간

왜 필요합니까?

인프라 KPI는 안정성에 대한 "감정" 을 측정 가능한 목표로 바꾸고 위험과 업무 집중을 관리합니다. 올바른 측정 항목은 기술 SLI를 비즈니스 결과 (변환, Time-to-Wallet, LTV) 에 연결하고 혁신 대 신뢰성의 개발, 로드 및 공유를 계획 할 수 있습니다.

기본 개념: SLI, SLO, SLA 및 오류 예산

SLI (서비스 수준 지표) - 품질 지표 측정: 성공적인 요청 비율, p95 대기 시간, 간격 가동 시간.
SLO (서비스 수준 목표) - SLI 목표 (예: "성공 99 이상. 30 일 만에 9% ").
SLA (계약) -처벌/크레딧이있는 외부 약속. 항상 SLO에서 파생되었지만 동일하지는 않습니다.
오류 예산 = '1-SLO'. 이것은 측정 창당 최대 허용 실패율입니다. 위험한 릴리스 및 실험에 대한 결정을 내리는 데 사용됩니다.

• 가용성 SLO 99. 30 일 동안 95% → 오류 예산 0. 05% ≈ 21. 한 달에 6 분의 "실패".

4 개의 금 신호 및 추가

1. 대기 시간 (p50/p90/p95/p99, 꼬리는 평균보다 중요합니다).
2. 오류 (5xx/타임 아웃/비즈니스 오류).
3. 트래픽/처리량 (RPS/QPS, MBps).
4. 포화 (CPU/RAM/IO/FD/연결/GC/할당량).
추가: 콜드 스타트, 큐/백 로그, 배포 시간, SLO 준수.

다양한 유형의 서비스에 대한 SLI 모델

STP/API

가용성: '(성공적인 2xx/3xx- 논리 오류 )/( 모든 요청)'

대기 시간: 성공적인 쿼리를위한 'p95'; 뜨거운 경로를 목표로합니다

품질: '청중/범위' 가 올바른 요청 비율 (작성 오류 없음).

대기열/비동기식

메시지 처리 시간: p95 엔드 투 엔드

백 로그: 중앙값 <X, 꼬리 p99 <Y.
배송 오류: λZ ppm.

DB/캐시

작동 대기 시간: p95를 얻거나 넣거나 커밋하십시오.
포화: 연결 풀 사용량, 캐시 적중 비율.
오류: 타임 아웃, 교착 상태, 퇴거 폭풍.

CDNA/정적

적중 비율: 목표 수준 분해 → 원산지 부하 성장.
팝 가용성: 어쨌든 실패는 이웃에 의해 보상됩니다.

지불 (비즈니스 SLI)

지갑 시간 p95, 예금/출력 성공률%, PSP 실패율.

가용성 및 가동 시간 계산

서비스 가용성 = '성공적인 요청/모든 요청' (바람직하게는 '가동 시간' 이 아님).
인프라 노드의 대안은 '녹색 시간/창 시간' 입니다.
달력 창: 28-31 일, 슬라이딩 창: 지난 30/90 일.
근무 시간/중요 창: 일정에 따라 가동 시간을 고려할 수 있습니다 (예: 현지 시간 08: 00-22: 00).

• '가용성 (A) Av (B) × Av (C) × Av (A' B, C) '-경계에 SLO를 배치하는 것이 중요합니다.

예제 SLO 키트 (샘플)

게이트웨이 API: 99 이상 사용 가능 95 %/30d; p95 대기 시간 오류 제곱 0. 2%.
체크 아웃/지불: 예금 성공 98 이상. 5 %/30d; 타임 투 월렛 p95 PSP 타임 아웃 3%.

데이터베이스: p95는 10ms를 읽습니다. p95 쓰기 소수 자릿수 25ms; 레플리카 지연 p95 소 150

캐시: 적중률 85% 이상; 퇴거 폭풍 = 0/30m2.
지불 시간: p95 처리 사기-낙하-긍정 3%.

오류 예산 및 변경 관리

창 중간 이전에 오류 예산이 50% 이상 소진되면 기능/릴리스의 "동결" 이 도입되면 안정화에 중점을 둡니다.
예산이 느리게 소비되면 실험/카나리아 속도를 높일 수 있습니다.
'release _ id' 를 통해 예산 소비를 특정 릴리스/사고에 연결하십시오.

경고: 헛된 "밤에 전화" 하지 않는 방법

SLO 분해 및 각 증상에 대해서만 경고하지 않습니다.
다중 창, 멀티 번 속도: 짧은 창 (5-15 분) + 긴 창 (1-6 시간).
예: "5 분 14 ×, 1 시간 6 ×" → 호출 페이지.
비 P1 신호에 대한 조용한 시간; 소유권 라우팅.

대시 보드 및 시각화 관행

SLO 패널: 서비스 준수, 남은 예산, 종속성 맵.
대기 시간 패널: p50/p90/p95/p99, 노선/테넌트/국가/ASN 별 분해.
오류 패널: 코드/이유, 릴리스/기능 플래그와의 상관 관계.
용량 패널: CPU/RAM/IO/네트워크/FD/연결, 동향 및 예측.
비즈니스 패널: 전환, 지갑 시간, 예금/철회, 보호 영향 (WAF/안티 봇).

사건, MTTR 및 사후 사후

• MTTD (감지), MTTA (수락), MTTR/MTTC (복구/격리), 제 시간에 RCA가없는% 사고.
• 플레이 북: 에스컬레이션, 기능 플래그/블록 켜기 방법, 릴리스 롤백 방법, 비즈니스와의 커뮤니케이션.
• 사후 (흠없는): 사실, 타임 라인, 근본 원인 (그/프로세스), 행동: 즉시/장기, 회귀 테스트, SLO에 미치는 영향.

성능, 채도 및 분해

헤드 룸: 대상 리소스 헤드 룸 (예: CPU <70% p95, RAM <75% p95).
뜨거운 길: 중요한 경로 프로파일 링; 'p99' 는 평균보다 중요합니다.
분해 모드: 캐시 전용, 읽기 전용, 중요하지 않은 요청의 드롭 그라인딩, "속도 제한 "/할당량.

공식 및 계산 예

1) 주문형 가용성

availability = (total_requests - error_requests) / total_requests

여기서 '오류 _ 요청' = 5xx + 타임 아웃 + 비즈니스 오류 (구성 가능).

2) 오류 예산 (분)

error_budget_minutes = window_minutes (1 - SLO)

예: 30 일 (43,200 분), SLO 99. 95% → 21. 6 분

3) 화상 속도

burn_rate = observed_error_ratio / (1 - SLO)

SLO 99 인 경우 9% (예산 0. 1%) 및 오류 1% → burn _ rate = 10 ×

4) 복합 가용성

A_total ≈ A_gw × A_auth × A_db × A_psp

작은 낙하 곱셈이 전체 A에 영향을 미칩

측정 및 예외 정책

예정되지 않은 창 (사고) -고려됩니다.
계획된 유지 보수 창-SLA가 처방 된 경우에만 고려됩니다. SLO의 경우 종종 공제되지 않습니다 (또는 '계획된 _ 다운 타임' 으로 별도로 표시).
합성 대 실제 사용자: 두 채널 (RUM + 합성 검사) 을 모두 갖는 것이 유용합니다.

아티팩트의 예

KQL/PromQL (아이디어)

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

promql histogram_quantile(0. 95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, route))

promql
(
sum(rate(errors_total[5m])) / sum(rate(requests_total[5m]))
) / (1 - 0. 999)

SQL (결제 비즈니스 SLI)

sql
SELECT date_trunc('minute', finished_at) AS ts,
100. 0 sum((status='SUCCESS')::int)::float / count() AS payment_success_pct,
percentile_cont(0. 95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (finished_at - started_at))) AS ttw_p95_sec
FROM payments
WHERE finished_at > now() - interval '30 days'
GROUP BY 1 ORDER BY 1;

종속성 및 계단식 관리

팀 간의 SLO 계약: 게이트웨이 표준 지갑 PSP.
분해 정책: 종속성이 떨어지면 서비스는 "단순화 된 모드" 로 전환됩니다.
기능 플래그: 중요하지 않은 기능 비활성화, 대기 시간을 줄이기위한 "회색 릴리스".

용량 계획 및 예측

Schomes. 트렌드 및 이벤트 (토너먼트, 경기, 프로모션) 별로 예측되는 RPS/MBps.
PSP/지불에 대한 별도의 테스트 인 "골든 경로" 로드 테스트.
최고 재고: 목표 계수 1. 3 × -2. 예상 하중의 0 배.

SLO/KPI 구현 체크리스트

1. 중요한 사용자 경로를 식별하고 "고객의 관점에서" SLI를 협상합니다.
2. SLO 대상 및 창 선택 (30/90 일); 오류 예산을 계산하십시오.

3. 게이트웨이/서비스에 미터법 수집을 구축하고 코드/이유를 정규화하십시

4. 연소율 알림 (짧은 + 긴 창), 라우팅 및 통화 중 설정.
5. SLO 준수를 시각화하고 릴리스/기능 플래그와 연관시킵니다.
6. 변경 정책 및 동결 프로세스에 대한 예산을 만듭니다.
7. 각 초과, 회귀 테스트에 대한 회고 및 RCA.
8. 실제 예산 사용 및 비즈니스 목표는 분기별로 SLO를 검토하십시오.

일반적인 실수

응용 프로그램 오류를 무시하고 "핑으로 가동 시간" 을 측정하십시오.
SLO는 "예약 중" (99) 으로 설정됩니다. 999%), 달성 할 수없고 아무것도 해결하지 못합니다.
사용자 증상 대신 저수준 지표에 대한 경고.
종속성 맵이 없습니다 → 불타는 곳이 명확하지 않습니다.
SLO와 릴리스 → 사이에는 누가 예산을 "먹었는지" 명확하지 않습니다.
p99 꼬리를 무시하십시오 → 좋은 평균이지만 나쁜 UX VIP 사용자.

iGaming/fintech 특정

예정된 피크: 일치/이벤트/프로모션-사전 용량 증가, 워밍업 캐시/CDN에는 특수 제한 프로파일이 포함됩니다.
비즈니스 SLI: Time-to-Wallet, 예금/인출 성공, "지불 속도" p95; 대시 보드의 뿌리에서.
PSP/파트너: 공급자 별 개별 SLO/대시 보드, 자동 경로 전환.
안티 봇/사기 방지: 오류에 대한 예산이 없어야합니다. "합법적 인 블록" 과 "기술적 오류" 를 분리하십시오.
규제: 로그 저장, SLO/SLA 계산의 재현성, 사고 보고서.

FAQ

SLO에서 계획된 작업을 빼야합니까?
일반적으로 아님: SLO는 사용자가 경험 한 경험을 반영합니다. SLA에 대한 예외를 지정할 수 있습니다.

왜 p95가 아닌가?
가운데는 꼬리를 가리고 있습니다. UX는 꼬리를 정의합니다 (p95/p99).

전체 제품에 대해 하나의 SLO를 가질 수 있습니까?
중요한 경로/구성 요소별로 제품별로 집계하는 SLO 트리가 필요합니다.

합계

강력한 인프라 KPI 시스템은 맞춤형 SLI, 현실적인 SLO, 변경 제어 수단으로서의 오류 예산, 스마트 경보 및 사고 규율 및 RCA입니다. 기술 지표를 비즈니스 지표, 자동화 수집 및 시각화와 연결하면 인프라가 예측 가능해지고 최대 시나리오에서도 가동 시간이 제어됩니다.