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

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

总结回顾

需求流动过程管理

原始诉求–>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观象台、审批系统、堡垒机登录系统、灰度发布引擎、自助服务

监控服务

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

基础环境运维

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

数据分析

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

运维管理平台能力

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

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：推动落地团队级敏捷举措

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