가동 시간 보고서 및 SLA 감사

1) 왜 공식적인 가동 시간보고 프로세스가 필요합니까?

고객의 신뢰와 계약 투명성-단일 측정 기술, 반복 가능한 계산.
SLO 및 오류 예산 관리-가용성 사실을 릴리스 및 사고와 연결합니다.
올바른 SLA 대출은 객관적인 공식, 예측 가능한 지불/상쇄입니다.
법적 지속 가능성-증거 기반, 독립적 인 감사, 법률 보유.

2) 이용 약관

SLI 가용성-기간 당 성공적인 검증/거래 비율.
SLO-내부 대상 (예: 99. 28 일 만에 95%).
SLA-외부 약속 (예: 99. 9 %/월 + 서비스 대출).
측정 창-달력 월 (SLA) 및 롤링 창 (SLO).
범위-계산에 포함 된 구성 요소 (에지, API, 결제) 및 그렇지 않은 구성 요소 (관리 포털, 비 prod).

3) 진리의 근원 (그리고 어느 것이 책임이 있는지)

1. 합성 (블랙 박스/헤드리스) 은 "사용자 눈 접근성" 을위한 기본 SLI입니다.
2. 로그/메트릭-고장의 규모와 특성을 확인하십시오.
3. 비즈니스 이벤트는 "거래 성공" (예: 결제 승인) 입니다.
4. 상태 페이지 - 공개 커뮤니케이션 사실 1-3에 대해 확인됩니다.

불일치의 경우: 2 개 영역에서 올바른 정족수를 사용하는 합성에 우선 순위가 부여됩니다.

4) 가용성 계산 방법론

4. 1 기본 공식

Availability = Успешные проверки / Все проверки
ErrorBudget = 1 − SLO
Downtime(m) = (1 − Availability) × Длительность_периода(в мин)

4. 2 다지역 정족수

20N 독립 지역/ASN이 동시에 실패를 기록하면 사고가 계산됩니다.
권장: N = 2/3 (EU/NA/APAC).

4. 3 가지 SLI 유형

상태가 어떻게 되나요?
DNA/SL SLI: NXwitzer/SERVFAIL/만료.
SLI 비즈니스: 성공적인 거래/모든 시도 (고객 실패 제외).

4. 4 예외 (문서화)

예정된 유지 보수 창은 N 시간 전에 선언되어 관찰되었습니다.
증거와 공개 통지가있는 경우에만 SLA (예: IX 재난 제공 업체) 의 강제 전공.
클라이언트 오류/제한 (할당량 초과, 4xx).

5) 창 유지 보수 정책

계약에 동의 한 타임 슬롯 (예: 일요일 02: 00-04: 00 UTC + 0).
'유지 관리 = 경고/패널의 진정한 마커 → SLI에서 제외.
알림 임계 값: 5 일 이상 (또는 계약에서와 같이).
창 밖으로-SLA 영향이 고려됩니다.

6) 가장자리 케이스 및 반올림 규칙

브라운 아웃 (부분 저하): "0/1" 이 아닌 고장 백분율 (가중 다운 타임) 을 계산하십시오.
플래핑: 최소 계정 단위-샘플 간격 (예: 30-60 초) + 히스테리시스 (2-5 분).
시계 드리프트: UTC 및 ISO-8601의 모든 시간; NTP 동기화.

7) PromQL의 예 (합성 → 가동 시간)

promql probe_success{job="blackbox-http"} == 1

promql histogram_quantile(0.95, sum by (le, target) (rate(probe_http_duration_seconds_bucket[5m])))

promql sum_over_time((probe_success==1)[30d]) / (30246060)

promql sum by (target) (max_over_time((probe_success==0)[3m])) >= 2

8) SQL의 예 (보고 집계)

sql with checks as (
select target, ts, success -- success: 1/0 from synthetic_checks where ts >=:from and ts <:to
),
agg as (
select date_trunc('month', ts) m, target,
sum(success)::float / count() as availability from checks group by 1,2
)
select m, target, availability,
(1-availability) extract(epoch from (date_trunc('month', m) + interval '1 month' - date_trunc('month', m))) / 60 as downtime_minutes from agg;

sql select a.m, a.target, a.downtime_minutes, s.incident_id, s.start_utc, s.end_utc from monthly_downtime a left join statuspage_incidents s on a.m = date_trunc('month', s.start_utc)
and tstzrange(s.start_utc, s.end_utc) && daterange(a.m, a.m + interval '1 month');

9) 월간 보고서 템플릿 (고객 친화적)

yaml period: "2025-10-01..2025-10-31 (UTC)"
services:
- name: "API Edge"
sla: "99.90%"
measured_availability: "99.93%"
downtime:
total: "30m 14s"
windows:
- start: "2025-10-12T03:12Z"
end:  "2025-10-12T03:38Z"
impact: "EU+NA, HTTP 5xx spike, p95>2s"
root_cause: "DB connection pool exhaustion"
rca_link: "INC-20251012-0312"
slo_budget:
period_target: "0.10%"
consumed: "0.07%"
- name: "Payments API"
sla: "99.95%"
measured_availability: "99.97%"
summary:
sla_breaches: 0 service_credits: 0 maintenance:
announced: 2 total_duration: "48m"
signatures:
generated_at: "2025-11-01T10:00Z"
report_id: "SLA-2025-10-API"

