研发效率破局之道08 | DevOps、SRE的共性:应用全栈思路打通开发和运维

你好,我是葛俊。今天,我来跟你聊一聊 DevOps 和 SRE。DevOps 和 SRE,尤其是 DevOps,是最近几年软件研发方法的重要趋势。因为它们都跟打通开发和运维流程相关,所以常常被混淆。比如,SRE 等同于 Google 的 DevOps、SRE 是升级版的 DevOps,就是两个常见的误区。事实上,DevOps 和 SRE 虽然关系紧密,但差别还是蛮大的。所以今天,我首先会通过 DevOps 和 SRE 的对比,引出它们背后的 Why、How 和 What(也就是它们的目标、原则和具体实践)。然后,我会结合自己在一个创业公司的经验,向你推荐如何在团队落地 DevOps。DevOps 和 SRE 的定义和异同因为 DevOps 和 SRE 都是比较新的概念,而且在不断地发展变化,所以学术界和工业界对它们的定义并未达成一致。

研发效率破局之道07 | 分支管理:Facebook的策略,适合我的团队吗?

你好,我是葛俊。今天,我来跟你聊聊研发过程中的 Git 代码分⽀管理和发布策略。 在前⾯两篇⽂章中,我们讨论了持续开发、持续集成和持续部署的整个上线流程。这条流⽔线针对的是分⽀,因此代码的分⽀管理便是基础。能否找到适合⾃ ⼰团队的分⽀管理策略,就是决定代码质量,以及发布顺畅的⼀个重要因素。 Facebook 有⼏千名开发⼈员同时⼯作在⼀个⼤代码仓,每天会有⼀两千个代码提交⼊仓 ,但仍能顺利地进⾏开发,并发布⾼质量的产品。平⼼⽽论, Facebook 的⼯程⽔平的确很⾼,与他们的分⽀管理息息相关。 所以在今天这篇⽂章中,我会先与你详细介绍 Facebook 的分⽀管理策略,以及背后的原因;然后,与你介绍其他的常⻅分⽀管理策略;最后,向你推荐如 何选择适合⾃⼰的分⽀策略。 Facebook 的分⽀管理和发布策略 Facebook 的分⽀管理策略,是⼀种基于主⼲的开发⽅式,也叫作 Trunk-based。在这种⽅式中,⽤于开发的⻓期分⽀只有⼀个,⽽⽤于发布的分⽀可以有 多个。 ⾸先,我们先看看这个⻓期存在的开发分⽀。

研发效率破局之道06 | 代码入库到产品上线:Facebook如何使用CI/CD满足业务要求?

你好,我是葛俊。 在上⼀篇⽂章中,我和你分享了代码⼊库前的流程优化,即持续开发。今天,我会继续与你介绍流程优化中,代码⼊库和⼊库后的 3 种持续⼯程⽅法,即持 续集成(Continuous Integration, CI)、持续交付(Continuous Delivery, CD)和持续部署(Continuous Deployment, CD)。 在接下来的分享中,⾸先我会与你介绍这 3 种⽅法的定义和作⽤,帮助你深⼊理解这 3 个“持续”背后的原理和原则;然后我会以 Facebook 为参考,给你介 绍基于这些原则的具体⼯程实践。我希望,这些内容能够帮助你⽤好这三个“持续”⽅法,提⾼团队的研发效能。 ⾸先,我先来介绍⼀下,持续集成、持续交付和持续部署是⽤来解决什么问题的,也就是它们的定义和作⽤。 3 个“持续”的定义和作⽤ 不知道你是否还记得,在开篇词中,我提到过⼀个低效能的情况,即产品发布上线时出现⼤量提交、合并,导致最后时刻出现很多问题。这个情况很常⻅,引 起了很多⽤户的共鸣。产⽣这个问题最主要原因是,代码合并太晚。这⾥,我再与你详细解释⼀下原因。

研发效率破局之道05 | 代码入库前:Facebook如何让开发人员聚焦于开发?

