要的是确切结果，不要忽悠我 前段时间，乔帮主（乔梁，《持续交付2.0》的作者）在持续交付2.0的群里发出这一句话： 业务老大问：“原来100工程师做的一个产品，用半年时间做 devops 改进。半年之后会得到什么确切的结果？” 以上是原话。 乔帮主在群发这话的意思是：如果你的业务老大问这样的问题，你该如何回答？ 请注意，业务老大要的是确切结果，不要拿“虚”的东西来忽悠人。 请读者朋友思考一会。 。 。 。 客官不要急，请再思考一会鸭。 。 。 面对老大这样的提问，技术人可能觉得好笑，接着可能装作一本正经回答老大： 如果DevOps改进半年后，会使单元测试覆盖率提高到 80%。 如果DevOps改进半年后，会使A系统的部署耗时缩短到 1 分钟。 这回答真的很“确切”，但是，还是没有办法说服业务老大。注意，业务老大是不懂技术的。老大听到你的回答，估计一头雾水：什么是单元测试覆盖率？提高到 80% 后，对我的业务 KPI 又有什么关系？ 别笑，这在 IT 行业里是常态。很多时候是不懂技术的老大，却又领导着一批技术人员。 面对这样的“常态”，作为技术人员，我们有必要，也有责任让不懂技术的业务老大理解 IT 行业里必要的“常识”。 回到业务老大的问题，如果你仔细思考，还真不好回答。比如，单元测试覆盖率提高到 80% 后，对我的业务 KPI 又有什么关系？能让我的业务 KPI 提高 80% 吗？ 老翟的做法 当笔者看到这个问题，第一感觉就是：我们必须找到 DevOps 改进措施和业务老大关心的 KPI 之间的关系。换句话说，就是如果在100名工程师做一个产品的团队的情况下，进行 DevOps 改进半年后，会给我的业务 KPI 带来什么确切的结果？ 笔者认为业务老大的问题，可以拆分成两个小问题： 有效性问题：如何证明 DevOps 改进是对业务 KPI 提升是有效的？ 进度问题：怎么评估 DevOps 改进对业务 KPI 提升了多少？ 如何证明 DevOps 改进是对业务 KPI 提升是有效的？ 这就是我说的：我们必须找到 DevOps 改进措施和业务 KPI 之间的关系。 “DevOps 改进措施和业务 KPI 之间的关系”指的是什么？这需要针对不同的业务场景进行举例说明。 ...

