以自动化先行的 DevOps 实践及常见误区

作者介绍 陈正玮，来自中国台湾，中国台湾得宽科技 DevOps 工程师，在中国台湾负责翻译《Effective DevOps》，以及《DevOps 三十六计》简中转繁中，三十六计繁中版预定年底会上市。同时也是中国台湾DevOps社区其中一位组织者，非常期待能够在两岸多做一些技术的交流。

开始我的分享之前我先分享一个段子，大家轻松一下。

我们做工程师的时候非常怕一个问题，就是上面的老板出去开了一个会，参加了一个活动，回来的时候就说“小陈，我听到一个很牛的东西，你快帮我搞一下。”

通常老板如果只是拍你的肩膀还算小事，最怕他还直接跟所有同事说这事就交给小陈负全责，这才叫真正的麻烦。

更惨的是老板还会有一些突发奇想，像是他可能会说，下个季度开始，所有的人的生产效率都要提高好几倍，2倍还是小意思，可能来个10倍、5倍以上，这将是非常恐怖的一件事情。

段子说完了，今天将从这个四个方面开始分享，

1. DevOps 与自动化的误解
2. 自动化的误区
3. 会有两个正面的案例分享
4. 最后就会做一些简单的结语

DevOps 与自动化的误解

我想第一个误解是比较常见的，这个大家应该都知道 DevOps，有些人会把DevOps 跟 CI/CD 化成等号，这是一个错误的想法。

因为事实上这个持续集成早在1999年就出现了。

持续交付也是一样的，这本书 2010 年的时候就出了，所以也不是新的东西。

甚至如今天上午乔梁老师讲的，现在大家在讨论 CI/CD 时，已经进入 2.0了，DevOps 不只是 CI/CD，而是大家应该要对 CI/CD 有新的思维和新的想法，这是第一个常见的误解。

我们简单讲一个案例，曾经听过有老板这么说“你们怎么不快点导入 DevOps 的那个CI/CD？”这是满常见的误解状况，老板觉得这是新的东西，或者觉得里面的东西非常的重要，但是其实不知道工程单位早就已经在做这样的事情了。

还有一个非常常见的，或者是非常糟糕的误解，特别是对我们做工程的人来说，就像前面的段子一样，老板认为 DevOps 只是自动化，只是一种工具，一种解决方案而已。

在这种状况下前面这个段子真的就会出现，而且会非常惨，老板会要求你不只做两倍，而是要五倍或者十倍。他只想看到你的成效，而不会认为 DevOps 不只是一种工具，是影响组织全面的组织变革。

快速讲第三个误解，DevOps 或自动化能不能在短期内产生巨大的成效，其实这个误解的关键在于可能导入的初期会产生快速的成效，但紧接著会遇到一些坑，要越过这些坑才能得到长期的成效。

从三个案例来看这个误解，从自动化的角度来看，工程师会写很多自动化脚本，脚本其实也是一种代码，如果不注重脚本的代码质量，每一个工程师写出来的脚本质量高高低低，这势必会影响整体的效率。

再来架构和开发流程，如果开发流程好像违章建筑一样，接着形成了如同违章建筑模样的自动化流程，你看前面是质量不良的脚本，再加上违章建筑的自动化流程，那么最后就会形成千疮百孔的自动化平台，这将会是很大的问题。

自动化的误区

接著来谈谈自动化的误区。自动化的误区是什么呢？当我们想到导入自动化时，脑中都会想到上面这条一飞冲天的线，但现实状况其实是下面这一条线，会掉入很多坑，中间是非常坎坷非常崎岖的，而且坑可能比你想象的还要多很多。

第一个误区就是缺乏全局观的问题，工程师在做事的时候，特别是在写脚本的时候，遇到的问题是什么呢？他只会看到眼前。

只会优化眼前的工作，不会管其他的部分，这种优化对于整个流程来说优化成效是有限的，所以说工程师需要具备更高的全局观，从瓶颈点开始着手。

因为在非瓶颈点省下的每个小时都是虚幻的。

大家看一下案例，假设将开发流程简化成这样，这时要进行优化，你会先做持续部署，或者是自动化配置管理，或者说跟环境、服务器有关的基础架构即代码（Infrastructure as code），又或者如左下角这里有四种环境需要管理，在这么多环节当中你会从哪一个点要当做开始做改善的起点？

再谈另外一个案例，这来自社区里面的反馈，他们真的做了一些很棒的自动化平台，可以做到每小时部署10次，但他们的研发部门每个月只出一个版本。

所以后面运维自动化可以跑的很快，但前面研发动作很慢，这样的改善对整体生产效率有帮助吗？是没有的，除发他们产品研发迭代速度能提升，不然其实是没有太大益处的。

