审校：王冬辉，linuxsuren Jenkins master 的高可用是个老大难的问题。和很多人一样，笔者也想过两个 Jenkins master 共享同一个 JENKINS_HOME 的方案。了解 Jenkins 原理的人，都会觉得这个方案不可行。但是真的不可行吗？ 由于工作原因，笔者需要亲自验证以上猜想。 JENKINS_HOME 介绍 Jenkins 所有状态数据都存放文件系统的目录中，这个目录被称为 JENKINS_HOME 目录。 实验环境介绍 笔者通过 Docker compose 启动两个独立的 Jenkins master，分别为 jenkins-a 和 jenkins-b。它们共用同一个 JENKINS_HOME 目录。相应的代码仓库的链接放在文章底部。 将代码克隆到本地后，进入仓库，执行 docker-compose up -d 即可启动实验环境。启动完成，在浏览器中输入 http://localhost:7088 可访问 jenkins-a，jenkins-b 的地址是 http://localhost:7089 。但是你会发现它们启动后的界面显示是不一样的。 jenkins-b 的界面如下图所示： 而 jenkins-a 的界面如下图所示： 这时，将 jenkins-a 日志中的解锁密码（Unlock password）输入到 jenkins-b 的页面中，会得到报错信息： ERROR: The password entered is incorrect, please check the file for the correct password 这时，再次 jenkins-b 日志中的解锁密码（Unlock password）输入到表单中即可进入下一步。接下来就是按照提示一步步完成了。在 jenkins-b 安装步骤的最后一步，我们设置了管理员的用户名密码：admin/admin。然后就算完成任务了。 ...

本文假设读者已经了解 Jenkins 基本概念及插件安装，Zabbix 基础概念。基于 Zabbix 3.4，Jenkins 2.8 做实验 笔者最近的工作涉及到使用 Zabbix 监控 Jenkins。在谷歌上搜索到的文章非常少，能操作的就更少了。所以决定写一篇文章介绍如何使用 Zabbix 监控 Jenkins。 下图为整体架构图： 整体并不复杂，大体步骤如下： 在 Jenkins 上安装 Metrics 插件，使 Jenkins 暴露 metrics api。 配置 Zabbix server 及 agent 以实现监控及告警 为方便读者实验，笔者将自己做实验的代码上传到了 GitHub，链接在文章末尾。使用的是 Docker Compose 技术（方便一次性启动所有的系统）。 接下来，我们详细介绍 Metrics插件及如何实现 Zabbix 监控 Jenkins。 1. 使 Jenkins 暴露 metrics api 安装 Metrics 插件，在系统配置中，会多出“Metrics”的配置，如下图： 配置项不复杂。我们需要点击“Generate…”生成一个 Access Key（生成后，记得要保存）。这个 Key 用于身份校验，后面我们会用到。 保存后，我们在浏览器中输入URL：http://localhost:8080/metrics/<刚生成的 Access Key> 验证 Jenkins 是否已经暴露 metrics。如果看到如下图，就说明可以进行下一步了。 1.1 Metrics 插件介绍 Metrics 插件是基于 dropwizard/metrics 实现。它通过4个接口暴露指标数据：/metrics，/ping，/threads，/healthcheck。 ...

