AIoT 后端系统稳定性保障方案 v3.2

二审终稿 · SRE-first + AI-enhanced

版本: v3.2 (二审终稿) | 日期: 2026-05-13 基线: v3.1 (2026-05-13) 审查范围: 5 个角色二审（架构师 8.2/10、SRE 78/100、一线开发 7.5/10、安全总监、财务/IT 总监） 变更性质: 闭环 v3.1 残留问题 + 新增安全基线 + 修正成本估算

v3.1 → v3.2 变更清单（20 项）

| # | 变更 | 来源 | |---|------|------| | 1 | P0 升级链定义（L1→L2→L3，15 分钟超时） | SRE 二审 | | 2 | On-call 工具链明确（阶段 1 飞书 + 值班表，阶段 2 PagerDuty/Opsgenie） | SRE 二审 | | 3 | MTTR 四阶段定义（Detect <2min → Triage <3min → Mitigate <5min → Resolve 跟进） | SRE 二审 | | 4 | 稳定性预算与 Error Budget 对齐（非计划故障上限 ≤ SLO Error Budget） | SRE 二审 | | 5 | 降级架构分阶段定义（阶段 1-2 L4=设备端自治，L5=跨 AZ 熔断） | SRE 二审 | | 6 | 告警规则生命周期（90 天 review，到期自动静默） | SRE 二审 | | 7 | 组件运维责任人矩阵 | SRE 二审 | | 8 | 阶段 gate review 标准（1a→1b、2a→2b） | SRE 二审 + 架构师 | | 9 | AI 运维引入约束（对应手工流程成熟运行 ≥3 个月） | SRE 二审 | | 10 | 自愈 Agent 安全护栏（同一 on-call 有活跃 P0 时暂停自动执行） | SRE 二审 | | 11 | AI 安全护栏（Prompt 注入防护 + 操作白名单 + 自动回滚 + 双人审批） | 安全二审 | | 12 | 安全基线清单（K8s 加固 + WAF + 备份策略 + 日志脱敏 + 镜像签名 + Kafka ACL） | 安全二审 | | 13 | CI 门禁分级策略（Critical/High 阻断，Medium 72h SLA，Low 记录） | 安全二审 | | 14 | 设备密钥存储三层方案 + 轮换 + 分发 | 安全二审 | | 15 | PKI 根 CA 保护（离线 HSM）+ CRL 分发点 | 安全二审 | | 16 | 数据分类分级标准（L1 公开 / L2 内部 / L3 敏感 / L4 机密） | 安全二审 | | 17 | EMQX Enterprise 授权费计入成本 | 财务二审 + 架构师 | | 18 | 等保三级合规预算（一次性 $30, 000 - 50, 000 ） ∣ 财务二审 ∣∣19∣ 云资源成本修正（阶段 2$ 8K→ $12 - 18 K ，阶段 3$ 20-30K→$25-40K） | 财务二审 | | 20 | CI <10 分钟 + ArgoCD Manual Sync 优先 + SLO 不挂钩绩效 | 一线开发二审 |

1. 设计原则（v3.2 修正）

SRE-first, AI-enhanced：先建立 solid 的 SRE 实践（可观测性→SLO→告警→混沌工程），AI 是加速器
SLO 驱动：所有决策围绕 SLI/SLO 展开，Error Budget 是第一优先级
渐进演进：先看见，再守住，然后才谈得上智能
多云务实：阶段 1-2 单云（腾讯云），阶段 3 评估海外需求
安全左移：等保合规前置，安全基线在阶段 1a 前完成
运维友好：组件数量与团队规模匹配，能托管就不自建
【新增】AI 引入约束：任何 AI 运维能力必须在对应的手工流程成熟运行 ≥3 个月后才能引入

2. 架构全景图（5 层，统一命名）

┌─────────────────────────────────────────────────────────────────┐
│                    第 5 层：组织与工程文化                          │
│  SRE 团队 │ Blameless 文化 │ 知识管理 │ 培训演练 │ 稳定性预算       │
├─────────────────────────────────────────────────────────────────┤
│                 第 4 层：SRE + AI 智能运维                          │
│  SLO/Error Budget │ On-call │ 混沌工程 │ 降级架构 │ AI 辅助 RCA     │
├─────────────────────────────────────────────────────────────────┤
│              第 3 层：可观测性 + 安全 + DevSecOps                   │
│  OpenTelemetry │ 日志/指标/链路 │ 告警 │ IoT 安全 │ 等保合规        │
├─────────────────────────────────────────────────────────────────┤
│           第 2 层：应用 + 数据 + 大数据架构                          │
│  微服务 │ API 网关 │ 消息队列 │ MQTT │ 设备管理 │ OTA               │
│  数据采集 │ 实时计算 │ 数据湖 │ OLAP │ BI │ 数据治理                │
├─────────────────────────────────────────────────────────────────┤
│           第 1 层：云原生基础设施 + 设备端稳定性                      │
│  K8s │ IaC │ GitOps │ FinOps │ 边缘 K3s │ 设备 SDK 离线处理        │
│  ← 设备端稳定性纳入第 1 层（原"第 0 层"说法已统一）                    │
└─────────────────────────────────────────────────────────────────┘

3. 第 1 层：云原生基础设施 + 设备端稳定性

3.1 K8s 集群架构

| 阶段 | 策略 | 集群 | |------|------|------| | 1a-1b (0-3 月) | 单云（腾讯云主战场） | 生产 1 套 + 预发布 1 套 | | 2 (3-6 月) | 单云多 AZ | 生产多 AZ + 预发布 | | 3 (6-12 月) | 评估 AWS 海外部署需求 | 如需要，引入 ArgoCD 多集群 | | 4 (12-36 月) | 按需引入 Karmada | 集群数 >4 或明确跨云故障转移需求 |

3.2 K8s 安全基线（【新增】v3.2）

安全总监二审：K8s 安全加固是生产环境必须项，阶段 1a 前完成。

| 项目 | 配置 | 阶段 | |------|------|------| | Pod Security Standards | Restricted 模式（禁止 privileged 容器） | 1a | | NetworkPolicy | 默认拒绝所有入站，白名单放行 | 1a | | RBAC | 最小权限原则，禁止 cluster-admin 滥用 | 1a | | Secret 管理 | External Secrets Operator + 云 KMS | 1b | | 审计日志 | K8s Audit Log → Loki，保留 180 天 | 1b | | 镜像签名 | cosign + Sigstore 验证 | 1b |