你好,我是葛俊。今天,我将与你分享优化流程中,代码⼊库前的开发流程。 代码⼊库之前的开发活动,主要包括编码、调测调优、静态检查、⾃动化测试、代码审查等。这是开发者编写代码的步骤,⾃然是提⾼研发效能的关键环节。 图 1 本地开发流⽔线 提⾼开发者编写代码的效能,关键在于让开发者不受阻塞、不受不必要的⼲扰,从⽽全身⼼地聚焦在产品开发上。我把这种不受阻塞的开发状态叫作持续开发。 ⼀个团队如果能够做到持续开发,那么它的有效产出⾃然会很好。⽽对于个⼈开发者⽽⾔,持续开发能够帮助我们把精⼒集中在技术本身,对技术和个⼈能⼒ 的提升都⼤有裨益,所以是⼀种很好的开发体验。 在我看来,持续开发的基本原则主要包括两条: 1. 规范化、⾃动化核⼼步骤; 2. 快速反馈,增量开发。 接下来,我们就⼀起看看这两条核⼼原则吧。 规范化、⾃动化核⼼步骤 要让开发者聚焦于开发,就必须把研发流程中可以⾃动化的步骤尽量⾃动化。因为⼀般不可能完成所有步骤的⾃动化,所以我推荐的⽅式是:分析关键路径上 的活动,以及耗时较⻓的活动,然后投⼊精⼒优化这些步骤。 ⾸先,我们需要明确具体的开发步骤有哪些。

研发效率破局之道04 | 流程优化:怎样才能让敏捷、精益真正为我所用?

你好,我是葛俊。今天我们来聊聊怎样从流程⽅⾯来提⾼研发效能。 从这⼀篇⽂章开始,我们就正式进⼊研发流程模块了。在第 1 篇⽂章中,我与你强调了软件开发的最⼤特点在于它是⼀条⾮常灵活的流⽔线,因此提⾼研发效 能的第⼀步就是优化流程。 图 1 提⾼研发效能的第⼀步就是优化流程 因为优化流程会涉及⽅法论,所以我会先和你介绍⾼效实践⽅法论的关键要素。然后,我会按照⽬标、原则和实践 3 个层次,从抽象到具体,给你逐步讲解 如何优化流程。 需要说明的是,在这⼀篇⽂章中,我不会与你⼤量讨论实践细节,⽽是把这些内容放在了后续的⽂章中。 如何实践⽅法论? 其实,在研发流程上,最不缺的就是⽅法论,从敏捷到精益再到看板,层出不穷。但,实施效果却不理想。尤其是敏捷,⽆论在硅⾕还是在国内,绝⼤部分使 ⽤敏捷的团队实施得都不理想,导致这个概念的争议很⼤,Scrum 有时甚⾄成了贬义词。 相⽐之下,像 Facebook、Google 等⾼效能公司,并没有强调使⽤ Scrum、看板等⼯具,研发效能却很⾼。

研发效率破局之道02 | 效果不好甚至有副作用,怎么回事?

你好,我是葛俊。今天,我来和你聊聊研发效能的度量。 在和技术管理者,尤其是⾼层管理者聊起研发效能的时候,常常提起效能的度量这个话题。管理学⼤师彼得 · 德鲁克(Peter Drucker)曾经说过,“⼀个事 物,你如果⽆法度量它,就⽆法管理它”(If you can’t measure it, you can’t manage it)。要想提⾼研发效能,⾃然要⾸先解决效能的度量的问题。 在软件研发过程中,数据驱动的⼿段被⼤量采⽤,⽐如说通过使⽤漏⽃指标和 A/B 测试,⽤数据来指导产品的⽅向。按理说,软件开发⾏业是数据驱动的⾼ ⼿,⽤数据驱动来理解研发效能应该早被研究透了啊。 但事实上,效能的度量却是⼀个出了名的难题,⾄今没有哪个公司敢号称已经找到了效能度量的完美答案。不仅如此,绝⼤部分软件公司在使⽤研发效能度量 这个⼯具时,不但没有起到正向作⽤,还伤害了产出和团队氛围。 所以,在今天这篇⽂章中,我就与你⼀起看看研发效能度量到底是什么、常⻅错误,以及度量困难的原因。 研发效能度量的定义和作⽤ ⾸先,我来介绍⼀下效能度量的定义和作⽤。

研发效率破局之道01 | 如何系统地理解研发效能?

