容器跑起来以后，谁来兜住故障？K8s、Swarm、Mesos、Nomad怎么选
发布完成，容器全部显示“运行中”，业务监控却开始报错。 旧实例正在退出，新实例还没准备好，流量已经打了进去。 另一种情况更直接：承载服务的主机故障了。 镜像还在、配置也在，但服务能否自动恢复，取决于是否有人替你调度新的实例， 以及剩余节点有没有容量。 这时再去比较“哪个工具功能更多”，很难解决眼前的问题。 真正需要回答的是：谁判断实例可用，谁接住流量，发布失败以后怎样退回？ 我看容器编排，通常...
评论
点赞
收藏Linux 负载飙到 100，CPU 却很空闲：别急着扩容，先找出 D 状态进程
凌晨的告警突然响起：一台 16 核 Linux 节点的 Load Average 已经超过 100，接口延迟持续上升，部分请求开始超时。 值班同事登录服务器后却发现，CPU Idle 仍有 80% 左右。既没有进程持续占满 CPU，内存也没有明显耗尽。扩容一台机器后，故障依旧没有消失。 更反常的是，几个业务进程执行 kill -9 后迟不退出。重启服务同样卡住，Load Average 还在继...
别再一把梭哈！Istio 灰度发布实战：从 1% 流量到秒级回滚，附完整 YAML
凌晨一点多，新版订单服务刚上线，监控群就开始刷屏：接口超时、下单失败率上涨、客服反馈用户无法提交订单。 更麻烦的是，新旧版本混在同一个 Deployment 里滚动更新。我想把流量切回旧版本，却发现旧 Pod 已经被逐渐替换，回滚镜像、拉起容器、等待探针，前后折腾了十几分钟。 后来我把发布方式改成了 Istio 灰度，新旧版本独立部署，流量从内部测试、1%、5%、10%慢慢放开。真遇到问题时，只改...
10个运维9个踩过的坑：Deployment 和 StatefulSet 到底有什么区别？
凌晨 2 点告警炸锅，线上数据库 Pod 挂了挂挂停停，手忙脚乱地把它挂在 Deployment 下面，以为配置完了就万事大吉。 结果 Pod 重启后不仅数据找不到，集群网络还直接死锁，业务大面积报错。 今天我把 Deployment 与 StatefulSet 的底层区别、生产选型和踩坑避坑讲透，看完你也能彻底告别这个“低级”故障。 说实话，很多人做了两三年运维，每天就是 kubectl app...
线上 499 突然飙升：别只怪客户端，真正的超时可能藏在上游
上午 10 点 18 分，入口 Nginx 的 499 占比从不足 0.1% 升到了 8.6%。 应用 CPU 只有 42%，内存没有明显上涨，6 个 Pod 也全部处于 Running 状态。有人看到 499 后马上判断：“这是客户端主动断开，和服务端没关系。 ” 但客服反馈，用户打开订单查询页面时频繁看到“请求超时”。 与此同时，接口 P99 耗时已经从 800 毫秒上涨到 6 秒以上。 用户...
别再让 Codex 一个人包打天下：多 Agent 协同实战
一个横跨前端、后端和数据库的需求突然插进来：新增接口、调整页面、补单元测试，还要检查权限风险。 如果把整件事一次性交给 Codex，它需要先读项目结构，再定位业务逻辑，然后修改代码、补测试、运行构建，最后还要审查自己的改动。 任务不是不能完成，问题是所有探索记录、错误日志、测试输出和修改细节都挤在同一个上下文里。对话越来越长，真正重要的需求约束反而被埋了。 这和现实中的团队一样。一个人既负责需求分...
系统可用性从 99.5% 到 99.99%：数据从哪里来，四个 9 到底怎么算
月度复盘会上，监控大盘显示系统可用性已经达到 99.99%。 业务负责人却问了三个问题：“这个数字怎么算出来的？数据从哪里来？用户真的只受影响了 4 分钟吗？” 会议室一下安静了。 有人用 Pod 存活率计算，有人统计工单里的故障时长，还有人直接拿网关 5xx 比例当可用性。同一个系统，三种算法分别得到 99.96%、99.99% 和 100%。数字都很漂亮，却没有一个经得住追问。 系统从 99....
微服务通信别只看性能：REST 与 gRPC 的 6 个选型判断和一次 502 故障复盘
不少选型表会把 REST 写成 HTTP/1.1、JSON、不支持流式传输，再把 gRPC 写成 HTTP/2、Protobuf、天然高性能。这个对比方便记忆，但不够严谨。 REST 是一种架构风格，通常使用 HTTP 和 JSON，但并不限定只能使用 HTTP/1.1，也不强制 JSON。REST API 可以运行在 HTTP/2 上，也可以通过分块响应、SSE 等方式传输流式数据。 gRPC ...
别把 Galera 当普通主从！3 节点 MySQL 多主集群部署与故障恢复实战
凌晨两点，数据库主节点突然掉线，应用连接池开始疯狂报错，监控群里一排红色告警。 如果用的是传统 MySQL 主从架构，这时候通常要判断从库延迟、确认数据位点、提升从库、修改连接地址。动作看起来不多，真到了生产现场，手一抖就可能把“数据库故障”升级成“数据故障”。 我碰到过类似情况，主库已经不可用，从库还差几十秒日志没追完，业务又催着恢复。切还是不切，很难受。 后来有些业务开始使用 Galera C...