DevOps落地之五大基础保障体系建设

Posted 2023-03-07 DevOps落地与转型

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了DevOps落地之五大基础保障体系建设相关的知识，希望对你有一定的参考价值。

技术保障体系建设对于技术团队来说至关重要，为技术团队的交付效率、研发质量、系统稳定性以及资源成本做保障，很大程度上决定着技术团队的研发效能和技术体系的运转效率。互联网时代的业务形态变化快，对质量、效率、成本的要求更高，技术保障体系的作用越来越大。同时，DevOps 在各大互联网公司已经成为技术团队开展数字化转型和研发效能提升的可行性指导方法，进而也可作为技术保障体系建设的实施框架。

背景

作者曾就职于一家国内知名餐饮互联网公司，致力于餐饮产业全环节信息化、标准化和创新化的企业，技术团队规模500+。如同大多数创业公司一样，初期以追求满足业务快速上线为主，很难放缓脚步进行全面的技术体系建设，更没有充分时间进行技术保障体系建设。随着时间的推移，技术上的缺陷逐渐暴漏出来，甚至影响到业务的发展。

具体表现为如下6点:

系统编译、部署方式复杂，上线成功率低且耗时较长，一次上线经常持续到深夜。

缺少高可靠体系建设，故障发生时恢复时间较长甚至难以恢复。

IT资源管理混乱，带来严重的管理及安全风险。

研发缺乏有效的工程实践方法，研发效率和质量亟待提高，短时间内靠招人解决。

集中交付的研发模式以及强瀑布的项目管理方式无法满足频繁变更的业务形态。

技术团队的管理方式比较粗犷，缺乏有效的方法体系和平台工具支撑。

为解决这些问题，作者作为研发效能负责人，引导技术团队进行DevOps转型，通过组织的工程实践能力、制度体系、流程规范、平台工具几个方面进行了技术保障体系的建设规划。经过团队全员1年多的努力，初步完成技术保障体系建设。

本文将从5个维度讲述建设技术保障体系的方法。

技术保障体系包含5大基础保障体系：代码质量保障体系、测试质量保障体系、自运维管理体系、度量指标体系、稳定性体系，为技术团队的工程实践能力提升、产品研发流程规范落地、项目高效管理、研发效能提升等做保障。（限于篇幅，将概括性讲述）

同时，基于技术保障体系，作者主导搭建了技术团队的质量保障体系和精益运维体系（作为技术运营体系），作为技术团队研发质量和效率管理、系统稳定性管理的运营手段。作者通过项目（质量保障项目和精益运项目）的形式推进2个体系的周期性运转，同时希望通过大齿轮带动小齿轮的方式，确保技术保障体系的稳定运转。此部分，将在后续文章分享。

基于技术保障体系的质量保障体系

在管理方式上，以分层度量管理的方式驱动技术团队的反馈和改进：在CTO 层面，组建推进小组，把控改进方向，协调过程中问题解决；在技术部门负责人层面，通过部门质量分驱动发现问题和协调资源；在团队小组负责人层面，通过工程实践方法和平台工具最佳实践的方式，提升团队的工程实践能力和自运维能力，解决他们遇到的阻碍性问题。

下文将分别介绍技术保障体系中各基础保障体系的建设过程。

代码质量保障体系

对于技术团队而言，代码质量的重要性不言而喻。不过，在技术团队落实代码质量保障体系之前，研发团队表现出严重的问题。

集中交付的研发模式导致研发人员集中提测、集中上线，问题也会集中爆发，往往因为上下游服务依赖、协作沟通不畅导致项目上线延期。

研发提测质量差，导致测试时间严重压缩，职能间出现互相抱怨现象，协作效率差。

技术团队的改进，往往是脚痛医脚头痛医头，陷入局部优化的困境。并且，技术团队尚未掌握通过平台度量驱动团队改进的方法。

作者给出的解决方案是建立技术中心的代码质量保障体系，结合工程实践、流程规范、平台工具相结合的方法，通过分层度量驱动不同层级负责人发现问题和改进问题。同时，通过项目的形式推进代码质量保障体系稳定运转和落地。

