容器被OOM Killed——Exit Code 137的真相先说结论：容器退出码137 = 128 + 9，就是被SIGKILL了，99%是OOM Killed。怎么确认是OOM？第一步，看容器状态：docker inspect <container_id> --format=&...
排障别慌，先建立一个排查框架很多人遇到线上故障第一反应就是top一把看看，发现load高就开始查CPU，结果查了半天发现CPU其实没啥问题，真正的瓶颈在IO。我现在养成的习惯是按一个固定的顺序走：整体负载 → 瓶颈类型（CPU/内存/磁盘/网络）→ 定位进程 → 分析根因 → 解决问题从宏观到...
上周五晚上11点，刚上线的支付接口把10%的用户请求打到了一个有Bug的新版本上，告警群炸了。回滚倒是快，但老板第二天问了一句："咱们灰度方案到底靠不靠谱？"说实话，这事让我重新审视了一遍手头的灰度发布体系。趁周末把 Nginx Ingress Canary、Istio 流量管理、Argo R...
手头3台CentOS虚机，本来准备跑Kafka测试集群的，结果领导临时说要验证一下容器化部署方案。正经用kubeadm搭K8s？光etcd和各种证书问题就够折腾半天的。果断上K3s——一个二进制文件解决战斗。但真跑起来才发现，"轻量"不等于"没坑"。从节点加入报x509证书错误、重启服务直接卡...
半年前机房里一周炸了5块盘，RAID重建还没跑完第二块又掉了，那个晚上我盯着iDRAC面板手都在抖。事后复盘发现这5块盘的SMART数据在故障前2-4周就已经有明显异常了——只是没人看。从那之后我搞了一套磁盘预测感知的东西，用smartmontools采集SMART数据，跑一个轻量的XGBoo...
热爱技术的云计算运维工程师，Python全栈工程师，分享开发经验与生活感悟。
欢迎关注我的微信公众号@运维躬行录，领取海量学习资料
