解读 2018 之运维篇：我们离高效智能的运维还有多远
赵艳标
2018 年接近尾声，InfoQ 策划了“解读 2018”年终技术盘点系列文章，希望能够给读者清晰地梳理出重要技术领域在这一年来的发展和变化。本篇文章是运维领域 2018 年终盘点，分析了一些有代表性和影响力的技术，也展望了未来的发展。
过去一年的是各种新的运维技术和理念交相辉映的一年。技术和理念落地的过程中，也就是理想和现实碰撞的时候，往往具有戏剧性。有的技术破壳而出，迎来快速发展。有的则遇到了瓶颈，在艰难的爬坡。这里仅选择最具有代表性和影响力的技术来进行分析，作为对过去一年的总结，也希望能够看清楚未来运维领域的发展之路。
DevOps
运维方面最重要的技术理念就是 DevOps。传统的软件组织将开发、质量保障和 IT 运营设置为分离的部门。在分布式和云计算的潮流之下，这种开发模式明显地不能满足软件快速迭代的需求和模式。DevOps 则把他们有机的结合在一起，以更好的提高软件交付的效率。
在 DevOps 潮流之下，单独讨论运维已经是没有意义的事情了。自从 DevOps 理念提出之后，运维从边缘重新回到人们的视野。DevOps 所代表的打破开发、测试和运维之间的壁垒，利用技术实现自动化的理念深刻影响了运维，被证实也被广泛接受，对提高软件生产质量、安全、软件发布周期等都有非常非常明显的推动作用，已经成为一种不可抵挡的趋势，对整个信息技术领域产生了深远的影响。每一项 IT 技术和理念的变革，背后都会和运维技术和 DevOps 理念产生千丝万缕的联系。
对于 DevOps 的理解有一个逐步深入的过程。初期人们对于 DevOps 常见的错误观念是把 DevOps 认为是一个组织、一个职位或者一套具体的解决方案，或者简单把 CI/CD 当做 DevOps。经过 DevOps 社区的不断宣传，大家都认识到 DevOps 代表一种理念和文化。在具体落地时需要根据自己公司的文化、规模等来采取不同的形式。谷歌的 SRE 手册作为一种有代表性的 DevOps 实践，给出来一个非常具有指导意义的示范，是对 DevOps 的 CAMS 理念：文化（Culture）、自动化（Automation）、测量（Measurement）、共享（Sharing）最好的总结。
DevOps 在开发团队具体落地时，一般都是从 CI/CD 开始，通过采用一些开源软件，解决基本的自动化问题。但是这种组装的解决方案逐渐不能满足更加高效的开发要求，所以转向自己开发一些关键的流程和平台。这是因为每个公司的基础设施和解决的问题都有其特殊性。开源虽然提供了一些关键的组件，但是还是需要根据自己的需求进行定制。从这个意义上讲，对于致力于提供 DevOps 解决方案的公司既是挑战，也是机会。其平台一方面要具有通用性和可扩展性，又需要能够对于不同行业的灵活的定制化的能力。
近年来，DevOps 的意义也是不断扩展。从字面上理解，DevOps 主要是为了消除开发和运维团队之间的隔阂，让软件的交付和维护过程更加流畅。如今，DevOps 已经扩展为一个通用名词，把敏捷开发、精益开发等方面的核心理念也包括进来，成为软件全生命周期的概念。这是因为很多事情，例如安全、监控、部署、故障处理等问题，在软件设计和开发的阶段考虑得越全面，后面所付出的代价就越小。最新的 DevSecOps 成为一种趋势就非常明显说明这个问题。
虽然 DevOps 已经被广泛接受和认可，但是其在设计应用中的成熟度还有待进一步提高。在一份关于 DevOps 的调查报告中，把 DevOps 进化分为三个级别，80% 被调查的团队处于中等评级，而处于高级阶段和低级阶段的都在 10% 左右。报告分析，这是因为通过实现自动化以达到中等评级是相对比较容易，而达到高等评级则需要在文化和共享方面的努力，这相对来说更加难以掌握和实施。这也符合组织文化变革中的 J 型曲线。在经过了初期的效率增长之后，自动化的深化进入了瓶颈期。更进一步的效率提升需要对组织、架构进行更加深入的调整。这段期间可能还会有效率下降、故障攀升的问题。从这一方面讲，实际 DevOps 的落地和深化还有很长的路要走。
Kubernetes & CNCF
说到 DevOps，就必须提到 Kubernetes 和 CNCF。容器技术和 Kubernetes 的结合，解决了自动化、标准化、配置化的问题，顺应了 DevOps 的理念，生逢其时，所以成为了时代的弄潮儿。由于 Kubernetes 背后谷歌强大技术力量的支持，容器编排技术中和 Docker 的竞争在 2018 年初毫无悬念的结束了，以 Kubernetes 的完胜告终。
Kubernetes 解决了发布 & 服务管理的问题。通过把容器、编排技术完美结合在一起，为 Cloud Native 技术提供了一个良好的基础，所以过去的一年也是 CNCF 快速发展的一年。CNCF 的生态发展壮大，形成了一个具有压倒优势的开源生态。CNCF 一方面成为很多公司和厂家都急着要搭上的开源之车，一方面又打破了平台建设的壁垒。CNCF 平台的提出，使建设跨平台的应用成为可能，成为事实上的应用开发平台的标准，极大简化了多云部署，也让云平台的竞争到了另一个级别上。云厂商要么在 IaaS 层提高效率，要么在 SaaS 层提高价值，而以前的 PaaS 层则成为一个没有商业机会的平地。Kubernetes 在改变技术生态的同时也深刻影响了云计算的商业生态。竞争需要向更深层次，和更高价值链维度进行。仅仅靠平台壁垒和技术优势来摘取商业红利的设想成为了泡影。
微服务和 Serverless
开发人员对于效率的追求是没有止境的。所以在 DevOps 的 CI/CD 之后，新的技术理念不断涌现，要进一步降低运维的成本。微服务、Service Mesh、Serverless、FaaS、Lambda 等新的理念和技术让技术人员眼花缭乱。不过这些新的技术可以分为两类：以微服务为代表的架构派，和以 Serverless 为代表的 NoOps 派。
每一种新的技术和理念的提出，都是针对运维中的一些痛点而给出的解决方案。但是在落地的过程中，微服务、Service Mesh 在解决一方面问题的时候，也带来了新的挑战。微服务减少了服务间的耦合性，让部署更加便捷，但是同时对于架构设计和业务梳理要求更高，而对于可能的微服务爆炸的情况，如果没有一个强大的管理系统，则运维的整体复杂性实际上是升高的。Service Mesh 刚出来时，所提出的解决问题的思路确实让人眼前一亮，通过 Sidecar 技术剥离所有的安全、服务发现、负载均衡等问题，让服务开发人员只用关注业务逻辑，可以完美支持多语言。但是这个解决方案是以性能的损失为代价的。如果要把现有业务迁移到 Service Mesh 的架构上，要完美保持 Service Mesh 的架构和理念就比较困难了。看到一些实际落地的解决方案，例如蚂蚁金融的 SOFAMesh，都是进行了一些折中来提高性能。
Serverless 的目标是完全让运维对开发透明，也是过去的一年中的热门之一。在 AWS 的推动下，以 Lambda 为代表的 Serverless 产品得到广泛关注，进入云计算的舞台。在这个领域，技术的演化也是非常快的。对于 Serverless 计算来说，首先要解决安全隔离的问题。同时由于每个业务的寿命周期短，所以需要平台技术启动快、开销小，能够快速水平扩展。AWS 开源的 Firecracker 和谷歌的 gVisor 技术都致力于让 Serverless 计算场景下的容器安全沙箱更加精简、安全。
FaaS 是 Serverless 的另一个场景。一般是在某一个业务平台上提供一个可扩展的编程环境，为支持前端场景的多样性提供更加快速的开发环境。很多国内的业务场景比较复杂的公司都有实践，通过定制化的 IDE 环境让开发人员专注于业务。无论哪一种 Serverless 场景，实际上后台的运维工作都是不可以缺少的，只是通过自动化技术让扩容容错等技术对于开发人员透明。它们所面对的场景来说目前来说还是有限的，但是随着技术的成熟，越来越多的场景可能会利用其 FaaS 来实现快速开发和迭代。FaaS 就类似于 Python 等脚本语言，和 Java/C++ 这些语言相比，以一部分的性能换来快速开发的优势。
AIOps
AIOps 利用智能化技术解决运维问题。一经提出就影响深远。经过几年的努力，智能化技术在一些基本的运维场景落地，例如故障预测、根因分析、智能报警灯场景上已经确实极大地提高了系统的自动化程度，但是同时也碰到了一些瓶颈。
理想和现实之间的差距是有原因的。清华大学的张钹院士对于人工智能技术的分析可以对这个现象给出比较合理的解释。根据张钹院士的总结，目前的人工智能技术水平，要应用到具体场景，必须要满足下面的五个限制：有丰富的数据或者丰富的知识、完全信息、确定性信息、静态与结构性环境、单任务与有限领域。目前取得较大进展的图像识别、语音识别、推荐、搜索、下棋几个领域都满足这几个限制条件。深蓝和 AlphaGo 都以下棋作为突破口就是因为下棋是完全符合这些条件的问题。满足这 5 个条件的工作，总有一天会被计算机取代。这五个条件也可以我们帮助我们检验某个问题是否可以采用人工智能技术。
对于 AIOps 来说，数据丰富性和准确性是最大的限制条件。要想利用好智能算法，就必须要花很大的精力来清晰和整理数据。业界人士的估计是 80% 的时间花在数据上，20% 的时间花在算法上。这是因为很多系统最开始设计时，并没有考虑智能化运维的需求和场景。关键信息不全，关键的依赖和关联关系要通过机器学习的思路来抓取出来的话，往往是事倍功半。所以智能化的出路，还是要通过对系统的改造，在深入理解运维场景的基础上，通过提高数据和信息的完整性、准确性来实现运维的自动化和智能化。从这个意义上讲，我们需要在设计开发阶段就考虑到系统智能运维的需求，方便数据积累和建立关于系统的知识。
总体来说，AIOps 应该还是非常有意义的理念随着系统的规模越来越大、复杂性越来越高，AIOps 将是必然的趋势，不过我们需要保持冷静和客观的态度来建设。
展望
可以预期的是，新的一年 DevOps 将会得到更加广泛的接受，其含义和范围会继续扩大和深化。最近推出的 DevSecOps 就是一个例子，把安全作为一个关键考虑因素放入软件全生命周期管理之中。基于 Kubernetes 的生态会更加丰富多彩。CNCF 的影响力会更加巨大。开放、标准化仍然是趋势。所有人，都努力在大的生态中占有一席之地。
Firecracker 和 gVisor 技术非常具有象征意义。开始是容器和容器编排技术促进了运维自动化，而现在无服务器计算又对容器技术的安全、效率提出了更高的要求，推动了容器技术方面更多的创新和变革。计算机核心技术能力直接影响到在运维效率上的竞争力。运维和计算机核心技术相互促进，相互融合，我想才是将来技术发展的大的趋势。DevOps 正如一个硬币的两面，已经完全无法分割开来了。可以期待的是新的一年里会有更多深层的技术架构上的创新，让开发和运维更加高效智能。
每一个理论和模型、架构都有它的优势和缺点，有其适用范围，也有其局限性。我们不能指望一种技术解决所有的问题。人工智能、大数据将越来越重要，但是人的创造性、主动性仍将是最宝贵的资源。《人月神话》中预言没有可以解决一切问题的银弹，而人工智能看来也不是我们预期的银弹。但是通过积累对于整个系统更加完备的拓扑、依赖等更方面的信息，然后和 AI 技术相结合，我们还是有希望一步一步地接近我们期望达到的智能运维的目标的。
作者简介
赵艳标（花名：燕标） 阿里巴巴资深技术专家。2015 年加入阿里巴巴，现任阿里巴巴基础设施事业部天基平台架构师，主要从事大规模集群和应用运维、运维数仓、智能化和安全生产方面的研发工作，着力于建设面向未来的智能化运维体系。之前曾在微软公司的必应搜索、Office、SQL Server 等部门工作多年。