DevOps Master Student Manual
2022-06-22 17:51:05 0 举报AI智能生成
DevOps Master Student Manual
作者其他创作
大纲/内容
1. DevOps adoption （DevOps的应用）
1.1 什么是DevOps
DevOps 解析
DevOps是“开发”和“运维”的缩写
DevOps是一租最佳实践，强调IT专业人员（开发人员，操作人员，支持人员）在应用和服务生命周期中的协作和沟通
DevOps强调整个组织的合作以及交付和基础设施变更的自动化，从而实现持续集成、持续部署和持续交付
1.1.1 在场景中分析DevOps的反模式
1.1.2 说明DevOps的好处
使用DevOps的公司胜过那些没有使用的
将焦点从做什么转向为什么
问题
创新
协作
可重复，可靠，可预测
更快地相应业务需求
软件投资回报率高
DevOps原则也可以应用于业务
1.1.3 解释为什么DevOps适合当前的软件开发过程
软件并不与它的用户和开发人员分开存在
流行软件开发方法主要关注开发本身，与部署和操作几乎无关
DevOps是关于适应和创新社会结构，文化和技术，以更有效地工作
1.1.4 解释为什么DevOps需要一个特定的心态
旧视角（Old View）
消除认为错误（Eliminate human error）
孤岛思维（Silos）
怪罪文化（Blame culture）
新视角 DevOps（New View DevOps）
全局的系统/方法（Holistic system/methods）
分享故事，反馈（Sharing stories, feedback）
重视个人（Value individuals）
1.1.5 解释DevOps如何适应精益和敏捷Scrum实践
精益 （Lean）
持续改进（Continual improvement）
消除不必要的活动（Elimination of unnecessary activities）
敏捷（Agile）
响应不断变化的需求（Responsive to changing needs）
更短的发布周期（Shorter releasee cycles）
合作（Collaboration）
DevOps
1.2 组织文化
DevOps团队组织
小型组织的扁平化组织 （Flat organization）
大型复杂组织的矩阵式架构（Matrix organization）
1.2.1 解释高效DevOps的四个基础的重要性
合作（Collaboration）：通过互相支持和多人协同来达成特定结果
亲和（Affinity）：共同的租住目标，同理心和不同团队之间的互相学习
工具（Tools）：工具能带来加速效果和成本节省，但工具必须适合采用的工作方法
缩放（Scaling）：伴随组织成长、成熟、甚至收缩，DevOps应该如何做是硬性的变化
1.2.2 分析DevOps思维方式的缺失部分的方案
固化思维模式：才能和能力是天生的
成长性思维模式：人才和能力是可以通过实现学习得到和提到的
寻找
从错误中学习，不要怪罪
积极，频繁，建设性的反馈
沟通，倾听
1.2.3 解释如何通过协作，DevOps思维模式，同理心和信任来形成一个DevOps团队
1.2.4 分析对协作存在误解的情况，并确定正确的故障排除方法
团队中的一些人没有再做应有的贡献
澄清角色和责任
测量能力并允许学习
关注可能的原因——倦怠，个人问题等
有些人没有做足够的沟通
尝试评估潜在因素
确保信任，以身作则
1.2.5 分析冲突管理的场景并识别最佳解决方案
思考文化上的差异（价值观）
分享故事经验
我们在视图解决的问题是什么？
我们是否在解决正确的问题？
我们的团队是否有足够的知识和经验去识别问题，并能理解可能的解决方案会带来的影响是什么？
1.2.6 解释组织人力组员管理促进多元化带来的收益
聘用人员的组合
性别、性取向、宗教、种族、肤色、年龄、能力、教育程度、经验
确保工作环境和方法适配多元化的团队
增加不同的观点和能力，去挑战、询问、创新、反馈
1.3 原则和观念
1.3.1 不同软件开发方法论的用途和作用及其基本原则
瀑布
项目管理流程
按顺序从一个阶段到下一个阶段
为了降低后期错误，需要在生命周期早期花费一定的时间（磨刀不误砍柴工）
敏捷
比早期的方法（比如瀑布）更轻量更具灵活性
关注个人，互动以及协作
在短期内快速获得软件工作成果
Scrum
关注最大化开发团队快速响应需求变化的能力
故事，Sprint,，每日Scrum会议，Scrum Master，完成的定义
1.3.2 解释不通运维方法（ITSM）的使用和用途
ITSM支持服务的持续可用性及维护，以确保交附加值及期望的服务成果。
过程例如
事件与问题管理
可用性与服务连续性管理
服务级别及供应商管理
持续改进
最广泛地使用方法是ITIL，其覆盖了服务战略，服务设计，服务转换，服务运营及服务持续改进。
1.3.3 解释精益系统方法论的使用和用途
LEAN——客户价值的最大化及浪费的最小化
在精益的语境里，浪费是价值的反义词
精益思维的五个原则
价值
价值流
流动
拉动
尽善尽美
规划，需求和设计
2.1 应用（Application）或服务生命周期管理
应用程序（Application）生命周期管理
聚焦在应用的开发阶段
应用的操作和维护是一个输出服务是循环过程，该循环基于应用的生命周期
服务（Servie）生命周期管理
在应用的开发阶段，聚焦于服务交付的准备
服务交付有其自身的生命周期——战略，设计，转换，运营，持续改进
2.1.1 解释DevOps如何为现代应用程序生命周期管理增加价值
项目的愿景，目标和价值在开始时就达成一致
设计了整个过程的价值流图
使用自动化过程进行验收测试，性能测试和部署
考虑将DevOps方法用于业务流程，以是他们能够同等有效和高效
2.1.2 解释DevOps用于服务生命周期管理时为什么可以改进客户体验
为DevOps重新调整ITSM，创建轻量级ITSM，期以来与一组最低要求的信息，并严格关注与业务连续性
服务主管和可靠性工程师负责收集客户的反馈，以为他们增加价值，例如操作问题，用户体验和质量问题。
如果得以批准，这些反馈项将作为变更请求添加到产品的backlog。
如果得以批准，这些反馈项将作为变更请求添加到产品的backlog。
2.1.3 DevOps在用于服务生命周期管理时可以改善客户体验
PBA：Planning，Budget，Accountability 计划、预算和责任
SLR：Service Level Requirement 服务级别需求（针对外部业务/客户）
SLA：Service Level Aggrement 服务级别协议（针对外部业务/客户）
SAC：Service Acceptance Criteria 服务验收标准
OLA：Operation Level Agreement 运维级别协议（针对内部部门间，是SLA的基础）
SDP：Service Design Package 服务设计包
SLP：Service Location Product 服务定位协议
2.2 项目章程和可视化控制
2.2.1 解释如何确定DevOps项目的范围
Service Master （或其他类似）的角色定义范围
参与业务规划以了解业务目标，并建议如何使用IT服务实现目标
创建项目的愿景，目标和价值，然后将DevOps团队成员组件在一起
识别IT服务的客户，收集具有业务价值的要求并同意一个时间框架
对提供IT服务及时性（JIT）相应负有全责
这个角色就像产品负责人（Product Owner）在Scrum中一样，对待办项（Product Backlog）或者由新的增加IT服务成本的项目进行管理和排序
相关经验：Scrum 产品负责人（Scrum Product Owner）、服务负责人（Service Owner）
2.2.2 解释为什么在DevOps项目中的可视化看板有利于DevOps实践
经理们、管理员、销售人员、设计人员、开发者、运维人员以及客户的支持人员作为一个统一的团队，可以通过可视化看板来分享业务信息
可视化看板意味着“在没有额外解释的情况下是否每个人都能很容易理解当前的项目状况”
支持快速查看进度和识别问题
2.3 基础设施和架构设计
2.3.1 解释DevOps是如何改变或者影响IT系统基础设施和架构设计的
从项目开始阶段的环境管理和部署的各个方面，应用开发和基础设施管理团队就一起合作
使用敏捷结束来管理基础设施，例如自动加氟和自主维护
在类似生产环境的环境中进行测试，以更早的发现问题
服务连续性计划
对基础设施进行变更管理
2.3.2 解释为什么云计算和虚拟化技术使Dev和Ops集成更容易
虚拟化
快速供应环境
减少部署软件的时间
更容易提供“服务”基础设施
标准化硬件
云计算
快速访问，轻松扩展
部署到完全标准化的堆栈——无须担心配置或维护测试，暂存货生产环境或虚拟机映像
2.4 服务级别要求和协议
2.4.1 说明DevOps如何更改服务级别需求和协议
故事用于收集，定义服务级别要求和服务级别协议，并确定其优先级
2.5 实施一个测试策略：用户/测试/操作故事
2.5.1 解释为什么以及如何在转换到DevOps时需要更改测试策略
自动和手动测试
自动例如单元，组件，系统，部署，验收
手动例如展示，可用性，探索性
功能和肺功能测试
测试从项目开始就是连续的
测试也会随着应用程序，环境或者配置的更改而触发
2.5.2 分析用户故事，测试故事和操作故事的完整性
测试代表着对于开发者来说，故事已经达到“完成”的阶段，而对于用户来说则是“我得到了我想要的”
用户故事——可以使用快乐路径测试“给定X，当发生了Y，然后导致Z”
测试故事——INVEST原则：独立，可谈判，有价值，可估计，小，可测试，具有验收标准
操作故事——检查部署是否工作
3. 开发和部署
3.1 持续交付和持续集成
3.1.1 解释为什么持续交付对有效的DevOps至关重要
持续交付是应用程序构建，部署，测试和发布过程的自动化实施
确保高效（快速交付）和一致性（对需求）
快速交付使用户能够快速开始使用软件来实现其价值并提供反馈
运维阶段的发布使服务交付以相同的方式得以处理
是实现持续集成的基础
持续交付链=IT价值链
3.1.2 分析如何在场景中集成支持交付
审查当前情况
根据汇报选择不成熟的重点区域。就验收标准达成一致。
计划和实施。首先选择一个小领域实施概念证明
按照标准审查
对其他未成熟区域重复
3.1.3 在场景中分析如何解决持续交付的问题
示例问题
不频繁或有故障（Buggy）的部署
有质量问题的应用程序
没有良好管理的持续集成过程
糟糕的配置管理
发生问题时
检查症状
如何及早发现
根本原因分析
解决原因
根据需要使用风险管理
3.1.4 解释为什么持续集成对于有效的DevOps至关重要
在每次更改时构建和测试整个应用程序
始终保持软件处于可工作状态
3.1.5 分析一个实行持续集成的场景，如分散的团队或者使用分布式的版本控制系统
支持分散团队的工具
分布式的版本控制系统
自动化构建——从不同的来源合并代码
自动化测试——确保构建成功；如果不是，那么谁造成的必须先修复或者撤回，这样其他的人可以继续工作
自动化发布和部署（但是在提交代码发布之前必须进行本地测试）
信息化通讯工具（IM或者VOIP）是持续沟通的前提
GIT Flow模型——标准化的源代码管理模型
3.1.6 分析解决持续集成问题的场景
如果有问题，请检查确保持续集成运行的要求到位
经常性的提交代码（最好每天两次）
创建一个完整的自动化测试套件
保持构建和测试流程的剪短
管理你的开发环境
3.2 部署流水线
3.2.1 解释DecOps部署管道解剖的逻辑
3.2.2 解释如何使用构建和部署脚本
脚本——所有支持应用程序构建、测试、部署和发布的自动化操作
使用构建和部署的过程作为指导——那么构建或部署脚本中的每个人物都可以很容易实现
最终目标——使用一套部署机制，完成发开环境、测试环境和生产环境的部署
脚本也应进行版本化管理，并不断的验证、重构和维护，使它成为部署应用程序的唯一机制。
3.3 持续部署
3.3.1 解释为什么在DevOps中，迭代计划和发布计划应该改变
持续部署——将通过自动化测试的变更部署到指定的环境中
迭代计划——在第一次迭代结束即部署，以尽早验证部署本身是否可以工作
在发布计划和第一次迭代前，就建立好发布的策略
3.3.2 分析如何实施持续部署场景
执行部署的人员应参与创建部署过程
通过日志记录部署活动
不要删除旧文件，而是移动他们
部署是整个团队的责任
在新部署时，应有预热期
快速试错
不要再生产环境上直接进行更改
3.4 质量检查（Ji-Kotei-Kanketsu）,节奏（Rhythm），在制品（Work-in-Progress），单件流（One-piece-flow）
3.4.1 解释质量检测，节奏，在制品和单件流的含义
JKK——清晰理解的目标，确保高质量的工作，缺陷不会传递到下一个过程，“完成”的定义是至关重要的
Rhythm节奏——DevOps团队工作和部署到生产环境工作的节奏
Work-in-progress（WIP）在制品——减少在制品以减少瓶颈和加速循环周期
One-piece-flow 单件流——个体或团队一次性的弯沉给一个事项，保证快速、流畅的流动
3.4.2 场景分析：用JKK，Rhythm，WIP，One-piece-flow等方法找到解决方案
有用的检查
缺陷是否已经传给了下一个过程？
已完成是不是已经明确定义？
是否有一个恒定的部署节奏？
有多少处于进行中的工作？
有多少人在处理多个事项？
3.5 自动化、工具与测试
3.5.1 解释为什么自动化对有效的DevOps来说很重要？
自动化支持DevOps的目标
通过简化和移除哪些重复度高的工作可以降低可能由于人为导致的错误
通过减少劳动力，能量和/或材料
以提升质量、精度和准确度
3.5.2 解释如何使用工具来促进DevOps
DevOps团队需要工具来有效地完成他们的工作
软件开发
本地开发环境
Artefact管理
测试
监控
3.5.3 解释如何使用工具来支持DevOps的心态和文化
方向（Direction）+文化（Culture）+思维（Mindset）=>Tool Set 工具集
3.5.4 解释DevOps测试自动化的重要性
3.5.5 通过分析一个场景来说明如何正确的选择自动化验收测试方法
验收标准
输入
场景
输出
测试实现层
使用领域语言定义
与用户界面元素无关
应用驱动层
理解如何与应用程序交互并使之反馈结果
4. 运维实践与组织弹性
4.1 管理数据；应用基础设施和运行环境；组件和依赖
4.1.1 阐述在DevOps模式下对数据库的数据进行管理时可能会遇到的问题
信息量巨大
应用数据的生命周期与系统的其他部分不同
数据的迁移过程难以实现自动化
测试数据的管理和使用生产数据测试会来带来问题
4.1.2 分析一个在DevOps中使用数据库的场景并给出问题的最佳解决方案
对数据库进行版本化并使用工具自动地管理迁移
力争通过Schema变更来实现前向和后向的兼容性
确保在配置过程中为测试创建好所依赖的数据
只有当数据是应用程序启动所需时才保留测试之间的公共设置
尽可能使用应用程序的公共API为测试设置正确的状态
在多数情况下，不把生产数据直接转储出来用于测试目的。谨慎选取生产数据或者验收容量测试的数据的一个小子集来创建自定义数据集。
4.1.3 分析一个场景并确认最好的方式在部署后去准备一个基础设施环境去发布和管理
全面管理所有基础设施的方法
通过版本控制系统定义你的基础架构要求的状态
基础架构应该是自主的，例如，它应该能够自动地将自身更正到所要求的状态
通过仪表盘和监控，你始终能够了解你的的基础架构和实际状态
4.1.4 分析一个场景并建议一个常用的战略去管理组件
精心设计的应用程序，适合于组件化构建
定义组件
根据故事的功能区/组来组织团队，而不是根据组件
在流水线中构建组件，然后移动到整合流水线
考虑依赖关系
使用artefact（人工制品库）存储库
4.1.5 解释如何管理依赖
4.2 确认管理和版本控制
4.2.1 解释为什么版本控制是高效DevOps的关键
保留文件的多个版本以便对不同版本的跟踪，并能够始终回到正常可工作的版本
与软件相关的每个项（Artefact）都应受版本控制
合作的基础
DevOps的实践可以减少周期时间和提高质量，从持续集成和自动化测试到一键部署，一切都依赖于版本控制
4.2.2 解释如何保持对数据，基础结构和组件的版本控制
4.2.3 分析场景并制定配置管理问题的最佳策略
问题：开发站点之间的网络基础设施既缓慢又不可靠
为团队创建本地存储库，并将团队的更改每天合并到主线
问题：具有并行分支的庞大项目
为这些相对长期存在的分支和一个小的专用合并团队开发一个清晰的描述和合并策略，包含一个单独的持续集成服务器来管理该过程
问题：为每个客户都简历了软件的独立分支。而每个分支的产品代码和测试用例都在其单独的版本控制库中
使用公共版本控制库来存储代码和测试，以便清楚地链接他们
4.3 云和不变基础设施
4.3.1 解释为实现高效的DevOps，何时适合和不适合迁移到云基础架构
迁移到云上
去除采购、安装和维护硬件的开销
灵活的资源使用去扩大和收缩
避免厂商锁定
新组织的快速启动
标准化的协议栈
符合多DevOps的原则
不迁移到云上
移动到云或购买工具本身并不会让DevOps工作（DevOps不止这样）
已经对现有基础设施投资
增长和需要拥有自己的基础设施的考量
第三方，服务水平和安全问题
性能——对大型数据集的操作，高性能服务器可以比一些云服务更快
4.3.2 解释怎样用DevOps方法管理基于云的基础架构
研究各种可选项
服务——基础架构，平台
服务级别
安全，合规要求
弹性
监控，报告
基于云的基础架构需要较少的管理，但不是没有管理
4.4 业务连续性
4.4.1 解释DevOps如何促进业务连续性
IT服务的高可用性对于整个企业的生存至关重要
使用风险降低措施和恢复选项
持续维护恢复能力至关重要
4.5 规模化
规模化（Scaling）是一个组织在其整个生命周期中发展，成长和演进的过程
成功的会魔化（Scaling）既是艺术又是科学，来实现何时以及如何根据需要改变方向以适应不断变化的华景
4.5.1 分析场景：解释是否以及为什么在这种情况下伸缩很重要，并确定最佳方式
4.5.2 对规模化过程中的错误场景进行分析，并找到解决问题的最佳方法
缩小，但一些大型项目正在占用资源和成本
识别出那些没有业务价值的项目，并取消他们
对所有软件都扩展到非常频繁的发布，在资源水平上是不可能的
分析哪些软件需要24/7/365提供服务或者需要不断更新版本，哪些软件则不是这样。
对这些不同的软件采用不同的发布周期
对这些不同的软件采用不同的发布周期
管理冲突
不要容忍欺凌/责怪文化。但是承认和股利健康的冲突，作为识别新思路和解决问题的方法
4.5.3 解释社会政策和招聘活动是如何支持DevOps扩展的
关注团队规模，5-7人的小团队工作良好
更大的团队会变得官僚作风，并会扼杀创新
从内部晋升，同时也从外部招聘
维持团队只是和动力，但也要引入新的想法和所需的技能
在招聘时，除了技术需求，也要关注人际关系和文化方面的问题
对初级员工或新员工提供培训和支持
关注影响员工动机的因素：福利、机会和工作量以及有竞争力的工资
5. 服务生命周期的结束
5.1 产品或服务使用周期结束的条件
5.1.1 在终止一个服务或产品的使用之前应该满足哪些条件
使用周期结束也应被作为一个故事对待，像其他条件一样
这个故事会说明结束原因，例如没有更多的业务需要，或者被更便宜/更简单/更有效的服务取代
故事会说明终止的条件是什么
如何处理与旧服务相关的数据/文档/工具/其他组件
如何确保替换的服务在旧的服务官逼迁准备就绪
在什么时间，以什么顺序关闭旧的服务
0 条评论
下一页
