华为云DevOps系列之——华为云端到端 DevOps 实践

华为 30 年研发模式演进

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

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

• 这里有一个问题：华为用的就是 DevOps 方式吗？其实我们并不能一概而论，因为采用什么开发方式是和商业模式挂钩的，特别是像华为这样一个大体量公司来说，不同的部门、不同的业务情况是采用不同的研发模式的，所以我们现在将其剥析开发，看看它有哪些商业模式
  • 卖产品
    • 软件：TTM 缩短驱动力（3~6月）
    • 硬件：版本火车模式（6~12月）
  • 卖服务：DevOps（周~1月）
• 所以我们可以看到并不是说整个华为都在用 DevOps

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

• 华为云 DevCloud 是华为对外开放出来的开发者工具。这个工具原本是内部使用的，后来慢慢转为商用，并且根据市场需要增加功能，团队也在逐渐扩大。上图为华为云 DevCloud 团队的规模化成长历程
• DevCloud 发展历程
  • 2015.07 公测：只提供项目管理、代码托管、编译构建服务
  • 2016.09：正式发布
  • 2016.12 1.0 版本：增加代码检查、部署服务、发布服务，代码托管等功能
  • 2017.09 2.0 版本：移动应用测试发布、Wiki 特性发布、文档管理特性发布

华为云实现全流程 DevOps 平台

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

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

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

DevOps 全流程交付模式

• 首先看流水线：从源代码到构建，不同环境的部署、测试，最后发布到生产环境，这条线都提升到流水线上，看着很简单，但涉及到的开发活动一点都不简单
• 研发活动：代码管理，二进制软件包构建，功能、性能等安全验证
• 各级门禁控制质量的参与的角色有三个
  • SDE（开发）：开发团队参与整个过程的所有环节，包括微服务自己的功能测试及集成测试部分
  • I&V（测试）：测试团队主要参与的是安全、可靠性等测试
  • SRE：从类生产开始介入
• 迭代过程：需求分析、设计到编码，编码完毕之后，每一天代码都提交主干一次，并做完微服务的自验并要求通过质量门禁，通过测试的代码要发布到生产环境需要的时间是 小时级

规划与设计

需求管理部分

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

需求流动过程管理

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

需求分层管理

• 需求分层管理
  • 主要分成业界通用的 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 的评估、方案和开发交付，完成后要修改对应状态

华为敏捷项目管理 Scrum 框架

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

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

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

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

• 集中决策（2015年之前）
  
  • 开发的工具内部使用
  • 使用瀑布开发模式
  • 组织架构是职能团队，
  • 决策由项目经理一人制定
• 启发式决策（2015~2016）
  
  • 转为商用
  • 单一决策组织结构有深井式问题，沟通效率低，无法适应市场要求，转为启发式决策
  • Core Team：核心团队共同决策
  • 每个微服务包括全职能团队和单独的产品经理
  • 应对市场更加灵活
• “自主生长”（2017年之后）
  
  • 之前的启发式决策灵活度还是差一点
  • 完全自主的团队，彻底的去中心化，每个服务都由团队自主决策
  • 响应市场更加灵敏

开发与集成

架构解耦是敏捷的保障

• 架构与系统解耦，做到组件化，乃至微服务化：实现松耦合，可并行开发、构建、测试、部署、运行的最小可运行产品/特性
• 需求分解的原则：需求分解遵循 小步快跑，同一个特性可以由多个迭代 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）

微服务 API 设计

• 可通过 APIManager 进行接口在在线设计与评审，生成在线接口文档，自动识别接口变更，借助基于API的契约测试加强团队协作效率，减少依赖问题
• 基于 API 的契约测试
  

测试与反馈

DevCloud 敏捷测试实践

• 构建 CloudNative 测试能力，实现测试活动解耦，在线业务测试与监控
• 主要含以下几个方面
  • 分层流水线
    • 通过个人级、服务级、产品级分层自动化流水线来分层确保质量
    • 提升功能/安全/性能/可靠性自动化测试覆盖情况
    • 利用自动化技术，提升用例执行效率与稳定性，监控反馈流水线各测试环节执行效率
  • 质量门禁
    • 不合格的制品无法流入下一环节
    • 让流水线来拦截问题，让自动化门禁代替人工管理
    • 分层门禁，规则自定
  • 在线测试
    • 在线业务测试，对生产环境业务主线与重点功能持续在线测试，先于用户发现业务异常并告警
    • 在线体验巡视，每日生产环境巡视 E2E 主线场景体验
    • 在线 7x24 监控，错误事务和运行异常对比分析告警推送
  • 可视化
    • 测试过程可视化，让质量暴露在阳光下
    • 团队所有成员知道项目的质量，促进团队成功

DevCloud 持续交付场景

• 流水线分层详细描述
  
• 开发环境（Alpha）：每个微服务每个 story 独立开发，测试通过后合并到 develop 分支
• 服务级流水线（Beta）：所有人在本地开发测试通过的代码都集成到 develop 分支，然后运行集成角度的流水线（Beta）
• 产品级流水线（Gamma）：服务级流水线测试通过后，代码合并到 master 分支，即主干代码，并在类生产环境（Gamma）进行测试，测试通过后，在业务需要的情况下，将代码推送到生产环境，运行生产环境升级流水线

个人级流水线的质量活动

• 个人级流水线从开发、alpha 环境至 beta 环境，对应微服务个人或特性分支
• 代码检查门禁
  • 指定检查规则的问题数为 0
• 单元测试门禁
  • 方法覆盖率达标
  • 行覆盖率达标
• 安全扫描门禁
  • 问题数为 0
