[关闭]
@gaoxiaoyunwei2017 2020-04-16T21:51:13.000000Z 字数 7586 阅读 836

必知必会:IT运维体系与发展趋势——传统运维VS互联网运维

未分类


作者简介
韩晓光,IT运维践行者。开发、运维、商务、管理。
《系统运维全面解析:技术、管理与实践》、《运维的一天:架构设计、故障处理……》、《实践出真知:云计算新风向》……

备注:本文根据演讲者视频语音速记整理而成,如有图文不妥,请以视频为准。

今天要讲的内容是做一个IT运维体系是什么样的,包括未来的发展,我的题目就是IT运维体系与发展趋势,这也是我以前分享过的内容,老酒装新瓶,引入新的概念和新的信息,以前的题目是传统运维和互联网运维的对比分析。

我们分享的有三个方面:

首先说一下我的个人分享,可能也限于个人的经历和水平,能力有限,视野有限,欢迎大家指正,也只是代表我现在当前的一个观点,另外可能引用网络的图片和内容。

今天分享的内容大概分成五个方面:首先说一下运维做什么,为什么要这么做,我们应该怎么弄。第二分享一下整个封闭式系统架构和开源系统架构的对比分析。第三分享一下传统运维和互联网运维的对比分析。第四探讨一下IT运维发展的一些新趋势。第五给我们的运维人员提供一些建议。

一、运维是什么?

那运维是做什么?说句实在话,我干运维也十多年了,到底运维做什么的,在我刚入行的时候,别人也会问我,运维是做什么的,我会跟他们解释说,运维可能就是修电脑,或者维护服务器,或者说做一些系统维护,但是可能你的朋友并不理解,当你回到家的时候,估计七大姑八大姨都问你什么是运维,你根本解释不清楚,后来我就说,网吧你们总知道吧,这个他们好理解了,他们说哦,原来你就是网管。我觉得有点遗憾,上了那么多学,当成了一个网管,可能这个定义不太准确,对吧,也因此我心里总有一个想法,我要探究运维到底是做什么,我们未来要做什么,我们运维的价值是什么。

image.png-87.6kB

看看国外对IT运维的一些定义,英国的CCTA它说IT服务全生命周期的一个阶段,通过对IT服务与IT基础设施进行监控,实现备份恢复与作用调度等活动。这个定义我觉得读完了还是不知道它在描述什么,可能和我们差距有点大。

Gartner也有个定义,说是IT服务管理相关人员及管理流程,其目的是将具有成本与质量要求的服务交付给用户。这个可能还好理解一些,具有一定代表性,但是总觉得还是离我们IT运维的定义有些远。

再看我们国内一些白皮书怎么定义的,IT运维是指以组织的内、外部用户需求为导向,通过一系列流程、技术、方法,确保为用户提供的IT服务活产品符合一定要求。我觉得这个定义还是比较符合我们国内IT运维的一个工作内容和范围,还是比较精准的描述。总体来说我觉得我们现在的运维核心价值体现在哪?我们就是四个方面:质量、成本、效率和安全,这是我们IT运维核心价值体现。

image.png-581kB

平常运维在做什么?做很多繁琐的事情,打标签,做系统配置,做系统变更,这些工作很繁琐,我们的压力也是很大的,你经常有时候你在半夜三更做变更,什么时间做,每个时间点都是卡在非常精准的,过了那个时间点可能你的压力就会骤然放松,做运维的应该都有体会。做运维的加班也很多,我在刚入行的时候别人过中秋节,我在机房贴标签,这对我来说现在仍然记忆犹新。现在也是,我的运维工作生涯感觉是周六日一直是常态化的加班,这也是很多行业同事的常态,做运维难免会遇到很多系统故障,这也能挑战我们运维解决能力很重要的场景,故障不断,也是提升我们经验价值很重要的一个阶段,只有不断解决故障,才能有更多的层次在提高。

所以说我一直以为我们IT运维干的和社会上的消防员是很像的,消防员是救火,我们IT运维人员救的是IT的火,本质是一样的。