餐饮行业里，有些饭店的服务员应聘是需要试工的。就是让应聘者穿上酒店的工作服，然后在工作繁忙时间，工作一段时间。 这段时间里，面试官可以观察到他在点菜时会不会与客人互动，上菜过程中的专业程度等。进而判断要不要录入他。 试工后，基础能回答这人能否胜任当前工作。 当然，“试工”对于招聘起到效果也取决于面试官。这是另一个问题了。 而 IT 行业，如果面试官不问个偏门算法，问个万万亿级流量的处理解决方案，似乎显得自己比面试者差。所以，IT 行业有个笑话：面试造火箭，入职拧螺丝。 我们是不是应该换个方式来招聘程序员？也用“试工”来遴选人才。 据我所知，ThoughtWorks 很多年前就已经采用“试工”的方式招人了。以下是笔者当时的面试经历： 一面是与 HR 简单聊聊。 二面，你必须在规定时间内完成一个家庭作业（需要写代码）。当你把作业交上去，HR 会找到公司内部的程序员帮忙看题（这样有助于缓和HR与程序员的关系，因为HR有求于程序员啊。）。 三面，他们会邀请你到办公室，然后HR找两个程序员和你结对编程（注意：这里是真实的上机写代码），内容就是在你交的作业的基础上加需求。过程中，他们会观察你，会提问你。 其实，整个三面的过程，就是试工的过程。虽然不能拿真实代码来改，但是也尽量模拟真实的工作场景：结对编程、别人对你代码的质疑等。 像 ThoughtWorks 这样试工的，在我们行业里，真的太少了。 回到阿里面试王垠（暂不说是不是受邀面试）这件事。 从赵海平的回复来看： 整个面试最关键的过程恰好是对简历上具体工作的详细了解，这个王垠在博客里完全没有提到，实际上我问了将近二十到三十分钟，我希望王垠能够意识到这部分才是面试真正考核的部分，应该尽量把自己最拿手最出彩的工作分享给面试官，详细解释为什么难，为什么有意义，为什么对公司有着深远的影响，而不是直接问面试官是做什么的，到底懂不懂，很遗憾，我恰好是做编译器的，在Facebook做了PHP编译器，在阿里巴巴领导了团队在Java里加入了透明的协程 从这一段话来看，赵海平花了很长时间问王垠的过去。 赵海平是不是可以让王垠试试解决一下自己所在团队当前遇到的技术问题，又或者让王垠试着重新实现一遍自己骄傲的“透明的协程”？这个过程，我相信是非常兴奋的。 以上两种尝试其实也算是一种试工。能解决团队遇到的问题，能做面试官能做的，应该算是能胜任他所面试的岗位了吧？ 毕竟，是想招这个人来解决问题的。而不是抓住他的过去不放。 再说，有些应聘者可能真的不知道要怎么回答面试中的——真正考核的部分。所以，回答不上来，个人也觉得很正常。因为我也是那样的人。 最后，我疑问，在赵海平的这次面试里，“真正考核的部分”真的比“这个人能否真正解决问题”重要吗？HR 面，我可以理解。 后记 我们都是外人。所以，真正的背后的动机，上下文只有当事人知道。我不想评价他们个人和公司。只想讨论一下“试工”在IT行业的可能性。让更多人知道，招聘程序员，还有另一种姿势。 笔者是从这文章了解到事件的：https://www.ithome.com/0/464/417.htm 笔者的阿里三面经历：https://showme.codes/2018-06-24/alibaba-interview/

最近发现用户都喜欢构建命令最后加上一行：ls -a .。为什么呢？ 是因为他们想知道执行 npm run build 后的目录的结果是什么样的。目录里到底有没有出现期望的文件。 这个功能在 Jenkins 中叫做“工作空间”。其实就是源码在 Jenkins 上下载后的目录。Jenkins 中，用户是可以直接像在查看本地文件夹一样查看这个工作空间的内容。如下图如示。 为什么用户想要看工作空间中的目录结构呢？说到底就是用户本地打包环境和平台打包环境还是有区别的。当出现构建结果不符合预期时，用户需要根据工作空间的信息来找到失败原因。 另，笔者看了行业内的几个平台，没有找到“工作空间”的功能。为什么没有这个功能呢？不知道。 后记 “工作空间”这个特性本身提高了用户在平台上的自检能力。因为平台上的信息对于用户更透明了。那么实现这个功能的成本呢？这是我们在实现前要考虑的问题。

为什么部署后的包还是旧的包？ 有位同学说他在 DevOps 平台部署后，代码还是旧的。 在我跟他确认了构建时拉取的代码是版本是对的，部署时，使用的制品包也是正确的情况下 ，我也是摸不着头脑了。 最后，这位同学在 DevOps 平台的界面上看到了部署的目标机器的IP。 这才找到了真正的原因：他们自己部署的目标机器搞错了。也就是本来想部署到 A 机器，但是部署任务填写的是 B 机器的 IP。然后自己一直在 A 机器上检查部署结果。 接着，这位同学就感叹自己对 DevOps 不熟。 然而，笔者认为，那根本不是用户对 DevOps 熟不熟的问题。而是 DevOps 平台的设计问题。 为什么用户连自己部署错了主机都不知道？笔者认为那是因为目标机器的 IP 信息在界面上不够明显，其他所有的信息就只能通过分析 DevOps 平台提供的日志才能知道了。 所以，我们的平台需要提供这两个功能： 部署清单：列出本次部署的具体内容，可以包括：制品版本，执行人，目标机器列表，部署策略，回滚策略等。 部署结果报告：制品版本，目标机器的部署结果，与上一次部署的差异（这是关键）、多次部署报告的差异性比较功能等。 部署结果报告中必须要强调此次部署与上次部署之间的差异，毕竟大多数应用不会那么频繁的更换部署机器。 后记 “DevOps” 这个概念本身已经把很多人搞得云里雾里。在网上搜索一下 DevOps 的定义就知道了。所以，用户在使用 DevOps 平台时，达不到预期值，就习惯性地认为是自己的问题。我们作为平台设计方，用户达不到预期，那就是平台设计的问题。