3.3 容器运行时与网络

| 组件 | 推荐方案 | 理由 | |------|---------|------| | 容器运行时 | containerd 2.0 | K8s 默认，性能好 | | CNI | Cilium 1.16+ | eBPF 高性能，内置 Hubble 可观测性 | | CSI | 云厂商原生 CSI | CBS CSI | | DNS | CoreDNS + NodeLocal DNSCache | 减少 DNS 查询延迟 |

3.4 IaC：Terraform + Terragrunt

infra/
├── modules/           # 可复用模块
│   ├── tke/
│   ├── vpc/
│   ├── emqx/
│   └── monitoring/
├── environments/
│   ├── production/
│   └── staging/
└── terragrunt.hcl

【v3.2 新增】 IaC 安全扫描：tfsec/Checkov 接入 CI，Critical/High 阻断。

3.5 GitOps：ArgoCD

单集群部署，所有服务通过 ArgoCD 部署
ApplicationSet 按环境自动生成 Application
【v3.2 修正】 阶段 1b 先 Manual Sync，确认稳定 1-2 个月后再开 Auto Sync + Self Heal
给开发提供 argocd app sync --local 本地调试能力

3.6 FinOps 前置

阶段 1 立即执行：

Spot/抢占式实例用于无状态服务（省 60-70%）
非生产环境分时调度（晚上/周末自动缩容，省 30-40%）
Kubecost 部署到管理集群
每月 FinOps 评审会议

3.7 设备端稳定性

设备端 SDK 设计：

离线处理：断网后本地缓存消息（最多 1000 条），网络恢复后批量上传
重连退避：指数退避 + 抖动（初始 1s，最大 5 分钟）
命令队列：离线命令缓存，上线后按优先级执行
安全模式：异常情况下进入安全模式（如电机过热自动停机）
OTA 本地回滚：升级失败自动回退到上一版本固件
【v3.2 新增】防克隆：设备出厂绑定唯一硬件 ID（MCU 芯片 UID）+ 挑战-响应认证

设备端健康检查：

设备自身 CPU/内存/存储监控上报（每 5 分钟）
离线超过 24 小时标记为异常设备

【v3.2 新增】丢失/被盗场景处理：

一键吊销证书 + 远程擦除 + 行为异常自动暂停

4. 第 2 层：应用 + 数据 + 大数据架构

4.1 微服务架构演进

当前 → K8s 原生 Service + APISIX → Istio Sidecar → (评估 Ambient)
        (0-6 月)                     (6-12 月)        (12 月+)

【v3.2 新增】Istio Sidecar 资源开销预估（架构师二审）：

每个 Sidecar 增加 ~150MB 内存 + ~0.1 CPU
假设 100 服务 × 3 副本 = 300 Sidecar × 150MB = 45GB 额外内存
在预发布环境实测确认后再进入生产

4.2 API 网关：Apache APISIX

全局速率限制（防 DDoS）
JWT/OAuth2 认证
设备级限流（按 ClientID）
【v3.2 新增】WAF：启用 APISIX WAF 插件，防 SQL 注入、XSS、命令注入（OWASP Top 10）

4.3 消息队列：Kafka (KRaft)

Topic 设计：

device-telemetry-{device-type}
device-event
device-command
ota-progress

【v3.2 新增】Kafka 安全加固（安全总监二审）：

启用 SASL_SSL + Topic ACL
Schema Registry 启用认证
生产者/消费者最小权限

消费者 Lag 分级告警：

| Lag 级别 | 阈值 | 动作 | |---------|------|------| | 正常 | < 10 万条 | 正常 | | 警告 | 10-50 万条 | 告警，检查 TaskManager 资源 | | P1 | > 50 万条 | 触发自愈（自动扩容或降级） |

4.4 EMQX on K8s

| 项目 | 方案 | |------|------| | Session 持久化 | Redis Cluster（独立于业务 Redis） | | 连接风暴防护 | EMQX connack_rate 限制 + 客户端指数退避 | | LB 策略 | TCP 直通（不终结 TLS）+ 源 IP hash | | EMQX 版本 | Enterprise 版（百万级连接需要企业版功能） | | 混沌测试 | 阶段 1b 就进行（模拟 Pod 失败、网络分区） | | 设备级限流 | 按 ClientID 配置 rate_limit |

【v3.2 新增】EMQX 双云切换机制（架构师二审）：

设备路由：DNS 分地域解析（国内→腾讯云，海外→AWS）
主云 EMQX 全挂时：DNS TTL 缩短至 60s → 切换至辅云 EMQX
切换时间：DNS 传播 + 设备重连 ≈ 2-5 分钟
双云消息汇聚：阶段 3 引入 MirrorMaker 2.0 跨云复制
配置中心改为主云写，辅云只读（避免双向冲突）

【v3.2 新增】Redis Session 容量规划：

百万连接 × 1KB/Session = 1GB 基础数据
断线重连离线消息峰值：10-50GB
Redis Cluster 规划：3 主 3 从，每节点 16GB 内存

【v3.2 新增】EMQX 企业版费用（财务二审）：

| 阶段 | 连接数 | 预估月费 | |------|--------|---------| | 1b（PoC） | 10 万 | 开源版 $0∣∣2∣50 万 ∣$ 3,000-5,000 | | 3 | 100-200 万 | ~ $8, 000 - 15, 000∣∣4∣500 - 1000 万 ∣$ 15,000-25,000 |

【v3.2 新增】50 万连接压测里程碑（架构师二审）：

阶段 2 结束前完成 50 万连接压测
避免阶段 3 直接从 10 万跳到百万级

4.5 时序数据库：TDengine（PoC 验证）

【v3.2 修正】PoC 量化标准（架构师二审）：

| 验证项 | 通过标准 | 时间 | |--------|---------|------| | StarRocks 外表查询性能 | P99 < 3s（百万级数据） | 阶段 1b | | Superset 可视化兼容性 | 无异常图表类型 | 阶段 1b | | 百万级写入压测 | 写入吞吐 ≥ 10 万条/秒 | 阶段 1b | | 运维复杂度评估 | 扩容/备份/升级操作手册完成 | 阶段 1b 末 |

切换标准：以上 4 项中 ≥2 项不通过 → 切换至 TimescaleDB 决策时间点：阶段 1b 结束时做出决策

