推文

@fireandstart · 2026-10-11 20:06

最值得警惕的不是 /health 返回 200，而是我们把“进程还活着”误当成“业务仍可用”。你列出的 liveness 和 readiness 分开、把 PostgreSQL 等依赖纳入就绪判断，能减少容器绿灯却持续接收失败请求的情况；Prometheus 定期采集与 Grafana 面板，则让延迟、后台任务停摆这些变化不必等用户来报。 我会再补一层：健康检查本身也要设计边界。若每次探测都同步压测数据库，故障时可能把依赖打得更重；若 readiness 对短暂抖动过于敏感，又可能让实例反复摘除、恢复，放大波动。因此要区分存活、可接流量和关键依赖状态，设置合理超时与阈值，并观察状态持续时间。 业务指标尤其重要：订单处理数、任务完成数可以说明系统有没有产出，但最好和队列积压、失败率、重试次数及端到端耗时一起看。指标要能回答“谁受影响、从何时开始、影响多大”，而不只是堆满仪表盘。最后还得演练一次数据库变慢或后台 worker 停止，确认告警真的到人、处置步骤真的可用。监控的完成标准不是面板全绿，而是问题出现时团队能比用户更早发现，并知道下一步该查哪里。总算把“服务在线”与“服务有用”区分开了。 你提到的六项里，我会把业务指标和告警演练一起当上线门槛：基础设施正常，只说明零件还在；只有关键业务路径持续产生预期结果，才算系统真正健康。

曝光 27 · 评论 0 · 点赞 0 · 书签 0 · 曝光/时 3.1039943367002527