代码质量保障体系

1）通过自运维管理等平台（CI）和单元测试能力的提升，培养一线研发人员代码持续集成、频繁构建的研发习惯，提前暴露研发过程中问题。

2）围绕代码生命周期设置质量门禁，比如在代码提交阶段，通过构建流水线中质量门禁自动把控研发人员每次提交代码的静态质量、单测、构建耗时等问题，质量门禁不通过则构建直接失败。并在团队内部实施每日构建一次流水线等原则，将问题的解决分布到日常。

3）专项项目治理，质量推进小组每周通过分层会议，分层管理技术团队二级和三级负责人。协助二级负责人分析各部门问题，协调问题解决资源，推进技术重构和代码评审等实践落地；赋能三级负责人工程实践方法，分享共性问题解决方法，协助解决阻碍性问题，推进单元测试、频繁构建、接口自动化测试、代码评审等实践落地。

4）通过部门代码质量分（各代码质量指标、质量待办等的加权综合值）作为部门代码质量的考核标准（平台扫描出来质量问题，作为减分项；部门内部通过实践执行标准发现的问题，登记为质量待办，作为加分项，鼓励提前暴露问题；待办延期完成则作为减分项），也作为作者推进各技术部门落地保障体系的抓手。

基于项目的周期性运转和推进，代码质量保障体系中工程实践方法和平台工具也在技术团队各层级执行和应用起来，以此形成技术团队的代码质量保障工作框架。

代码质量保障工作框架

在二级部门负责人会议上（处理过程），作者会提供质量分析报告以及各部门质量分（诊断过程），针对报告分析内容以及当周各部门形成的质量待办进行定性定责（仅限之前会上未确定优先级和负责人的待办），最终将问题都落实为平台质量待办，并确定计划完成时间。作者作为项目经理会持续跟进质量待办的完成情况，协调资源，协助问题解决。

代码质量保障体系管控着代码从“编写”到“发布”阶段的质量问题，为后续质量保障体系的建立打下基础，也是效能团队在技术团队成功建立的第一个保障体系。

作者将此段故事进行了提炼和总结，作为书籍《DevOps落地与转型——提升研发效能的方法与实践》第1章的故事主线，其中详细讲解了代码质量保障体系中工程实践、流程规范、平台工具的落地执行过程以及实施策略等。

测试质量保障体系

当开发人员已经养成“频繁构建”的工作习惯时，测试团队大部分还处在手工测试阶段。为了让测试角色能够适配新的开发模式，产研团队必须进行测试左移实践能力的提升。经过作者调研，发现如下几点问题。

1）从全局看，技术团队的产研流程规范则强调强瀑布式的研发模式（PMO制定管理），开发人员完全提测完后，测试人员才能介入本次的测试流程。

2）从过程看，测试团队在技术团队比较弱势，往往成为上线延期、质量问题的受害者。

3）从局部看，由于测试过程全都是手工测试，之前为解决开发提测延期问题，招聘很多测试人员，当业务处在休整期时，资源利用率不高。

作者综合产研流程规范、测试人员能力、平台工具等维度，给出如下解决方案。

1）与PMO部门协作，优化产研流程规范，强调各角色左移活动环节，提前关注质量。

产品技术评审线：改造之前的评审方式，增加横向拉通的评审会议（比如增加全局的产品方案、技术方案评审），重新定义各负责人职责（测试负责人需提前介入上游活动环节）以及过程完成标准（关键环节的质量准入标准）。

测试流程线：改变之前的测试流程，将测试活动进行细化，按照执行顺序将用例管理、用例评审、制定测试计划过程进行分解，定义每个测试活动的参与角色。

2）与测试部门负责人协作，找出具有测开能力的测试人员，从技术中心维度组建自动化测试组，针对核心业务场景实施自动化测试，降低大量重复的回归测试时间，培养测试团队接口自动化工程实践能力。适配研发过程频繁构建、频繁验证的需求。

