2.2.5　所有过程自动化原则

技术是把“双刃剑”，容器、微服务、DevOps以及大量第三方组件的使用，在降低分布式复杂性和提升迭代速度的同时，也提高了软件技术栈的复杂度，加大了组件规模，从而不可避免地导致了软件交付的复杂性。如果控制不当，应用就会无法体会到云原生技术的优势。通过IaC、GitOps、OAM、Operator和大量自动化交付工具在CI/CD（持续集成/持续交付）流水线中的实践，企业可以标准化企业内部的软件交付过程，也可以在标准化的基础上实现自动化，即通过配置数据自描述和面向终态的交付过程，实现整个软件交付和运维的自动化。

要想实现大规模的自动化，需要遵循如下四个基本原则。

1.标准化

实施自动化，首先要通过容器化、IaC、OAM等手段，标准化业务运行的基础设施，并进一步标准化对应用的定义乃至交付的流程。只有实现了标准化，才能解除业务对特定的人员和平台的依赖，实现业务统一和大规模的自动化操作。

2.面向终态

面向终态是指声明式地描述基础设施和应用的期望配置，持续关注应用的实际运行状态，使系统自身反复地变更和调整直至趋近终态的一种思想。面向终态的原则强调应该避免直接通过工单系统、工作流系统组装一系列过程式的命令来变更应用，而是通过设置终态，让系统自己决策如何执行变更。

3.关注点分离

自动化最终所能达到的效果不只取决于工具和系统的能力，更取决于为系统设置目标的人，因此要确保找到正确的目标设置人。在描述系统终态时，要将应用研发、应用运维、基础设施运维这几种主要角色所关注的配置分离开来，各个角色只需要设置自己所关注和擅长的系统配置，以便确保设定的系统终态是合理的。

4.面向失败设计

要想实现全部过程自动化，一定要保证自动化的过程是可控的，对系统的影响是可预期的。我们不能期望自动化系统不犯错误，但可以保证即使是在出现异常的情况下，错误的影响范围也是可控的、可接受的。因此，自动化系统在执行变更时，同样需要遵循人工变更的最佳实践，保证变更是可灰度执行的、执行结果是可观测的、变更是可快速回滚的、变更影响是可追溯的。

业务实例的故障自愈是一个典型的过程自动化场景。业务迁移到云上后，云平台虽然通过各种技术手段大幅降低了服务器出故障的概率，但是却并不能消除业务本身的软件故障。软件故障既包括应用软件自身的缺陷导致的崩溃、资源不足导致的内存溢出（OOM）和负载过高导致的夯死等异常问题，也包括内核、守护进程（daemon进程）等系统软件的问题，更包括混部的其他应用或作业的干扰问题。随着业务规模的增加，软件出现故障的风险正变得越来越高。传统的运维故障处理方式需要运维人员的介入，执行诸如重启或者腾挪之类的修复操作，但在大规模场景下，运维人员往往疲于应对各种故障，甚至需要连夜加班进行操作，服务质量很难保证，不管是客户，还是开发、运维人员，都无法满意。

为了使故障能够实现自动化修复，云原生应用要求开发人员通过标准的声明式配置，描述应用健康的探测方法和应用的启动方法、应用启动后需要挂载和注册的服务发现以及配置管理数据库（Configuration Management Database，CMDB）信息。通过这些标准的配置，云平台可以反复探测应用，并在故障发生时执行自动化修复操作。另外，为了防止故障探测本身可能存在的误报问题，应用的运维人员还可以根据自身容量设置服务不可用实例的比例，让云平台能够在进行自动化故障恢复的同时保证业务可用性。实例故障自愈的实现，不仅把开发人员和运维人员从烦琐的运维操作中解放了出来，而且可以及时处理各种故障，保证业务的连续性和服务的高可用性。