如何识别和消除系统单点？
简化版
识别单点要沿端到端链路检查计算、存储、网络、控制面、第三方和人员流程：任何一个失败就让核心业务不可用且没有可验证替代路径的组件，都是单点。 消除方式不是机械加副本，而是增加独立故障域、自动/可控切换、状态复制和降级路径，并通过故障注入证明替代路径可用。
详细版
从核心用户旅程画依赖图，用 FMEA 记录每个节点的失效模式、影响、检测和恢复。特别检查“伪冗余”：双实例同机架、主备共用电源、两个应用共用单库、HAProxy 双机却只有一个 VIP 控制器、多人值班但只有一人有权限。
对无状态服务做多实例与多 AZ；有状态系统要复制、仲裁、fencing 和恢复；外部依赖准备多供应商或业务降级；控制面故障时数据面使用版本化快照。每个单点都有 owner、目标 RTO 和演练证据，无法立即消除的则限流、备份并接受显式风险。
完整版教学
一、单点由业务结果定义
一台机器只有一个进程未必是关键单点，如果失败只影响离线任务并可次日重跑；看似三副本数据库若都在同一 AZ，则对 AZ 故障仍是单点。判断标准是某故障是否让目标业务失去可接受服务，而不是组件数量。
记忆钩子：不要数副本，去问“共同原因能不能一次把它们全带走”。
二、沿用户旅程画依赖图
DNS -> CDN/WAF -> LB -> API -> Auth -> Order -> DB
\-> MQ -> Inventory对每一条边问：目标失败后是否有替代？调用方会超时、重试还是降级？依赖图还要包含证书、密钥、配置、监控和发布系统，这些平时不在请求热路径，却可能阻止恢复。
三、用 FMEA 排优先级
| 失效项 | 影响 | 可检测性 | 恢复 | 优先级 |
|---|---|---|---|---|
| 单 AZ 数据库 | 全站写停 | 高 | 2h | 极高 |
| 推荐服务 | 首页降级 | 高 | 5min | 中 |
| 单个报表 Worker | 报表延迟 | 高 | 自动重试 | 低 |
可用严重度、发生概率和可检测性评分，但分数只是排序辅助，合规与资金风险可直接提高等级。
四、伪冗余为何最危险
两台服务器共享一个交换机、电源或存储阵列，只能防主机故障；主备数据异步但从未恢复演练，备用可能无法启动；多 DNS provider 但域名注册商账号是单一凭证，控制权仍是单点。要标注主机、机架、AZ、地域和组织权限等故障域。
三副本跨三个主机但同一错误配置全量发布，也会同时失效，所以变更系统和配置同样需要灰度与回滚。
五、不同层的消除方法
无状态计算用多实例、多 AZ、健康摘流和冗余容量；状态存储用复制、共识/选主、备份和 fencing；网络用多链路、多 LB 与可控 DNS；第三方依赖用降级、异步或第二供应商；人员单点用双人权限、Runbook 和轮值训练。
增加副本会增加一致性和切换复杂度。若一个功能允许明确失败后重试，可靠降级可能比构建昂贵双活更合理。
六、验证替代路径而非配置数量
假设有 4 个实例，逐一 kill 只能验证实例级冗余；还要断开一个 AZ、让注册中心不可用、撤销某密钥和恢复备份。演练中测用户成功率、切换时间、数据缺口与剩余容量。若切换依赖人工且目标 RTO 5 分钟，就要实际测人工链路能否达到。
维护单点清单：风险、owner、目标日期、临时缓解、最近演练和残余风险。架构变化后自动/人工复查，避免已消除单点重新出现。
七、常见误区与追问
- 误区：部署两个实例就没有单点。 它们可能共享故障域、依赖和配置。
- 误区：有主备就一定能自动切换。 还要验证数据、fencing、容量和流量收敛。
- 误区：只检查请求热路径。 证书、密钥、控制面和人员会影响恢复。
- 误区：所有单点都必须用双活消除。 可根据业务影响选择降级、备份或显式接受。
- 追问：如何发现人员单点？ 让非 owner 按 Runbook 执行演练，检查权限与知识缺口。
- 追问：第三方单点怎么处理？ 评估替代供应商、缓存、异步和明确降级语义。
- 追问：如何验证没有共同故障域？ 标注物理、网络、地域、账号与变更域并做对应注入。
八、加强记忆
识别单点按“用户旅程—依赖图—共同故障域—FMEA—实战演练”推进。消除方案覆盖冗余、隔离、切换和降级，不能停在多放几台机器。只有替代路径在目标 RTO/RPO 下真实走通，单点才算被消除。
单点清单应带 owner、验证日期和失效后果，随着架构变更持续更新；一次性盘点很快会因新依赖而失真。
判断优先级时可用“发生概率 × 业务损失 × 恢复难度”，先治理影响核心链路且没有手工替代路径的节点。