3）将测试过程的产研规范落实到在线测试平台。打通测试平台和自运维管理平台，将接口自动化测试计划接入每次部署流水线，实现自动化集成测试。

4）为解决测试人员编程能力弱问题，前期脚本实现由开发配合测试共同完成，形成结对编程；为解决上下游接口调用实现问题，组织开发提前实现场景化接口依赖的SDK；为解决造数问题，组织测试间互相提数据需求，由各测试人员实现并维护到平台造数中心。

以此形成技术团队的测试质量保障体系。此后，各部门接口自动化测试结果也作为代码质量保障体系考核的一部分，并由作者作为项目经理推进开展。

测试质量保障体系

作者将此段故事进行了提炼和总结，作为书籍《DevOps落地与转型——提升研发效能的方法与实践》第2章的故事主线，其中详细讲解了测试左移实践过程中各角色职能职责的变化、产研流程规范的改进、在线测试平台的落地以及接口自动化测试实践的实现等过程。

自运维管理体系

2021年初，技术团队决定业务上云，并要求在第二季度完成全面迁移某云。上云对于任何没有相关经验的技术团队来说都是巨大的挑战。这种挑战不仅来自底层技术架构能力的改变，还有产研间的协作方式和研发模式的改变。只有寻找到能够适配云环境的管理模式、工程实践方法以及工具平台，上云后的降本增效作用才能够真正体现出来。

技术团队上云面临挑战的主要是技术体系的改造和适配，也就是技术保障体系和技术支撑体系的改造。因为只要技术保障体系和底层架构改造适配的好，就能够降低技术团队的上云门槛，研发人员只需了解一些基础的云原生相关背景知识，即可像原来一样工作。对于技术保障体系的改造，效能团队面临的挑战如下。

1）需要充分理解云上研发、云上运行服务的特点，充分利用其服务化、自助化、弹性伸缩以及资源共享特性，充分发挥公有云已有的功能，帮助技术团队屏蔽掉云原生相关的“专业”门槛问题，比如构建部署模式改变、配置管理升级、系统架构重构适配、安全风控担忧、资质认证、权限管控等方面的问题。

2）需要深入改造自运维管理平台（CI/CD），如何在不影响技术团队当前“研发习惯”的前提下，通过DevOps工作框架协助技术团队实现云环境下的协作模式和研发模式转型，进而协助技术团队实现团队自治，培养自运维能力。

作者综合技术团队持续集成的研发实践、基于虚拟机维度的平台部署实践以及技术团队的研发管理模式，给出如下解决方案。

1）基于GitLab 的CI/CD模块快速搭建基于Kubernetes 环境下的构建和部署平台，满足研发团队上云的基础诉求。同时，通过平台约束流水线触发规则、流水线终止操作规范、服务统一暴露方式等，避免影响到之前的产研协作效率和代码提测质量。

2）组织CTO和技术部门负责人讨论有关自运维管理平台改造升级的问题，确认改进方向，主要确认技术团队CI的实践理念，即快速集成、频繁构建、质量内建和快速反馈；以服务为中心建设CI/CD 平台，这个思路不仅要改造此平台，还需要改造CMDB等。

3）通过平台改善之前强职能部门间的协作方式（组织架构也要做相应调整），云环境下研发模式强调研发人员自运维，提升技术团队整体的自运维能力，弱化职能运维的管理。

结合技术工程实践和平台工具的改造，为技术团队落实自运维管理体系。

自运维管理体系

作者将此段故事进行了提炼和总结，作为书籍《DevOps落地与转型——提升研发效能的方法与实践》第3章的故事主线，其中详细讲解了平台如何实现如上技术工程实践提升研发效率、保障技术团队的研发质量，研发人员如何通过平台实践自运维管理等。

度量指标体系

在软件开发领域，特别是研发效能领域，度量是一个无法回避的话题。

研发效能领域的实践者和软件领域的管理者只有掌握如何建立度量指标体系、如何选取关键的数据指标、如何做好度量运营以及掌握实践过程中的指导原则和方法，才能够从全局视角协助并驱动各层级管理者发现和解决团队中的问题。

