以自动化先行的DevOps落地实践经验

luna

作者： 陈正玮 台湾得宽科技DevOps工程师

作者介绍

陈正玮，来自台湾，台湾得宽科技DevOps工程师，在台湾负责翻译《DevOps 三十六计》，这本书年底会上市。同时也是台湾社区其中一位组织者，非常期待能够在两岸多做一些基础的交流。

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

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

通常老板如果只是拍你的肩膀还不够，还要跟所有人说小陈要负责所有的东西。

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

目录

今天要从这个四个方面开始讲，DevOps与自动化的误解，自动化的误区，会有两个正面的案例分享，最后就会做一些简单的结语。

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

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

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

今天上午乔梁老师讲的，大家都在讨论CI/CD2.0，大家要有新的思维和新的想法，这是第一个常见的误解。

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

还有一个非常常见的，或者是非常糟糕的误解，特别是对我们做工程的人来说，因为会发生前面的案例，自动化只是一种工具而已，一种解决方案，前面这个段子真的就会出现，而且会非常惨，老板会要求你不只做两倍，而是要五倍或者十倍，只要看到你的成效，不会认为是全面的。

快速讲第三个误解，DevOps能不能在短期内产生巨大的成效，其实这个误解可能初期会产生这个快速的成效，会遇到一些坑，越过这些坑才能得到长效。

从三个案例来看，从自动化的角度来看，工程师会写很多脚本，脚本其实也是一种，如果不注重产品的品质，每一个工程师写出来的脚本是不可以的，势必会影响效率。如果架构和开发流程，开发流程好像违章建筑一样，违章建筑的自动化流程，如果前面是不良的脚本，和违章建筑的自动化流程，那么就会有千疮百孔的自动化，会是很大的问题。

②自动化的误区

自动化的误区是什么呢？我们在想到导入自动化，都会想到上面这条线，现实状况就是下面这一条就会掉入很多坑，中间是非常坎坷非常崎岖的，坑可能比你想象的还要多很多。

第一个误区就是缺乏全局观的问题，工程师在做事的时候，特别是在写脚本的东西，遇到的问题是什么呢？他只会看到眼前，只会优化眼前的工作，不会管其他的部分，对于整个流程来说优化效果是有限的，所以说具备需要更高的全局观，从瓶颈点开始着手。

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

大家看一下案例，开发流程简化成这样的话你要做持续部署，或者是要从整个智能化的角度来看，或者说跟技术、设备有关的，有四种环境要做管理，或者是说开发人员要测试环境，在这么多环节当中你会从哪一个点要当做开始做改善的起点，先从持续的部署这一层开始，对我们而言我们要管理环境，治理是非常痛苦的，所以要从该点作为起点。

这也是另外一个案例，社区里面的反馈，我们真的做了一些很棒的自动化平台，这可以做到每小时部署10次，我们每个月只出一个版本，后面跑的很快，前面很慢，这样对生产效率有帮助吗？是没有的，如果迭代速度提升的话，其实是没有太大利益的。

还有就是技能丧失，是从工程师的角度来看这个事情，高度自动化会导致的状况是什么，员工会丧失所原有的专业技能，像金鱼一样，有些十几分钟就忘了，自动化有可能产生这样的结果。

开发自动化控制系统的设计人员是为了解决痛点的问题，这个平台建立的时候可能会带来另外的伤害，比如说我刚才讲到技能丧失也是其中的一部分，或许举一个另外的例子，努力弥补人为执行时的不可靠性，却在不知不觉中创造了新的错误的机会，这个错误甚至可能比他们原本极力避免的更严重。

我们来看一下这个案例，对于工程师来讲，上一次在命令列输入的命令是什么，大家还记得吗？或者是在这个平台我们是怎么部署的？现在有没有办法再来一遍这个流程，在拥有自动化平台之前，你是如何测试与部署的，简单来说我们原本的研发或者开发人员是有一些能力的，一开始不需要运维的人担心的，但是自从运维人帮他做了很多智能化的东西，他发现很多东西都不会了，还说别用脚本了，不晓得或者也不愿意再去做这样的事情了，所以丧失去学习这样技能的心态。

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

