欢迎光临深圳市丞昊信息科技有限公司网站
联系我们

联系电话:0755-23960018

官方邮箱:vilber.xue@shared-it.com

公司地址:罗湖区京基100大厦2401

    IT运维发展趋势及运维转型情况

    • 时间:2019-11-30 14:18:11
    • 作者:
    • 来源:IT运维
    • 浏览:237

           今天深圳IT运维公司在这里和说说IT运维发展趋势及运维转型情况,伴随着企业IT信息化的不断深入,企业对IT系统的依赖程度与日俱增。面对越来越多的各种IT系统,企业中各层IT人员可谓既爱又恨。爱的是,企业各种IT系统成为了企业业务的助推器,提升了企业业务和管理上效率。恨的是,随着企业愈发离不开IT系统,IT运维被推上了风口浪尖。如何保障IT系统高效、稳定、持续、甚至7×24小时不间断地提供服务,成为企业中各级IT人的亟待解决的问题,接下来我们就一起来看看。


    IT运维发展趋势及运维转型情况


    IT运维是指企业IT部门采用相关的方法、手段、技术、制度等,对IT软硬运行环境、IT业务系统和IT运维人员进行的综合管理。随着技术的发展,IT运维近年来也发生了的翻天覆地的变化,下面总结一下近年来IT运维的发展,并展望IT运维未来的总体趋势。

    一、IT技术架构:从“IOE架构”走向“互联网架构”

    1、IOE架构

    为何从技术架构讲起呢?政治经济学上是这样总结的:“经济基础决定上层建筑”,我认为换到IT业界同样适用。技术架构这个基础的演进,从根本上必然引发其他领域的变革,这当然也包括了我们讨论的IT运维层面。

    曾几何时,以IBM为代表的商用小型机、Oracle为代表的商用数据库、EMC为代表的高端存储设计是企业IT体系高大上的标配。我曾在十多年前参观某省级运营商的机房,几乎都是清一色的黑压压IBM小型机;他们的系统数据库无论大小和用途都是Oracle企业级数据库。

    回过头来去想,为什么当时的企业都倾向于这种IOE架构呢?当时而言,企业这种选择无可厚非,就连后面叫“去IOE”最凶的阿里,当年最初的技术架构其实也是IOE。在当时分布式技术未能成熟的前提下,IOE这种国外商用成熟软、硬件产品确实比同期其他产品带来无以伦比的单机稳定性和高性能。

    我曾在某客户现场看到一台即将下线的老旧小机设备,关机下线前检查了一下启动时间,惊讶地发现这台机器上一次启动时间居然是在3000多天前,也就是说这台小机居然在无故障、无停机的情况下服务了将近十年时间。许多企业正是为这种稳定性和性能,花了大量的银子买单,因为对于IT运维者而言“稳定压倒一切”是其根本需求。

    此外,从技术因素考虑,在当时IT系统运维还是以人力为主的年代,系统技术栈构成的单一也有利于开发和运维团队的组建和培养。例如,一两个Oracle的高手再配上一些中低级的DBA就能搞定所有的数据库相关问题,显然是相当合算的选择。

    但是随着技术的发展,“IOE”架构所提供的基于向上扩展技术的高端商用产品而设计的传统集中式系统架构达到了瓶颈。特别是互联网企业在技术架构上的不断深入研究,为IT行业带来了全新的技术模式变革。互联网企业掀起这场轰轰烈烈的技术革命背后原因,无非来自于以下几个因素:

    成本:成本是不得不考虑的,毕竟一台小型机的价钱,能换回来一货车的X86服务器。

    灵活性:互联网行业多变的业务特征,使技术架构需要及时按需而动,很明显IOE式集中式的架构难以实现这种目标。

    扩展性:集中式向垂直扩展的技术特点已经开始限制互联网企业的业务发展需求。互联网企业业务迅猛发展的特点,使他们需要一种更具弹性、更易于扩展的水平式扩展的云化技术架构。

    技术控制:互联网行业汇聚了行业中的各类技术精英,他们需要更为开放的技术环境为其不同的业务场景做出各种极致的改造。打个比方,他们显然更需要一台给他们随之改装的小跑车,而非一台四平八稳的商务车。这是显然也是闭源商用软硬件设备并不具备的。

    2、互联网架构

    随着技术的发展,这种云化、分布式、开源化的技术架构开始进入传统企业的视线。2014年9月,银监会就发布39号文即《关于应用安全可控信息技术加强银行业网络安全和信息化建设的指导意见》。此后数年逐步掀起了传统企业去IOE并向互联网架构学习的大潮。

    互联网架构其实并不神秘,归纳起来为以下几点:

    X86化和开源软件:用大量的国产x86服务器代替昂贵的外国小型机和存储,用开源的软件代替闭源商用软件,节省大量采购,许可证(license)以及原厂维护带来的成本。打个比方,就是“用买一头大象的钱买来一个牛群”。

    分布式:在架构上支持分布式计算能力,以多台机器的性能总和代替集中式架构下的单台小型机的能力。继续沿用上面的比喻,就是“用几十头牛代替一头大象在干拖木头的活”。

    系统可靠性:在架构上增加必要的冗余,在单个设备不靠谱的情况下,以整体的系统性可靠性代替单个设备的可靠性。再延用上面的比喻,就是“拉木头里的其中一头牛病了,应该马上换一头牛,然而并不会影响拉木头的进度”。

    高度可扩展:架构设计上支持可以不断加资源以达成更大容量,支撑更高的并发、迎接更多用户。“当拉木头变成了拉石头,要做的事情是增加牛的数量而已”。

    二、运维体系:从ITIL走向DevOps

    1、ITIL

    企业的技术架构的不断革新,推动着IT运维管理模式运维体系从稳态向敏态转变。

    随着企业信息化的深入,IT系统越来越多,企业IT运维人员也随之增加,不少企业信息部门专门成立运维团队进行IT系统运维工作。IT团队内部自然不可避免地需要对运维人员的各种活动进行管理。ITIL正是为企业的IT服务管理提供了一个客观、严谨、可量化的最佳实践的标准和规范。我认为正是ITIL提出的这些标准和规范在一段很长的时间为我国许多企业的运维体系建设起来指明了方向。

    ITIL强调流程:以ITIL理念为核心的各种ITSM系统无不将运维操作流程化。事件管理、问题管理、变更管理、配置管理,大家都按流程办事,杜绝一切拍脑袋决策和盲目操作。

    ITIL强调规范:运维人员按组织依据流程进行各种规范的运维操作,约束本身是为了确保大家的行为不要偏离方向,少犯错误。

    ITIL强调分工:运维人员按技能进行有效的分工,有人负责服务台的一线响应,有人负责二线的事件和问题处理,有人负责配置管理,有人负责变更审批等等。运维团队内部实现各司其职,分工协作。

    这种管理机制在IOE技术架构的年代是非常适合的。这种集中式的技术架构结构相对简单,显然需要更加稳妥运维操作,毕竟所有鸡蛋都放在这几个篮子里面;另外,在这种集中式的架构下面,业务变更也没有如此的频繁,需要动不动就走一个流程是有点麻烦,但是由于频率低,倒也可以接受。

    2、DevOps

    然而,在企业IT技术架构逐步进入互联网架构下,业务的迅速发展,强调IT更好地按需而变,强调更敏捷地响应业务的需求时,ITIL这个体系多少就有些与现实格格不入的感觉。这时,DevOps这个词汇走进人们的视野。

    DevOps的思想跟ITIL有着天然的区别

    流程压缩,反应敏捷,效率大幅提升:

    ITIL强调流程,但是也带来了效率的下降。在IOE时代,企业业务的变更还并不是那么的频繁,这种效率的下降还并不明显。但到了互联网架构下,这种负面效应就会被无限放大。

    举个例子,某运营商发布新的系统版本,往往会经历源代码提交、编译、打包、发布到测试环境、UAT测试、修改bug、再测试、最后上线发布的流程,这个流程往往会经历3-4天。因此,该运营商的版本发布一般只能以月为单位,最快也只能以周为单位。相对于业务周期以天来计算的互联网行业,这套体系对业务变更的反应也就太迟钝了。

    所以,DevOps体系则更为强调效率,在持续集成、持续的自动化测试、持续部署平台、立体化监控、技术架构优化等多种自动化工具的加持下版本发布和运维的过程被大大压缩,效率被大幅提升。应用版本发布频率可以以天,甚至以小时为单位。这种为了效率有选择性地放弃一些有点拖沓的流程管理,是IT运维管理为适应IT更好地按需而变,强调更敏捷地响应业务需求的一种更好选择。

    自动化操作代替冗长流程控制下的规范性:

    从另一个方面来说,ITIL强调了规范性,但是这种以建筑于流程之上的规范性仍然有很多缺陷。

    再接着上面运营商的例子来说,即使是有再完善的流程加以控制和规范,仍然没有人能打包票说版本上线一定没有问题。在每次版本上线前后,运维团队成员仍然如临大敌,战战兢兢。

    原因在于,技术架构复杂程度发展到一定阶段,流程往往无济于事甚至流于形式。在大规模、多类型软硬件设施运维情况下,单纯依赖人的运维体系终将成为整个IT运维的瓶颈。在这种情况下,许多企业尝试将规范性操作细化为各种自动化操作场景,例如,上文就提及过的持续集成、持续自动化测试、持续部署、自动化监控和运维等等的工具和平台。这些高效率、规范化的自动化彻底解放了运维人员的压力,让运维人员的精力可以投入到真正有意义的工作中,而非总是在重复一些机械和重复的常规性事务当中。

    以谷歌为例,他们的SRE工程师强制规定他们只有30%的时间会花在on call这种事务型的工作当中,而70%的时间则花在各种自动化工具的开发之中,比如自动化发布系统、监控系统、日志系统、服务器资源分配和编排等,这些工具需要他们自己完成开发和维护。这种以自动化工具下高效率的自动化操作代替冗长流程控制下的规范性,也是DevOps体系的一个比较明显的特征。

    开发与运维的融合:

    同时,ITIL背景下的分工也带来许多负面问题。例如,运维团队感知和认同感很差。企业高层领导认为运维工作没有亮点和价值,是一个成本部门;运维团队也多半认为自己是“背锅侠”。以至于多年前做项目时曾听到合作某甲方运维团队核心成员的一句抱怨:“少壮不努力,老大干运维”。

    这可能也是大多数运维者的心声吧。诚然,这里面有运维工作成果难以量化,企业高层不够重视等因素,但是这种过于壁垒分明的开发与运维的分工也是重要原因之一。

    企业开发团队与运维团队形成的鸿沟,使开发团队在规划、设计和研发的过程中过于着重功能的实现,在一定程度上忽视了运维团队所关心的稳定性、性能、可用性等因素。

    同时,运维团队又无渠道将这些问题在开发前期予以反馈和修复。于是乎,运维团队不断沦为“救火队员”和“背锅侠”,团队士气下降人才流失,运维质量下降形成了恶性循环。

    所以,DevOps体系中强调的是开发与运维的融合。

    开发运维一体化使开发和运维的信息透明性,运维过程中遇到的问题更有效地反馈到开发团队中。同时,运维的责任主体从单一运维团队变化开发、运维团队共同承担。这使得开发团队也需要为运维中遇到的故障负责,让开发团队也需要将部分的精力和资源投放到与稳定性、性能和可用性等运维相关的研发中去。

    当然,并非说ITIL这套体系就已经完全过时,而是我们需要将两者与企业中的开发运维特点相结合,形成更有效的适合企业自身的开发运维体系。只有适合自己的才是最好的。

    三、运维平台:从ITOM走向AIOps

    “工欲善其事,必先利其器”,运维工具是我们实现各种运维操作的有效帮手,它解放了运维人员,让他们可以更多更好地维护各种IT系统。运维体系的发展当然也离不开运维工具的发展。

    1、手工运维

    二十多年前,企业IT信息化刚刚起步,IT运维基本还处于刀耕火种的时代,没有所谓运维工具也没有意识其存在必要性。几个小姑娘定时在终端上敲些命令,并在纸质的表格上一丝不苟地记录着读数,这还是当时比较规范运维做法。原因是当年那个年代需要维护IT系统的量很少,单靠人也看得过来。

    在IOE架构统治的时代,运维团队的人工维护还是占绝大部分。当然其中也不乏一些人,开始总结他们的运维操作,将一些常用的操作写成大量的脚本以便于从事一些机械、重复的事情时候可以“偷个懒”。但是,在这个阶段手工运维还是占了绝大部分的工作量。

    2、ITOM

    在IOE架构时代的后期以及互联网架构开始普及,也同时伴随着企业IT信息化的不断深入,企业中IT设备量呈现爆发性的增长,单靠人力开始逐渐管不过来。

    以我服务过的某运营商客户为例,最初的业务支撑部门负责维护其核心系统,当时只有区区20来台主机,几个数据库。然而其后数年,维护系统规模上升了十数倍,运维团队规模只增加了不到一倍。维护规模和运维团队能力只会形成了事实上的越来越明显的剪刀差,这成为运维管理中最核心的矛盾。

    而后到了企业开始尝试引入互联网架构,系统的复杂度更是陡然上升、维护目标更是迅速增长,按照传统的手工或者半自动维护来做,就更是走不通。因此,企业为解决这种问题,尝试引入各种运维工具通过自动化的手段解决运维人手和能力不足的问题,IT运营管理也就应运而生。

    IT运营管理(ITOM)是指对IT基础设施以及软件应用等对象的运营进行实时监控管理并提供反馈的服务,为监测对象保持最佳运行状态提供保障。ITOM领域的工具分为三大类别,分别是:

    监控类:各种提供应用性能监控、基础软件服务监控、主机存储设备、网络设备等自动化监控和告警的软件服务,例如,商用软件中的Tivoli、开源软件中的Zabbix等为代表。

    管理类:各种提供IT运维支撑服务以及配置管理等方式的软件服务,例如,各种ITSM系统和CMDB软件系统,例如,HP的OpenView之类。

    自动化类:各种提供自动化运维手段的工具和软件,例如,开源的Ansible、Puppet之类。

    IT 运维管理(ITOM)将从原有的人工加被动响应,转变为更高效、更为自动化的运维体系。

    以上文提及的运营商客户为例,由于运维人力的增长无法区配IT系统规模的增速,企业连每天早上大规模营业前,对所有IT系统的设备进行一次常规状态巡检也难以维持。

    为解决这个矛盾,专门部署和实施了我们的自动化监控和运维平台,将大量常规的操作交由机器实现。就正如每天的巡检动作,只需要定义好相关的巡检模板,机器就会十年如一日地按照我们定义的规范进行各种巡检操作。

    如巡检结果中出现任何异常,运维人员的手机就会出现该问题的告警短信,通知相关运维人员处理。这种自动化的运维工具体系,其实质是让机器管理机器,将大量重复、机械的运维工作交给机器执行,有效地降低运维人力资源的投入,也让运维人员的精力得以释放并投向更为重要的领域。

    最近我又跟该运维团队的负责人在聊天,了解到他们实际上80%运维操作都交给机器自动去完成。最后,他哈哈一笑道:“其实我们现在运维团队除了应对突发性的系统故障以外,最常见的事务实际上是给应用系统为企业各式人员创建账号和分配权限,并且我们现在正在开发代码将这件事也自动化了”。

    3、基于运维数据的分析ITOA

    ITOM体系将自动化带到运维当中,让IT运维更加高效。但是,ITOM仍然未能打破运维工作对运维者经验的依赖,往往缺乏分析能力,虽然也能采集到运维数据,但无法对这些数据所包含的信息进行洞察,更加无法将数据进行知识化的本质提升。

    例如,各种故障的处理分析过程中,仍然是依靠运维者的经验甚至直觉来分析处理,运维决策中各种拍脑袋的例子仍然层出不穷。这是因为传统的ITOM工具往往缺乏数据分析能力。虽然也能采集到部分的运维数据,但是由于数据采集不全面,并且数据未能整合、数据间缺乏连接和分析手段,所以运维者无法对这些数据所包含的信息进行洞察,更加无法将运维背后进行知识化的本质提升。

    因此,运维者开始着手进行基于运维数据分析ITOA的探索。大数据技术的成熟,让海量运维数据的分析成为了可能。参考经营分析领域的例子,我们开始着手建立了从运维数据采集、处理、分析和可视化展示的全面运维数据分析体系。我们运维IT系统无时无刻不在产生海量的数据,它产生的数据量甚至可能会超过我们的应用系统,因此运维分析天生就是个大数据的应用场景。

    实现基于运维数据的分析ITOA

    首先要解决的是数据采集问题:

    因为运维体系中的数据是多种多样的,有像监控系统直接采集回来的结构化的数据,也有像各种应用日志、机器日志等非结构化的数据。