SLA 및 SLO 모니터링

1) 이용 약관

SLA (서비스 수준 계약) - 고객에 대한 외부 계약 의무 (페널티 조항, 크레딧).
SLO (Service Level Objective) - SLA 실행을 지원하는 내부 서비스 수준을 대상으로합니다.
SLI (서비스 수준 지표) - SLO/SLA가 평가되는 기준으로 측정 된 표시기.
오류 예산-해당 기간 동안 "비가 용량/오류" 의 허용 비율: '예산 = 1-SLO'.
범위: 사용자의 눈 (엔드 투 엔드) 으로 측정됩니다. 마이크로 서비스에서 구성 요소 레벨과 엔드 투 엔드 경로 레벨 모두에서.

2) SLI 선택: 정확히 측정해야 할 것

기준은 사용자 경험 및 비즈니스 가치와의 상관 관계입니다.

• 가용성: 성공적인 요청의 백분율. 'SLI = 성공/모두'.
• 대기 시간: 요청 비율이 임계 값 T.보다 빠릅니다. 'SLI = P
• 품질: 정답의 비율 (5xx/functs 없음). 오류).
• 최신 데이터-복제 대기 시간/ETL
• 비즈니스 프로세스 성과: 성공적인 결제/등록 비율.

반 패턴: 비즈니스 실수를 무시하고 200 개만 "성공" 으로 간주하십시오. 사용자 네트워크 대신 테스트 네트워크에서 측정

3) 공식 및 관측 창

• '가용성 = (확인 요청/모든 요청) × 100%'.

• 'P95 λT' → 는 주식으로 더 잘 공식화됩니다: 'SLI = 요청의%
• 예: "28 일 동안 검색 쿼리의 99%
• 슬라이딩 창: 28 일 또는 30 일 (감도 및 안정성의 균형). 사고의 경우-추가 창문: 1 시간, 6 시간, 24 시간

4) 예산 오류 및 변경 속도 제어

계산: 'SLO = 99에서. 9% '예산 =' 0. 기간 당 1% 의 오류/사용 불가.

• 예산> 50%: 릴리스 및 계획 실험.
• 예산 10-50%: 저 위험 방출, 카나리아 강화.
• 예산 <10%: 방출 동결, 근본 원인, 신뢰성 향상.
• 프로그레시브 릴리스와의 연결: 카나리아/피처 플래그는 예산을 복용량으로 "먹습니다".

5) 경고 정치인: 임계 값에서 연소율까지

왜 "daupal SLO-경고를 제기하지 않았습니까?": 너무 늦었습니다. 사전 활동이 필요합니다.

• 'BR = (짧은 창에서 오류 관찰/이 창에서 허용되는 오류)'.
• 'BR> 1' 인 경우 예산이 정상보다 빠르게 소비됩니다.

• 빠른 경보 (잡음이 민감하고 재난이 발생합니다): 창 5-10 분, 임계 값 BR 14-20 ×.
• 느린 경고 (크리핑 저하를 포착): 창 1-6 시간, 임계 값 BR 2-4 ×.
• 조합 조건: 빠르거나 느리게 작업-호출 중 페이징.
• 레벨: 사용자 SLO 용 호출기, 내부 SLI의 회색 저하를위한 티켓/알림.

6) 관찰 가능성과 진실의 근원

로그-원인 진단.
측정 항목-수치 SLI (성공/오류, 대기 시간 백분위 수, 분수, 카운터).
트레일-경로를 통해 "핫" 세그먼트의 현지화.
합성 - 주변 (지역 인식) 의 활성 샘플.
실제 이벤트-RUM/고객 원격 측정, 비즈니스 지표 (전환, 성공적인 지불).

요구 사항: 릴리스 및 사건 대시 보드의 단일 그림, 주석 "버전/카나리아/플래그".

7) SLO 디자인: 단계별 템플릿

1. 중요한 경로를 설명하십시오 (예: "카드 예금").
2. SLI 정의: 성공/오류, 대기 시간 임계 값, 완전성.
3. SLO 동의: 28 일 목표 + 예외 (예약 된 창).
4. SLA에 연결: 법적 의무는 실제 SLO를 혼란스럽게합니다.
5. 서비스 소유자, RACI 및 경고 채널을 할당합니다.
6. 경보 정책 (2 창 BR) 및 자동 롤백을 정의하십시오.
7. 구현보고: 주간 예산 검토, 사후 검토.
8. 분기별로 SLO 검토 (로드/아키텍처 변경).

