【云驻共创】DevOps实践与转型路径

举报
nukinsan 发表于 2022/08/27 14:14:11 2022/08/27
【摘要】 通过DevOps转型,能提升企业持续交付核心能力,同时能强化企业科技与业务的高效融合,增强科技对市场的敏感度和技术赋能业务创新的能力,将DevOps转型经验由科技向业务和市场拓展,是企业转型很重要的环节。

1、华为云端到端DevOps实践


华为创建于1987年,当时做软件开发用的都是瀑布流。到了 2000 年左右,引进了 IPD 开发模式,这个模式用了很久,降低了研发费用的同时提高了效率。10年前后,CICD 的理念传播过来,开始采用其中的一些原则,改变了开发方式。后来 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、规划与设计

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

a、需求流动过程管理

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


b、需求分层管理

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


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

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


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

  • SAPDSL 形成的铁三角;
  • 交付以服务 为中心,而不是以项目为中心;
  • PDProduct Owner,产品负责人/产品经理:负责产品规划、设计、分析;
  • SA:负责客户场景及解决方案,跟客户沟通,获取一些反馈和帮助客户解决一些问题;
  • SL:微服务/特性经理Service Leader,兼任敏捷Scrum Master,带领团队进行开发;
  • Sponsor:干系人(项目/业务/服务);
  • UEUCD(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 流水线,全流程保障网络安全,持续提升安全设计、编码、测试、运维能力
  • 安全设计
    • 构建网络分区、分层管理,管理面/业务面分离、执行节点独立 VPCOS/中间件/业务框架多层安全防护 体系
    • 微服务安全设计、威胁建模,落入微服务 发布签发项,保障系统架构与需求设计充分考虑安全
    • 基于威胁点开展TMBT 测试,通过 projectMan 服务来跟踪问题闭环
  • 安全编码
    • 构筑安全稳固的研发服务框架,引入公司安全框架 WSFWCC
    • 流水线集成 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 双模 ITSOR 侧重于做得正确,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.com/blogs/370132

任务27DevOps实践与转型路径

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。