アップタイムレポートとSLA監査

1）正式なアップタイム報告プロセスが必要なのはなぜですか？

顧客の信頼と契約の透明性-単一の測定技術、繰り返し可能な計算。
SLOとエラー予算管理-可用性の事実とリリースやインシデントをリンクします。
正しいSLAローンは、客観的な数式、予測可能な支払い/オフセットです。
法的持続可能性-証拠ベース、独立監査、リーガルホールド。

2）用語と境界

SLI可用性-有効な検証/トランザクションの期間あたりの割合。
SLO-内部ターゲット（例：99.28日で95％）。
SLA-外部コミットメント（例：99.9％/月+サービスローン）。
測定ウィンドウ-暦月（SLA）およびローリングウィンドウ（SLO）。
スコープ-計算に含まれているコンポーネント（エッジ、API、支払い）およびそうでないコンポーネント（admin portal、 non-prod）。

3）真実の源（どちらが担当しているか）

1.Synthetics （blackbox/headless）は「、ユーザーアイ・アクセシビリティ」の主なSLIです。
2.ログ/メトリクス-障害の規模と性質を確認します。
3.ビジネスイベントは「トランザクション成功」（例えば、支払いが承認された）です。
4.ステータスページ-公共コミュニケーション；事実第1-3号と照合されている。

不一致の場合：優先度は、≥ 2領域から正しいクォーラムを持つ合成に与えられます。

4）可用性計算の方法論

4.1基本的な式

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

4.2マルチリージョナルクォーラム

N独立領域/ASN ≥同時に障害を記録すると、インシデントがカウントされます。
推奨：N=3の2 （EU/NA/APAC）。

4.3つのSLIタイプ

HTTP SLI：○○2xx/3xx、レイテンシ≤ T。
DNS/TLS SLI： NXDOMAIN/SERVFAIL/expiry。
SLIビジネス：成功したトランザクション/すべての試み（クライアントの失敗を除く）。

4.4例外（文書化）

予めN時間前に宣言され、観測されたスケジュールされたメンテナンスウィンドウ。
SLAからの不可抗力（例えば、IX災害プロバイダ）-証拠と公告がある場合のみ。
クライアントのエラー/制限（クォータを超え、4xx）。

5）ウィンドウのメンテナンスポリシー

契約で合意されたタイムスロット（例：日02：00-04：00 UTC+0）。
'Maintenance=true'は、alert/panels→SLIからの除外を示します。
通知のしきい値：少なくとも5営業日（または契約のように）。
Out of window-SLAの影響が考慮されます。

6）エッジケースと丸めルール

Brownout（部分的な劣化）：「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％など。
True-up：クレジットは次のアカウントにクレジットノートとして適用されます。

自動化： "if 'measured_availability

クライアントのショーケース：ポータルカード「SLAクレジット残高」。

11）監査、証拠および法的保持

監査証跡：誰/何/計算されたとき、方法論のバージョン、チェックサム。
生データは不変です（追加のみ）。調整-別々のレコードで。
法的保留：データ範囲（サンプル、ログ、インシデントカード、アラート）をフリーズします。
レプリカアーカイブ-WORM/S3オブジェクトロック。

12）公開ステータスページとの和解

ステータスページのインシデントには、タイムラインとコンポーネントが必要です。
時間/スケールの不一致は、差分レコードによって作成され、RCAによって投稿されます。
レポートの概要には「、和解ノート」セクションが含まれています。

13）インシデント及び報告

各ダウンタイムウィンドウは、INCカード（ID、 SEV、所有者、RCA、 CAPA）に対応しています。
レポート：INCへのリンク、短い根本原因、CAPAステータス。
SEV-1の場合：ポストモアのトピック≤終了から48時間です。

14）データ品質管理

サンプルの衛生：>薬剤の成功したスクラップの99％、ギャップの欠如>5分。
アンチノイズ：quorum+マルチウィンドウ、debounce。
トレース/ログサンプリングが記録され、文書化されます。
メソッドテスト：計算のユニットテスト、履歴データに基づくゴールデンファイル。

15）セキュリティとプライバシー

ingest、 packet signature （HMAC）用のTLS/mTLS。
ログ/レポートのPIIエディション。SLAレポートは、個人データを開示してはなりません。
レポートのRBAC/ABAC；アクセストレースは監査ログに書き込まれます。

16）ダッシュボードとSLOウィジェット（表示するもの）

月/四半期のサービスによる全体的な可用性。
重大度と検出チャネルを備えたダウンタイムウィンドウ。
エラー予算の書き込み（高速/遅い）とトレンド。
リリースオーバーレイ-計算の注釈。
SLAクレジットの予測-現在の傾向で。

17）実施計画（3つの反復）

1.モデルとデータ（2週間）：SLI/SLO/SLAを修正し、量子合成を含み、DWHで「原材料」を収集します。
2.計算とレポート（2-3週間）：数式、SQL/PromQL、 YAML/PDFテンプレート、顧客ポータル、自動クレジット。
3.監査と自動化（3-4週間）：法的保持、ステータスページとの和解、署名されたwebhook、紛争規制。

18）レポートの質のチェックリスト

• スコープ、SLI、メソッド、測定ウィンドウが定義されています。
• クォーラムとマルチウィンドウがあります。フラップは抑制されます。
• 例外（メンテナンス/不可抗力）が文書化されています。
• 各ダウンタイムウィンドウはINCとRCAに関連付けられています。
• 計算されたSLAクレジットと請求に反映されます。
• 再現可能なレポート（式/データバージョン）。
• 監査証跡と法定保留が含まれています。
• 公開ステータスページが調整されます。

19） ミニFAQ

なぜ合成が主流なのですか？
ユーザパスに最も近く、周囲（DNS/CDN/WAF）が含まれています。メトリクス/ログ-理由を明確にします。

部分的な劣化を数える方法は？
重み付けされたダウンタイム：失敗の割合×ウィンドウの持続時間であり「、すべてまたは何も」ではありません。

「raw」チェックを保存する必要がありますか？
はい、私はしました。紛争の監査と再計算のために-生が必要です。

［結果］

アップタイムレポートとSLA監査は「月末の数値」ではなく、正しいSLI、クォーラムチェック、透明な数式、インシデントと請求、例外管理、法的保留など、測定、規則、証拠の再現可能なシステムです。方法論を記録し、計算とクレジットを自動化し、監査証跡を維持します。SLAは管理しやすく、理解しやすく、安全になります。