共计 7978 个字符，预计需要花费 20 分钟才能阅读完成。
外围观点
- 单点工具的串联无奈无效解决研效痛点问题，企业须要通过一体化协同平台进步端到端价值流动效率。
- 一体化协同平台的价值是软件工程理念最大化落地、数字化研发治理、沉迷式研发体验。
- 一体化协同平台集成须要评估闭环效率杠杆，确定集成边界和集成深度。
- BizOps 和 FinOps 的呈现，代表一体化协同趋势正在回归“生产实质”，发明价值。
一体化协同平台概述
“斗争式”研效治理
目前，越来越多的企业抉择通过数字化转型应答市场的不确定性。软件作为数字化的间接载体，软件研发效力治理（简称为研效治理）成为企业数字化转型的要害，企业冀望通过引进优良的研效文化、方法论、技术，重塑组织职能边界，优化分工效率；通过翻新软件研发流程，面向“价值”协同；通过引进自动化工具链，优化价值流转效率。
然而，市场竞争是残暴的，软件研效治理也始终在进行，发展新的软件研效治理不得不向“业务连续性”和“IT 固有资产斗争”，研效治理变为“斗争式”研效治理，落地成果大打折扣，如图 10.7.1 所示。
业务连续性斗争
大多数企业都不足渐进式研效治理的教训，如何小规模试点，从边缘业务向外围业务推动，是摆在企业背后的难题。为了保障业务的连续性，不对现有组织构造和业务流程造成影响，在软件研效治理的过程中，往往会就义“组织变革”和“流程翻新”。
图 10.7.1“斗争式”研发效力治理
IT 固有资产斗争
研效治理对企业来说是贯通“整个生命周期”的使命，为了保障自动化需要，须要购买和保护大量的自动化工具。在新一轮研效治理中，为了不造成 IT 固有资产的节约，企业经常抉择补齐面向职能单点的自动化工具，晋升繁多职能的工作效率。如图 10.7.2 所示，企业曾经存在客户治理、我的项目协同、代码仓库等工具，痛点在代码的集成和利用公布上，思考到曾经产生的工具洽购老本，企业通过引入 Jenkins 和 ArgoCD 进步 CI/CD 单点效率，这种状况即为 IT 固有资产斗争。
图 10.7.2 IT 固有资产斗争
“斗争式”研效治理的痛点
“斗争式”研效治理仅引入新单点工具，通过自动化伎俩进步繁多职能工作效率，而单点工具之间的串联大多是通过 Webhook 机制在 backend 级别买通的，而账号、权限、交互没有被买通，如图 10.7.3 所示。基于这个客观事实，单点工具在研效治理中存在职能内工具应用不规范、跨职能协同效率低、跨工具切换老本高和保护老本低等痛点，如图 10.7.4 所示。
图 10.7.3 单点工具
职能内工具应用不规范
单点工具解决繁多职能内的工作效率问题，不解决繁多职能内标准化作业问题，如果工具不能被标准化应用，则意味着团队与团队之间、员工与员工之间存在应用效率和交付品质的高下问题。
图 10.7.4 单点工具痛点
跨职能协同效率低
单点工具之间的信息传递是不规范的，但跨职能之间的协同依赖于上游信息传递的标准化，比方信息的有效性、完整性、及时性，否则就可能存在需要已确认，但研发人员、测试人员、设计人员、运维人员都不晓得，无奈发展本人的工作，研发工序与工序之间存在大量的前置等待时间，这些工夫最终会变为工作流中一个又一个的效率“高地”。
跨工具切换老本高
在研发工作流中，繁多职能的生产者须要横跨多个工序实现工作，比方研发人员须要从我的项目协同（Jira）支付需要、代码仓库（GitLab）实现编码、继续集成（Jenkins）查看构建后果、继续部署（ArgoCD）确认公布物料、公布之后需更改我的项目协同（Jira）的需要状态，实现一个需要须要跨多个工具，切换老本十分高，这使研发人员无奈专一于价值发明，繁多工具的引入从研发赋能变成了研发“负”能。
保护老本高，治理难度大，无奈无效度量
保护老本高：在单点工具自研或洽购后，企业须要安顿 IT 资源运行和运维，而稳定性的保障工作老本较高。
治理难度大：单点工具之间是无限串联的，这也就意味着企业须要在不同工具之间维持账号和权限的一致性，一旦呈现不统一，其影响可能是灾难性的，比方我的项目协同工具中不属于某我的项目的成员，能够在公布工具中执行该项目标公布。
无奈无效度量：繁多工具的数据是绝对残缺的，但因为工具应用的不规范、跨职能协同等待时间无奈度量、工具切换耗费了大量工夫等因素，因而度量失去了参考意义，企业无奈无效地洞察效力瓶颈、继续改良研效治理。
组织职能僵化，无奈应答软件复杂性的挑战（图 10.7.5）
图 10.7.5 利用复杂性对软件工程的挑战
软件的微服务化大大增加了运维人员的工作量，如果还只是依附运维来负责整个软件的公布，则运维人员的规模无奈匹配软件微服务的规模，于是软件公布这一工序会成为效率卡点。然而软件的微服务规模通常和研发人员的规模成正比，如果能重塑研发和运维之间的职能边界，将软件公布左移至研发，则可大大缓解软件微服务化对公布的挑战。
从制造业看生产理念和流程翻新
制造业生产方式的演进，如图 10.7.6 所示。
图 10.7.6 制造业生产方式的演进
在制造业生产方式的演进历史中，福特汽车的流水线和丰田汽车的精益生产实践别离代表了流程和生产理念翻新，两者为晋升企业生产效率、改善产品质量、升高制作老本做出了巨大贡献。相比制造业数百年的历史，软件工程的倒退还不到 60 年，现在的成熟度还远远不迭制造业，从福特和丰田的翻新带来的微小价值看，软件研发流程重构和面向价值协同的生产理念同样十分重要。
基于对“斗争式”研效治理痛点的剖析，企业须要的不是单点工具，而是能闭环研发流动的一体化协同平台。一体化协同的实质是企业面向价值的协同文化对立、优化价值流转效率的软件研发流程重构、晋升资源效率的自动化工具链建设，其中任何一项都是不小的投入。那么，一体化协同平台到底能为企业带来什么价值呢？
一体化协同平台的价值
图 10.7.7 所示为一体化协同平台的整体价值图。
最大化落地软件工程认知
“锅碗瓢盆的拼凑，不会解决做饭的问题”，同样的，单点工具的串联也不能解决软件研效治理的问题。个别企业是先通过对精益、麻利、DevOps 等卓越工程理念的学习；而后联合对企业研效痛点及外部业务模型、组织模型、利用模型的思考，实现企业组织自上而下的软件工程认知降级；最初通过工具落地企业对软件工程的全新认知，包含软件研发对立治理、端到端的协同形式、品质内建、度量、合规生产、双态多端治理等问题，这些问题绝不是开源单点工具可能落地的。很难设想，ArgoCD 面向繁多场景的工具会思考企业的软件工程认知如何积淀、如何落地。比方，公布之后主动批改我的项目协同的需要状态、主动归档代码仓库的公布分支、批改制品的元数据、记录公布信息。
图 10.7.7 一体化协同平台的整体价值图
不同于单点工具，一体化协同平台的外围价值是最大化落地企业的软件工程认知，无论是品质内建，还是重构端到端的协同形式，都不会受限于单点工具的能力，并且企业可通过一体化协同平台产生的全链路软件研发数据，继续降级软件工程认知，继续改良软件研发效力。
数字化研效治理
一体化协同平台须要实现研发流水线的工业化，其特色是信息化、自动化、标准化、流程化，信息化保障了全链路数据的完整性；自动化和标准化拉平了因人而异的效率差别，保障了数据的主观可信；流程化则抹去了单点工具切换引发的前置等待时间，保障了数据的有效性。这些工业化特色数据，使企业软件研发的价值、过程、老本变得可被度量，企业研发管理人员可根据这些度量后果开展数字化研效治理流动。
沉迷式研发体验
一体化协同平台通过重构软件研发流程，实现了对立编排和配套工具链的深度整合，研发流水线帮助研发人员实现了自动化的上下游协同，使研发人员专一于利用编码，毋庸在多个零碎之间切换，真正实现了沉迷式研发体验，进步了研发效率。
举一个研发上下游协同的例子，在产品经理将某个需要调配给研发人员后，一体化协同平台会依据需要名称主动创立个性分支，分支被创立后会主动告诉该研发人员，其仅须要本地 checkout 该分支即可开始编码。代码一旦提交，继续集成的测试环境流水线会主动触发执行代码 clone、构建和运行单元测试、代码扫描、制品推送、测试环境部署。流水线运行胜利后，需要状态主动批改为「待测试」，这时平台会主动告诉需要的关注人，测试人员收到告诉开始测试工作。整个流程中如果没有品质门禁不通过或者测试失败的状况，研发人员仅须要关注利用编码和代码提交，真正做到了工具服务于人，而不是人服务于工具。
一体化协同平台的实现
设计思路
端到端闭环
端到端闭环是指一体化协同平台重构软件研发流程，集成软件交付过程中的次要流动和工具，对立单点工具的账号和权限，解决研发过程中工具频繁切换和工具之间信息割裂的问题。为进步软件交付端到端流动效率和软件交付品质，企业需明确集成边界和集成深度，以及工具分工边界。
（1）集成边界和集成深度：评估闭环效率杠杆，确定集成边界和集成深度。
一体化协同平台对单点工具的集成并不是越多、越深就越好，须要拉通软件交付整条链路，评估集成对闭环效率高下的影响，确定是否集成和如何集成。如果咱们把一次端到端软件交付当作一次交付闭环的话，则闭环效率杠杆是指集成工具对闭环效率影响的大小。上面以设计工具、CMDB、项目管理为例，通过对集成效率杠杆高下的剖析，别离采纳不集成、局部集成和残缺集成的计划。
首先是不集成，以设计师罕用的设计工具 Figma 为例，设计流动次要由产品经理、设计师、前端工程师、测试工程师参加，Figma 自身曾经为跨职能场景提供了协同能力，因而设计流动可能在 Figma 中实现闭环，这时一体化协同平台毋庸集成 Figma，因为集成的外围价值在于实现全链路的协同闭环，而当初这个闭环曾经实现，任何投入只有老本而没有收益。因而，一体化协同平台仅须要在需要中关联 Figma 的设计稿即可，以保障需要信息的完整性。
接下来是局部集成，以运维人员保护 IT 资源信息的 CMDB 为例。在软件研发过程中，存在大量的机器资源依赖场景，比方继续构建机器资源、代码扫描机器资源、制品扫描机器资源、自动化测试机器资源、公布机器资源等。运维人员个别会先在 CMDB 中保护这些资源，比方资源规格、资源业务归属、资源利用归属、供应商、洽购老本等，而后按资源应用权限（业务和利用隔离）交付给对应的研发人员。在这种场景下，因为 CMDB 影响闭环效率的是资源交付流动，因而 CMDB 的集成仅需实现资源交付的集成即可，资源保护的性能还是在 CMDB 中实现。资源交付会通过一体化协同平台的 OPEN API 和 CMDB 实现集成，进步资源交付效率。
最初是残缺集成，以项目管理工具 OmniPlan 为例。OmniPlan 能够帮忙项目管理人员实现工作划分、里程碑制订、我的项目排期等工作，在可视化和信息结构化上做得不错，然而因为 OmniPlan 和研发流动中其余工具之间的割裂，间接升高了闭环效率，比方和代码仓库与测试管理工具的割裂，导致研发人员和测试人员不得不通过在多个零碎中切换来实现工作状态批改，这种状况就须要思考残缺集成，进步闭环效率。
（2）工具分工边界：规范的交给工具，不规范的交给人。
其是指把反复的、规范的流动交给工具，如需要状态流转、上下游信息协同、单元测试执行；把非标准的、具备价值创造性的流动交给人，如代码编写、工作拆分、测试用例编写，以最大化价值流动效率和资源转换效率。要做到这一点，就须要一条工业化研发流水线引擎，其须要串联软件研发所有流动及其配套工具，并为每一个流动设置流动规范执行标准、活动状态上下游流转规定、流动上下游信息同步标准，如图 10.7.8 所示。
图 10.7.8 工业化流水线
品质内建
丰田的流水线相比福特的一个重要翻新，就是退出了质量检查和疾速止损的环节。福特的流水线一旦运行，品质问题只能在最初被发现，造成流水线的良品率较低。而丰田的流水线，退出了品质检测环节，并配有“安灯”按钮，一旦流水线上发现品质问题，即可通过“安灯”按钮中断生产，修复产品质量后再运行流水线生产，大大提高了良品率。
而在软件研发流水线中，也须要将代码扫描、单元测试、接口自动化测试、制品扫描、制品依赖剖析等品质检测能力有机地整合在流水线中，并且将这些品质检测的后果标准化，再配合品质门禁配置规定实现品质问题的疾速拦挡，早发现，早修复。
扩展性
平台的集成是有边界的，往大了看，研发一体化协同平台也只是企业数字化转型中的一环，因而在企业数字化业务场景中，一体化协同平台会存在大量集成、被集成、定制化的需要。咱们能够从 webhook、OPEN API、UIKit 三个维度建设零碎的扩展性，以应答扩展性的挑战，比方不同部门心愿有不同的度量大盘，而依附平台对立建设会十分迟缓，此时平台只须要提供对立的 UIKit 和数据拉取 OPEN API，最初的度量大盘可交由部门外部闭环建设。
可度量
德鲁克说：“如果不能度量，就不能无效治理”，可见度量的重要性。基于闭环工作流引擎产生的残缺数据，企业可从价值流动散布、价值流动效率、资源耗费三个维度，对软件价值交付、过程治理、研发老本进行度量，达到资源优化配置、研效继续治理、继续优化软件研发老本的目标。
高可用
一体化协同平台间接影响企业的 SLA 和产品交付效率，如果平台不稳固，则会对企业的市场造成十分顽劣的影响。比方，金融公司受股市周期影响，个别发版工夫都会在周末，周一到周四为研发工夫，周五下午休市后为集成工夫。如果周五平台的继续集成模块呈现故障，导致无奈构建，将会间接影响周末两天的产品公布。最顽劣的状况是，线上有故障须要 hotfix，然而平台进行运行，这时靠手工简直无奈疾速复原生产。以继续部署为例，当初很多企业都是混合云部署，即一次公布可能要跨多个云厂商、可用区和集群，为了保障交付的可靠性，两头可能还要执行各种公布策略，这绝不是靠人工能够实现的动作。那么，如何保障平台的 SLA 呢？
首先，倡议把 IaaS、PaaS 的稳定性交给云，业余的“人”做业余的事。
其次，控制软件复杂性，尤其是微服务的规模和中间件的技术选型。微服务的呈现对平台型产品的演进速度有较大帮忙，因为平台的功能模块多，微服务能够帮忙模块独立演进和独立交付，然而一旦呈现微服务规模爆炸，其自身对架构的挑战将会十分大，故障排查和公布物料组织都会十分慢。另外是中间件的选型，笔者已经看到过一款 B 端软件的数据存储计划就有 MariaDB、MySQL、PGSQL、MongoDB、Redis5 种，这些中间件的性能存在大量的反复建设，且最终运行的稳定性不足兜底策略，间接影响平台的稳定性。
最初，建设残缺的可观测性和灾备。没有故障的平台是不存在的，呈现故障疾速复原才是王道，因而倡议除思考平台性能外，也须要思考监控、日志、告警、调用链追踪等可观测工具的建设，优化故障排查效率，早发现，早复原。如果切实不能复原，则倡议为平台建设灾备能力，如跨云、跨区筹备灾备实例，一旦呈现问题能够疾速切换灾备零碎，复原生产。
实现形式
一体化协同平台的性能全景如图 10.7.9 所示，提供从我的项目协同、开发、构建、测试、制品、部署的全流程协同及研发工具撑持。
图 10.7.9 一体化协同平台性能全景
目前，搭建一体化协同平台的次要形式有洽购商业计划和自建平台。这里以腾讯云 CODING 的商业计划为例，从投入产出、回报周期、保护老本等多个维度与自建平台做差别比照，如图 10.7.10 所示。
两个计划的差别非常明显，绝对于自建，商业计划的投入产出比更加清晰可控、回报周期更短、前期保护老本更低。企业在两个计划之间的抉择实质上是研效治理估算，即在商业计划的“确定性”和自建计划的“不确定性”上进行抉择。
图 10.7.10 商业计划 VS 自建计划
商业计划个别都会积攒很多企业研效治理的教训，产品状态更加成熟，个别都会提供 SaaS 和私有化交付两种形式。企业可依据本身需要进行交付形式抉择，如无数据隔离和行业合规强制要求，倡议抉择 SaaS，其交付周期更短，后续保护老本更低。另外，商业计划也能够对企业的非凡场景提供定制化服务。对于企业而言，规范需要通过规范性能匹配，非标准需要通过定制需要匹配，最终投入产出比“确定性”是比拟高的，且交付周期更短，保护老本更低。对于 SaaS 状态的交付，企业简直没有保护老本。
而自建计划受限于企业的研效认知和团队成熟度，企业需经验一个较长的心智爬坡和试错周期，能力找到正确的研效治理门路，资源投入和试错老本都比拟高，投入产出比的“不确定性”也较高，短时间内无奈预估一体化协同平台生产可用的工夫。笔者已经见过企业投入 100 多人的团队自研一体化平台，每年的投入在 1 亿元以上，而受疫情影响，外围业务膨胀，平台建设叫停，期间昂扬的投入没有产生任何收益。在头部公司都在讲“聚焦”的时代，如果把这些估算投入到外围业务上，则更能帮忙企业进步市场的竞争力。
最初，如果企业的研效治理需要大部分可通过商业计划匹配，倡议抉择商业化计划，其投入产出比会更加“确定”；如果需要匹配度不高，且企业有短缺的研效治理估算，对研效治理的失败有足够的容纳预期，也能够尝试自建。
一体化协同平台倒退方向
近两年，BizOps 和 FinOps 的呈现代表一体化协同平台正在从关注软件研发外部的流程化、自动化、标准化，向买通业务和优化云老本方向倒退。如果从经济学“生产”的定义来看，一体化协同正在从软件研发外部（生产过程），向整合市场需求及生产因素的方向倒退。能够说，一体化协同平台的发展趋势正在回归“生产实质”，即生产发明价值。
BizOps
一体化协同平台通过突破“组织墙”和“工具墙”，使软件研发变得高效有序，但高效并不解决无效的问题，企业冀望能将软件研发和组织策略、市场需求、用户反馈买通，使软件研发不仅高效而且无效。
2020 年，BizOps 宣言提出了业务驱动研发、研发价值数字化、数字化驱动业务增长的核心理念，突破了业务与软件研发之间的隔离，使软件研发过程中的业务价值流动变得清晰通明。企业能够通过洞察业务价值流动速率和业务价值流动散布，进步策略业务的资源投入，升高有效业务的资源投入，实现资源优化配置；通过研发价值的数字化，评估软件研发对业务价值的奉献，比方业务策动的“拉新”流动上线后，通过经营零碎和一体化协同零碎的买通，企业可依据新增用户的规模变动，直观评估软件研发对业务的奉献，软件研发人员的价值举证也将变得简略可信；通过业务和软件研发的全流程数字化，企业进步了业务全流程“生产数字”的能力，再配合大数据及人工智能技术，进步“生产数字”的能力，最终实现数字驱动业务增长和数字驱动软件研发效力降级的目标。
FinOps
明天，云计算的趋势已势不可挡。Gartner 的调研报告显示，2022 年年底，寰球企业的云计算收入将约为 3300 亿美金，但受限于企业对云计算自身的认知及本身利用模型的特色，大量企业存在云计算估算超支和资源利用率严重不足的状况。
FinOps 买通软件研发、财务和业务，使企业的云计算成本散布变得清晰通明，并可借助软件线上运行历史数据，主动预测负载波峰和波谷，实现云计算资源的弹性扩缩容，将云计算应用形式从“按使用量付费”变为“按业务需求量付费”，优化企业云计算成本。
2021 年，腾讯云推出的云原生老本治理产品“老本巨匠”正是 FinOps 的典型代表。“老本巨匠”从老本洞察、老本优化、老本经营三个层面来帮助企业做更好的老本治理，具备全链路的老本优化能力，可能准确、智能地进行老本洞察，一分钟发现资源节约并提供 8 种弹性策略组合，满足任意场景的弹性需要。其外围能力 qGPU 是强隔离的 GPU 虚拟化技术，该技术在业内首次实现了 GPU 算力、显存和故障的强隔离，反对算力精密切分共享和多优先级混部，GPU 利用率最高可晋升 230%。
作者：吴海黎
本文章节选自 QECon 出品《软件研发效力权威指南》一书，《一体化协同平台》章节。
