智能运维适合哪些场景?都涉及那些领域?

智能运维适合哪些场景?都涉及那些领域?,第1张

IT的智能运维AIOps,目前在国内落地比较多的是对IT故障容忍率更低的行业,比如金融、交通、互联网等等。各厂商主要的差异在于数据治理的能力和经验(当数据量越来越大时,一个好的运维数据中台可以保证运行性能)、产品线的覆盖度(告警、日志、指标等均可进行智能分析)、智能场景的丰富度。

对于智能运维来说,常见的智能场景有异常检测、根因定位、自动排障、容量预测、告警收敛、日志聚类等。随着应用的进一步广泛,智能场景也会不断更新、越来越多。

可以说智能运维的发展完全是顺应时代的需求,互联网逐渐与衣食住行变得息息相关,由生活衍生出来的金融、交通、通讯、能源等行业企业同互联网一起经历了多样化的变迁升级。因此,与互联网伴生而来的是对生产数据的运维管理,经历了手工、自动化的阶段后,在人工智能的推动下,运维逐渐向智能化(AIOps)进化。

运维自动化是我们所渴望获得的,但是我们在一味强调自动化能力时,却忽略了影响自动化落地的一个关键因素。那便是跟运维朝夕相处,让人又爱又恨的业务架构

要点一:架构独立

任何架构的产生都是为了满足特定的业务诉求,如果我们在满足业务要求的同时,能够兼顾运维对架构管理的非功能性要求。那么我们有理由认为这样的架构是对运维友好的。

站在运维的角度,所诉求的架构独立包含四个方面:独立部署,独立测试,组件化和技术解耦。

独立部署

指的是一份源代码,可以按照便于运维的管理要求去部署、升级、伸缩等,可通过配置来区分地域分布。服务间相互调用通过接口请求实现,部署独立性也是运维独立性的前提。

独立测试

运维能够通过一些便捷的测试用例或者工具,验证该业务架构或服务的可用性。具备该能力的业务架构或服务让运维具备了独立上线的能力,而不需要每次发布或变更都需要开发或测试人员的参与。

组件规范

指的是在同一个公司内对相关的技术能有很好的框架支持,从而避免不同的开发团队使用不同的技术栈或者组件,造成公司内部的技术架构失控。

这种做法能够限制运维对象的无序增加,让运维对生产环境始终保持着掌控。同时也能够让运维保持更多的精力投入,来围绕着标准组件做更多的效率与质量的建设工作。

技术解耦

指的是降低服务和服务之间相互依赖的关系,也包含了降低代码对配置文件的依赖。这也是实现微服务的基础,实现独立部署、独立测试、组件化的基础。

要点二:部署友好

DevOps 中有大量的篇幅讲述持续交付的技术实践,希望从端到端打通开发、测试、运维的所有技术环节,以实现快速部署和交付价值的目标。可见,部署是运维日常工作很重要的组成部分,是属于计划内的工作,重复度高,必须提升效率。

实现高效可靠的部署能力,要做好全局规划,以保证部署以及运营阶段的全方位运维掌控。有五个纬度的内容是与部署友好相关的:

CMDB配置

在每次部署 *** 作前,运维需要清晰的掌握该应用与架构、与业务的关系,为了更好的全局理解和评估工作量和潜在风险。

在织云自动化运维平台中,我们习惯于将业务关系、集群管理、运营状态、重要级别、架构层等配置信息作为运维的管理对象纳管于CMDB配置管理数据库中。这种管理办法的好处很明显,集中存储运维对象的配置信息,对日后涉及的运维 *** 作、监控和告警等自动化能力建设,将提供大量的配置数据支撑和决策辅助的功效。

环境配置

在运维标准化程度不高的企业中,阻碍部署交付效率的原罪之一便是环境配置,这也是容器化技术主要希望解决的运维痛点之一。

腾讯的运维实践中,对开发、测试、生产三大主要环境的标准化管理,通过枚举纳管与环境相关的资源集合与运维 *** 作,结合自动初始化工具以实现标准环境管理的落地。

依赖管理

解决应用软件对库、运营环境等依赖关系的管理。在织云实践经验中,我们利用包管理,将依赖的库文件或环境的配置,通过整体打包和前后置执行脚本的方案,解决应用软件在不同环境部署的难题。业界还有更轻量的容器化交付方法,也是不错的选择。

部署方式

持续交付原则提到要打造可靠可重复的交付流水线,对应用软件的部署 *** 作,我们也强烈按此目标来规划。业界有很多案例可以参考,如Docker的Build、Ship、Run,如织云的通过配置描述、标准化流程的一键部署等等。

发布自测

