华为云devops认证考试课堂笔记5

柔光的暖阳◎ 2022-11-11 05:54 277阅读 0赞

> 目前在备考华为云的devops认证考试，特把近期的笔记整理好，方便复习

### 文章目录 ###

*   *  总结回顾
     *   *   *  需求流动过程管理
             *  需求分层管理
             *  团队
             *  devcloud能力构建
             *  devcloud敏捷测试实践
             *  devCloud质量门禁
             *   *  个人级流水线
                 *  服务级流水线
                 *  产品级流水线
             *  基于devops流水线，全流程保障网络安全
             *   *  安全设计
                 *  安全编码
                 *  安全测试
                 *  安全运维
             *  devcloud全流程版本追溯
             *  基于SRE运维框架体系的运维保障
             *  自动化运维
             *   *  业务支撑
                 *  监控服务
                 *  基础环境运维
                 *  数据分析
                 *  运维管理平台能力
         *  devops转型
         *   *  准备阶段1：选择合适的试点项目
             *  准备阶段2：组建全功能团队
             *  准备阶段3：团队成熟度评估
             *  准备阶段4：绘制价值流图，识别阻碍点
             *  实施阶段：确定实施的优先级
             *   *  团队敏捷
                 *  业务敏捷
                 *  工程敏捷
                 *  管理工具
                 *  实施阶段1：基础知识培训、理论准备
                 *  实施阶段2：推动落地团队级敏捷举措

## 总结回顾 ##

#### 需求流动过程管理 ####

原始诉求–>PD&一线预审–>产品backlog–>RAT评审(关键需求)–>迭代backlog–>CCB评审(关键方案或约束)–>迭代会议(业务+原型)–>串讲会议(实现+约束)–>迭代

需求优先级排序：业务优先级

*  问题>需求
 *  解决方案需求>产品需求
 *  跨服务依赖需求>独立需求
 *  清晰需求>不清晰的需求
 *  UCD完成需求>UCD等待需求
 *  80%功能需求+20%体验需求
 *  价值用户需求>普通用户需求
 *  通用需求>定制需求

趟过的坑：

*  严格按照三层模型拆分，工作量大
 *  全部只用story管理，任务无法承载，交付吞吐率无法度量
 *  前后台任务拆分/不拆分
 *  需求依赖未标明和识别
 *  详细完整的story方案
 *  UCD任务未纳入管理导致等待

#### 需求分层管理 ####

需求分层原则：

*  视情况允许独立的story存在，不要非分解三级需求，大部分需求直接以story分发
 *  任务允许以story直接分发，不一定要拆分出task
 *  epic和feature主要对应于产品backlog，关键测听，决策和优先级排序

需求分层责任划分：

*  PD: 维护epic、feature、story，应用于产品backlog和迭代backlog
 *  SL: 关注进入迭代的story分配及task拆解，关注交付优先级，关注技术和方案层面的任务和对交付的影响
 *  developer：关注迭代中分配到的story和task的评估、方案和开发交付，完成后要修改对应状态

#### 团队 ####

*  sponsor：干系人（项目/业务/服务）
 *  SA：负责客户场景及解决方案
 *  PD：product owner，负责产品规划、设计、分析
 *  UE：UCD(user centered design)工程师，负责用户研究、交互设计、美工、视觉
 *  SL：微服务/特性经理service leader，兼任敏捷scrum master，带领团队进行开发
 *  SE：技术leader，系统工程师，负责架构、系统设计
 *  开发：负责代码实现
 *  测试：负责测试验证
 *  运维：负责部署、发布、运维、监控

#### devcloud能力构建 ####

核心：价值交付

架构：

*  采用服务化架构/微服务架构实现全面解耦
 *  通过API，重用云原生公共服务提供的基础能力和架构能力
 *  使用自服务、敏捷的云化基础设施服务

工程：

*  系统与环境、流程、配置解耦
 *  devops实现运维和开发互相融合
 *  实践极速迭代，持续交付，快速响应业务变化，缩短TTM

组织：全功能团队；云化运维团队

#### devcloud敏捷测试实践 ####

构建cloudNative测试能力，实现测试活动解耦，在线业务测试与监控

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

#### devCloud质量门禁 ####

##### 个人级流水线 #####

*  代码检查门禁：指定检查规则的问题数为0
 *  单元测试门禁：方法覆盖率达标；行覆盖率达标
 *  安全扫描门禁：问题数为0
 *  接口测试门禁：测试通过率达标；测试覆盖率达标

##### 服务级流水线 #####

*  单元测试门禁：方法覆盖率达标；行覆盖率达标
 *  安全扫描门禁：问题数为0
 *  接口测试门禁：用例通过率达标；测试覆盖率达标
 *  界面功能测试门禁：用例通过率达标
 *  浏览器兼容性测试门禁：问题数为0
 *  性能测试门禁：TPS、RT达标

##### 产品级流水线 #####

*  安全扫描门禁：问题数为0
 *  接口测试门禁：用例通过率达标；测试覆盖率达标

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

##### 安全设计 #####