在技术保障体系度量改进过程中，逐渐发现如下几个严重问题。

1）对于技术团队管理者来说，针对每个体系的度量指标都比较难以达成一致，缺乏有效的实践框架，核心问题在于缺乏对每个效能域的实践认知。

2）各平台拥有独立数据库，都有相应的度量模块，模块间缺乏有效的关联性，平台间的指标获取比较繁琐，需要互相提供API接口。

3）每次度量指标需求的实现都需要平台前端发版上线，灵活度不高。

团队采用轻量数据 ELT 形式，将业务系统的数据经过抽取、清洗和转换之后加载到数据仓库，实现“实时数据”和“T+1数据”的集中获取。表现层通过BI工具Metabase集成到各平台前端，指标变更只需调整Metabase数据逻辑规则和可视化方式即可，解决每次需求实现均需平台发版的问题。另外，针对研发效能域、持续交付域以及项目交付域，经过实践都落实了度量模型和指标，并且在研发管理体系、质量保障体系、项目管理体系中应用。同时，通过平台间消息（度量指标信息）驱动负责人和研发人员及时发现、反馈和解决问题。

以此形成度量指标体系，更便捷可靠地支撑技术保障体系稳定运转。

度量指标体系

作者将此段故事进行了提炼和总结，作为书籍《DevOps落地与转型——提升研发效能的方法与实践》第4章的故事主线，其中详细讲解了平台如何搭建度量指标体系、如何选择合适的研发效能度量指标以及如何通过闭环消息驱动团队改进等。

稳定性支撑体系

公司经过一年的发展，技术团队已经初具规模，随着业务量的增加，告警事件和线上问题频繁发生，各技术部门也开始频发故障。每次研发核心例会上，各部门负责人经常会针对一个线上问题是哪个团队引起的而争执不清，因为每个问题的发生都是多面性的：可能是外部环境问题，可能是上下游服务依赖问题，也可能是整体技术架构问题。

从技术保障体系来看，作者在与技术团队做复盘过程中发现如下问题。

1）技术体系中以CMDB为中心的运维基础服务体系理念已经基本形成，并且CMDB已经完成以服务为中心的轻量化改造，但技术支撑体系的资源管理平台尚未进行适配，导致研发人员需到各资源管理平台自行管理操作，并且没有对接工单审核，很容易导致线上故障。

2）当系统稳定性较差时，各种监控告警信息、平台消息、故障信息对研发人员形成了消息轰炸，没有一个平台能够承载这些事件的管理、指挥解决以及知识沉淀，导致问题的处理效率较差。经调研，重复出现的同类型故障数占总数的13%。

3）部署过程规范线下约束较弱，部署前检查、部署过程中审核、部署后监控流程执行不到位，导致线上问题80%都是由于人为因素导致。

作者综合复盘结果，决定立项，通过精益运维项目推进稳定性体系的有效实施和落地。

1）联动架构运维团队组建资源治理专家组（分布式中间件、mysql、虚拟机、日志等），改造各平台对接CMDB和工单系统，通过工单约束服务资源的申请、审核和解绑，将所有服务依赖的资源数据落实到CMDB，作为元数据管理，以CMDB作为技术体系全局唯一权威数据源。同时，CMDB支持定期与云平台和资源管理平台进行资源的自动化校准，保证数据的可靠性和唯一性。

2）搭建事件管理平台，收集和获取全面的事件数据，协助事件“指挥官”更加精准地进行事件指派；针对核心业务场景指定技术负责人作为指挥官，提高问题的解决效率；当问题定性为故障时，需走故障应急流程。同时，研发人员可以根据事件管理平台自查询分析历史共性事件的解决方案；并且通过分类，很容易度量分析各部门线上问题和故障等。

3）将部署过程中流程和规范的检查在自运维管理平台实现线上化管理。

以此形成稳定性支撑体系。同时，稳定性支撑体系将技术团队进行的压测、故障植入、故障应急响应、故障复盘等工程实践的结果作为事件源，纳入稳定性质量管理流程。