发布自测包含两部分:

应用的轻量级测试;

发布/变更内容的校对。

建设这两种能力以应对不同的运维场景需求,如在增量发布时,使用发布内容的校对能力,运维人员可快速的获取变更文件md5,或对相关的进程和端口的配置信息进行检查比对,确保每次发布变更的可靠。

同理,轻量级测试则是满足发布时对服务可用性检测的需求,此步骤可以检测服务的连通性,也可以跑些主干的测试用例。

灰度上线

在《日常运维三十六计》中有这么一句话:对不可逆的删除或修改 *** 作,尽量延迟或慢速执行。这便是灰度的思想,无论是从用户、时间、服务器等纬度的灰度上线,都是希望尽量降低上线 *** 作的风险,业务架构支持灰度发布的能力,让应用部署过程的风险降低,对运维更友好。

要点三:可运维性

运维脑海中最理想的微服务架构,首当其冲的肯定是可运维性强的那类。不具可运维性的应用或架构,对运维团队带来的不仅仅是黑锅,还有对他们职业发展的深深的伤害,因为维护一个没有可运维性的架构,简直就是在浪费运维人员的生命。

可运维性按 *** 作规范和管理规范可以被归纳为以下七点:

配置管理

在微服务架构管理中,我们提议将应用的二进制文件与配置分离管理,以便于实现独立部署的目的。

被分离出来的应用配置,有三种管理办法:

文件模式;

配置项模式;

分布式配置中心模式。

限于篇幅不就以上三种方式的优劣展开讨论。不同的企业可选用最适用的配置管理办法,关键是要求各业务使用一致的方案,运维便可以有针对性的建设工具和系统来做好配置管理。

版本管理

DevOps持续交付八大原则之一“把所有的东西都纳入版本控制”。就运维对象而言,想要管理好它,就必须能够清晰的描述它。

和源代码管理的要求类似,运维也需要对日常 *** 作的对象,如包、配置、脚本等都进行脚本化管理,以备在运维系统在完成自动化 *** 作时,能够准确无误的选定被 *** 作的对象和版本。

标准 *** 作

运维日常有大量重复度高的工作需要被执行,从精益思想的视角看,这里存在极大的浪费:学习成本、无价值 *** 作、重复建设的脚本/工具、人肉执行的风险等等。

倘若能在企业内形成统一的运维 *** 作规范,如文件传输、远程执行、应用启动停止等等 *** 作都被规范化、集中化、一键化的 *** 作,运维的效率和质量将得以极大的提升。

进程管理

包括应用安装路径、目录结构、规范进程名、规范端口号、启停方式、监控方案等等,被收纳在进程管理的范畴。做好进程管理的全局规划,能够极大的提升自动化运维程度,减少计划外任务的发生。

空间管理

做好磁盘空间使用的管理,是为了保证业务数据的有序存放,也是降低计划外任务发生的有效手段。

要求提前做好的规划:备份策略、存储方案、容量预警、清理策略等,辅以行之有效的工具,让这些任务不再困扰运维。

日志管理

日志规范的推行和贯彻需要研发密切配合,在实践中得出的经验,运维理想中的日志规范要包含这些要求:

业务数据与日志分离

日志与业务逻辑解耦

日志格式统一

返回码及注释清晰

可获取业务指标(请求量/成功率/延时)

定义关键事件

输出级别

管理方案(存放时长、压缩备份等)

当具体上述条件的日志规范得以落地,开发、运维和业务都能相应的获得较好的监控分析能力。

集中管控

运维的工作先天就容易被切割成不同的部分,发布变更、监控分析、故障处理、项目支持、多云管理等等,我们诉求一站式的运维管理平台,使得所有的工作信息能够衔接起来和传承经验,杜绝因为信息孤岛或人工传递信息而造成的运营风险,提升整体运维管控的效率和质量。

要点四:容错容灾

在腾讯技术运营(运维)的四大职责:质量、效率、成本、安全。质量是首要保障的阵地,转换成架构的视角,运维眼中理想的高可用架构架构设计应该包含以下几点:

负载均衡

无论是软件或硬件的负责均衡的方案,从运维的角度出发,我们总希望业务架构是无状态的,路由寻址是智能化的,集群容错是自动实现的。

在腾讯多年的路由软件实践中,软件的负载均衡方案被广泛应用,为业务架构实现高可用立下汗马功劳。

可调度性

在移动互联网盛行的年代,可调度性是容灾容错的一项极其重要的运维手段。在业务遭遇无法立刻解决的故障时,将用户或服务调离异常区域,是海量运营实践中屡试不爽的技巧,也是腾讯QQ和微信保障平台业务质量的核心运维能力之一。

