#NSIO Next · 服务运营、SLA 与状态通报

状态：托管服务运营与客户支持实现依据。本文把工程 SLO、合同 SLA、状态页、事故响应、支持响应和隐私遥测分开。具体价格与 entitlement 仍以商业模型和采购计费为权威。

#1. 服务边界

不能用一个“NSIO 可用率”覆盖不同失败影响。运营对象至少分为：

自建 NSD、客户 IdP、客户网络、客户自建 Relay/NSGW 和目标应用不计入 NSIO 托管服务可用率，但诊断必须明确归因，不能笼统标成客户问题。

#2. SLI 与测量

#2.1 请求型服务

一分钟 bucket 中，符合生产协议的合成请求在截止时间内得到成功或明确幂等结果，记为成功。鉴权错误、无授权和合法限速不是服务错误；5xx、超时、无有效签名配置和错误空投影是服务错误。

全局服务至少由三个独立故障域探测；同一分钟至少两处成功才记为 available。区域服务由至少两个区域外探针进入所购区域，并结合区域内 dataplane canary；任一侧证明平台不能完成真实事务即记 unavailable。单个探针自身网络故障只有在独立证据确认且其他探针成功时才从该分钟剔除，不能人工挑掉平台故障样本。

月可用率：

successful eligible minutes / total eligible minutes

探针使用最小测试租户完成真实 DNS、TLS、认证和签名验证。只 ping 端口不算控制面可用。bucket 原始结果、剔除原因和批准规则版本必须可重算。

#2.2 Relay 与 Edge

Relay SLI 使用真实端到端加密 session：两个探针节点获得 route token、经目标 region 交换带 nonce 的 frame 并校验返回。Edge 使用每种 capability 的实际流：Ingress 请求、Egress origin 连接、Exit canary 流量。Community Relay 按已声明 allowance 进入 degraded/fallback profile 是合法服务等级结果，不计平台故障；错误 subject/period、预算错误重置、控制面故障导致高速限制失效、或者平台容量不足导致无法提供当前有效 profile，均计服务故障。容量拒绝若由客户购买上限或明确滥用策略触发不计服务故障；平台容量不足导致的拒绝计故障。

#2.3 客户可验证性

管理端展示 Organization 维度的服务类、区域、受影响窗口、request/incident ID 和 SLA 计算结果。客户不能看到其他租户容量或流量。原始测量和排除决定至少保存到争议窗口结束。

#3. 工程 SLO 与合同 SLA

SLO 是内部可靠性目标；SLA 是合同承诺。内部 SLO 必须比 SLA 更严格并留 error budget。首发默认合同基线：

不出售的服务不进入 SLA。Community Relay 是基础兜底，不以单一区域承诺；状态页仍公开其健康。高于上述目标的专属架构必须由容量、故障域和演练证据支撑，销售不能在报价单中自由填写更高数字。

默认服务抵扣按受影响服务当月费用计算：

抵扣总额不超过该受影响服务当月费用，不自动折算为现金赔偿。客户在账期结束后 30 天内提交或由平台自动生成 claim；合同可提供更优条款但不能低于已签承诺。

#4. 排除项与维护

可排除：提前至少 72 小时通知且在公布窗口内的计划维护、客户明确配置错误、客户/第三方 IdP 或目标系统故障、互联网级不可控事件、客户违反容量/滥用规则、不可抗力和客户选择的 preview 功能。排除必须有时间、证据和影响服务类，不能事后把平台容量不足改写成计划维护。

安全紧急维护可少于 72 小时通知，但仍计入内部 SLO；是否从合同 SLA 排除依合同执行并在事后报告。维护不能靠状态页一句“性能下降”无限延长。

#5. Error Budget 与变更门

每个服务类/区域单独计算 28 天滚动 error budget。消耗达到 50% 时停止非必要高风险变更；达到 100% 时只允许修复、容量和安全变更。恢复新功能发布需要 owner 记录原因和保护措施。

发行灰度、NSD schema、NSGW config 和路由策略变更都关联 deployment ID；异常可以按 revision/region/cohort 回滚或停止，不靠全局停机排查。

#6. 状态页

公开状态页使用独立域名和故障域，不依赖主要 NSD 登录。无需登录即可查看：

• Identity、Control、Coordination、Community Relay、各托管区域、Ingress/Egress/Exit、Billing/API；
• operational / degraded / partial outage / major outage / maintenance；
• 开始时间、受影响区域/能力、当前缓解、下一次更新时间；
• 近 90 天历史、订阅邮件/RSS/webhook 和 incident API。