一位同学的疑问 有一位同学问我： 你们一个流水线从编译到部署成功需要多少分钟啊。我们快的2分钟，Java 普遍10分钟，开发同学总是觉得慢，我不知道业界是什么水平。 我的回答是： 没有行业标准的，有些项目10万行代码，有些100万行代码，没法比。 后来，我又问他：你们的流水线都包括了哪些阶段？ “编译，带数据库的测序，sonar，docker build，ansible deploy，mvn release”，他回答。 后来的沟通中，我得知，他们流水线时间长发生在两个阶段：带数据库的测试和下载依赖。 下载依赖慢是因为他们每次构建都重新下载依赖，这样做又是因为总是遇到缓存问题，所以，干脆就每次重新下载了。 带数据库的测试通常会慢，因为要启动应用，然后操作数据库，这个数据不确定他是类似 MySQL 这样的真实数据库，还是使用 H2 这样的内存数据库。 出乎我意料的是，他们的 SonarQube 扫描倒是很快。 所以，他们的优化点就是那两个慢的阶段。具体解决办法还要看具体情况，比如带数据库的测试是不是可以通过并行解决、构建时依赖缓存遇到的问题是不是可以通修改构建工具配置来解决。 写到这里，我想表达的是，优化流水线的速度的思路，差不多就是这样：先找到最慢的阶段，然后根据具体情况来优化。 从 DevOps 平台设计角度解决 那么，作为 DevOps 平台，我们能通过什么办法帮助用户提高流水线的速度呢？ 笔者认为，只要将流水线中的每个阶段中的每个步骤的耗时都记录下来，然后显示给用户，用户自然会注意到每次流水线的执行速度差异。当然，管理层也可以对这部分内容进行考核。 同时，要将耗时进行分类，一类是用户步骤的耗时，比如执行mvn package，执行单元测试等，一类是 DevOps 平台本身的耗时，比如初始化构建环境耗时，上传制品耗时等。 为什么要进行这样的分类？是因为 DevOps 平台使用过程中，用户遇到问题，往往是区分不了，是平台的问题，还是自己的问题。这时，我们将平台的信息显示给用户，用户就可以自行判断，自行处理了。这会大大节约平台维护者的时间。而且，平台维护者也可以根据平台运行耗时统计来对平台进行有依有据的优化。这是一箭双雕。 我把这个功能叫做：流水线耗时统计。 那么这个功能，到底应该如何实现？不同的平台有不同的实现，比如基于 Jenkins 的话，在每个步骤后加上一个回调请求就可以了；基于 GitLab 的话，就不了解了。 图来自：https://wiki.jenkins.io/display/JENKINS/Pipeline+Stage+View+Plugin 后记 流水线的速度是一个很重要的指标，它直接显示了一个软件开发团队在工程方面的效率（正确性问题是另一个问题）。而流水线耗时统计功能可以有效地帮助用户提高自己的流水线速度。