结合域名、VIP、接入网关等技术,让架构支持调度的能力,丰富运维管理手段,有能力更从容的应对各种故障场景。

异地多活

异地多活是数据高可用的诉求,是可调度性的前提。针对不同的业务场景,技术实现的手段不限。

腾讯社交的实践可以参考周小军老师的文章“2亿QQ用户大调度背后的架构设计和高效运营”。

主从切换

在数据库的高可用方案中,主从切换是最常见的容灾容错方案。通过在业务逻辑中实现读写分离,再结合智能路由选择实现无人职守的主从切换自动化,无疑是架构设计对DBA最好的馈赠。

柔性可用

“先扛住再优化”是腾讯海量运营思想之一,也为我们在做业务架构的高可用设计点明了方向。

如何在业务量突增的情况下,最大程度的保障业务可用?是做架构规划和设计时不可回避的问题。巧妙的设置柔性开关,或者在架构中内置自动拒绝超额请求的逻辑,能够在关键时刻保证后端服务不雪崩,确保业务架构的高可用。

要点五:质量监控

保障和提高业务质量是运维努力追逐的目标,而监控能力是我们实现目标的重要技术手段。运维希望架构为质量监控提供便利和数据支持,要求实现以下几点:

指标度量

每个架构都必须能被指标度量,同时,我们希望的是最好只有唯一的指标度量。对于业务日趋完善的立体化监控,监控指标的数量随之会成倍增长。因此,架构的指标度量,我们希望的是最好只有唯一的指标度量。

基础监控

指的是网络、专线、主机、系统等低层次的指标能力,这类监控点大多属于非侵入式,很容易实现数据的采集。

在自动化运维能力健全的企业,基础监控产生的告警数据绝大部分会被收敛掉。同时,这部分监控数据将为高层次的业务监控提供数据支撑和决策依据,或者被包装成更贴近上层应用场景的业务监控数据使用,如容量、多维指标等。

组件监控

腾讯习惯把开发框架、路由服务、中间件等都统称为组件,这类监控介于基础监控和业务监控之间,运维常寄希望于在组件中内嵌监控逻辑,通过组件的推广,让组件监控的覆盖度提高,获取数据的成本属中等。如利用路由组件的监控,运维可以获得每个路由服务的请求量、延时等状态和质量指标。

业务监控

业务监控的实现方法分主动和被动的监控,即可侵入式实现,又能以旁路的方式达到目的。这类监控方案要求开发的配合,与编码和架构相关。

通常业务监控的指标都能归纳为请求量、成功率、延时3种指标。实现手段很多,有日志监控、流数据监控、波测等等,业务监控属于高层次的监控,往往能直接反馈业务问题,但倘若要深入分析出问题的根源,就必须结合必要的运维监控管理规范,如返回码定义、日志协议等。需要业务架构在设计时,前置考虑运维监控管理的诉求,全局规划好的范畴。

全链路监控

基础、组件、业务的监控手段更多的是聚焦于点的监控,在分布式架构的业务场景中,要做好监控,我们必须要考虑到服务请求链路的监控。

基于唯一的交易ID或RPC的调用关系,通过技术手段还原调用关系链,再通过模型或事件触发监控告警,来反馈服务链路的状态和质量。该监控手段属于监控的高阶应用,同样需要业务架构规划时做好前置规划和代码埋点。。

质量考核

任何监控能力的推进,质量的优化,都需要有管理的闭环,考核是一个不错的手段,从监控覆盖率、指标全面性、事件管理机制到报表考核打分,运维和开发可以携手打造一个持续反馈的质量管理闭环,让业务架构能够不断进化提升。

要点六:性能成本

在腾讯,所有的技术运营人员都肩负着一个重要的职能,就是要确保业务运营成本的合理。为此,我们必须对应用吞吐性能、业务容量规划和运营成本都要有相应的管理办法。

吞吐性能

DevOps持续交付方法论中,在测试阶段进行的非功能需求测试,其中很重要一点便是对架构吞吐性能的压测,并以此确保应用上线后业务容量的健康。

在腾讯的实践中,不仅限于测试阶段会做性能压测,我们会结合路由组件的功能,对业务模块、业务SET进行真实请求的压测,以此建立业务容量模型的基准。也从侧面提供数据论证该业务架构的吞吐性能是否达到成本考核的要求,利用不同业务间性能数据的对比,来推动架构性能的不断提高。

容量规划

英文capacity一词可以翻译成:应用性能、服务容量、业务总请求量,运维的容量规划是指在应用性能达标的前提下,基于业务总请求量的合理的服务容量规划。

运营成本

