参考来源：
极客时间专栏：DevOps实战笔记，作者：石雪峰
课程链接：https://time.geekbang.org/column/intro/235
DevOps学习回顾02-实践的通用路径-需求分析的拆解-CI的理解-质量体系的实践路径
DevOps 实践的通用路径
第一步:寻找合适的试点项目
一个合适的项目应该具
备以下几个特征：
贴近核心业务。DevOps 要以业务价值为导向
倾向敏捷业务。敏捷性质的业务需求量和变更都比较频繁，更加容易验证 DevOps 改造所带来的效果.
改进意愿优先。
第二步：寻找团队痛点
所谓痛点，就是当前最影响团队效率的事情，同时也是改进之后可以产生最大效益的事情。
第三步：快速建立初期成功
切记不要把面铺得太广，把战线拉得太长，这其实是DevOps 转型初期最典型的一个陷阱。
最关键的就是识别一个改进点，定义一个目标。比如，环境申请和准备时间过程，那么就可以定义这样一个指标：优化 50% 的环境准备时长。这样一来，团队的目标会更加明确，方便任务的拆解和细化，可以在几周内见到明显的成果。
第四步：快速展示和持续改进
取得阶段性的成果之后，要及时向管理层汇报，并且在团队内部进行总结。这样，一方面可
以增强管理层和团队的信心，逐步加大资源投入；另一方面，也能够及时发现改进过程中的问题，在团队内部形成持续学习的氛围，激发团队成员的积极性，可以从侧面改善团队的文化。
DevOps 的价值拆开业务价值和交付能力,交付能力的提升，可以帮助业务以最小的成本进行试错，将新功能快速交付给用户。业务的敏捷能力高低，恰恰体现在对功能的设计和需求的把握上.
需求分析相关的最佳实践
需求分析的方法–影响地图
影响地图是通过简单的Why-Who-How-What分析方法，实现业务目标和产品功能之间的映射关系。
Why 代表目标，它可以是一个核心的业务目标，也可以是一个实际的用户需求。
Who 代表影响对象，也就是通过影响谁来实现这个目标。
How 代表影响，也就是怎样影响用户以实现我们的目标。
What 代表需要交付什么样的功能，可以带来期望的影响。
需求优先级排序–卡诺模型（Kano Model）
卡诺模型将产品需求划分为五种类型：
1.兴奋型：指超乎用户想象的需求，是可遇不可求的功能。比如用户想要一个更好的功能
手机，乔布斯带来了 iPhone，这会给用户带来极大的满足感。
2.期望型：用户的满意度会随着这类需求数量的增多而线性增长，做得越多，效果越好，但难以有质的突破。比如，一个电商平台最开始是卖书，后面逐步扩展到卖电脑、家居用品等多个类别。用户更多的线性需求被满足，满意度自然也会提升。
3.必备型：这些是产品必须要有的功能，如果没有的话，会带来非常大的影响。不过有这些功能的话，也没人会夸你做得有多好，比如安全机制和风控机制等。
4.无差别型：做了跟没做一样，这就是典型的无用功。比如你花了好大力气做了一个需求，但是几乎没有用户使用，这个需求就属于无差别型。
5.反向型：无中生有类需求，实际上根本不具备使用条件，或者用户压根不这么想。这类需求做出来以后，通常会给用户带来很大的困扰，成为被吐槽的对象。
五类产品需求的核心，要做到 3 点,
优先规划期望型和必备型需求，将其纳入日常的交付迭代中，保持一定的交付节奏；
识别无差别型和反向型需求，这些对于用户来说并没有产生价值。如果团队对需求的分类有争议，可以进一步开展用户调研和分析。
追求兴奋型需求，因为它会带来产品的竞争壁垒和差异化。采用精益创业的思想，采用 MVP（最小可行产品）的思路，进行快速验证，并且降低试错成本，以抓住新的机遇
检验用户故事拆分粒度是否合适，可以遵循 INVEST 原则
Independent（独立的）：减少用户故事之间的依赖，可以让用户故事更加灵活地验证和交付，而避免大批量交付对于业务敏捷性而言至关重要。
Negotiable（可协商的）：用户故事不应该是滴水不漏、行政命令式的，而是要抛出一个场景描述，并在需求沟通阶段不断细化完成。
Valuable（有价值的）：用户故事是以用户价值为核心的，所以每个故事都是在对用户交付价值，所以要站在用户的视角思考问题，避免像最近特别火的那句话一样：“我不要你觉得，我要我觉得。”
Estimatable（可评估的）：用户故事应该可以粗略评估工作量，无论是故事点数还是时
间，都可以。如果是一个预研性质的故事，则需要进一步深挖可行性，避免不知道为什
么做而做。
Small（小的）：用户故事应该是最小的交付颗粒度，所以按照敏捷开发方式，无论迭代还是看板，都需要在一个交付周期内完成。
Testable（可测试的）：也就是验收条件，如果没有办法证明需求已经完成，也就没有办法进行验收和交付。
BizDevOps 的核心理念:
引入业务的 DevOps，就成了 BizDevOps，这也是 DevOps 发展的一种潮流
- 对齐业务和开发目标、指标；
- 把握安全、合规指标；
- 及时对齐需求，减少无用开发；
- 体现 DevOps 的价值；
- 让开发团队开始接触业务，不单单是执行，调动积极性。
需求价值的度量
需求价值的定义，可以理解为需求价值的度量，分为客观指标和主观指标 2 个方面
客观指标：也就是客观数据能够表明的指标，比如对电商行业来说，可以从购买流程角
度，识别商品到达率、详情到达率、加入购物车率、完成订单率等等；
主观指标：也就是用户体验、用户满意度、用户推荐率等等，无法直接度量，只能通过
侧面数据关联得出。
对度量的理解(能耗比)
度量不是目的，而是手段，也就是说度量的目标是做正确的事，而度量的手段是正确地做事
好的指标典型特征
1.明确受众。
指标不能脱离受众而单独存在，在定义指标的同时，要定义它所{{c1::关联的对象}}，也就是这个指
标是给谁看。
2. 直指问题。
一看到这个指标，就能意识到问题所在，并自然而然地
进行改进
3. 量化趋势。
按照 SMART 原则，好的指标应该是可以衡量的，而且是可以通过客观数据来自证的。
4. 充满张力。
指标不应该孤立存在，而是应该相互关联构成一个整体。好的指标应该具有一定的张力，向上可以归并到业务结果，向下可以层层分解到具体细节。
配置管理
四个核心理念
- 版本变更标准化；
- 将一切纳入版本控制；
- 全流程可追溯；
- 单一可信数据源。
版本变更的核心是要记录：谁，在什么时间，做了什么改动，具体改了哪些内容，又是谁批准的。
一个完整的提交记录应该至少包括以下几个方面的内容：
- 提交概要信息：简明扼要地{{c1::用一句话}}说明这个改动实现了哪些功能，修复了哪些问题；
- 提交详细信息：详细说明改动的细节和改动方式，是否有潜在的风险和遗留问题等；
- 提交关联需求：是哪次变更导致的这次提交修改，还需要添加上游系统编号以关联提交和原始变更。
配置管理的价值
除了追溯能力以外，还有一个重要的价值，就是记录关联和依赖关系。
怎么理解这句话呢？我先提个问题，
在你的公司里面，针对任意一个需求，你们是否能够快速识别出它所关联的代码、版本、测试案例、上线记录、缺陷信息、用户反馈信息和上线监控数据呢？
对于任意一个应用，是否可以识别出它所依赖的环境，中间件，上下游存在调用关系的系统、服务和数据呢？
CI
是 Continuous Integration 的缩写，集成什么东西？为什么要持续？
CI 的定义
是一种软件开发实践，团队成员频繁地将他们的工作成果集成到一起（通常每人每天至少提交一次，这样每天就会有多次集成），并且在每次提交后，自动触发运行一次包含自动化验证集的构建任务，以便尽早地发现集成问题。
践行 CI的三个问题
1.每一次代码提交，是否都会触发一次完整的流水线？
2.每次流水线是否会触发自动化的测试环节？
3.如果流水线出现了问题，是否能够在 10 分钟之内修复？
CI 涵盖了三个阶段
第一阶段：每次提交触发完整的流水线
第二阶段：每次流水线触发自动化测试
第三阶段：出了问题可以在第一时间修复
实施提交触发流水线，还需要一些前置条件
1.统一的分支策略,有一条以集成为目的的分支
2.清晰的集成规则，根据分支策略(快速验证和反馈,系统集成)选择合适的集成规则
3.标准化的资源池，资源池需要实现环境标准化
4.足够快的反馈周期，要约定能够容忍的 CI 最大时长。
第二阶段：自动化测试的几个关注点
第二个阶段的关键词是：质量内建
1.匹配合适的测试活动。
对于不同层级的 CI 而言，同样需要根据集成规则来确定需要注入的质量活动
2.树立测试结果的公信度。
自动化测试的目标是帮助研发提前发现问题，但是，如果因为自动化测试能力自身的缺陷或者环境不稳定等因素，造成了 CI 的大量失败，那么，这个 CI 对于研发来说就可有可无了。
3.提升测试活动的有效性。
考虑到 CI 对于速度的敏感性，那么如何在最短的时间内运行最有效的测试任务，就成了一个关键问题。
第三阶段：出了问题可以在第一时间修复
真正让 CI 发挥价值的关键，还是在于团队面对持续集成的态度，以及团队内是否建立了持续集成的文化。
交付质量
内建质量的实施步骤
第一步：选择适合的检查类型
选择投入产出比相对比较高的检查类型，是一种合理的策略。
第二步：定义指标并达成一致
确定检查类型之后，就要定义具体的质量指标了。
第三步：建立自动化执行和检查能力
第四步：定义问题处理方式
第五步：持续优化和改进
无论是检查能力、指标、参考值，还是处理方式，只有在运行起来后才能知道是否有问题。
质量指标分两个层面，一个是指标项，一个是参考值
指标项是针对检查类型所采纳的具体指标。
参考值的定义是一门艺术，推荐的做法是将静态指标和动态指标结合起来使用，静态指标就是固定值，对于漏洞、安全等问题来说，采取零容忍的态度，只要存在就绝不放过。
而动态指标是以考查增量和趋势为主，比如基线值是 100，你就可以将参考值定义成小于等于 100，也就是不允许增加。
DevOps 模式下的质量思想
简单概括就是：要在保障一定的质量水平的前提下，尽量加快发布节奏，并通过低风险发布手段，以及线上测试和监控能力，尽早地发现问题，并以一种最简单的手段来快速恢复。
服务可用性实践-故障演练
故障演练就是针对以往发生过的问题进行有针对性地模拟演练。通过事先定义好的演练范围，然后人为模拟事故发生，触发应急响应预案，快速地进行故障定位和服务切换，并观察整个过程的耗时和各项数据指标的表现。
故障演练针对的大多是可以预见到的问题，比如机器层面的物理机异常关机、断电，设备层面的磁盘空间写满、I/O 变慢，网络层面的网络延迟、DNS 解析异常等。这些问题说起来事无巨细，但基本上都有一条清晰的路径，有明确的触发因素，监控事项和解决方法。
DevOps 度量的五条原则(全局、综合、结果、团队、灵活)
1.全局指标优于局部指标：过度的局部优化可能对整体产出并无意义，从而偏离了度量的
核心，也就是提升交付速度和交付质量。
2.综合指标优于单一指标：从单一维度入手会陷入只见树木不见森林的困境，综合指标更
加客观。所以，要解决一个问题，就需要一组指标来客观指引。
3.结果指标优于过程指标：首先要有结果指标，以结果为导向，以过程为途径，一切过程
指标都应该归结到结果指标。
4.团队指标优于个人指标：优先考核团队指标而非个人指标，团队共享指标有助于形成内
部合力，减少内部的割裂。
5.灵活指标优于固化指标：指标的设立是为了有针对性地实施改进，需要考虑业务自身的
差异性和改进方向，而非简单粗暴的“一刀切”，并且随着团队能力的上升，指标也需
要适当的调整，从而不断挑战团队的能力。
DevOps度量体系实践推荐(三组、八项)
- 交付效率
需求前置时间、开发前置时间 - 交付能力
发布频率、发布前置时间、交付吞吐量 - 交付质量
线上缺陷密度、线上缺陷分布、故障修复时长
一个团队实施 DevOps 转型时期望达到的状态
，具备了一种能力，就是始终能够找到新的突破，持续追求更好的状态。（勇猛精进）
被动、主动、突破的50/30/20模型（来自书籍：重塑心灵）
##END提示，>!<
标签：02,需求,CI,用户,路径,DevOps,实践,指标,交付 From： https://blog.csdn.net/qinaide56/article/details/139756925