同事发了一个前端构建失败的链接过来，接着就是那句：任务执行失败了，麻烦帮忙看看。 DevOps 平台的“老手”了，所以，在找我们解决问题时，都知道附上平台任务的链接。 我们打开链接，第一件事情就是看日志。是的，DevOps 平台的使用者很多都认为：在本地执行构建成功，那么在平台上构建失败就是平台的问题。所以部分人连构建日志都不看，直接把链接发给我们这些平台维护者看。 不出意外，这次又是依赖管理问题。只不过，这次是发生在前端项目上。错误截图下如下： 日志里（画红线部分）已经说得很清楚了。虽然我不清楚“Tristan”是什么，但是可以猜到是他的业务代码报这样的错。但是他本地执行没报错，那通常就是依赖的版本的问题了。 他的前端的依赖定义(package.json)类似以下这样： { ..... "dependencies": { "cookie-parser": "^1.4.3", "debug": "~2.6.9", "express": "^4.16.0", "http-errors": "^1.6.2", "morgan": "~1.9.0", "pug": "2.0.0-beta11" }, ... } 我们看到依赖的版本号的前缀有 ~，有也 ^。这是什么意思呢？ ~: 前缀表示，安装大于指定的这个版本，并且匹配到 x.y.z 中 z 最新的版本。 ^: 前缀在 ^0.y.z 时的表现和 ~0.y.z 是一样的，然而 ^1.y.z 的时候，就会 匹配到 y 和 z 都是最新的版本。 也就是说，每次执行 npm install ，该项目所依赖的内容，都是有可能变的。 这对我来说是不可思议的。为什么？ 因为依赖的版本代表着一个软件的基础。依赖的版本在你不知道的情况下发生变更，就好比建房子，建第一层时，地基是100个平方，建第二层时，地基突然就变成了90个平方。而前端项目中大量这种情况。 你可能会说开源前端node项目都会遵循语义化的版本号，小版本升级不会出问题的。我想说，那只是约定，还是要看那个人遵守不遵守。如果你真相信每个人都遵守，本质上是把软件开发风险的控制权交给了开源软件作者的个人习惯。开发出来的软件注定是不稳定的。 但是，为什么前端项目的依赖的版本号前普遍会加上 ~ 和 ^ 。在我亲自执行 npm install express 命令时，我知道了原因。因为在执行命令后， package.json 文件中就出现了："express": "^4.16.0"。也是 npm 在安装依赖时，默认就给版本号加上 ^ 前缀。而很多人可能改都不会去改。这就导致了文章开头所说的那位同事的问题。 后记 真心希望大家固定下 package.json 中的依赖的版本号。这样的前端项目构建起来才有稳定的基础。 ...

题记：DevOps 平台通常搭建于内网环境，不能直接外网，所以，如果你也要在内网环境构建前端，就一定会遇到本文所说的问题。 我们发现在 DevOps 平台构建前端项目时，会报这以下这样的错误： node scripts/install.js Downloading binary from https://github.com/sass/node-sass/releases/download/v4.9.0/linux-x64-57_binding.node Cannot download “https://github.com/sass/node-sass/releases/download/v4.9.0/linux-x64-57_binding.node”: tunneling socket could not be established, statusCode=500 Hint: If github.com is not accessible in your location try setting a proxy via HTTP_PROXY, e.g. export HTTP_PROXY=http://example.com:1234 or configure npm proxy via npm config set proxy http://example.com:8080 [email protected] postinstall 以上的错误日志的意思是node在安装 node-sass 时，要去 github.com/sass/node-sass 下载一个名为 linux-x64-57_binding.node 的二进制包。然后它无法下载（其实是因为DevOps平台搭建在企业的内网，是无法直接连接外网的），就建议你设置一下系统的HTTP代理，让它能连接到 github.com。 除此之外，错误日志中，还发现了，node-sass 依赖本身的构建，还需要 Python2 环境： gyp verb check python checking for Python executable "python2" in the PATH gyp verb `which` failed Error: not found: python2 对于一个 Java 后端开发人员，看到这样的错误就懵了。心里在想： ...

