解读运维的2020：从救火背锅到生产力担当，云原生时代的运维新归宿

本文是 InfoQ“解读 2020”年终技术盘点系列文章之一。

2020 年是云原生技术快速发展的一年，随着容器技术的普及，过去几年 Kubernetes 已经成为云原生基础设施的事实标准，今年在全球不同地区开展的线上 Kubecon 大会依旧火爆，疫情也阻挡不了大家对技术的追求，CNCF 社区同样发展迅速，2020 年有五个项目从社区毕业，这标志着云原生技术栈越来越成熟，同时截止目前共有 74 个项目加入社区，2020 年是围绕 Kubernetes 的云原生生态体系建设快速发展的一年。云原生技术的长足发展给企业数字化转型带来了便捷，企业转型的背后是基础架构人员面临的对自身的升级和转型。

传统运维的困局

在我的印象中，每个传统运维人员都是全能的，要熟悉各种各样的系统，要熟悉基础网络、操作系统、各种中间件、各种工具，并且熟练掌握能高效解决问题的脚本编写能力，24 小时待命，随时准备去解决生产中的各种问题，俨然是业务系统的救火员。我们有思考过是什么造成了这种局面？

过去我们运维人员的职责很多，是基础设施的管理者，承担了业务应用从上线到稳定运行的所有职责。所以我们面对了太多的因素，而要将这些因素沉淀下来又太不容易，过去要从无到有的去建立一套运维体系是非常困难的，同样既有的体系传承也很困难，一个新人要想完全熟悉一套运维体系要学的东西非常多，更别指望能将运维体系延伸到整个软件生产周期，将领域知识方便的传输出去，所以才造成了上下游不通，只有一两个核心人员熟练掌握运维系统。职责繁重，运维平台标准化困难，运维体系建设困难，无法有效打通上下游，这些都是传统运维的困局，也使运维人员成了产品质量的背锅者。

那么云原生时代的基础设施会有什么变化？运维有什么特征，能解决什么样的问题？我们运维人员应该重点关注什么？

云原生时代的运维特征

从 2013 年 docker 开源，到 2014 年发布正式版本（1.0），容器技术因为其轻量方式实现了系统级别的隔离特性受到追捧，并且发展迅速。再后来 Google 开源了 Kubernetes 并且和 Linux 基金会合作成立了 CNCF，随着开源社区的不断发展，以 Kubernetes 为核心建立的云原生生态逐步完善。云原生时代的基础设施是以容器技术为基础，以 Kubernetes 为平台的架构。那么云原生平台上的运维有什么特征呢？

基础设施即代码

容器的出现实现了一次构建处处运行的设想，而 Kubernetes 则定义了一个基础设施平台，并且实现了通过配置文件定义资源，让通过编写配置文件实现资源编排成为现实。Kubernetes 构建的基础设施平台将很多运维概念封装到配置文件中，并且提供了便捷的扩展方式给用户定义自己的资源，这样使 Kubernetes 的生态变得丰富起来，所以现在如果你想要实现一项运维特性，只需要在基础设施平台上定义一种类型的资源，并且编写相应的控制器即可实现，这样不仅规范了资源定义的格式，而且也方便了资源的真实用户。

运维特性下沉、聚焦

得益于基础设施平台上的资源定义规范化，面向应用的资源编排能力可以很方便的获得，在云原生体系下，我们只需要定义一些配置文件就可以轻松的编排出来一套复杂的应用系统，目前通过各种不同的应用定义模型，我们不仅可以定义资源交付的依赖关系还能屏蔽一些运维细节，将应用研发和运维的关注点分离开，实现不同角色的职责划分。最终应用研发可能只需要关心应用启动的一些启动参数配置，应用实例数量等一些最基础的应用配置，而网络、存储、监控日志等复杂的运维特性则会下沉到基础设施层，由运维人员负责管理。

基础设施可靠性和运维自动化

运维特性下层到基础设施层之后，运维人员可以专注于运维特性，并且依托于云原生生态提供运维能力。大家都知道云的最显著的特性就是弹性，而在云原生架构下还有一个非常重要的特性就是鲁棒性。Kubernetes 通过声明式编程实现了资源定义和资源实例的一致性，这基本上就保证了业务容器在 Kubernetes 上的很高的自愈能力，再加上各种监控告警、日志、事件告警以及配套的自动化运维平台，基本上可以做到高度的运维自动化。这仅仅是云原生平台的自愈能力，而如果基于业务应用的监控数据，配合上人工智能的分析能力，我们可以提前预测到即将到来的事件，并且做出相应的措施来应对，则会大大增加系统的容错特性。这些都是运维平台化之后逐步发展出来的。

如何适应云原生时代的运维