4.6 跨云数据一致性策略

| 组件 | 主云 | 辅云 | 同步方式 | 一致性级别 | |------|------|------|---------|-----------| | Kafka | 主云一套 | 阶段 3 评估 MirrorMaker | — | 强一致（副本 3） | | StarRocks | 主云一套 | 辅云 Iceberg 外表直查 | Iceberg 共享存储 | 最终一致 | | EMQX | 双云独立 | 设备就近接入 | 阶段 3 MirrorMaker | 各自独立 | | TDengine | 主云 | 辅云 | 异步复制 | 最终一致 | | 配置中心 | 主云写 | 辅云只读 | 单向同步 | 最终一致 |

4.7 大数据平台

| 阶段 | 大数据能力 | 交付物 | |------|-----------|--------| | 1a-1b | 基础数据采集 | EMQX → Kafka 直通 | | 2 | 实时计算 + 基础报表 | Kafka → StarRocks 直通 | | 3 | 完整数据平台 | Flink + Iceberg 引入 | | 4 | 数据治理 + AI | 全链路 + 数据血缘 + Text-to-SQL |

阶段 2 报表延迟说明（架构师二审）：Kafka Connect Sink 到 StarRocks 有秒级到分钟级延迟（取决于批次大小配置）。阶段 2 报表是近实时（分钟级延迟），阶段 3 引入 Flink 后才是秒级实时。

4.8 【新增】OTA 升级稳定性保障（架构师二审）

| 项目 | 方案 | |------|------| | 灰度策略 | 按设备批次：1% → 5% → 10% → 50% → 100% | | 回滚触发 | 失败率 > 5% 自动暂停并回滚 | | 云端回滚 | 推送上一版本固件，设备端自动回滚 | | 监控 | OTA 成功率实时 Dashboard，SLO ≥ 99% | | 自动暂停 | 失败率超过阈值后自动暂停推送，告警通知 |

5. 第 3 层：可观测性 + 安全 + DevSecOps

5.1 可观测性：OTel + VM + Loki + Tempo

| 组件 | 方案 | 理由 | |------|------|------| | 采集 | OpenTelemetry | 事实标准，统一 logs/metrics/traces | | 指标 | VictoriaMetrics | 比 Prometheus 省 3-5x 资源 | | 日志 | Grafana Loki | 轻量级，与 Grafana 原生集成 | | 链路 | Grafana Tempo | 无需索引，成本极低 | | 展示 | Grafana | 统一面板 |

【v3.2 新增】OTel 接入开发指南（一线开发二审）：

必须采集的 RED 指标：Rate（请求速率）、Errors（错误率）、Duration（延迟）
trace_id 注入日志规范：所有日志必须包含 trace_id 和 span_id
推荐采样率：生产环境 1-5%，P0 场景 100%
自定义 metric 命名规范：{service}_{type}_{unit}，如 emqx_connections_active_total

5.2 告警策略（v3.2 修正）

| 层级 | 方法 | 用途 | |------|------|------| | 生产告警 | 静态阈值（唯一触发条件） | P0/P1/P2 告警 | | 辅助发现 | ML 异常检测 | 仪表盘标注、趋势预警，不直接触发告警 | | 告警降噪 | 告警聚合 | 减少告警风暴 | | 动态基线 | 基于历史数据的动态阈值 | 补充静态阈值，不替代 |

告警分级：

| 级别 | 响应时间 | 通知方式 | 覆盖时间 | 示例规则 | |------|---------|---------|---------|---------| | P0 | 5 分钟 | 飞书 + 电话 | 7×24 | MQTT 连接成功率 < 99% 持续 2 分钟 | | P1 | 15 分钟 | 飞书 + 电话 | 8:00-22:00 | API 错误率 > 1% 持续 5 分钟 | | P2 | 1 小时 | 飞书 | 8:00-22:00 | 磁盘使用率 > 80% |

【v3.2 新增】告警规则生命周期（SRE 二审）：

每条告警规则设置 90 天有效期
到期必须 review 或自动静默
每月 review 告警有效性（误报率 > 50% 的规则下线）

5.3 On-call 机制（v3.2 修正）

| 阶段 | On-call 覆盖 | 策略 | |------|-------------|------| | 1a-1b | 工作时间 8:00-22:00 | P0 非工作时间仅电话升级 | | 2 | 工作时间 + P0 7×24 | 主 + 备轮值，每人每月不超过 2 周 | | 3 | 7×24 全覆盖 | NOC 外包夜间值守，内部处理升级 |

【v3.2 新增】P0 升级链（SRE 二审）：

L1: on-call 值班（SRE）
    ↓ 15 分钟未响应
L2: SRE Lead / Tech Lead
    ↓ 15 分钟未响应
L3: CTO / VP

【v3.2 新增】On-call 工具链（SRE 二审）：

阶段 1：飞书告警群 + 飞书审批流值班表（零成本）
阶段 2：PagerDuty 或 Opsgenie（$21/人/月），管理轮值、升级、确认
外包值守必须有清晰的升级矩阵，不能只说"NOC 夜间值守"

【v3.2 新增】On-call 排班策略（一线开发二审）：

阶段 1-2：只有 SRE 小队 on-call，开发不排班
开发只在"自己写的服务出问题"时才被呼叫（通过服务 owner 映射）
疲劳度积分阈值：月累计 30 分触发预警、50 分强制休息 2 周

5.4 IoT 安全（v3.2 修正）

设备密钥存储（v3.2 三层方案）

| 设备能力 | 方案 | |---------|------| | 高端 | TPM 2.0 / SE 芯片（NXP A71CH / Infineon OPTIGA / ATECC608B） | | 中端 | ARM TrustZone TEE + 硬件 KeyStore | | 低端 | MCU 内置 Flash Read Protection + AES 加密存储密钥 |

【v3.2 新增】密钥轮换：

年度自动轮换 + 事件触发轮换（疑似泄露时）
出厂安全烧录 + 供应链审计 + 批次可追溯

数据驻留与合规

【v3.2 新增】数据分类分级标准（安全总监二审）：

