【DevOps】DevOps如何落地实施（二）

李易安QSR

已于 2022-10-30 11:15:45 修改

阅读量797

点赞数 1

分类专栏： DevOps 文章标签： devops

于 2022-02-07 18:37:17 首次发布

本文链接：https://blog.csdn.net/weixin_44025411/article/details/122812978

版权

DevOps 专栏收录该内容

9 篇文章 3 订阅

订阅专栏

文章目录

参考资料
六、自动化测试
七、内建质量
八、技术债务
九、环境管理&部署管理
十、混沌工程
十一、DevOps的正向度量体系如何建立
十二、持续改进才是团队引入DevOps时最该具备的特质

《DevOps如何落地实施》一共两篇笔记
【DevOps】DevOps如何落地实施（一）
【DevOps】DevOps如何落地实施（二）

参考资料

《DevOps实战笔记》极客时间，石雪峰

书接上文

六、自动化测试

图片来源：“DevOps Handbook"
测试数据、用例、脚本的管理，测试过程中数据的收集、度量、分析和展示，以及测试报告的发送等，都是一个成熟的自动化测试框架应该具备的功能。

UI自动化测试（投产比低）
接口自动化测试（投产比高）

需要搭建接口自动化，可以参考我的博客
【接口自动化平台搭建】TestNG搭建接口自动化（一）

单元测试

一般是由开发的领导主导，但是国内一般情况下，单元测试的覆盖面并不广泛，也不会被测试领导认可。

测试误报率是体现自动化测试稳定性的一个核心指标。对于不同测试类型和产品形态，误报的的原因有很多。比如测试环境的网络不稳定导致的连接超时、测试脚本和测试工具本身的固有缺陷导致的执行失败、测试数据不齐备、测试资源不可用等等。由于测试误报的客观存在，即便执行了自动化测试并给出了测试结果，但还是需要人工审查判断之后，才能将真正的问题上报缺陷系统。这样一来，在自动化执行末端加入了人工处理，就导致自动化测试难以大规模推行，这也是自动化测试略显“鸡肋”的原因之一。

那么，要如何解决这个问题呢？这就要依赖于自动化测试结果的分析啦。

对自动化测试的问题进行分类。
你要弄清楚一次失败是环境问题、网络问题、功能变更，还是系统缺陷？
你需要将失败的用例归纳到这些分类之中。

当一个类别的问题非常多的时候，你可以考虑进行拆分，比如网络问题，你可以拆分为网络不可达、延迟超时、域名解析错误等等。

增加已有分类的自动识别能力。比如，对于捕获到的常见异常，可以根据异常信息自动上报到对应的错误分类，从而简化人工识别和归类错误的工作量。

提升自动化测试工具和环境的健壮性，对已知问题增加一定的重试机制。持续积累和丰富错误分类，有针对性地开展改进工作，从而不断提升自动化测试的稳定性。

七、内建质量

什么是内建质量？

在美国汽车工厂装配流水线的末端，总是有个人在拿着橡胶锤子敲打车门，以检查车门是否安装良好。如果一个公司要靠“拿锤子的人”来保证质量，这就说明，这个公司的流程本身可能就有问题。

传统的软件开发过程中，一个软件的质量往往是由测试团队进行保证，测试工作并不直接提升软件质量，只是为了证明软件质量有缺陷。

因此，正确的做法是，应该将质量内建到整个流程中。

那如何实施？

在需求环节：定义清晰的需求准入规则。比如需求的价值衡量指标是否客观、需求的技术可行性是否经过了验证、需求的依赖是否充分评估、需求描述是否清晰、需求拆分是否合理、需求验收条件是否明确等等。“一句话需求”和“老板需求”是非常典型的例子。由于没有进行充分沟通，研发就跟着感觉走，结果交付出来的东西完全不是想要的，这就带来了返工浪费。
在开发阶段：代码评审和持续集成。
在测试阶段：使用各类自动化测试，以及手工探索测试，覆盖安全、性能、可靠性等，来保障产品质量；在部署和发布阶段，可以增加数据库监控、危险操作扫描、线上业务监控等多种手段。

快速失败原则

关于内建质量，有个经典的案例就是丰田公司的安灯系统，也叫作安灯拉绳。

丰田的汽车生产线上方有一条绳子，如果生产线上的员工发现了质量问题，就可以拉动安灯系统通知管理人员，并停止生产线，以避免带有缺陷的产品不断流向下游。