客户端在控制面不可达且本地网络基本诊断正常时可以展示状态页链接，但不能据状态页绿色就判定本地无问题。状态页内容来自事故系统，不允许值班人员只改前端颜色而没有事件记录。

#7. 事故响应

内部流程：自动告警/报告 → incident commander → 分级和受影响面 → 状态页/客户通知 → 缓解 → 验证 → 关闭 → 复盘。SEV-0/1 在恢复后 5 个工作日内提供客户可读复盘，包含时间线、影响、根因类别、检测缺口和有 owner/日期 的行动项；不泄露其他租户数据或可利用细节。

安全事故另走 security incident 流程，并按适用合同和法律时限通知。产品事故和安全事故可以关联，但不能用普通 outage 关闭数据事件义务。

#8. 支持

首次响应不是解决时限。工单必须包含 Organization、deployment、component versions、request/operation ID 和脱敏诊断包；支持人员不能要求客户发送私钥、完整策略或业务流量。

#9. 可观测性与隐私遥测

#9.1 运行遥测

默认允许的字段采用 allowlist：组件/版本、平台/OS major、operation stage、typed error code、duration bucket、path kind、Relay region、crash signature、更新通道和随机安装级诊断 ID。默认禁止：业务域名、完整 Node/Service 名、IP/endpoint、用户邮箱、Group 成员、ACL 内容、应用 payload、密钥和 token。

云托管的服务端安全/计费日志按必要性收集；Client 产品分析和 crash 上传提供清晰设置与区域适用的同意。自建默认本地保存，向厂商上传必须 opt-in 或由管理员策略明确开启。

#9.2 激活漏斗

为了验证“三分钟首次成功”，只收以下状态转移及耗时，不收用户访问目标：

install_completed
login_started / login_completed
enrollment_started / committed
tunnel_permission_requested / granted / denied
first_connection_ready
second_device_visible
first_peer_connect_success
first_service_published / opened

每个事件带 schema version、occurred_at、installation analytics ID、deployment class、platform、app/runtime version、result/error code 和 duration bucket。账号、Organization、Device 业务 ID 在分析系统中使用不可逆且按部署轮换的伪名，不允许与广告标识关联。

漏斗 dashboard 必须区分未知/漏报与零，展示每阶段样本量、版本和平台；不得依据未同意遥测推断个人行为。删除账号时按信任与数据权利处理可关联分析数据。

#10. 容量与区域运营

每个 NSGW region 有 admission、CPU/memory、bandwidth、session、queue、packet loss 和 drain 指标。达到软阈值停止向该实例分配新 session；达到硬阈值由控制面移除候选并告警。扩容失败不得返回 unauthorized 或 offline。

区域上下线经过 canary、容量验证、drain 和 DNS/config revision。Data residency 商品只在数据和运营链路均满足时展示可购买；region label 不是合规证明。

#10.1 Relay 可售容量权威

平台运营维护 RelayCapacityInventory，键固定为 (deployment_id, region_id, gateway_pool_id, capacity_class)。它是销售 admission 的运营权威，不是 NSGW 自报指标的直接镜像。每个 revision 至少记录：

• validated_capacity_bps、测量窗口、拓扑/实例集 revision、证据 digest 与批准人；
• worst_failure_domain_loss_bps，按主机、机架、可用区、供应商、transit 和上游网络中已建模的最大相关故障计算，不能只减最大实例；
• operational_headroom_bps 与 platform_safety_margin_bps；
• sellable_reserved_bps、有效 held_bps、committed_reserved_bps 和当前 revision；
• 独立 capacity_state=healthy|constrained|oversold、measurement_freshness=fresh|stale|invalid 和 capacity_admission_policy_revision。它们不能与 Gateway runtime Availability 合成一个状态；进入 constrained 的余量阈值/人工 hold reason 必须来自该版本化策略，不能藏在销售或 UI 代码里。

专属池可售预留公式固定为：

sellable_reserved_bps = max(0,
    validated_capacity_bps
  - worst_failure_domain_loss_bps
  - operational_headroom_bps
  - platform_safety_margin_bps)

具体余量和测量窗口保持 pending_measurement，但公式、输入 provenance 和审批不可省略。Reserved Throughput 首发只允许使用 dedicated_reserved isolation class 的 Dedicated Relay Pool；该池不得承载 Community Relay 或其他 Organization，因此 community_relay_demand_bps 不进入预留成交公式。共享池仍必须把 Community Relay 需求分布作为 Regional Capacity 的扩容/降级规划输入，但共享容量不能签发硬 Reserved Throughput 承诺。