现在来看看这个案例，自动化平台能否兼容遗产与新的项目，有时候当你标准化的时候你的架构要重新做一些调整，像很多人这样，可能我的老项目不适合了，你的平台是不是同时能够兼容这个架构，或者这个自动化只能帮你解决新的问题，旧的问题就不管了，这也是实际上我们遇到的问题。

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

有50%的工作时间是在传统运维的工作，还有另外一半时间是在不断的研发工作，不断的在做改善、改进的工作，也就是说这样的有大量自动化的工具或者说平台，为了维持这个自动化的平台的维护性，或者说使用可靠性，必须投入更多的管理过程中的能力或者是管理开发的时间，当你开始有大量自动化测试的时候，光是维护这件事情好像就得花不少力气，如何聪明的做这件事，对这样角色的定义要有分配，对整个工作的环境以及脚本的平台有持续帮助的这样的分配规划。

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

还有误区五，工具决策优先的事情，这是工程师也会遇到的状况，当你在面临工具和技术选型的时候，你要用哪种呢，要用jenkins或者是要用circleci，这么多选择，工程师一开始就要去思考，我应该学哪一个工具。

给大家举一个实际的案例，场景是这样子的，有一个团队主要的技术使用的是PHP，这个团队非常擅长对接API与其他第三方服务，刚开始会采用Ansible，在这样的情况之下，有三个选项，你会选用阿里云的SDK-PHP，或者说阿里云SDK-python，还有就是阿里云的Ansible Module，你会选哪一个呢？会选绿色的这个PHP的举个手，有一些，中间的呢？最后一个，我想这个没有太大的标准答案。

我用这句话来呼应一下，“人们并不抵制改变，他们抵制的只是被改变”。

并非新技术，我们不能单技术的单面思考这个问题，这是一个需要持续实现的以及需要改善的实践方法。

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

为何选择工作A而不是工具B，另外就是两个团队三种沟通管理或者工具，两个团队三种活动工具，我也不知道这两个团队到底是要怎么沟通，如果大家不在一个频道上这是一个很恐怖的状况，这是常见的误区。

③案例分享
我给大家说几个简单的案例。

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

下一个状况就是每一个产品线，每一个程序里面都会跑很多的程序，所以每个命题每个项目都要有很多程序，加起来程序总数量多，实际上面临的问题会更多。还有就是跟硬件本身的问题，硬件组态配制，还要分析或者是调整如何复杂，比较麻烦一点。

最后来一个总结，是真的非常需要自动化，像前面这些繁杂的工作，整体的版本分析，打包，还要送件硬件上面，还要测试，这些流程都需要人的手工去做，耗的时间非常长。落地过程是这样子的，从研发开始，首先挑了其中一个项目从流水线来看，第一个是他们构件和配置有关，从配置库开始，然后从发布入手，到发布就是统一集中，配置也是非常复杂而且非常多的，自动化组态配置，之后自动化构建进行测试环境，再进行自动化整合测试，整个流程就是这样子开始的。一旦有自动化你的系统、流水线完善之后，要确保真的是从配置库取得需要的配置，进行介入，包含了怎么测试，怎么结构，怎么失败，然后再重新反馈或者来修正。

对研发产生了什么影响呢？提升产品的灵活性和更弹性的配置文件设计

简单来说一个案例，首先是交付的总共时长一开始非常大概超过60分钟，而且60分钟要有工程师在做，非常慌张的一件事情，自动化之后这整个流程就小于了20分钟，更正或者验证之后自动化就会更好，也需要10-20分钟左右，但是至少比原本的60分钟要好。前置作业时间长，其中有30分钟是在做前置作业的，没有好的数据库，没有好的管理方式，还要做一些各种前置工作。最后一个就是人工作业时长，大于40分钟，版本测试出什么问题，没有问题的话就通过，自动化以后在效率上提升了很多。这个案例最重要的就是体现持续改进，自动化成效呈现之后，包含进一步的产品设计以及架构设计，所以有这样持续改进的循环。

我们来看第二个案例，

主要是以研发为主力，话语权都比较大，另外其是会有运维或者是基础建设，所以比较符合常见的运维单位这样的概念，研发可以做些什么呢？可以做小型网站，或者信息系统，或者写一些API在使用，除了自己产品之外也帮其他的企业做研发、开发的工作。在这样的情况下基础研发有什么样的困境呢？有物理机，有虚拟机，有路由机，交换机，通常如果自己也会先用虚拟机，所以基础建设会遇到这样的问题，机器如何管理。

