プロバイダとのSLA/OLA

1）用語と境界

SLI-測定可能なインジケータ（可用性、p99レイテンシ、正常に処理されたWebhook、 RPO/RTO）。
SLO-測定ウィンドウごとのターゲットSLI値（例：99。9％/30日）。
SLA-法的拘束力のある文書（SLO+手続き+払い戻し）。
OLA： SLAの遵守を確実にする社内の目標とプロセス。
UC（下支え契約）-第三者（チャネル、データセンター、CDNなど）との「基板」。

境界：プロバイダの責任領域（クラウド/WAF/CDN/ペイメントゲートウェイ/KYCプロバイダ）をエリア（コード、構成、クライアント設定）から明確に分離します。

2）臨界マトリックスとモデル選択

マトリックスは、SLAの深さ、チェックの範囲、およびOLA/UCの要件を決定します。

3）測定窓と測定窓

可用性-公差に応じてサービスがクエリを実行する時間の割合。
遅延：主操作のためのp95/p99；「slow success」カウント。
データの信頼性：RPO（最大許容データ損失）とRTO（リカバリ時間）。
帯域幅/制限：保証クォータ（RPS/MBps）。
統合の質：配信されたWebhookのシェア≤ X分、2xx応答のシェア、繰り返しと重複排除。
測定ウィンドウ：毎月/30日間のローリング、制限付きの例外（計画されたアクティビティ）。

• 'Availability_ext=1 − （Downtime_confirmed_outages/ Total_minutes_in_window）'
• 停止は、プロバイダのステータスページだけでなく、外部モニタリングによって確認された利用できない状態です。

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％の可用性。可用性は、お客様の外部合成モニタリングによって測定されます≥ 3地域から≤ 1分間隔で。≥ 2つの地域で記録された利用不能は、同時にレベルSEV2インシデントと見なされ、ダウンタイムにカウントされます"

5.2主要なAPIレイテンシ

「p99応答時間'POST/payment/authorize」 ≤、月の95％の日に450ミリ秒です。しきい値を超えるリクエストの割合について、原因分析レポートが提供されます"

5.3インシデントとエスカレーション

"S1： ack ≤ 15分、≤ごとに更新30分、目標の回復≤ 2 h；S2： ack ≤ 30分、更新≤ 60分；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ゲートウェイ≤ 200ミリ秒、エラー率≤ 0。3％、 DR： RPO 0、 RTO 30分。
• 責任：SRE-on-call、 24 × 7；一般的なダッシュボードとアラート。
• プロセス：リリースのカオススモーク、PRのパーフスモーク、シェーディングのヒューリスティクス。
• ゲート：SLO/xaocテストが失敗したときのデプロイブロック。必須のrunbookの更新。

7）モニタリングとエビデンス

合成：外部プローブ（HTTP/TCP）、ユーザーパス、「遅い成功」。
RUM：影響を確認する実際のユーザー監視。
相関：'provider'、 'region'、 'api_method'、' incident_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.Postmortem+アクション：設定の制限、キー、バックアップルートを更新します。

6.SLAローンの開始、請求の修正。

9）セキュリティとDPA

DPA/プライバシー：コントローラ/プロセッサの役割、データカテゴリ、合法性ベース、処理期限/目的、サブプロセッサおよびそのSLA。
暗号化：TLS1。2+、PFS；データ「残り」、キー管理（KMS/HSM）、回転。
監査：アクセスログ、違反通知≤ 72時間、リクエストに応じてペンテストレポート。
ローカリゼーション：ストレージ領域、同意なしに輸出を禁止します。

10）サプライチェーンと相互運用性

SBOM/vulnerabilities： CVSSのしきい値ポリシーと修正時間（7日間≤批判され、高い≤ 14）。
APIの互換性：契約テスト、サンドボックスおよび安定した据え付け品。
プロバイダの変更：早期リリースノート、プレビュー/ベータウィンドウ、下位互換性。

11）複数の提供者およびfeilover

アクティブ/アクティブ：より困難で高価ですが、可用性が高くなります（一貫性を考慮してください）。

アクティブ/パッシブ： コールド/ウォームリザーブ、DRRレギュラーワークアウト

抽象化/アダプター：単一の契約、健康/コスト/カーボンルーティング（関連する場合）。
ライセンス/商用条件：移植性、データ出力の制限、排出コスト。

12）出口プランと定期的なリハーサル

データ/ダイアグラムカタログとボリューム。
SDK/APIポータビリティスクリプト（最小-2番目のソース）。
乾燥した出口テスト：輸出/輸入は、不変量を点検します。
リリース後の法的保持/廃棄期間。

13）契約テストおよび適合

APIサンプル：正/負、リミット、エラー、およびリトレイ。
イベント/webhookの配信：署名/時間/祖父/繰り返し。
Perfベースライン：p99、帯域幅；プロバイダのリリースノートの回帰テスト。
クロスリージョン：1つのリージョンの劣化は、グローバルにSLOに違反してはなりません。

14）アンチパターン

外部測定なしのSLA 「on status page」。
すべての地域/エンドポイントで同じ目標を設定します。
監査権と詳細なインシデントログの欠如。
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契約Webhookテスト（擬似コード）

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、パイプライン化されたゲート、マルチベンダー、および実際の出口計画は、プロバイダの依存関係をプラットフォームの管理、測定、経済的に予測可能な部分に変えます。