一次发布引发生产故障：变更止血、回滚决策与复盘模板 # 一次发布引发生产故障：变更止血、回滚决策与复盘模板 发布后错误率升高时，团队最容易陷入“继续观察还是回滚”的争论。生产处置的目标不是立即解释根因，而是用最短时间恢复服务并保留证据。 ## 一、识别变更相关性 把告警时间与应用发布、配置修改、数据库 DDL、网络策略、证书、依赖升级对应起来。检查错 DevOps 与自动化 2026-08-09 12 0
生产级容灾演练：RTO、RPO、故障注入、切换与回切完整流程 # 生产级容灾演练：RTO、RPO、故障注入、切换与回切完整流程 没有演练过的容灾方案，只能算文档。一次合格演练必须验证人员、流程、权限、数据、网络、应用和监控，而不只是证明备用机器可以启动。 ## 一、定义目标与边界 RTO 是允许恢复业务的最长时间，RPO 是允许丢失数据的最大时间窗口。应按业务 架构设计 2026-08-09 12 0
生产系统容量规划：从业务指标、压测模型到扩容阈值 # 生产系统容量规划：从业务指标、压测模型到扩容阈值 容量规划不是简单地看 CPU 是否超过 80%，而是把业务增长、流量形态、依赖瓶颈和扩容提前量转化为可执行的资源计划。 ## 一、明确业务容量指标 先收集日活、订单量、峰值 QPS、并发连接、请求/响应大小、读写比例、数据日增量、保留周期和增长率 架构设计 2026-08-09 14 0
Kubernetes Service 间歇性访问失败：CoreDNS、kube-proxy、CNI 与 MTU 排查 Service 偶发超时最难排查，因为 Pod 看起来正常，重试又可能成功。建议沿着“域名解析—Service 转发—Pod 网络—宿主机网络—应用监听”逐层缩小范围。 一、先固定故障边界 记录调用方 Pod、目标域名、Service、端口、协议、失败时间和比例。分别测试 Service 域名、Cl 容器与云原生 2026-08-09 21 0
MySQL 死锁与锁等待超时：现场取证、应急止血和根因修复 # MySQL 死锁与锁等待超时：现场取证、应急止血和根因修复 生产环境出现接口超时、事务回滚或 Deadlock found 时，不要第一时间重启数据库。重启会清空最重要的现场信息，也可能让问题很快复发。正确顺序是：确认影响、保留证据、找到阻塞链、谨慎止血、修复事务设计。 ## 一、先判断是死锁还 数据库与中间件 2026-08-09 8 0
systemd 服务反复重启：退出码、启动限速与依赖故障排查 服务不断“启动—退出—重启”，既可能造成业务抖动，也可能刷满日志、打爆下游或触发 systemd 启动限速。正确做法是先确认最后一次失败原因，再决定是否继续自动重启。 一、确认服务当前状态 systemctl status <service> --no-pager -l systemctl show 2026-08-09 14 0
nf_conntrack 表满导致丢包：连接跟踪容量、异常流量与治理 Linux 网关、NAT 节点、Kubernetes 节点或防火墙出现 nf_conntrack: table full, dropping packet 时，新连接可能被丢弃，表现为随机超时、DNS 异常、服务偶发不可达。增加表上限只是应急动作，还必须找到连接为什么增长。 一、确认内核是否报告表满 2026-08-09 31 0
Linux 服务器时间漂移：chrony、NTP、虚拟化时钟与安全恢复 服务器时间漂移会导致证书校验失败、日志顺序混乱、分布式锁异常、Kerberos 认证失败，甚至影响数据库复制和集群选举。处理时既要恢复准确时间，也要避免突然跳时给业务造成二次故障。 一、确认系统时间与时区 date -Ins timedatectl status hwclock --show 记录当 2026-08-09 10 0
Linux 僵尸进程不断增加：定位父进程、正确回收与代码修复 僵尸进程是已经退出、但父进程尚未读取其退出状态的子进程。它几乎不占 CPU 和业务内存，但会保留 PID 和少量进程表信息。数量持续增长时，最终可能耗尽 PID 或暴露父进程的回收逻辑缺陷。 一、确认僵尸进程数量 ps -eo stat | awk '$1 ~ /^Z/ {count++} END 2026-08-09 15 0
Linux 负载很高但 CPU 使用率不高：D 状态进程与 I/O 阻塞排查 生产服务器的 load average 持续升高，但 top 中 CPU 仍有大量 idle，这通常不是计算能力不足。Linux 负载包含可运行任务，也会受到不可中断睡眠任务影响；磁盘、NFS、云盘或内核 I/O 路径阻塞时，进程可能进入 D 状态并推高负载。 一、确认负载是否持续异常 date u 2026-08-09 19 0
