光环：研发云搭建及人才梯队建设——姚冬

摘要：文章内容主要来源于光环国际2022年第三届中国科创者大会姚冬老师的分享，原分享名称为"数字化时代的研发效能建设"。讲述了华为在研发上整套流程规范，通过云的方式去实现人机协同，保持人去做创新型工作。对人才梯队建设做了要求，特别是核心人才一定是需要懂管理也会编码，鼓励工程师多去和客户沟通，站在项目战场线上，形成全能小团队，自己去思考定位和养活自己。也侧重的表达了质量和安全重要性，因该贯穿全流程。
1、需求收集、客户沟通、业务设计、架构设计、开发代码、完成代码这些阶段活动都是增值，都会往发布包里面增加特性、功能。测试、部署、运维这些阶段活动理论上都是非增值，因为没有增加任何一个代码、核心。在软件开发中，非增值活动在整个过程中占比较重（要求做的好一点预计占到50%）
2、人和机器之间进行有效的协同，真正的让重复工作由机器完成，让人可以去持续做高增值、高价值的活动，这个是研发效能根本目的。
3、“核心人才”做到承上启下，带领团队，跟随推动组织向前走。主要重视这一部分人的培养和留存，建立梯队，有序的流动，不能流动的太快。
4、代码不是机器去读而是人

---

一、研发效能如何搭建

1.1 研发效能定义

研发效能是近几年出来的一个比较火的词，什么是研发效能，和敏捷和DevOps有什么关系。个人对研发效能的定义为：持续 并且 快速 的交付 高质量 的 有价值 的软件给客户。加粗的形容词是关键字，纲要。

研发效能有两点“效”和“能”，“效”也有两个含义，其中一个就是“效率”，快速就是指的效率。另一个就是“效果”，高质量、有价值就是指的效果。所有的效果都是由客户、用户去定义。“能”就是指能力，是否具备既有效率又有效果这样的一个能力，能力不能是一次性或者突然的，为了满足某一次上线的冲刺，而是可持续。

下图是一个研发效能端到端大的流程，一个典型的研发流程，有产品创新，大段的开发工作，发布上线，产品运维。从需求收集、客户沟通、业务设计、架构设计、开发代码、完成代码这些阶段活动都是增值，都会往发布包里面增加特性、功能。从测试、部署、运维这些阶段活动理论上都是非增值，因为没有增加任何一个代码、核心。在软件开发中，非增值活动在整个过程中占比较重（要求做的好一点预计占到50%）。

所以，软件研发效能做的是如何让这些非增值活动去争取一个极致的效能，比如通过工具自动化去完成，自动化后就可以保证效率和效果一致性。无论做10次、100次都是按照定义的流程、规范、要求完成，保证一致性。工具就是指机器，那么人有擅长什么了？

人擅长创造性这一部分活动，去整体保障效果。比如要做一个什么样的产品，它的方向是什么？客户想要的是他话术背后的隐藏的含义，人是擅长去抓取这些信息。这就是为什么要由人去在元宇宙中做职工，因为机器传递不出人的情感，抓不住客户的真实灵感。人和机器之间如何进行有效的协同，真正的让重复工作由机器完成，让人可以去持续做高增值、高价值的活动，这个是研发效能根本目的。

贯穿始终的有几条线：①测试：质量的保证，②安全，③可信：是否值得信任。

1.2 华为如何搭建研发配套

华为传统是做电信业务，随着最近几年做终端设备（手机、电脑、路由器等）才逐步让更多的人知晓华为这家公司。电信业务主要就是交换机，比如2G、3G、4G、5G网络相关业务。华为内部产品非常丰富，除了终端、交换机、还有换华为云，既有纯硬件，也有纯软件，同时也有两者结合的软硬件一体化。

华为历经30多年的发展，走过了成立之初的个人英雄主义，比如能看见的郑宝用、小徐总(徐直军)。在90年代中后期时，发展可持续，避免前面可能说一个产品是偶然成功，在下一个版本可能就会黯淡情况。这里推荐一本书《从偶然到必然》，这一本书讲述华为完整研发体系，集成产品开发 （Integrated Product Development, 简称IPD）。99年从IBM中引进，从先僵化、再固化、到优化用了将近5年时间。然后接纳很多业界的实践进行自己优化，比如持续集成、持续测试、敏捷到现的DevOps，在18年的时候产生华为自己的一套体系“可行工程”，在内部通过指标去做牵引。

