2.1 应用（Application）或服务生命周期管理
应用程序（Application）生命周期管理
聚焦在应用的开发阶段
应用的操作和维护是一个输出服务是循环过程，该循环基于应用的生命周期
服务（Servie）生命周期管理
在应用的开发阶段，聚焦于服务交付的准备
服务交付有其自身的生命周期——战略，设计，转换，运营，持续改进
2.1.1 解释DevOps如何为现代应用程序生命周期管理增加价值
<font color="#c8e6c9">项目的愿景，目标和价值在开始时就达成一致</font>
设计了整个过程的价值流图
使用自动化过程进行验收测试，性能测试和部署
<font color="#ffcdd2">考虑将DevOps方法用于业务流程，以是他们能够同等有效和高效</font>
2.1.2 解释DevOps用于服务生命周期管理时为什么可以改进客户体验
为DevOps重新调整ITSM，创建轻量级ITSM，期以来与一组最低要求的信息，并严格关注与业务连续性
服务主管和可靠性工程师负责收集客户的反馈，以为他们增加价值，例如操作问题，用户体验和质量问题。<br>如果得以批准，这些反馈项将作为变更请求添加到产品的backlog。<br>
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 （或其他类似）的角色定义范围
<font color="#c8e6c9">参与业务规划以了解业务目标，并建议如何使用IT服务实现目标</font>
创建项目的愿景，目标和价值，然后将DevOps团队成员组件在一起
识别IT服务的客户，收集具有业务价值的要求并同意一个时间框架
对提供IT服务及时性（JIT）相应负有全责
这个角色就像产品负责人（Product Owner）在Scrum中一样，对待办项（Product Backlog）或者由新的增加IT服务成本的项目进行管理和排序
相关经验：Scrum 产品负责人（Scrum Product Owner）、服务负责人（Service Owner）
2.2.2 解释为什么在DevOps项目中的可视化看板有利于DevOps实践
<font color="#c8e6c9">经理们、管理员、销售人员、设计人员、开发者、运维人员以及客户的支持人员作为一个统一的团队，可以通过可视化看板来分享业务信息</font>
可视化看板意味着“在没有额外解释的情况下是否每个人都能很容易理解当前的项目状况”
支持快速查看进度和识别问题
2.3 基础设施和架构设计
2.3.1 解释DevOps是如何改变或者影响IT系统基础设施和架构设计的
<font color="#c8e6c9">从项目开始阶段的环境管理和部署的各个方面，应用开发和基础设施管理团队就一起合作</font>
使用敏捷结束来管理基础设施，例如自动加氟和自主维护
在类似生产环境的环境中进行测试，以更早的发现问题
服务连续性计划
对基础设施进行变更管理
2.3.2 解释为什么云计算和虚拟化技术使Dev和Ops集成更容易
虚拟化
快速供应环境
减少部署软件的时间
更容易提供“服务”基础设施
标准化硬件
云计算
快速访问，轻松扩展
部署到完全标准化的堆栈——无须担心配置或维护测试，暂存货生产环境或虚拟机映像
2.4 服务级别要求和协议
2.4.1 说明DevOps如何更改服务级别需求和协议
故事用于收集，定义服务级别要求和服务级别协议，并确定其优先级
2.5 实施一个测试策略：用户/测试/操作故事
2.5.1 解释为什么以及如何在转换到DevOps时需要更改测试策略
<font color="#c8e6c9">自动和手动测试</font>
自动例如单元，组件，系统，部署，验收
手动例如展示，可用性，探索性
功能和肺功能测试
测试从项目开始就是连续的
测试也会随着应用程序，环境或者配置的更改而触发
2.5.2 分析用户故事，测试故事和操作故事的完整性
<font color="#c8e6c9">测试代表着对于开发者来说，故事已经达到“完成”的阶段，而对于用户来说则是“我得到了我想要的”</font>
用户故事——可以使用快乐路径测试“给定X，当发生了Y，然后导致Z”
测试故事——INVEST原则：独立，可谈判，有价值，可估计，小，可测试，具有验收标准
操作故事——检查部署是否工作
