当前我们逐步地移除对于非硬件问题的处理，回归面向硬件自愈的场景（面向软件的通用自愈也有系统在承载，这类场景与业务的耦合性较大，无法面向集团通用化），这样也更利于软硬件问题分类和未知问题发现。
4.架构演进4.1.云化
最初版本的自愈架构是在每个集群的控制机上实现，因为一开始时候运维同学也是在控制机上处理各种问题。但随着自动化地不断深入，发现这样的架构严重阻碍了数据的开放。于是我们采用中心化架构进行了一次重构，但中心化架构又会遇到海量数据的处理问题，单纯几个服务端根本处理不过来。
因此我们对系统进一步进行分布式服务化的重构，以支撑海量业务场景，将架构中的各个模块进行拆解，引入了 阿里云日志服务(sls)/阿里云流计算(blink)/阿里云分析数据库(ads) 三大神器，将各个采集分析任务由云产品分担，服务端只留最核心的硬件故障分析和决策功能。
下面是DAM1与DAM3的架构对比
4.2.数据化
随着自愈体系的不断深入，各阶段的数据也有了稳定的产出，针对这些数据的更高维分析，能让我们发现更多有价值且明确的信息。同时，我们也将高维的分析结果进行降维，采用健康分给每台机器打标。通过健康分，运维的同学可以快速知晓单台机器、某个机柜、某个集群的硬件情况。
4.3.服务化
基于对全链路数据的掌控，我们将整个故障自愈体系，作为一个硬件全生命周期标准化服务，提供给不同的产品线。基于对决策的充分抽象，自愈体系提供各类感知阈值，支持不同产品线的定制，形成适合个性化的全生命周期服务。
5.故障自愈闭环体系在AIOps的感知、决策、执行闭环体系中，软件/硬件的故障自愈是最常见的应用场景，行业中大家也都选择故障自愈作为首个AIOps落地点。在我们看来，提供一套通用的故障自愈闭环体系是实现AIOps、乃至NoOps（无人值守运维）的基石，应对海量系统运维，智能自愈闭环体系尤为重要。
5.1.必要性
在一个复杂的分布式系统中，各种架构间不可避免地会出现运行上的冲突，而这些冲突的本质就在于信息不对称。而信息不对称的原因是，每种分布式软件架构在设计都是内敛闭环的。现在，通过各种机制各种运维工具，可以抹平这些冲突，然而这种方式就像是在打补丁，伴随着架构的不断升级，补丁似乎一直都打不完，而且越打越多。因此，我们有必要将这个行为抽象成自愈这样一个行为，在架构层面显式地声明这个行为，让各软件参与到自愈的整个流程中，将原本的冲突通过这种方式转化为协同。
当前我们围绕运维场景中最大的冲突点：硬件与软件冲突，进行架构和产品设计，通过自愈的方式提升复杂的分布式系统的整体鲁棒性。
5.2.普适性
透过大量机器的硬件自愈轮转，我们发现：
- 被纳入自愈体系的运维工具的副作用逐渐降低（由于大量地使用运维工具，运维工具中的操作逐渐趋于精细化）。
- 被纳入自愈体系的人工运维行为也逐渐变成了自动化。
- 每种运维动作都有了稳定的SLA承诺时间，不再是随时可能运行报错的运维脚本。
因此，自愈实际上是在复杂的分布式系统上，将运维自动化进行充分抽象后，再构筑一层闭环的架构，使得架构生态形成更大的协调统一。
