云原生时代 DevOps 的最新实践

白凡

分享：顾宇
编辑：白凡

讲师介绍：熟悉我的同学都知道，我之前是斯通沃客（音译）的，今年来到埃森哲，也住在深圳。如果深圳的朋友在做社区活动的，大家以后可以常交流。为什么离开斯通沃客呢？世界这么大，我想去看一看。我现在在埃森哲工作，在深圳。

今天的第一个话题是我带来的《云原生时代DevOps的最新实践》，也不敢说最新，这是一个实践。因为你知道一个实践从开始构想到完成要在很多场合去实践，证明这个实践是有用的，它是需要一段时间的。这个时间通常是在6个月到12个月，也就是说我们开始构想这个实践超出已有的实践。

大家在很多DevOps的书上看到很多东西都是沉淀下来很长的东西了，所以我们今天讲的实践实际上是书上没有的，只是我们在做的时候觉得这个实践非常好要推广给大家，有些技术细节等一会儿我们可以讨论。因为时间有限，我只选了我觉得几个比较有代表性的。
这是今天的几个议题，云原生到底是什么，云原生带来的DevOps有什么技术挑战，最重点的是围绕这些挑战我们会有什么样的新的实践。

1. 云原生是什么？

1.1 云原生背景和概念

因为Cloud Native的概念诞生有两三年时间，在最初没有云原生计算基金会的时候就有Cloud Native概念了。当时提出云原生概念主要是基于四点：DevOps、持续交付、微服务、容器化，但是在这之后出现了云原生的概念，有没有同学在6月份听过我讲云原生的？有，非常感谢。在6月份之后，7月份CNCF也就是说云原生计算基金会已经修改了云原生的定义，已经不是那几个实践的组合了。

新的定义更加开放一点，这是比较完整的定义的中文版。上面这一句话可以理解为应用无状态化，只有你能做到无状态之后，你才可以构建一个弹性可扩展的应用，剩下的技术都是为了目标所服务的。

第二条定义我们是构建一个反脆弱系统，所以需要两部分，我的应用既然可以进行无状态的可扩展、弹性扩展，我要在上面运行的时候就需要为各种失败情况做好准备。

我们把这两个概念拆解一下:

1. 首先在私有云、公有云、混合云的环境下，因为之前最早讨论云原生的时候，它的概念是没有云的，我们有云之后就有公有云和私有云。这个区别是它在不在我的机房里面，我能不能管到它，所以现在我们在讨论云的时候，不仅有公有云，还有私有云和混合云。

2. 你的应用程序是可弹性扩展的，它的意思也就是说你要为你的应用做好无状态化准备，可以随时进行扩展，而且减少失误、不一致性或者其中带来的问题。

3. 容器，虽然我们现在说容器已经不仅包括Docker了，还有其它的容器化技术，包括最近流行的微服务Service mesh、不可变基础设施等，这些是为这个目的服务的一些技术工具，当然技术还在不断的发展。我们在未来的云原生的技术实践发展里面，尤其是工具发展里面还是为了运行可弹性扩展而服务的。

4. 后面两点是刚才说的第二条，构建容错性好、易于管理和便于观察的松耦合系统。这里面的一个重点是容错性好，如果是高可用前面就已经保障了，后面是一定要易于管理。其实我们知道很多同学开始实践微服务的时候，你做微服务化的时候，你把应用拆解到一定层次的时候发现这不是技术问题，而是管理性的问题，你采用什么方式管理微服务中运维的复杂度、以及它们之间的关系、以及它们的版本之类的。因为我昨天听到好几个带来这样的问题，我怎么通过大版本发布微服务，这是一类管理性问题，但是我们通过技术手段解决。尤其在云原生的环境下变得更加复杂一点，基础设施容易了，但是管理应用更复杂了。

