首页>>互联网>>DevOps->devops怎么读(2023年最新整理)

devops怎么读(2023年最新整理)

时间:2023-12-02 本站 点击:0

导读:很多朋友问到关于devops怎么读的相关问题,本文首席CTO笔记就来为大家做个详细解答,供大家参考,希望对大家有所帮助!一起来看看吧!

怎么理解devops

在软件开发的过程中,开发人员负责编写代码,然后将代码交给 QA(质量保障)团队进行测试,然后将最终的发布版交给运维团队去布署。

DevOps 就是 Development(开发)和 Operations(运维)两个词的组合。但这里的组合并不是简单地将两个团队合并,而是要从思维和流程上变革,根据 DevOps 思想重新梳理全流程的规范和标准。

DevOps 既是一种思维方式,同时也是一种工作方式,作为一套促进开发、技术运营和质量保障三个部门之间的沟通、协作与整合的方法论,使得组织的快速迭代,实现竞争优势成为现实。

在 DevOps 的流程下,运维人员会在项目开发期间就介入到开发过程中,了解开发人员使用的系统架构和技术路线,从而制定适当的运维方案。而开发人员也会在运维的初期参与到系统部署中,并提供系统部署的优化建议。

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年开始逐步推出的一个理念。关于历史的部分就讲到这里,大家感兴趣的可以再做进一步的了解。

智能运维是什么?

得益于IT外包服务的发达,现在的运维已经不包括搬机器上架、接网线、安装操作系统等基础工作,运维人员一般会从一台已安装好指定版本的操作系统、分配好IP地址和账号的服务器入手,工作范围大致包括:服务器管理(操作系统层面,比如重启、下线)、软件包管理、代码上下线、日志管理和分析、监控(区分系统、业务)和告警、流量管理(分发、转移、降级、限流等),以及一些日常的优化、故障排查等。

随着业务的发展、服务器规模的扩大,才及云化(公有云和混合云)、虚拟化的逐步落实,运维工作就扩展到了容量管理、弹性(自动化)扩缩容、安全管理,以及(引入各种容器、开源框架带来的复杂度提高而导致的)故障分析和定位等范围。

听上去每一类工作都不简单。不过,好在这些领域都有成熟的解决方案、开源软件和系统,运维工作的重点就是如何应用好这些工具来解决问题。

传统的运维工作经过不断发展(服务器规模的不断扩大),大致经历了人工、工具和自动化、平台化和智能运维(AIOps)几个阶段。这里的AIOps不是指Artificial Intelligence for IT Operations,而是指Algorithmic IT Operations(基于Gartner的定义标准)。

基于算法的IT运维,能利用数据和算法提高运维的自动化程度和效率,比如将其用于告警收敛和合并、Root分析、关联分析、容量评估、自动扩缩容等运维工作中。

在Monitoring(监控)、Service Desk(服务台)、Automation(自动化)之上,利用大数据和机器学习持续优化,用机器智能扩展人类的能力极限,这就是智能运维的实质含义。

智能运维具体的落地方式,各团队也都在摸索中,较早见效的是在异常检测、故障分析和定位(有赖于业务系统标准化的推进)等方面的应用。智能运维平台逻辑架构如图所示。

智能运维平台逻辑架构图

智能运维决不是一个跳跃发展的过程,而是一个长期演进的系统,其根基还是运维自动化、监控、数据收集、分析和处理等具体的工程。人们很容易忽略智能运维在工程上的投入,认为只要有算法就可以了,其实工程能力和算法能力在这里同样重要。

智能运维需要解决的问题有:海量数据存储、分析、处理,多维度,多数据源,信息过载,复杂业务模型下的故障定位。这些难题是否会随着智能运维的深入应用而得到一定程度的解决呢?我们会在下一篇文章中逐步展开这些问题,并提供一些解决方案。

本文选自《智能运维:从0搭建大规模分布式AIOps系统》,作者彭冬、朱伟、刘俊等,电子工业出版社2018年7月出版。

本书结合大企业的智能运维实践,全面完整地介绍智能运维的技术体系,让读者更加了解运维技术的现状和发展。同时,帮助运维工程师在一定程度上了解机器学习的常见算法模型,以及如何将它们应用到运维工作中。

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 是通过使用正确的方法,工具等将理论部分扩展为有效的工作流程。这还涉及在每个人之间分担责任,并使每个人都具有相同的目标和愿景。

不明白 DevOps 到底是什么意思

在业务敏捷化的需求背景下,传统的单体式架构及项目制瀑布开发模式已经无法满足业务快速开发交付及变更的需求。从企业IT部门的视角,为了更快速响应业务变化,实现应用的快速开发交付及迭代,敏捷开发(Agile)风靡一时,Scrum作为敏捷方法论被认为是全球最流行与最有效的敏捷项目管理理念与方法之一;

而以敏捷开发为基础的DevOps(Development和Operations),则进一步整合了开发测试和运维团队,通过组织、文化和工具,以及自动化“软件交付”和“架构变更”的流程,使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

DevOps可以有效提升软件交付效能,在实现更频繁更快速应用发布的同时,可以有效减少发布变更导致的故障及停机时间。

根据DORA公司与Google Cloud合作发布的《2018年DevOps现状报告》,实施DevOps的高效能团队在代码发布频率、代码提交至发布的速度、变更的故障率、事故恢复时间上的表现远远优于低效能团队:

代码发布频率高 46 倍

代码提交至发布的速度快 2555 倍

变更故障率少 7 倍

事故恢复时间快 2604 倍

而在所有参与调查的企业当中,在实施DevOps的同时采用PaaS、云原生、容器技术的企业有更高的概率是高效能精英团队。IT团队的敏捷化转型,为业务团队更快速响应市场变化提供了能力支撑。在企业数字化浪潮下,能否比竞争对手更快的发现和响应市场变化,是保持企业竞争力的重要因素。

完整阅读:Nebulogy纳比云原创文章《BizDevOps推动企业数字化转型与高速增长》

DevOps的概念是什么?

是软件开发人员和IT运维人员之间的合作过程,是一种工作环境、文化和实践的集合,目标是高效地自动执行软件交付和基础架构更改流程。开发和运维人员通过持续不断的沟通和协作,可以以一种标准化和自动化的方式快速、频繁且可靠地交付应用。想要了解更多,我推荐你去看看时速云,他们是一家全栈云原生技术服务提供商,提供云原生应用及数据平台产品,其中涵盖容器云PaaS、DevOps、微服务治理、服务网格、API网关等。大家可以去体验一下。

希望能给您提供帮助,可以给个大大的赞不。

结语:以上就是首席CTO笔记为大家整理的关于devops怎么读的全部内容了,感谢您花时间阅读本站内容,希望对您有所帮助,更多关于devops怎么读的相关内容别忘了在本站进行查找喔。


本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。
如若转载,请注明出处:/DevOps/7877.html