




版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领
文档简介
1、 企业IT自动化运维实践分析目 录 TOC o 1-3 h z u HYPERLINK l _Toc522786788 1.前言 PAGEREF _Toc522786788 h 3 HYPERLINK l _Toc522786789 2.自动化运维的定义 PAGEREF _Toc522786789 h 3 HYPERLINK l _Toc522786790 3.自动化运维落地的实践基础 PAGEREF _Toc522786790 h 5 HYPERLINK l _Toc522786791 4.自动化运维和流程管控 PAGEREF _Toc522786791 h 7 HYPERLINK l _T
2、oc522786792 5.自动化运维常用的工具分析 PAGEREF _Toc522786792 h 9 HYPERLINK l _Toc522786793 6.基于云平台的自动化运维 PAGEREF _Toc522786793 h 11 HYPERLINK l _Toc522786794 7.总结 PAGEREF _Toc522786794 h 13前言本文介绍自动化运维这个话题。当你把自动化运维这个话题抛给不同的角色,他们的反应也一定是不一样的,程序员眼中的自动化运维可能是可以自助申请资源,可以点点点的进行应用发布;应用运维人员眼中的自动化运维可能是自动的监控每个应用的状态有简单的问题就按
3、照约定的动作去自愈,复杂的问题通知给我,我去处理或者是过期的日志清理等;基础资源运维人员眼中的自动化运维可能是硬件服务的自助系统安装,自动的环境初始化,垃圾文件清理等。这些理解都没有错,但是这些都是一个一个的点,没有形成一个整体,没有从方法论的角度去理解自动化运维,去建设自动化运维,本文就来谈一谈自动化运维是什么,以及如何实现企业自动化运维。自动化运维的定义对于不同的人眼中的自动化运维意味着什么,这些理解站在点的角度上或者说站在非领导的角度上理解都是没有问题的,但是如果作为一个运维方面的领导理解仅仅理解到以上层面那就有点欠缺了,在我看来至少是缺乏了更为抽象的理解,缺少了理论的支持。我们先抛开这
4、个缺少的理论不说,在运维领域,有人会说,运维经历了人肉化,脚本化,自动运维工具以及平台化几个阶段(图一),这个说法有错吗?也没有。但是细心地你会发现,这里提到的演化过程还是一个纵向的演化过程,说白了是通过技术的更新来推动运维的前进,而且这样的演化过程很容易让人陷入技术实现的细节,不能跳出来从宏观的角度分析自动化运维到底该做什么?不该做什么?边界在哪里?图一接下来我就说下我理解的自动化运维的方法论或者说抽象的理论应该是什么,大家仔细回想开篇提到的场景,无论是开发想要的资源自助申请,自动发布,还是运维项要的自动装机、自助初始化环境以及故障的自愈等,还是我们从立项开始通过需求分析,详细设计,编码,测
5、试,运维,运营,反馈等,这些我们都是在干嘛?对了,我们都是在做端到端的交付!接下来再想,it系统建设是干嘛的,是为业务服务的,也就是说业务系统实现了业务功能就能带来收益,大家才有饭吃,那么问题就简单了,最简单的场景是系统架构设计好了以后所有的工作都围绕业务实现来投入,其他的非功能性需求(这里没有说非功能性需求不需要)投入的人力越少越好!到此,自动化运维理论的内涵和外延都有了,那就是:对于非业务的功能性需求,在提供端到端交付的过程中能够尽量的全自动化(图二)。图二最近很火的service mesh在微服务领域就有点这个意思,今天我们不是主要讲service mesh,这里先不展开。自动化运维落地
6、的实践基础我们在第一个章节里交待清楚了什么自动化运维理论的内核和外延,下面开始接地气的谈一谈要想落地自动化运维理论,需要有什么样的基础或者说如何才能更好的落地自动化运维理论。笔者曾工作于国内某一线互联网公司,同时也是传统行业工作过,切身体会到抛开技术架构和人员能力不谈,一线互联网公司的自动化运维比传统行业好的不是一个量级,笔者对整个问题进行过思考,得到的结论是:一线互联网公司对端到端交付的自动化运维理念落实的很到位,而促使他们很好落实端到端交付的自动化运维理论的主要抓手有三个:一是对既定规范的绝对遵守;二是所有资源的抽象化;三是各种标准化(图三)。图三下面分别介绍一下这三点:一是对既定规范的绝
7、对遵守,在一线互联网公司,运维团队在接手开发的系统时,会有一个准入的等级要求,这个要求是对开发提的,例如你要满足我的哪些要求,我才会给你提供相应的运维保障,这里的要求有业务系统重要性等级说明、业务系统运行时间说明、业务系统不能依赖低等级的业务系统、业务系统不能有单点故障等,因为在运维团队看来,你只有符合我不同的要求,对我而言对你实现端到端的自动化运维保障难度也是不同的。例如,一个非常重要的业务系统,可是开发有很多单点故障问题都没有解决,很多健康检查监控都没有实现,那么我运维不可能破坏游戏规则,单独为你一个系统做特殊高等级的保障,来耗费我的人力资源,甚至后续的背锅风险。绝大多数情况下,开发都会按
8、照既定规范来遵守游戏规则,对于非要玩特殊化的,那也很简单,两边老大pk。有了规范,对于运维团队而言只需要针对固定数量的保障等级准备相应的自动化运维手段就可以,而避免的过多的个性化需求。二是资源的抽象化,一线互联网公司很多物理资源都是抽象化表示的(编码化),例如机房名字、不同硬件配置的服务器。这样的好处一方面便于记忆,另一方面统一了术语大家在交流的时候不容易出错,最重要的是抽象表示后很对运维场景也变的简单的。这里的抽象对于很多传统行业的同学可能不太理解,我在这里举几个例子,例如一个在上海的联通机房,他的命名可能是cnshu01,简单解释下,cnsh代表中国上海,u代表是联通,01代表编号;再举一
9、个例子,我们在传统行业购置硬件服务器的时候,可能是每次根据需求不同选好硬件配置后再选品牌,在互联网公司一般会首先对服务器的用途进行分类,例如计算密集型,内存密集型,io密集型等,针对每种会有一个编码,例如C42代表计算密集型,这样的好处是需要使用机器的部门只需要将自己需要机器的编码和数量发给采购部门就行了,别的就不用关心了。资源编码化还有一个好处是当需要用程序来管理资源的时候,编码化最容易处理。三是各种标准化,每个公司都会面临一个软件版本管理的问题,从操作系统版本到软件版本参差不齐,不同的软件版本在运维时还是有一些差别的,在一线互联网公司对于软件的版本一般会有比较严格的一致性要求,尤其是生产环
10、境,过一段时间的软件版本升级工作其实也促使了自动化运维的发展,试想如果没有高效的自动化运维保障,每升级一次操作系统或者软件版本都是一项巨大的工程,恰恰是这样相互促进的关系,当整个公司都使用统一的操作系统版本和软件版本时,很多工作的难度就降低了。另外,一线互联网公司还对操作系统的目录结构(主要是指linux操作系统)有着标准化的要求,目录结构标准化的好处是无论谁来处理问题,都能根据标准化的路径到达目的地,找到自己所需的内容。综上所述,既定规范的绝对遵守、资源的抽象化和标准化,是落地端到端自动化运维交付的有力抓手。自动化运维和流程管控这一部分,我们来聊下自动化运维与流程管控的关系。我们知道,运维工
11、作中的任何一个需求的执行都是有相应的流程在进行管控的。如果自动化运维的动作没有流程来进行管理,那么自动化做了哪些运维工作,为什么要做这些运维工作,是谁做了这些运维工作,对于管理员来说如果都不知道或者不可查,那就太恐怖了。ITIL的规范里面也对流程管控有很详细的描述,但是根据笔者了解到的情况,在实际企业中,尤其是业务变化比较快的企业能够完全按照ITIL流程来的还真是少只又少,ITIL流程还是比较重的,针对ITIL流程做裁剪来适合企业自身情况这才是正确的方式。在流程管控方面,传统行业无论是用了ITIL还是没有用的,目前都存在以下几个问题:一是流程不完善,即流程还是欠缺的不能完全覆盖所有场景;二是流
12、程完善了,但是没有全部系统化;三是流程完善了,系统化也有了但是流程没有串起来,还都是一些孤立的点。以上三种场景都很难对流程做出较强的管控,好的流程管控,应该这样做:第一步结合工作的实际情况梳理出我们需要做流程的场景,这一步可以首先让每位同事把自己认为需要做流程管控的场景梳理出来,作为总的一个需求池,然后通过开会讨论的方式将需求进行合并或者是去重,经过这样一个过程,产出物是一个需要做流程管控的文档;第二步针对第一步梳理出来的文档,标注出每一个流程中最关键的点,这个点称之为要素点。例如新购机器上架这个流程里,包括送达机房,签收,上架前准备,上架并加电,更新已上架设备信息等几步,在这个流程中,上架并
13、加电是最核心也是对后续实际使用最有影响的一步,那么这一步就成为要素点;第三步就是针对第一步梳理出的流程,找到流程之间的衔接点,这也是为了解决流程孤岛的问题。在这一步中如果发现有不能连接在一起而断层的流程,就需要在这一步解决。第四步就是系统实现了,这一步无论是自研实现还是外包实现,都需要考虑的一点是如何与现有的自动化运维系统以及资源管理系统进行对接,因为流程的管控过程肯定会涉及资源的生命周期管理,这里的资源可以是实实在在的物理资源,例如服务器、防火墙、路由器和交换机等,也可以是软件资源,例如安全策略,4/7层的负载均衡等,这样的流程管控平台就涉及到与cmdb、云平台和容器平台等的对接工作,这一步
14、一般是比较消耗精力的,倒不是说这里的技术难度有多难,而是这里一般都涉及接口的调试工作,如果这些系统都是自研的系统,那对接起来的难度可能还低些,毕竟都是自己公司的团队,如果涉及到与外购系统的对接,这里的时间周期就很难控制了,根据笔者经验,这里如果是与外购系统对接,每个系统最好预留1个月的时间。第五步就是流程管控平台上线后的与自动化运维平台磨合和优化的阶段了。在这个阶段,要留意观察自动化运维平台、资源平台与流程管控平台的数据交互是否正常,这里可以引入敏捷迭代的方式来及时处理问题(图四)。图四自动化运维常用的工具分析各位看官,在这个阶段我主要介绍下实现自动化运维工具的三种理念,为了严谨期间说明下这个
15、环节说的自动化运维工具是要是指x86服务器层面。实现自动化运维工具的三种理念:第一种是完全自研,例如阿里巴巴集团的所有物理机上都安装有一个久经考验并且功能强大的代理staragent,阿里巴巴集团所有物理机在系统初始化的时候就安装了这个staragent,直到生命周期结束,这个startagent才会被卸载。这里有个问题就是,不是所有的公司都能像阿里巴巴一样自研一个功能非常强大的agent,因此就有了第二种和第三种理念。第二种理念是使用市面上已有的自动化运维工具,并基于这些工具做成自动化运维平台。目前市面上常见的自动化运维工具主要有以下几种,Puppet、Chef、Ansible和Salt,下
16、面对四种产品做一个对比介绍:Puppet应该是市面上使用最多的,就操作、模块、界面而言,它是最全面的,Puppet呈现了数据中心协调的全貌,为各大操作系统提供了深入的工具,初始设置简单,只是需要加以管理的每个系统上安装客户端代理软件,CLI简单直观,允许通过puppet命令下载和安装模块,你可以对配置文件进行需要的修改,让模块适合所需的任务,接到指令的客户端与主服务器联系时,会更改配置文件,也可以是客户端主动与服务端通信来获取到最新的配置文件,还有一些模块可以提供和配置云服务器实例和虚拟服务器实例,所有模块和配置都使用基于Ruby的Puppet专属语言或者Ruby本身构建而成,因而除了系统管理
17、技能外,还需要编程专业知识。Chef的总体概念类似Puppet,因为在被管理的节点上安装代理软件,但实际部署又不一样。除了主服务器外,安装的Chef环境还需要工作站来控制主服务器。代理软件可以借助使用SSH来部署的knife工具从工作站加以安装,减轻了安装负担。被管理的节点通过使用证书,完成与主服务器之间的验证。与Puppet一样,Chef得益于一大批的模块和配置菜谱,那些模块和配置菜谱又高度依赖Ruby。由于这个原因,Chef非常适合注重开发的基础设施。Ansible极其类似Salt,而不太类似Puppet或Chef,Ansible关注的重点是力求精简和快速,而且不需要在节点上安装代理软件也
18、可以选择安装。Ansible能通过SSH执行所有功能,Ansible基于Python开发对于熟悉python的人而言是一大福音,并且是由红帽进行运营。Ansible可以从命令行来运行,不需要使用配置文件。至于比较复杂的任务,Ansible配置通过名为Playbook的配置文件中的YAML语法来加以处理。Playbook还可以使用模板来扩展其功能,目前playbook的模板还是非常丰富的。Salt类似Ansible,因为它也是基于CLI的工具,采用了推送方法实现客户端通信。它可以通过Git或通过程序包管理系统安装到主服务器和客户端上,客户端会向主服务器提出请求,请求在主服务器上得到接受后,就可以
19、控制该客户端了。这四款自动化运维工具网上的比较很多,但是很难说谁就一定比谁好很多,还是那句话,你的团队具有哪方面的人才就使用哪个,如果非要选出一个我个人推荐ansible,因为基于python实现,开发人员比较好找,同时社区资源活跃,相关的资源和组件也是比较丰富的。第三种思路是采购市面上商用的自动化运维平台,这种思路对于很多甲方公司还是很现实的一种方案。对于这种思路,需要采购方切实梳理清楚自身的需求,整理出自己真实需要的自动化运维场景。这里的建议是,在选择商用自动化运维平台时和平台销售方协商好以下三件事,一是甲方结合实际工作中遇到的自动化运维场景,把需要马上满足的自动化运维场景梳理出来,作为第
20、一个模块,即确定要完成的功能模块;二是要求平台销售方提供自动化运维工具的编写接口,并支持shell和python两种语言,这个要求是考虑到后续有些运维场景开始没有考虑到,或者新增了一些场景,自己的人员可以自行通过编写脚本在这个平台上实现;三是要求平台销售方对于产品层面积累的已有的运维场景实现要提供给采购方,并且支持后续当产品有新运维场景更新时,要免费提供给采购方使用。基于云平台的自动化运维目前云平台还是比较热的一个话题,最后这个章节主要来聊下私有云iaas和paas平台的自动化运维该是什么样的。先说iaas平台,iaas平台主要涉及计算、存储、网络、安全这四大块(图五)。图五计算资源应该是分为
21、几种固定的规格(计算密集型/io密集型/内存密集型),这些规格由开发和运维团队协商定制。没有特殊情况下,无论是谁申请都不会新增新的机型,同时计算资源无论是开发人员自助申请,还是开发人员通过运维人员申请,申请完以后系统的初始化环境应该是已经自动完成的,这里的初始化环境包括并不限于IP地址、内核参数、文件目录结构、计算机名称、磁盘卷挂载等。存储资源,要能够做到容量预警和扩容提醒,当触发容量预警需要扩容时能够通知到存储管理员,同时存储管理员提出扩容需求和方案后可以通过流程平台通知到存储采购人员,并进行采购动作。在存储资源的服务能力方面,最佳情况是同时具备块、文件和对象存储能力,这样才能满足云环境下的应用需求,尤其是对象存储现在越发受到重视,笔者举一个小例子,由于经过前面的标准化要求,每台云主机的文件目录结构都是统一的,那么当应用程序需要进行文件操作的时候,使用基于S3协议的对象存储就很方便,免去了通过nfs或者smba进行盘挂载的方式,使用nfs或者smba进行挂载的方式会额外增加运维人员的维护成本,并且差异化也是与自动化运维的标准化理念相违背的。实际情况是,笔者
温馨提示
- 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
- 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
- 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
- 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
- 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
- 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
- 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
最新文档
- 20 金字塔 金字塔夕照(教学设计)2023-2024学年统编版语文五年级下册
- Unit 4 Speaking教学设计 -2024-2025学年沪教版(五四制)英语六年级上册
- 2025合同终止证明书欢迎访问中国青岛自贸区
- 2025聘请技术顾问合同-劳动合同模板资料文档
- 七年级历史上册 第三单元 秦汉时期:统一多民族国家的建立和巩固第10课 秦末农民大起义教学设计 新人教版
- 2025商业房产买卖合同模板
- 2025年网站广告投放合同
- 新疆农业职业技术学院《合唱与指挥(4)》2023-2024学年第二学期期末试卷
- 西南财经大学天府学院《数字文化创意与传播》2023-2024学年第一学期期末试卷
- 新疆铁道职业技术学院《大数据采集与清洗》2023-2024学年第二学期期末试卷
- 《课程与教学论》形考二答案
- 公积金提取单身声明
- 磷酸铁锂生产配方及工艺
- 高处作业吊篮进场验收表
- 电工电子技术及应用全套课件
- DB33T 1233-2021 基坑工程地下连续墙技术规程
- 8.生发项目ppt课件(66页PPT)
- 《新农技推广法解读》ppt课件
- 车载式轮椅升降装置的结构设计-毕业设计说明书
- 社区家庭病床护理记录文本汇总
- 剑桥BEC中级真题第四辑TEST1
评论
0/150
提交评论