*  构建网络分区、分层管理，管理面/业务面分离，执行节点独立VPC、OS/中间件/业务框架多层安全防护体系
 *  微服务安全设计、威胁建模，落入微服务发布签发项，保障系统架构与需求设计充分考虑安全
 *  基于威胁点开展TMBT测试，通过projectMan服务跟踪问题闭环

##### 安全编码 #####

*  构筑安全稳固的研发服务框架，引入公司安全框架WSF、WCC
 *  流水线集成CodeDex工具与安全代码检视门禁
 *  整改原生开源组件5000+安全问题，规范规则满足度100%
 *  定期全员网络安全培训，覆盖网络安全红线与TopN典型问题

##### 安全测试 #####

*  深入黑客视角E2E渗透测试，挖掘深层次威胁
 *  加强源码审计能力与引入业界新安全测试工具
 *  建立微服务流水线安全自动化验证能力，固化公司安全红线和TopN问题落入自动化用例管控

##### 安全运维 #####

*  基础组件一键式自动化安全加固，自动化安全巡检，数据定时备份
 *  基于公司红线与公有云运维合规性要求，排查风险隐患，并建立自动化机制，遵从度提升至100%
 *  生产环境引入网络安全能力WAF安全防护网，有效监测防范现网应用层攻击
 *  7x24小时日志异常告警，系统监控告警

#### devcloud全流程版本追溯 ####

`<微服务名称>_<主版本号>.<子版本号>.<迭代版本号>.<release号>.<后缀>`

版本追溯：现网服务节点的版本可见，并可追溯该版本的发布、软件包、构建记录、验证记录、以及代码仓库中的每次提交

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

\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Od8crV6k-1616148393527)(img\\10.png)\]

运维保障：基于SRE运维框架体系要求，具体化软件开发云一二三线运维支撑体系

原则1：统一一线：客服、技服、操作中心、监控中心统一；各服务产品不自建，且需要进行培训赋能

原则2：共建二线：服务on-call接口组人员需要稳定，如需更换，需要获取SRE团队批准

原则3：体系遵从：服务on-call人员、接口人员、开发人员，如需在云现网进行相关工作，需完全遵守SRE运维框架体系相关规定。

#### 自动化运维 ####

##### 业务支撑 #####

包括：SSL证书监控系统、业务版本管理系统、变更管理系统、工单系统、配置管理、DB观象台、审批系统、堡垒机登录系统、灰度发布引擎、自助服务

##### 监控服务 #####

服务健康度、故障自愈、故障处理、监控大屏、调用链、性能、基本监控

##### 基础环境运维 #####

安全基线系统、密码修改系统、一键扩容减容、自助开局、资源管理

##### 数据分析 #####

现网问题分析系统、日志检索分析、容量平台、业务运营

##### 运维管理平台能力 #####

<table> 
 <thead> 
  <tr> 
   <th>能力项</th> 
   <th>详细说明</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>变更管理</td> 
   <td>依托devcloud流水线服务，devops自动化持续发布，灰度变更0中断</td> 
  </tr> 
  <tr> 
   <td>日志管理</td> 
   <td>公有云ELK日志平台</td> 
  </tr> 
  <tr> 
   <td>监控告警</td> 
   <td>基础环境监控、性能监控、调用链监控，覆盖面100%</td> 
  </tr> 
  <tr> 
   <td>巡检</td> 
   <td>每日巡检3次，涵盖基础环境、安全、性能，覆盖面100%</td> 
  </tr> 
  <tr> 
   <td>拨测</td> 
   <td>5分钟一次，覆盖所有服务L0级用例，在线实时短信、邮件告警</td> 
  </tr> 
  <tr> 
   <td>工单管理</td> 
   <td>公有云cloud incident MGMT工单平台</td> 
  </tr> 
  <tr> 
   <td>资源管理</td> 
   <td>Prometheus、Zeus运维平台</td> 
  </tr> 
 </tbody> 
</table>

### devops转型 ###

#### 准备阶段1：选择合适的试点项目 ####

绿地项目(greenfield)与棕地项目(brownfield)

> 绿地指新项目；棕地指已经服务客户长达几年或几十年的产品或服务，大部分有技术债务

*  改进棕地项目时，不但要努力降低复杂性，提高可靠性和稳定性，而且应更快、更安全、更易变更

兼顾在SoR记录型系统和SoE交互性系统

*  gartner双模IT：SOR侧重于做的正确，SOE侧重于做的快速
 *  高绩效组织能兼顾高水平的生产能力和可靠性，每一位客户都应同时享有速度和质量

从最有同理心和最乐于创新的团队开始，扩大devops的范围

*  发现创新者和早期采用者
 *  尽早展示成果并积极宣传，将大目标分解为渐进式的小步骤

#### 准备阶段2：组建全功能团队 ####

参考康威定律设计组织结构，使团队安全和独立的工作

> 康威指出：系统设计受限于组织自身的沟通结构
> 
>  *  第一定律：组织沟通方式会通过系统设计表达出来
>  *  第二定律：时间再多，一件事也不可能做的完美，但总有时间做完一件事
>  *  第三定律：线型系统和线型组织架构间有潜在的异质同态特性
>  *  第四定律：大的系统组织总比小系统更倾向于分解

