1、华为云端到端DevOps实践

华为创建于1987年，当时做软件开发用的都是瀑布流。到了 2000 年左右，引进了 IPD 开发模式，这个模式用了很久，降低了研发费用的同时提高了效率。10年前后，CI、CD 的理念传播过来，开始采用其中的一些原则，改变了开发方式。后来 DevOps 的理念也传播过来了，华为不同的部门根据自己的业务情况，逐渐转型微服务化、云原生、使用容器等多项最佳实践。

1.1、多种商业模式敏捷 & DevOps 转型匹配

那华为用的就是 DevOps 方式吗？其实我们并不能一概而论，因为采用什么开发方式是和商业模式挂钩的，特别是像华为这样一个大体量公司来说，不同的部门、不同的业务情况是采用不同的研发模式的，所以我们现在将其剥析开发，看看它有哪些商业模式

卖产品。

• 软件：TTM 缩短驱动力（3~6月）
• 硬件：版本火车模式（6~12月）
• 卖服务：DevOps（周~1月）

所以我们可以看到并不是说整个华为都在用 DevOps。

1.2、华为云 DevCloud 团队的规模化成长历程

华为云 DevCloud 是华为对外开放出来的开发者工具。这个工具原本是内部使用的，后来慢慢转为商用，并且根据市场需要增加功能，团队也在逐渐扩大。下图为华为云DevCloud 团队的规模化成长历程；

DevCloud 发展历程；

• 07 公测：只提供项目管理、代码托管、编译构建服务；
• 09：正式发布；
• 12 1.0 版本：增加代码检查、部署服务、发布服务，代码托管等功能；
• 09 2.0 版本：移动应用测试发布、Wiki 特性发布、文档管理特性发布；

1.3、华为云实现全流程 DevOps 平台

通过华为云 DevCloud 实现全流程 DevOps，包括从需求规划到开发、测试、发布、运维、运营、反馈，整个这一套流程，至今包括超过 15 个服务，实现端到端的 DevOps。

1.4、华为云支撑企业数字化转型

企业数字化转型是一个复杂的系统工程，涉及到研发流程、研发模式、商业模式、组织和文化的变化，不是一蹴而就的事情。要通过小步快跑、持续迭代、平滑演进、持续改进，这种方式来推进。

华为云支撑数字化转型步骤，从产品的研发到业务及最后的运维运营，全打通实现端到端的闭环，拆分微服务化，每一个子业务都可以根据实际需要进行独立发布和维护，全行业场景应用汇聚，业务上云平滑演进。这一步常面临的问题是缺少统一的设备信息集成途径，数据格式多样化，难以传输和集成，缺少与合作伙伴分享数据和后端服务的便捷途径，缺少云上云下跨网络的安全信息通道。通过 ROMA 平台，聚焦应用和数据链接，适配多种企业常用的使用场景，它可以提供轻量化信息、数据、API、设备等集成能力，简化企业上云，支持云上云下、跨区域集成。

1.5、DevOps 全流程交付模式

首先看流水线：从源代码到构建，不同环境的部署、测试，最后发布到生产环境，这条线都提升到流水线上，看着很简单，但涉及到的开发活动一点都不简单。

研发活动：代码管理，二进制软件包构建，功能、性能等安全验证，各级门禁控制质量的参与的角色有三个：

• SDE（开发）：开发团队参与整个过程的所有环节，包括微服务自己的功能测试及集成测试部分；
• I&V（测试）：测试团队主要参与的是安全、可靠性等测试；
• SRE：从类生产开始介入；

迭代过程：需求分析、设计到编码，编码完毕之后，每一天代码都提交主干一次，并做完微服务的自验并要求通过质量门禁，通过测试的代码要发布到生产环境需要的时间是 小时级。

1.5.1、规划与设计

