高效能研发体系构建方案

背景

    技术管理者(技术总监/经理/CTO)都会面临公司战略执行，公司业绩的压力，以及业务对技术团队支撑能力的期望和诉求。如何打造一支快速响应，高效能，能打硬仗的技术团队？是技术管理者的挑战和必须完成的任务。

 

痛点

    1）技术选型混乱，大量基础技术组件代码重复构建，使用方式不一样；一些坑大家都需要重复踩一遍，关键是踩完了还不能复用经验可能还会在其他项目重复发生。

    2）项目最终被业务追着跑，产品设计没有路线图, 整体业务架构没有规划，最终演变成大量业务基础服务重复建设，业务边界不清晰，业务服务职责不清晰。

    3）线上事故不断，同一个问题可能重复发生或者一个事故发生后只有用户人为反馈后才能感知。解决和排查问题原因，需要很久分析才能解决。

    4）线上服务器管理混乱: 公共服务重复建设，服务器权限不清晰, 发版断服，服务不能动态扩容等。运维忙于处理线上故障和版本发布。

    5）研发流程，故障处理流程等标准化制度缺失或不明确; 人员的效能，团队的效能和组织效能无法量化，只能靠直觉和经验。

 

目标

    打造一支快速响应，高效能，能打硬仗的技术团队。

    1）技术人员效能提升50%, 整体人员成本降低50%。

    2）业务迭代周期提升30%, 实现秒级发布秒级回滚。

    3）故障响应速度提升90%，线上稳定性提升90%。

 

研发体系构建

 

1）业务一体化构建

    业务的一体化（或者称为业务中台），本质是基于功能抽象复用、架构合理性和业务统一管理的视角，通过适度的业务逻辑抽象、弹性的复用功能设计，将产品方案进行抽象、复用和下沉，打造企业级一站式功能服务平台。而这个过程非常考验产品的统筹规划设计能力，架构师的业务理解和服务拆分能力。

    个人比较推荐采用ddd的战略设计能力，产品与架构师和业务一起参与事件风暴，并梳理业务的核心流程，明确业务领域中的核心领域，支撑领域，通用领域，以及各个领域的上下文边界，并据此进行合理的业务微服务拆分，并反复验证业务领域模型和细节设计（也可同时采用传统的经验设计进行验证）后实施。同时个人也推荐在落地业务中台的时候，可以考虑把业务中台做“薄”一些，业务的前台做“厚”一些，这样可以保持前台业务的最大灵活性，帮助新业务快速度过探索期。

    假如在业务架构顶层设计时候领域拆分不合理，会在未来造成很多的业务架构技术负债而且项目迭代的效能会大大降低。而这些负债越到后面的业务发展，改动越难，影响越大。合理的领域服务拆分，服务调用链路应该是理想的树状或者可预期的规律调用链路。而在实操过程中，我们可以通过观察pinpoint或者skywalking追寻调用链路是否是网状无规律的循环调用结构？此时我们要确认服务拆分是否合理，是否需要重新梳理业务进行优化。

    虽然实际上每家公司的业务形态都不一样，若假设业务架构拆分合理（至少满足1-3年左右的业务架构演变），规划好产品技术路线图，项目迭代效能应该可以提升20%~30%。

 

业务领域图例:

 

2）技术一体化构建

    技术的一体化（不仅仅只称为技术中台），主要解决的是“业务开发人员”使用技术的统一标准化，比如是技术编程语言统一（如java,.net,python），技术选型统一(如分布式的技术选型统一,框架统一)，技术使用标准统一（如日志规范），项目脚手架统一（如项目结构，项目文档统一）等。

我们在实践过程中通常会构建bsf（base service framework）基础服务框架，business framework 基础业务框架及bsf-demo基础业务脚手架去解决业务开发人员的技术问题。

    【bsf基础服务框架】解决框架使用，技术选型，性能优化，日志规范及中间件监控等标准。让业务开发人员无需关注底层框架实现，只需按照标准技术规范，专注本身领域的业务开发实践，专注本身领域的业务价值实现。（bsf框架层优先兼容新旧技术选型,推进技术演变,业务开发无需改动代码;同时为运维一体化，监控一体化，管理一体化提供框架级支撑）

参考(部分开源版): https://gitee.com/yhcsx/csx-bsf-all

    【business 业务基础框架】 解决业务之间公共通用使用的类库，比如业务的通信协议，业务的状态码标准（错误状态码）等等，同时也解决一些新旧架构兼容等业务兼容问题。

    【demo标准脚手架】 解决业务框架标准化项目结构（或ddd项目标准结构）及文档，让开发人员1分钟生成项目3分钟进入项目开发。

参考(部分开源版): https://gitee.com/yhcsx/csx-bsf-demo

 

基础框架集成顺序:

 

标准脚手架结构图:

 

    通过技术一体化的实践，我们比较完美的做到剥离业务开发的（与业务无关的）技术，让业务专注业务的实践，同时底层技术演进和实践，业务开发人员无需关注和配合。那么业务线高级开发人员的比例可以减少50%+，研发效能提升10%+。（当然架构师依旧会深入在某个业务线领域协助业务优化自身的业务架构（如分库分表），让业务性能和稳定性得到进一步的提升。）

 

3）监控一体化构建

    监控一体化的目的在于自动化的产出项目质量报告，并进行实时的预警机制，让业务开发人员只关注业务实践，无需关注线上性能问题（因为一旦有问题，我们就会自动监测）。

 