作为运维我们也会有各种背黑锅,当你解决不了问题,发现不明问题,那你怎么办?你又没有证据,这个时候对于一个企业来说运维的价值就在于你发现问题和解决问题,当你解决不了问题的时候可能你还真要背黑锅,这个也是很多行业,不光运维行业,我们同仁同行也好,我们一个必经之路,只有经历多大的委屈,才能成就多大的事情。作为运维来说我们是7×24小时×365天这样的工作情况。

二、封闭式系统架构 VS 开源系统架构

image.png-267.2kB

其实在运维圈里有传统运维,也有互联网运维,他们有很多共同之处,就像我们刚才讲的那方面,但是也有很多差异性,传统运维和互联网运维的差别还是蛮大的。下面先讲一讲两种运维架构的区别,传统的架构和开源的架构。

image.png-230.1kB

通常我们说的传统架构也就是商业封闭式的架构,这个在很多金融业、电信业、能源交通这些国家企事业单位包括一些传统的企业都会使用这些商业架构,典型的是以IOE产品软硬件为主要元素的架构。这种架构的特点就是说它的纵向扩展能力很强,能够增加CPU、内存、扩展柜等,以这种方式提高架构的处理能力和稳定性。典型的架构比如像IBM的power系列,他们会做这些HV的架构,只能是送机(音),然后做多冗余的这种方式去连接后端存储,这是一种典型的IOE架构。

这种IOE架构在十几年前,二十几年前我们这种架构它为我们的国民生产业务IT运行还是提供很重要的支撑能力,还是有当年价值的存在,还是值得认可,还是推动我们IT信息化的建设这一块内容。

image.png-238.1kB

随着互联网产业的发展,这种IOE架构就不太适合很多互联网企业,互联网企业他们会使用这种开源的系统架构,典型的就是以这种比较廉价的PC服务器基于一些开源的应用、程序去搭建他们的系统架构,这种系统架构的特点典型的以横向扩展为主。

什么叫横向扩展?比如一台机不够,不是说在机器里面增加CPU和内存,而是在一台机器不够的时候增加两台,两台不够增加四台,四台不够增加八台,一百台增加二百台,是这种以单服务器的方式扩展它的系统架构。

所以说这种架构下有很多典型的像BAT包括新的像字节跳动,或者京东这些新的互联网企业他们都是典型这种架构特点,互联网访问,然后经过一些CDN的策略,经过一些负载的策略,经过后面一些应用的集群去访问后端的一些数据库或者图片文件这些信息,就是典型的这种开源式的互联网式的系统架构。

三、传统运维 VS 互联网运维探析

说完这两种架构的特点,我们说一下基于这两种不同的运维方式,一个是传统运维,另一种是互联网化的运维,这两种运维体系基于架构特点的不同,他们有很多不同点,总结为如下几个方面:

架构的差异、工作内容差异、面向对象的差异、运维人员的差异、体制理念的差异和知识体系的差异。

image.png-144.2kB

在架构差异我们刚才也基本讲了,一种是IOE的架构,另一种是开源的架构。IOE的架构更多是以商业闭源的软硬件去搭建,形成了一种解决方案,纵向能力扩展是很强的,横向扩展能力比较弱。围绕这种架构,当年建了很多两地三中心,包括现在很多金融业的两地三中心也是基于这种IOE架构搭建的,这种方式是比较重的运维模式,也是一种比较集中式的运维管理模式,它有完整的保护机制,毕竟商业在价值还是在稳定性方面还是很好的。

而互联网的网管用的X86服务器,白盒的一些产品,这种DIOA这种能力的特点比较明显,当然这种架构就像我们刚才说的,它的横向能力扩展很强,纵向能力扩展比较弱。这种在不同的行业,采用相同的技术理念去搭建他们的内部架构,基本上是技术体系技术栈差不多的。

在这种技术架构下,他们更多追求分布式、负载集群的理念,这种方式往往就是一种模块化,很典型的这种轻量级的,坏了一台机器也没问题,坏了两台也没问题,这是典型的运维方式。这种方式就是随着开源社区包括这种X86服务器,他们迭代还是很快的,这种产品迭代速度是比IOE架构迭代快很多,这也是开源运维所要面对的比较典型的一个特点。