结合这两类技术之后就会得到后面的结果，能够轻松的对系统作出频繁和可预测的重大变更，频繁的变更以前可能一天部署10次、一天部署1次，这个系统指的变更是不仅你的应用程序，也包括你的基础设施。我今天调整一个网络，我再调整我网络的时候上升系统不受影响可不可以，是有办法做到的，我们等一会儿会介绍这方面的实践。
可预测对时间的要求比较高，可预测跟我们说的AI Ops有点关系。但是这个可预测是基于资源和容量，即在保证上面的条件都满足的情况下，我如何做到这一点。

1.2 云计算定义

云原生意味着什么呢？下面有一行小字，我们在讨论云计算的时候，这个定义是谁给出的。你在网上搜索到10个条目，大概会有11到12个对云的定义。现在比较公认的是美国国家标准语技术研究院的定义，它有5个特征：

• 按需自助的服务
• 低门槛的网络接入
• 池化的资源
• 快速的弹性化
• 度量的服务

这几句话比较抽象，我们来解读一下这5个定义到底是什么意思。

早晨我问大家有没有吃早饭是这个原因，就是为了放这张图，并不是所有人都喜欢吃火锅，但是有些同学看到这张图就饿了。什么叫按需自助的服务，就是说当你有了云计算基础设施之后，你所需要的东西不是需要第三方支付的，比如说我可能需要一个系统管理员给我创建一些资源，而这些资源已经存在和运行了，只需要开发者申请，这就是按需自助的服务。也就是说，当你有了云原生之后，所需要的资源是开发人员可以自己按需获得的，不需要再去搭建一套数据库，直接调用这种服务，无论是在PaaS平台或者公有云平台上就可以达到目的。
当然我们说到缓和或者数据库太底层了，更高的会有一个比较抽象的应用。比如说我们需要一个负载均衡，负载均衡有硬件方案，也有软件方案。你需要负载均衡的时候，在云环境的情况下只是一个API，你就可以自己去创造这么一个负载均衡。

第二是低门槛的网络接入。在座有没有运维工程师，见过这样的机房的举手，你们的机房是这样的吗？

这里有一个很重要的东西，在这张图片里面右边是线，在最开始做运维的时候是X8线、一堆交换机、背板、路由器，只要来了设备，我只要哪些是我的线，上面打个标志插进去就行了。我们曾经见过陕西省出口的一个对外网络，它就集成在一根网线上，那是很久以前的事情了，就这么一根线关联整个陕西电信网络对外的出口。还有一个东西是风扇，这个东西的散热性并不是那么好，别看它那么松散。

低门槛的网络接入就是在你以前使用云自己建机房最初级的时候是这样的，现在高级一点，大家缠蜘蛛网和拔蜘蛛网有一个经验，就会变成这样美观一点的，用不同颜色的线，现在的网线五颜六色做精细化的管理。但是现在的网络很少能看见了，我们主要有一个数据中心，也不需要下面有一台风扇，也不需要机房建设、空调、防火、防潮。以前我在银行工作的时候管理过机房、也建设过机房，我知道要构建一个数据中心不是我一个人就能负担得起的，但现在想要有这个机房把自己的应用接入网络必须刷身份证，用支付宝交钱，你就能得到可以用的计算资源。这是低门槛的网络接入。

第三是池化资源。它是一个停车场，我知道东北有一个全国最大的停车场，什么是池化资源？我们都知道我们有一个局部性原理，在学操作系统和计算机原理的时候有一个局部性原理，也就是说你的计算机在使用的时候总是有一些空闲资源。当这些空闲资源很多的情况下，被浪费的空闲资源就会变成很可观的浪费资源，我们能不能这些资源通过租户隔离租的方式给别人，他用完之后再归还回来。
池化资源的意思是有足够大的请求量、使用量和弹性空间，能够应对我当前所需要的需求。所以在这种情况下，你的构建机房和使用资源的成本会大大减少，这也是很多企业为什么要投入做云的原因。有了池化资源之后，你的资源在当天使用的时候不一定在你所在的机房里面，如果你有机房，你的应用肯定在你的机房里面，但是如果是两地三中心的，你的应用在运行的时候，这个应用当前就访问A机房，可能到B机房了，因为哪里有可用资源，他会尽全力先把这些资源用完。

