用途
本技能用于在生产系统中实现零停机部署模式，帮助降低部署风险、支持即时回滚、执行金丝雀发布，并在生产环境进行 A/B 测试。
主要能力
技能覆盖多种部署策略，并给出了对应的配置示例：
- 蓝绿部署（Blue-Green）：维护两个完整环境，通过切换流量实现即时回滚，但需要约 2 倍资源。文档提供了 Kubernetes 的 blue/green Deployment 与 Service 清单，以及通过修改 Service 选择器切换流量的脚本
blue-green-switch.sh，还给出 AWS CodeDeploy 的appspec.yml配置。 - 金丝雀部署（Canary）：按 10%–25% 逐步引入流量，支持较慢但安全的回滚。文档包含基于 Istio 的
VirtualService与DestinationRule流量切分配置，以及 Argo Rollouts 的分步权重与 Prometheus 分析模板。 - 滚动部署（Rolling）：Kubernetes 默认策略，逐 Pod 替换。文档提供
RollingUpdate配置（maxSurge、maxUnavailable）、常用的kubectl rollout命令（状态查看、暂停、恢复、回滚、历史查看），以及就绪/存活探针配置。 - 重建部署（Recreate）：一次性替换全部实例，速度快但风险高，资源占用与滚动部署相同。
使用方式
技能以 YAML 清单、Shell 脚本和编程示例的形式提供可直接参考的配置：
- Kubernetes 蓝绿部署：分别定义
myapp-blue与myapp-green两个 Deployment，并通过 Service 的selector.version在二者之间切换；切换脚本会先验证新部署的 rollout 状态，再执行健康检查，通过后使用kubectl patch切换流量。 - 金丝雀发布：Istio 配置中默认将 90% 流量路由到 stable、10% 路由到 canary，并支持通过请求头
x-canary: true命中金丝雀版本；Argo Rollouts 则按 10%、25%、50%、75% 分步加权并暂停 5 分钟，同时结合 Prometheus 指标进行成功率分析。 - 健康检查：提供 Flask 健康端点示例，
/health用于存活探针，/ready用于就绪探针，就绪检查会验证 PostgreSQL 与 Redis 连接，异常时返回 503。 - 回滚：提供自动化回滚脚本，通过 Prometheus 查询成功率，低于 0.95 阈值时执行
kubectl rollout undo；同时给出手动回滚检查清单，覆盖回滚前、回滚中和回滚后的操作。
适用场景
- 需要零停机发布的生产系统
- 希望降低部署风险、实现即时回滚的团队
- 需要金丝雀发布或生产 A/B 测试的场景
- 使用 Kubernetes、AWS ECS、Istio 或 Argo Rollouts 的部署流程
前置条件
使用该技能需要具备：负载均衡器或 Ingress 控制器、容器编排平台（如 Kubernetes）或云平台、CI/CD 流水线、健康检查端点。
限制与注意事项
文档列举了常见问题及处理建议：部署缓慢时可增大 maxSurge、减小 minReadySeconds；健康检查失败时需检查探针端点和超时时间；回滚期间出现流量错误时应使用连接排空并实现优雅关闭。最佳实践建议始终实现健康检查、使用连接排空、定期测试回滚流程、在部署期间监控关键指标、实现熔断、使用部署槽/环境、自动化部署验证并记录回滚流程。相关技能包括 kubernetes-ops、argocd-gitops 和 feature-flags。
需要说明的是，资料中未提供该技能的具体安装命令、收费方式或价格信息。