再谈另外一个案例，这来自社区里面的反馈，他们真的做了一些很棒的自动化平台，可以做到每小时部署10次，但他们的研发部门每个月只出一个版本。

所以后面运维自动化可以跑的很快，但前面研发动作很慢，这样的改善对整体生产效率有帮助吗？是没有的，除发他们产品研发迭代速度能提升，不然其实是没有太大益处的。

开发自动化平台的研发人员原本是为了解决痛点的问题，但这个平台的建立很可能会带来另外的伤害，比如说我刚才讲到技能丧失是其中的一部分。

我们举一个另外的例子，我们努力的想要弥补人为操作时的不可靠性，但却在不知不觉中创造了发生新的错误的机会，而且这个错误甚至可能比我们原本极力避免的更严重。

我们来看一下这个案例，对于工程师来讲，上一次在命令列输入的命令是什么，大家还记得吗？或者是在拥有这个自动化平台之前，我们以前是怎么部署的？

现在有没有办法再重现一遍这个流程，同样的在拥有自动化平台之前，你是如何测试与部署的？

简单来说原本我们的研发或开发人员是拥有一些能力的，一开始不需要运维人员担心的。

但是自从运维人员帮他做了很多智能化的东西之后，研发人员渐渐的很多东西都不会了，只愿意使用自动化平台，甚至连自动化脚本都不愿意使用，也不愿意再去学习这方面的知识，所以丧失去学习这项技能的心态。

误区还有就是丧失灵活性，假设这是一个简单部署的流程，有非常多的环节可能需要思考的，要连上主机，取得打包版本，取得系统组态配置，一些环境初始化的动作，应用程序所需之环境配制，如何重新部署，如何回滚至特定版本，这个步骤可不可以重新部署，这些叠加起来是非常复杂的状况，在做自动化平台的时候，要先做标准化，甚至要先做规范化，标准化规范化之后很多东西都被固定下来了，所以丧失了很多灵活性。

现在来看看这个案例，自动化平台能否兼容遗产与新的项目，自动化平台能否兼容巨石架构跟现在很火的微服务架构，或者这个自动化只能适用新项目，旧项目依然要人工处理，或者这个自动化只能帮你解决新的问题，旧的问题就不管了，这也是我们实际上曾遇到的问题。

第四个误区，就是欠缺维护性和可配制性，简单来说脚本这件事情前面已经提过了，看待脚本要用看待代码的方式看待它，要让它更容易重构、维护。

以谷歌的 SRE 为例子说明，SRE有 50% 的工作时间是做传统运维的工作，但有另外一半时间是做研发工作，不断的在做改善、改进的工作，也就是说为了维护大量的自动化工具或平台，为了维持这个自动化平台的维护性，或者说维持它的可靠性，你必须投入更多的软件工程的能力与编程的时间。

好比当你开始有大量自动化测试的时候，光是维护测试用例这件事情就得花不少力气。所以谷歌对 SRE 这样角色才会有这种工作时间的规划，这是为了对整个工作环境，以及自动化脚本和平台提供持续的维护与改善。

以谷歌对 SRE 这样角色才会有这种工作时间的规划，这是为了对整个工作环境，以及自动化脚本和平台提供持续的维护与改善。

自动化非常需要持续的维护，持续的运维，自动化脚本的质量是什么？前面也提到了，脚本有没有做测试、代码审查和持续部署。

还有误区五，工具决策优先，这是工程师很容易会遇到的状况，太快的陷入工具决策之中，而忽略其他方面。

当你在面临工具和技术选型的时候，你要用哪种呢，要用Jenkins或者是要用 circle CI，这么多选择，工程师往往一碰到这个问题会在一开始就陷入思考，想著我应该选哪一个工具。

给大家举一个实际的案例，场景是这样子的，有一个团队主要的技术使用的是PHP，这个团队非常擅长对接 API 与其他第三方服务，团队正好刚开始采用Ansible。

在这样的情况之下，有三个选项，你会选用阿里云的 SDK-PHP，或者说阿里云SDK-python，还有就是阿里云的 Ansible Module，你会选哪一个呢？

其实我想这个案例并没有什么绝对的标准答案。

这里我先用这句话来呼应一下，“人们并不抵制改变，他们抵制的只是被改变”。表面上刚才的提问看起来是工具与技术选型的问题，但其实你还需要考虑其他方面的问题，像是人们对工具的接受度、工作流程、协同等。

当我们导入 DevOps 或自动化时，这并非只是关于新技术的议题，我们不能单从技术方面来思考这个问题，就像 CI/CD 并非是一种新技术，而是一个需要持续实现以及需要持续改善的实践方法。