先从各个渠道收集需求，然后由产品经理评估是否接受，然后由 UCD（User Centered Design） 进行设计，设计完进入评审，评审通过后排入交付计划，然后进行开发、测试、发布到生产给客户使用，最后收集客户的反馈信息再回到收集阶段，帮助产品经理做下一轮的以及未来产品的设计。

a、需求流动过程管理

• 上图为一个漏斗来展示上面提到的过程，蓝色部分为评审或澄清的步骤，评估优先级是非常重要的，因为需求来源太多，产品经理需要评估出哪些需要做、哪些需要先做
• 需求优先级排序：业务优先级
  • 问题 > 需求
  • 解决方案需求 > 产品需求
  • 跨服务依赖需求 > 独立需求
  • 清晰需求 > 不清晰需求
  • UCD 完成需求 > UCD 等待需求
  • 80% 功能需求 + 20% 体验需求
  • 价值用户需求 > 普通用户需求
  • 通用需求 > 定制需求

b、需求分层管理

• 需求分层管理
  • 主要分成业界通用的 Epic、Feature、Story 三个需求层级
  • 视情况允许独立的 Story 存在，不是非要分解出三级需求，大部分的需求都是直接以 Story 分发
  • Story 拆分过程中要符合INVEST 原则
    • Independent（解耦）：尽可能拆分独立的用户故事，尽量避免依赖
    • Negotiable（易交流）：使用用户语言描述，让用户、产品、开发、测试各角色方便理解交流
    • Valuable（传递价值）：用户故事要关注带来的用户价值或解决的问题，而不仅仅是功能
    • Estimable（易估算）：足够小和清晰让开发、测试都容易评估工作量、优先级
    • Small（足够小）：用户故事要在1个迭代内可以被完成，有助于小批量开发和交付和响应变化
    • Testable（可测）：用户故事应该包含一个可被测试和验收的小场景，否则无法确认其完成时间
  • 任务允许以 Story 直接分发，不是一定要拆分出 Task
• 需求分层责任划分
  • PD（产品负责人）：负责维护 Epic、Feature、Story，应用于产品 backlog 和迭代 backlog
  • SL（Servers Leader）：关注进入迭代的 Story 分配及 Task 拆解，关注交付优先级，关注技术和方案层面的任务和对交付的影响
  • Developer（Test）：关注迭代中分配到的 Story 和 Task 的评估、方案和开发交付，完成后要修改对应状态

c、华为敏捷项目管理 Scrum 框架

• 华为敏捷项目管理流程，基于 Scrum 框架进行交付侧扩展
• 融合了 DevOps 的新型敏捷模式强调持续交付 CD（包含持续构建、测试、以及持续部署、发布、反馈），加速了产品推向真实用户，并及时获得海量反馈的决策数据源，比仅仅依靠 PO 或者少数粉丝用户反馈的决策准确率大为提升
• 整个框架的运作流程如下：
  • 首先，PD（产品负责人）会从用户、一线运维团队等等去收取反馈信息，他基于这一反馈信息去做决策，制作出产品代办列表，做出发布计划，在每一次迭代的时候选取最高优先级的需求，生成迭代待办列表，在迭代会议上，团队在待办列表中选取、认领需求；
  • 进入每周迭代开发后，每天都会有站会去沟通当前的进展（需要注意，回顾会议是不定期进行开展，项目团队比较成熟的时候开的频率会相对低一些）；
  • 每一周开发完毕之后产生的都是经过测试的代码，然后这些代码可能会根据业务情况来决定是否直接发布生产，往往会先将这些代码发布到内部的不同环境，比如经过 α 环境、β 环境的测试之后，将代码部署到内部的使用环境，DevCloud 团队将自己先使用这些新功能；
  • 在工作过程中，每当一个团队有新的功能在内网发布的时候，都会通知整个团队，欢迎大家去测试反馈；
  • 经过 PD 验收，推送到生产环境给客户使用；
  • 最后上到生产之后，再通过一些渠道获取用户反馈给到产品经理；