组织结构：

*  职能型functional：以专业技能为中心，优化分工或降低成本，通常多层次的组织结构
 *  矩阵型matrix：试图结合职能型和市场型
 *  市场型market：以快速响应客户需求为中心，扁平化结构，涵盖多功能领域，可能存在冗余情况

具体：

*  利用康威定律组织团队，减少工作交接次数，提升交付速度和成功率
 *  小团队独立运作，彼此充分解耦，避免过多的沟通与协调
 *  松耦合架构
 *  两个比萨原则，保持小规模

#### 准备阶段3：团队成熟度评估 ####

level1：regressive原始级

*  手动，无序，缺少流程，对良好的实践不了解，未采纳；团队个别人员偶然的发起改进

level2：basic基础级

*  基本流程，开始尝试建立基本的流程和工程实践能力，但是基于直觉，未系统性的规划，不能完全达到目的

level3：standardized标准化级

*  标准化、自动化，通过已定义的标准流程和实践，以及在软件的开发过程中越来越多的实现自动化，支持软件开发的持续实施

level4：mature成熟的

*  量化的、端到端，端到端的流程是可度量，受控的，能良好的响应变化，具备交付过程自动化自适应的能力

level5：optimizing优化级

*  持续优化，创新，关注交付过程的持续优化和能力的持续提升，有能力发明新的技术和实践解决前所未遇的问题，一个典型特点是团队能积极贡献和回馈更广大的软件开发社区

#### 准备阶段4：绘制价值流图，识别阻碍点 ####

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

LT：lead time，是一个过程从发起到执行完毕之间间隔的时间，在精益生产中为缩短和预测价值流中的前置时间。可采用方式：减少批量尺寸、减少在制品、避免返工、确保不把次品传递给下游，持续不断的全局优化

C/A：complete & accurate，返工效能比率，关注返工指标

#### 实施阶段：确定实施的优先级 ####

##### 团队敏捷 #####

敏捷意识强化、知识点与工具使用培训、敏捷会议的观察及引导、测试前移、团队质量监控、SoS敏捷管理方法

##### 业务敏捷 #####

探求运用用户故事地图、实例化需求与用户故事、进行需求条目化、利用需求条目需求及任务拆分、形成统一的产品需求列表、探求估算与迭代计划、探求需求沟通及反馈方式

##### 工程敏捷 #####

自动化单元测试、自动化代码扫描、自动化集成测试、自动化功能/流程测试、持续集成、持续交付、部署流水线、主干开发

##### 管理工具 #####

电子看板/物理看板、任务列表、项目状态-燃尽图、增值流图

##### 实施阶段1：基础知识培训、理论准备 #####

企业级敏捷：企业数字化转型与组织变革、规模化敏捷、敏捷领导力

管理实践：

*  产品创新管理：设计思维、用户故事地图、精益创业实践
 *  敏捷交付管理：敏捷项目管理、敏捷scrum、精益看板
 *  管理实践：软开云快速试点、敏捷需求管理、精益数据分析及黑客增长

工程实践：

*  认证体系：华为云HCIP认证、DevOps Professional 认证、SAFe规模化敏捷认证
 *  实例化需求和敏捷测试、单元测试与代码重构、devops方法实践
 *  持续集成与持续交付、微服务与容器开发、软开云工具培训

##### 实施阶段2：推动落地团队级敏捷举措 #####

<table> 
 <thead> 
  <tr> 
   <th>项目</th> 
   <th>详细说明</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>目标</td> 
   <td>引入scrum框架团队，打造高效敏捷团队，实现迭代快速交付</td> 
  </tr> 
  <tr> 
   <td>参与人员</td> 
   <td>顾问、试点团队</td> 
  </tr> 
  <tr> 
   <td>主要活动</td> 
   <td>整个敏捷改善实施过程，将会运行两个单个周期为2周的迭代，会穿插<br>- 敏捷scrum项目管理培训<br>- 构建基于projectMan的敏捷项目管理流程<br>- 依据scrum流程框架，实施具体指导，包括但不限于：敏捷团队组件，基于user story mapping的需求整理，任务划分与估算，product owner指导，product backlog的组织梳理，敏捷发布规划，sprint计划会议，每日例会，进度跟踪与可视化管理，sprint演示与回顾<br>- 在实施指导结束后，进行敏捷实施经验总结与持续改善规划<br></td> 
  </tr> 
  <tr> 
   <td>工作量</td> 
   <td>20人天</td> 
  </tr> 
  <tr> 
   <td>交付物</td> 
   <td>- 打印版培训材料<br>- 敏捷流程改善实施附属物<br>- 定制化的敏捷项目管理流程<br>- 敏捷项目管理平台<br></td> 
  </tr> 
  <tr> 
   <td>客户职责</td> 
   <td>- 保证敏捷改进团队成员积极参与<br>- 根据实施计划提供相应的资源<br></td> 
  </tr> 
 </tbody> 
</table>