每笔容量占用是独立 RelayCapacityReservation，状态为 held|committed|released|expired，并绑定 ProductAllocation ID/revision、Inventory ID/revision、bps、有效期和幂等键。Capacity Authority 的单库事务固定为：锁定当前 Inventory revision/freshness → 汇总有效 held/committed → 校验商品/专属池/地域/故障域约束 → CAS 写 Reservation 与 Inventory aggregate → 写容量 outbox。商业编排以该 Reservation 结果推进 ProductAllocation/Assignment，不假设跨库原子提交；未知结果只查询/重放同一幂等 operation。扩缩容在 Capacity Authority 内原子替换旧承诺，不能先释放再争抢；Capability Lease 只能投影 committed Reservation，不能创建或扩大容量。

状态语义固定为：

重新测量必须允许写入更低的 validated_capacity_bps，提升 Inventory revision 并重新计算 state；不能因结果难看而拒绝测量，也不能静默接受而不告警。进入 constrained/oversold 时写 relay.capacity.remeasured 与 relay.capacity.constrained|oversold 审计，关联旧新公式输入、evidence digest、受影响 Allocation/Assignment/SLA 和财务责任。运营按“补容量 → 在相同 residency/isolation/SLA 约束内迁移 → 与客户明确协商”处置；不得自动跨区、改到共享池、降低合同 bps 或取消 Reservation。

oversold 期间继续按 committed Reservation 签发 Lease并优先调度预留流量，不把库存下修伪装成 entitlement 失效。若物理条件已无法兑现，真实探针失败进入对应 SLA/incident；签发承诺不代表 SLI 成功。measurement stale/invalid 同样停止新增/扩大，但不自行改变既有 Reservation 或 runtime Availability。

#10.2 Community Relay 成本与路径证据

Community Relay 数值回填分为两条并行证据流，不能把“Direct Path 尚未完成”当作不测基础设施成本的理由：

Direct Path Engine 同时是功能与毛利任务。生产/试验指标至少包含 direct_connection_rate、customer_relay_rate、community_relay_rate、relay_bytes_by_network_class、time_to_direct、fallback_count 和 path_migration_success_rate；按网络类别与版本聚合，不采集业务目标或 payload。直连率提升的成本收益必须能从同一数据集重算，不能只报告总体成功率。

每个 pending_measurement 常量的回填证据必须绑定 commit、NSGW/carrier 版本、供应商/region/价格生效窗口、实例规格、压测命令 digest、网络样本分层、原始分位数和计算公式。输出至少包括：Community Relay normal/degraded/fallback 参数、Team 保守场景毛利、Free budget owner 最坏月成本，以及固定/流量成本的敏感性区间。估算可以用于规划，不能填入生产常量或销售承诺。

发布门要求同时证明：

1. Direct → customer-owned Relay → Community Relay → WSS/TLS 的选择、故障转移和恢复直连；
2. RelayBudgetLease 多实例分配总和及有界重叠不会突破批准成本上界；
3. subject 轮换、升级/降级和进程重启均不重置 allowance；
4. 中央计量/outbox/Allocator 故障时，本地持久窗口和 fallback profile 仍封住最坏成本；
5. 单谓词反向注入可以让预算验签、period/rotation/generation、counter、token bucket、桶深和 stale fallback 测试变红；
6. Free/Team 控制台可以解释用量、档位、恢复时间和替代路径；
7. Community Relay 商业降速、平台过载和安全滥用产生不同稳定 reason、状态页归因和审计。

#11. 完成门

• 每个 SLA 服务类有真实合成事务和独立 dashboard；
• 故障注入能让客户端、状态页、告警和 SLA 计量得到一致但不过度推断的结果；
• 状态页在主 NSD 登录故障时仍可访问；
• SEV-1 tabletop 和 region outage 演练完成；
• 服务抵扣可从原始 bucket 重算并生成客户证据；
• telemetry schema 经隐私审查，新增字段默认拒绝而不是自动上传；
• Community Relay 所有 pending_measurement 常量有可复现实验、成本上界和反向注入证据；
• ProductAllocation/Capacity Reservation 的重复命令、并发成交、hold expiry 和原子 resize 不重复占位或突破 sellable_reserved_bps；
• 容量重测下修能够进入 constrained/oversold、停止新售、保留既有承诺并产生可关联的运营/财务审计；
• Reserved Throughput 故障演练分别覆盖持续满负载、最大相关故障域退出和单实例退出，证明的是故障后兑现能力而非正常态峰值；
• 漏斗可以回答每个平台从安装到首个 peer 成功的转化和耗时；
• 销售报价中的 SLA 只能从受控产品目录选择。