软件开发平台 DevCloud软件开发平台 DevCloud

计算
弹性云服务器 ECS
裸金属服务器 BMS
云手机 CPH
专属主机 DeH
弹性伸缩 AS
镜像服务 IMS
函数工作流 FunctionGraph
云耀云服务器 HECS
VR云渲游平台 CVR
特惠算力专区
存储
对象存储服务 OBS
云硬盘 EVS
云备份 CBR
弹性文件服务 SFS
存储容灾服务 SDRS
云硬盘备份 VBS
云服务器备份 CSBS
数据快递服务 DES
专属企业存储服务
云存储网关 CSG
专属分布式存储服务 DSS
CDN与智能边缘
内容分发网络 CDN
智能边缘云 IEC
智能边缘小站 IES
智能边缘平台 IEF
人工智能
AI开发平台ModelArts
华为HiLens
图引擎服务 GES
图像识别 Image
文字识别 OCR
自然语言处理 NLP
内容审核 Moderation
图像搜索 ImageSearch
医疗智能体 EIHealth
园区智能体 CampusGo
企业级AI应用开发专业套件 ModelArts Pro
人脸识别服务 FRS
对话机器人服务 CBS
视频分析服务 VAS
语音交互服务 SIS
知识图谱 KG
人证核身服务 IVS
IoT物联网
设备接入 IoTDA
设备管理 IoTDM(联通用户专用)
全球SIM联接 GSL
IoT开发者服务
IoT数据分析
车联网服务 IoV
路网数字化服务 DRIS
IoT边缘 IoTEdge
设备发放 IoTDP
开发与运维
软件开发平台 DevCloud
项目管理 ProjectMan
代码托管 CodeHub
流水线 CloudPipeline
代码检查 CodeCheck
编译构建 CloudBuild
部署 CloudDeploy
云测 CloudTest
发布 CloudRelease
移动应用测试 MobileAPPTest
CloudIDE
Classroom
开源镜像站 Mirrors
应用魔方 AppCube
云性能测试服务 CPTS
应用管理与运维平台 ServiceStage
云应用引擎 CAE
视频
实时音视频 SparkRTC
视频直播 Live
视频点播 VOD
媒体处理 MPC
视频接入服务 VIS
管理与监管
统一身份认证服务 IAM
消息通知服务 SMN
云监控服务 CES
应用运维管理 AOM
应用性能管理 APM
云日志服务 LTS
云审计服务 CTS
标签管理服务 TMS
资源管理服务 RMS
应用身份管理服务 OneAccess
区块链
区块链服务 BCS
可信跨链服务 TCS
智能协作
IdeaHub
开发者工具
SDK开发指南
API签名指南
DevStar
HCloud CLI
Terraform
Ansible
API问题定位指导
云生态
云市场
合作伙伴中心
华为云培训中心
其他
管理控制台
消息中心
产品价格详情
系统权限
我的凭证
客户关联华为云合作伙伴须知
公共问题
宽限期保留期
奖励推广计划
活动
容器
云容器引擎 CCE
云容器实例 CCI
容器镜像服务 SWR
应用编排服务 AOS
多云容器平台 MCP
基因容器 GCS
容器洞察引擎 CIE
云原生服务中心 OSC
容器批量计算 BCE
容器交付流水线 ContainerOps
应用服务网格 ASM
网络
虚拟私有云 VPC
弹性公网IP EIP
弹性负载均衡 ELB
NAT网关 NAT
云专线 DC
虚拟专用网络 VPN
云连接 CC
VPC终端节点 VPCEP
数据库
云数据库 RDS
数据复制服务 DRS
文档数据库服务 DDS
分布式数据库中间件 DDM
云数据库 GaussDB (for openGauss)
云数据库 GaussDB(for MySQL)
云数据库 GaussDB NoSQL
数据管理服务 DAS
数据库和应用迁移 UGO
大数据
MapReduce服务 MRS
数据湖探索 DLI
表格存储服务 CloudTable
可信智能计算服务 TICS
推荐系统 RES
云搜索服务 CSS
数据可视化 DLV
数据湖治理中心 DGC
数据接入服务 DIS
数据仓库服务 GaussDB(DWS)
应用中间件
微服务引擎 CSE
分布式消息服务Kafka版
分布式消息服务RabbitMQ版
API网关 APIG
分布式缓存服务 DCS
分布式消息服务RocketMQ版
企业应用
域名注册服务 Domains
云解析服务 DNS
云速建站 CloudSite
网站备案
华为云WeLink
会议
隐私保护通话 PrivateNumber
语音通话 VoiceCall
消息&短信 MSGSMS
云管理网络
SD-WAN 云服务
边缘数据中心管理 EDCM
云桌面 Workspace
应用与数据集成平台 ROMA Connect
ROMA资产中心 ROMAExchange
API全生命周期管理 ROMA API
安全与合规
安全技术与应用
DDoS防护 ADS
Web应用防火墙 WAF
云防火墙 CFW
应用信任中心 ATC
企业主机安全 HSS
容器安全服务 CGS
云堡垒机 CBH
数据库安全服务 DBSS
数据加密服务 DEW
数据安全中心 DSC
云证书管理服务 CCM
SSL证书管理 SCM
漏洞扫描服务 VSS
态势感知 SA
威胁检测服务 MTD
管理检测与响应 MDR
安全治理云图 Compass
迁移
主机迁移服务 SMS
对象存储迁移服务 OMS
云数据迁移 CDM
专属云
专属计算集群 DCC
解决方案
高性能计算 HPC
SAP
游戏云
混合云灾备
华为工业云平台 IMC
价格
成本优化最佳实践
专属云商业逻辑
用户服务
帐号中心
费用中心
成本中心
资源中心
企业管理
工单管理
客户运营能力
国际站常见问题
支持计划
专业服务
合作伙伴支持计划
文档首页> 软件开发平台 DevCloud> 理论实践> DevOps概览> 解读华为云DevCloud HE2E端到端DevOps实施框架
更新时间:2021-03-18 GMT+08:00
分享