监控中心概要图

    我们构建一个监控体系用于基础采集指标的收集，其中包含开源的一些采集系统，自建的一些采集指标（插件行使）补充，或第三方商业的工具（如听云等），同时也会动态多维度的项目性能质量分析报告及动态评分和评级，同时根据策略实时进行性能及异常预警到特定人员。

    一方面将我们对常见的性能及稳定性问题的分析经验沉淀，形成自动化的监控和报警系统，彻底解放运维人力监控、人力分析预警；另一方面我们自动化的形成质量报告，实时分析出项目的质量情况和相应的解决方案建议（经验沉淀），推进项目质量改进和分析。

    最终实现秒级性能及异常报警，实时质量分析报告，1分钟内精准定位问题，解放重复的性能分析和排查，研发效能可提升5%+。

 

4）运维一体化构建

    运维一体化的本质在于彻底解放运维日常的工作,让运维更加关注服务器性能的提升,成本的降低。

在我们实践的认知中，我们认为运维和架构是一体的（至少也是难以分离），假如项目架构和技术层面没有做到统一（各自采用不同的技术选型和项目结构），那么在运维层面也难以做到统一，整体运维的工作量随着项目的数量，不断增加，甚至大部分场景都要单独维护，那么重复性和不必要的工作重复做。

运维自动化概要图

    运维的工作是技术中较为繁杂的（包含环境管理，权限管理，网络安全建设，资产管理等等），我们期望在基础设施服务一体化,云原生容器化，运维一站式,CICD一体化,发布自动化这几块就做到运维的一体化。

    【基础设施服务一体化】架构和运维推进并在设计初级做到技术选型的统一和项目结构的统一，技术内部团队中只允许使用一套基础设施服务和一套基础技术选型标准，比如分布式相关的基础服务，监控体系，研发管理体系和发布体系。

    【云原生容器化】容器化可以有效的节省服务器成本,快速扩缩容和服务持续可用，在技术体系统一的情况下，实践虚机到容器化迁移非常迅速，实际可节省服务器成本约30%左右；同时我们也推进所有的基础设施服务全部用云原生方式替代，进一步降低成本和快速部署能力。

    【CICD一体化】在技术一体化的基础上，采用一套部署脚本和机制，满足一键发布服务，一键回滚服务，所有服务版本化，所有服务秒级发布。开发人员无需关注线上部署脚本情况,无需关注服务启动切换，无需关注线上服务运行环境（虚机还是容器）。

    【运维一站式】所有运维的定时/监控等脚本分发执行,所有服务器，资产及成本等关键性的运维工作进行统一的管控及自动化平台。

    【发布自动化】在技术一体化的基础上，通过可视化流程形式构建整套发布流程和回滚流程，构建审批流程，将版本发布工作交还给项目团队，彻底解放运维的日常项目迭代发版的协同工作。

    按照两家公司的不同技术团队（150-200人左右）同等规模下实践对比，运维一体化实践较好的公司运维仅需1-2人，而另外一家公司运维约7人左右，而对整个技术团队的效能提升应该在5%~10%左右。

 

5）管理一体化构建

    管理一体化的目标在于建立数字化，标准化的管理方式，将经验和理念沉淀到系统中，通过数据去指导及验证管理决策，提升整体研发人员能效；同时我们期望将“人治”逐步变成"系统化",让管理者精力更加聚焦业务价值实现。

 

管理模式演变概要图

 

    在管理实践中，我们将“经验直觉”人治管理方式逐步演变成规范化标准化的人治管理方式（管理成本也逐渐增加），也期望逐步向“数据化”“自动化”的系统管理转变（更加精准，更加实时且直观的暴露问题），通过数据指标进行分析和对比，快速的决策和改进。

从项目初期，我们就推进各个环节的标准化(管理规范一体化)，并制定关键核心规范并落地到各个项目中，但是效果不一定很理想。因为管理者在做业务价值和技术负债的取舍矛盾中，往往选择优先满足业务价值，本质是因为我们没有直观的量化的指标去衡量投入产出比,项目质量的变化,有效业务价值，这个也是最初数字化管理的需求痛点。

    管理要“以人为本”，管人要以“人性”为前提，但管理者要有财务思维。研发效能平台将组织架构，组织文化，项目管理工具（禅道/tapd），项目质量（监控一体化）,标准规范（管理规范标准化），缺陷故障（线上bug/故障rca复盘），资源成本（服务器，资产，人员成本），周报管理，激励+成长+360考核等等已知研发体系信息进行分析。

    以“员工”为维度产出员工/管理者的职级，任务数，bug数，任务完成度，有效产出量，代码质量，工作时长，有效工作时长，线上故障数，工作饱和度，分享能力，学习能力，成长度，产品价值，技术价值，业务价值等等；

    以“项目”为维度产出项目/迭代的人员数，工时数，产品价值(达成率)，技术价值(达成率)，业务价值(达成率)，人员投入成本，服务器投入成本；

    以“组织”为维度产出团队/组织的人员数，工时数，产品价值(达成率)，技术价值(达成率)，业务价值(达成率)，人员投入成本，服务器投入成本，任务数，bug数，任务完成度，有效产出量，代码质量，工作时长，有效工作时长，线上故障数，工作饱和度，分享能力，学习能力，成长度等等。

    管理者最重要的事：制定目标，带领团队，拿出结果。我们期望通过将管理方法论沉淀为数据化，自动化的系统平台化管理，让管理者更加聚焦业务本身，通过一体化的量化数据增强管理和精准决策（验证管理成果），同时通过系统化降低管理(人员/职能)成本，（百人以上研发团队规模下）整体研发效能提升10%~20%。

 

总结

    通过研发体系的构建，五个维度的一体化建设，我们不断努力的实践并验证人员能效提升并聚焦业务价值；然而研发管理体系的建设并没有银弹，我们依旧在不断的沉淀，实践，总结，交流，打破，提升；欢迎一起交流分享！

出处：https://www.cnblogs.com/chejiangyi/p/15000543.html