审校：LinuxSuRen（https://github.com/LinuxSuRen） Gerrit 是一个基于 Git 版本控制的基于 Web 的代码审查工具 。笔者在学习它的过程中发现，要使用好它，第一步就是要理解 Change-Id。 理解 Change-Id 要理解 Gerrit 的 Change-Id，我们就必须对“一次代码审查任务”有一个定义。通常，我们认为对一次完整的功能实现或 Bug 修复（即一次完整的变更）进行代码审查是合理的。而对一个半成品进行代码审查，得到的结论是不可靠的。因此，一次代码审查任务意味着是对一次变更进行审查。 Gerrit 使用 Change-Id 来标识一次变更。Change-Id 实际上就是一串字符串，类似这样：Ic8aaa0728a43936cd4c6e1ed590e01ba8f0fbf5b 但是，一次变更通常会伴随多次 Git 提交（Commit），而且每次提交的提交是不同的 Commit Id（提交Id）。Gerrit 如何将多次提交关联到同一个 Change-Id 呢？ 我们需要在每次提交时，将 Change-Id 以规定的格式放在提交消息（Commit message）的Footer 部分中（最后一行）。如下图： Change-Id 为避免与提交 Id 冲突，通常以大写字母I为前缀。但是，我们怎么才能方便生成 Change-Id 呢？ 使用 Git 钩子生成 Change-Id Change-Id 最好是自动生成，并放到提交消息指定位置，这样才能节约开发者的时间。Gerrit 提供了标准的“commit-msg”钩子来实现。 Git 提供了4个提交工作流钩子：pre-commit、prepare-commit-msg、commit-msg、post-commit。其中 commit-msg 钩子，会在我们执行 git commit 时被执行。 本质上，commit-msg 钩子是一段脚本程序，放在 .git/hooks 目录下。commit-msg 脚本可以使用 Shell、Ruby、Python 等语言实现。 Gerrit 的 commit-msg 钩子直接从 Gerrit 下载： ...

