DevOps学习回顾02-实践的通用路径-需求分析的拆解-CI的理解-质量体系的实践路径

最新推荐文章于 2024-06-30 16:31:39 发布

勇敢的星火

最新推荐文章于 2024-06-30 16:31:39 发布

阅读量558

点赞数 17

文章标签： devops 学习需求分析

本文链接：https://blog.csdn.net/qinaide56/article/details/139756925

版权

参考来源：
极客时间专栏：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，也就是不允许增加。