공급자와 SLA/OLA

1) 이용 약관

SLI-측정 가능한 표시기 (가용성, p99 대기 시간, 성공적으로 처리 된 웹 후크, RPO/RTO).
SLO-측정 창 당 대상 SLI 값 (예: 99). 9 %/30 일).
SLA - 법적 구속력이있는 문서 (SLO + 절차 + 상환).
OLA-SLA 준수를 보장하는 내부 목표 및 프로세스.
UC (Underpinning Contract) - 타사 (채널, 데이터 센터, CNC 등) 와의 "기판".

경계: 공급자의 책임 영역 (클라우드/WAF/CNC/결제 게이트웨이/KYC 공급자) 을 해당 영역 (코드, 설정, 클라이언트 설정) 과 명확하게 분리합니다.

2) 비판 행렬 및 모델 선택

비즈니스 영향에 따른 세그먼트 제공 업

행렬은 SLA 깊이, 수표 범위 및 OLA/UC 요구 사항을 결정합니다.

3) 측정 및 측정 창

가용성-서비스가 공차에 따라 쿼리를 실행하는 시간의 백분율.
대기 시간: 주요 작업의 경우 p95/p99; "느린 성공" 이 중요합니다.
데이터 안정성: RPO (최대 허용 데이터 손실) 및 RTO (복구 시간).
대역폭/제한: 보장 된 할당량 (RPS/MBps).
통합 품질: 전달 된 웹 후크의 공유, XX 분, 2xx 응답 공유, 반복 및 중복 제거.
측정 창: 월별/롤링 30 일, 제한이있는 예외 (계획된 활동).

• '가용성 _ X = 1- (다운 타임 _ 확인 된 _ counts/Total _ mulls _ in _ 창)'
• 공급자의 상태 페이지뿐만 아니라 외부 모니터링을 통해 중단이 확인 될 수없는 상태 인 경우.

4) SLA 컨텐츠 (섹션 템플릿)

1. 주제 및 범위 (서비스, 지역, API 버전).
2. 정의 (SLI/SLO, "사건", "계획된 작업", "강제 전공").
3. 요청 범주 및 지역별 서비스 목표 (SLO).
4. 모니터링 및 증거 기반: 어떤 방식으로, 어떤 센서, 어떤 주파수.
5. 사건 및 에스컬레이션: 채널, 응답/업데이트 시간, 역할.
6. 환불: 크레딧/벌금/보너스, 임계 값, 공식.
7. 보안 및 개인 정보: DPA, 암호화, 로그, 위반 알림.
8. 서비스 변경: 사용하지 않음, 알림 창, 호환성.
9. 연속성 및 DR: RPO/RTO, 복구 테스트.
10. 감사 및 준수: 감사, 보고, 인증에 대한 권리.
11. 종료 계획: 데이터 내보내기, 날짜, 형식, 마이그레이션 지원.
12. 법적 조항: 관할권, 강제 전공, 기밀 유지, 유효 기간.

5) 문구의 예 (조각)

5. 1 가용성 및 측정

"공급자는 99를 제공합니 한 달에 95% 의 가용성. 가용성은 1 분 간격으로 3 개 이상의 영역에서 고객의 외부 합성 모니터링으로 측정됩니다. 2 개 지역에서 기록 된 사용 불가능은 동시에 레벨 SEV2 사건으로 간주되며 다운 타임에 계산됩니다. "

5. 2 주요 API 대기 시간

"p99 응답 시간 'POST/결제/승인" 월 중 95% 에서 450ms. 임계 값을 초과하는 요청의 백분율에 대해 원인 분석 보고서가 제공됩니다. "

5. 3 건의 사건과 에스컬레이션

"S1: 정 15 분, 매 30 분마다 업데이트, 목표 복구는 2 시간; S2: 정 30 분, 업데이트 S3: 다음 영업일. 채널: 전화 24 × 7, 채팅 브리지, 이메일 "

5. 4 환불 (크레딧)

If Availability_ext <99. 95% → credit 10% monthly fee
< 99. 9% → 25%
< 99. 5% → 50%

대출은 중과실로 인한 피해에 대한 다른 보상 방법을 배제하지 않습니다.

5. 5 비 승인 및 호환성

"호환성이 중단되는 변경에 대해 최소 180 일 전에 통지하십시오. 최소 90 일 동안 vN 및 vN + 1에 대한 동시 지원 "

5. 6 번 출구

"종료 후 30 일 이내에 제공 업체는 무료로 Parquet/JSON + 형식으로 데이터를 완전히 내보냅니다. 추가 마이그레이션 서비스-관세 X에서. 사본의 파괴는 그 법에 의해 확인됩니다. "

6) OLA: 외부 SLA에 대한 내부 지원

• 목표: p99 게이트웨이 3%, DR: RPO 0, RTO 30 분
• 책임: SRE-on-call, 24 × 7; 일반적인 대시 보드 및 경고.
• 프로세스: 릴리스의 혼돈 연기, PR의 퍼프 연기, 음영 휴리스틱.
• 게이트: SLO/xaoc 테스트가 실패하면 블록을 배포합니다. 필수 런북 업데이트.

7) 모니터링 및 증거

신디케이트: 외부 프로브를 사용합니다.
RUM: 영향을 확인하기위한 실제 사용자 모니터링.
상관 관계: '제공자', '지역', 'api _ 방법', '사고 _ id' 레이블.
아티팩트: 스크린 샷/트레일/로그, KPI 내보내기, 에스컬레이션 타임 라인.