我们也可以从敏捷软件开发宣言来看这件事，个体和互动高于流程和工具，工作的软件高于详尽的文档。

工具决策不一定是需要最优先考量的关键，但在导入自动化时，却很容易陷入工具决策优先的状况。

所以为何选择工具A而不是工具B，有时候不只是因为技术选型的缘故。另外的案例就是明明只是两个团队却使用了三种沟通管道或工具，我实在不知道这两个团队到底是要怎么有效沟通，这是一个很恐怖的状况，这也是常见的误区。

案例分享

我给大家说两个简单的案例。

先从一个由技术面切入，后来确实把文化或价值观带入团队当中，来自嵌入式装置行业的案例，状况是这样子的，他们产品我就不介绍了，因为不是跟议题有关系，他们产品的维护期都比较长，产品项目多而复，有非常多的产品线，产品线多而且复杂。

除此之外就是每一个产品线，每一个产品里面都会跑很多的程序，所以每个项目都要有很多程序需要管理，全部加总起来程序总数量多，图片只是简单描绘，实际上面临的问题会更多。

还有就是跟硬件本身有关的问题，硬件的组态配制，还要故障分析或硬件的调整，硬件比起软件来的比较复杂麻烦一点。

总结来说，他们是真的非常需要自动化，像前面这些繁杂的工作，整体的版本分析，打包，打包后还要部署到硬件上面，还要测试，这些流程原本都需要人手工去做，耗的时间非常长。

而他们的落地过程是这样子的，首先挑了其中一个项目开始，从流水线改进，第一个改进和他们构件和配置有关，从建立共用配置库开始，然后从自动化发布入手，之后发布就是统一集中送进构件库。

因为配置也是非常复杂且非常多，因此著手建构了自动化组态配置，之后建立自动化构建测试环境，再进行自动化集成测试。

整个流程就是这样子开始的，一旦有了自动化的系统、流水线完善之后，确保真的能从配置库取得需要的配置，进行自动化然后根据反馈持续改进，包含怎么测试，怎么建构，以及怎么会建构失败。

这落地过程对研发产生了什么影响呢？研发因此修改产品，提升了产品的灵活性和更弹性的配置设计。

简单来说这个案例的成效，首先是交付的总共时长一开始非常长大概超过60分钟，而且这60分钟都要由工程师操作，这是非常夸张的一件事情，自动化之后这整个流程就小于了20分钟。

前置作业时间长，交付总时长其中有30分钟是在做前置作业的，因为没有好的数据库，没有好的管理方式，以及其他一些各种的前置工作。

最后一个就是人工作业时长，原本大于40分钟，自动化以后在效率上提升了很多。

这个案例最重要的就是体现持续改进，自动化成效呈现之后，进一步的影响到了研发的产品设计以及架构设计，形成有这样持续改进的循环。

我们来看第二个案例。

该公司主要是以研发为主力，研发的话语权比较大，另外是公司认为运维或基础建设部门是支撑单位，这案例比较符合常见对于运维单位的看法。

研发部门都做些什么呢？会做小型网站，或者信息系统，或者写一些 API 供第三方使用，除了自己产品之外也帮其他的企业做研发、开发的工作。

在这样的情况下基础建设有什么样的困境呢？同时拥有物理机，虚拟机，路由机，交换机，所以基础建设会遇到机器如何管理的问题。

对研发而言，研发就是不断的根据新的项目需要新的环境、新的服务器，同时因为研发执行的项目类型多种，每种对环境需求都不一样，研发同学常常就会对运维同学说，老板等着看，服务器好了没？运维同学就会说，光是支撑你们，我们都不用做其他工作了。

这案例的落地过程就是先从Iac基础设施即程式码开始，针对基础设施先做一些调整，然后就是全面的虚拟化跟容器化，建立一些标准流程SOP或规范化，并建立一个简单的自动化运维，为什么说是简单的呢？因为它确实不是我们在其他场合听到的非常厉害的自动化平台，只是一个自己架设的 GitLab CI服务。

简单来说利用 GitLab CI提供这个接口，只要去触发这个API，就会自动执行自动化脚本，以自助的方式构建环境，达成半人工、半机器自动构建。更进一步在大家都使用的沟通平台上导入ChatOps让自动化脚本更容易触发。

最后，渐渐开始有人就说大家一起来研究一下怎么样把这个内部使用的自动化平台做的更好。

所以这个是一个蛮奇妙的落地过程，就是从运维开始，运维做了一个简单的平台，但渐渐发现不够用，大家想要更多、更棒的平台，而且不止是运维这边想要，研发那边也想要，最后连研发都一起跳进来说一起来开发一个更好的自动化平台。