| 级别 | 类型 | 加密 | 访问控制 | 保留策略 | |------|------|------|---------|---------| | L1 公开 | 产品文档、公开 API | 传输加密 | 公开 | — | | L2 内部 | 设备遥测数据、运维数据 | 传输+存储加密 | 内部员工 | 180 天 | | L3 敏感 | 用户个人信息、位置数据 | 传输+存储+脱敏 | RBAC + ABAC | 按需，可删除 | | L4 机密 | 设备密钥、CA 私钥 | HSM 保护 | 最小权限 + 审计 | 永久归档 |

【v3.2 新增】数据出境合规：

中国用户数据只存腾讯云中国区域
AWS 仅处理海外用户数据
海外运维/技术支持场景下使用脱敏数据（最小可用原则）
管理面与数据面隔离：运维管理数据可跨境，业务数据不可
如达到数据出境安全评估门槛，向网信办申报
增加 DPO（数据保护官）角色

PKI 架构（v3.2 修正）

| 项目 | 方案 | |------|------| | Root CA | 离线 HSM 存储，10 年有效期，仅签发 Intermediate CA 时上线 | | Intermediate CA | 在线，3-5 年有效期，按设备类型/客户/区域分区 | | Device Cert | 1-2 年有效期，提前 30 天自动续期 | | OCSP | OCSP Stapling + 服务端缓存 | | CRL | EMQX 集成 CRL 自动拉取，设备端至少缓存最近一次 CRL | | 证书吊销 | 吊销后所有边缘节点/服务快速感知（K8s cert-manager webhook） |

设备生命周期安全

注册 → 激活 → 运行 → 暂停 → 退役
  │       │       │       │       │
  │ 防克隆 │ 出厂   │ 行为   │ 证书   │ 证书吊销
  │ 机制   │ 证书链 │ 基线   │ 暂停   │ + 连接踢出
  │        │ 验证   │ 检测   │        │ + 数据清理

行为基线明确定义（安全总监二审）：

消息频率、数据范围、通信目标、地理围栏
偏离基线 → 自动暂停 + 告警

退役数据清理（安全总监二审）：

设备端：安全擦除固件 + 密钥
云端：匿名化/脱敏处理用户数据，按法规保留审计数据

5.5 DevSecOps（v3.2 修正）

CI 安全门禁：

| 阶段 | 工具 | 扫描内容 | 门禁策略 | |------|------|---------|---------| | 编码 | Semgrep + CodeQL | SAST | Critical/High 阻断 | | 编码 | trufflehog / gitleaks | 密钥泄露 | 任何匹配阻断 | | 构建 | Trivy | 容器镜像扫描 | Critical/High 阻断 | | 构建 | Snyk | 依赖漏洞扫描 | Critical 阻断，High 72h SLA | | 构建 | tfsec / Checkov | IaC 安全扫描 | Critical/High 阻断 | | 测试 | OWASP ZAP | DAST | Critical 阻断 | | 部署 | OPA/Gatekeeper | 策略即代码 | 违反策略阻断 | | 运行时 | Falco | 运行时安全监控 | 告警 + 自动响应 |

【v3.2 新增】容器镜像签名（安全总监二审）：

cosign + Sigstore 供应链安全
生产环境只允许已签名镜像运行

【v3.2 新增】全链路密钥扫描：

代码仓库 + CI 变量 + K8s Secret + 配置中心

【v3.2 新增】应急响应预案（安全总监二审）：

0day 定位 → 影响面评估 → 修复验证 → 复盘
季度渗透测试（从阶段 2 开始）

5.6 【新增】安全基线清单（v3.2，阶段 1a 前完成）

安全总监二审：这些可以在 1-2 周内完成，不阻塞主流程。

| # | 项目 | 耗时 | 负责人 | |---|------|------|--------| | 1 | K8s Pod Security Standards（Restricted 模式） | 1 天 | SRE | | 2 | NetworkPolicy 默认拒绝 | 1 天 | SRE | | 3 | RBAC 最小权限 review | 2 天 | SRE | | 4 | APISIX WAF 启用 | 1 天 | SRE | | 5 | 日志脱敏规则（OTel 采集前） | 2 天 | 开发 | | 6 | 备份策略定义（RPO/RTO） | 2 天 | SRE | | 7 | 多租户隔离方案定义 | 2 天 | 架构师 | | 8 | Kafka ACL 启用 | 1 天 | SRE | | 9 | AI 安全护栏定义（见 6.6 节） | 2 天 | SRE + 安全 |

5.7 零信任落地路径

| Phase | 内容 | 时间 | |-------|------|------| | Phase 1 | mTLS 服务间通信（Istio/Cilium） | 阶段 2 | | Phase 2 | 身份基访问控制 + BeyondCorp | 阶段 3 | | Phase 3 | 持续验证 + 风险自适应访问 | 阶段 4 |

6. 第 4 层：SRE + AI 智能运维

6.1 SLO 体系

| 服务 | SLI | SLO | SLA | |------|-----|-----|-----| | 设备接入 | MQTT 连接成功率 | ≥ 99.95% | 99.9% | | 消息传输 | 消息端到端延迟 P99 | ≤ 500ms | ≤ 1s | | 命令下发 | 下行命令到达率 | ≥ 99.9% | 99.5% | | App API | 请求成功率 | ≥ 99.95% | 99.9% | | OTA 升级 | 升级成功率 | ≥ 99% | 98% |

6.2 Error Budget 策略

| Error Budget 消耗 | 动作 | |------------------|------| | ≤ 50% | 正常发布 | | 50% - 80% | 发布需 SRE 审批 | | 80% - 100% | 仅安全修复 + P0 bug | | > 100% | 停止所有变更，强制 Post-mortem |

【v3.2 新增】Error Budget 与稳定性预算对齐（SRE 二审）：

SLO 99.95% → 年度 Error Budget = 4.38 小时
稳定性预算的"非计划内故障"上限 = 4 小时/年（原 8 小时，已对齐）
Error Budget Dashboard 在阶段 2 实现（原阶段 1 手工算撑不住）

6.3 On-call 升级链

L1: on-call 值班（SRE）
    ↓ 15 分钟未响应
L2: SRE Lead / Tech Lead
    ↓ 15 分钟未响应
L3: CTO / VP

6.4 MTTR 定义（v3.2 新增）

SRE 二审：MTTR 定义不完整，需要四阶段拆分。

| 阶段 | 时间 | 说明 | |------|------|------| | Detect | < 2 分钟 | 告警触发 | | Triage | < 3 分钟 | 确认问题 + 初步定级 | | Mitigate | < 5 分钟 | 止血/降级 | | Resolve | 不限制 | 彻底修复（跟进 Post-mortem） |