我在本地跑明明成功的，为什么在你平台跑就报错？ 用户在 Jenkins 上跑构建时，失败了，把日志截图给我看，如下图： 在过去几个月，每个星期都会有一两个 Jenkins 用户就会给我发送类似的错误日志。 这样的日志，我通常回：请检查你们的依赖，是不是有依赖没有上传到咱们的 Nexus 仓库。验证方法是先在本地删除你的 .m2 目录，然后再执行一次构建。 当用户业务开发比较急的时候，他们还会说本文标题中的那句话。有些抱怨的意思。我都已经习惯了。 出现这样的情况，我总结大概会有以下原因： 用户对于 Maven 这类构建工具不熟悉。 用户对于依赖管理不重视，或者没有依赖管理的意识。 用户根本不看日志。 面对这三个原因，我就在思考：我们 DevOps 平台能做些什么呢？ 我觉得 DevOps 平台是不是可以直截了当地告诉用户： xxx 依赖在 Nexus 仓库（maven.abc.com）中没有找到，请您先 deploy 该依赖到 Nexus 仓库后，再执行此任务。 如果能检测到缺少的依赖放在哪个代码仓库就更好了。因为这样，就可以提示用户直接到该代码仓库的 deploy 了。 这样的技术，我称为依赖AI管理技术（笑）。当然，这样的技术，应该可以应用于所有的语言。 同时，我们将这些数据（依赖管理失误）统计起来，就可以看出一个团队在依赖管理方面的能力表现了，进而可以有效的对团队进行培训，以提高相应的能力。 回到本文主题，当用户自行检查依赖后，大多数时候，用户就不会来找我了，因为问题已经解决了。可是有一次，用户还是说不行，他已经把 .m2 删除，并把依赖包上传到 Nexus 仓库了。 我检查了他的 pom.xml 文件，发现版本号的定义也是正确的。可是，放在 Jenkins 上执行时，使用的还是旧版本的类的定义。 这就奇怪了。这种情况还是头一回遇到。来来回回检查了好几次，查了好久才知道，是因为用户 deploy 依赖到 Nexus 时，deploy 的是相同的版本号，就是覆盖了原来的版本的包，但是版本没有升级。而 Maven 检测到本地就该版本的依赖，就不会重新下载了。最后，就是大家看到的，本地可以，但是 Jenkins 上就是不行。 最后的解决方式是： 用户 deploy 一个新的版本到 Nexus 仓库，并在 pom.xml 中使用新的版本。 我们将 Nexus 设置为不允许重复 deploy。 小结 经过这次事件，我们可以看出，依赖管理对于工程质量的重要性。因为，依赖管理不当，很有可能在连开发人员都不知情的情况下引入Bug。 ...

通常我不喜欢写开发环境搭建类文章的，但是见到不少同学在 Ansible 的开发环境花了很多时间。所以，就想写这么一篇文章。希望能帮助到有需要的同学。 在介绍开发环境搭建之前，需要介绍 Ansible 脚本的开发流程。 不像普通的业务系统的开发，只需要打开 IDE 就可以写代码，然后调试了。当然 Ansible 脚本也可以进行单元测试，但是 Ansible 脚本还是需要真实运行并部署，才能验证脚本的正确性。 所以，Ansible 脚本的开发过程通常是这样的： 启动一台虚拟机。 在开发机上编辑 Ansible 脚本。 在开发机上执行 ansible-playbook -i hosts playbook.yml 命令。 通过 Ansible 脚本的开发过程了解到，开发环境的搭建可以分成3部分： 测试机器的准备。 文本编辑器的准备。 Ansible 的安装。 1. 测试机器的准备 见到不少同学使用 Vmware 或 VirtualBox 手工创建虚拟机。这种方式是可以达到搭建测试机器的目的。但是笔者认为这样不够好。因为验证 Ansible 脚本，我们需要频繁创建新的虚拟机。手工创建虚拟机的效率太低。而且不利于版本控制。 所以，测试机器的准备，笔者使用的是 Vagrant。通过它，可以自动化创建和配置虚拟机。当然，整个过程还是版本控制的。 同时需要注意，Vagrant 本身并不是一个虚拟机的实现，它是基于 VirtualBox 和 Vmware 的。换句说就是我们可以通过 Vagrant 去控制 Vmware 和 VirtualBox。所以，在安装 Vagrant 的同时，也需要安装 VirtualBox 或 Vmware。本文使用 VirtualBox。 Vagrant 和 VirtualBox 的具体安装在本文末有官方教程。 2. Vagrant 介绍 Vagrant 本身只是一个软件，提供了 vagrant 命令。我们通过一个名为 Vagrantfile 的文件声明启动什么配置的虚拟机。 ...

