什么是DevOps? 什么是DORA?

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方法论的组织的运行状况。例如下图给出的一个参考标准:

什么是DevOps? 什么是DORA?_第1张图片

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

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

3. 总结

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

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

你可能感兴趣的:(IT项目与团队,运维,DORA)