【云驻共创】DevOps实践与转型路径
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 服务来跟踪问题闭环;
- 构建网络分区、分层管理,管理面/业务面分离、执行节点独立 VPC、OS/中间件/业务框架
- 安全编码
- 构筑安全稳固的研发服务框架,引入公司安全框架 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 侧重于做得快速;
- 高绩效组织能够兼顾高水平的生产能力和可靠性,每一位客户都应该同时享有速度和质量
- 两者都合适做试点;
- 绿地项目和棕地项目最初用于描述城市规划和建设项目。2014 年 DevOps 企业峰会上分享的转型案例中,棕地项目所占的比例超过 60%;
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
- 点赞
- 收藏
- 关注作者
评论(0)