加入收藏 | 设为首页 | 会员中心 | 我要投稿 源码网 (https://www.900php.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 服务器 > 搭建环境 > Windows > 正文

自动化运维落实到位的三点基础及常用工具对比

发布时间:2019-03-13 17:34:41 所属栏目:Windows 来源:王洋
导读:副标题#e# 当你把自动化运维这个话题抛给不同的角色,他们的反应也一定是不一样的,程序员眼中的自动化运维可能是可以自助申请资源,可以点点点的进行应用发布;应用运维人员眼中的自动化运维可能是自动的监控每个应用的状态有简单的问题就按照约定的动作去
副标题[/!--empirenews.page--]

当你把自动化运维这个话题抛给不同的角色,他们的反应也一定是不一样的,程序员眼中的自动化运维可能是可以自助申请资源,可以点点点的进行应用发布;应用运维人员眼中的自动化运维可能是自动的监控每个应用的状态有简单的问题就按照约定的动作去自愈,,复杂的问题通知给我,我去处理或者是过期的日志清理等;基础资源运维人员眼中的自动化运维可能是硬件服务的自助系统安装,自动的环境初始化,垃圾文件清理等。

这些理解都没有错,但是这些都是一个一个的点,没有形成一个整体,没有从方法论的角度去理解自动化运维,去建设自动化运维,那么今天我们就来谈一谈我眼中的自动化运维是什么?

一、自动化运维是什么?你是不是有什么误解?

开篇的时候说了对于不同的人眼中的自动化运维意味着什么,这些理解站在点的角度上或者说站在非领导的角度上理解都是没有问题的,但是如果作为一个运维方面的领导理解仅仅理解到以上层面那就有点欠缺了,在我看来至少是缺乏了更为抽象的理解,缺少了理论的支持。

我们先抛开这个缺少的理论不说,在运维领域,有人会说,运维经历了人肉化,脚本化,自动运维工具以及平台化几个阶段(图一),这个说法有错吗?也没有。但是细心地你会发现,这里提到的演化过程还是一个纵向的演化过程,说白了是通过技术的更新来推动运维的前进,而且这样的演化过程很容易让人陷入技术实现的细节,不能跳出来从宏观的角度分析自动化运维到底该做什么?不该做什么?边界在哪里?

自动化运维落实到位的三点基础及常用工具对比

图一

接下来我就说下我理解的自动化运维的方法论或者说抽象的理论应该是什么,大家仔细回想开篇提到的场景,无论是开发想要的资源自助申请,自动发布,还是运维项要的自动装机、自助初始化环境以及故障的自愈等,还是我们从立项开始通过需求分析,详细设计,编码,测试,运维,运营,反馈等,这些我们都是在干嘛?对了,我们都是在做端到端的交付!

接下来再想,it系统建设是干嘛的,是为业务服务的,也就是说业务系统实现了业务功能就能带来收益,大家才有饭吃,那么问题就简单了,最简单的场景是系统架构设计好了以后所有的工作都围绕业务实现来投入,其他的非功能性需求(这里没有说非功能性需求不需要)投入的人力越少越好!

到此,自动化运维理论的内涵和外延都有了,那就是:对于非业务的功能性需求,在提供端到端交付的过程中能够尽量的全自动化(图二)。

自动化运维落实到位的三点基础及常用工具对比

图二

最近很火的service mesh在微服务领域就有点这个意思,今天我们不是主要讲service mesh,这里先不展开。

二、自动化运维落地的实践基础

我们在第一个章节里交待清楚了什么自动化运维理论的内核和外延,下面开始接地气的谈一谈要想落地自动化运维理论,需要有什么样的基础或者说如何才能更好的落地自动化运维理论。

笔者曾工作于国内某一线互联网公司,同时也是传统行业工作过,切身体会到抛开技术架构和人员能力不谈,一线互联网公司的自动化运维比传统行业好的不是一个量级,笔者对整个问题进行过思考,得到的结论是:一线互联网公司对端到端交付的自动化运维理念落实的很到位,而促使他们很好落实端到端交付的自动化运维理论的主要抓手有三个:一是对既定规范的绝对遵守;二是所有资源的抽象化;三是各种标准化(图三)。

图三

下面分别介绍一下这三点:

一是对既定规范的绝对遵守,在一线互联网公司,运维团队在接手开发的系统时,会有一个准入的等级要求,这个要求是对开发提的,例如你要满足我的哪些要求,我才会给你提供相应的运维保障,这里的要求有业务系统重要性等级说明、业务系统运行时间说明、业务系统不能依赖低等级的业务系统、业务系统不能有单点故障等,因为在运维团队看来,你只有符合我不同的要求,对我而言对你实现端到端的自动化运维保障难度也是不同的。例如,一个非常重要的业务系统,可是开发有很多单点故障问题都没有解决,很多健康检查监控都没有实现,那么我运维不可能破坏游戏规则,单独为你一个系统做特殊高等级的保障,来耗费我的人力资源,甚至后续的背锅风险。绝大多数情况下,开发都会按照既定规范来遵守游戏规则,对于非要玩特殊化的,那也很简单,两边老大pk。有了规范,对于运维团队而言只需要针对固定数量的保障等级准备相应的自动化运维手段就可以,而避免的过多的个性化需求。

二是资源的抽象化,一线互联网公司很多物理资源都是抽象化表示的(编码化),例如机房名字、不同硬件配置的服务器。这样的好处一方面便于记忆,另一方面统一了术语大家在交流的时候不容易出错,最重要的是抽象表示后很对运维场景也变的简单的。这里的抽象对于很多传统行业的同学可能不太理解,我在这里举几个例子,例如一个在上海的联通机房,他的命名可能是cnshu01,简单解释下,cnsh代表中国上海,u代表是联通,01代表编号;再举一个例子,我们在传统行业购置硬件服务器的时候,可能是每次根据需求不同选好硬件配置后再选品牌,在互联网公司一般会首先对服务器的用途进行分类,例如计算密集型,内存密集型,io密集型等,针对每种会有一个编码,例如C42代表计算密集型,这样的好处是需要使用机器的部门只需要将自己需要机器的编码和数量发给采购部门就行了,别的就不用关心了。资源编码化还有一个好处是当需要用程序来管理资源的时候,编码化最容易处理。

三是各种标准化,每个公司都会面临一个软件版本管理的问题,从操作系统版本到软件版本参差不齐,不同的软件版本在运维时还是有一些差别的,在一线互联网公司对于软件的版本一般会有比较严格的一致性要求,尤其是生产环境,过一段时间的软件版本升级工作其实也促使了自动化运维的发展,试想如果没有高效的自动化运维保障,每升级一次操作系统或者软件版本都是一项巨大的工程,恰恰是这样相互促进的关系,当整个公司都使用统一的操作系统版本和软件版本时,很多工作的难度就降低了。另外,一线互联网公司还对操作系统的目录结构(主要是指linux操作系统)有着标准化的要求,目录结构标准化的好处是无论谁来处理问题,都能根据标准化的路径到达目的地,找到自己所需的内容。综上所述,既定规范的绝对遵守、资源的抽象化和标准化,是落地端到端自动化运维交付的有力抓手。

三、自动化运维和流程管控

(编辑:源码网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读