一文读懂云上DevOps能力体系

简介: 阿里云ECS自动化运维套件架构师,深度拆解云上运维能力体系建设:自动化运维等级金字塔、自动化运维的进阶模式、DevOps的基础核心、云上标准化部署三大能力……

序言

云计算行业已经有十多年的发展了,话题早已从“要不要上云”转向“如何用好云”。“要不要”其实是一个决策性的话题,直到决策出来一个结果了,话题就算结束了。而“如何用好云”却是一个持续性的话题。

一般来说,在规划阶段开始,企业就会开始思考“如何用好云”,这个话题会伴随用云的整个过程。如果简单地从工作类型划分,除了业务代码的研发(Dev),其他的部分都可以称为运维(Ops),包含资源创建(环境部署)、应用部署、资源管理、资源监控、报警、故障排查等工作。

笔者从事云计算工作超过五年时间,参与开发过多款云产品,可以说既是云计算产品的消费者,也是云计算产品的生产者。在这里,笔者谈一谈对云上DevOps能力体系的多年思考和总结,希望对准备上云或是已经上云的运维人员有所帮助。

1 自动化运维等级金字塔

从运维自动化等级和程度来看,DevOps其实是一种非常高级的自动化,不仅自动化程度比较高,而且对于自动化的完成方式有着非常严格的定义。关于运维自动化与DevOps的关系,其实可以非常好地参考汽车自动驾驶技术分级标准,笔者做了个对比图,如图1。
image.png
图1:自动化运维等级金字塔

如图1,自动化运维可分为5个等级,分别是手动运维、半手工/半自动化运维、高度自动化、标准化运维和AIOps,分别对应自动化驾驶的6个Level,其中运维自动化L2对应了自动驾驶的Level 1和2。为了方便说明和对比这5个自动化运维等级,请参考如下的表格。
image.png
表1:自动化驾驶等级与自动化运维等级对比参考

  • Level 1:手动运维。一些技术能力一般的企业,在上云初期运维工作主要是纯手动,只能依赖云服务商提供的控制台进行操作。
  • Level 2:半手工/半自动化运维,运维自动化工作比例还不超过30%。运维人员可以通过命令行(CLI)完成部分运维工作。
  • Level 3:高度自动化,运维自动化程度可达到50%。企业运维人员会使用云平台的SDK调用API进行日常运维工作,同时自行开发运维系统,但运维系统通常无定制化和平台能力,和内部系统紧耦合。
  • Level 4:标准化自动化,运维自动化程度超过90%。企业的运维系统已具备平台化、模版化和代码化的能力,可根据自身的运维需求定制化开发系统。与此同时,运维人员已具备使用具备模板化的产品来实现运维工作的标准化和自动化。
  • Level 5:AIOps,即智能运维,运维自动化程度达100%。不再需要值班人员,生产力完全解放。这是当前很多大型互联网企业的运维目标,也是头部企业重点投入的方向。

2 DevOps 是自动化运维的进阶模式

2.1 模板化是最DevOps的自动化方式

这里,笔者想着重谈一下Level 3-高度自动化运维与Level 4-标准化自动化运维的区别。大多数自研的运维系统是在Level3 类型,例如在内部运维系统上开发了一个功能,可以立即创建10台云服务器,下次需要创建其他资源时,如创建3个消息队列,还是需要额外再开发创建消息队列功能。所以,Level 3-高度自动化运维可以理解为是一个聚焦具体场景的单一“系统”。

而Level 4-标准化自动化运维更具备普遍性,完成了更高一级的抽象。当前,大多数的云平台都提供了自动化部署相关产品,如AWS CloudFormation、阿里云的资源编排工具ROS等,所以Level 4标准化自动化运维系统其实是一个平台型的产品。

使用Level 4阶段的产品创建资源只需要创建一个模板,当需要创建新资源时,只需要套用模板即可,无需额外开发。多提一句,这里说的模板通常是YAML或是JSON文件,最近业界又开始将这类YAML和JSON代码化,面对资源的代码方式,思路和模板还是一致的,对于DevOps先锋者建议可以关注下AWS CDK和Pulumi类的产品。
实现模板化后,即可以将模板的管理方式和代码一致,使用Git等版本控制软件管理起来,使得模板的修改和发布过程可以享受类似代码一样的福利——评审、构建和持续发布,这就是最DevOps的自动化方式。

2.2 模板化或代码化是AIOps基础