面向读者：需要了解 Jenkins 流水线的基本语法。 Electron 是由 Github 开发，用 HTML，CSS 和 JavaScript 来构建跨平台桌面应用程序的一个开源库。 本文将介绍 Electron 桌面应用的流水线的设计。 但是如何介绍呢？倒是个大问题。笔者尝试直接贴代码，在代码注释中讲解。这是一次尝试，希望得到你的反馈。 完整代码 pipeline { // 我们决定每一个阶段指定 agent，所以， // 流水线的 agent 设置为 none，这样不会占用 agent agent none // 指定整条流水线的环境变量 environment { APP_VERSION = "" APP_NAME = "electron-webpack-quick-start" } stages { stage("生成版本号"){ agent {label "linux" } steps{ script{ APP_VERSION = generateVersion("1.0.0") echo "version is ${APP_VERSION}" }} } stage('并行构建') { // 快速失败，只要其中一个平台构建失败， // 整次构建算失败 failFast true // parallel 闭包内的阶段将并行执行 parallel { stage('Windows平台下构建') { agent {label "windows && nodejs" } steps { echo "${APP_VERSION}" } } stage('Linux平台下构建') { agent {label "linux && nodejs" } // 不同平台可能存在不同的环境变量 // environment 支持阶段级的环境变量 environment{ SUFFIX = "tar.xz" APP_PLATFORM = "linux" ARTIFACT_PATH = "dist/${APP_NAME}-${APP_PLATFORM}-${APP_VERSION}.${SUFFIX}" } steps { script{ // Jenkins nodejs 插件提供的 nodejs 包装器 // 包装器内可以执行 npm 命令。 // nodejs10.15.2 是在 Jenkins 的全局工具配置中添加的 NodeJS 安装器 nodejs(nodeJSInstallationName: 'nodejs10.15.2') { // 执行具体的构建命令 sh "npm install yarn" sh "yarn version --new-version ${APP_VERSION}" sh "yarn install" sh "yarn dist --linux deb ${SUFFIX}" // 上传制品 uploadArtifact("${APP_NAME}", "${APP_VERSION}", "${ARTIFACT_PATH}") }}} // 将括号合并是为了让代码看起来紧凑，提升阅读体验。下同。 } stage('Mac平台下构建') { agent {label "mac && nodejs" } stages { stage('mac 下阶段1') { steps { echo "staging 1" } } stage('mac 下阶段2') { steps { echo "staging 2" } } } } } } stage("其它阶段，读者可根据情况自行添加"){ agent {label "linux"} steps{ echo "发布" } } } post { always { cleanWs() } } // 清理工作空间 } def generateVersion(def ver){ def gitCommitId = env.GIT_COMMIT.take(7) return "${ver}-${gitCommitId}.${env.BUILD_NUMBER}" } def uploadArtifact(def appName, def appVersion, def artifactPath){ echo "根据参数将制品上传到制品库中，待测试" } 代码补充说明 因为 Electron 是跨平台的，我们需要将构建过程分别放到 Windows、Linux、Mac 各平台下执行。所以，不同平台的构建任务需要执行在不同的 agent 上。我们通过在 stage 内定义 agent 实现。如在“Mac平台下构建”的阶段中，agent {label "mac && nodejs" } 指定了只有 label 同时包括了 mac 和 nodejs 的 agent 才能执行构建。 ...

注意，下文所说的“老板”通常指业务提出方。 问题描述 上个星期，在持续交付2.0的群中，群主发出一个别人的提问。在我看来，这个问题在软件工程领域非常的典型，所以想单独写一篇博客来讨论。以下是问题原文： 我是一个开发部门的管理人员，团队规模还较小，开发需要兼任测试和部分应用运维的工作，但公司业务条线不算少（差不多有4个左右，目前部门中基本是按每个条线分配2-3个开发，出现某个组资源不足以满足需求时再进行调剂），之前这么做还算稳定，因为各业务对交付频率的要求一般很低，但近期各业务都提出了一个较紧急的项目需求，而且都还无法推迟或拒绝，资源一下子变得非常紧张（如果可以推迟某一个当然就会有富裕资源，但是这些项目由于各种原因公司都不能放弃，也很难推迟），如果依然每个组独立完成自己的项目，可能导致大部分项目因无法按时交付失败，而且每个组还必须保留少部分资源用于处理日常业务，如果临时招聘也来不及做培训，我们暂时是让资深一些的程序员和管理人员参与多个项目中的开发，但仍不能完全解决问题（他们抱怨任务太多都来不及测试），请问帮主遇到这类情况应该如何协调？ 提问者所说的情况，在现实中，太普遍了： （无法拒绝的）紧急需求的插入，打乱原有的步骤 开发除了需求的开发，还需要处理日常业务 人员不足：临时招聘也解决不了 开发人员报怨任务太多，来不及测试（就上线？） 项目无法按时交付 可以看出，“人员不足”是“项目无法按时交付”这个“果”的其中一个“因”。而提问者希望通过业务线之间人员的调剂和临时招聘的方式增加人员，但仍不能完全解决问题。笔者每当听到增加人员的信息，都会想起《人月神话》所说的：向进度落后的项目中增加人手，只会使进度更加落后。 而从提问者口中也了解到，原来人员还算足（感觉是刚刚好），只是因为出现了一个无法拒绝的紧急需求，问题就暴露出来了。 问题解决 面对这样的问题？你是如何解决的呢？以下是我个人提出来的解法，不一定对，只做交流： 第1是把当前工作的优先级排出来 把所有的工作内容（包括日常维护和新功能实现）列出来，同时，也要找到这些工作的交集（避免重复开发）。工作内容列出来后，确定它们的业务价值及优先级，并预估其开发难度。有些新功能是老板直接下发的，但是实现难度过高且业务价值又不高（团队及产品经理觉得），能和老板谈就和老板谈。这部分工作是我觉得最难的。 这个工作的优先级一定要让老板看到。主要是避免老板中间随意的插入需求。当然，有时需要向现实妥协，但不是每次。同时也要让所有人达成共识，遵守这个优先级。 第2是找出团队平时工作中最耗时的环节（瓶颈），想办法在这个环节上减少耗时（自动化或者别的办法）。一般来说，经常工作在这个耗时环节的人会知道如何优化它。 第3是慢慢让人可以流动 意思是人没办法调剂到其它项目，通常是因为他不了解其它项目（业务或者技术）。所以，在平时，就要注意将项目的“知识”尽可能准确地传递给更多人。当然，也可以定向的传递。具体操作方式要看团队平时的协作方式。 最后，1，2，3步需要重复执行，同时1，2，3步也不是顺序的。 笔者提出这样的解法并不是笔者猜的，而是有依据的。依据如下： 人员不足只是表象，我们怎么知道是真的人员不足，还是没有真正发挥每个人的最大潜能呢？第2、3步是为了让每个人发挥最大的潜能。而工具方面，个人建议通过看板可视化人员的工作内容，来达到了解当前资源状态的目的。 即使每个人的潜能都发挥到了极致，但是还是出现人员不足的情况啊。这就是第1步要解决的问题。这时，我们要学会舍弃。但是为什么老板就不会舍弃，老爱插入一些所谓的紧急需求呢？个人认为是因为老板不了解你当前的工作内容及其优先级。所以，这个优先级一定要和老板达成共识。 小结 当我把解法提出来了，群里的同学就提出了质疑：如何确定老板提出新功能是业务价值不高的？毕竟老板从整个公司考虑问题的。 这位同学提出了一个软件工程领域内经常发生的问题：执行者怀疑业务提出者提出的需求的价值。个人觉得质疑是好事。但是质疑之后，双方有没有讨论及讨论结果才是关键。讨论了就容易形成共识，有了共识，大家才好力往一处使。题外话，“我只要结果，不管过程”的管理理念的适用范围是拿出来讨论的。 最后，以上解法，不一定适用所有的情况。比如在外包项目管理中，可能就不适合。

通过脚本命令行批量修改Jenkins任务 最近，笔者所在团队的 Jenkins 所在的服务器经常报硬盘空间不足。经查发现很多任务没有设置“丢弃旧的构建”。通知所有的团队检查自己的 Jenkins 任务有没有设置丢弃旧的构建，有些不现实。 一开始想到的是使用 Jenkins 的 API 来实现批量修改所有的 Jenkins 任务。笔者对这个解决方案不满意，经 Google 发现有同学和我遇到了同样的问题。他使用的更“技巧”的方式：在 Jenkins 脚本命令行中，通过执行 Groovy 代码操作 Jenkins 任务。 总的来说，就两步： 进入菜单：系统管理 –> 脚本命令行 在输入框中，粘贴如下代码： import jenkins.model.Jenkins import hudson.model.Job import jenkins.model.BuildDiscarderProperty import hudson.tasks.LogRotator // 遍历所有的任务 Jenkins.instance.allItems(Job).each { job -> if ( job.isBuildable() && job.supportsLogRotator() && job.getProperty(BuildDiscarderProperty) == null) { println " \"${job.fullDisplayName}\" 处理中" job.addProperty(new BuildDiscarderProperty(new LogRotator (2, 10, 2, 10))) println "$job.name 已更新" } } return; /** LogRotator构造参数分别为： daysToKeep: If not -1, history is only kept up to this days. numToKeep: If not -1, only this number of build logs are kept. artifactDaysToKeep: If not -1 nor null, artifacts are only kept up to this days. artifactNumToKeep: If not -1 nor null, only this number of builds have their artifacts kept. **/ 脚本命令行介绍 脚本命令行（Jenkins Script Console），它是 Jenkins 的一个特性，允许你在 Jenkins master 和 Jenkins agent 的运行时环境执行任意的 Groovy 脚本。这意味着，我们可以在脚本命令行中做任何的事情，包括关闭 Jenkins，执行操作系统命令 rm -rf /（所以不能使用 root 用户运行 Jenkins agent）等危险操作。 ...

李翔商业内参 9月15日（中秋）那期的主题是：最好的礼物是一个真诚的建议。我深表认同。 两年前，我被另一个资深的同事说了一通（当时我们正结对编程）。原因是我说了另一个同事的代码写得烂，还随手看了下提交记录，发现是当时的leader。 先不说这位同事教训得是不是。我心里很不爽：我说的就是真话嘛。 后来，我发邮件给总经理，说了一通，诚恳地向他请教，到底是谁的错。后来总经理给我回了一封邮件，邮件其中一段是这样的： 有个有意思的故事： 弟子问：”师父您有时候打人、骂人；有时候对人又彬彬有礼，这里面有什么玄机吗？” 师父说：对待上等人直指人心，可打可骂，以真面目待他；对待中等人最多隐喻他，要讲分寸，他受不起打骂；对待下等人要面带微笑，双手合十，他很脆弱、装不下太多指责和训斥，他只配用世俗的礼节 我想说的不是谁是上等人，谁不是，而是受众不一样，说话的方法就会不一样。 中国有句老话，世事洞明皆学问，人情练达即文章。能够把意见说的让人接受是个技能，要不断练习，你自己也多揣摩。 到底是谁的问题不重要， 严于律己，宽以待人对你的职业生涯会很有帮助。 每每对别人过于苛刻时，我都会想起“严于律己，宽以待人”。虽然，有时还会偶尔犯贱。但是它的确改变了我。 …不小心翻出自己2016年写的小短文。

你对你6年跳5次有什么感想？ 上周进行了阿里三面。奇怪的是他们居然迟到10来分钟。上来直接问的都是我职业生涯的问题（不清楚面试官的岗位）。 从我第一份工作到最近的工作，一个个问入职时间，做了什么，离职时间，为什么离职。我也“老实”一一回复。这个过程，加上视频的网络质量不好，我感觉好像被压着说话。 最后，面试官问我：你对你6年跳5次是什么感想？（后来算算我应该是毕业6年，工作7年。而5次是指包括这次跳成功） 听到这个问题，我一下懵了。我从来没有仔细想过这个问题，想了一下，说出了自己的内心的声音：太年轻，太冲动。 面试官没有说下去。后来草草的结束了20多分钟的面试。 结束后，我问自己：你为什么在别人眼里就是不稳定？HR 眼里跳槽“多”就是不稳定？ 回想自己的回答，的确给别人不稳定的感觉。因为一次主要是因为对 leader 不爽，一次是因为办公室政治干不过别人。所以，各位提前想好自己跳槽的“借口”很重要。 但是，另一个问题开始不断萦绕自己：你为什么跳这么多次槽？回想自己的每次跳槽，没有答案。于是，我反过来想：公司如何才能留住我？ 第一家创业公司7人，我的导师走了，我唯一留在这家公司的理由都没有了。 第二家公司做开源软件，Leader 换成了我不喜欢的人。现在想想真幼稚。现在想想，真没必要。 第三家公司是一家咨询+外包的公司，做了一年多的外包，发现自己想做自己的产品，我留在公司的理由是有产品给我做，询问当时的办公室负责人，并没有产品可以做。 第四家公司是做产品了，组织构架的调整我不满意，产品不再是我，细节不方便说，我就想好好做产品，留下来的理由也没有了。 目前这家公司，进来的初衷是从零建设一个敏捷的团队，后来希望破灭。然后我的希望变成能好好写代码。目前留下来的理由是好好磨炼自己的技术。但有机会会看。因为这里是 code is cheap。 企业应该如何留住员工 我尝试把“我”的私人问题扩大到组织上思考：企业应该如何留住员工？ 最近看的《红雀》的台词跳了出来： 给了别人想要的，你就会得到你想要的。 留住员工，靠的不是“留”，而是“给”。当然，前提是这个人值得留。 这时，会有读者想到马斯洛需求层次理论： 这个理论告诉我们如何满足一个人的不同层次的需求。但是，站在公司层面，如何操作呢？毕竟公司里会同时存在不同层次需求的人，而且同一个人不同时期的需求还可能千差万别。 如何能满足所有人的需求（至少是大部分）？我想到了一句话：海纳百川，有容乃大。但是不可能路边随随便便就收纳，而是能帮助公司实现目标的人。这是海纳百川的前提。 所以，公司应该像大海，能满足不同的人不同时期的需求。这是什么意思？ 生理需求上，提供上行业内比较有竞争力的薪资，像奈飞。安全需求上，比如提供团体险；社交需求上，让工程师之间有更多的交流的机会，比如谷歌为促进员工的非正式交流，在食堂排队，一般要4分钟。因为时间长了大家会掏出手机来看，时间短了，同事们又聊不起来……等等。 P.S. 公司文化并不是没有理论的发展，而是要根据公司的发展需要进行调整。 我再次强调，上述想法的前提：不可能路边随随便便就收纳，而是能帮助公司实现目标的人。所以，要严进。 同时，上述想法是理想情况，处于企业生命周期不同阶段的公司需要根据自己的具体情况量力而行。 同时，我也提醒读者啊：我没有办过企业，上述想法都个人臆想。 教训 给那些还在路上的新人，不要冲动，不要冲动，不要冲动。不要学我。我是反例。 成本 最后，突然想到，好奇阿里为什么不让HR 先把这些稳定性问题在一面给问了？就可以节约一二面的工程师的时间了。毕竟工程师的时间永远相对 HR 的时间更缺。招工程师比招 HR 更难，如果我没有理解错的话。 小结 听说30到35岁是大多数人职场的转折点。我相信了。想清自己想要的，是做好职业规划的前提。

提示：本文要求读者有一定的 Ansible 使用经验 最近一年才有机会在生产环境上使用 Ansible。用的过程中，想把一些小技巧记录下来，避免自己忘记。如果能帮助到其他同学就更好了。如果有同学指出有更好的方法，就更更好了。 技巧1：校验你的模板文件是否正确 通常我们会使用template module 来生成应用的配置，比如生成 Nginx 的配置或者 sudoers 配置。而像 sudoers 文件内的配置错误可能直接导致无法登录。所以，我们希望在生成这些配置文件后能校验一下它的正确性。如果校验失败，直接停止，不生成该配置文件。 而 template module 有一个属性 validate 就是为了实现这一需求的： - template: src: "user-sudoers" dest: "/etc/sudoers.d/abc" validate: visudo -cf %s 校验 Nginx 配置文件的文件： - name: Copy the nginx file template: src: nginx.conf.j2 dest: /etc/nginx/nginx.conf validate: "/usr/sbin/nginx -t -c %s" notify: - restart nginx 校验 Prometheus 配置文件： - name: Copy Prometheus config template: src: prometheus.yml.j2 dest: "/etc/prometheus.yml" validate: "promtool check config %s" notify: reload prometheus config 校验 Logstash 配置文件： ...

注：本文要求读者对Ansible和 Jenkins有一定的认识。 题记: 幸福的家庭都是相似的 不幸的家庭各有各的不幸 行业内各巨头的自动化运维架构都各种功能各种酷炫，如下图，让人可望不可及。现在最终的样子大家都知道了，但问题是如何根据自己团队当前的情况一步步向那个目标演进？ 笔者所在团队，三个半开发，要维护几十台云机器，部署了十来个应用，这些应用90%都是遗留系统。应用系统的编译打包基本在程序员自己的电脑上。分支管理也清一色的 dev 分支开发，测试通过后，再合并到 master 分支。生产环境的应用配置要登录上具体的机器看才知道，更不用说配置中心及配置版本化了。 对了，连基本的机器级别的基础监控都没有。 我平时的工作是 50% 业务开发，50% 运维。面对这么多问题，我就想啊，如何在低成本情况下实现自动化运维。本文就是总结我在这方面一些经验和实践。希望对读者有帮助。 别说话，先上监控和告警 事情有轻重缓急，监控和告警是我觉得一开始就要做的，即使业务开发被拖慢。只有知道了当前的情况，你才好做下一步计划。 现在市面上监控系统很多：Zabbix、Open-Falcon、Prometheus。最终作者选择了 Prometheus。因为： 它是拉模式的 它方便使用文本方式来配置，有利于配置版本化 插件太多了，想要监控什么，基本都会有现成的 以上三者，我基本都要重新学，我为什么不学一个 Google SRE 书上推荐的呢？ 之前我们已经介绍过，人少机器多，所以，安装 Prometheus 的过程也必须要自动化，同时版本化。笔者使用的是 Ansible + Git 实现。最终样子如下： 这里需要简单介绍一下： Prometheus Server 负责监控数据收集和存储 Prometheus Alert manager 负责根据告警规则进行告警，可集成很多告警通道 node-exporter 的作用就是从机器读取指标，然后暴露一个 http 服务，Prometheus 就是从这个服务中收集监控指标。当然 Prometheus 官方还有各种各样的 exporter。 使用 Ansible 作为部署工具的一个好处是太多现成的 role 了，安装Prometheus 时，我使用的是现成的：prometheus-ansble 有了监控数据后，我们就可以对数据进行可视化，Grafana 和 Prometheus 集成得非常好，所以，我们又部署了 Grafana: 在 Grafana 上查看 nodex-exporter 收集的数据的效果图大概如下： 可是，我们不可能24小时盯着屏幕看CPU负载有没有超吧？这时候就要上告警了，Promehtues 默认集成了 N 多告警渠道。可惜没有集成钉钉。但也没有关系，有好心的同学开源了钉钉集成 Prometheus 告警的组件：prometheus-webhook-dingtalk。接着，我们告警也上了： ...