所以对研发而言，就是不断的需要新的项目，新的环境、新的服务器，研发出来项目的类型多种，每种对环境需求都不一样，这样的话研发同学就会说，老板等着看服务器好了没，运维同学就会说不用做其他工作了，百分之两百都在做运维的工作。

落地的过程就是Iac基础设施即程式码，基础设施做一些调整，然后就是全面的虚拟化跟容器化，建立一些标准的流程SOP或者规范化的工作，自动化成立简单的自动化运维，为什么说简单呢？并不是说在其他场合听到的非常厉害的，另外如果你经常使用自动化的方式，进行维护和方式进行使用。简单来说提供这个接口，所以只要去在触动API，执行自动化的脚本，自助构建环境，半人工，半机器自己来构建。大家都用同一个沟通平台ChatOps试着来用聊天的平台来进行沟通，有的人可能就会说找来一个更好的，大家一起来研究一下怎么样把内部做的更好，所以这个是一个蛮奇妙的，就是从运维开始，运维做了一个发现不够，想要更多、更棒的，不止是研发这边，运维那边也需要。

看一下落地成效，运维外部工单需要的时间蛮多的，自从有了自动化平台之后，至少减少了30%以上，所以对于运维的时间可以减少，可以做其他的工作。还有就是环境构建时长，之前都是大于60分钟，经常会打电话来催促，但是有了自动化之后10分钟就可以搞定了，交付部署时长也是很长时间，大于60分钟，但是有落地完成后变成了30分钟，变得更加的有效了。

这个案例想要跟大家谈一下自动化成效开始引发的跨部门，这也是一个发展的方向，技术和工作，流程，人和文化，跨部门合作的话要有沟通的问题，假设前面研发不认同这个平台的话也是做不成的，同时这里包含的是研发的运维平台。

④建议和结语
自动化这件事，单看这个事是一个老把戏，

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

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

这是另外一个工程师要玩积木，不会好好的玩，但这其实是非常厉害的结构，前面会有机器自动把这个球吸附上来，然后就会回到这里，重复这个流程。

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

自动化的演进，刚开始是没有自动化的，都是人工手动操作，后来慢慢工程师个人自行进行使用和维护，系统特定的自动化脚本、进程、服务，或者是简单的启动某一个程序，多人共同使用，大家一起来维护，通用自动化脚本、进程、服务，适用于多种情景，下一个阶段是半自动的自动化平台，快速的搭建了一个半自动的平台，怎么去触发自动化脚本，好处是有一个集中的管理，最后就是全自动、完全无需人为介入的自动化平台，像有自我修复、自我治愈的这种。

我不知道大家对K8S熟不熟，其实我一开始看到K8S的时候我很期待，因为这是一个典型治愈的能力，这是非常喜爱的，尤其是工程师都会很喜欢这样的，如果我写的东西在维护产品，能够自动修复，总之终极目标就是达到全自动、无需人为介入的自动化平台。其实可以被自动化的工作很多，在这么多的工作当中你要选哪一个，有的人只看眼前的问题，被眼前所看到的东西困住了。

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

还有简单的结语，对应前面讲的东西，从这几个面给大家一些建议，首先当然是建立全局观，要从瓶颈点着手，消除价值流中的浪费，对于产品没有帮助可能不是最优先的事情，从整个开发过程当中，最早是从部署阶段开始，我们才能看到下一个瓶颈是什么，自动化测试的时候会遇到一些问题，我们会试着做一些测试，其实一开始建立项目的时候里面有非常多的工作，手工去完成这些设置的话会很慢，所以我们要在自动化中慢慢修正。

还有就是软件工程这一块，有些运维他们可能觉得我是研发单位，现在时代的趋势是所有的东西都是代码或者是程序码，所以尽可能要用这样子的观念看待你手上被你运维的东西，既然都是代码就跟代码一样，重视维护性和可配制性，当然要有敏捷、开发的观念。最后要注意管理开发的架构，重视灵活性，标准化与定制化的取舍。还有就是文化，建立滩头堡，不要好高骛远。

自动化绝对是DevOps落地的重要关键，绝对是可行的，但是自动化落地之后，工具落地之后相对的文化、价值观也要跟上，也是需要持续的度量、反馈以及持续的改进，今天就分享这些，谢谢大家。