要知道，在生产制造业中，生产线恨不得 24 小时运转，因为这样可以最大化地利用时间，生产更多的产品。可是现在，随随便便一个员工就可以让整条生产线停转，丰田公司是怎么想的呢？

其实，这背后的理念就是“Fail fast”，即快速失败。如果工人发现了有缺陷的产品，却要经过层层审批才能停止生产线，就会有大量带有缺陷的产品流向下游，所以，停止生产线并不是目的，及时发现问题和解决问题才是目的。

当启动安灯系统之后，管理人员、产线质量控制人员等相关人员会立刻聚集到一起解决这个问题，并尽快使生产线重新恢复运转。更重要的是，这些经验会被积累下来，并融入组织的能力之中。

内建质量扭转了看待产品质量的根本视角，也就是说，团队所做的一切不是为了验证产品存在问题，而是为了确保产品没有问题。

八、技术债务

传送门：写个代码也能“欠债”？关于“技术债务”的事儿

九、环境管理&部署管理

环境问题，绝对是一个顶级背锅侠。“这一定是环境问题！”是不是很耳熟

1、环境管理的挑战

环境种类繁多。比如开发环境、测试环境、UAT 用户验收测试环境、预发布环境、灰度环境、生产环境等。
环境复杂性上升。现代应用的架构逐渐从单体应用向微服务应用转变。随着服务的拆分，各种缓存、路由、消息、通知等服务缺一不可，任何一个地方配置出错，应用都有可能无法正常运行。这还不包括各种服务之间的依赖和调用关系，这就导致很多企业部署一套完整环境的代价极高，甚至变成了不可能完成的任务。
环境一致性难以保证。比如，那句经典的甩锅名言“在我的机器上没问题”说的就是环境不一致的问题。如果无法保证各种环境配置的一致性，那么类似的问题就会无休止地发生。实际上，在很多企业中，生产环境由专门的团队管理维护，管理配置还算受控。但是对于开发环境来说，基本都属于一个黑盒子，毕竟是研发本地的电脑，即便想管也管不到。
环境交付速度慢。
环境变更难以追溯

解决方案：
一切皆代码。基础设施即代码。就是用一种描述性的语言，通过文本管理环境配置，并且自动化完成环境配置的方式。典型的就是以 CAPS 为代表的自动化环境配置管理工具，也就是 Chef、Ansible、Puppet 和 Saltstacks 四个开源工具的首字母缩写。

通过将所有环境的配置过程代码化，每个环境都对应一份配置文件，可以实现公共配置的复用。 在这里插入图片描述
开发运维打通的 GitOps 实践顾名思义，GitOps 就是基于版本控制系统 Git 来实现的一套解决方案，核心在于基于 Git 这样一个统一的数据源，通过类似代码提交过程中的拉取请求的方式，也就是 Pull Request，来完成应用从开发到运维的交付过程，让开发和运维之间的协作可以基于 Git 来实现。

虽然 GitOps 最初是基于容器技术和 Kubernetes 平台来实现的，但它的理念并不局限于使用容器技术，实际上，它的核心在于通过代码化的方式来描述应用部署的环境和部署过程。

在 GitOps 中，每一个环境对应一个环境配置仓库，这个仓库中包含了应用部署所需要的一切过程。比如，使用 Kubernetes 的时候，就是应用的一组资源描述文件，比如部署哪个版本，开放哪些端口，部署过程是怎样的。

当然，你也可以使用 Helm 工具来统一管理这些资源文件。如果你还不太熟悉 Kubernetes，可以简单地把它理解为云时代的 Linux，而 Helm 就是 RPM 或者 APT 这些包管理工具，通过应用打包的方式，来简化应用的部署过程。除了基于 Kubernetes 的应用，你也可以使用类似 Ansible Playbook 的方式。只不过与现成的 Helm 工具相比，使用 Ansible 时，需要自己实现一些部署脚本，不过这也不是一件复杂的事情。

你可以看看下面的这段配置文件示例。这些配置文件采用了 yml 格式，它描述了应用部署的主要信息，其中，镜像名称使用参数形式，会有一个独立的文件来统一管理这些变量，你可以根据应用的实际版本进行替换，以达到部署不同应用的目标。


apiVersion: extensions/v1beta1
kind: Deployment
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: demo 
    spec:
      containers:
      - name: demo
        image: "{{ .Values.image.tag }}"
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80

现在，我们来看看这个方案是如何实现的。