10) SLA 크레딧: 계산 및 적용

크레딧 표: 예를 들어 99. 0–99. 5% → 5% MRR; 98. 0–99. 0% → 10% 등

진실: 신용은 다음 계정에 신용 메모로 적용됩니다.
자동화: "'측정 된 _ 가용성 <SLA' → '신용 _ 노트 규칙. () '를 만듭니다.
클라이언트 쇼케이스: 포털 카드 "SLA 크레딧 잔액".

11) 감사, 증거 및 법적 보류

감사 흔적: 누가/무엇을/언제 계산했는지, 방법론 버전, 체크섬.
원시 데이터는 불변입니다 (추가 전용). 별도의 레코드로 조정.
법적 보류: 데이터 범위 동결 (샘플, 로그, 사건 카드, 경고).
복제 아카이브-WORM/S3 Object Lock.

12) 공개 상태 페이지와의 조정

상태 페이지의 사고에는 타임 라인과 구성 요소가 있어야합니다.
시간/스케일 불일치는 불일치 기록에 의해 생성되고 RCA에 의해 게시됩니다.
보고서의 요약에는 조정 노트 섹션이 포함되어 있습니다.

13) 사건과보고

각 다운 타임 창은 INC 카드 (ID, SEV, 소유자, RCA, CAPA) 에 해당합니다.
보고서에서: INC, 짧은 근본 원인, CAPA 상태에 대한 링크.
SEV-1의 경우: 포스트 모어 주제는 닫힌 지 48 시간 후입니다.

14) 데이터 품질 관리

샘플 위생: 약제의 성공적인 스크랩의> 99%, 간격이 없음> 5 분.
노이즈 방지: 쿼럼 + 멀티 윈도, 바운스.
추적/로그 샘플링이 기록되고 문서화됩니다.
방법 테스트: 계산의 단위 테스트, 과거 데이터를 기반으로 한 황금 파일.

15) 보안 및 개인 정보 보호

섭취, 패킷 서명 (HMAC) 을위한 SL/mTLS.
로그/보고서의 PII 판; SLA 보고서는 개인 데이터를 공개해서는 안됩니다.
보고서에 대한 RBAC/ABAC; 액세스 추적은 감사 로그에 작성됩니다.

16) 대시 보드 및 SLO 위젯 (표시할 내용)

월/분기 서비스 별 전체 가용성.
심각성 및 감지 채널이있는 다운 타임 창.
오류 예산 연소 (빠른/느린) 및 추세.
오버레이 릴리스 - 계산 주석.
SLA 크레딧은 현재 추세에서 예측합니다.

17) 구현 계획 (3 회 반복)

1. 모델 및 데이터 (2 주): SLI/SLO/SLA를 수정하고 쿼럼 합성을 포함하며 DWH에서 "원료" 를 수집합니다.
2. 계산 및 보고서 (2-3 주): 공식, SQL/PromQL, YAML/CP 템플릿, 고객 포털, 자동 크레딧.
3. 감사 및 자동화 (3-4 주): 법적 보류, 상태 페이지와의 조정, 웹 후크 서명, 분쟁 규정.

18) 품질 점검표 보고서

• 범위, SLI, 방법 및 측정 창이 정의되었습니다.
• 쿼럼과 다중 창이 있습니다. 플랩 핑이 억제됩니다.
• 예외 (유지 보수/힘 전공) 가 문서화되어 있습니다.
• 각 다운 타임 창은 INC 및 RCA와 관련이 있습니다.
• SLA 크레딧을 계산하고 청구에 반영했습니다.
• 재현 가능한보고 (수식/데이터 버전).
• 감사 흔적과 법적 보류가 포함되어 있습니다.
• 공개 상태 페이지가 조정됩니다.

19) 미니 -FAQ

합성이 주요 소스 인 이유는 무엇입니까?
사용자 경로에 가장 가깝고 주변 경로가 포함되어 있습니다 메트릭/로그-이유를 명확히하십시오.

부분 저하를 계산하는 방법?
가중 가동 중지 시간: 실패 비율은 창의 지속 시간을 × "전부 또는 전혀" 가 아닙니다.

"원시" 수표를 저장해야합니까?
그렇습니다. 분쟁에서 감사 및 재 계산을 위해서는 원시가 필요합니다.

결과

가동 시간 보고서 및 SLA 감사는 "달 말의 그림" 이 아니라 올바른 SLI, 쿼럼 검사, 투명 공식, 사고 및 청구와의 연결, 예외 통제 및 법적 보류와 같은 측정, 규칙 및 증거의 재현 가능한 시스템입니다. 방법론을 기록하고 계산 및 크레딧을 자동화하며 감사 추적을 유지하면 SLA를 관리 가능하고 이해하기 쉽고 안전하게됩니다.