第四是快速的弹性。弹性我们都知道是水平扩展，什么是快速的弹性，比如说瞬间秒级的情况下可以并发产生很多资源。为什么需要快速的弹性呢？因为在云计算特别是公有云的情况下，很多流量是不可预测的。比如说我以前在中国移动做大型机系统的时候，每个月都有一个出让期，出让期是在月初1号和月末最后一天，这段时间用户的访问量是非常巨大的。但是这个是可预测的，因为用户的访问量再大也不可能大于中国移动在一个省里面的用户总和，是有上限的。
但是在互联网不可能把全球或者中国所有人都点一遍给它增加一个最大的资源，而这个时间的突发访问比如说即将到来的双11就是很大规模的访问。如果备这么大的访问量是没有必要的，像池化资源，你只要有这么多空闲，我只要能随时把基础设施和应用程序快速扩展起来，能够满足我当前的业务需求，使每个用户都有同样的体验，这个是很重要的。而这个能力在之前并不是很容易的能力，但是我们现在有了云计算平台，它一定会提供这样的能力。

第五是可度量的服务。前面几个都是环环相扣的，度量的服务是非常重要的一点，在大规模、不可预知、而且池化资源在随时变动的情况下，你想定位一个问题是非常困难的。比如说昨天腾讯做的AI Ops，在这样的环境下你想知道究竟出现什么状况是非常困难的，所以需要每个服务都有一个度量的数据，可以让我们及时知道云上的服务应用基础设施都在什么样情况下。

Cloud Native带来的一点是再一次降低了互联网化的门槛，如果你之前要把你的应用接入到互联网上，你需要有一个机房或者起码有一台托管的机器，后面慢慢有服务，但还是需要很多人需要有运维的知识、系统的知识、网络的知识才能做到。而到了现在的Cloud Native，你可能只需要支付宝账号或者微信可以支付，你就可以立即获得这些资源。以前我们想一个互联网应用可能太科幻化，但是现在你要想达到这样的应用是很容易的。

2. 云原生带来的 DevOps 新挑战

在这种情况下，我们能够做到一些新实践分别是什么。有几个问题，第一个问题是我们所说的后DevOps时代，DevOps时代是开发和运维，我们认为甲方管理资产、乙方开发服务应用程序的。我们会把这两个分开来，它不仅是组织上的隔离，也是生命周期的隔离。所以它在一个应用程序的生命周期里面扮演着一个分裂的角色，我们DevOps就是要把这个重新分裂的角色完整的合上，让它变成一个完整的生命周期的。但是我们现在看到越来越少人关注运维是什么样的，因为我知道现在很多做DevOps的也不关注机房、也不关注网络、也不关注散热，我们更多的是通过软件定义基础设施的方式把你的基础设施当成一个软件产品进行研发、进行端到端的维护。

2.1 后DevOps时代

在后DevOps时代，我们的运维工程师和开发工程师团队就变成两个不同团队了，一个是应用程序服务团队。这跟我们以前的开发团队做的事情没有什么不一样，只是要把应用程序上线后的维护完成了。而应用程序上线后的维护这一部分，从基础设施我们以前的DevOps团队被剥离了，这两者之间就会形成一个断层，我们之前说的DevOps后面进行分裂就会变成这两类不一样的团队。现在我们很多企业开始用云、用PaaS就会有一个专门管理PaaS的团队，这个也是我们现在推出大中台的一个前提。业务的组合分界线越来越清晰，当我们现在写应用的时候，后DevOps时代我们已经不需要关注输出了，也不需要关心有哪些监控点或者埋点。

因为现在提供的基础设施已经慢慢把业务从技术层面剥离了，我们会发现我们的基础设施越来越厚，下面的应用程序越来越薄。因为下面的东西越来越稳定，上面的东西变动越来越频繁，我们希望上层跟用户贴近的东西能够更加的灵活和轻便。我们等会会介绍一个实践，看看我们怎么能够做到一天需求提出，我们在一天之内就把从需求到上线全部完成了。后DevOps时代的一个特征，我们的应用程序部分会越来越薄，程序员只需要写好代码，剩下的事情什么都不用管，剩下的事情会落到基础设施团队上。