①指标一：“六问一”，也是DevOps中的 MTTR (Mean Time To Repair，平均修复时间)，就是当一个服务宕掉的时候，多快的时间能恢复过来。给到一分钟时间，这么短的时间，就不是由人工的去检测发现问题，然后再切换回来，一定是工具自动化帮助完成，自动故障检测，自动恢复，推荐通过生态云、容器等等这样的基础去搭建。

②指标二：需求到闭环，就是客户的需求提出到完成、到上线，这个是一个平均的指标。就是敏捷 Scrum Time 或者 Lead Team 前置时间（采购方开始下单订购到 供应商 交货所间隔的时间），是客户可见的。华为在前置时间下，需要每周迭代。

为了完成指标，做了以下几件事情：
①基础设施云化，以往可能有大量服务器、终端，各个部门在需要使用的时候去采买。过了这个时间阶段后，经常就会被闲置，资源利用率并不高。当把这些资源集中在一起，就可以有效去提高利用率。而且需要这个环境的时候，不用去跑到机房去搭建环境，只需要在页面点击按钮。

所以这里就用到云计算，虚拟化、容器化，包含DevOps中重要词汇基础设施即代码。把基础测试描述（如需要几G，什么系统，数据库中间件是什么，他们相关的配置、应用的版本是怎样）通过脚本化描述出来。

那么，能通过脚本化描述出来，就可通过工具自动化，以此保证高度的一致性。同时把环境和代码绑定到一起，一个标签打出，它所依赖的代码、底层环境一定是一致的，就不存在这个环境能跑，另一个环境就不能跑甩锅情况。 ②架构云化，所有应用上云后，才能真正用到云的特性，首先需要应用云化，对原有的应用进行改造，如何去上云，需要有一个规划路径。同时新的应用就可以直接采用原生云开发，原生好处就是架构可以解耦开，解耦后可以对某一个单点服务；甚至服务再拆分成微服务，彼此之间解耦开，不需要依赖其他服务。这样就可同时编译构建、测试的力度就会很小，它的速度就会很快。 ③工具上云，整个运行环境上云，架构上云，应用上云后，开发这个过程显而易见也是需要上云。需要把工具（如：项目管理工具，需求管理工具，架构设计工具，编码工具，测试工具，CI/CD，甚至运维等）这些都上云。上云后，整体研发模式就能整体重构。 综上三步：①基础设施云化，②架构云化，③工具云化，并非需要①完成后做②，②完成后做③，他们是相互结合，一个螺旋上升过程，可以同时并行。

---

二、产品研发运维全过程

2.1 年度目标制定

下图为华为一个研发全景图，最上面绿色部分是一个大的战略或者战术计划，在每年年底时候就会做下一个年度规划，称之OBP。这里就会定义出来，明年的目标是什么，要挑战的目标是什么，跟OKR相结合，定下计划后，第二年会在季度上进行发布。按年做规划，按季度做大版本发布，这样所有服务都会向版本对齐，保证步调一致。

下方是一个过程，分为Dev 和 Ops，在Dev一侧会有以下几个贯穿始末：

①需求：需求是一个来源，也是一个目标，所有设计、架构、开发、测试等等都是因需求而来。在研发的整个过程中，都应该与需求做对齐。需求不是在前端设计完、分析完、采集完就完事，代码任务需要和需求相关联，测试标准、测试用例、测试结果数据也来源于需求。然后发布的版本，版本二进制包中包含哪些功能、缺陷、修复、生产环境也和需求有关联。

②流水线：流水线也是把这整过流程去惯穿。

③测试：测试不是开发完成后开始进行，在需求阶段就引入进来，站在测试角度看这些功能有哪些边界、异常等等。去验证测试的扩充性、稳定性等跟功能无关的非功能性需求（Non-functional requirements），这些都是架构师需要考虑的问题。

④安全：经常看见安全是上线后进行的安全巡检，做一些攻防演练等等，其实不是这样。安全一定是在早期设计阶段引入安全，否则不能保证开发的应用是安全内置的，不能依靠最后的验证去保证安全，这样效率也低下，效果极差，所以安全是贯穿始末。

⑤第三方：指开源，这一个无法回避也无需回避，同时应该极大的去利用它。在使用的过程要小心，保持警惕，包含对开源协议的了解、开源中可能存在的一些漏洞、版本依赖关系，一旦出现漏洞怎么快速检测到，怎么快速修复，同时让整个组织应用到你的包。

