SLO/SLA 및 메트릭

SLO/SLA 및 메트릭

1) 이용 약관

SLI (Service Level Indicator) - "사용자가 볼 때" 측정 가능한 지표: 성공적인 요청 공유, p95 대기 시간, 데이터 신선도, 성공적으로 처리 된 배치 공유 등

SLO (서비스 수준 목표) - 관찰 간격 (28/30/90 일) 에서 SLI 값을 목표로합니다. 예: "99. 요청/지불 종료의 9%

오류 예산 - 1-SLO. SLO 99에서. 9% 오류 예산 = 0. 시간/요청의 1%.
SLA (계약) - 법적으로 중요한 서비스 수준: SLO, 측정, 예외, 보상/벌금 포함.

2) 디자인 원칙

증상> 내부 지표. SLI는 실제 사용자 경험을 반영해야합니다.
소수의 주요 SLI. 서비스-2-5 메인: 성공, 대기 시간, 처리량/신선도, 정확성.
중요한 경로의 적용 범위. 각 비즈니스 시나리오 (체크 아웃, 로그인, 웹 후크, ETL 다운로드) 에는 자체 SLI/SLO 세트가 있습니다.
엄격한 "성공" 의미론. "코드 200" 이 아니라 "사용자가 정시에 응답을 받았으며 결과가 유효합니다".
외부 및 내부 SLO 분리. 내부-더 엄격한; 외부 SLA 소 1-2 9 더 낮습니다.

3) SLI 카탈로그 (참조)

3. 1 API/온라인 서비스

성공: 'SLI _ success = 1- (5xx + 타임 아웃 + 비즈니스 _ 오류 )/모든 요청'

대기 시간: 경로/방법/테넌트에 의하여 p95/p99 'http _ server _ guidence _ seconds'

대역폭: 'RPS '/한계/할당량

정확성: 유효한 응답의 비율 (서명, 스키마, 불변)

3. 웹 후크 2 개/비동기 배송

배송: T 초 단위로 확인 된 이벤트 비율 및

고객: 지연이없는 가입자 비율 (임차인 당)

3. 3 데이터/ETL/DWH

신선도: '이제 마지막 _ 성공 _ ingest _ ts'

완전성: 'inested _ rows/respended _ row'

정확성: 품질 점검을 통과 한 기록의 비율

파이프 라인: 마감일 전에 완료된 작업의 비율

3. 4 모바일/클라이언트 SDK

클라이언트 성공: 치명적인 오류가없는 세션의

왕복 대기 시간: 요청에서 렌더링까지 p95

캐시 적중: 캐시에서 제공되는 비율 (성능 증상)

4) 공식과 목표의 예

• 'SLI _ req _ aide = 1- (실패 _ 요청/총 _ 요청)'
• 'SLO _ req _ aide = 99. 30 일 동안 95% '→ 오류 예산 = 0. 요청의 05%.

• 'uptime = (obs _ 창-다운 타임 )/obs _ window'

• 캐시 워밍업 (1%) 을 제외하고 7 일 슬라이스에서 'SLO _ latency = p95 (경로 = "/지불 ")

• 'SLO _ freshness (dataset = "order") 24 시간 내에 10 분' p99.

5) 예산 및 변경 관리 오류

예산 (B): 'B = 1-SLO'.
화상-허용 가능한 오류에 대한 실제 오류의 비율.

• 초과 지출 (연소> 1) → 동결 기능, 신뢰성에 중점을 둡니다.
• 짧은 창에서 연소율> X에서-사고 및 캡. 측정.
• 계획: 스프린트의 신뢰성 점유율은 과거 기간 동안의 화상과 관련이 있습니다.

6) 경고: 연소율 및 다중 창 규칙

아이디어: 우리는 빠른 누출과 느린 드리프트를 잡습니다

• 중요: "1 시간 안에 2% 예산" (빠른 화재).
• 경고: "6 시간 동안 예산의 5%" (크리핑 열화).

• 빠른 사고에 대한 짧은 창 (분 시간).
• 트렌드에 대한 긴 창 (6-24 시간).
• 대기 시간: 미량 인스턴스와의 플랩 및 통신 억제와 함께 p99> 임계 값 이상 5 분 경고.

error_ratio_5m = errors[5m] / requests[5m]
error_ratio_1h = errors[1h] / requests[1h]
burn_5m     = error_ratio_5m / error_budget_fraction burn_1h     = error_ratio_1h / error_budget_fraction alert_critical if burn_1h > 14 and burn_5m > 14 alert_warning  if burn_6h > 6 and burn_30m > 6

7) 다중 세입자 및 세분화

SLI/SLO는 세입자/계획/지역에 따라 계산되며, 그렇지 않으면 중앙값이 고장을 "덮습니다".
통계적 유의성을위한 최소 이벤트 수 (가드 레일).
SLA는 관세가 다를 수 있습니다 (예: "Pro 99. 9%, 무료 99. 5%»).

8) 관찰 가능성 및 흔적과의 연관

SLI 지표-예를 들어 히스토그램/카운터에서 "나쁜" 트레일로 전환합니다.
로그는 타임 아웃, 비즈니스 오류 코드, 제한 사항의 원천입니다.
데이터의 경우-계보와의 링크: "신선도 측정을 지연시키는 작업".

9) 계약 및 SLA

• SLI/측정 방법/창 정의.
• 예외 (계획된 작업, 강제 전공).
• 사건 및 통신 절차 (상태 페이지, RFO/RCA).
• 서비스 크레딧 및 요청 순서.
• 관할권, 유효 기간, 개정 조건.