在工作内容也是有很大的差异性,传统运维往往有很多自建的机房,自主维护机房的风火水电,他们对自己的业务背景知识有很强的逻辑性在里面,有很复杂的业务场景在里面。但是对于这种开源互联网企业往往他们不一定有自己的机房,但是很多大的企业,头部企业会自建机房,也有很多租用别人的机房,或者别人代运维的机房,他们围绕这种LAMP这些技术栈去做工作。

image.png-138kB

业务对象和面向对象也有很多差异性,很多传统运维面对的对象更多的是自己的用户,自己的业务,偏重的是业务性运维,他们对这种业务的把控性和敏感性比较高。对于互联网化的运维方式,往往是偏重于技术产品的运维,往往是偏重于to C的业务,网民比较多一些。在这种场景下,用户对象就比较复杂了,所以说对象市场多变,而且前方对技术的需求也是五花八门,对象和需求都是海量不可控的,传统运维和互联网运维就有很大很大的一个面向对象的差异性在里面。

image.png-120.7kB

在运维人员方面也是有很大的差异性,传统运维他们有很多人在这个技术窗里面有比较高规格的配置,学历高,另外他们学习成本也很高,因为毕竟是必然的传统IOE这种培训体系成本还是很高的。对于互联网化的运维差别就比较大了,大神、小白每个层次的人都会有,他们的成长路径也是五花八门,各有各的成长路径,各有各的薪资,在薪酬体系方面当然也是有很大差别。传统运维普遍的工资比较稳定,因为毕竟它还是有工资体系的受控在里面,但是对于互联网运维当然就是千差万别了,高的也很高,低的也很低。

image.png-162.6kB

体制理念上,传统运维和互联网运维差别也很多,在传统运维他们很多运营指标,KPI也好或者OKR也好,他们的指标往往有很多社会效益的评价指标,他们最注重的是统一的发展思路路线,这个也是有很大体现在他们的统一性的管理文化和流程文化在里面。对于互联网更多是求快,求变,他们更注重追求的是经济效益第一位的,目标导向,在这种文化里面就比较开放一些,这个文化体系就跟传统企业差别很大。

还有就是知识体系的差异,首先这张图引自于赵班长(赵舜东)的《运维知识体系》,这个知识体系总结得非常棒,大家可以去他的官方网站去了解一下,当然赵班长也是我的好朋友,他的知识体系我也还是很佩服的,总结得很完善,当然在这里面不再细说了,大家可以了解一下。对于传统运维的知识体系可能会包含一些围绕传统的产品、传统的硬件、传统的知识去构建的知识体系。

四、IT 运维发展的一些趋势

说到知识体系还有一点,大家不知道有没有注意到,其实在最右侧有一个云计算,我们现在所用的任何的技术,很多东西都可以靠云计算来解决,都有对应的产品和解决方案来解决,这就是说其实在后面我们将讲到,我们的运维由于这种云计算这些新技术,新革命,给我们带来新的变化,对我们的运维是有一定的冲击性。

image.png-90.4kB

第一个趋势是从IOE到开源 X86。其实去IOE也有一段时间,为什么要去IOE?在2008年全网有一个比较深刻的印象,那时安全已经逐步上升到国家的层面,另外中国的本土环境发展日新月异,国产化的需求和自主研发的能力越来越强,这也是去IOE很强的一个内部基因所在。

另外也是考虑到不管国家层面还是企业层面,各个行业都希望灵活掌控架构能力,这也是本土化这种产业的需求,这也是去IOE的第二个原因。

第三,全球开源技术理念和互联网蓬勃发展对IOE有很大冲击。由于IOE这种封闭式的体系或者说闭源的体系往往不利于产业或者技术的蓬勃发展。当然去IOE,无论设备还是产品,还是学习成本,还是有一个很高的门槛和成本所在,这个不是广大互联网产业、开源产业所能接受的,所以说去IOE一个当前还是真正不可逆的趋势。

从长远来看,IOE架构和非IOE架构还将是长期并存的,因为技术体系的更新换代并非一二天能解决,尤其对一些当年的核心数据库、核心应用、核心系统往往部署在IOE这种架构下。

