已有措施三层次，及规避与解决措施的优先级选择

FMEA表里的”已有措施”记录系统当前针对某个具体故障原因已经具备的应对手段，分三个层次由弱到强：检测告警是最基础的，系统只负责发现故障并告警，自己不处理，需要人工介入；容错是系统检测到故障后能通过备份手段自动应对，比如MySQL主备架构里，业务服务器一旦发现主机连不上，就自动切换去连备机读取数据；自恢复是系统检测到故障后能自己恢复，比如Hadoop发现某台机器故障后，会自动把原本存在这台机器上的副本重新分配到其他机器上——需要注意这里的”恢复”指的是业务层面的恢复，而不是真的把物理故障修好（Hadoop不可能把一块产生了坏道的磁盘真正修复成没有坏道）。除了已有措施，FMEA还区分”规避措施”（为了降低故障发生概率而做的事，可以是技术手段也可以是管理手段，比如为避免新引入的MongoDB丢数据而在MySQL里冗余一份，或者强制统一更换服役超过两年的磁盘）和”解决措施”（为了真正解决问题而做的事，通常是技术手段，比如为了防暴力破解密码而限制重试次数、为防拖库泄露而给敏感数据加密、为防非法访问而加白名单控制）。如果某个故障既能规避又能解决，应优先选解决措施——毕竟能真正解决问题总是更好；但很多时候有些故障系统自己根本没法解决（比如磁盘坏道、开源系统本身的bug），这类只能靠规避措施降低发生概率或减小影响，而系统能自己解决的故障，大多都和系统本身的功能设计直接相关。综合前面所有字段的分析结果，就能看出哪些故障目前完全没有对应措施、哪些已有措施还不够充分，结合风险程度排出优先级，给出”后续规划”——既可以是技术手段也可以是管理手段，既可以是规避也可以是解决，核心原则是优先投入资源解决风险程度最高的隐患（例如”地震导致机房业务中断”这种没法真正解决的故障，只能靠建备份中心来规避；”机柜断电导致业务中断”则可以通过把业务机器分散部署到不同机柜来规避；”敏感数据泄露”可以直接靠数据库加密这个技术手段解决）。以书中一个用户管理系统（MySQL存储+Memcache缓存+Server业务处理）的FMEA实战为例，分析下来汇总出的改进措施包括：给MySQL加备机、把Memcache从单机扩展为集群、给MySQL配置双网卡连接——这几条改进正是FMEA分析表”后续规划”列汇总后的直接产出。

结构图：

flowchart TB
  A["已有措施三层次(由弱到强)"]
  A --> B["检测告警<br/>只发现+告警，需人工介入"]
  A --> C["容错<br/>检测到故障后自动切备份<br/>如MySQL主备自动切换"]
  A --> D["自恢复<br/>检测到故障后自动恢复业务层面<br/>如Hadoop自动重新分配副本"]
  E["规避措施 vs 解决措施"]
  E --> F["规避：降低发生概率<br/>如数据冗余/强制更换老旧磁盘"]
  E --> G["解决：真正解决问题<br/>如加索引/加密/限制重试次数"]
  F --> H["两者都可选时优先选解决措施<br/>但系统自身无法解决的(磁盘坏道/开源bug)只能规避"]
  G --> H
  H --> I["后续规划：结合风险程度排优先级<br/>汇总产出改进清单<br/>(实战案例：MySQL加备机+MC集群化+MySQL双网卡)"]