AIOps(智能运维)可能是我们所有人的目标,不过理想和现实的差距还是存在的。现阶段的AIOps 只在少数的特定场景下才有,比如弹性扩容场景下,可以对历史扩容数据进行学习后进行预扩容,或用AI的方式来检测某个指标是否异常等,所以AIOps还远没有达到完全自动化的程度。建议在特定场景里可进行AIOps的调研,在方向上对AIOps保持关注即可。

即便如此,笔者还是愿意表达自己的观点,模板化或代码化自动化运维(即Level 4),应该会是AIOps的基础,因为只有所有运维工作都可以被自动化、所有自动化工作都非常规范和标准时,AI才有机会进行学习,AIOps 才可能成为现实。

3 DevOps基础核心:CI/CD,基础设施即代码

通常,云上自动化运维系统的第一步是环境部署,这是基础同时非常重要的一步。一旦部署完成,后续想要再去修改代价会非常大。尤其是上线以后,会是一个环境迁移的工程量了,所以环境部署是最先需要开始设计的。

image.png
图2 :CI/CD流水线的系统运行环境

3.1 CI/CD 流水线的系统运行环境

以实际项目中运用DevOps模式的例子——CI/CD流水线应用“基础设施即代码”的实践为例,看一下自动化部署的整个流程。
image.png
图3:CI/CD流水线

通常流水线的源头是从Git开始的,所以也有人将这种模式称之为GitOps,显然这里的Git也可以替换成其他的版本控制系统,如SVN等,因为思路是一样的,所以本文依旧称之为DevOps。

相信大家对CI/CD流水线都很熟悉了,如图3,这里的流水线不仅包括了业务代码Repo,还包括了DevOps Repo,那么DevOps Repo应该用来存什么内容的呢?这里重点强调的是系统所依赖的运行环境的配置,这里的运行环境通常也叫“基础设施”,即包括了云服务器、网络、数据库、负载均衡和中间件等业务应用所依赖的系统环境,目录可参考图4。

image.png
图4:系统环境目录

在图4中,environment.yml是一个环境所需要的完整模板,modules里是各个资源模块,分别是云服务器、数据库、负载均衡和VPC网络,这里只包含了最最基本的云资源,对于有经验的DevOps工程师还可以增加更多的资源,如消息队列、kafka等中间件,NoSQL类型的数据库以及监控和报警规则。

环境的配置信息可以存储在流水线上,这样在部署时可以先部署环境、后部署业务。那部署环境时,可以根据实际情况选择创建一个新环境或是更新环境。一个环境配置通常包含以下信息:

  • 环境类型:如日常测试环境、预发环境和生产环境。
  • 环境地域:如杭州、北京和上海等。
  • 环境其他参数:如账号、AccessKey/Token和角色等。
  • 资源相关配置:如服务器数量、域名等。

3.2 云上标准化部署三大能力

云上环境与传统数据中心的环境最大的区别是,云上的一切服务是以API为核心,资源的创建、修改和删除等所有操作都可以通过API来完成,因此云上部署是天然的规范化,从而提高了云上的部署效率,即实现了高效而统一的标准化部署。其中,典型的需重复部署的场景有以下四类:

  • 环境部署,如日常测试环境、预发环境和生产环境,只需要构建一个部署,即可以通过新增stage的方式达到重复部署。通常由日常环境开始,然后重复到预发和生产环境。
  • 多地域部署,如先部署在杭州、后需部署到北京和上海等其他地域,可以快速地重复部署。一般只需要在流水线上新增一个新地域stage,添加配置参数即可实现一键部署。
  • 集群部署,如先部署了几个集群,再重复部署多个集群,同样也可以快速地重复部署。可以通过在流水线上新增一个新集群stage,添加配置参数即可实现一键部署。
  • 容灾环境部署,如先部署了一个主要的生产环境,后需要部署一个容灾环境时,采取集群部署的同样方式来实现。

通常,云上高效而标准化部署具备三大能力——消除环境差异、环境的快速复制能力和环境的重建能力。
消除环境差异,实现环境一致性。环境的微小差异即可带来业务上非常大的差异,而且排查起来非常困难,比起代码的Debug要费时费力许多,毕竟大部分的代码逻辑可以在本地复现和Debug,但是环境造成的差异则非常繁琐,需要进行非常细致的排查才能找到问题的症结所在。而云上标准化部署能够消除环境差异,实现环境的一致性,大大地简化了运维工作。