首先，开发人员提交新的代码改动到 Git 仓库，这会自动触发持续集成流水线，对于常见的版本控制系统来说，配置钩子就可以实现。当代码经过一系列的构建、测试和检查环节，并最终通过持续集成流水线之后，就会生成一个新版本的应用，并上传到制品库中，典型的就是 Docker 镜像文件或者 war 包的形式。

以上面的配置为例，假如生成了应用的 1.0 版本镜像，接下来，会自动针对测试环境的配置仓库创建一个代码合并请求，变更的内容就是修改镜像名称的版本号为 1.0。这个时候，开发或者测试人员可以通过接受合并的方式，将这段环境变更配置合入主干，并再一次自动化地触发部署流水线，将新版本的应用部署到测试环境中。每次应用的部署采用相同的过程，一般就是将最新版本的应用制品拷贝到服务器并且重启，或者更新容器镜像并触发滚动升级。

这个时候，测试环境就部署完成了，当然，如果使用 Kubernetes，可以利用命名空间的特性，快速创建出一套独立的环境，这是使用传统部署的应用所不具备的优势。在测试环境验收通过后，可以将代码合并到主分支，再一次触发完整的集成流水线环节，进行更加全面的测试工作。

当流水线执行成功后，可以自动针对预发布环境的配置仓库创建一个合并请求，当评审通过后，系统自动完成预发布环境的部署。如果职责分离要求预发布环境的部署必须由运维人员来操作，把合并代码的权限只开放给运维人员就行了。当运维人员收到通知后，可以登录版本控制系统，查看本次变更的范围，评估影响，并按照部署节奏完成部署。而这个操作，只需要在界面点击按钮就可以实现了。这样一来，开发和运维团队的协作就不再是一个黑盒子了。大家基于代码提交评审的方式完成应用的交付部署，整个过程中的配置过程和参数信息都是透明共享的。

最终实现环境配置的共享和统一管理。

2、低风险的发布手段

1）蓝绿部署

蓝绿部署就是为应用准备两套一模一样的环境，一套是蓝环境，一套是绿环境，每次只有一套环境提供线上服务。这里的蓝和绿，只是用于区分两套环境的标志而已。在新版本上线时，先将新版本的应用部署到没有提供线上服务的环境中，进行上线前验证，验证通过后就达到了准备就绪的状态。在发布时间点，只要将原本指向线上环境的路由切换成另外一套环境，整个发布过程就完成了。

一般来说，这种方式的实现成本比较高。因为有两套一模一样的环境，只有一套用于真正地提供线上服务。为了减少资源浪费，在实际操作中，另外一套环境可以当作预发布环境使用，用来在上线之前验证新功能。另外，在这种模式下，数据库普遍还是采用同一套实例，通过向下兼容的方式支持多个版本的应用。在这里插入图片描述

2）灰度发布

灰度发布，也叫金丝雀发布。与蓝绿部署相比，灰度发布更加灵活，成本也更低，所以，在企业中是一种更为普遍的低风险发布方式。

灰度发布有很多种实现机制，最典型的就是采用一种渐进式的滚动升级来完成整个应用的发布过程。当发布新版本应用时，根据事先设计好的灰度计划，将新应用部署到一定比例的节点上。当用户流量打到这部分节点的时候，就可以使用新的功能了。

值得注意的是，要保证同一个用户的行为一致性，不能时而看到新功能，时而看到老功能。当然，解决办法也有很多，比如通过用户 ID 或者 cookie 的方式来识别用户，并划分不同的组来保证。

新版本应用在部分节点验证通过后，再逐步放量，部署更多的节点，依次循环，最终完成所有节点的部署，将所有应用都升级到新版本。分批部署只是实现灰度发布的方法之一，利用配置中心和特性开关，同样可以实现指向性更强的灰度策略。比如，针对不同的用户、地域、设备类型进行灰度。在这里插入图片描述

3）暗部署

随着 A/B 测试的兴起，暗部署的方式也逐渐流行起来。**所谓暗部署，就是在用户不知道的情况下进行线上验证的一种方法。**比如后端先行的部署方式，把一个包含新功能的接口发布上线，这个时候，由于没有前端导向这个接口，用户并不会真实地调用到这个接口。当用户进行了某些操作后，系统会将用户的流量在后台复制一份并打到新部署的接口上，以验证接口的返回结果和性能是否符合预期。

比如，对于电商业务场景来说，当用户搜索了一个关键字后，后台有两种算法，会给出两种返回结果，然后可以根据用户的实际操作，来验证哪种算法的命中率更高，从而实现了在线的功能验证。