2.2 软件定义的基础设施

在很多云环境下很多事情没有办法手工操作，我拔一根网线登录进去修改一台机器，你碰到大规模批量性的应用基础设施的时候，你需要自动化的方式实现。我们有了基础设施即代码，但是这只是我们在持续交付过程中做的一个实践，而我们现在的软件定义基础设施更加的偏向于一个编程模型。

当你的基础设施和应用程序变成软件的时候，我们能不能用开发实践解决运维问题？现场做一个调查，在团队里面用TDD测试驱动开发的同学请举手，非常不错。当我们开始用云化Cloud Native方式的时候，你发现运维的同学会面对更多底层的编程操作，刚才那3位有运维的同学吗？没有运维的同学，都是开发的，有运维同学是做基础设施编程的吗？有，也有用其它语言的。这边是开发的同学，他们用TDD，运维同学没有用TDD。

讲一下历史，在软件发展的历程中，我们为了证明软件是正确的有两种方法，一种是形式化证明。很多人没有听说过这种方法，这是一种偏数学的方法，它的难度非常大。另外一种方法是怎么保证软件是正确的，这是测试反证法。举个例子，有个人能吃20个包子，他自己说了不算，我们需要有20个包子来验证他吃过20个包子。他今天吃过不算，要每天吃才算，才能证明他是每天吃20个包子的人。自动化测试和TDD就解决了这个问题，第一是验证了他的能力，第二是持续自动化做验证，他就能每天达到这样的能力。

另外一点，我们这样的实践有很多，如果大家去年关注技术雷达就知道，我们很多基础设施的部分都可以做TDD，比如说在docker上面做了TDD，我们开发docker镜像的时候采用TDD方式开发。我们的基础设施在规划容量的时候，我们采用TDD的方式先构建如何验证基础设施的测试，之后再实现基础设施的调整。当你面对的基础设施规模越大、使用越复杂的时候，因为你的基础设施都已经是通过软件定义或者代码定义的方式，你的基础设施的代码会变得很复杂，我们有了TDD就有了基础设施即代码的重构。
像我们刚才看到的机房一样，左边是比较凌乱的机房、右边是比较整齐的机房，我们要从左边凌乱的机房要右边比较整齐的机房，在以前的规划中是要新规划一个机房，把左边机房的应用和网络慢慢切换到这边来。我们现在在做基础设施的时候，一开始没有注重基础设施的网络规划和资源规划，它在你的代码里面一定也是非常凌乱的。你可以通过TDD的方式重构，我的行为和验证方式是不变的，通过这个方式创建新的基础设施比较整齐的架构的时候就有了一个验证，可以让你更快的得到结果。因为我知道一些数据中心的网络重新切换大概会需要两到三年的时间，如果完成基于基础设施即代码的重构两三个月就完成了，你会得到更加整齐的规划更加合理的架构。

另外一个是基于基础设施和代码的解耦，大家知道微服务应用层面的解耦，但是基础设施PaaS平台慢慢会变成很大的一块，中台会变成很大的一块。但是有一点它的变化不会像应用变化那么频繁剧烈，而且带来更多的依赖性。通过基础设施代码解耦解决什么问题？解决并发问题，比如前端做一个网站从前端设计到CDN到数据库到应用到底层实施，每一个部分实施变更的周期是不一样的，我们通过合理的解耦可以让大的问题变小、小的问题变得更快。这样基础设施就更加有弹性，而不是来了一个应用需求说我的基础设施已经是这样了，太难变了，我没有办法改变基础设施。如果我动一点点，比如说大家用的共享存储，只要动一点点上面云计算平台或者PaaS平台的所有应用都会受到影响，大到不敢动，它不会出现这种情况。为了应对这种情况，我们根据基础设施即代码，重新看待基础设施即代码，把它规划得更好。