一键部署,快速复制能力。从日常环境到生产环境,从A地域到B地域,从单集群到多个集群,无一不需要高效的复制能力,而环境的复制能力是其中的第一步,且是最为关键的一步。标准化部署能将原来的数天工作量缩短为几个小时,甚至一键部署的能力,可以说极大地提升了运维效率。

重建的能力。很多环境问题是问题历史悠久造成的,各种不规范、不标准的操作日积月累最终导致环境混乱。因此,对于日常测试环境来说,定期地推倒重建是非常有必要的,理由类似自动化测试,越干净的环境越能验证、复现和Debug业务问题。因此,当一个测试环境有问题时,应该可以做到随时释放并能够一键重建。

所以,如果在项目规划阶段就考虑到自动化部署能力,那么后续的部署无疑会平滑许多。然而,对于已经存在的项目是否也可以使用这个模式呢?答案是肯定的,这要求对应的服务有能力将已有的云资源转化成部署模板的能力,然后再根据修改这个模板以便可以重复使用。

4 完整DevOps体系应具备哪些能力?

如果说,100% 自动化是DevOps理想中的形态,那么任何环节的缺失都可能成为实践DevOps的障碍。通常,按照运维工作的流程来看,DevOps 往往会包括八个环节:计划、编码、构建、测试、发布、运维、监控,然后重新回到计划,开始新一轮迭代。
image.png
图5:DevOps流程图

值得重点强调的是,利用上述部署模板的方式,也是可以包括监控、报警等设置。因为一切皆是云产品、一切云产品都提供API缘故,因此才成就了部署模板是可以做到统一集中的。

笔者所在的阿里云,DevOps体系不仅环境部署实现了模板化,连运维编排也可以模板化的,即自动化运维(阿里云提供运维编排工具OOS),业界也把这种模式叫做Ops as Code、Automation as Code或是Runbook as Code了。因为产品的设计原则和思想和部署模板一致,所以不再赘述其详细步骤。

作为云计算产品的生产者,笔者同时也从一个云资源的全生命周期梳理了一个DevOps的闭环,如图5。这张图笔者在今年2020云栖大会的分享中也做了阐述,熟悉北京的朋友喜欢用“四环图”来称呼它。

image.png
图6:云资源生命周期四环图

一环:最核心的云资源,有服务器类资源,虚拟机服务器和裸金属,也可以包括容器实例。
二环:云服务器的生命周期的六个阶段:创建、镜像、补丁升级、诊断修复、监控和运维和实例配置。
三环:云服务器全生命周期的六个阶段,可以利用不同的工具可以提升效率。如实例的监控和运维,除了有云厂商提供的监控产品外,还有很多第三方的监控产品。运维方面,建议使用自动化运维类产品,如运维编排OOS,可以把最常用的运维任务模板化,从而提供运维的规范性,减少因为人肉执行的失误,避免让运维背锅。
最近,我们已经将三环的这一整套“ECS自动化运维套件”正式对外发布,帮助企业实现从IT架构的规划、迁移、部署、弹性扩缩容,到日常管理全生命周期的自动化运维。利用这套工具,每一家云上的企业都可以低成本构建属于自己的自动化运维体系。