你好,我是葛俊。今天,我来和你聊聊什么是研发效能,以及研发效能的模型,这些内容是理解整个专栏的基础。 今年的 3 ⽉ 26 ⽇,⼀位昵称为 996icu 的⽤户,在 GitHub 上创建了 996.ICU 项⽬,⾃此 996 这个话题被推上了⻛⼝浪尖。⽬前,这个项⽬已经拿到了 24 万多颗星。朋友们也常常问我:硅⾕的公司有没有 996? 其实,在硅⾕,很少有公司要求 996。不过,在初创公司,因为业务紧张、同事间的竞争,加班也很常⻅。但是,硅⾕和国内的公司有⼀个很⼤的区别,就 是硅⾕的公司⼀般是任务驱动,只要完成任务就⾏,不管你花了多少时间。⽽国内很多实⾏ 996 的公司不仅仅是要求完成任务,更强调⼯作时⻓。但其实, 专注时⻓的这种操作在软件开发⾏业是不合理的,因为⻓期加班不能保证持续的⾼效产出。 从我以及身边许多开发者的经验来看,每天能够⾼效地产出代码五六个⼩时,已经相当不错了。短期突击加班会有效果,但如果⻓期加班,通常效率、质量会 下降,产⽣了 Bug 就要花费更多的精⼒去修复。如果这些 Bug 发布到了⽤户⼿上,损失就会更⼤,得不偿失。 ⻓期加班还会出现⽆效加班的结果。

研发效率破局之道开篇词 | 为什么你要关注研发效能?

你好,我是葛俊,曾在 Facebook 内部⼯具组⼯作,与两个同事共同负责软件研发⼯具套件 Phabricator 的开发和开源,是Phabricator的主要作者之⼀。最近这⼗年,国内互联⽹产业的发展速度不亚于硅⾕,在商业模式创新⽅⾯甚⾄已经完成超越,但是我们在研发效能⽅⾯始终⽐较落后。今年年初爆发的 996 ⼤讨论,让国内的加班问题,吸引了国内外开发者的关注。我们很难予以否认,在互联⽹⾏业繁荣发展的背景下,国内很多公司采⽤了“拼⼯时”的做 法,却忽略了最最应该关注的研发效能。 现在,我想请你回忆下,你是否也曾为下⾯这些问题感到困扰呢?1. 研发团队看起来⼈也不少,⼤家也很⾟苦,加班也不少了,但是产品发布还是常常延期,上线后产品问题频发。 2. ⽤户需求从需求分析、产品设计、开发、测试最终流到部署,但最终发布的产品与⽤户需求偏差却很⼤。 3. 产品发布上线时出现⼤量提交、合并,导致最后时刻出现很多问题,团队成员集体熬夜加班,却将⼤把的时间花在了等待环境、等待验证上。 4. 开发提测质量不好,⼤量压⼒聚集到测试这⼀步,导致代码返⼯率很⾼。引⼊单元测试、代码审查,效果却都不明显。

研发效率破局之道03 | 如何选对指标与方法,真正提升效能?

你好,我是葛俊。今天,我来和你聊聊如何正确使⽤效能度量。 在上⼀篇⽂章,我给你介绍了效能度量的定义、作⽤,以及⼏个使⽤误区。我们先简单回顾⼀下: 软件系统异常复杂,度量指标⽆法覆盖其所有参数,从⽽容易被“数字游戏”欺骗。 竖井指标的提⾼不等于全局指标的提⾼,局部优化不等于全局优化。 研发效能度量指标⼀般⽤来衡量软件产品的⽣产过程和产品质量,但公司真正需要关注的是能否产⽣⽤户价值。这两者之间存在着难以跨越的鸿沟。 正是因为这种种看似难以解决的问题,业界甚⾄有⼈认为研发效能的度量是⼀个⽆解的问题。但我并不这样认为。如果使⽤得当,效能度量可以给公司的研发 带来⾮常⼤的好处。 举⼀个真实的例⼦。国内⼀个⼤概 20 ⼈的研发团队,研发流程混乱,产品发布经常推迟,但是⼤家都不清楚问题出在哪⼉。于是,团队负责⼈决定引⼊数据 驱动开发:项⽬经理正式跟踪研发过程中每部分的耗时,并在功能发布后复盘。复盘时⼤家发现,整个研发过程耗时分布如下:  开发耗时 1 周; 联调耗时 1 周; 测试、发布耗时 1 周。 ⼤家⼀致认为联调耗时⼀周,是最需要优化的地⽅。