题目重点：通过DNS、网络、监听、代理、应用和依赖逐层缩小故障，再设计恢复与韧性。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练一个Web host突然不可用，只有告警没有给定根因；需根据下一条证据选择下一步，不用固定背诵所有命令。
- 恢复优先级与允许动作由事故授权定；先读状态/请求，避免未经诊断无差别重启。
解题路线
- 确认影响范围/起始时间，外部与本地请求对比：DNS解析、路由/TLS、端口连接、HTTP状态、响应时间各代表不同层。ping成功不能证明HTTP健康，超时也不能独自证明host宕机。
- 主机可达后查listener/process、CPU/load/memory/OOM、磁盘/inode与socket/fd、反代/upstream状态，按请求链与时序关联部署/配置变化。没有日志不等于没请求，可能日志写失败或路径错。
- 应用健康接口与真实业务请求分别测；数据库/外部依赖超时需分清等待和自身处理瓶颈。请求积压可能由一个慢依赖引发线程耗尽，扩大线程数不是自动修复。
- 证据支持后选择最小恢复：回滚已知坏变更、恢复资源、隔离坏依赖或故障切换；记录action与观察，验证真实流量恢复，再做复盘。
- 韧性先消除单host：至少多实例/故障域与健康LB，但数据库、存储、队列也可能单点。持久数据复制/备份、可回滚发布、timeout/backpressure和可观测性需要端到端设计。
手动走一遍
本地app端口200、外部入口502，先查Apache/upstream映射或TLS链，而不是重启数据库。若app请求全阻塞且依赖延迟高，先确认连接池/timeout与降级策略；单机加副本仍共享坏依赖会一起失败。
规模与取舍
诊断以证据驱动分支缩小搜索，恢复目标用RTO/RPO、错误率和延迟定义。多副本仅提升计算故障容忍，数据丢失/故障域和容量余量另算。
易错点与追问
容易失分的边界
- 从告警直接猜CPU或重启，丢现场而未修原因。
- 只有浅health check，进程活但业务不可用仍被LB送流量。
继续深挖
- LB健康检查怎样避免短抖动频繁摘挂，同时及时隔离真失败？
- 新增副本后如何验证状态、session和本地文件不成为新隐含依赖？
