DevOps发布工程与CI/CD护栏：实战指南

场景

某电商平台在高峰期推送了一个微服务更新。新版本引入了错误的健康检查端点，导致Kubernetes认为Pod健康，但实际服务无法处理请求。CI/CD流水线没有检测到这一变化，因为单元测试和集成测试均未覆盖健康检查逻辑。部署后，流量路由到不健康的Pod，引发大量5xx错误和用户投诉。

症状

• 监控告警：HTTP 502/503错误率飙升
• 用户反馈：页面加载失败，部分功能不可用
• 集群状态：Pod运行中但 readiness 探测失败（如果配置了），但liveness探测通过
• 日志：应用容器抛出连接超时或请求转发错误

诊断

1. 检查Kubernetes事件：kubectl describe pod <pod-name> 查看事件，确认是否有失败探针或重启。
2. 查看Pod日志：kubectl logs <pod-name> --previous 寻找应用级错误。
3. 验证服务端点：kubectl get endpoints <service-name> 确认Pod是否在端点列表中。
4. 测试健康检查：手动执行健康检查命令，例如 curl http://localhost:8080/healthz（从Pod内）。
5. 检查CI/CD流水线：审查最近的构建日志，确认测试阶段是否跳过或失败。

命令

# 获取Pod状态
kubectl get pods -n production -l app=myservice

# 查看Pod事件
kubectl describe pod myservice-xxx -n production

# 查看日志
kubectl logs -l app=myservice --tail=100 -n production

# 验证服务端点
kubectl get endpoints myservice -n production

# 测试健康检查（进入Pod）
kubectl exec -it myservice-xxx -n production -- curl http://localhost:8080/healthz

# 检查CI/CD流水线（示例用Jenkins）
curl -u user:token https://jenkins.example.com/job/myservice-release/lastBuild/consoleText

风险控制

• 立即回滚：使用快速回滚机制（见下一节）。
• 限制流量：通过Kubernetes NetworkPolicy或Ingress规则临时阻断异常版本。
• 暂停发布：停止后续部署直到根本原因确定。
• 启用断路器：若使用服务网格，配置熔断策略。
• 通知团队：通过PagerDuty/Slack发送事件告警。

回滚

# 方法1：使用kubectl rollout undo
kubectl rollout undo deployment/myservice -n production

# 方法2：还原到已知稳定版本
kubectl set image deployment/myservice myservice=myregistry.azurecr.io/myservice:v1.2.3-stable -n production

# 方法3：使用Helm回滚
helm rollback myservice 1 -n production

执行后，监控错误率是否下降。

验证

• 监测指标：确认错误率归零，P95延迟恢复正常。
• 检查Pod状态：所有Pod处于Ready状态。
• 功能测试：执行冒烟测试，确保关键用户流程正常。
• 回归测试：运行自动化集成测试套件。
• 审查流水线：在CI/CD中添加健康检查验证步骤。

何时提交OpsGlobal工单

• 如果回滚后问题仍然存在，可能涉及底层基础设施。
• 需要审计CI/CD权限或配置变更。
• 需要专业SRE协助设计更健壮的护栏（如金丝雀发布、蓝绿部署）。
• 需要分析故障根源并形成事后报告。

提交工单时请提供：时间戳、受影响的服务、错误日志片段、已尝试的排查步骤。