导图社区 DevOps Master-读书笔记
这是一篇关于《DevOps 》读书笔记的思维导图,对《DevOps 》感兴趣的小伙伴可以收藏起来观看哦,希望对大家有所帮助。
编辑于2022-05-31 14:53:45《DevopsMaster白皮 书:企业Devops的成 功之路》读书笔记
1 整体介绍
从业务流程角度编写
DevOps旨在建立 软件/1T服务供应 链( software/1T service supply chain)
Devops概念有助于
建立流水线式(stream-lined)业务运营过程
缩短交付前置时间(delivery lead-time)
Devops框架应该直接支持到业务结果,而不仅 仅是为了开发与运维的协同。要能帮助企业使用 1T服务来支持和提升业务。
2 什么是企业体系的Devops?
双峰挑战(Bimod al challeng e):soR如何适应 频 繁 更 改 的 影 响 ,同 时 还 要 保 持 业 务 连 续 性
交 互 型 系 统 (System of Exchange,SoE )-关注速度
记录型系统(System of Record,SoR)-关注【业务连续性】
问题:SoR的连续性受SoE的频繁变更影响
大多数企业的SoR既有传统的系统与应用还需要维系和使用,使用DevOps建立准时制(just-in-time, JIT)概念的流水线过程可以帮到这类系统
DevOps框架
工具
方法
技能
组织架构
结合所有元素建立流水线的过程
业务快速运营
更快应对变化
企业级DevOps
敏捷开发
持续交付
IT服务管理
应用程序管理
实现和促进业务增长、保障业务连续性
3 DevOps的目标
【即时制流水线】建立流水线式的、即时制的业务流程 - 最大化业务产出
【IT服务供应链】实现从软件交付,提供软件交付到供给IT服务的模式转变
【自动化快速部署系统】利用丰富的方法和工具
没有统一的实施模板
4 Devops Body of Knowledge Devops的知识体系
DevOps主要三大支柱和一个基础组成
4.1 规范敏捷(Disciplined Agile)
定义
速度稳定(Stabilized Velocity)
适应变化(Adaptability for change)
总是能发布优质的无错误代码(Always release high quality bug free code)
更频繁、快速的发布周期,才能更快地响应业务
质量至关重要
工作分解为小任务
JKK (Ji-Kou tei-Kanketsu) - 100%完成某个条 目
为每个角色定义清楚DoD
Product owner的使命
对待办项(Product Backlog)的管理
是新的IT服务计划
4.2 持续交付
实现自动应用程序的构建、部署、测试和发布的流程
关键的关注点
验收测试
性能测试
使用TPI NEXT(测试流程优化)提高这个过程的成熟度
部署流水线实施
每个组织都会有各自不同部署流管线(Pipeline),因发布软件的价值流而异
一个关键的成功因素是为IT服务建立一个单一的部署管线
4.3 IT 服务管理
业务存亡的关键因素
IT服务的连续性
IT服务的高可用性
需求持续维护恢复方案以保持其有效性
轻量级ITSM
只包含所需最少必要信息(MRI)
严格聚焦于业务连续性
每个组织的MRI设置取决于他们的业务
4.4 以TPS(Lean)理念为基础
JIT-及时生产
以单件流的方式
建立流水线式的供应链
自动化
尽可能实现自动化
当出现缺陷时停止整个生产过程
开发和运维的生命周期
采用敏捷方法
开发和运维之间每天或每周的信息同步
5 DevOps团队角色
为保证IT服务的业务连续性,建立小型优质的DevOps团队 ,原则:2个披萨饼规则
团队角色
流程主管 (Process Master)
领导并促进团队,类似于在Scrum中 的Scrum Master。
对整个过程实施可视化管控
求建立单件流作业(one-piece flow)的流水线式的流程
经验需求:Scrum Master,敏捷项目领导(Agile Project Leader)。
服务主管 (Service Master)
对提供IT服务及时性(JIT)负有全责,类似于scrum中的PO
管理和排序Product Backlog
负责IT服务成本规划
经验需求: Scrum 产品负责人(Scrum Product Owner)、服务负责人(Service Owner)。
DevOps工程师 (DevOps Engineer)
优化和维护自动化流程
检查整个自动化过程和工具
DevOps 流程需要很多工具
经验需求:研发(Development)、工具(Tools)
把关人 / 发布协调员 (Gatekeeper / Release coordinator)
监控IT服务的运行状态
监控下一次发布的进展
参考相关标准做部署与否的决策
安全性
合规性
监管要求
运营团队的成熟度和流程观念
可靠性工程师 (Reliability Engineer)(可选)
监控部署过程中的服务,处理服务运行中所产生的问题。
监控流程状态以确保开发团队严格遵守了CI(持续集成)和CD (持续交付)的规则。
监视和管理复杂的构建管线的工作流。
有义务提升测试流程
开发团队 (Development team)
规范的敏捷团队
以可持续的步伐来满足发布计划和发布质量。
经验需求:开发(Development),敏捷(Agile)
运维团队 (Operation team)
采用轻量级ITSM
在整体战略的环境中支持对服务的设计、实施、运维与改进。
在TPS中采用“提前持续改进(KAIZEN in advance)”
经验需求:运维(Operations),持续改善(KAIZEN)
图例
6 组织
在服务管理办公室中组建 DevOps 团队来支持服务主管。
服务管理办公室=Service Management Office
适合小型组织的扁平化组织 (Flat organization)
适合大型复杂组织的矩阵架构 (Matrix organization)
有点儿像流式团队 建立专家池并安排他们作为一个团队给到服务主管。 这个矩阵组织的想法来自丰田的首席工程师。
7 DevOps 的流程
要建立一个流水线式的流程,采用 JKK 在指导 DevOps 团队是最有效的办法
对目标清晰理解
理解正确的工作方式
使工作正确的100%完成
在没有检查的情况下维持质量要求
图例
7.1 业务战略和规划 (Business Strategy and Planning)
服务主管
应该参加业务规划会议
提出如何通过 IT 服务获得业务优势的建议
7.2 市场营销 (Marketing and sales)
服务主管应该与市场部门讨论如何从 IT 服务中获得优势。
识别 IT 服务的客户
收集具有业务价值的需求,并约定时间范围
7.3 管理 (Administration)
流程主管很希望了解如何可视化整个过程
试用Obeya(作战室)可视化整个流程,团队成员可利用可视化管理工具看到过程中的方方面面
信息管理
现场决策(on-the-spot decision)
当跨职能团队使用obeya可以
准确做出决策,加强沟通、保持队形
迅速收集信息、并形成重要的团队意识
7.4 项目规划 (Project Planning)
服务主管
组织服务管理办公室(SMO)并定义团队的基本规则
创建愿景、目标和项目的价值
整合 DevOps 的团队成员
在此阶段
运行中的基础设施被定义
一个整体流程的价值流图表被设计
7.5 需求和设计 (Requirements and Design)
服务主管定义待办任务(Product backlogs)和并安排优先级。
DevOps团队使用待Product backlogs来定义故事(Story)。
用户故事:角色,职能,业务价值/理由,以及运营条件。
测试故事:验收测试用例和服务验收标准。
运维故事:设置 IT 服务的优先级的和业务连续性的运营条件
创建服务级别和运营级别协议
DevOps 工程师和运维团队定义转换、测试和开发的基础设施
开发团队创建发布和迭代计划。
把关人研究 IT 服务的合规性以及 IT 服务的监管要求
可靠性工程师定义测试方法和测试用例
7.6 开发 (Development)
Scrum 是这个阶段最适用的方法论。
开发团队
提交发布计划
使用规范的敏捷方法
迭代(Sprint)周期需要遵循业务的需要
质量内建
XP
TDD
结对编程
重构
十分钟构建
7.7 部署(Deployment)
DevOps 工程师应该建立单件流作业(One-piece flow)方式构建一个单一的自动化部署途径
可靠性工程师和 DevOps 工程师将共同提升测试流程
把关人(Gatekeeper)监控整个过程的进度,决定是否上线。
运维团队研究如何保持业务连续性
7.8 运维(Operation)
运维团队
运维团队采用轻量级的 ITSM 流程来监控 IT 服务运行的状态。
发生灾难事件时确保关键服务正常运行,应该让可靠性工程师参与进来。
恢复点目标-RPO
恢复时间目标-RTO
7.9 维保(Maintenance)
服务主管和可靠性工程师决定是否允许进行维保。
经允许,它们被作为变更请求(RFC-Request For Change)添加到待办任务中。
7.10 客户服务(Customer service)
服务主管和可靠性工程师负责收集客户的反馈
用户体验
质量事件
经允许,它们被作为变更请求添加到待办任务中
7.11 生命周期终止(End of life)
服务主管将决定 IT 服务生命周期的终止条件
发生事件
如何发生
8 DevOps 的实施
8.1 丰田方式(先进但复杂) (TOYOTA way)
于关注 IT 服务战略,并给予业务的战略优势
要由业务负责人或服务主管来领导
大型企业选择矩阵式管理组织架构
在 IT 战略和业务战略之间保持密切的关系
很适合IT 服务提供商
8.2 协同方式(标准) (Collaboration)
专注如何快速和频繁的提供 IT 服务,并保障可靠运行
由服务主管来主导
尤其适合SoE和SoR共存
8.3 持续交付(基本) (Continuous Delivery)
侧重于快速和频繁的软件发布
可以由产品负责人主导
最适合数码产品提供商(例如新型的互联网企业)
9. 结论
DevOps对从大多数IT经验来说是一个整体的模式重大模式的转变
DevOps的培训对员工来说十分重要