西安网站微信开发我的百度网盘登录入口

为什么需要 DevOps

传统软件以瀑布模型进行开发，软件以单体服务的形式发布。立项、开发、测试、运维等步骤几乎是割裂的，软件的升级迭代也非常缓慢。笔者毕业时的第一家公司就是这种形式，一个项目从立项、开发到最终部署上线要近两年的时间。在互联网时代，市场需求瞬息万变，谁能快速响应需求，谁就能在竞争中脱颖而出。这对软件的交付效率提出了更高的要求。

随着分布式微服务架构的普及，一个单体软件被拆分为多个为服务，服务变得轻量简洁，并且可以并行开发，快速迭代上线。在带来开发效率提升的同时，微服务架构也带来了运维上的复杂性，因此分布式微服务架构必然是重运维的，传统的靠人肉运维的方式已经无法适应这种变化，由此催生了 DevOps 文化。

DevOps 的目的是加强开发和运维之间的密切联系，以产品为核心，需求为导向，通过自动化的”持续集成“、”持续交付“，使得软件的编译构建、测试审查、部署上线可以更加频繁可靠的执行，实现从开发到上线的自动化，打造一条从需求到交付的自动化生产流水线。

从对技术人员的要求来看，DevOps 不是将开发和运维合并，而是将开发变成运维，或者说运维需要有开发能力，从而实现人管代码，代码管机器，最大程度的减少人为干预，实现自动化交付。

按照康威定律，一个软件的架构设计会受到组织架构的影响。在传统的瀑布式开发模式下，开发、测试、运维团队是分开的，而在微服务架构下，一个全功能的小团队更符合微服务架构的开发模式。最著名的便是亚马逊的 “two pizza” 团队，一个两张披萨可以喂饱的团队，从需求设计、开发测试到部署运维，整个团队负责一个完整的软件生命周期。

DevOps 需要的团队文化

和传统的开发、测试、运维割裂开来的团队不同，DevOps 需要跨职能的全干团队，对比如下：

在整个软件开发生命周期中，除了具体的开发任务是需要不同的开发人员负责完成外，整个团队需要共享需求背景、软件设计、系统架构和运维知识。这样即使开发人员只开发自己负责的模块，也能对软件的整体架构有足够的了解，从而可以作为一个整体进行工作，而不是割裂为互不相干的团队，在出问题时也避免了对某个成员的单点依赖。

采用 DevOps 的目标就是要建设这样一个团队，这不仅仅是一种技术、工具或者流程的改变，更是管理和协作方式以及团队文化上的改变。

一个 DevOps 团队应该具有的文化有：

• 崇尚标准化与自动化：只有标准化的东西才能自动化，只有自动化的东西才能规模化。团队要建立凡事皆可自动化的思想，不断优化软件上线流程，减少不必要的人力干预。

• 主人翁精神：DevOps 团队中的成员并不是只负责自己的一小块，而是面向整个产品或服务做交付，需要对服务的软件架构、系统架构、CICD 流程有足够的了解。这也更有利于激发团队成员的技术热情和归属感，避免出现螺丝钉现象。

• 协作精神：团队成员之间要有良好的协作能力，除了日常沟通外，能以文档形式留存的内容都应该建立文档。比如软件设计文档、API 文档，良好的文档留存可以提高知识功效效率，减少知识传递成本，从而提高团队协作效率。

• 创新探索精神：团队成员需要不断学习新的技术，用于用新的技术服务于流程自动化的改进。

除此之外，一个满足 DevOps 的团队成员需要具备以下特点：

• 全栈式工程师：DevOps 团队的成为应该熟悉不同的技术栈，能够使用不同的语言、利用不同的工具来实现不同的需求。以笔者的团队为例，业务服务用的是 Java，中间件用的是 Go，运维用的是 Python、Shell、Groovy 等语言。工具上既有 Maven，也有 Jenkins、Kubernetes 等工具。这些技术应该是整个团队共享的，而不是只由运维人员掌握。

• two pizza 团队：团队的人数应该维持在两张披萨可以喂饱的规模，一旦超过这个规模，团队的沟通管理规模就会增加。与此同时，小团队的能力其实是不足以完成大型单体服务的开发的。根据康威定律和软件的单一职责原则，小团队应该负责维护若干个独立的微服务。这要求我们事先做好服务拆分和团队职责划分。

• 全栈团队：这里的全栈指的是团队作为一个整体，从需求分析、开发、测试、部署、运维，到最后的监控和故障修复，需要对软件的整个生命周期负责，务必保证服务的质量和持续迭代。

一个好的 DevOps 建设可以带来如下价值：

• 提升团队成员的积极性和归属感：团队成员需要面向整个产品和架构负责，而不是只负责自己的一小块，这样可以提高成员工作学习的积极性，避免出现螺丝钉现象。

• 更短的发布准备时间：自动化的交付流程可以提高发布频率，从而降低每次发布的影响范围，减少发布准备时间。

• 更高的软件质量：自动化的测试和代码扫描可以提高软件质量，减少人为错误。

• 更低的故障平均恢复时间：通过分钟级别的近实时监控告警以及链路追踪、上下文分析，可以快速诊断问题，结合自动化的发布流程，可以做到快速修复，快速上线。

• 更高的团队效率：通过自动化建设，避免了大量重复性的工作，开发人员可以专注在更有创造性的工作和学习上。

DevOps 需要的技术架构

上面介绍了 DevOps 所需的团队文化和成员要求，本小节我们讨论下建设 DevOps 的技术需求。

DevOps 的工程实践是要建立一套自动化的软件发布流水线，一个基于 Cloud Native 的 DevOps 的软件生产线示例如下：

为此我们需要一套完整的工具或框架来支持上述的软件生产线，这些工具或框架包括但不限于:

• 问题跟踪工具，比如 Jira 等
• 版本管理工具，比如 Git。
• 编译构建工具，比如 Maven、Docker 等。
• 制品仓库工作，比如 Nexus、Harbor等。
• 软件质量工具，比如 SonarQube 等。
• 容器编排工具，比如 Kubernetes。
• 流程编排工具，比如 Github Action、Jenkins、ArgoCD 等。

在工具选择时需要注意：

1. 尽可能选择 CNCF 已经毕业或者长期活跃的工具。这样遇到问题时，可以参考文档或者从社区获得帮助。

2. 每种类型尽可能只选择一个工具，减少维护成本。比如容器编排就是 Kubernetes，镜像仓库的话可以选 Harbor，它是 CNCF 唯一已经毕业的镜像仓库工具。

上述流程需要一个像 Github Action 或者 Jenkins 这样的工具将其串联成一个 Pipeline 工作流。以笔者熟悉的 Jenkins 为例、下图是一个最基本的 Jenkins pipeline，开发人员 push 代码后会自动执行基本的镜像构建和发布，然后按需执行单元测试、代码检测和部署。

整体流程如下：

• 开发人员 push 代码到 Git 代码库
• Jenkins 自动触发，拉取代码并并进行编译构建
• 如果是在测试环境，通常会执行单元测试和代码审查
• 构建镜像并发布到镜像仓库
• 通知 Kubernetes 部署到测试或生产环境
• 部署完成后，按需进行流量调度，比如灰度发布、蓝绿部署等
• 对整体服务进行监控，根据监控结果进行故障修复或扩缩容