• 接口测试门禁
  • 测试通过率达标
  • 测试覆盖率达标

服务级流水线的质量活动

• 服务级流水线从 alpha 环境至 beta 环境，对应微服务版本分支
• 单元测试门禁
  • 方法覆盖率达标
  • 行覆盖率达标
• 安全扫描门禁
  • 问题数为 0
• 接口测试门禁
  • 测试通过率达标
  • 测试覆盖率达标
• 浏览器兼容性测试门禁
  • 问题数为 0
• 性能测试门禁
  • TPS、RT达标

产品级流水线的质量活动

• 产品级流水线从 gamma 环境至生产环境，对应微服务版本主干

DevCloud 自动化代码检查

• 常见代码问题
  • 编码风格：方法圈复杂度、Java 编码风格等
  • 编码正确性：空指针引用、资源泄露、除零、类型转换异常等
  • 编码安全：SQL 注入等
  • 编码性能：字符串拼接使用+、锁内调用 sleep 等
  • 多线程：编程安全问题等
  • 其他：代码坏味道等
• 代码检查的作用
  • 发现问题
  • 问题原因说明
  • 修改建议
  • 正确示例、错误示例

测试环节效果对比

安全与审计

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

• 基于 DevOps 流水线，全流程保障网络安全，持续提升安全设计、编码、测试、运维能力
• 安全设计
  • 构建网络分区、分层管理，管理面/业务面分离、执行节点独立 VPC、OS/中间件/业务框架 多层安全防护 体系
  • 微服务 安全设计、威胁建模，落入微服务 发布签发项，保障系统架构与需求设计充分考虑安全
  • 基于威胁点开展 TMBT 测试，通过 projectMan 服务来跟踪问题闭环
• 安全编码
  • 构筑安全稳固的研发服务框架，引入公司 安全框架 WSF、WCC
  • 流水线集成 CodeDex 工具与安全代码检视门禁
  • 整改原生开源组件 5000+ 安全问题，规范规则满足度 100%
  • 定期全员网络安全培训，覆盖网络安全红线与 TopN 典型问题
• 安全测试
  • 深入 黑客视角 E2E 渗透测试，挖掘 深层次威胁
  • 加强 源码审计 能力与引入业界 新安全测试工具
  • 建立微服务 流水线安全自动化验证 能力，固化公司安全红线与 TopN 问题落入自动化用例管控
• 安全运维
  • 基础组件 一键式自动化安全加固、自动化安全巡检、数据定时备份
  • 基于公司红线与公有云运维合规性要求，排查风险隐患，并建立自动化机制，遵从度提升至 100%
  • 生产环境引入 网络安全能力 WAF 安全防护网，有效检测防控现网应用层攻击
  • 7x24 小时日志异常告警、系统监控告警

开源 & 第三方组件自检

• 严格遵照先申请后使用要求，使用的时候先从内部的组件系统里提取地址来使用，如果组件的来源不是内部的 PDM 系统的话，还需要申请将其评审加入内部系统使用
• 整套流程确保使用的安全组件都是经过严格审批的，这样可以避免使用了有不明组件、以及那些有缺陷的版本

部署与发布

DevCloud 自动化快速部署

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

DevCloud 自动化快速发布

• 软件包资产的可视化管理和追溯
• 流水线：打通从代码提交至服务上线自动化流水线，代码提升至生产上线最快X小时
• 支持产品版本内建出口质量标准，流水线门禁集中管理，提升版本出口质量
• 关键环节的自动化质量门禁策略

DevCloud 全流程版本追溯

• 迭代计划、发布、以及版本号命名：每周一个迭代，可以多次发布
• 版本追溯：现网服务节点的版本可见，并可追溯该版本的发布、软件包、构建记录、验证记录、已经代码仓库中的每次提交

DevCloud 版本发布质量控制

• 基于 DevOps 流水线，构建 E2E 自动化测试能力
• 质量门禁管控研发过程质量，在线测试持续先于用户发现现网问题

运维与监控

基于 SRE 运维框架体系的运维保障

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

自动化运维

• 业务支撑
  • SSL 证书监控系统
  • DB 观象台
  • 业务版本管理系统
  • 审批系统
  • 变更管理系统
  • 堡垒机登录系统
  • 工单系统
  • 灰度发布引擎
  • 配置管理
  • 自助服务
• 监控服务
  • 服务健康度
  • 故障自愈
  • 故障处理
  • 监控大屏
  • 调用链
  • 性能
  • 基本监控
• 基础环境运维
  • 安全基线系统
  • 密码修改系统
  • 一键扩容减容
  • 自助开局
  • 资源管理
• 数据分析
  • 现网问题分析系统
  • 日志检索分析
  • 容量平台
  • 业务运营

运维管理平台能力

能力项	详细说明
变更发布	依托 DevCloud 流水线服务，DevOps 自动化持续发布，灰度变更 0 中断
日志管理	公有云 ELK 日志平台
监控告警	基础环境监控、性能监控、调用链监控，覆盖面 100%
巡检	每日巡检三次，涵盖基础环境、安全、性能，覆盖面 100%
拨测	5 分钟一次，覆盖所有服务 L0 级用例，在线实时短信、邮件告警
工单管理	公有云 Cloud Incident MGMT 工单平台
资源管理	普罗米修斯、zeus 运维平台

最后，欢迎大家关注我的个人微信公众号 『小小猿若尘』，获取更多IT技术、干货知识、热点资讯。同时，我在公众号中分享了精心整理的一些视频资料（包括 Python全栈教程、AI教程、前端、数据库等），大家回复相应关键词即可获取网盘视频链接，感谢大家的关注😊