解读华为云DevCloud HE2E端到端DevOps实施框架

前言

我们经常讨论什么是敏捷、什么是精益、什么是DevOps。与其去讨论什么是,不如讨论为什么。

精益、敏捷与DevOps为什么会产生?目的是为解决软件研发交付中遇到的各种问题。

软件研发的过程,是价值交付的过程。而价值交付,天生就是从客户来,到客户去,是端到端的。价值交付过程是一个系统工程,需要进行全局优化而非单点改良。割裂的去看价值交付价值流上的单点,亦或是阶段点之间的问题,例如业务到开发、开发到测试、测试到运维,都只能是局部改善。

华为HE2E(端到端)的DevOps实施框架,就是将整个软件价值交付过程完整展现出来,汇集业界先进实践的同时,也结合了华为自身30年研发经验,形成的一套可操作可落地的敏捷开发方法论,并基于华为云DevCloud工具链进行固化和承载。

下面让我们逐一解读HE2E DevOps实施框架的几个主要部分。

影响地图,回归商业的初心

简单的讲,影响地图是这样的一个思维逻辑和组织结构:为什么(Why)>谁(Who)>怎样(How)>什么(What)

也就是:我们的目标是什么(Why),为了达成目标需要哪些人(Who)去怎样(How)影响,为此我们需要做什么(What)。影响地图通过构建产品和交付项目来产生实质影响,从而达到业务目标。

  • Why:回答我们为什么做这些?也就是我们要试图达成的目标。找到正确的问题,要比找到好的回答困难得多
  • Who:回答谁能产生需要的效果?谁会阻碍它?谁是产品的消费者或用户?谁会被它影响?也就是那些会影响结果的角色。找对受众群体,是接下来最关键的问题,受众若是匹配错误,做出来的产品就是对牛弹琴。
  • How:回答考虑角色行为如何帮助或妨碍我们达成目标?我们期望见到的影响。
  • What:回答作为组织或交付团队,我们可以做什么来支持影响的实现?包含:交付内容,软件功能以及组织的活动。

最后,才是我们要做的事情,也就是通常我们讲的产品功能。

往往我们做产品最容易犯的错误就是一上来就罗列一堆的功能,却没有想清楚我们为什么要做这些,有没有/有哪些人需要,需要这些功能干什么。

影响地图的价值正在于它将现实的商业逻辑用最清晰简洁的结构展现出来,以终为始,回归初心,从目的出发,推演出最终的产品功能。