传统运维的核心职责是让业务应用稳定运行，而业务则希望能快速试错快速反馈，这两者目标是背离的，这也造就了研发和运维之间的隔阂，也是运维人员忙于救火的原因。那么在云原生运维体系下，这会是一个什么样的局面呢？因为运维特性下沉和基础设施平台化，运维可以立足于云原生平台之上，运维的职责也随之变化，运维人员不再聚焦于借助手工或者脚本工具去完成某些自动化特性，而应该从云原生体系出发，借助于云原生平台的能力提供自动化运维系统。SRE（Site Reliability Engineer）角色正是在这样的诉求之下诞生的，是 Google 率先提出了这个概念，并且给出了角色职责定义：保障服务的可靠性。通过构造标准的运维平台去保证服务可靠性，这要求 SRE 角色具有创造性，能够运用软件工程思想去完成运维特性的自动化。

云原生应用交付

以 CI/CD 为例，过去我们一般使用 Jenkins 作为 CI 的流水线工具，而 Jenkins 本身不具备高可用，实现方式较重，master-slave 的模式严重影响了性能，所以基于 Jenkins 的流水线系统运维起来成本较高。现在基于容器的流水线，比如云原生流水线工具 Tekton，通过 Kubernetes 资源定义流水线，并且基于 Kubernetes 的策略去调度，由自身的控制器来管理流水线，整体架构非常轻量，因为他的很多功能都依赖于云原生平台实现，无论是部署还是迁移性都非常好。现在 Jenkins 也可以通过插件的模式去支持容器调度，升级版 JenkinsX 也越来越向云原生方向发展。再说应用交付，如果我需要交付一套应用，应用包括 LB 负载均衡，RDS 数据库，一个无状态服务，现在只需要编写一个 LB 资源配置文件，RDS 资源配置文件以及应用的 Deployment 文件，并且设置相互的依赖关系，然后一键发布，平台控制器会自动拉起实例，不需一会，你的应用就可以访问了。

在网易的轻舟云原生平台上，我们基于 Tekton 和 Kubernetes 实现了云原生应用交付，充分利用 Tekton 的资源定义特性，实现了灵活的流水线模板，让用户可以非常方便的定义各种流水线。另外我们设计了网易轻舟应用交付模型，将应用的研发和运维特性分离，良好的模型定义加上云原生平台的特性，可以轻松实现多云多集群交付，再结合网易轻舟微服务平台的 Service Mesh 能力，能实现灰度发布、AB 测试、区域访问等路由策略，帮助业务方轻松上云的同时，还能很好应对各种复杂的交付场景。云原生日志采集工具和传统一样，但是因为服务以容器创建出来，具有漂移特性，所以要求日志采集平台能够自动感知业务容器的新增和漂移，自动管理采集配置文件。一般的实现是平台提供日志采集功能和对应的资源对象，应用交付中增加日志采集资源配置，控制器监控指定资源对象和应用 Pod，做出相应的管理动作。

云原生平台上的监控，同样以监控资源配置的方式对业务暴露，业务应用在交付时以 Kubernetes 资源对象的方式定义监控规则，由相应的控制器去监控到并且最终修改监控组件的配置文件。

总结而言，在 Kubernetes 上，所有的功能都是通过资源对象的方式对外提供。用户需要什么功能只需要定义对应的资源对象即可。而资源对象则通过 Kubernetes 的自定义控制器管理，为应用适配指定的运维能力。

云原生自动化运维平台

应用在平台内会产生事件、日志、指标等数据，这些是运维自动化的基础。根据事件告警去设置对应的处理脚本，并在告警发生时能立即执行，这是运维自动化的通用做法。

但是在传统运维框架下，为了保证告警事件能被准确消费，我们可能需要消息队列组件。为了保证消息不被重复消费，我们可能需要引入分布式锁，总之为了保证业务稳定，实现运维自动化，我们需要实现一套复杂的运维系统，而谁又来保证运维平台的可靠性？

这些问题在云原生框架下可以得到有效的解决，首先是事件，Kubernetes 本身就有 Event 资源用来标识平台内发生的各种事件，另外基于 Prometheus 的告警，基于日志采集的告警可以方便的在平台内对接。在云原生技术架构下，我们同样可以基于资源对象和控制器的模式去实现运维的自动化。

网易内部就实现了一套云原生故障处理平台，我们通过监控平台内的各种事件，生成异常事件资源，由对应的控制器去监控异常事件，并且根据事件基础信息去进一步采集关联信息。然后分析控制器会对异常事件进行二次确认，确认完成之后会交给恢复控制器，恢复控制器执行运维人员事先定义好的处理方案，执行完成之后，异常事件资源的状态会被改写表示异常处理完成。这是一套标准的云原生的处理流程。

在云原生平台上，我们可以充分利用平台特性去建设自动化运维系统，遵循平台的标准，融入平台生态中。从而可以快速建设出运维系统，并且不断完善。

运维转型

可以看到云原生时代的运维会和云原生平台紧密结合，运维人员的职责会基于云原生平台提供软件的运维能力，将运维能力平台化，体系化，并且不断的打磨平台，实现高度的自动化。那么运维人员如何去适应云原生时代？

