Uptime報告和SLA審計
1）為什麼需要正式的更新時間報告流程
客戶信心和合同透明度是一種統一的測量技術，可重復計算。
管理SLO和錯誤預算-將可用性事實與發布和事件捆綁在一起。
正確的SLA信用是客觀公式，可預測的付款/抵銷。
法律可持續性是證據基礎，獨立審計，法律保留。
2）術語和界限
SLI可用性-在此期間成功檢查/交易的比例。
SLO是內部目標（例如99。在28天內占95%）。
SLA是外部義務（例如99。9％/月+服務貸款）。
測量窗口是日歷月（SLA）和滾動窗口（SLO）。
Scope-包括哪些組件（邊緣、API、付款）和哪些組件（admin portal, non-prod）。
3）真相的來源（以及什麼時候）
1.合成（blackbox/headless）是用於「用戶眼睛可訪問性」的主要SLI。
2.邏輯/度量-確認故障的規模和性質。
3.業務事件-「運營成功」（例如,已授權付款）。
4.狀態頁面-公共交流；與第1-3號事實核對。
如果存在差異：優先考慮來自≥2地區的正確的quorum合成。
4）無障礙計算方法
4.1基本公式
Availability = Успешные проверки / Все проверки
ErrorBudget = 1 − SLO
Downtime(m) = (1 − Availability) × Длительность_периода(в мин)4.2多區域quorum
如果獨立區域/ASN的≥N同時記錄故障，則將計算該事件。
建議：N=3中的2 （EU/NA/APAC）。
4.3 SLI類型
HTTP SLI: код 2xx/3xx, latency ≤ T.
DNS/TLS SLI: NXDOMAIN/SERVFAIL/expiry.
SLI業務：成功交易/所有嘗試（不包括客戶端故障）。
4.4個例外（文檔）
計劃維護窗口，提前N小時聲明並觀察到。
SLA的主要力量（例如IX災難提供者）-僅在有證據和公開通知的情況下。
客戶端錯誤/限制（quota exceeded，4xx）。
5）窗口維護政策
合同中商定的臨時插槽（例如UTC+0的vs 02：00-04：00）。
Alert/面板中的「維護=true」標記→ SLI的例外。
通知閾值：至少5個工作日（或合同中）。
窗外-被認為是SLA影響。
6）邊緣案例和四舍五入規則
Brownout（部分惡化）：計數故障比例（加權時間）而不是「0/1」。
翻轉：最低計量單位-樣本間隔（例如30-60秒）+hysteresis（for：2-5分鐘）。
時鐘漂移：UTC和ISO-8601中的所有時間；NTP同步。
7） PromQL示例（合成→藥房）
HTTP驗證成功：promql probe_success{job="blackbox-http"} == 1p95 latency:
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])) >= 28） 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：信用作為信用註應用於下一個帳戶。
自動化： 「如果」measured_availability 客戶展示：「SLA信用平衡」門戶卡。 11）審計，證據和法律保留 審計跟蹤：誰/什麼/何時計算,技術版本,校驗金額。 12）與公共地位頁面核對 狀態頁面上的事件必須具有時間線和組件。 13）事件和報告 每個市區窗口都對應於INC卡（ID，SEV，所有者，RCA，CAPA）。 14）數據質量控制 樣品衛生：>99%成功抽取劑,無通行證>5分鐘。 15）安全和隱私 TLS/mTLS for ingest,數據包簽名（HMAC）。 16）Dashbords和SLO小部件（顯示的內容） 每月/每季度服務可用性過高。 17）實施計劃（3次叠代） 1.模型和數據（2周）：固定SLI/SLO/SLA,包括quorum合成,在DWH組裝「原材料」。 18）報告質量清單 19）迷你常見問題 為什麼合成是主要來源？ 如何計算部分降解？ 是否需要保留「原始」檢查？ Uptime報告和SLA審核不是「月底數字」，而是可復制的度量，規則和證據系統：正確的SLI，quorum檢查，透明的公式，事件和計費捆綁在一起，異常控制和合法保留。確定方法，自動化計算和信用額度，保持審計跟蹤-並且您的SLA將變得可管理，可理解和保護。
原始數據不變（僅append-only）；調整-單獨記錄。
法律保留：凍結數據範圍（樣本，標誌，事件卡，Alerta）。
檔案副本：獨立存儲（WORM/S3對象鎖）。
時間/規模不匹配→由discrepancy記錄創建並由RCA執行。
報告的結果包含「重新分配註釋」部分。
報告：鏈接到INC,簡短的root cause, CAPA狀態。
SEV-1：從關閉開始≤ 48小時後。
反噪音：quorum+多窗口，debounce。
記錄並記錄了軌道/記錄的采樣。
技術測試：單位計算測試，歷史數據的金文件。
Logs/報告中的 PII修訂版；SLA報告不得披露個人數據。
RBAC/ABAC報告；訪問痕跡寫入審核日誌。
帶有severity和檢測通道的Downtime Windows。
錯誤預算燒傷（快速/慢速）和趨勢。
Releases overlay-布局註釋。
SLA credits forecast-當前趨勢。
2.計算和報告（2-3周）：公式,SQL/PromQL, YAML/PDF模板,客戶門戶,自動信用。
3.審核和自動化（3-4周）：法律保管,狀態頁面重新認證,簽名網絡手冊,分配規則。
它最接近用戶路徑，並且包括外圍（DNS/CDN/WAF）。度量/標誌-指定原因。
加權市區：未修復的比例×窗口的持續時間，而不是「全部或全部」。
是的。對於爭議中的審核和重新計算-必須使用raw。
結果