影响地图可以帮助组织避免在构建产品和交付项目的过程中迷失方向。确保所有参与交付的人对目标、期望影响和关键假设理解一致。

影响地图可以有效地评估交付,作为质量反馈的标准之一:如果一个需求不能有效地支持期望的行为影响,那么即使在技术上正确,功能交付给用户了,也仍然是失败的。

用户故事地图,既见树木又见森林

由影响地图得到了What部分,也就是我们要做什么,是不是就可以当成用户故事(User Story)排进产品待办事项(Product Backlog)开始开发了呢?答案是还不可以。

用户故事是敏捷开发中普遍使用的实践,但常见的困惑是:产品负责人整理了一大堆的产品Backlog,还编排了优先级,过早地陷入到细节的讨论中,只见树木不见森林。

传统敏捷开发中,扁平的产品待办列表,存在很多问题:它很难解释产品是做什么的。对于一个新的系统,扁平化待办列表无法帮助我们确认是否已经识别出全部故事。同样的,扁平化待办列表也无法帮助制定发布计划,用户故事少则几十,多则上百,详细分析每一个用户故事并且做出是否采纳的决定是非常乏味并且低效的。

用户故事地图是一门在需求拆分过程中保持全景图的技术,目的是既见树木,又见森林,聚焦于故事的整体,而不是过早的纠缠于细节,在看到全景图的同时,逐层进行细节拆分。采用用户故事地图,跳出了扁平化的产品待办列表,看到了产品的全景图,可以真正聚焦于目标用户以及产品最终的形态。产品待办列表只是一维的,而用户故事地图是三维的,这是高维与低维的比较,高维恒胜。

用户故事地图基于简单的网格结构,规则是从左到右讲述故事,即按照叙事主线顺序;自上向下的拆分,即由大到小的细节展现。其中最关键的部分是产品的构思框架,贯穿整个产品的发布地图,可以帮助团队以可视化方式展示依赖关系。此外,更多的背景信息可以摆放在地图的周边,例如产品目标、客户信息等,这几乎就是用户故事的全部了。这也恰好是用户故事地图的魅力所在,好的东西通常都很简单而有效。

Scrum与Kanban相得益彰

有了需求的梳理和组织,接下来就是开发落地的过程,而这一过程中,最多使用的就是Scrum与看板的方法。

Scrum与看板,在江湖上是两个门派,采纳时是否需要泾渭分明,区分严格呢?并不是这样,其实Scrum与看板事实上是可以很好结合的。Henrik Kniberg有一本书叫做《Scrum与Kanban相得益彰》,讲的就是如何兼容并蓄,将Scrum与Kanban的实践进行融合,相互借鉴,从而发挥两者的最大价值。

Scrum的好处是,它是一个框架,设定了角色、活动、过程产物,以及相关原则。

  • 计划会议与每日站会,形成了时间维度上从大到小的拆分。
  • Product Backlog与Sprint Backlog,形成计划层面从大到小的分解。
  • “Epic>Feature>Story>Task”的层级关系,形成了需求粒度上的划分。
  • 迭代评审会议,是对迭代产物的沟通与反馈。
  • 回顾会议,是对迭代过程的审视与优化。

Scrum设定了严格的时间盒Timebox,对节奏的保持大有益处,Develop on Cadence,从产品大的版本/批次、到小的迭代、再到每日的站会,就是一个很好的节奏把控过程。

Kanban最大的价值在于可视化,软件研发最大的问题就在于过程不可见。可视化意味着把价值流动,以及问题都显示化出来。暴露问题,而不是遮掩;解决问题,而不是追责。

WIP限制在制品,是看板方法中最难遵守的实践,却也是精益软件开发原则的精华体现。Stop Start,Start Finishing,停止开始,聚焦完成。我们开发中最大的问题往往在于开始的事情太多,却没有及时的将一件事情打穿做完。为什么会这样?如何发现?答案是可视化,人们往往没有意识到自己同时在进行的工作到底有多少,一旦将并行工作可视化出来,加上WIP限制,才有可能解决并行在制品问题。