在Ops一侧主要是运维工作，主要是如何自动化和运营。

2.2 组织文化

对于华为而言需要的是，如何高效的、快速的去做一个创新。以往是跟随战略，主要跟随电信设备商，在十多年前华为已经做到很多领域第一，以前的跟随战略就不生效。在无人区，自己如何去做引领，做领航者。

这里主要涉及到几个维度：高效组织如何去建设，组织及文化（可信文化、软件文化、工程师文化），创新（创新体现在方方面面），如何打造一群精英的人。

2.3 人才梯队

所有都离不开人，如何取培养、留住一圈精英的人？华为有一个人才金字塔模型，经常会听见华为招聘某天才博士，比如前年有博士造出会自己行走的自行车。这些领军人物，在关键技术领域的突破确实起到至关重要的作用，华为对于这些技术领袖是非常非常看重。他们的职业发展可以跟各级部长、董事长都是匹配的。在内部一个 Title 叫 fellow，就是一个院士，其级别非常高。但是这些人非常少，中流砥柱主要就是红圈标注的“核心人才”，做到承上启下，带领团队，跟随推动组织向前走。主要重视这一部分人的培养和留存，建立梯队，有序的流动，不能流动的太快。

对于核心人才（部门主管）会有一个人模型V-eset，华为在打造工程师文化。这可能在国外硅谷的一些企业可以经常听见，在国内相对少一些。工程师文化就是把工程师摆到前台一个重要的位置。尤其现在公司软件、IT、数字化不可或缺，因为技术变成了一个核心业务竞争力，技术背后就是技术工程师。

如何去体现工程师价值，让其即动手又动脑，这就是华为目前想做的一件事情。在此之下就是团队如何建设，构建高绩效团队，如何可被客户信任的交付。可信任就是质量保证、需求满足、周期内交付并和客户保持优秀的沟通，最后就是整体的去构建业务的竞争力。业务竞争力中需要强调的是所有的主管都需懂业务，关心业务，不是闭门造车。研发费用拆解完成一定是从业务侧而来，研发的产品它的市场是什么，用户群体是什么，市场竞争力是什么，收入从哪里来，这些收入需持续构建。现在非常重视开发者生态，比如说整个运营手段，也是源自于此。 对于部门主管的要求，主要会从几个方面去看，
①业务交付能力 ：项目管理能力、工程能力
②专业技术：技术领先性、架构要求，

不能只懂管理还需懂技术，在内部有要求写代码的需求，1年往代码仓库中（核心需求）commit的代码有多少。 对于团队阵型，从以往大功能职能性划分，到现在的全能性团队。在这个团队里面包含了从前端产品，到架构，到开发，到测试，到上线运维所有的都在这个团队里包含。同时这个团队需要自己去考虑自己的生存问题，如何去养活自己。团队不会超过10人，团队定位是创新型、流量型、公共服务类，需要自己去掌握定位，他的预算从哪里来就很重要，这是一个成功团队需要考虑的东西。 对于单个个人工程师而言，强调全栈，首先技术要专精，体现在架构层面、开发层面。在华为拆分测试后，其中有大部分测试称之为开发者测试，不在强调测试应该由谁去做。除了技术以外，同时需要了解业务和客户沟通，不能够闭门造车，鼓励走到战场上去，跟客户沟通，真正的走到项目里面去。

2.4 代码检测

代码质量方面有一个Clean Code要求，如何让代码是好的代码，有哪些标准或特征。代码不是机器去读而是人，后来肯定有人会帮你去更新维护，90%以上代码一定会涉及到修改，在修改的时候不是同一个人，所以代码的可读性、可维性是代码整洁的核心。在华为有一个Committer机制，所有的代码都需要经过开发者自测，提交上去后，有一个门禁会进行检查，通过门禁后会有一个Committer帮助做评估，保证提交到主干代码一定是经过筛选。

在Clean Code评估也会有一个标准，在华为有一个三层质量模型和六级评分标准。 编译构建是开发人员日常常做的事情，编译构建一旦时间很长就会痛苦，所以需要对齐加速，

2.5 测试能力

为了提升开发工程师的测试能力，进行了如下的一个培养方式。前期由测试人员培训，后面逐渐转成以开发人员自己为主，到独立自主偶尔遇到问题测试人员进行协助，最后整个团队都具备了测试能力。