在这种情况下，我们采用编程是面向资源的总架构，实际上你可以认为它是一种API，你的资源、磁盘、网络、负载均衡等很多东西都可以看作API资源。我通过UIO访问它，它有这种架构，通过状态机我们就可以进行这方面的操作。另外资源是不同的状态机，在不同的状态之间进行切换。如果资源是一个状态机，实际上源代码是这台机器的配置，而不是附进去的软件包，而是你的应用程序是云计算资源的一种配置。

2.3 回顾Cloud Native带来的挑战

第一是后DevOps时代基础设施变得越来越厚，应用程序变得越来越薄，基础设施和应用都要求变动频繁的情况下，以前的DevOps摸清和DevOps的实践合作模式可能已经不再适用了。我们要看到新的DevOps，新的DevOps是我基础设施端的DevOps和应用程序端的DevOps，我们中间会有一个很明显的分界线。我们现在大部分实践都是用docker，docker以内都是应用开发的，docker以外都是基础设施管理的，但是应用程序会越来越薄。我们接下来所要讲的实践里面，你不需要关注运营环境怎么样，只需要把代码写好就好了。

第二是软件定义基础设施，我们的基础设施在云上、在PaaS平台上，在机房看到物理性的东西越来越少，用软件来解决的问题越来越多。我们可以开始用一些开发的实践优化Ops的工作，Ops更多的是规划处理的问题。
最后一点是我们在这种状态下，我们编程的方式和架构的方式已经发生了变化，它是一种面向资源的计算架构。

3. 云原生下的新 DevOps 实践

3.1 安全

云环境的安全跟企业内网的安全是不一样的，有可能我做一个网络分段，拔一根网线就安全了，但是云计算是不太一样的。先说一下在DevOps的过程中发生的安全过程，一开始我们讲DevOps的时候，你可以看到最早的DevOps是不讲安全的，我们只是发现问题，怎么样把开发和运维两端能够更快的进行沟通，提出我们的交付效率和问题响应速度，安全只是传统运维上已经有的安全措施继续再采用，但是并不会考虑安全。
但是你会发现慢慢的随着自动化程度增强，你会觉得这个安全也是实践DevOps中的一个瓶颈，你要解决这个问题，我不如把安全放到DevOps整个环里面作为重要的一环来考虑，我们会把一些安全的手段自动化加入到DevOps流程中。像昨天讲到的，我们会把一些扫描放到持续交付流水线里面，我们会在线做一些验证，但是这些所谓的DevOps更多的有DevOps网站，我们把安全手段通过自动化的方式加入到DevOps的反馈环和流水线。

在两三年前我们就已经不再这么做了，在一个安全的框架下，我们如何重新考虑DevOps，设计DevOps的人员、场景、使用。通过更多的方式，而不仅仅是自动化的方式，在座有没有做安全的同学？有没有做DBA数据库的？有点可惜，希望大家可以理解。你在做安全的时候，你会发现更多的安全问题是人为因素。因为我们技术上的保证尤其是在运维层面已经非常成熟了，你只要符合某个规范，把安全的点都考虑到，其实你运维端的安全就已经做得不错了。我们可能偏向于应用端的安全，应用端的安全有一个BSI，在你的整个应用开发周期里面考虑安全因素，你的应用有可能是你的安全最大的漏洞。但是你考虑这一点以后，你会发现DevOps不好串起来、也不好用，我们要考虑人的因素在DevOps体系里面是怎么样的。

3.2 软件定义安全

了解BeynodCorp的同学有吗？谷歌去年发表了一篇论文，这篇论文讲的是在未来的云环境下怎么定义安全。因为在云环境下要连接第三方服务和不同供应商之间就会更加复杂，它安不安全你是不知道的，它不安全会造成非常大的损失，它所能受到的是很大的影响。这是一个模型，有相应的论文，后面我会把论文全篇发送给大家。他在里面讲到三个原则：