生产过程中的物料堆积被视为浪费,研发过程中的任务堆积如何解决?有了前面讲到的可视化,让过程以及产物看得见;有了WIP,让并行工作得到控制,但依然无法解决上下游产能不匹配可能造成的任务堆积问题。拉动式系统相比于传统的推动式系统,目的就在于解决这一问题。传统开发过程中任务是被上游推动,一旦下游产能低于上游,或者出现阻塞,就会出现下游的任务堆积;拉动式系统中,只有下游产能出现空余,才能从上游拉动任务,由于有WIP的限制,所以上游一旦超过WIP,而下游又没有产能可以拉动时,上游是不能继续开展工作的(Stop Starting),所以最好的办法是帮助下游尽快完成(Start Finishing),这也体现了Whole Team的精神。

可视化、WIP、拉动式系统,形成了看板的三要素。

以上内容支撑起了HE2E框架的上半部分,通常被称为管理实践,也是传统敏捷开发所关注的部分。

接下来我们来看一下下半部分的工程实践:持续交付域。

持续交付

正如Jez Humble对持续交付的定义:“The ability to get changes—features, configuration changes, bug fixes, experiments—into production or into the hands of users safely and quickly in a sustainable way.”持续交付也好,DevOps也罢,最终目标是快速的交付价值。

如果说管理实践的目的是为了鉴别什么是正确的事情,以及正确的做事情。那么工程实践的目的,是除了正确的做事情以外,还能高效的做事。

工程实践就像人体的肌肉,是强调执行力的,是大脑想到然后肌肉能够做到并且快速的做到。每一丝的赘肉都会影响身体执行的速度,所以需要锻炼来消除。如何消除持续交付过程中的赘肉?和肌肉锻炼燃烧脂肪一样,痛苦的事情需要反复做,做十次一百次上千次,反复打磨,持续优化。

工程过程是需要高效、准确并且高度保持幂等性的。也就是说,执行一次的结果,与执行一百次的结果应该是一样的,所以对一致性的要求极高。人工过程是无法满足高频度发布与部署,因此工程实践要求的就是尽可能的自动化。最大化的自动化,越是频繁做的事情越要自动化,越是需要尽快反馈的事情越要自动化。在自动化来保证一致性的同时,我们还要去消除阻塞,发现问题并进行疏通。

自动化与人工审核要有机结合,需要想清楚人工审核的目的是保障质量,而不是管控,更不是官本位的体现屁股所在。每一个存在人工审核的地方,先想一想是否一定需要、是否有自动化的方式、是否可以后移。

质量与速度能否兼得?答案是肯定的。要持续识别并消除开发中的约束点,常见约束点以及相关建议有:

  • 环境搭建的约束点:采用基础设施即代码的实践,应该让环境搭建与配置的过程自动化、版本化,提供自服务平台,使能开发者。
  • 代码部署过程的约束点:采用自动化部署实践,利用容器化与编排技术,让应用部署与运行的过程呈幂等性。
  • 测试准备和执行的约束:采纳自动化测试实践,分层分级的进行测试,针对不同的阶段,建立不同的测试环境、设置不同的测试目标、建立不同的反馈闭环。
  • 紧耦合的架构往往会成为下一个阻塞点,要进行架构解耦,采用松耦合的架构设计,将重构等实践纳入日常的技术债务清理过程,演进式的采用服务化、微服务化的架构。

就像长跑一样,教科书里说道:每一丝肌肉都对跑步成绩造成影响,工程过程也是如此,彼此之间会产生关联并彼此影响。因此我们更应该将持续交付域作为一个整体来看待,而不是分裂的去看编译、构建、静态动态测试、集成、部署、发布等。工程过程更像是一个联动的机器,故而我们称之为持续交付流水线。良好配置的流水线,应该是分层分级,同时又不失整体的。

回到HE2E大图:

持续交付以代码配置管理为基础,除了传统意义的代码资产安全与管控、多人并行开发以及发版与基线管理以外,更重要的这体现了团队的协作与沟通。

代码检查即静态扫描,自动化的构建,拉起来的各阶段的自动化测试,以及相应的自动化部署过程,都被有机的串联在流水线上。

除了这些动态的阶段与活动,还有发布包的制品管理,以及各级的环境管理,包括开发环境、测试环境、准生产环境,以及生产环境。

持续交付流水线就是将整个持续交付中,都有哪些阶段、分别运行在什么环境、每个阶段执行什么活动、准入与准出的质量门禁,以及每个阶段的输入与输出的制品进行管理。

分享:

    相关文档

    相关产品

关闭导读