这里有几点建议：

1. 容器和 Kubernetes 是云原生基础设施的事实标准，所以熟练掌握他们是基础。
2. 至少掌握一门编程语言（最好是 Go），学会使用软件工程思想去建设运维系统。
3. 关注 DevOps 的发展，了解系统的瓶颈，学会和研发做互补。
4. 关注云原生社区的发展，学习使用各种开源工具去解决遇到的困难。

云原生时代下的运维价值

云原生 DevOps 快速发展

容器和 Kubernetes 开源以来，从 Knative 开源，CNCF 应用交付兴趣小组成立，再到今年的 Helm 成功从 CNCF 社区毕业，云原生工具的发展推动着云原生 DevOps 的发展。

另一方面明确的职责划分使得研发和运维人员可以更加方便的协作，传统的环境治理需要运维人员按照系统清单准备各种系统设备，然后按照部署清单将应用部署起来，但是最终往往会卡在各种问题上，环境不一致，配置变化未同步，制品版本错误等等各种问题使得运维人员焦头烂额，而研发也是怨声载道，两者之间隔阂越来越大，而当应用运维功能下层到基础设施平台之后，当平台以统一的标准去定义各种运维资源，环境治理已经变得轻而易举，而且在新的体系下基本上不会再出现之前的问题。这也是最近几年 DevOps 越来越受关注的原因之一。基于云原生技术体系建设 DevOps 变得容易起来，很多传统问题迎刃而解。

云原生运维体系助力业务

传统运维体系下，我们要实现敏态业务的运维通常会非常复杂，敏态业务要求应用能快速迭代，因为快速试错快速反馈才能赢得市场，所以对基础设施的自动化要求非常高。而在云原生体系下，借助于应用交付平台、自动化运维平台，双态 IT 运维实现起来也不再复杂，我们可以一键快速搭建出一套复杂应用环境，做各种测试，并且将结果反馈给开发人员，在质量卡点通过之后能快速进入预发环境，并通过完备的监控体系将结果持续反馈，最终交付上线，运维自动化能保证线上故障在第一时间得到处理，通过不断的优化和打磨，运维平台越来越智能，能处理的故障越来越多，运维人力得到释放，可以更多的投入到平台建设中去，这是一个良性循环。这样体系下的业务会变得更加的敏捷、可靠。

为什么说运维是生产力担当

过去运维平台化程度不高，业务一旦变更容易引起线上服务的不稳定，无论是上线过程还是新特性带来的运维不稳定，都极大的影响了终端用户的体验，并且因为运维复杂性高，一些运维规范较难沉淀下来，造成了研发和运维隔阂重，相互抱怨的状态，产品迭代缓慢，用户满意度低。

当企业建立起云原生运维平台的时候，有了容器、微服务等技术的加持，运维更具体系，更加规范，自动化程度也更高。业务可以更方便的编排应用，发布上线，一天十次交付，线上问题能及时反馈，并且可以自动修复，新的运维手段可以快速沉淀，可以说是运维平台推动了产品的快速迭代，让产品保持创新和活力。

我认为运维平台可以从以下几点提升企业软件生产力：

1. 好的基础设施利于创造好的产品，好的产品创造更高的价值。
2. 快速迭代的产品可以增加企业竞争力。
3. 云原生生态下的技术更加开放，标准更加统一，问题解决的速度更快，这些都能降低生产成本。
4. 中台模式也是生长在运维基础架构上的，并且大大提升了生产效率。
5. 创新、快速试错、快速反馈是团队乃至一个公司保持活力的根本。

未来展望

当运维经历了从手工到脚本自动化再到基于云原生平台的系统化，一路发展而来，可以看到非常明显的特征：自动化和系统化。

这里我们也做一些展望：

1. 云原生平台已经定义了基础设施的标准，未来会有更多运维方面的事实标准落地，DevOps 标准，交付标准，自动化运维标准等等，只有尺度适合的标准才能更好的促进行业内的繁荣。
2. 代码定义一切，GitOps 已经非常流行，相信后面可定义的范围会更广。
3. 人工智能快速发展，AIOps 已经在各大厂商落地，得益于云原生平台，AIOps 将能和更多的特性结合，将来也会更加精确通用。
4. Serverless 将彻底屏蔽基础设施，运维概念对应用研发透明。
5. 再远一些，立足于云原生平台，随着运维自动化的程度大幅度加强，NoOps 不再是奢望，运维人力会得到很大程度释放。

作者简介

裴明明，网易数帆轻舟云原生架构师，目前主要负责网易轻舟云原生 DevOps 体系设计、研发及落地应用。8 年云计算实践经验，曾经在甲骨文、中国移动等公司从事云计算技术研发相关工作，对云原生相关，DevOps、微服务架构、分布式系统有着丰富的经验和独特的理解。