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。
结果