image.png
(关于自动化运维套件的系统化介绍,欢迎大家下载《阿里云ECS自动化运维套件白皮书》:https://developer.aliyun.com/topic/download?id=1112

四环:除了使用云平台工具之外,还可以利用第三方的工具,如Terraform、Ansible等。另外,很多工具都不约而同地选择了模版的方式, 如YAML、JSON、Hashicorp自定义的HCL等。基于模板,可以构建一个生态,方便外部的参与者共同贡献内容,不仅丰富了DevOps的世界,最终达到了更高的DevOps效率。

图6不仅包含了阿里云的DevOps工具,也包括了业界较为流行的运维工具,它们的设计思想都是类似的,因此在工具的采用上可以根据实际需要分别采用。一般来说,如果使用的是单一云平台的云资源时,使用云平台一方的产品有着最一致的体验,集成度也最高,成本也是相对最少的。

这里,笔者还想简单提一下容器DevOps和云服务器DevOps的区别。当前,K8S已经是容器编排(管控)领域的事实标准了,几乎所有的云服务商也都实现了各类托管K8S产品,甚至局部的Serverless K8S。

很多云服务器的使用者对于K8S是心向往之,却又因为各种原因需要继续使用云服务器。笔者曾经这样评价过K8S,“K8S本身并不是什么技术上的重大创新,更多的是把DevOps里面的很多最佳实践产品化了”——这一说法也得到了部分容器专家的认同。

image.png

5 DevOps落地的阻碍:如何和财务流程实现平衡

事实上,DevOps并不是一个新鲜的概念,但是真正做到DevOps的企业少之又少,背后的原因是多种多样的。以笔者多年的经验看来,其中最大的两个因素:一个是财务,二是运维开发人员的习惯。
财务人员是典型的计划式模式,需先预估、再采购,这里最大的挑战在于没人能够精准地预测明天的事情,所以最终的结果要么是预估多了,要么就是预估少了,预估多了下一次的预估必定要收紧,预估少了再放松,然后循环重复这个过程。

财务上的限制对于DevOps的发展有时是致命的,这种“计划式”的模式直接影响到了云上资源的创建和释放模式,财务上喜欢“包年包月”,因为看起来比较划算,而DevOps运维开发人员则偏向于“按需分配,弹性伸缩”。

所以,笔者最后想呼吁各位财务专家多考虑下,给予技术架构上在预算上一定的灵活性,可以非常有效地帮助并促进业务高速发展。

作者:吴君印

原文链接

本文为阿里云原创内容,未经允许不得转载

 

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

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

mcem r语言代码_R语言阈值自回归模型(TAR)代码示例

原文链接:R语言时间序列TAR阈值模型分析​tecdat.cn阈值模型用于统计的几个不同区域,而不仅仅是时间序列。一般的想法是,当变量的值超过某个阈值时,过程可能表现不同。也就是说,当值大于阈值时,可以应用不同…

【洛谷算法题】P4414-[COCI2006-2007#2] ABC【入门2分支结构】Java题解

👨‍💻博客主页:花无缺 欢迎 点赞👍 收藏⭐ 留言📝 加关注✅! 本文由 花无缺 原创 收录于专栏 【洛谷算法题】 文章目录 【洛谷算法题】P4414-[COCI2006-2007#2] ABC【入门2分支结构】Java题解🌏题目描述&a…

EDAS微服务应用同城容灾最佳实践

简介: 大多数业务应用只要做到同城双活,就可以避免掉大多数数据中心不可用故障。本实践就是帮助大家高效、低成本地实现自己的业务应用具备同城双活容灾能力。 前言 上云目前已经是绝大数企业首选的IT基础设施建设方案,但是云上仍然存在一些…

脸书推出VR视频会议应用程序 正式跨出元宇宙第一步;三家公司新入选福布斯2021云计算百强榜;微软挖来亚马逊云业务顶级高管贝尔...

NEWS本周新闻回顾微软挖来亚马逊云业务顶级高管贝尔微软公司已经聘请亚马逊云业务高管查理贝尔担任其企业副总裁。鉴于微软的Azure 云业务正试图从亚马逊 AWS 手中争夺份额,这一挖角行动可以说是微软的一次胜利。在亚马逊前 AWS 主管安迪贾西被任命为亚马逊 CEO 后&…

三字经带拼音a4打印版_人教版八年级下册英语6单元重点单词带音标打印版

UNIT 6shoot [ʃu:t] v. 投篮,射击,发射stone [stəʊn] n. 石头weak [wi:k] adj. 虚弱的,柔弱的god [ɡɒd] n. 上帝,神remind [rɪmaɪnd] v. 提醒,使想起bit [bɪt] n. 一点,小块a little bit 有点儿&am…

拥抱云原生,Fluid结合JindoFS :阿里云OSS加速利器

简介: Fluid 是一个开源的 Kubernetes 原生的分布式数据集编排和加速引擎,主要服务于云原生场景下的数据密集型应用。在 Fluid 上使用和部署 JindoRuntime 实现数据集的可见性、弹性伸缩、数据迁移、计算加速等,并流程简单、兼容原生 k8s 环境…

【观点】传统企业如何在数字化时代实现进化?

简介: 我们看到的数字化的大多数场景集中于日常商业消费活动,背后其实是超越个体行为的场景变革。 究竟是谁在承载这个时代一步步走进数字化场景?又是谁通过数字化技术与解决方案帮助他们实现场景变革?这个过程是什么样的&#xf…

网易数帆发布轻舟低代码平台2.0,聚焦中等复杂度企业级应用

编辑 | 宋 慧 出品 | CSDN云计算 头图 | 轻舟低代码平台2.0发布会现场 8月26日,网易数帆正式发布轻舟低代码应用开发平台2.0版本(以下简称“轻舟低代码平台”),以全新的可视化编程语言为特色,针对中等复杂度的企业级应…

宝塔 开启_宝塔面板安装完的一些列操作

前言新安装的宝塔会有很多地方需要配置,如果懂的大佬可以跳过,如果是小白可以按照辉哥的教程一步步操作,辉哥是以虚拟机进行操作的,但是服务器也是一样的道理!安全入口因为现在使用宝塔面板的人数在激增。所以为了避免…

黑灰产攻击洪峰来袭,企业如何守住自己的钱袋子?

简介: 风控大考最佳实践 根据阿里云历史行业风险治理相关数据显示,未经风险管控的自然流量中,约三分之一比例属于疑似黑灰产的高风险行为;而在建立合理的风控指标监控体系并采取风险防控手段后,高风险用户比例下降至3%…

服务网格的最佳实践

简介: 服务网格是用于处理服务间通信的专用基础设施层。它负责通过包含现代云原生应用程序的复杂服务拓扑来可靠地传递请求。 微服务发展的这几年,新的技术和概念层出不穷,这些技术的引入本质上都是在围绕服务稳定性和业务开发效率提升&#…

高性能开发,别点,发际线要紧!

作者:轩辕之风O来源:编程技术宇宙-前言-程序员经常要面临的一个问题就是:如何提高程序性能?这篇文章,我们循序渐进,从内存、磁盘I/O、网络I/O、CPU、缓存、架构、算法等多层次递进,串联起高性能…

如何打造一个高性能的前端智能推理引擎

简介: 什么是前端智能推理引擎又该如何打造和应用呢? 什么是前端智能推理引擎 在前端智能推理引擎之前,我们先来说一下什么是”端智能”。 端智能(On-Device Machine Learning)是指把机器学习的应用放在端侧做。这里…

115配额怎么增加_笔电、平板接口少怎么办,ORICO八合一多功能扩展坞助你一臂之力...

现在笔记本电脑大多都往轻薄的外形上发展,保持性能的前提下可以增加移动的便捷性,但是弊端同样明显,那就是牺牲掉了一部分常用接口。比如我手上这部戴尔XPS,左右两侧加起来只有4个可怜的接口,其中还包括一个SD槽&#…

OpenYurt:延伸原生 Kubernetes 到边缘场景下的落地实践

简介: 随着云原生技术的逐步成熟,阿里云容器服务团队在具体落地实践过程中不断探索云原生技术的应用边界。同时随着物联网和 5G 的迅猛发展,传统的边缘计算架构已经不能满足业务发展的需要。 如何基于云原生技术构建新一代的边缘计算平台成为…

对象存储,为什么那么火?

作者|小枣君 来源|鲜枣课堂引言上期文章(链接:关于存储技术的最强入门科普),小枣君给大家详细介绍了数据存储技术的基本知识,其中重点对DAS、SAN和NAS技术进行了对比分析。我们知道,在很长的一段时间里&…

使用react实现select_React笔记——核心概念:9.表单

1、受控组件在 React 中,可变状态(mutable state)通常保存在组件的 state 属性中,并且只能通过使用 setState()来更新。state:唯一数据源渲染表单的 React 组件还控制着用户输入过程中表单发生的操作。被 React 以这种方式控制取值的表单输入…

压测场景下的 TIME_WAIT 处理

简介: 压测场景下的 TIME_WAIT 处理 1. 序 某专有云项目具备压测场景,在Windows的压测机上用 LoadRunner 进行业务的压力测试,压测运行一段时间后出现大量端口无法分配的报错。 其实通过问题描述,以及 Windows的报错信息基本确定…

DataX在数据迁移中的应用

简介: DataX在数据迁移中的应用 1. DataX定义 首先简单介绍下datax是什么。 DataX是阿里巴巴集团内被广泛使用的离线数据同步工具/平台,实现包括 MySQL、Oracle、SqlServer、Postgre、HDFS、Hive、ADS、HBase、TableStore(OTS)、MaxCompute(ODPS)、DRDS…

华为发布《绿色5G白皮书》,定义绿色5G网络八大技术方向

全球“碳达峰、碳中和”已成主流趋势,为了助力全球运营商绿色网络“双碳”行动计划的达成,在华为首届无线媒体沙龙上,华为无线网络SRAN产品线总裁马洪波发表了“绿色5G,E2四化八大方向,共赢双碳未来”主题演讲&#xf…