image.png-53.8kB

第二个趋势是运维自动化、智能化。这个也提了好几年,从我接触也有大概五六年,现在仍在提。其实很多产业在运维自动化、智能化的成果还在不断迭代和优化中,它确实能够为我们运维带来很多的优点和优势。

image.png-173.3kB

第三个趋势是双态IT运维。在传统向互联网化、移动化转型的过程中,为了一方面保证现有业务运转,另一方面去适应这种新的IT技术的变化,就产生了两种IT运维模式。目前,很多行业一直在提到的“双态运维”,一个是稳态,一个是敏态,一个追求业务稳定的发展,另一个追求迭代、快速、变化的诉求,于是有了这两种运维方式。

image.png-162.5kB

第四个趋势就是研发运营一体化,即 DevOps。DevOps 两三年深入到了千家万户,它的核心理念包括丰田的精益管理、敏捷的理论,持续交付、持续集成的工具链,还有一些轻量级的IT服务管理。基于这些理念和工具共同打造了从研发运营一整条的流程体系,其实更多的是解决了我们以前从开发到部署到后期的运维运营这样一个互相割裂、烟囱式的状态,使我们的IT运营更加有效率,迭代更快,反馈更快,更好地满足内部的业务需求和用户需求,这也是研发运营一体化理念的价值所在。

image.png-184.5kB

第五个趋势就是云计算、混合云、融合云。基于底层的虚拟化技术构建的云平台,包括最近一两年发展的融合云或者混合云去整合云资源来提供更大的平台去支撑大数据、AI智能、运维,包括其他各行各业万物互联的场景,这也是一个很大的趋势。这对运维既是挑战也是机遇,为什么呢?因为这个产业总是在变和技术总是在变化,只要随着大趋势变,那我们就会站在时代的潮流。

如果我们还是保守以前运维的理念,不上云,不接触云,那你肯定是被淘汰的,因为十年前我部署一个数据库很难,各种配置各种调用,现在直接十分钟可以开出一个RDS,而且做好了优化,做好了集群,那无论是效率还是稳定性方面,分分钟达到我们的传统运维,所以说这就是运维我们所要面对的大趋势。

基于这个,最近一两年还有比较火的云原生的概念,其实是更深层次更广的层面整合现有的云架构体系的技术栈,用敏捷的理念,用一种中台的理念或者打通的理念去构建、重塑技术体系,更好支撑新的业务快速迭代发展,这个跟 DevOps 理念其实还是有很多融合的地方。

image.png-315.3kB

第六个趋势是数字化。国内这一两年也是很火的话题,其实它也是,我们以前在构建各种信息化,打造很多系统很多平台,但是往往也构建了很多壁垒,导致我们很多信息系统不通,业务是割裂的,组织也是割裂,这个数字化要解决的问题就是通过更底层的数据加算法构建新的服务去打通我们的业务,重塑我们的组织架构,使我们未来的IT价值体系与业务更加充分融合,这就是数字化所要解决的问题,也是带来了他们的价值所在。说白了就是它在优化它的资源配置,优化我们的流程体系,让我们更好地区面对未来的智能化社会,这就是数字化的核心价值所在。

image.png-172.1kB

总体来说,说了那么多趋势,当然还有一些,大体也就是这些,以前是用硬件,现在是自动软件定义;以前用服务器,现在用云,我们现在用云,未来可能更多是混合云,融合云;以前是技术运维,现在搞的是技术运营一体化;另外还有重要的就是不论我们现在做任何一个方面,网络空间安全现在也是提升到一个国家层面的高度,在企业里面也是提供企业至高点,这个网络安全是一个标配。

五、运维人的一些辅助技能

image.png-305.2kB

讲了四个方面,再说说面对新的趋势,运维同仁需要掌握常见的什么技能去应对未来的变化,去武装我们自己。其实怎么说呢,这些知识都是我们的一些技术知识,只有打好基本技能才能更好面向未来。比如说运维很多人不一定光做这些项目管理,但是我认为当你做到一定程度运维,你不可避免接触到各种项目管理知识,这个是提升我们运维管理能力、管理项目能力、构建IT信息化能力很重要的知识体系。

