01. bizdevops概述
it技术交付实践方法在不断迭代中持续优化。在工业化时代，biz（业务）、dev（开发）、ops（运维）三者往往相对分离，甚至有时只有其中的两者或仅有一者独立存在。然而，随着时代的演进，互联网化时代带来了敏捷的先进思想，推动了业务与技术的初步融合。devops等理念则进一步促进了开发与运维的深度融合，打破了组织壁垒，提升了团队协作效率。如今，在数字化时代，我们更加注重以业务为中心，实施精益化、平台化、一体化的管理模式，以更好地满足业务需求。业务与技术之间的链接一步步紧密，这是业务竞争与技术发展之间的双向奔赴。bizdevops也应运而生。
从字面意思理解，bizdevops即业务研发运维一体化，是一种倡导业务、开发和运营三个工作域拉通互联的方法论。但若想真正落地一个扎实的bizdevops绝非易事，如果没有强健的纵深的建设，横向的拉通将无法真正体现其价值。本文将从基础devops的视角，对bizdevops的进阶建设提供思路。
02. bizdevops纵向建设
1）biz的纵向建设
从一些研发组织视角来看，与业务之间的交集似乎只在于需求的评审及最后的验收阶段，事实上，对于较复杂的业务场景梳理可能远比研发更头疼。在数字化转型的背景下，这些业务场景也越来越需要研发的技术、数据的支撑。
与研发侧最近常被提及的平台工程类似，业务也有自己的平台工程或业务中台，包含创意供给平台、产品信息中心、内容营销洞察等等。而这些平台所支撑的企业最核心的目标愿景便是企业的整体战略，这其中业务创新又是大部分企业最重要的一个战略方向。
同样类似于dev的建设过程，业务也需要与业务中台匹配的实践，dev中的敏捷、精益等思想同样适用在业务的纵向建设。而与dev“标准化”为目标的区别在于，biz的这些实践更多是为迸发更多的创新点。
2）dev的纵向建设
devops如今已是滑过了gartner软件成熟度曲线的“peak of iflacted expactations”，但国内很多组织的devops基建仍处于建设期，且相对于国外，国内的devops更聚焦在dev：
- 对于devops工具链模块明显缺失、研发过程管理缺少规范的组织，选择基于成熟的开源或商用一体化devops平台，并配套最佳实践，是快速构建devops基础能力的较佳选择。具体的建设内容可划分为需求管理（兼备敏稳双态管理）、持续集成（以流水线为核心串联自动化工程工具）、测试管理（与需求之间更紧密地联动）、制品库（一、二、三方库统一管理，保障交付物可信度）等模块；
- 对于已具备完成工具链路的研发组织，则需要为后续的横向拉通做准备，为节约后续横向拉通的成本，首先需对自身交付过程进行端到端的贯通。主要为dev中的流程与工程的融合，要尽量做到各个阶段的标准化建设，可以结合敏捷实践、精益思想使工具发挥其最大价值，同时通过需求池及业需评审实践，初步与biz建立连接。
3）ops的纵向建设
传统的运维域已有丰富的场景支撑，如cmdb、itsm、监控告警体系等。而在数字化背景下，ops除了运维之外，还被赋予了运营的使命。通常的运维建设中，cmdb是基石的角色，cmdb中的“c”是capital（资产），而被消费的才能称之为资产。因此一般运维的建设路径是从cmdb出发，之后根据实际的运维消费场景对运维工具进行扩展。同时ops侧的规范化要求要远高于dev侧，一系列的体系规范如itil给出了指导方向，因此，传统ops相较于dev的异构化兼容（包含了工程、流程、文化等）会有更明确的建设方向。而运营上，可以分为技术指标和业务指标，技术指标在于dev、传统ops的进度指标及软硬件健康情况等；业务指标在于用户分析之类的埋点，以及需求后评价。
03. bizdevops横向建设
基于bizdevops的横向拉通方式：biz、dev、ops三者的拉通可以分成上中下三层。
1）上层为目标层
从战略出发统一目标，各类角色基于一致的模型理解bizdevops，对齐实施目标和策略步骤，帮助组织形成共同语言，保证对同样的概念有统一的理解，提升沟通的效率和效果，制定有效和可落地的行动计划。以研发角色为例，不仅要从单一需求的角度对其价值进行判断，更要以业务视角对整个需求的业务关联有一定认知。
2）中层为价值流层面
从biz的创意点——dev的研发工程——ops的各平台之间要相互连接并对齐目标，比如：
- biz中创意平台中的创意点以需求池的形式同步到dev的需求管理，同时将biz及dev的流程串联在一起；
- dev和ops之间以制品的形式进行自动化同步晋级，保障交付物的单一可信、可追溯；
- ops的需求后评价与biz的实际价值形成闭环反馈，技术人员可以更直观认知到自己的工作对业务产生的贡献。
以上信息都可以通过价值流引擎串联，从而以业务整体维度去识别卡点。同时，也要基于上层的统一的模型，纵向检查当前实践中缺失或薄弱的点。
3）下层的沉淀与维护
下层主要是基于上层的价值流架构，拉通中层梳理的网络关系，基于完整的模型，识别组织的核心数字资产，并持续沉淀和维护这些资产，如业务架构、研发架构、过程产出物等。
04. 结语
由上述内容可见，bizdevops的建设并非一蹴而就，它需要长时间的积累与努力，并对各角色人员的能力提出了明确要求。然而，其带来的价值也是显而易见的，回报丰厚。显性上：在biz、dev、ops纵向上做的沉淀都将有形地得到贯通、理顺，让每一个纵向节点产生的价值真正从全局维度带来收益；隐性上：有统一的工作语言、统一的平台串联，跨部门沟通将较传统“devops”进一步提效，而新的技术势必会提高人才的吸引力，人才梯队建设也会更加扎实。