d、团队 - 重塑角色设置，拥抱敏捷和 DevOps

• 以 SA、PD、SL 形成的铁三角；
• 交付以服务 为中心，而不是以项目为中心；
• PD：Product Owner，产品负责人/产品经理：负责产品规划、设计、分析；
• SA：负责客户场景及解决方案，跟客户沟通，获取一些反馈和帮助客户解决一些问题；
• SL：微服务/特性经理Service Leader，兼任敏捷Scrum Master，带领团队进行开发；
• Sponsor：干系人（项目/业务/服务）；
• UE：UCD(User Centered Design)工程师，负责用户研究、交互设计、美工、视觉；
• SE：技术leader，系统工程师，负责架构、系统设计；
• 开发：负责代码实现；
• 测试：负责测试验证；
• 运维：负责部署、发布、运维、监控；
• 上述这些并不是具体的某些角色，而是工作。比如有测试工作、开发工作，并不代表团队里面有专门的开发人员或专门的测试人员，并不是说每个团队里面一定要有某一个角色去做开发或者做测试，而是一定要有这个工作，，也许开发人员同时做着开发和测试的工作，或者说在 DevOps 中，开发人员常常是开发、运维、测试三个事情都能一起做；

e、团队 - 逐渐转型为自主经营的全功能团队

1.5.2、 开发与集成

架构解耦是敏捷的保障

• 架构与系统解耦，做到组件化，乃至微服务化：实现松耦合，可并行开发、构建、测试、部署、运行的最小可运行产品/特性；
• 需求分解的原则：需求分解遵循小步快跑，同一个特性可以由多个迭代 story 逐步演进，从简单可用、到功能完善；
• 演进过程
  • 最开始前后台开发人员各为一组，每次更新的时候，前后台将各自需求更新出来，然后将代码合到一起；
  • 服务化改造：使用云化产品交付模式，以一个周期（一到两周）为版本火车一起发布；
  • 微服务化，每一个服务包含前后台开发，并和其他服务间彻底解耦，产品功能比较完善，团队 DevOps 能力也有。

DevCloud 能力构建

• 一个中心，三个要素
  • 价值交付为中心：是否采用云原生由业务 决定，合适的情况下才使用
  • 架构、组织、工程三个要素
• 架构
  • 采用服务化架构/微服务架构实现全面解耦
  • 通过API，采用云原生公共服务提供的基础能力和架构能力
  • 使用自服务、敏捷的云化基础设施服务
• 工程
  • 系统与环境、流程、配置解耦
  • DevOps 实现运维和开发互相融合
  • 实践极速迭代，持续交付，快速响应业务变化，缩短 TTM
• 组织
  • 全功能团队
  • 云化运维团队

CodeHub 代码管理

