作者： 万金
编辑：济萌
作者简介
万金
ThoughtWorks 高级顾问10年+知名外企与中国企业的IT从业经验，包括IBM，华为，中兴，Thomson. 具有7年云计算相关经验，多系统的研发和运维经验，熟练掌握敏捷和DevOps方法论和实践，具有软件研发生命周期工具与流程改进丰富经验。
序言
在软件吞噬时间的时代，在IT基础设施多样性与分布式趋势中，部署的复杂性与规模日益增加，而大部分的软件崩溃都发生在部署过程中。目前提高部署效率与稳定性成为了一个严峻的挑战。本文讨论在原生云应用的场景下如何将软件高效稳定的发布到用户手中。在本文的末尾会畅想智能运维给软件发布与运维工作带来的新能力。
本文的四个部分：
- 数字化转型的趋势与挑战;
- 软件发布的各种坑;
- 云原生应用如何发布软件;
- 下一站智能运维。
(一)数字化转型的趋势与挑战
1.1.分工协作提高效能达到增长极限
如果说到DevOps的精益，就不得不说亨利•福特将流水线引入到汽车生产当中。为什么要说流水线呢？我们在传统企业转型中所使用的成功经验，在现代数字化转型的环境里没有办法继续复制成功。
原因主要有以下几点：
第一，单一产品的竞争优势被行业外颠覆：传统汽车产品积累了多年的竞争优势，在电动车出现后被颠覆。比如特斯拉，不使用机械引擎，竞争优势不再可持续。
第二，低价高质不再是客户选择的关键因素：消费水平提高和体验差异导致成本竞争不再是竞争的主要因素。相同的东西只要便宜一分钱都可能造成市场份额的巨大差距。如果一款手机卖十块钱会有市场吗？在同学聚会的场合你会用十块钱的手机拍照发朋友圈吗？这种赋予商品的个性标签属性，使得价格为主要竞争手段的情况已经不复存在了。
第三，人的延伸价值观局限（麦克卢汉笔下的所有商品都会以人的延伸的能力来衡量价值，而人类的能力种类是有限的,因此商品的总量也有局限的）。现在的主流产品，可以参考结婚时候需要的几大件商品。现在的住房里需要的大家电数量都是有限的（电视，冰箱，空调，洗衣机），并且每一个电器品类的市场容量都是有限的。世界就就这么大，人口就这么多，市场总量也是有限的。如果业务已经达到饱和，还有什么办法可以扩大市场？一个企业如果没有增长是个非常大的问题，如何来刺激业务持续增长成为新的挑战?
1.2.追求个性化用户体验带来新的增长
怎么解决市场增长乏力的问题？答案是追求个性化的体验，因为人的体验有无穷多种。女生都有这样的感受，衣柜里永远都缺那么一件衣服，就是你明天要穿的那一件衣服。我们买衣服并不是买纺织品这个产品，我们买的是穿衣服的体验，或者我们买的就是我有很多衣服的感觉。
硬件和软件的分离就提升了软件的使用体验。以前IBM的邮件软件使用体验不是很好，作为IBM的员工自己也说 Lotus notes 邮件软件使用体验不是很好。这个是没办法的事情，在市场充分竞争的情况下，一个有着优秀硬件基因的公司很难同时把软件做到最好。展开来说，一个公司很难让服务于消费者的终端手机生产与销售业务做得很好；同时也在服务于全球前50的运营商的电信设备市场也做得很好，并且2B和2C同时成功。这样的的成功非常少见，即使是诺基亚做到的也只是暂时的成功。
服务与产品的分离，也提升了使用体验。就是说，做产品但不把这个产品直接卖出去，而只把产品提供的服务租出去。比如亚马逊的云计算，亚马逊拥有这个云计算的平台，但是只以云计算的方式给客户提供服务。对于卖硬件服务器的厂商IBM、戴尔、惠普来说亚马逊卖的服务是不一样的体验，有不一样的体验就带来新的市场。
业务与实现分离，提供了比内部所提供的服务更专业，更便捷。这样就有了IT外包市场，一个企业如果生产一个产品或服务的成本高于采购成本就会采购该产品或服务。只有当自己生产一个产品或服务低于采购成本才会自己生产该产品或服务，甚至向市场提供该产品或服务。
使用与拥有的分离就是共享经济。由于维护一辆自行车比较麻烦（存放，维修，防盗），人们可能不会买一个自行车，但可以通过刷一下手机直接得到自行车交通服务。消费者买的是这种交通服务，把存放，维修，防盗的事情交给共享单车公司。
我们说软件架构来自于建筑的概念，但是软件研发的过程和建筑施工过程有着非常迥异的地方。对于建筑来说，工程师有了图纸后就确定完工后的样子，即使换一个开发商结果也没有明显区别。而对于软件研发过程来说，我更愿意类比原型车的开发。当一个原型车设计完成，到买到这个原型车的量产车型，你会发现它们之间有很大的差别。这就是软件的特点。即使按照软件设白纸黑字签下合同，当拿到软件发布时使用时候，由于技术与业务的不确定性，实际软件与设计阶段差异很大。
总而言之，企业把一部分业务外包出去，满足个性化用户体验，在这个过程中产品/服务价值获得了提升。
1.3.传统行业面临数字化转型的两个挑战
数字化转型对传统企业会带来哪些挑战？以下两点揭示了答案所在：
第一点，从内部看是通过互联网的工具提升内部协作效率。比如说：减少沟通的成本，并进行可视化以及各部门之间的信息共享和协作，提高这种协作的效率。
第二点，如何把握用户需求。这分为两点：首先是精确。在不同场景下人们需要的产品是不一样的。比如：早上起来打开微信我可能看谁更新了什么东西，而晚上可能要看还有什么事情没有做完。一个产品在不同的场景、时间、地点、环境下所需的特性是不同的，这就是需求的准确。其次是准确。其实很多时候为什么我们的客户都不知道自己要什么？因为一般的通用的需求完全被满足了。这是一个生产过剩的时代，你要挖掘客户的需求，通过不断与客户沟通，去了解客户心里说不出的潜在需求，然后通过跟他不断地互动，达到他在那个时间那个场景下相对可以达到的服务。
(二)软件发布的各种坑
本章节主要是介绍一下软件发布过程中各种坑。上图可以简化地去看第一块，即：Codebase。所有的代码和分支都在代码库中。
第一个动作是Build（构建），研发人员工作最终结果是以软件包的形式交付一个可以运行的软件环境。
第二个是Verify（测试），测试人员所有的工作都是在众多可运行的软件中找到达到发布质量的软件。
最后是将软件发布到生产环境中去。
上面各种复杂的分支、构建、和可以测试的环境，下面是研发，测试，和发布，只有达到质量要求才能进入下一个环节。这个过程里面其实有非常多的手动的工作，就导致了在研发过程中很多低效和没有必要的动作，或者不产生价值的动作。怎么去识别，如何避免研发过程中这些复杂的过程不会影响最后的Release（发布）？
那么对于上述过程，我们可以简单的理解为以下三点内容：
1. 软件编译复杂：
• 软件编译第三方依赖关系复杂；
• 多技术栈解决方案复杂性高；
• 多分支并行开发策略复杂；
2. 测试经历软件测试环境类生产境等迁移：
• 测试环境搭建；
• 测试数据准备；
• 界面测试无法自动化；
3. 软件发布过程无法保证不出问题：
• 发布流程与过程时间长；
• 手动或配置过程导致发布失败；
打个比方：原来研发几个月的产品，最后上线的话可能要持续两三天上线（周末发布）。这就像看一个美剧连续剧（研发），我看了一年的连续剧到年底要出一个电影版（发布），在最后的电影版里哪些环节没有做，哪些环节铺垫的不够好，都会在剧场版里发现问题。如此复杂的过程要在短的时间内重现一遍，这就是发布容易出现问题的根源。所以一个版本研发的功能越多，最后部署的风险就越大。发布过程就是把手动的过程全部重新再现一遍，所以非常容易出错。
(三)云原生应用如何发布软件
3.1.Application Pass项目背景与挑战
首先，说一下Application Paas的项目背景。我公司的客户是欧洲的汽车制造企业。其中一部分的IT项目是外包给了供应商，这样就会有很多的问题。因为这个外包做这个项目，那个外包做那个项目；所以不能有效把过往的项目整合起来形成合力。
客户的痛点是，缺乏新技术新平台的运营能力。随着项目的增多，管理成本也会增加，管理一个供应商和管理十个、一百个带来的复杂性差异是巨大的所以成本奇高。在全球上线多个供应商研发的不同销售系统，其运维复杂程度可想而知，同时也很难实现功能的快速开发和上线。
最后就是之前说到转型的最后一个挑战：我们如何掌握最终客户的需求。我怎么和客户互动？我们不是通过人工发放调查问卷，而是要通过平台的方式收集相关信息。这有利于研发出符合多样化的用户需求，并且成本可接受的产品。
3.2.DevOps软件研发实践
对于下DevOps实践来说，其中最主要的实践是要做自动化的部署（降低频繁部署的成本）。首先要建立信任，并提供可见性。运维人员收到一个版本，却不知道是新增的功能还是只是一个补丁。如何能让运维人员安心的部署到生产环境中去呢？通过开放监控给研发人员可以提高修改缺陷的速度的，最后是让大家的上下文一致，让研发和运维工作在同一个上下文中。通过相同的考核指标要求研发与运维人员（比如可用性指标）来达到相互配合相互信任的目的。
然后是文化。首先要尊重工程师的文化，要有责任共担。一些创业的企业主说遇到的最大的问题就是：招聘的研发人员只管开发代码，上线的稳定性和他们无关，这个就没办法玩下去了。最后就是试错，因为没有人可以保证软件转换一个环境就一定好用。我们如何从错误当中学习，或者说可控的失败。在不会造成很大风险的错误当中学习，让我们的软件从长期的角度来看既具备功能快速上线能力又有高可用性，这就是我们最终的目标了。
3.3.部署与功能分离：从项目到平台
本小节主要一下思路：
- 平台部署能力与项目功能的分离。开始我们讲了很多的分离，如软硬件的分离。而现在来说的是部署与功能的分离。比如：CRM软件。为什么不能把软件的部署抽取出通用的部署能力，并通过不断的迭代来升级平台的部署能力呢？满足平台上每一个项目的自动化部署，这样就提升部署的体验。
- 对于研发和运维来说，这种要求的体验是不一样的。因为对于研发来说，要具有应对变化的弹性和适应性。在金融行业里有很多的规则需要满足，流程需要弹性，不能违反红线规则。每个研发的检查点，转到下一个流程规则是什么，都需要要满足。运维在生产环境需要稳定性，又要随时可以上线新功能，对于研发的适应性和运维稳定性要求都需要满足。
3.4.Dev和Ops需要两个PaaS平台
就如上图所示的一样。对于Dev和Ops来说，他们需要两个PaaS平台：Application PaaS平台和Production PaaS平台。一个负责适应性一个负责稳定性。
3.5.Application PaaS架构
从Application PaaS的架构的角度来讲，底层是的资源层对接云计算资源层。在这上面，我们可以构建两层虚拟网络。在研发虚拟网络中的里，我们有Web层和App层，其实就是对Jenkins做封装。在App层有代码管理，自动构建，环境管理，软件包管理，发布管理，部署管理的核心能力工具。
这么多的核心功能，通过Web层的代码流水线与用户互动。核心能力在下面，融合下面的核心能力，通过Web层定制来满足客户的多样化的需求用以实现适应性。为了保证生产环境稳定，需要把研发和运维要分开，前面是研发的PaaS，后面是运维的PaaS。在运维PaaS下面是监控和洞察的核心能力。
3.6.开源技术选型实现
我们公司的客户还有一个需求就是不能被技术绑定；同时还要引入一些多样性，在相同的团队使用不同的工具去完成任务。为了达到这种灵活性，我们可以选择一些开源软件。这就是我们在做这种咨询的时候，会给客户提供的可定制性，也是客户对Thoughtworks的认可的一个原因。
3.7.试验性发布-灰度发布关键环节
首先，说一下灰度发布的定义。它是在从0到1平滑过渡的方式完成软件发布，有点像蓝绿部署，也有点像金丝雀发布，对客户是有筛选的分流机制。最后可以达到让我们在安全的环境下让软件发布的风险在可控的范围内，这样做不能保证不出错，但是会把出错的影响降低到可控范围内，并不会对生产环境的用户造成影响。（灰度发布过程中是有真实用户参与的）
对于灰度发布，有这样的三个环节：
- 应用监控数据；
- 用户分流规则；
- 递进发布策略。
3.7.1.应用监控数据：Kibana应用监控
的监控考量。
首先是功能测试阶段。功能测试阶段提交到生产环境的边缘节点环境，但是没有真实客户上来。这个阶段会监控错误请求的返回。比如我测试阶段有没有反回404这样的错误，没有错误的话我们就进入下一个阶段。
然后是兼容性测试。兼容性测试主要是测试接口是否有正确的返回结果。
最后在性能测试阶段，对比新旧版本的性能延迟数据。如果不存在性能恶化的现象就可以全网上线了。
整个灰度发布过程从功能测试到兼容性测试，再到性能测试，在生产环境下逐步地升级扩大范围的过程，就是来保证在安全可控的前提下来做灰度发布，做到对客户零影响。
3.7.2.用户分流实现：k8s边缘节点（Edge Node）
对于用户分流实现来说，我们要使用K8S边缘节点的能力，用它作为生产环境持续交付的最终环境。有人会问：持续交付直接到生产环境中，那么你真的敢上线吗？上线之后对客户有影响怎么办？解决办法是：我们用前端的负载均衡把边缘节点的用户流量屏蔽掉，不会让真实客户进来。这个实践与之前的类生产环境是不同的，它真的是生产环境的服务器，配置完全一样；但是区别是没有真实客户使用。
通过功能测试，性能测试环境，然后我们来一步步把最新版本升级到全网。首先边缘节点环境用来做自动化功能测试。通过了功测试后，在新版本和旧的版本共存的情况下测试兼容性的问题，最后兼容性没有问题的话，就进入下一步性能测试阶段，直至全网发布
3.7.3.递进发布：Kubernetes滚动升级
最后，本小节从总体解释灰度发布的三个阶段：
- Phase-0 进行功能测试，当发布包通过持续交付测试环境的验证后，部署到生产环境的边缘节点。配置发布包在生产环境下测试是否能正常工作，这是生产环境下安全地做持续交付的方式。
- Phase-1我们来做兼容性的测试，要做数据的隔离。举个失败的例子，某个网站在做生产环境上的测试时，真的产生了购买两百台洗衣机的订单，并且快递员打电话要求收货（收货200台洗衣机，画面太惨不忍睹了）
- 最后是性能没问题了，我就慢慢滚动部署到全网环境了。
总结一下，灰度发布是什么？在生产环境最小范围内没有真实用户流量情况下，验证功能问题（无客户影响实现持续交付）；以及在较小的范围内，验证兼容性和性能问题（少量用户SLA可控）；同时是在控制范围内保障用户体验。那么在验证功能，兼容性和性能之后我们再全网发布。这样就大大降低了风险，提高发布质量。
而以前的传统发布过程是非黑即白的过程。如果功能，兼容性和性能出现问题会直接导致对所有用户造成影响，造成严重的后果。那么通过灰度发布方式把风险控制在可接受的范围内，才是实践落地的可行性方案。
3.8.通过平台能力开放，从单一产品竞争走向生态竞争
下图讲述的是：通过生态，大家的合作来达到整体的价值提升。比如：有做平台的公司，有做平台上特定业务的公司，有去把握这种用户需求销售产品的公司。有了很多最终服务客户的公司之后，反过来平台也不断发展壮大，同时用户的体验也得到了提升。
为什么要有一个平台？现在有很多开源的或商业的技术，但是多的技术能不能为你所用呢？答案是依靠简单的集成是不能满足企业要求的。因为企业有很多的限制条件，我们要把这些限制条件定义成平台的流程和自动化的过程。这样平台构成了引入技术的能力，就是我们的第一个客户挑战。
有一次客户对我说：我们不太担心Thoughtwork的技术顾问解决不了客户的问题，而是担心当顾问完成工作后自己的外包员工技术水平搞不定这些新技术，这才是客户最担心的问题。那么很多客户的普通员工或者外包人员如何掌握新技术呢？答案是通过平台降低新技术推广的难度（平台封装技术细节，通过现有员工熟悉的流程平滑推广新技术）。
总之，通过Application Paas平台，公司内部团队来控制业务的方向；然后，把业务的实现和交付外包给在这个平台上的供应商。这就提升了业务实现和交付的体验。
举一个小团队控制业务方向的例子。一家服装企业”韩都衣舍“，负责设计团队只有三个人，一个负责广告，一个负责设计服装，一个负责后面的与制造平台对接。这个团队如果能设计出爆款的话，一年几百万的奖金就拿到了。当然你要有平台，在制造效率提升的前提下，才能来满足服装市场不断化的多样化的需求，以及用户的精准的需求。
再则，公司存在的意义是什么？公司存在的意义是：如果产品的生产成本低于购买成本那就自己生产；但是，如果采购成本低于制造成本，那就采购，这就是公司存在的意义（一个公司不是什么都要自己做，而是做自己擅长的产品其他的都外包出去）。比如说Kubernetes，我需要对资源进行调度，但是我们不能自己做出一个Kubernetes。因为那是不可能的，这是谷歌擅长的事情，那么我们就外包出去。我们就做最核心的业务，这是公司存在价值；你做的成本一定比别人低，这就是你存在的价值。
这是某国内大型通讯公司公有云实验性发布的方案，在全球大概有二十多个数据中心，它最关键的实践是包管理。而，我们之前讲的都是在一个数据中心的内网发布一个软件。
在全球范围如何实现灰度发布？首先是策略，也许在不同的地域里面业务都是不一样的，那么软件包也是不一样的。这要有更高一个层次的考量，并不是做了灰度发布之后，就可以在一个数据中心或者在所有的数据中心上线。这是需要有一个统一的考量，也是全球化带来的改变。把业务差异从应用逻辑中分离到数据中去，就可以实现应用的全球灰度发布了。
(四)下一站智能运维
最后，在本节让我们畅想一下智能运维的未来。当说到智能的时候，我们谈的到底是什么呢？在丹尼尔•卡内曼的著作《思考快与慢》中提到了一个概念，我们的大脑有快与慢两种作决定的方式。
这两种思考系统：一个是不需要思考的；比如我和一个人交谈，很容易就可以感觉到对方的情感的变化——这是人情感的感知，不需要思考就知道。看电影不需要思考就知道这个电影是不是一个烂电影，这就是人的经验，不需要思考就能快速得出结论的思考系统。目前计算机并不擅长这样思考系统，因为计算机的计算力和成本很难满足这样的系统。
第二种是需要逻辑思考。比如：查看监控数据，找到故障记录，分析原因和关联性，最后解决问题。这个过程非常慢，但非常有效。它的正确率也很高，缺点是这样思考大脑会消耗大量能量。对于人工智能来说第二种思考系统正是计算机所擅长的。我们从第二种思考系统方式以及从数据的计算、数据关联分析、系统的相关性入手解决问题。
这里需要阐述一个问题：牛顿发现了三大定律，通过这三大定律推论得出物质运行的规律。但是，问题在于从科学研发到改变生活的周期和成本都是非常巨大的。就像沃尔玛要规划如何摆放货物就有一个很好的实践，啤酒和尿不湿只要放在一起就能卖得很好。还有像阴天时候甜品和蛋糕就卖得好。对于这些关联性不需要知道科学原理，只要按照这个结果去做就可以提高我们的销售额。那我为什么要知道原理呢？也许当了解了原理之后，就像那个啤酒和尿不湿的销售关联性在中国已经失效了，中国的父亲在买尿不湿的时候不会去购买啤酒。那么，一般情况下，掌握关联性并运用到实际的工作中就能获得收益。
4.1.软件研发流程的数据化和个体在线化
软件在研发过程当中会产生很多的数据，比如需求实现的时长、发布频率、部署前置时间，稳定性，部署成功率、应用错误率等。上图是业务相关的数据，比如性能、用户体验、用户增长、用户满意度，转化率、流失率等。如果我们将上述这些串联起来，比如说有一个客户想花三千万获取新客户，如果性能不好的话，流失率就非常高（提示：页面性能，点击反映速度的数据与转化率相关性是很容易查到的）；但是性能变化提高20%的转化率，那么价值就直接可见了。
4.2.人工智能的作用
软件在开发过程中有三个特点：
1.软件设计的不确定性。我们都知道拿到了软件设计文档并根据这份设计文档来生产的软件并不一定能有效果。因为，现实中进行交付软件时，如果客户说还可以，但是，要求加一个功能，才能通过验收。这不是加一个功能的问题，其实是委婉否定了你前面所有的软件的价值。
2.质量的不可见性。对于软件快速上线来说，如果你加班的话，短时间也能通过测试并上线；但是，短时间的测试没有办法能测到所有的问题。因为一个好的软件是写出来的，短期测试没有办法保证软件的质量。
3.价值的不透明性。对于价值的理解，就要说到我们大脑如何理解做事情的意义，我们生活的改变速度远远超出大脑的进化速度。比如一个原始人，他们做一面镜子的意义就是用来打扮。但是，每天的软件研发工作却无法映射到最终上线上去，那么这就显得没有多少意义。长此以往会对工作失去不断改进的动力。
那么对于上述问题，我们能不能通过人工智能对以往同类项目的过程数据，制定出一条明确的研发过程。使得在研发，测试和发布的工作中，每个人都清楚的感觉到自己的工作对最终的产品起到的意义。那么，这种人工智能数据化的方式就会给我们生活赋予意义，这就是我能想到并且能做的事情。
人工智能从研发和运维过程中收集的大量数据入手，寻找关联性使得工作的过程和结果直接产生联系，从而连接了研发与运维再到业务成功的链条，提升软件研发过程的可预见性，为业务成功打下坚实基础。
原文来自微信公众号：DevOps时代
本文链接：https://www.yunweipai.com/23733.html
网友评论comments