在设计 DevOps 平台时，笔者认为版本号的管理是一个绕不开的课题。可是，行业里似乎很少人提这个事，笔者觉得要谈一谈，所以就有了这篇文章。 一万个人的眼里有一万个“版本号” 笔者这三年在同一家公司里，换岗换了四个团队。团队的成员组成各异，有的团队都是在大型跨国企业跳槽过来的，有的团队大部人都是刚毕业的。 每到一个团队，团队运行一段时间，都会做一件事情：讨论该怎么定义这个版本号。版本号的制定，有些只有开发人员参与，有时会有产品经理参与，有时还有 PMO 参与。 经过这些讨论，我发现：一万人的眼里有一万个“版本号”。讨论的最后，基本上就是谁的嗓子大，听谁的。 所以，在讨论“版本号”之前，一定要搞清楚讨论各方对于“版本号”的理解，再深入讨论，否则，大家谈的都会是牛头不对马嘴的东西。浪费时间。 为什么对于“版本号”，各方的理解，差异会如此大。笔者认为，主要是因为他们关心的面不同。 APP产品经理关心的是该APP在用户界面上显示的版本号，比如当前爱彼迎的APP的版本号是：1.9.44.china。 对于后端开发工程师，关心的是网关服务的版本是1.2.1、客服服务的版本是4.11.1。 对于前端开发工程师，关心的是通用组件的版本是2.1.1、首页组件的版本是3.1.1。 而对于 PMO，他们可能只关心在 Staging 环境的最后一个版本是否为一个稳定的版本（这写在他们的管理规范里），保证不影响测试人员的工作，根本不关心具体的“版本号”是多少。 重新认识版本号 各方的关注点不同，不是问题，但是我们作为一个平台的设计必须对“版本号”有更深入的理解。 笔者分析各方的关注点，他们所说的“版本号”分布在以下两个层面： 技术层面：程序员关心线上跑的是哪份代码（对应的是Git\SVN中的Commit ID）、运维关心线上跑是哪个版本（对应的就是具体哪个包）。 业务层面：方便终端用户识别的版本号，产品经理也属于这一层面。 认识到这点，我们设计DevOps平台，就会对两种版本号进行区别对待，进而设计出对团队非常有用的功能，最终帮助团队更好的实现交付。 为方便沟通，技术层面的版本号，如 Commit ID 我们称为技术版本号，业务层面的版本号，称为业务版本号。 版本号相关功能设计 但是版本号有什么用？仔细想想，除了产品经理发布时要定个版，后端服务的版本用于保证服务之间的相互引用或调用不出问题，就没有什么别的用处了。 也许是因为大家都不了解版本号的用处，也或者是认为它根本就不值得讨论，所以，笔者在国内的几个大的平台都没有看到版本号的相关功能的设计。唯一使用到版本号的地方就是在制品库，部署时需要指定制品的版本号。而业务版本号与技术号之间的关系被隐藏得很深，用户很难查到。 笔者不想一开始就谈它的好处。我直接上功能，下图是笔者臆想出来的。 笔者认为，DevOps 平台应该有的功能之一：能输出这么一幅图，暂定名为版本关系图。图中的方块下，同时标有业务版本号和技术版本号。而图中的系统之间的连接线是应用系统的调用链，读者可忽略。 版本关系图应该能提供以下信息： 系统应用之间的版本依赖。 系统内部所依赖的组件的版本。 能根据某系统的版本查到目前直接依赖于或间接依赖于它的其他系统。 各系统的版本变迁信息。 这些信息能给用户带来的价值如下： 团队内信息更透明，沟通效率更高，可以有效避免某个员工成为单点。你不必等其他成员，自己也可以得到整个系统的版本信息。 可以提高团队成员的排错能力，因为当A发布新版本后，APP 首页打开变慢，有了版本关系，我们可以首根据整个平台的“版本事件”来排查问题。同时，团队也很快可以找到相应的代码变更，然后进行 review 及修复。 上图中，当 A 服务是一个集群时，我们还可以将部署的目标机器与版本号关联起来了。这样，团队就可以轻松的知道，哪台机器部署了哪个版本。 上图只是整个业务系统的某个时间点的“快照”。事实上，我们还可以在版本号上做更大的文章。比如让技术版本号与代码质量、构建速度等过程指标关联起来，这样我们可以在不同的版本之间进行对比。再比如计算两个业务版本号之间，代码质量的差异，长期积累下来这些数据后，我们就有能力计算出代码质量与业务指标之间的关系。 总的来说，版本号就是整个研发流程中的各项指标数据的枢纽。 后记 版本号和其它数据的关系的价值，笔者认为被大大低估了。希望本文能给 DevOps 平台设计者带来不一样的想法。