MTTR 目标 = Detect + Triage + Mitigate = < 10 分钟（核心 P0 场景，阶段 4） Mitigate 阶段目标 = < 5 分钟（阶段 4 核心场景自动止血）

| 阶段 | MTTR 目标 | 说明 | |------|----------|------| | 1-2 | < 60 分钟 | 依赖 Runbook 执行 | | 3 | < 30 分钟 | AI 辅助根因分析 | | 4 | < 10 分钟（核心 P0） | 半自动自愈覆盖核心场景 |

【v3.2 新增】 阶段 2 引入 Incident Timeline 自动记录工具，用于 MTTR 度量。

6.5 降级架构（v3.2 分阶段定义）

【v3.2 修正】（SRE 二审）：阶段 1-2 和阶段 3+ 的降级能力不同。

| 降级层级 | 阶段 1-2 | 阶段 3+ | |---------|---------|---------| | L1 功能降级 | ✅ 关闭非核心功能 | ✅ 同左 | | L2 流量降级 | ✅ 限流 + 429 | ✅ 同左 | | L3 数据降级 | ✅ 返回缓存/默认值 | ✅ 同左 | | L4 边缘降级 | 设备端 SDK 离线模式（纯设备自治） | 边缘 K3s 节点承载基本运行 | | L5 熔断保护 | 单云内跨 AZ 调用熔断 | 跨云/跨区调用熔断 |

降级触发机制：

L1-L2：自动触发（基于 SLO/Error Budget）
L3-L5：人工确认（on-call 评估后决定）

6.6 AI 智能运维（v3.2 修正）

【v3.2 新增】AI 安全护栏（安全总监二审）：

| 风险 | 防护措施 | |------|---------| | Prompt 注入 | 输入经过清洗和沙箱化；系统 prompt 使用模板引擎，用户输入作为参数而非拼接；输出前进行安全策略检查 | | 自愈误操作 | 操作白名单（只允许预定义的有限操作）；操作前影响面评估；自动回滚机制（超时/异常自动撤销）；高危操作双人审批 | | AI 训练数据泄露 | 生产日志用于 AI 训练前必须脱敏（自动 PII 检测 + 替换）；禁止将包含密钥/个人数据的日志送入外部 LLM；AI 数据使用审计日志 | | LLM API 依赖 | 多模型 fallback（GLM → 备用模型） |

自愈 Agent 三级分类（v3.2 修正）：

| 级别 | 场景 | 执行方式 | |------|------|---------| | 全自动 | Pod 重启（CrashLoopBackOff > 3 次） | 自动执行，审计日志 | | 通知+自动执行 | HPA 扩容、降级开关 | 告警通知 On-call，10 分钟不响应则自动执行 | | 人工审批 | DNS 切换、跨集群迁移 | 必须人工确认 |

【v3.2 新增】 自愈 Agent 安全约束：同一 on-call 人员有活跃 P0 incident 时，自动执行暂停，升级到下一级。

AI 运维定位表：

| AI 能力 | v3.0 定位 | v3.2 定位 | 实施时间 | |---------|----------|----------|---------| | RCA Agent | 自动根因分析 | 辅助工具：告警后自动生成分析报告供人参考 | 阶段 3 | | 自愈 Agent | 自动执行 | 半自动：AI 给建议，人工确认执行 | 阶段 3 | | Post-mortem | AI 自动生成 | AI 生成初稿和时间线，根因和改进措施由人讨论确定 | 阶段 2 | | AI Code Review | 流程卡点 | 辅助审查：所有 MR 自动审查，聚合为 summary ≤5 条 | 阶段 2 | | AI 测试生成 | 80% 覆盖率目标 | 辅助生成：生成基础用例，人工补充 | 阶段 2 | | 智能告警降噪 | ML 替代静态阈值 | 告警聚合：合并相关告警，不替代阈值 | 阶段 2 | | Text-to-SQL | 自然语言查数据 | 辅助工具，Superset Dashboard 为主 | 阶段 4 |

6.7 混沌工程

| 阶段 | 内容 | |------|------| | 1b | GameDay：人工手动注入故障（kill pod、模拟网络延迟），验证监控告警 | | 2 | Chaos Mesh 部署，自动化演练 | | 3 | AIoT 场景专属混沌实验（EMQX 节点故障、Kafka 分区丢失、设备连接风暴） |

6.8 组件运维责任人矩阵（v3.2 新增）

SRE 二审：阶段 2 有 14+ 组件需要运维，必须有明确的责任人。

| 组件 | 负责人 | 备份 | |------|--------|------| | K8s (TKE) | SRE | DevOps | | ArgoCD | DevOps | SRE | | Terraform | SRE | DevOps | | APISIX | SRE | 开发 | | Kafka | SRE | 大数据工程师 | | EMQX | SRE | 开发 | | StarRocks | 大数据工程师 | SRE | | VictoriaMetrics | SRE | DevOps | | Loki | SRE | DevOps | | Tempo | SRE | DevOps | | Grafana | SRE | 开发 | | Cilium | SRE | — | | Trivy | DevOps | SRE | | Chaos Mesh | SRE | 开发 |

组件健康度仪表盘（v3.2 新增）：阶段 1b 部署，统一展示所有组件运行状态。

6.9 阶段 Gate Review 标准（v3.2 新增）

SRE + 架构师二审：各阶段之间必须有明确的准入/准出标准。

| Gate | 准入条件 | |------|---------| | 1a → 1b | VM + Grafana 上线 + 3 个核心 SLO 定义 + 基础告警生效 + CI 模板化 + 第一次 Post-mortem 完成 | | 1b → 2a | Loki + Tempo 上线 + On-call 轮值运行 ≥2 周 + Terraform 管理核心 infra + ArgoCD Manual Sync 稳定 + EMQX 10 万连接通过 + 第一次 GameDay 完成 | | 2a → 2b | Kafka + StarRocks + Error Budget Dashboard 全部上线并稳定运行 ≥2 周 + 等保差距分析完成 + AI Code Review 运行 ≥2 周 | | 3 → 4 | 50 万连接压测通过 + 等保认证通过 + 全链路可观测性成熟 + 混沌演练覆盖率 ≥80% |

7. 第 5 层：组织与工程文化

7.1 SRE 团队