以上这三种低风险发布手段，如果应用规模整体不大，蓝绿部署是提升系统可用性的最好手段，比如各类 Hot-standby 的解决方案，其实就是蓝绿部署的典型应用。而对于大规模系统来说，考虑到成本和收益，灰度发布显然就成了性价比最高的做法。如果想要跑一些线上的测试收集真实用户反馈，那么，暗部署是一种不错的选择。

十、混沌工程

传送门：什么是混沌工程？

十一、DevOps的正向度量体系如何建立

在这里插入图片描述
所有指标细化、数据化。

十二、持续改进才是团队引入DevOps时最该具备的特质

谈到持续改进，有一个非常著名的方法体系，叫作 PDCA，也称为戴明环。没错，你从名称就能看出，这套方法体系同样来自于质量管理大师戴明博士。PDCA 是四个英文单词的缩写，也就是 Plan（计划）、Do（实施）、Check（检查）和 Action（行动）。

PDCA 提供了一套结构化的实施框架，任何一项改进类工作，都可以划分为这四个实施阶段。通过 PDCA 循环的不断迭代，驱动组织进入一种良性循环，不断识别出新的待改进问题。针对这些问题，首先要进行根因分析，制定具体的实施计划。然后，不定期地检查实施的结果和预期目标是否一致。最后，要对改进结果进行复盘，把做得好的地方保留下来，把做得不好的地方纳入下一阶段的循环中，继续改进。

在这里插入图片描述
这个方法听起来也没什么复杂的，每个人都能够理解，关键在于是否真正地用心在做。

构建持续改进的核心，就在于构建一个学习型组织。

1、鼓励正向回溯和总结

故障回溯并不一定以确定责任为第一要务，更重要的是，要识别系统流程中的潜在问题和漏洞，并通过后续机制来进行保障，比如增加测试用例、增加产品走查事项等等。

其实，大到线上故障，小到日常错误，都值得回溯和总结。

这就需要有团队来负责收集和总结这些常见的错误，并提取关键错误信息和常见解决方法，形成一个案例库。同时，在构建系统中嵌入一个自动化服务，下次再有人遇到编译错误的时候，就可以自动匹配案例库，并给他推送一个问题分析报告和解决建议，帮助团队成员快速解决问题。

这样，随着团队智慧的不断积累，越来越多的问题会被识别出来，从而实现组织知识共享和研发辅助的能力，这在很多大公司里面都是一个重点建设方向。仔细想想，这本身就是一个 PDCA 的过程。

不过，这里要补充一点，团队实施持续改进的过程，不应该是一次大而全的变革，而应该是一系列小而高频的改进动作。因为大的变革往往影响众多，很容易半途而废，而小的改进更加温和，也更加容易成功。为了方便你理解，我跟你分享一张示意图。
在这里插入图片描述

2、预留固定时间进行改进

很多时候，团队都处于忙碌的状态，时间似乎成了推行 DevOps 的最大敌人。于是，团队就陷入了一种太忙以至于没时间改进的状态中。

如果团队选择在同等时间内去做更多的功能，那就说明，至少在当前这个阶段，业务开发的重要性要高于 DevOps 建设的重要性。

可问题是，业务的需求是没有止境的。有时候，我去问一线员工：“你觉得有什么地方，是 DevOps 可以帮你的吗？”要么大家会说“没什么特别的，现在挺好”，要么就是一些非常琐碎的点。实际上，这只能说明，要么是没想过这个事情，要么就是不知道还有更好的做法。但是，如果不能调动一线员工的积极性，持续改进也就无从谈起了。

所以，正确的做法是，在团队的日常迭代中，事先给改进类工作预留一部分时间，或者是在业务相对不那么繁忙的时候（比如大促刚刚结束，团队在调整状态的时候），在改进工作上多花些时间。

这些工作量主要用于解决非功能需求、技术改进类问题，比如修复技术债务、单元测试用例补充、度量识别出来的改进事项等。通过将这部分改进时间固定下来，可以培养团队持续改进的文化。

我比较推荐的做法是，在团队的 Backlog 中新增一类任务，专门用于记录和跟踪这类持续改进的内容。在迭代计划会议上，对这类问题进行分析，并预估工作量，保证团队有固定的时间来应对这些问题。

另外，很多公司也开始流行举办 Hackathon Day（黑客马拉松），是说在有限的时间里通过编程实现自身的想法和创意，在这个过程中，充满了积极探索的精神、自由散发的思维和挑战极限的理念，通过团队协作与互相激发，实现创意到开发的全过程。