1. 课程导论：RTO概念、容器网络运维挑战、蓝绿发布与发布包完整性的关系
1.1 RTO 概念与容灾核心指标
恢复时间目标（Recovery Time Objective, RTO）是容灾与高可用架构中最关键的量化指标之一。它定义了从故障发生到业务系统完全恢复所允许的最大时间窗口。在云原生环境中，RTO 直接决定了容器编排、网络策略、发布策略的设计底线。
| 指标 | 定义 | 典型值（云原生场景） | 影响范围 |
|---|---|---|---|
| RTO | 恢复时间目标 | 分钟级（1~15 min） | 基础设施、网络、应用层 |
| RPO | 恢复点目标 | 秒级（0~60 s） | 数据持久化、状态同步 |
| MTTR | 平均修复时间 | 与 RTO 强相关 | 运维流程、自动化程度 |
关键认知： RTO 不是纯技术指标，而是业务连续性承诺。容器网络运维中，每一次蓝绿发布、网络策略变更、发布包校验失败，都会直接消耗 RTO 预算。运维团队必须将 RTO 拆解为可观测、可度量的子阶段。
1.2 容器网络运维的核心挑战
容器网络相比传统虚拟化网络，引入了更复杂的动态性、扁平化地址空间和更细粒度的策略控制。以下是运维中最突出的四个挑战：
- 网络拓扑动态变化：Pod 创建/销毁、扩缩容、节点故障迁移导致 IP 地址频繁变更，传统静态 ACL 和防火墙规则失效。
- CNI 插件多样性：Flannel、Calico、Cilium、Weave 等插件在性能、安全策略、可观测性上差异巨大，运维排障路径不统一。
- 服务网格与东西向流量：微服务间调用链复杂，Sidecar 代理引入额外延迟，网络故障定位需要全链路追踪能力。
- 网络策略与安全合规：NetworkPolicy 的生效顺序、默认拒绝规则、命名空间隔离策略配置不当会导致大面积服务中断。
运维建议： 在容器网络运维中，建议将网络策略变更纳入蓝绿发布流程，通过灰度验证网络连通性，避免策略全量下发导致的 RTO 超限。
1.3 蓝绿发布与发布包完整性的关系
蓝绿发布（Blue-Green Deployment）是云原生场景下实现零停机发布的标准模式。其核心思想是维护两套完全独立的生产环境（蓝环境与绿环境），通过流量切换完成版本升级。然而，如果发布包本身存在完整性缺陷（如文件损坏、依赖缺失、签名校验失败），蓝绿发布不仅无法降低 RTO，反而会因环境切换失败导致更长的恢复时间。
1.4 蓝绿发布中的 RTO 拆解
在蓝绿发布场景下，RTO 可以拆解为以下四个可度量子阶段，每个阶段都有对应的校验点和风险控制手段：
| 阶段 | 时间消耗 | 校验点 | 风险控制 |
|---|---|---|---|
| 发布包完整性校验 | 5~30 s | 签名、哈希、依赖树 | 自动阻断、告警通知 |
| 绿环境部署与就绪 | 30~120 s | Pod 状态、Service 端点、健康检查 | 滚动更新、优雅终止 |
| 网络策略与连通性验证 | 10~30 s | NetworkPolicy 生效、DNS 解析、东西向流量 | 灰度流量、自动回滚 |
| 流量切换与观察 | 5~15 s | Ingress/Service Mesh 路由、错误率、延迟 | 渐进式切换、熔断保护 |
常见误区： 很多团队只关注绿环境部署阶段的 RTO，忽略了发布包完整性校验和网络策略验证的时间。实际上，这两个前置阶段如果出现问题，会导致整个发布流程回滚，实际 RTO 可能膨胀 3~5 倍。建议将完整性校验纳入 CI/CD 流水线的前置步骤，而非等到发布时再执行。
1.5 课程核心目标
本课程将围绕以下三个核心目标展开：
- 建立 RTO 驱动的运维思维：将 RTO 拆解为可观测、可度量的子指标，贯穿容器网络运维全流程。
- 掌握蓝绿发布中的网络校验技术：包括 NetworkPolicy 验证、服务网格流量切换、DNS 解析一致性检查等。
- 实现发布包完整性的自动化校验：通过签名验证、依赖完整性检查、制品仓库一致性校验，确保发布包在蓝绿环境切换前是可信的。