| 阶段 | SRE 团队 | 职责 | |------|---------|------| | 1-2 | 统一 SRE 小队 3-4 人 | 基础设施 + 可观测性 + SLO + 告警 | | 3 | SRE 小队 5-6 人 | 增加混沌工程 + AI 运维 | | 4 | 评估是否需要嵌入式模式 | 团队 > 60 人时再拆分 |

SRE 职责边界：

✅ 可靠性、可扩展性、性能、监控
✅ On-call、Incident Management、Post-mortem
✅ 自动化工具、平台能力
❌ 不做业务功能开发
❌ 不做运维手工操作（必须自动化）

7.2 稳定性文化

| 实践 | 频率 | 参与者 | 度量 | |------|------|--------|------| | 事故演练（GameDay） | 每月 | 全体技术 | 演练覆盖率 | | Post-mortem 复盘 | 每次 P1+ 事故 | 相关团队 | 改进措施完成率 > 80% | | Error Budget Review | 每周 | 各团队 Lead | SLO 达成率 | | 可靠性周报 | 每周 | 全体技术 | 事故数/MTTR | | SRE 培训 | 每季度 | 新入职 | 培训完成率 |

7.3 Blameless 文化落地保障（v3.2 新增）

一线开发二审：Blameless 在中国团队很难真正落地。

Post-mortem 文档明确标注"不用于绩效评估"，由 CTO 或 VP 级别签字背书
第一次 Post-mortem 拿管理层自己的失误开刀，示范 blameless 的态度
SLO 明确不挂钩绩效，Error Budget 消耗 = 需要修的技术债，不是个人问题
改进措施必须指派 owner + deadline，否则复盘会变成吐槽大会

7.4 知识管理

AI 生成 Post-mortem 初稿和时间线
AI 生成 Runbook 初稿（人类审核 + 演练验证）
AI 生成 API 文档
每个 Incident 的经验自动归档

7.5 培训体系

| 培训内容 | 对象 | 周期 | 形式 | |---------|------|------|------| | K8s 基础 | 全体开发 | 入职 | 2 天 Workshop + 4 周实操辅导 | | 可观测性实战 | 全员 | 季度 | 在实际排查中边做边学 | | SRE 基础 | Tech Lead + SRE | 季度 | Google SRE Book 读书会，6 周 | | AI 工具使用 | 全体开发 | 每月 | 分享会 | | 安全意识 | 全体 | 半年 | 在线培训 |

7.6 稳定性预算（v3.2 对齐）

| 预算项 | 年度预算 | 季度消耗 | 剩余 | |--------|---------|---------|------| | 计划内维护窗口 | 52 小时 | 追踪 | 追踪 | | 非计划内故障 | 4 小时（与 SLO 99.95% Error Budget 对齐） | 追踪 | 追踪 | | 变更失败次数 | 50 次 | 追踪 | 追踪 | | 混沌演练次数 | 12 次 | 追踪 | 追踪 |

每月 Review，接近阈值时冻结变更。 预算耗尽流程：SRE Lead 提出 → CTO 审批 → 冻结变更 → 整改完成后解冻。

8. 四阶段落地路线图（v3.2 修正）

阶段 1a：止血（第 1-6 周）

| 维度 | 交付物 | 验收标准 | 耗时 | |------|--------|---------|------| | 安全基线 | K8s 加固 + WAF + 备份策略 | 安全基线清单 9 项完成 | 2 周 | | 可观测性 | VictoriaMetrics + Grafana | 核心服务 metrics 可见 | 2 周 | | SLO | 定义 3 个核心 SLO（初版） | 设备接入成功率、API 成功率、消息延迟 | 1 周 | | 告警 | 基础告警规则（静态阈值） | P0 飞书通知，至少 3-5 条具体规则 | 1 周 | | CI/CD | GitLab CI 模板化（核心服务） | lint → build → test，CI <10 分钟 | 1 周 | | 安全 | Trivy + 密钥扫描 + IaC 扫描 | 所有镜像自动扫描，Critical/High 阻断 | 0.5 周 | | 文化 | 第一次 Post-mortem | 拿最近一次线上事故复盘 | 1 次 |

人力：2-3 人专注 工具成本：$0（全部开源）

阶段 1b：看见（第 7-12 周）

| 维度 | 交付物 | 验收标准 | |------|--------|---------| | 可观测性 | Loki + Tempo 部署 | logs + traces 可查，trace_id 关联 | | 可观测性 | OTel 接入开发指南 | RED 指标 + trace 规范 + 采样率 | | On-call | 工作时间轮值 + P0 升级链 | 8:00-22:00 覆盖，L1→L2→L3 | | IaC | Terraform 管理核心 infra | terraform apply 可复现 | | GitOps | ArgoCD 部署（Manual Sync） | 所有服务通过 ArgoCD 部署 | | EMQX | EMQX on K8s 基础部署 | 支持 10 万连接 + 混沌测试 | | 混沌 | 第一次 GameDay | kill pod、模拟网络延迟 | | 安全 | 日志脱敏 + 镜像签名 + Kafka ACL | 安全基线清单完成 |

人力：3-5 人 工具成本：~ $1, 000/ 月 * * 云资源 * * ：$ 4,000-7,000/月

阶段 2a：数据管道 + 报表（第 3-4 月）

| 维度 | 交付物 | 验收标准 | |------|--------|---------| | APISIX | API 网关 + WAF | 统一入口 + 限流 + 认证 + WAF | | Kafka | 生产级 Kafka 集群 | EMQX Data Bridge 直通 + SASL_ACL | | StarRocks | 基础报表查询 | 核心报表近实时（分钟级延迟） | | AI Code Review | CodeRabbit 接入 CI | 所有 MR 自动审查，summary ≤5 条 | | AI 测试辅助 | Copilot 生成单元测试 | 核心服务覆盖率提升至 60% | | Error Budget | Grafana Dashboard | 自动展示 | | 安全 | 等保差距分析 + 渗透测试 | 输出差距报告 | | 混沌工程 | Chaos Mesh 部署 | 月度演练 | | 等保 | 安全产品采购 + 整改启动 | 等保三级一次性预算 $30,000-50,000 |

阶段 2b：Service Mesh + Runbook（第 5-6 月）