还可以达成精简一些流程。 然后为了提升测试，去优化工具，降低使用门槛和投入。同时测试也会有金字塔，更好知道测试投入产能比分布，应用处在什么阶段，因该采取什么样的测试。由原先做测试这个活动，转变为一个测试能力构建、测试工具改造、测试推广和普及，变成了测试服务化的一个团队。可能是工具、可能是实践、可能是流程等等。变成一个测试能力中心，在测试领域变得非常精专，是未来测试方向，取缔以前的手工测试。

2.6 质量守护

在质量里面会有很多质量的看护流程。

每一个阶段都会去定义，比如开发：在开发代码的时候就会做质量活动（橘黄色部分）。在开发完成时，转到团队级集成的时候，又会做其他质量活动。在往后产品级的集成时，又有另外的质量活动。

应用在开发转测试的时候，有需要达成什么条件规范，到达测试后，测试阶段又有分级分层的测试。比如集成测试、BPI功能测试、性能测试、压力测试、安全测试等等。做完这一些后，再去做端到端的测试。由测试转上线应有需要达成什么条件规范，这个叫测试左移或者测试前移。在上线后还会做大量的测试，比如线上的巡检、倒流测试、混沌工程等等。

每一个节点都会有不同的人员去参与，SDE会很忙，从架构设计、开发、测试、运维都会以SDE为主。

2.7 安全

安全应该是贯穿始末的，所以在需求阶段、架构阶段等各个阶段，都应该植入安全相关措施。

最终会行一个完整的软件链条，架构体现到代码、配置、上线的版本是什么。这样架构信息的定义就会和生产环境有一个很好关联关系。 安全保障体系不只是说去扫描一下代码有没有安全漏洞、做一些渗透性测试、攻防演练等等。需要有一些安全的需求、建模、设计。比如代码安全、上线之后的安全等等。同时需要去定义出来安全标准规范、安全技术，怎么把安全能力下沉下来，安全工具如何去支撑。 还有一点就是开源的管理

2.8 度量

最后讲一下度量，度量在讲效能的时候都会比较关心，具体的度量指标有过程性和结果性两个维度指标。所有的指标都应该是工具在过程中去抓取下来，最后去汇总形成一个展现，对不同的人员看到不同的内容，因为他需要看到内容不一样。

下图是华为内部的看板，一个全流程端到端的流水线，不仅仅包含CI/CD，还包含需求、架构。标绿为通过质量要求，粉色是有违背，违背更多颜色会很更深。这里图片隐藏了每个阶段质量要求是多少，比如100条，遵循多少违背多少，都会一目了然的标识出来。 在质量背后，去定义很多规范，比如研发流程规范，所以会有一个流程看板，去看每一阶段需要去做什么事情，一目了然全体系的流程规范是什么，

2.9 创新阻碍调研

我们需要的是软件创新，是什么妨碍了软件创新，下图为一个调研报告，其实技术层面占的不是很多，还应该从文化、团队等一些因素做建设。

---

三、在线答疑

1、DevOps投入占研发投入的总占比是多少？

答：不仅仅是自动化工具，在华为整个研发会占收入的百分之十几（预估14%），华为每年的收益在 7000 ~ 8000亿。研发效能研究占研发的占比具体不清楚，但是会是上亿的投入。老师部门主要承载公司内部工具建设，以前叫做<2012实验室>，主要研发新技术、前沿工具引入，然后给各个产品线去提供这些能力。就是搭底层给各个业务去使用，逐步这部分提取到华为云，因为内部本身也在云上，在华为云对外提供之后，顺带研发能力也对外提供，当然对外和对内还有有一定差异。

2、感觉devOps 对各个要求都是全栈？

答：对，希望是全栈，但是事实上不可能所有的都是精专。努力做到从T型（一专多能），到现场的多专多能。

3、小公司也需要投入这么多占比去构建DevOps体系吗？

答：个人觉得小公司要考虑的是存活问题，而不是更快的效率，更高的产出比。适度的客户满意度，不可能要求极致的质量。需要去背负一些风险，质量一旦出现问题，这个风险一定要去抗，但是不一定去修复它，要去平衡。明确小公司不能投入这么大比例，可去使用开源工具、云上服务去快速构建。增加的时候再逐渐去还这个风险债务，发展到一定的阶段后，不能承担失败风险，再花更多精力在这上面。