第一个原则是所有网络都不可信，所有网络包括你自己的网络都是不可信的，比如在企业里面我的PC笔记本电脑和企业无线路由器连接的网络也是不可信的，你不要以为在企业里面有企业内网，电脑设备就一定安全了，这种情况下在BeynodCorp里面所有网络都是不可信的。
第二是基于已知的用户和设备进行授权访问，如果网络是不可信的，你要访问资源一定要经过用户和设备进行授权访问。在座的有没有不知道是MFA多因子认证的？MFA是我们比较通用的一个实践，在如何确定你是你的问题上，这几个元素里面、这几个因子里面，你只要满足其中两个就可以证明你是你。
第三个原则是对所有服务的访问必须进行身份验证，授权和加密。我们想到再做一个安全小调查，从用户的输入开始到最后存储数据库里面所有部分都进行加密的同学请举手，我们可能想到第一个问题是麻烦，第二个问题是可能有性能问题，现在加密技术的性能还是不错的，但是会有一些麻烦，而麻烦和应用性之间是有一个平衡的。在这里面我们在Beynod和Corp里面，为了保证数据安全性，我们一定要做身份授权和加密。

另外一个是3R企业安全--云原生的安全，这是他们给的标题，我觉得这个非常不错。有没有听过3R企业安全的？这证明我的实践比较新，这也是去年的实践。什么叫3R呢？一是Rotate，经常更新用户的口令，每天都更新数据库密码的同学请举手？一天更新几次？

观众：实时更新。

顾宇：这个做得不错，等一会儿我要介绍跟你一样的实践。二是Repave从0开始构建，每天从基础设施开始构建的同学请举手，我的网络和机器全部拆掉了，每天把应用重新构建一次，没有，我举手。三是Repair及时打补丁，这个我相信有同学做吧，每天做这个的举手，你们的运维做得非常不错，等一会儿解释一下。

3.2 数据库流水线

这是我们做的案例，没有人管理密码的数据库。大家可以看到，这是一个数据库用户常见分析结构，Root是数据库最大的权限。在所有的用户里面没有一个活着的人知道用户密码的，Root有下面所有的权限，包括有用户管理和配置管理的权限，以及下面所有的权限。Power User是DDL语言，每一个都是针对我们数据库权限的访问，通过这种分层访问的方式来决定数据库里面的用户分配。我们应用访问数据库也会有一个用户，就是App User，目前是没有人知道密码的。我们首先会有权限架构，权限架构会扩大分配应用。

我们的数据库是构建了一个流水线，前年有一个实践叫基础设施流水线，我们建立了一个数据库流水线。从左边到右边看，左边第一个配置是把PaaS平台的网络配置关于数据库的配置好，如果有变动就相当于重新建。当然我们用了一些高可用的手段，让它的变动不那么大，我们会新建数据库，用PaaS平台数据库配置。数据库配置文件，建好数据库之后需要配置文件，当然数据库配置文件完成之后需要数据库重启。但是有些PaaS平台包括公有云不用重启，创建之后这两边就变成一块了，这是我说的数据库的基础设施。

这里左边是数据基础设施，右边是数据库实例，我们把这些全部放到流水线里面。而这两份除了最基本的创建用户、删减用户、增加用户名和密码之后，我们可能还有一些用户数据是由应用程序触发的，我们就会放到另外一条流水线里面。这边完成之后会驱动这边。所以我们可以做到每天把数据库重新干了再恢复，中间会有一个差额，这个数额我们会通过打标志的方式迁移过来。另外一种比较快的方式是数据库镜像，现在很多公有云数据库会做数据库镜像，很快就能还原出数据库实例。我知道在AWS上有一个没有服务器实例的数据库，大家有兴趣的可以尝试一下，当然中国区应该没有，是在国外的区域。

没有人管理的密码数据库还有一点，就是我们的应用流水线。我们每次应用部署的时候都会更新访问应用的用户名密码。我们的方式是每次部署的时候创建一个新的用户，我们的用户名就是app-user-version，每次部署的时候都会有新的用户，他的密码是自动随机生成的。每次生成密码的时候，按需可以随机创建新的基础设施，如果我的配置没有变更，他的变动是很小的，是秒级的，可能我点基础设施没有变动就快速过去了。