• 아키텍처 및 운영 관행이 허용하는 것보다 SLO를 더 엄격하게 공개적으로 약속하지
• 별도의 내부 SLO 및 외부 SLA.

10) 비용과 우선 순위

9의 가격은 선형으로 증가하지 않습니다. «99. 9% → 99. 99% "= 다른 아키텍처 클래스 (N + 1, 다중 영역, 자산 간).
SLO를 가장 귀중한 사용자 작업에 배치하십시오.
원격 측정 비용 (다운 샘플링, 할당량, 복제 및 저장) 을 클래스별로 제어하십시오.

11) 절차 및보고

주간 보고서: 서비스/테넌트 별 SLO 실행, 예산 지출, 주요 이유, 개선 계획.
사건 후 RCA: 우리는 예산의 일부와 관련이 있습니다. 근본 원인을 제거하는 작업을 설정했습니다.
Fichfriz: 포함/철회 기준.

12) 템플릿 (빠른 시작을 위해)

12. SLO 카드 1 개 (예)

Service: Checkout API
SLI:
success: 1 - (5xx+timeouts+biz_failures)/all latency_p95: p95(http_server_duration_seconds{route="/pay"})
SLO:
success: 99. 95% / 30d latency_p95: ≤ 400ms / 7d
Windows:
primary: 30d rolling secondary: 7d rolling
Burn Alerts:
critical: use 1h/5m > 14 warning: use 6h/30m > 6
Owner: Team Checkout
Tenancy: per-tenant (≥ 1k req/day threshold)
Dashboards: RED + trace exemplars

12. SLO 성숙도 표 2 개

13) 규칙의 예 (조각)

promql
Error rate (5xx + timeout) for the sum (rate (http_requests_total{route="/pay",code=~"5. route.    599"}[5m]))
/ sum(rate(http_requests_total{route="/pay"}[5m]))

p99 histogram_quantile latency (0. 99, sum(rate(http_server_duration_seconds_bucket{route="/pay"}[5m])) by (le))

promql error_budget_fraction = 0. 001 for 99. 9%
(err_rate_5m / 0. 001 > 14) and (err_rate_1h / 0. 001 > 14) # critical
(err_rate_30m / 0. 001 > 6) and (err_rate_6h / 0. 001 > 6)  # warning

promql
Data order lag (minutes)
(max(time()) - max(last_ingest_ts_seconds{dataset="orders"})) / 60

14) 데이터 및 ML 용 SLO (기능)

엔드 투 엔드 데이터 SLO: p99 신선도, p99 완전성, 충돌 후 "재 처리" 시간.
데이터 계약: 예상 체계, 볼륨, 마감일; 데이터 위반 → 사건.
ML: 추론 대기 시간을위한 SLO, 피처 가용성을위한 SLA, 드리프트 모니터링 (모델 품질은 SLA 외부의 별도 주제 임).

15) 보안 및 개인 정보 보호와의 통합

PII/비밀없이 SLI 로그; 토큰 화/마스킹.
감사는 SLO/SLA로 변경되고 불변의 로그에 출판물을보고합니다.
규제 경로 (지불/PII) 의 경우-별도의 더 엄격한 SLO.

16) 점검표

서비스/기능을 시작하기 전에

• 성공/대기 시간/처리량/신선도 SLI가 정의되었습니다.
• SLO 및 정의 된 창; 오류 예산이 계산됩니다.
• 연소율 경고를 설정하십시오 (짧은 + 긴).
• 대시 보드 RED + 예제 → 경로; 사건 룬 문서.
• 다중 임대 섹션 및 중요도 임계 값.
• 피치 프리즈 및보고 절차.

작동

• SLO/burn 주간 보고서, 계획 강화.
• 아키텍처/로드가 변경 될 때 SLO를 재평가하십시오.
• 정기적 인 "드릴 사건" 및 룬북 업데이트.
• 원격 측정 비용 및 SLI 수를 모니터링하십시오.

17) 런북

런북: 빠른 성장 p99/지불

1. 경고 p99> 임계 값 → 대시 보드를 엽니 다 → 모범을 통해 추적하십시오.
2. 좁은 CLIENT/SERVER 스팬을 찾고 지역/버전을 비교하십시오.

3. 열화 (캐시/제한/대체) 사용, 종속성 명령 알림

4. 안정화 후-RCA, 최적화 작업, SLO 측정 업데이트.

런북: 주당 예산 지출> 50%

1. 기능을 동결하고 신뢰성 우선 순위를 높입니

2. 오류 클러스터링: 경로/테넌트/종속성.
3. 롤아웃 수정 → 추세 복구를 확인합니다.
4. 회고 및 경고/임계 값 조정.

18) FAQ

Q: 몇 개의 SLO가 필요합니까?
A: 중요한 사용자 시나리오의 최소: 성공 + 대기 시간. 다른 모든 것은 필요하지 않습니다.

Q: 시간별 또는 요청에 따른 가용성은 무엇입니까?
A: 주문형-더 많은 사용자 지표. 네트워크 구성 요소/인프라에 시간이 편리합니다.

Q: 왜 평균이 아닌 p95?
A: 가운데는 꼬리를 숨 깁니다. 사용자는 p95/p99를 느낍니다.

Q: "나사를 너무 많이 조이지" 않는 방법은 무엇입니까?
A: 현실적인 목표 (과거 데이터) 로 시작한 다음 성숙함에 따라 강화하십시오.

• "관찰 가능성: 로그, 메트릭, 추적"
• "분산 추적"
• "감사 및 불변의 통나무"
• "웹훅 배송 보증"
• "대중 교통/휴식 시간에 암호화"
• "데이터 원점 (리니지)"