| 维度 | 交付物 | 验收标准 | |------|--------|---------| | Istio Sidecar | 核心服务 mTLS | 核心服务全覆盖 + 资源开销实测 | | Flink | 1-2 个实时场景 | 实时在线数、实时故障率 | | 数据质量 | 基础监控 | Kafka Lag 告警、数据缺失告警 | | Runbook | 核心告警 Runbook | 每个 P0/P1 告警有标准操作手册 | | 组件健康度 | 统一 Dashboard | 14+ 组件运行状态可见 |

Gate Review：2a 的 Kafka + StarRocks + Error Budget Dashboard 全部上线并稳定运行 ≥2 周后，才进入 2b。

人力：5-7 人 工具成本：~ $5, 000 - 8, 000/ 月（含 E M QX E n t er p r i se$ 3,000-5,000） 云资源增量：~$12,000-18,000/月

阶段 3：智能升级（第 6-12 月）

| 维度 | 交付物 | 验收标准 | |------|--------|---------| | Flink | 完整实时计算平台 | Flink 1.x LTS，5+ 场景 | | Iceberg | 数据湖上线 | 原始数据入湖 | | RCA Agent | v1（辅助工具） | P0 事故后自动生成分析报告 | | 自愈 Agent | 预定义场景（半自动） | Pod 重启全自动，扩容/降级半自动 | | AI Post-mortem | 初稿 + 时间线自动生成 | 所有 P0+ 自动生成 | | 评估 Ambient Mode | 技术预研 | Sidecar 运行 6 个月后评估迁移 | | 评估 AWS 部署 | 海外需求评估 | 如需，引入多集群 | | 等保 | 通过等保认证 | 三级 | | On-call | 7×24 覆盖 | NOC 外包夜间值守 | | 边缘 K3s | 试点部署 | 边缘设备接入 | | EMQX | 升级到百万级 | 企业版 ~$8,000-15,000/月 | | 压测 | 50 万连接压测 | 压测报告 |

Gate Review：50 万连接压测通过 + 等保认证通过 + 全链路可观测性成熟 + 混沌演练覆盖率 ≥80%。

人力：8-12 人 工具成本：~ $10, 000 - 18, 000/ 月（含 E M QX E n t er p r i se ） * * 云资源增量 * * ：$ 25,000-40,000/月

阶段 4：规模化（第 12-36 月）

| 维度 | 交付物 | 验收标准 | |------|--------|---------| | 千万级 | 全链路千万级压测通过 | 压测报告 | | Karmada | 按需引入（仅集群数>4时） | 跨集群调度 | | 边缘计算 | K3s 边缘集群 | 边缘智能 + 离线运行 | | 全栈 AIOps | 自建或商业工具 | 替换部分商业工具 | | 数据治理 | 全链路数据血缘 | 数据质量评分 | | 预测性维护 | 故障预测模型 | 准确率 > 80%（务实目标） | | FinOps | 成本优化闭环 | 云成本优化 30%+ |

人力：12-20 人 工具成本：~ $15, 000 - 25, 000/ 月 * * 云资源增量 * * ：$ 50,000-90,000/月

9. 资源投入估算（v3.2 修正）

人力投入

| 角色 | 阶段 1a | 阶段 1b | 阶段 2 | 阶段 3 | 阶段 4 | |------|--------|--------|--------|--------|--------| | 平台 SRE | 1 | 2 | 3 | 4 | 5 | | DevOps | 1 | 1 | 1 | 1 | 1 | | 大数据工程师 | 0 | 0 | 1 | 2 | 3 | | AI/ML 工程师 | 0 | 0 | 0 | 1 | 2 | | 安全工程师 | 0 | 0 | 0.5 | 1 | 1 | | 业务开发（兼职） | 1 | 2 | 3 | 4 | 5 | | 合计 | 3 | 5 | 7.5 | 13 | 17 |

成本估算（月，v3.2 修正版）

| 阶段 | 人力成本 | 工具 | 云资源 | 合规 | 总计 | |------|---------|------|--------|------|---------| | 1a (0-1.5 月) | ~ $30, 000∣$ 0 | $3, 000 - 5, 000∣$ 0 | ~ $33, 000 - 35, 000 * * ∣∣1 b (1.5 - 3 月) ∣$ 50,000 | $1, 000∣$ 4,000-7,000 | $0∣ * *$ 55,000-58,000 | | 2 (3-6 月) | ~ $75, 000∣$ 5,000-8,000 | $12, 000 - 18, 000∣$ 0 | **~ $92, 000 - 101, 000 * * ∣∣2 等保一次性 ∣—∣—∣—∣$ 30,000-50,000 | 一次性 | | 3 (6-12 月) | ~ $130, 000∣$ 10,000-18,000 | $25, 000 - 40, 000∣$ 0 | ~ $165, 000 - 188, 000 * * ∣∣4 (12 - 36 月) ∣$ 170,000 | $15, 000 - 25, 000∣$ 50,000-90,000 | $0∣ * *$ 235,000-285,000 |

修正说明：

阶段 2 云资源从 $8, 000 修正为$ 12,000-18,000（Kafka 多 AZ、StarRocks、APISIX）

阶段 2 工具成本含 EMQX Enterprise ~$3,000-5,000/月

等保三级一次性预算 $30,000-50,000（单独列项）

阶段 3 工具成本含 EMQX Enterprise ~$8,000-15,000/月

阶段 4 云资源 buffer 从 100% 调整为更保守的上限

需要 CEO/董事会决策的事项

| 决策 | 影响 | 何时决策 | |------|------|---------| | 单云策略（腾讯云为主） | 阶段 1-2 专注国内，年成本省 ¥500 万+ | 阶段 1 启动前 | | 阶段 2-3 月成本 ¥92-188 万 | 占营收比重 | 阶段 1b 结束前 | | SRE 团队独立建制 | 组织架构调整 | 阶段 1 启动前 | | 等保合规投入 | 一次性 ¥21-55 万，年维护 ¥5-10 万 | 阶段 1 启动前 | | EMQX Enterprise 授权 | 百万级年费 ¥50-100 万+ | 阶段 1b PoC 时获取报价 |

10. 业界案例支撑（精选）

| 公司 | 实践 | 对我们的启发 | |------|------|-------------| | Google | SRE 体系发源地 | Error Budget 驱动决策，Blameless 文化 | | 阿里 | 双 11 全链路压测 | 压测能力建设应从早期开始 | | 字节 | Service Mesh 大规模落地 | Sidecar 模式成熟后再评估 Ambient | | EMQX 用户（蔚来） | 千万级车联网 | EMQX → Kafka 直通架构已验证 | | Netflix | Chaos Monkey | 混沌工程常态化，先 GameDay 再自动化 |