rego package policy. sla deny["Release blocked: provider SLO risk"] {
input. release. affects_providers[_] == p input. slo. forecast[p].breach == true
}

8) 사건과 상호 작용

1. SEV 분류, 전쟁 실 개방, IC 목적.

2. "핫 채널" 을 통한 공급자 알림, 아티팩트 전송.

3. 바이 패스 모드/기능 플래그 (오래된, 음영, 속도 캡).

4. 공유 타임 라인, 복구.

5. 사후 + 동작: 설정 제한, 키, 백업 경로 업데이트.

6. SLA 대출 시작, 청구 수정.

9) 보안 및 DPA

DPA/개인 정보 보호: 컨트롤러/프로세서 역할, 데이터 범주, 합법성 기반, 처리 마감일/목표, 하위 프로세서 및 SLA.
암호화: TLS1. 2 +, PFS; 데이터 "휴식", 키 관리 (KMS/HSM), 회전.
감사: 액세스 로그, 위반 알림은 72 시간, 요청시 가장 적은 보고서입니다.
현지화: 저장 구역, 동의없이 수출 금지.

10) 공급망 및 상호 운용성

SBOM/취약점: CVSS 임계 값 정책 및 수정 시간 (비판 7 일, 높은 14 일).
API 호환성: 계약 테스트, 샌드 박스 및 안정적인 비품.
공급자 변경: 조기 릴리스 노트, 미리보기/베타 창, 이전 버전 호환성.

11) 다중 제공 업체 및 feilover

액티브/액티브: 더 단단하고 비싸지 만 가용성이 높습니다 (일관성 고려).

액티브/패시브: 콜드/웜 리저브, DR. 정규 운동

추상화/어댑터: 단일 계약, 건강/비용/탄소 라우팅 (관련된 경우).
라이센스/상업적 조건: 이식성, 데이터 출력 제한, 탈출 비용.

12) 종료 계획 및 정기 리허설

데이터/다이어그램 카탈로그 및 볼륨.
SDK/API 이식성 스크립트 (최소 - 두 번째 소스).
건조 종료 테스트: 수출/수입, 복원, 불변 검사.
릴리스 후 법적 유지/폐기 기간.

13) 계약 테스트 및 적합성

API 샘플: 긍정적/음성, 한계, 오류 및 배신.
이벤트/웹 후크 전달: 서명/시간/할아버지/반복.
퍼프베이스 라인: p99, 대역폭; 공급자의 릴리스 노트에 대한 회귀 테스트.
교차 지역: 한 지역의 저하가 전 세계적으로 SLO를 위반해서는 안됩니다.

14) 반 패턴

외부 측정없이 SLA "상태 페이지".
모든 지역/종점에 대해 동일한 목표.
감사 권한 부족 및 자세한 사건 기록.
OLA/UC → 내부에 외부 의무를 이행 할 사람이 없습니다.
미확인 출구 계획 → 공급 업체 인질.
체계적인 위반의 경우 종료 할 권리가없는 "대출에 의해서만 벌금".
전환 창이 없으면 사용하지 않습니다.

15) 건축가 점검표

1. 주요 흐름 및 영역에 대해 정의 된 SLI/SLO?
2. 선택된 외부 모니터링 방법 및 증거 기반?
3. SLA에서 사건, 에스컬레이션, 계획된 작업 창 및 예외 제한이 명시되어 있습니까?
4. 신용 규모/위약금과 N 위반에 대한 해지 권한이 있습니까?
5. DPA/보안: 암호화, 로그, 알림, 하위 프로세서, 현지화?
6. 파이프 라인의 계약 테스트 및 샌드 박스?
7. 내부 OLA/UC는 외부 SLO를 가능하게합니까?
8. DR: RPO/RTO 선언, 교육 수행, 보고서 제공?
9. 종료 계획: 수출 형식, 타이밍, 건식 종료 연습?
10. SLA 위반의 위험을 증가시키는 CI/CD 차단 릴리스의 게이트가 있습니까?

16) 미니 예 (스케치)

16. 1 공급자 위험에 대한 배포 게이트 정책

yaml gate: provider-slo-risk checks:
- name: forecasted-slo-breach input: slo_forecast/providers. json deny_if: any(.providers[].breach == true)
action_on_deny: "block-release"

16. 2 "사고 증거" 수출

bash curl -s https://probe. example. com/export? from=2025-10-01&to=2025-10-31 \
jq '.      {region, endpoint, status, latency_ms, trace_id, ts}' > evidence. jsonl

16. 3 계약 웹훅 테스트 (의사 코드)

python evt = sign(make_event(id=uuid4(), ts=now()))
res = post(provider_url, evt)
assert res. status in (200, 202)
assert replay(provider_url, evt). status = = 200 # idempotency

결론

SLA/OLA는 "법률 용지" 일뿐만 아니라 위험과 품질을 관리하기위한 건축 메커니즘입니다. 올바른 지표 및 창, 외부 모니터링, 명확한 사고 및 상환 절차, 내부 OLA/UC, 파이프 라인 게이트, 다중 공급 업체 및 실제 출구 계획은 공급자 의존성을 플랫폼의 통제되고 측정 가능하며 경제적으로 예측 가능한 부분으로 전환합니다.