目前在备考华为云的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人天 |
交付物 | - 打印版培训材料 - 敏捷流程改善实施附属物 - 定制化的敏捷项目管理流程 - 敏捷项目管理平台 |
客户职责 | - 保证敏捷改进团队成员积极参与 - 根据实施计划提供相应的资源 |