8) SLO 예 (템플릿)

• 이용 가능 여부는 다음과 같습니다. 95% '(발표 된 창을 제외한 28d, 월 30 분/월).
• 대기 시간: '
• 비즈니스 운영의 성공: 'λ98. 5% 의 성공적인 승인 (사기 필터가 고려 됨).

• 대기 시간: '확장 99%' 요청 '계정 300ms'.
• 캐시 관련성: '

• 배송: '이하 99. '지정 60 초' 의 경우 9% '(레트라가있는 엔드 투 엔드).
• 손실: 'λ0. 01% '메시지 (dedempotency/deduplication 활성화).

9) 다중 지역 및 다중 임차인

"코호트 별" SLO: 국가, 결제 제공 업체, VIP 세그먼트, 장치.
가장자리의 로컬 SLO: 사용자와 가장 가까운 지점의 메트릭 (가장자리/PoP).
집계: 총 SLO는 중요한 코호트에서 실패를 숨기지 않아야합니다.
스위칭 제공 업체: SLO 게이트 레벨의 자동 폴백 경로.

10) 대시 보드 및보고

출시 대시 보드: 버전, 카나리아 (% 트래픽), SLI (성공/대기 시간), BR, 플래그 주석.
운영 대시 보드: 하루 별 연소 예산, 최고 사건, MTTR, 문제 코호트.
주간 보고서: 예산 균형, BR 동향, 기술 부채 (병목 현상), 개선 계획.

11) 프로세스: 사건, RCA 및 개선

사건 관리: 경고 → BR 평가 → 카나리아/플래그 규모 → 롤백/수정.
RCA (근본 원인): SLI의 사실/타임 라인/가설/수정/효과 검사.
학습 된 교훈: 사후 처벌, 소유자가있는 필수 조치 항목 및 마감일.
루프 클로저: 테스트, 기능 플래그, 한계, 캐시, 배송, 할당량 변경.

12) 준수 및 감사

제어 아티팩트 (코드 정책, 불변의 로그) 로서의 SLO/SLI.
요구 사항에 연결하십시오 (예: 결제 거래 가용성).
증거: 경고 시간, 예산 보고서, 릴리스/롤백 로그.

13) 빈번한 실수와 피하는 방법

“99. 99% 또는 사망 ": 달성 할 수없는 목표 → 일정한 경보 소음. 사실적인 SLO를 선택하십시오.
전 세계 평균은 로컬 딥을 숨기고 → 코호트를 소개합니다.
e2e가 아닌 메트릭: 클라이언트에서 실제로 저하되는 동안 높은 SLO → 는 RUM/합성물을 추가합니다.
한 임계 값에 대한 경고 → 두 창 연소율로 전환합니다.
변경 사항에 대한 링크가 없습니다 → 릴리스에 주석이 달리지 않고 자동 롤백이 없습니다.

14) 미니 구현 점검표

• 중요한 경로와 SLI/SLO가 설명되어 있습니다.
• 모니터링 및 제외 창이 설정되었습니다.
• 2 창 BR 경고 (빠르고 느린) 가 구성됩니다.
• 버전/플래그의 주석이 달린 릴리스 및 작업 대시 보드.
• 오류 예산 정책은 릴리스에 영향을 미칩니다.
• 정기 예산 검토 및 사후 RCA.
• 문서 및 스코어 카드 소유자.

15) 계산 예 (특정)

API 가용성 SLO: 99. 28 일 만에 9% → 예산 = 0. 1%.
7 일 동안 0이 누적되었습니다. 오류의 06% → 는 주간 예산의 60% 를 사용했습니다.
15 분의 짧은 창에서 오류의 2% 가 관찰됩니다. 이 창에서 유효한 것은 '0입니다. 1% × (15 분/40320 분) 000037%`.
굽기 비율 1 (수십 ×) → 빠른 호출기가 트리거되고, 카나리아가 1% 로 롤백되고, 저하 지불 -UX 기능 플래그가 켜지고, RCA가 시작됩니다.

16) 결론

SLA/SLO 모니터링은 보고서의 숫자 일뿐만 아니라 변경 위험과 서비스 품질을 관리하는 메커니즘입니다. 올바른 SLI, 실제 SLO, 오류 예산 관리, 2 창 연소율 경고 및 e2e 관찰 가능성은 메트릭을 작동 솔루션으로 전환합니다. 값을 더 빨리 릴리스하고 사용자 경험을 예측할 수 있습니다.