Linux SRE运维手册生产排障实战：从事故到自动化响应

概述

在生产环境中，故障不可避免。SRE运维手册（Runbook）是保障服务可靠性的关键工具。本文以Kubernetes集群中的Pod频繁重启为例，展示从发现症状到自动化响应的完整排障流程。

场景

某微服务应用在Kubernetes集群中运行，Pod状态显示CrashLoopBackOff。

症状

• Pod状态：CrashLoopBackOff
• 日志：OutOfMemoryError 或进程被OOM Killer终止
• 监控告警：内存使用率持续超过阈值

诊断步骤

1. 查看Pod状态 bash kubectl get pods -n <namespace> | grep -v Running
2. 检查Pod日志 bash kubectl logs <pod-name> -n <namespace> --previous
3. 描述Pod事件 bash kubectl describe pod <pod-name> -n <namespace>
4. 检查节点资源 bash kubectl top nodes kubectl top pods -n <namespace>
5. 分析内存使用 bash # 登录到容器（如果还在运行） kubectl exec -it <pod-name> -n <namespace> -- bash # 查看进程内存 ps aux --sort=-%mem | head -n 10

风险控制

• 在非高峰期操作，避免影响用户。
• 先行资源配额调整：kubectl edit deployment <deployment>，增加内存限制。
• 禁止直接删除有状态Pod，应先评估。
• 使用kubectl cordon <node>隔离故障节点。

回滚方案

1. 确认问题为最近一次变更所致。
2. 回滚部署： bash kubectl rollout undo deployment/<deployment> -n <namespace>
3. 若回滚失败，使用历史版本： bash kubectl rollout history deployment/<deployment> -n <namespace> kubectl rollout undo deployment/<deployment> --to-revision=<revision>

验证措施

• 检查Pod状态变为Running且稳定。
• 监控内存使用曲线是否恢复正常。
• 执行正常流量测试。

何时提交OpsGlobal工单

• 多次回滚后问题依旧。
• 涉及底层系统配置（如内核参数、文件系统）。
• 需要性能调优或架构审查。
• 非工作时间需要快速响应。

通过结构化运维手册，SRE团队可以提升故障响应效率，减少MTTR。对于复杂问题，及时寻求专家支持是关键。