另外一点，在这个基础设施上再部署新的应用，你会奇怪自动创建新用户的权限是哪里的。这个自动创建新用户的权限，我们会取得一个临时的权限，在创建完新用户之后取得一个权限，不是Root权限。创建权限之后再把它的权限回收，我创建完用户之后就把用户权限回收了，也就是说，保证我使用这个权限的时候，当场的情况下只有一次授权，谁都没有碰过任何用户名密码，因为我每次用户名密码都是自动随机生成的，只有应用程序自己知道密码是什么样的，这是我们每次部署都会更换密码的一个方式。
我们在以前创建应用数据中心的时候是从左边开始的，网络到应用程序我们都管，后面我们有云之后，到IaaS平台的时候，操作平台可能是IaaS平台给定的，上面是我们处理的。到了PaaS和SaaS之后有更多事情交给云环境，我们所需要写的程序越来越少。我前面说到，后DevOps时代你所需要管理的基础设施是越来越少的，但是管理基础设施的复杂度会越来越高。

3.3 全云端运维

这里讲到CLI calls API，你做的事情是通过你的命令和API处理的。在座有没有用过AWS应用的，它会给你一个命令，AWS应用后面跟着服务、服务跟着操作，每个操作都可以通过CLI工具完成，这个东西是非常好编程的。而不是给你一大堆核心界面拖来拖去，那样的东西是非常不好管理的。这种面向资源的计算思维，每次CLI API都是一步的，性能上还会好一点。另外一点是在这种情况下你需要有全云端运维机制，知道你所对应的资源是不是完成你所要完成的工作，这就是一种方式。

右边是国外比较通用的，左边是对应的产品。以前我们做应用性能测试的时候要买点做各种各样的事情，自己要开发、自己要找工具、自己要搭建。我们现在首先我们用这些运维工具，我们不再自己搭建了，我们在云端就用云端的服务，非常成熟。比如说查日志，我们看到很多ELK教程，很多人都把ELK搭建起来，但是现在已经不太用了，有从ELK调整到EFK的吗？我们已经不再用自己搭建的方式，而是买成熟实践和稳定实践的方式做这件事情。全云端运维，右边是国内对应的产品。

全云端在线协作开发，AWS上的Cloud9被AWS收购的，我们的整个开发环境都是在云上的。你只要有一个浏览器，不需要在自己的配置上装安装包、装Java，虽然Java马上要收费了，我们未来可能不会再用Java了，我们会用全云端在线协作开发。

国内也有同样的产品叫行云趣码，这个产品跟前面的Cloud9不一样，行云趣码产品可以接不同的云环境。你只要有任何的云环境，就可以在上面搭建这样的环境。所以你的开发人员入门使用这些东西的时间就会大大缩短，我打开浏览器就开发了，不用考虑语言冲突和各种SDK的麻烦。

另外一个是FaaS应用，函数即服务。最早是AWS Lambda，我两年前讲AWS Lambda的时候还是一个很新的概念，这两年各种平台都已经出现了。你只写应用端的一些代码，剩下的都不需要管。

之前用serverless框架可以很容易的集成到持续交付流水线里面，然后去运行FaaS服务。有了FaaS服务，还是你自己手工搭建数据的时代，现在有了更多FaaS平台。首先我们可以看Pythonanywhere，作为一个程序员是很幸福的，因为你可以马上转变成大数据工程师。有了这个工具之后就可以快速的把FaaS部署到线上，直接成为一个应用，而不需要搭建环境。如果是私有云需要像前面搭建一些Webtask等，它就可以快速帮你生成。

3.4 去中心化持续集成