image.png-149.9kB

另外说运维两个很重要方面,一是如何构建运维流程?二是如何构建运维的网络安全性。这个是作为一名运维入行之后要持续去构建的两个方面。当然这只是以 ITIL 作为一个引子,如果现在太偏重于 ITIL 肯定也不太好,因为这种业务流程体系会拖累IT的敏捷性,现在更多的是 DevOps 上的轻量级的、敏捷型的流程体系。基于这种流程和过程中融入到安全,基于国家网络安全法和指南去构建一个可靠的、安全的运维运营的环境必不可少。

image.png-426kB

这同时就需要各种技能。举一个例子,运维怎么开会,开会是不是要设定一个主题,基于一个主题大家去讨论问题,而不至于跑偏,主题确定完了,后续有什么目标要做,怎么做,大家要有一个追溯,这些还是很意义的。

另外,运维要遵循一些MECE的原则,我觉得这个对于运维思考问题也很重要,经常有一些运维思考问题互相交集互相交叉,让人有时候无论是解决问题,构建系统架构,还是处理故障问题,我们还是要有一个比较清晰相互独立,又能完全重建的思维方式去有利于运维工作,更有利于运维生涯。

还有墨菲定律,很神奇,作为运维我们总担心出现某种故障,但是越担心的事情它这个概率无论有多少,它总会发生,很神奇,我觉得运维同事也有必要去了解一些。还有一些思考方式,比如思考帽、Smart原则。

还有运维经常会做一些采购或者商务工作,难免要与人打交道,察言观色,这个根据人的行为、言谈举止去判断人要做什么,他们内部要在想什么,基于此我们更好与人打交道,这也是对于运维来说很重要的一个方面。

image.png-211.6kB

对于运维来说我们还要有了解一些架构的体系,比如说单体架构,还有微服务架构体系,在我们设计这种运维的时候,我们参与架构设计的时候很重要的一个方面。作为运维人员我们想成长,其实有一个最基础的理念,希望大家能够用,就是手脑心,就是经常有很多运维的同事爱动手,但是呢不爱思考,不爱动脑筋,这个也不太好,有人说我做了事,但是不愿意总结。其实我认为这样不利于我们做,因为想要做深度的运维或者你做一个架构层面的,比如说更深层次的运维,你必须既动手,也要动脑,用心想,把一个事情做完美,总结完美,然后呢基于此能够推演出一些沉淀出来你的价值,沉淀出一些你的运维经验,这个可能对运维来说很重要,这个希望运维的同行能够去尝试试一试,多做,多总结,多想。

杂七杂八说了那么多,其实作为运维涉及内容还有很多,但不管devops、敏捷精益、云计算,还是双态运维、数字化、智能化……,这些趋势及理论都有一个共同点:他们都是对现有和既往的IT体系进行整合优化,万变不离其宗,都是面向人、事、物、流程的重组优化,不同的资源要素配置组合,就会产生不同转型升级效果,最终就是对组织、对业务构建新的生产力及生产关系。按照人、事、物、流程这几个层面划分,IT运维通常涉及如下管理内容:

image.png-692.2kB

最后再说一个更宏观的,哲理性的东西,其实不管你做运维也好,还是各行各业,其实很多道理是相通的,无论是技术,还是从事商务还是从事产品,其实都一样,我们既要知道一个产品,也要基于知道的东西去实践,以知促行,以行促知,只有做到知和行的完美结合,才能更让我们运维做得更好,更完美,走的人生路更长,这就是我想说的。

image.png-324.6kB

其实这个图是一个混元三教九流图,它也是这么一个道理。左边其实是一个儒家孔子的形象,右边是一个道家老子的形象,中间是一个佛像,它也是一个浑圆,融会贯通的浑圆图,这个也是给我们很多启发,怎么说呢,最后运维一句话,一粒沙一个IP,一叶一菩提,万事万物融会贯通,让我们运维走得更长,更远,祝福大家的人生更美好。

谢谢,这就是我今天的演讲。

添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注