减少运营成本,是为公司减少现金流的投入,对企业的价值丝毫不弱于质量与效率的提升。

腾讯以社交、UGC、云计算、游戏、视频等富媒体业务为主,每年消耗在带宽、设备等运营成本的金额十分巨大。运维想要优化运营成本,常常会涉及到产品功能和业务架构的优化。因此,运维理想的业务架构设计需要有足够的成本意识,

小结

本文纯属个人以运维视角整理的对微服务架构设计的一些愚见,要实现运维价值最大化,要确保业务质量、效率、成本的全面提高,业务架构这块硬骨头是不得不啃的。

运维人需要有架构意识,能站在不同角度对业务架构提出建议或需求,这也是DevOps 精神所提倡的,开发和运维联手,持续优化出最好的业务架构。

2020年IT运维市场前景分析

2019年10月29日,第一财经刊发了关于《工信部:加强5G、人工智能、工业互联网、物联网等新型基础设施建设》一文,其中指出,推动新型IT基础设施建设。加强5G、人工智能、工业互联网、物联网等新型IT基础设施建设,扩大高速率、大容量、低延时网络覆盖范围,鼓励企业通过内网改造升级实现人、机、物互联,为企业提供有力的信息网络支撑,让企业IT基础设施成为企业发展之路上的护航者。由此可以看出,国家对企业IT基础设施建设的重视之深,而我们IT运维人员将是这次IT基础设施建设的主力军。

IT运维是企业项目开发后保证业务系统正常运行的必备工作之一,如何满足企业对在线业务系统高可靠、低延时、大容量、零故障等要求或在终端用户无感知情况下处理运维过程中存在的各种各样的突发性问题,是IT运维人员必会的技能,但是如此优秀的IT运维人员几乎一将难求。

既然,IT运维人员对于国家相关部门大力支持的IT基础设施建议那么重要,那么我们IT运维人员都需要拥有哪些能力或IT运维工作内容有哪些呢?

1、IT基础设施运维自动化

由于企业要求IT基础设施能够做到高可靠、低延时、大容量、零故障等,那就需要IT运维人员对底层硬件设备进行用心维护,硬件不出故障才能保证上层业务系统的稳定、高效地运行。

2、IT基础设施之上在线业务系统上线

企业在线业务系统是企业对内或对外提供服务的重要途径,IT运维人员在业务系统开发后,能够准确及时上线业务系统是对其业务能力的重要考核标准之一。

3、IT基础设施及在线业务系统监控自动化

对企业IT基础设施及在线业务系统进行有效监控,能够IT运维人员及时获知硬件或业务系统状态,以此判断硬件或业务系统有效服务能力,对硬件或业务系统故障做到即时反馈,即时处理,不影响企业对内或对外提供服务。

4、IT基础设施及在线业务系统日志处理自动化

对企业IT基础设施及IT在线业务系统进行日志处理(收集、分析、监控、趋势图展示等),获知硬件使用或业务系统中用户行为,以此预测下一周期内硬件或业务系统资源可用情况,及时应对用户访问波峰。

5、在线业务系统发布自动化

使用业界先进工具实现在线业务系统代码发布自动化,打破传统IT运维 "领域隔离",实现真正的一键式发布业务系统,加快系统部署速度,实现用户无感知升级或回滚 *** 作等。

6、IT基础设施平台升级

传统的企业IT基础设施平台对企业在线业务系统需要底层硬件平台的高响应、高可靠、大容量等能力反应不及时或不彻底的情况时有发生,这就需要我们IT运维人员能够对传统的企业IT基础设施平台进行升级,把传统的企业IT基础设施平台升级为云平台,由云平台的高响应、高速度、低延时、大容量等能力为业务系统稳定运维保驾护航。

7、在线业务系统迁移至云平台

传统的企业IT基础设施平台升级为云平台后,需要IT运维人员能够把运行在传统的企业IT基础设施平台之上的业务系统迁移至云平台。

8、云平台运行维护(升级)

云平台运行过程中,需要IT运维人才时刻进行监控、对于云平台突发情况进行处理。

9、IT运维自动化系统开发

由于企业IT基础设施运维过程中,涉及多业务、多场景、多平台等,IT运维人员在运维过程中亟需一套本企业的IT运维管理系统,但是由于每家企业的IT基础设施异样性,导致市场上无法采购标准化系统进行应用,大多数情况下由本企业IT运维人员根据企业自身情况进行开发。

10、业务系统海量数据分析及展示

企业在运营过程中产生大量的业务类数据,并且此类数据对于生产、运营等有利于决策,因此IT运维人员需要对企业内部或行业内的数据进行收集、分析、展示等,最终为企业运营提供决策参考依据。

