敏捷大会 II DevOps的工程化(上)

孙敬云 --Worktile高级系统架构师，WTC成员

1.研发的困境

互联网的环境

互联网这个环境比较特别，包括现在不只是互联网，就算是被互联网赋能的这些“互联网+”的企业也在改变，用户在发生变化，用户构成的群体在发生变化，群体造成场景的变化，场景营造新需求，需求养成新用户习惯，新用户习惯造就一批新用户，周而复始。我们一直在追赶用户，但从用户的角度来说，他一直都期望有一个好的产品和一个稳定的服务。相信在座各位既是技术从业者也是普通的用户，大家会发现自己总是想尝试一些新的东西和好的东西。

软件交付的困境

进度不可控： 我们的研发团队会面临一个问题，一些传统的行业也好，或者现在在实行Sprnit的团队也好，你会发现研发 进度非常不可控 。你有时候感觉一切都很可控，完成任务的时候前80%也觉得没问题，一定能交付。但一旦到了后20%，测试报出海量的bug，运维问你怎么部署？好多东西还没有定，越来越忙。尤其是上线的晚上，一定要搞一个通宵才能把所有的问题解决。这种复杂的困境是技术不可控的;

流程不可靠： 我们公司总是有各式各样的流程发生，但你会发现这个流程走着走着总是需要有一些 关键角色 蹦出来，必须有一些企业大牛或团队经理站出来说这个事情应该怎样做，或者说今天谁谁没来，这个流程没法往下做。

环境不稳定： 线上怎么就出问题了？测试环境好好的，本地就没问题，是不是因为线上没有按照我说的做？环境这个问题在哪个公司都会遇到。

沟通不顺利：研发同学跟运维同学在争论，研发同学说上线之后跑脚本，运维跑完了上线出了问题。研发同学就问他“你跑脚本了吗？”他说“跑了”，“是部署前跑的还是部署后跑的？”他说“你没有跟我说这个。”这就是沟通不顺畅，这个本来是可以避免的。

我们需要一种工程手法，让软件在很短的周期内稳定部署上线。 关键词是 “很短” 和 “稳定” ，甚至一键部署到任何版本任何环境中，甚至这些操作都在可视化的环境进行。我们在研发团队中说，凡是要定目标做计划，怎么办？我们今天每个人给自己定一个目标： 从今天开始每个团队一天部署三次 。大家觉得不可能，安排计划Sprint两天就够呛了，怎么可能一天上线三次？

举一个真实的例子

汇丰银行在2014年的时候全年release24次，这个数字相当于 两周有一个 release的版本，很高效。但是2018年全年release12000次，这是什么概念？你今天一天release 几十 次，大家觉得这不可能，开发代码能写完吗？这就是一种思维方式的转变。

如果我们今天说一定要达成这个目标，不管可能不可能，给我一个执行方案和参考的借鉴点。

概念的组合

我们把这个事情分为四个步骤：

第一步 ，自动化的流水线，这是稳定可重复使用的。
第二步 ，支持构建流水线所需要的技术平台和工具。
第三步 ，运行这些平台完成流水线所需要的人和角色。
第四步 ，支持能够把这些所有东西全部落地并有稳定持续改善方案的文化与规则。

2.DevOps是什么？

DevOps在维基百科上的定义

DevOps是一种重视软件开发人员和IT运维技术人员之间沟通合作的文化、运动或惯例，透过自动化软件交付和架构变更的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

所以前面所有的都是定语，只有最后一句最关键，就是 ：频繁可靠的发布软件，这就是我们的终极目标。

针对刚才定义的原始阐述，从这个环形图上的工作方式，一直在持续演进，好像看起来没有什么特别的，这个神奇点在哪？

如果你跟别人说你今天看了一篇分享是DevOps，或者你去搜DevOps，会发现所包含的含义和相关的含义特别多，包括 精益思想、自动化、持续集成、持续部署、价值流、三步工作法、持续交付、分级部署、敏捷思想、敏捷开发、团队合作 。

在我看来这是大家对于美好事物的一种期望，期望DevOps能承担更多。即使我们今天不提DevOps这个词，把敏捷这个词说出来，你也会说敏捷包含这些部分，换个词也是这样。我认为我们 千万不要陷入于这个词的含义是什么 ，我是想谈 工程化 ，谈 工程化背后美好的东西 。

“持续交付”和“DevOps”

我们挑两个特别容易被网上的人或大家所对比的词汇，一个是 持续交付 ，一个是 DevOps 。

持续交付也好，DevOps也好，他们的共同点是秉持交付思想，他们都崇尚精益思想，他们都喜欢自动化，他们都以快速和稳定的变更为目标，这是两个共同点。持续交付偏向于将不同的过程集中起来，并且更快更频繁地执行这个过程。

虽然我们对比了这两个词，但我希望大家不要过度陷入于概念本身，不是说我今天学的究竟是DevOps还是持续交付，这个没有意义。我们要把好的思想带回项目组，带回团队，能不能落地是我们的关注点，我们不要过多对比概念。

基础参与人

凡是涉及人的话题，一定是比较特别的，你只要不把人的范围说清楚，这个事情就别想落地。只要你没说这个事情让他做，他就不会主动问你，如果你主动问你说明这个人是优秀员工。

把敏捷开发单独四个字列出来，持续部署跟持续交付看似范围一样，但持续交付指的是我有交付能力，但我没说一定要部署到线上环境。持续部署讲的是现在既然已经完成了构建的流水线，那么就从头走到尾就结束了，这个讲的是自动化。DevOps讲的是什么？范围好像一模一样，但 DevOps不强调每一个角色应该干什么，而是将所有的角色汇集在一起 ，有点像敏捷思想里面的 角色互换 ，大家谁都能干这个事情，不用指定这个事情，大家可以角色互换一起来做，所以 DevOps不强调每一个人谁是谁，而是强调这些人汇集到一起之后，你能够将开发编译测试一次性完成 ，这是他们的区别点。

未完，下期继续
to be continue......