## 案例
某电商应用部署在顺云云服务器上，某天下午起用户下单持续超时，页面转圈。运维第一反应查应用所在实例：控制台显示运行中，CPU、内存、带宽全部正常，SSH 登录流畅，Web 进程健康检查通过。实例本身无懈可击，但业务就是不通。团队排查了近一小时，从应用到网络逐层翻检，最后发现故障根本不在这台机器上——它依赖的数据库实例磁盘写满，所有写入挂起，应用每个请求都堵在等数据库上。
## 根因分析
现代 Web 业务是一张依赖网：应用实例只是前台，数据库、缓存、对象存储、第三方支付接口，每一项都是请求链路上的必经节点。控制台的实例状态只覆盖实例自身，依赖项的故障不会体现在实例的任何指标上——它显示运行中是真的，业务超时也是真的，两者并不矛盾。这类故障的迷惑性在于：排障的注意力天然被引向"超时的那一台"，而真凶藏在依赖网深处。超时类故障的定位口诀：实例健康不代表链路健康，从实例出发顺着依赖往外测。
## 修复过程
复盘当时的定位路径，正确的做法应该是三步。第一步从实例内部逐项测依赖：
bash nc -zv 数据库内网IP 3306 redis-cli -h 缓存内网IP ping
数据库端口通但写入挂起，测试连接后跑一条写入语句立即暴露。第二步确认数据库侧指标：磁盘水位 100%，写入全部失败，元凶锁定。第三步清理磁盘恢复写入，业务自动恢复，前后十分钟。当时实际花了一小时，差的就是"主动测依赖"这一步意识。
## 复盘要点
依赖清单化：每个业务画出依赖图，数据库、缓存、存储、外部接口，标注各自的监控方式与责任人。监控覆盖依赖本身：数据库磁盘、缓存内存、对象存储配额，这些指标直接告警，而不是等业务超时倒查。链路探测常态化：探活脚本从实例内部定期测各依赖的连通与响应，异常先于用户暴露。故障演练时把"依赖故障"纳入场景，团队形成肌肉记忆——实例无辜，先查它背后的人。