1. 前言

对于搞云原生应用的同学，对于DevOps和DORA应该都不陌生。但对于传统应用程序开发的同学，经常被DevOps, Microservice, CICD, DORA这些新颖的名词搞得晕头转向。那么到底什么是DevOps? 什么是DORA呢？

2. 解析

2.1 DevOps

DevOps并不是凭空创造出来的一个概念，它也是有着历史的发展过程的。在知乎上找到了一篇不错的文章，对DevOps的解析很清楚，感兴趣的同学可以去读一下DevOps到底是什么意思？ - 知乎 (zhihu.com)。

简而言之，DevOps是继软件开发的瀑布模型、敏捷模型后的第三种软件开发的方法论，可以理解为：

• 第一阶段：瀑布模型
• 第二阶段：敏捷模型
• 第三阶段：DevOps

在瀑布模型中，大家分工合作，开发、测试、部署、运维，每一部分都有专门的团队负责，开发完成后进入测试环节，测试完成后进去部署环节，部署完成后进入运维环节，每个环节都是独立的，有着独立的开发团队、测试团队、部署团队、运维团队。

瀑布模型的弱点在于，软件上线周期长，对于新需求的反映速度慢。因而，在瀑布模型的基础上，衍生出了敏捷开发，强调“开发测试”一起搞，小步快走完成开发任务，但仍然有独立的部署团队和运维团队。

DevOps是敏捷模型的进一步升级，为了进一步加快软件的上线速度，更快地对客户需求做出反应，强调“开发测试部署运维”全部一起搞定。

这也就是DevOps缩写的含义，也即Development and Operation, 开发和运维。

总结起来，采用DevOps这种方法论，主要就是想在软件开发过程中提升以下几点：

• 更专注于用户的需求
• 更快的上线速度
• 更自动化流程
• 更稳定的运行时长

为了实现这一目标，有着一些列辅助DevOps的工具和方法论，例如包括软件架构上的微服务设计Microservices、云原生的部署方案K8S、持续集成持续交付CICD等。

2.2 设计上的妥协与变通

通过上面的介绍可以了解到，实施DevOps，不仅仅要在软件开发理念上改变，也要在组织架构上发生改变，要打破开发测试部署运维的组织边界和职能边界，同时为了完成这一目标，软件的架构设计也会发生变动，即从之前的“单体架构monolithic architecture”转变成“微服务架构Microservices”。

云原生为什么要使用微服务架构，让我们首先对比下两种架构的优势与劣势。

对于传统的单体架构：

	优势	劣势
1	易开发（同一个代码库，更容易开发）	开发速度慢（大型的用程序使开发更复杂、更慢）
2	高性能（集中式的代码库和数据库，一个API通常可以执行许多API在微服务中执行的相同功能）	可扩展性差（不能扩展单个组件）
3	测试简单 （端到端测试可以比分布式应用程序更快地执行）	可靠性弱（任何模块出现错误，都可能影响整个应用程序的可用性）
4	易调试 （所有代码都放在一个地方，跟踪请求和发现问题容易）	新技术应用障碍（框架或语言的更改都会影响整个应用程序，使得更改通常既昂贵又耗时）
5		灵活性差（受到单体中已经使用的技术的限制）
6		部署代价大（一个小更改需要重新部署整个单体）

对于微服务架构：

	优势	劣势
1	敏捷的部署与扩展（弹性扩展、独立部署）	开发蔓延（微服务增加了更多的复杂性、更多冗余重复的API，如果管理不当，就会导致开发速度变慢，操作性能变差）
2	高可维护性和可测试性（易隔离和修复单个服务中的错误和错误）	指数级的基础设施成本（每个新的微服务在测试套件、部署脚本、托管基础设施、监控工具等方面都有自己的成本）
3	更灵活的技术（不同的服务可以通过不同的技术栈完成）	增加了管理成本（团队需要增加另一个层次的沟通和协作，以协调更新和接口）
4	高可靠性（可更改特定服务部署，而不会危及整个应用程序）	调试复杂（每个微服务都有自己的日志集，这使得调试变得更加复杂。另外，单个业务流程可以跨多台服务器运行，这进一步增加了调试的复杂性）
5		缺乏标准化（如果没有一个通用的平台，语言、日志标准和监控标准，管理会失控）

可见，微服务架构虽然灵活，但微服务也不是万灵丹，微服务架构带来系统敏捷性的同时，也有着很多的妥协和挑战。例如为了微服务间的解耦，可能需要创建更多冗余的服务或数据，这与之前软件设计中的do not repeat yourself是完全相反的思路，这种设计也为数据的最终一致性带来了不小挑战。

可以说，实施DevOps方法论和微服务架构目前也仍然是在不断试错、不断摸索的过程中。

有一点需要注意的是，使用微服务架构，构建云原生应用程序的初衷并非是“降低运营成本”，因为随着微服务数量的增加，其所消耗的基础设施成本也是指数级增长的。使用微服务架构的初衷是获得更高的敏捷性，获得更快的部署速度，更快的软件迭代周期。

2.3 DORA

DORA是DevOps Research & Assessment的缩写，它是研究如何评判DevOps运行状况的一个组织 DORA | DevOps Quick Check。总结下来，这个组织提出了5点衡量标准:

• （速度）Deployment Frequency: 部署的频率
• （速度）Lead time for changes: 从代码提交，到在生产系统上生效的时间
• （稳定性）Time to restore service: 部署之后，出了问题，需要多久能修复
• （稳定性）Change Failure Rate: 由于部署产生问题的百分比
• （运维角度）Reliability：服务是不是稳定的 ---> （这一条是新提出的）

这5点标准可以量化成具体的衡量指标，用于衡量一个实施DevOps方法论的组织的运行状况。例如下图给出的一个参考标准：

 总的来说，通过DORA提出的指标，我们可以从部署的速度和服务的稳定性两个角度，去量化软件开发团队运行的状况。

所以说，DORA的核心其实是提出了DevOps的“可量化的衡量指标” 。

3. 总结

本文简单总结和介绍了DevOps和DORA的基础概念，对于云原生开发的很多衍生工具和概念没有过多的介绍，包括例如Zero-Downtime Deployment，Zero-Downtime DB Migration，Resilience，Feature Toggles，Monitoring & Alerting， Product Metrics等等，这些概念的核心都是围绕着DevOps方法论的思想所服务的。

首先把握DevOps的初衷和Miscrosevices架构的特点，是学习其它相关概念的前提，希望本文对你了解DevOps有所帮助。