我们的去中心化持续集成没有集成服务器，集成怎么做？我可以给大家讲一下，这是我们做去中心化的持续集成步骤。第一是git push，git 有一个功能，在你提交Push命令之前可以增加一些代码做测试，这样就不用CI做测试。第二是代码提交门禁，采用单一主干提交，进行部署，部署后测试，最后是发布。在这个过程中，第一个是手工操作、第二个是手工操作，中间全部是自动化，也就是所有上线都是自动化，有什么集成测试，集成测试也是我应用的一种，直接上线进行部署后测试。

我们在提交预测做一些单元测试的事情，但是切忌不要用分支，如果增加分支就给管理源代码和延迟提交应用的借口，所以单一主干提交，当然你的管理就会更麻烦。我们部署的时候直接是函数式微服务的部署，因为我只修改那一点就只部署那一点，最后是部署测试。如果微服务要测试之外，微服务直接跨服务的业务也需要测试，而这种功能测试也是端到端的应用。在这种情况下，我们是没有集成服务器的，因为你也不需要。有没有在座的同学提交代码之后直接上生产环境的，中间也不需要手工操作发布，直接发布到生产环境的有没有？厉害厉害，我们花了三年才做到这一步，中间主要是在测试这个地方花了很大的功夫。
除了我们刚才的功能测试之外，我们还有ATDD，ATDD是验收测试驱动开发，大家可以了解一下。通过这种方式，我们可以把手工操作代码提交到生产环境下，增加信心和保证。因为你不会考虑到上去之后有什么问题，你能考虑的问题都用自动化测试的方式解决，当然也不能特别绝对。

另外一点，小心采用FaaS的时候不要变成Nano-Service。以前微服务是中间部分，FaaS微服务可能会有更多函数。但是如果你的管理复杂性增高，可能你管理服务的复杂性，包括来回调用、相互依赖、事务处理更多，可能就会进入一种反模式，这种情况是需要避免的。

3.5 Chaos Engineering

这个有在用的吗？没有。这个实践后来叫做混乱工程，混乱工程是什么意思呢？混乱工程是它随机在计算机把你的几个实例下线或者服务搞坏，看你的服务是不是正常使用。基于这种方式，你可以用这种工具，在网上查混乱工程或者Chaos Engineering。

这个要重点讲一下，首先我们假设这个系统是正常的，我们在系统正常上的指标来定义系统怎样是稳定的，第二是假设这个稳定的状态，你会把这个状态的所有服务器和实例拆成两个组，一个是控制组、一个是实验组。第三是我们会引入一些反映真实世界的变量，比如说断电、攻击、负载过高之类的东西，硬盘故障、网络连接故障等干扰实验组，看最后的应用是不是一致的。如果实验组部分被这些因素扰动，它应该和你正常的部分行为是一致的。如果它们两之间没有差异，就证明验证通过。如果它们之间有差异，反驳这个假设找到差异修复应用系统，找到不稳定的因素让它变得更稳定。这个测试你可以每天去做，也可以隔一段时间做一次，但是我建议每天去做，像我们以前做的每日可发布一样。

另外在安全方面也是这样的，这个工具ChaoSingr很初级，大家可以记一下。这个工具目前只是涉及到AWS，它是引入一些安全方面的变量，破坏安全控制和访问策略，看有没有入侵的可能性。它的理论和上面是一样的，假设我们的应用是安全的，什么样是安全的，我们做了哪些措施保证安全。我们找出另外一组来，用一些安全方面的手段去除这些策略，看有没有其它手段保护住。

3.6 总结

我们在DevOps Cloud Native的实践有几个是比较重点的。第一是安全第一，从安全的角度设计DevOps，而不是把安全引入到DevOps里面。另外一个是BeyondCorp、一个是3R企业安全，能够重建应用和基础设施，让入侵及时被处理掉，让它没有足够时间做这些事情。第二是Serverless First，当你开始用运维工具、开源工具开发应用的时候，尽可能要有AWS Lambda方式，因为你需要维护的基础设施越少，你的应用弹性就会更好。最后是混乱工程Chaos Engineering，让你云上包括私有云上的基础设施都在一个非常稳定的状态下做测试。我们架构的只有一点是最核心的，就是为你的失败可能出现的情况进行设计。