导读：本篇文章首席CTO笔记来给大家介绍有关devops怎么读语音的相关内容，希望对大家有所帮助，一起来看看吧。
DevOps的概念和历史
当你看敏捷的时候，不经意间出现了DevOps这个词，你还在好奇，这是什么的时候，发现规模化敏捷也出现了，这个时候如果你还发现自己对这个词很陌生，那说明你的知识该补齐了，毕竟他们如果总是频繁出现，说明他们的相关性很高。
其实不只是敏捷，在CMMI、ITIL都在提到DevOps，说明我们真的很有必要对它进行一个系统性的了解了。
1.CMMI中提到关于Devops
图 CMMI
2.ITIL中提到关于DevOps
各类管理体系其实都在走向融合，而且都需要DevOps的支持，所以你还觉得自己不需要认真了解下它么？
如果你想快速的系统性的了解DevOps，可以先阅读以下几本书：
《凤凰项目》
《持续交付》
《独角兽项目》
《凤凰项目 一个IT运维的传奇故事》
《DevOps精要》
如果你报考了DevOps Master认证，那你《EXIN DevOps Master WhitePaper》是必读的。
DevOps是对敏捷软件开发与精益生产思想的演进，应用于IT端到端的价值链中，使得业务基于现代信息技术，并通过文化，组织与技术变革来获得更大的成功。
这是《DevOps精要》中关于DevOps定义，定义都有其严谨性，所以往往看完定义让我们摸不着头脑。DevOps其实是英文单词Development(Dev)和Operations(Ops)的组合，为什么要把这两个词组合到一起，最初创造这个词的人目的就是期望开发和运维能够紧密的合作，随后逐步的被扩展和衍生，下面这个“DevOps能力环”是对这种打破部门墙，进行顺畅交付的一个非常经典的一个表达。它强调了IT专业人员（研发，运维，测试）在应用和服务生命周期中的协作和沟通；强调整个组织合作以及交付和基础设施变更的自动化，从而实现持续集成、持续部署和持续交付。
[图片上传失败...(image-c93581-1650555848432)]
DevOps能力环
我们为什么要了解其历史，如果我们只是想用DevOps的一些工程实践，大可不必，但是如果你的团队还对这个概念很陌生，他们不知道为什么要用DevOps，如果是这样的话，我们还是有必要花几分钟来了解下它。
DevOps起源于敏捷，是在2008年敏捷论坛上被提出的，所以现在很多人会认为DevOps是敏捷的一部分，对于到底是谁属于谁，谁包含谁，这些观念大家不必纠结，各大体系都认为自己包括别人。敏捷认为它包括DevOps，而DevOps认为自己是它的衍生。
DevOps的概念在2010年的《What is DevOps》这篇文章中得到了较为完整的描述。DevOps在2013年之后被业界快速接受，源于相关技术的同步发展，2013年，dotCloud公司推出Docker项目，同年，Google推出开源项目Kubernetes，提供了以容器为中心的不部署、伸缩和运维平台，2015年云原生的概念也逐步成熟，他们的发展助推了DevOps的快速发展。
大家可能还听说过DevSecOps，Sec是不是安全，你猜的没错，就是安全和合规性，这是在2016年开始逐步推出的一个理念。关于历史的部分就讲到这里，大家感兴趣的可以再做进一步的了解。
SRE和DevOps
DevOps 和 SRE 似乎是同一枚硬币的两个面。他们都旨在弥合开发团队和运维团队之间的鸿沟，都想要提高软件部署的效率和软件运行的可靠性。
DevOps 的定义是“一种软件工程文化和实践，旨在统一开发和运维” 。这个术语最初是由 Andrew Shafer 和 Patrick Debois 于2008年创造的，虽然花了几年时间才成为一个通用概念，但如今，几乎每个企业都在使用 DevOps。
Site Reliability Engineer(SRE) 的概念自2003年以来一直存在，比 DevOps 还要古老。它是由创建 Google 的本·特雷诺（Ben Treynor）创造的。根据 Treynor 所说，SRE 是“软件开发工程师开始承担运维人员的任务”。
DevOps 和 SRE 都倡导自动化和监视，其目标都是减少从开发到部署生产中的时间，同时又不影响代码或产品的质量。Google 指出，SRE 和 DevOps 彼此之间并没有太大区别：“在软件开发和运维方面，他们不是竞争关系，而是旨在打破组织障碍，使得更快地交付更好的软件的亲密朋友。”
DevOps 只是关心需要做什么，但 SRE 却谈到了如何可以做到。SRE 是通过使用正确的方法，工具等将理论部分扩展为有效的工作流程。这还涉及在每个人之间分担责任，并使每个人都具有相同的目标和愿景。
听到很多IT专业的人再说DevOps，什么是DevOps啊？
DevOps=Developers+Operators，即开发团队和运维团队一体化，有了 DevOps ，团队可以定期发布代码、自动化部署、并将持续集成 / 持续交付作为发布过程的一部分。
DevOps 的概念对于使大型应用程序在不同负载或流量下保持高性能是非常有益的，它使软件部署管道易于管理。但如果没有可用的工具，DevOps 概念就很难实现。这个领域有很多工具，比如Terraform、Artifactory、Packer、Docker、Kubernetes等等，像JFrog的Artifactory，就是能够支持所有不同开发语言的二进制制品管理仓库。
不明白 DevOps 到底是什么意思
在业务敏捷化的需求背景下，传统的单体式架构及项目制瀑布开发模式已经无法满足业务快速开发交付及变更的需求。从企业IT部门的视角，为了更快速响应业务变化，实现应用的快速开发交付及迭代，敏捷开发（Agile）风靡一时，Scrum作为敏捷方法论被认为是全球最流行与最有效的敏捷项目管理理念与方法之一；
而以敏捷开发为基础的DevOps（Development和Operations），则进一步整合了开发测试和运维团队，通过组织、文化和工具，以及自动化“软件交付”和“架构变更”的流程，使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
DevOps可以有效提升软件交付效能，在实现更频繁更快速应用发布的同时，可以有效减少发布变更导致的故障及停机时间。
根据DORA公司与Google Cloud合作发布的《2018年DevOps现状报告》，实施DevOps的高效能团队在代码发布频率、代码提交至发布的速度、变更的故障率、事故恢复时间上的表现远远优于低效能团队：
代码发布频率高 46 倍
代码提交至发布的速度快 2555 倍
变更故障率少 7 倍
事故恢复时间快 2604 倍
而在所有参与调查的企业当中，在实施DevOps的同时采用PaaS、云原生、容器技术的企业有更高的概率是高效能精英团队。IT团队的敏捷化转型，为业务团队更快速响应市场变化提供了能力支撑。在企业数字化浪潮下，能否比竞争对手更快的发现和响应市场变化，是保持企业竞争力的重要因素。
完整阅读：Nebulogy纳比云原创文章《BizDevOps推动企业数字化转型与高速增长》
结语：以上就是首席CTO笔记为大家介绍的关于devops怎么读语音的全部内容了，希望对大家有所帮助，如果你还想了解更多这方面的信息，记得收藏关注本站。