• 代码在线检视；
  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-sGcKdjsU-1635058053402)(https://files.mdnice.com/user/1631/c45c7e55-464a-4b02-8516-dd497a2b9e02.png)]
• 设置代码合入门禁，必须达到最低评分才能合入；

分支管理

• 生产环境使用 master 分支，每个人在开发的时候由 master 分支直接拉出来特性分支（feature）进行开发，开发完毕之后，合并到之前 master 拉出来的 develop 分支（从特性分支合并到开发分支）。如果代码提交到 develop 分支的时候通过了测试，代码可以继续选择向发布分支（release）上进行合并，从 release 分支可以进一步提交到 master 分支；如果向 develop 分支合并的时候测试没有通过，回到自己的特性分支继续测试，直到测试通过再提交；
• 过程（feature -> develop -> master）不是强制的，比如说 feature 分支可以直接合并到 master 分支；
• 如果生产环境发生了严重的 Bug，需要紧急修复的话，增加一个临时的紧急修复分支（hotfix），从生产环境的 master 拉取代码过来修复 Bug，测试通过之后将 hotfix 分支代码提交到生产环境，通过将此更新拉回到开发分支（feature）；

1.5.3、安全与审计

基于 DevOps 流水线，全流程保障网络安全

• 基于 DevOps 流水线，全流程保障网络安全，持续提升安全设计、编码、测试、运维能力
• 安全设计；
  • 构建网络分区、分层管理，管理面/业务面分离、执行节点独立 VPC、OS/中间件/业务框架多层安全防护 体系；
  • 微服务安全设计、威胁建模，落入微服务 发布签发项，保障系统架构与需求设计充分考虑安全；
  • 基于威胁点开展TMBT 测试，通过 projectMan 服务来跟踪问题闭环；
• 安全编码
  • 构筑安全稳固的研发服务框架，引入公司安全框架 WSF、WCC；
  • 流水线集成 CodeDex 工具与安全代码检视门禁；
  • 整改原生开源组件 5000+ 安全问题，规范规则满足度 100%；
  • 定期全员网络安全培训，覆盖网络安全红线与 TopN 典型问题；

1.5.4、部署与发布

• 部署应用到物理机、虚机、容器；
  • 支持将应用部署到物理机，虚拟机，容器，即使是用户私有的物理机，虚拟机，容器集群，只要能连通就能进行部署；并且主机部署还支持以代理机的方式进行部署；
• 支持多种技术栈应用的部署；
  • 支持 tomcat, springboot, nodejs 等多种技术栈应用的部署，提供通用模板比如 springboot, tomcat 等方便用户创建部署任务，并支持用户自定义模板，提供 25+ 原子步骤组装成部署任务；
• 支持与流水线集成打通部署流水线；
  • 在流水线能关联部署任务，并可以通过流水线关联构建，代码检查，测试等服务，实现端到端的 DevOps 流程；

1.5.5、运维与监控

• 基于SRE运维框架体系要求，具体化软件开发云一二三线运维支撑体系；
• 原则一：统一一线；
  • 客服、技服、操作中心、监控中心统一；
  • 各服务产品不自建，且需要进行培训赋能；
• 原则二：共建二线；
  • 服务 On-Call 接口组人员需要稳定，如需更换，需要获取 SRE 团队批准；
• 原则三：体系遵从；
  • 服务 On-Call 人员、接口人员、开发人员，如需在云现网进行相关工作，需完全遵守 SRE 运维框架体系相关规定；

2、DevOps转型路径

2.1、总体概览

总体阶段包括：

• 访谈评估
  • 首先对研发团队的各个角色进行访谈和自评估，从每个角色自己角度了解其所处环节的状况；
  • 了解研发中每个过程可能涉及到的不同部门的不同角色，以及上下游衔接情况；
• 过程建模
  • 根据访谈和评估结果，将 DevOps 过程分成 15 个子过程进行评级并提出改进建议和落地方案；
• 持续改进
  • 以上评估/建模/改进过程将在整个咨询服务过程中迭代进行，按照 3个月/6个月/12个月的阶段，提出每个阶段的状态评估和改进建议，并配合我们的实施团队提供 DevOps 落地服务；

2.2、整体过程

2.2.1、选择合适的试点项目

• 在实施团队DevOps的过程中要先选择合适的试点项目，选择的标准可以参考以下三个方面；
• 绿地项目与棕地项目；
  • 绿地项目和棕地项目最初用于描述城市规划和建设项目。2014 年 DevOps 企业峰会上分享的转型案例中，棕地项目所占的比例超过 60%；
    • Green field: 大部分是试点项目，全新的软件项目，有机会构建全新的应用和基础设施，对已有的代码库、流程和团队没有太多顾虑；
    • Brown field: 已服务客户的产品或服务，大部分有很多技术债务，没有自动化测试，紧耦合架构；
    • 改进棕地项目时，不但要努力降低复杂性，提高可靠性和稳定性，而且还应该更快，更安全，更容易变更；团队可能更愿意尝试；
  • 兼顾在 SOR 记录型系统和 SOE 交互性系统；
    • Gartner 双模 IT：SOR 侧重于做得正确，SOI 侧重于做得快速；
    • 高绩效组织能够兼顾高水平的生产能力和可靠性，每一位客户都应该同时享有速度和质量
    • 两者都合适做试点；

2.2.2、组建全功能团队

“系统设计受限于组织自身的沟通结构，组织规模越大，灵活性就越差，这种现象也就越明显” —— Melvin Conway, 1968

• 康威指出：系统设计受限于组织自身的沟通结构；
  • 第一定律：组织沟通方式会通过系统设计表达出来；
  • 第二定律：时间再多一件事情也不可能做得完美，但总有时间做完一件事情；
  • 第三定律：线型系统和线型组织架构间有潜在的异质同态特性；
  • 第四定律：大的系统组织总是比小系统更倾向于分解；
• 软件开发团队的结构对软件产品的架构和成果有巨大的影响；
• 利用康威定律组织团队，减少工作交接次数，提升交付速度和成功率；
• 小团队独立运作，彼此充分解耦，避免过多的沟通与协调；
• 松耦合架构；
  • 面向服务架构 SOA，由限界上下文的松耦合服务组成；
  • 微服务架构；
• 两个披萨原则，保持小规模；
• Robert Fernandez 博士定义了组织结构类型的3种类型；

2.2.3、 团队成熟度评估

DevCloud 为企业提供专业评估诊断，对被评估对象在 DevOps 领域方面的能力或现状进行分析、评判并给出建议；

• DevOps 成熟度评估【主观评估】：主观评估就是基于主观信息或依据做出判断的评估方式（eg：问卷调查）；
• 用户故事成熟度评估【客观评估】：客观评估是基于客观事实或数据做出判断的评估方式（eg：基于系统数据进行计算得出结论）；

2.2.4、绘制价值流图，识别阻碍点

• 召集所有关键成员，绘制价值流图；
• 记录主要的步骤和细节，让相关干系人拥有同样的视图；
• 重点分析和优化，识别阻碍：需要等待数周甚至数月的工作；引发或处理重大返工的工作；
• 确定想要改进的度量指标，通过探索各种假设，然后分析结果，不断迭代和重复，将获得的经验用于下一次实验；

2.2.5、软件研发过程：管理属性和工程属性

• 项目规划
  • 使用 DevCloud 提供端到端的需求版本管理能力，每个工作项上都可以设置迭代字段代表需求所需的项目规划；而与这一需求相关的任务/测试用例/缺陷/问题等可以相互关联；

2.2.6、推动实施企业级 DevOps 举措

• 在 DevOps 转型成功的路上，实现企业级敏捷是转型成功的最理想状态
• 企业规模化 DevOps 转型怎么实现：我们采用变革八步曲结合华为变革流程，通过多循环迭代，最终完成企业 DevOps 转型
  

2.2.7、设置转型路径与蓝图

• 第一阶段闭环：开发测试融合，组建研发部门内部的跨职能团队，提升自动化水平，降低修复成本
• 第二阶段闭环：需求开发测试融合，将产品、研发、测试等角色融合，组建跨职能团队，提升产品交付价值与质量
• 第三阶段闭环：研发运营一体化，实施产品自运营、自运维，打破了市场、研发、运维部门之间的壁垒，更多角色融入交付链路，提升业务响应力，建立价值反馈流
• 第四阶段闭环：目标是逐步实现所有业务线都以跨职能团队为最小组织单元，实现业务敏捷性，持续提升企业的市场竞争力

3、小结

通过DevOps转型，能提升企业持续交付核心能力，同时能强化企业科技与业务的高效融合，增强科技对市场的敏感度和技术赋能业务创新的能力，将DevOps转型经验由科技向业务和市场拓展，是企业转型很重要的环节。

本文参与华为云社区【内容共创】活动第19期。
https://bbs.huaweicloud.cn/blogs/370132

任务27：DevOps实践与转型路径