附录 A：v3.0 → v3.1 → v3.2 完整变更清单

| # | 变更 | 轮次 | 来源 | |---|------|------|------| | 1 | 设计原则改为 SRE-first, AI-enhanced | 一轮 | CTO + SRE + 架构师 | | 2 | 9 层合并为 5 层 | 一轮 | 架构师 | | 3 | 阶段 1 拆为 1a+1b | 一轮 | 架构师 + 研发总监 | | 4 | Karmada 延后至阶段 4 | 一轮 | CTO + 架构师 + SRE | | 5 | Istio 改用 Sidecar 先 | 一轮 | 架构师 + SRE | | 6 | Flink 改用 1.x LTS | 一轮 | SRE | | 7 | 告警策略改为静态阈值为主 | 一轮 | SRE | | 8 | On-call 改为工作时间优先 | 一轮 | SRE | | 9 | 自愈 Agent 改为半自动 | 一轮 | SRE | | 10 | MTTR 目标改为分阶段 | 一轮 | SRE | | 11 | 补充设备端稳定性 | 一轮 | SRE | | 12 | 补充跨云数据一致性策略 | 一轮 | 架构师 | | 13 | 补充设备密钥存储方案 | 一轮 | 安全总监 | | 14 | 补充等保/数据出境合规 | 一轮 | 安全总监 | | 15 | 补充 PKI 架构细节 | 一轮 | 安全总监 | | 16 | 补充 CI 安全门禁 | 一轮 | 安全总监 | | 17 | 补充降级架构设计 | 一轮 | SRE | | 18 | 补充稳定性预算 | 一轮 | SRE | | 19 | 补充 On-call 疲劳管理 | 一轮 | SRE | | 20 | 成本估算增加 buffer | 一轮 | CTO + SRE | | 21 | SRE 团队改为统一小队 | 一轮 | CTO | | 22 | FinOps 前置到阶段 1 | 一轮 | CTO | | 23 | AI 定位为辅助 | 一轮 | CTO + 研发总监 | | 24 | 大数据阶段 2 简化为直通 | 一轮 | 研发总监 | | 25 | TDengine 需 PoC 验证 | 一轮 | 架构师 | | 26 | EMQX 补充关键细节 | 一轮 | 架构师 | | 27 | P0 升级链 | 二审 | SRE | | 28 | On-call 工具链 | 二审 | SRE | | 29 | MTTR 四阶段定义 | 二审 | SRE | | 30 | 稳定性预算与 Error Budget 对齐 | 二审 | SRE | | 31 | 降级架构分阶段定义 | 二审 | SRE | | 32 | 告警规则生命周期 | 二审 | SRE | | 33 | 组件运维责任人矩阵 | 二审 | SRE | | 34 | 阶段 gate review 标准 | 二审 | SRE + 架构师 | | 35 | AI 引入约束（≥3 个月手工流程） | 二审 | SRE | | 36 | 自愈 Agent 安全约束 | 二审 | SRE | | 37 | AI 安全护栏 | 二审 | 安全 | | 38 | 安全基线清单（9 项） | 二审 | 安全 | | 39 | CI 门禁分级策略 | 二审 | 安全 | | 40 | 设备密钥三层方案 + 轮换 + 分发 | 二审 | 安全 | | 41 | PKI 根 CA 保护（离线 HSM）+ CRL | 二审 | 安全 | | 42 | 数据分类分级标准 | 二审 | 安全 | | 43 | 容器镜像签名（cosign） | 二审 | 安全 | | 44 | WAF 启用 | 二审 | 安全 | | 45 | 日志脱敏 | 二审 | 安全 | | 46 | Kafka ACL | 二审 | 安全 | | 47 | 应急响应预案 | 二审 | 安全 | | 48 | EMQX Enterprise 授权费计入 | 二审 | 财务 | | 49 | 等保合规预算（一次性 $30-50K） | 二审 | 财务 | | 50 | 云资源成本修正 | 二审 | 财务 | | 51 | CI <10 分钟 | 二审 | 一线开发 | | 52 | ArgoCD Manual Sync 优先 | 二审 | 一线开发 | | 53 | SLO 不挂钩绩效 | 二审 | 一线开发 | | 54 | AI Code Review 聚合 summary ≤5 条 | 二审 | 一线开发 | | 55 | Blameless 文化落地保障 | 二审 | 一线开发 | | 56 | OTA 升级稳定性保障 | 二审 | 架构师 | | 57 | EMQX 双云切换机制 | 二审 | 架构师 | | 58 | 配置中心改为单向同步 | 二审 | 架构师 | | 59 | 50 万连接压测里程碑 | 二审 | 架构师 | | 60 | Istio Sidecar 资源开销预估 | 二审 | 架构师 |

附录 B：安全基线清单（阶段 1a 前完成）

| # | 项目 | 验收标准 | 耗时 | |---|------|---------|------| | 1 | K8s Pod Security Standards | Restricted 模式，无 privileged 容器 | 1 天 | | 2 | NetworkPolicy 默认拒绝 | 所有 namespace 默认 deny | 1 天 | | 3 | RBAC 最小权限 | 无 cluster-admin 滥用 | 2 天 | | 4 | APISIX WAF 启用 | OWASP Top 10 防护生效 | 1 天 | | 5 | 日志脱敏规则 | OTel 采集前脱敏手机号/身份证/密钥 | 2 天 | | 6 | 备份策略 | RPO < 1 小时，RTO < 4 小时 | 2 天 | | 7 | 多租户隔离方案 | Namespace 隔离 + 资源配额 | 2 天 | | 8 | Kafka ACL | SASL_SSL + Topic ACL 启用 | 1 天 | | 9 | AI 安全护栏 | Prompt 注入防护 + 操作白名单定义 | 2 天 |

方案状态：v3.2 二审终稿已完成。5 位专家（架构师、SRE、一线开发、安全、财务）的审查意见已全部闭环（56 项变更）。 下一步：召开方案评审会，确认阶段 1a 的具体执行计划和安全基线清单。

📚 喵喵的笔记库

探索

AIoT后端稳定性保障方案-v3.2-二审终稿