DevOps 中遇到的不靠谱荒唐事

今天发生了一件大事特拉斯辞任英国首相，我想借着这件事情说下我看到的一件研发效能的荒唐事，这其中的关联也许就是「都用了不靠谱的人」。

两件事情

今儿一早就听到，2022年10月20日英国第78任首相伊丽莎白·特拉斯宣布辞职。特拉斯上任后任命她的「密友克沃滕」出任财政部长推出「迷你预算」结果引来英国金融大震荡，英镑对美元汇率跌幅达3%，股市和英国国债均大幅下挫。最后架不住投资者、保守党和民意，辞去英国保守党党首职务，自动卸任英国首相职务，任职45天，也是英国历史上任期最短的首相。

迷你预算这事干的真不靠谱，一发出来股市、汇市、国债齐跌。具体原因大家可以自行搜索，总之这就是不靠谱的人不专业的人才能捅出来的大窟窿，但凡有点花生米也不至于如此。我做研发效能这么多年，也见过一件只有不靠谱的研发效能团队才能干出的事。

这件事就是把全公司「90%」的代码仓库设置成全 internal 。什么意思呢？只要你是 gitlab 的用户并且登录，那么公司除了少部分被设置成 private 的代码仓库，其它 90% 以上的仓库你都可读(可以克隆到本地）。当很多公司都在梳理仓库权限，建议把权限设置成 private 的时候，居然有人推动把公司的绝大部分仓库开放出去。我了解了一下，这样做的目的是项目公司内部开源。当时我内心的想法是「擦....老板又被不靠谱的人给忽悠了」。

内部开源(Inner Source)

我找了一些资料列下来。这也许就是他们忽悠老板的理由吧，可是仔细一看这些都站不住脚啊。

内部开源（Inner Source）简称内源，指把开发开源软件中学到的经验教训应用到公司或组织内部开发软件的实践。公司和组织可以在内部开源的同时开发专有软件。

荒唐做法理由之「开放式协作」

• 在推行内源的公司，所有员工都必须可以访问所有需要的开发制品（例如，代码、文档、问题跟踪等）。基于开放式协作的原则（平等的、精英领导的、自组织的），通常欢迎愿意为内源项目提供帮助的所有贡献者。
• 公开讨论决策时，开放式沟通也实现了精英制度。尽管组织不一定要变成彻底的自组织来适应内源，但是内源允许个人，组织单元和项目团体具有更高程度的自组织。

企业内部代码库全部内部开源，期待有人关心，感兴趣，看了代码后能帮修复个bug添加个功能，和原有负责团队一起讨论、形成方案。真的会出现这种情况么？

企业内部每个工程都是分工明确，职责清晰的团队在维护。内部公开后，真的有其它团队去看、克隆下来学习学习、有空的时候帮修复个bug添加个功能？没事干闲得慌了么？如果真的有这样的情况且这样的情况很多，我觉得我们更应该反思为啥有这样的情况出现。为啥有这么多闲着的人，不忙自己的业务，去跟其它的团队一起讨论功能、修bug、添加功能、保证质量。

荒唐做法理由之「开放式沟通」

开放式的沟通可以让内源项目和软件中的所有成员能够公开参与所有的交流互动。开放式沟通是公开的（在公司内部）、书面的、有存档且完整的。目的是允许与内源项目有关或感兴趣的任何个人或团体参与沟通。开放式沟通是会被存档的，软件的详细文档会被收集起来，团队可以回顾当时的讨论和决策。

公司内部的公共组件可以把自己的文档、源码公开这倒是没问题。本来有一些帮助文档也是要公开的，以便大家阅读。其它的真有必要么？比如平台的需求、PRD、设计稿、测试用例、程序代码、编译脚本.....其它团队真的想去插一脚？除非两个团队负责的系统之间有依赖或者协同，否则实际很少出现这种情况。即便系统之间有接口调用，也都是在接口维护平台上查看参数和文档，而不是去扒拉对方的代码。我就用一个接口，你让我了解你的平台，这效率也忒低了。

荒唐做法理由之「通过分离角色保证产品质量」

专门的代码审查以及贡献者和提交者（拥有写入权限的集成者、开发者）分离，可以确保开源项目的质量，也可以保证内源项目的质量。

很难想象有人给其它团队PR。不要对团队外的其他人抱有能提升产品质量的想法，他们没义务，也没兴趣。

企业内源不靠谱、不适合国情

我觉得上面的做法非常不适合国情。企业内部开源和社区开源根本就不是一回事。开源社区真是靠兴趣、靠爱在发电，而国内的企业内部根本不存在这样的土壤。

• 国内工作节奏快，每个人都很忙。这种让人每天加班到深夜，还要用爱去给别人发电的做法非常不靠谱。
• 国内一个萝卜一个坑，自己的坑自己填。别人不给你挖坑就很好了，千万不要指望别人给你填坑。
• 另外这种目的不明确边界的介入，很容易让负责的团队认为是「抢活」

可能的「解」

最近我也写过一篇文章《研发效能之技术治理》，我觉得「技术治理架构师」这个岗位可以来承担、完成企业内部开源的工作，「也许是」最可能达到目的的人选。

• 技术治理的目的：
• 梳理公司技术现状、制定技术治理方向
• 协调制定技术选型、研发流程等技术类规范
• 解决公司业务发展过程中遇到的共性问题和技术挑战
• 为不同业务场景提供全面的技术解决方案
• 进行规章制度、规范、平台使用的宣传、培训、布道、配套工具推广等

文章总结

分工明确、职责清晰、各司其职、高效协同是最好的状态。 国内外情况不同，很多做法都需要仔细斟酌。这种不假思考直接生搬硬套的做法非常不合适，也不安全。说不定哪天代码就「意外」跑到 github 上去了，还很难查是哪里泄漏出去的，全公司的人都有权限啊。我觉得哪怕干过一天源码管理的人都整不出这事，各位看官还是招点靠谱的人吧。

另：特拉斯真要是找个靠谱的财政大臣，结局是否会不一样？

延展阅读

研发效能之技术治理
找到能做好研发效能的人

感谢点赞、转载
关注我，了解最新研发效能发展动向
欢迎进入「DevOps研发效能群」一起探讨