看一下落地成效，原本运维在处理外部工单需要蛮多时间，自从有了自动化平台之后，至少减少了30%以上，所以对于运维来说做外部工单时间减少了，时间可以拿来做其他的工作。

还有就是环境构建时长，之前都是大于60分钟，经常会打电话来催促，但是有了自动化之后10分钟就可以搞定了，交付部署时长也是很长时间，大于60分钟，但是有落地完成后变成了30分钟，变得更加的有效率了。

这个案例想要跟大家谈一下因为看见自动化的成效而开始引发的跨部门合作，这也是一种落地的发展方向。

技术和工具，流程，人和文化，跨部门合作必定会有沟通的问题，在这个案例中，假如前面研发并不认同运维建立的简单版自动化平台，那后面一切也都做不成了，包含最后的一起合作研发的内部的自动化运维平台。

建议和结语

自动化这件事，单看这个事是一个老把戏，但老狗也是能变出新把戏的！

我想所有的工程师都是非常喜欢自动化的，工程师都曾幻想着躺在床上就能自动把代码写出来给老板，躺著领薪水。

这是国外一位老先生自己做了一个自动早餐机，非常原始的机械结构，这也是一种自动化。

这是另外一个工程师，就连要玩积木，也不正常的玩，这其实是非常厉害的结构，全自动的，前面会有机器自动把这个球吸附上来，然后送入一个流水线，最后球又会回到起点，不断自动的重复这个流程。

我们应该思考的是什么是自动化，或者刚才说自动化这些事情对你而言是什么，对公司来说是什么，能否帮助我更有生产力，更有效率，自动化能带来什么样的价值这才是重点。

这里快速谈一下自动化的演进，最开始是没有自动化的，都是人工手动操作，后来慢慢工程师个人自行使用和维护，系统特定的自动化脚本、进程、服务，可能只是简单的脚本用来启动某一个程序。

下一步是多人共同使用，大家一起来维护的共用的自动化脚本、进程、服务，能适用于多种情景。

再下一个阶段是半自动的自动化平台，也许是快速搭建的一个半自动的平台，让人可以半自动去触发自动化脚本，好处是有一个集中的管理。最后就是全自动、完全无需人为介入的自动化平台，像有自我修复、自我治愈的这种能力。

我不知道大家对 K8S 熟不熟，其实我一开始看到 K8S 的时候我很期待，因为看见它天生就具备自我治愈的能力，这尤其是工程师会很喜欢的能力，总之终极目标就是达到全自动、无需人为介入的自动化平台。

所以其实可以被自动化的工作很多，但在这么多的工作当中你要选哪一个做自动化，呼应前面讲过的误区，要思考优化哪一个环节才具有价值，有的人会只看眼前的问题，被眼前所看到的东西困住了。

快速回顾一下今天讲的东西，我们有提到三个误解，DevOps 即 CI/CD，DevOps 即自动化，自动化短期内可有巨大的成效。还有误区，就是欠缺全局观的问题，还有就是技能丧失的问题，丧失灵活性的问题，欠缺维护性和可配制性。

做个简单的结语，对应前面讲的东西，从这几个方面给大家一些建议，首先当然是建立全局观，要从瓶颈点着手，消除价值流中的浪费，如果某项优化措施但对于产品没有任何帮助，那它可能就不是最优先要优化的地方。

举个例子，我们最初在整个开发过程当中，最早是从部署阶段开始改进，优化完毕之后接著继续检视下一个瓶颈点是什么并接手继续改进，接著发现自动化测试的时候会遇到一些问题，于是改进了测试环节，接著又发现其实在一开始建立项目的时候其实有非常多的工作是需要手工去慢慢完成设置的，所以我们又要在自动化中修正这一部分，就是这样一步又一步的持续改进最有价值的部份。

还有就是软件工程这一块，运维人员也必须觉得自己是研发单位，现在时代的趋势是所有的东西都是代码，所以尽可能要用这种观念看待你手上被你运维的东西，既然都是代码，那就跟代码一样，要重视维护性和可配制性，当然也要有敏捷开发的观念。

最后要注意架构，重视灵活性，注意标准化与定制化的取舍。还有就是文化，先建立滩头堡逐步前进，不要好高骛远想要一步登天。

因为有些超时了，快速的总结一下，自动化绝对是DevOps落地的重要关键，绝对是可行的，但是自动化落地之后，工具落地之后相对的文化、价值观也必须要跟上，并需要持续的度量、反馈以及持续的改进才行。今天就分享这些内容，谢谢大家。