以上为我们为罗列的IT运维人员能力要求或工作内容,下面我们再来了解一下2020年IT运维市场规模,2020年有越来越多的企业开始拥抱互联网,借助互联网开展“无接触”式业务,特别是在2020年初“新冠”疫情的影响下,公司为了生存开启了全员在线办公及业务全天侯在线处理等,这也就为企业打开了企业在线常态化;让更多的工作借助互联网完成,据权威机构公布称:"这一切将产生约100万相关技术开发岗位及约10万IT运维岗位,至2024年,IT运维行业市场容量将呈现出逐年增长态势,到2024年IT运维管理行业市场规模将达到3832.8亿元。"

2020年IT运维行业技术展望

企业对于IT运维人员要求越来越“T型”化,其中包含更深层次的专业化,自动化以及智能化,因此在2020年全球大多数的企业都在以行业标杆(例如:谷歌、亚马逊、阿里等)为榜样,着力发展企业自身的如下方向:

1、云计算

云服务器是由云服务厂商提供的性能卓越、稳定可靠、d性扩展的IaaS(Infrastructure as a Service)级别云计算服务。云服务器免去了采购IT硬件的前期准备,让企业像使用水、电、天然气等公共资源一样便捷、高效地使用服务器,实现计算资源的即开即用和d性伸缩。

2、DevOps

DevOps使企业项目开发者与企业项目开发后IT运维人员、测试人员、产品经理、客户等直接发生了连接关系,让项目各方能够进行更好地结合,把以住只关注自身业务转移到整个交付过程,甚至关注到最终服务上,DevOps已经成熟,其在2020年将成为每一位IT运维人员必备技能之一。

3、AIOps

IT运维内容没有变,但是IT运维方式在发生改变,AIOps将为我们IT运维人员“解放”双手,让我们可以花费更少的时间在IT基础设施及IT业务系统监控、日志、安全等工作上,把业务重心投放到企业IT基础设施及IT业务系统发展、运营、服务决策上。

4、SaaS

SaaS(Software-as-a-Service)是企业提供应用、开发、IT运维等全套服务的一种形式,由于其不再需要用户有任何IT基础设施的投入,可以大大降低企业IT成本,获得更优质的服务。

5、边缘计算

随着5G技术大面积应用,更多的边缘设备需要对接到云平台,并享受近十年云计算行业发展的红利,但是如果生硬地把物联网设备与云计算平台对接,将会为云计算平台带来非常大的数据量的同时,也会影响到物联网边缘设备的数据处理能力,因此我们可以考虑把云计算技术向边缘设备进行延伸,这就是我们所说的边缘计算,IT运维人员将主导边缘计算的成云能力。

6、Serverless

ServerLess,为一种无服务模式,目的让企业不再关注IT基础设施,由IT运维人员提供IT基础设施后,多企业可以共享同一IT基础设施平台,企业可以摊销更多IT基础设施成本。

2020年黑马程序员IT运维工程师学习路线图

1、Linux *** 作系统基本功

Linux系统安装、配置,基本命令,VIM编辑器,Linux自有服务,权限管理,YUM包管理,开源项目上线部署。

2、Linux系统服务

网络基础(重点难点TCP/UDP)、sshd服务(scp/rsync)、文件共享服务(ftp/nfs/samba)、DNS域名服务、LAMP编译安装、rsyslog、Linux分区+LVM逻辑卷+(软硬RAID)

3、Shell、MySQL

Shell脚本编程、MySQL从入门到精通(DBA方向)

4、商城系统上线部署

Nginx概述、LNMP环境搭建、MySQL读写分离、LB负载均衡(Nginx/LVS/HAProxy)、NoSQL(Memcached、Redis、MongoDB)、存储、企业级商城系统架构实战。

5、配置自动化

配置自动化(Ansible/SaltStack)、监控(Zabbix/Promethus)、日志分析(ELK、KafKa)、CI/CD(Git、GitLab、Jenkins)

6、运维安全与调优

运维安全(防火墙、CA认证、VPN)

应用软件调优(Web应用调优)

系统调优(系统+内核)

7、运维云计算

Hadoop、KVM虚拟化、公有云运维(阿里云)、私有云运维(OpenStack)、Docker容器、Kubernetes(K8S)容器编排工具

8、Python运维开发方向

Python运维基础、Python面向对象、Django框架、Python CMDB项目开发

附件为2020版黑马程序员Linux云计算+运维开发学习路线图:


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/sjk/6777910.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-03-28
下一篇 2023-03-28

发表评论

登录后才能评论

评论列表(0条)

保存