1.2.3　运维模式的升级

配置变更是运维场景下的高频操作。针对配置变更，云原生的理念是提倡采用不可变的基础设施，即任何变化都是基于容器重新生成一个镜像来进行部署，而不是在原有环境下直接变更配置，也就是说，基础设施是只读的。这样做的好处是任何变更都是可版本化的，因此也就更容易维持变更的质量，从而避免各种未记录的变更给系统带来不可知的影响。当然，对于大型系统而言，变更的相互影响也是非常大的，因此建议一个环境不要只用一个大的镜像，而是将大环境分成若干个小环境，从而避免出现每个小环境发生变化时需要将整个大环境全部重新做镜像和部署升级的问题。

此外，传统的运维更多是面向操作的运维，而云原生的运维则是面向观测数据的自动化运维，两者在运维效率和效果上存在非常大的差别，具体说明如下。

面向操作的运维本质上是基于规则的运维，也就是运维人员根据事先准备好的规则，在规则前置条件都满足的情况下采取相应的运维操作。比如，当软件宕机时采取故障迁移操作，按照约定的时间采取备份操作，根据新版本的发布进行升级操作等，这些规则都是基于手册进行枚举的，而大部分运维操作是需要人工完成的。无论是枚举还是人工操作，都存在遗漏和操作错误的风险，而风险和故障带来的经验教训继续被规则化，这些都导致了运维无法形成完整的闭环，难以被持续优化。

举例来说，我们可以编写自动化脚本完成Redis的升级。在升级脚本的过程中，容易遗漏的一点就是升级后对各种可能导致Redis工作异常的情况进行完整检测，如通过redis-cli命令进行延迟测试，禁止THP（Transparent Huge Page，透明大页）甚至完整的内存测试。这些检测中的绝大部分应用在升级或启动Redis时都不会做，毕竟这些故障的发生概率很低且验证成本很高，一般是当业务系统因此产生了对应的故障时才会进行补救。

云原生运维可以基于标准化基础设施的运维，通过完整的可观测性实现系统中各类异常的实时可见，也可以结合声明式API实现自动化运维。这里仍以Redis升级为例：由于基于Kubernetes部署的Redis所依赖的操作系统及第三方库版本、核心参数配置全都打包到了容器中，因此不会出现所安装的环境产生THP的问题；安装后的checklist可以被沉淀到负责安装部署的Operator中，在readiness-probe中可以用redis-cli增加延迟测试；Prometheus可用于观察完整的Redis工作状态；Open Tracing可用于跟踪应用对Redis的每次调用是否存在异常；等等。所有这些数据全部整合在一起后作为metrics（度量）信息导出，由Operator通过API自动、实时获取，并将异常的Redis服务器下线、替换或者升级。