
经过几十年的发展,it行业在当前互联网技术的推动下,进入了一个资源高度整合的时代,即系统化和智能化的时代。运行维护服务也将向组织化、标准化、专业化、智能化方向发展。
相比其它相关行业发展来说,IT运维服务的智能化管理更具得天独厚的优势,因为IT系统设计本身问题就是一个基于企业数字化、数据化和网络化的,而这几个方面要素恰恰是一切智能化的基础。
手工——机器——自动化——智能化,这种生产方式的演进,其目的就是逐步用机器取代人工,最大限度地把人从繁复的、非创造性的劳动中解放出来,以提高生产质量、降低生产成本。智能化对于IT运维服务来说,同样具有非凡的划时代意义。它不仅能大幅度地降低服务成本、提高服务质量的稳定性,还为商业竞争构筑越来越高的技术门槛。
在长期的运维管理实践中,人们开发出各种运维管理工具,如信息安全系统、负载均衡系统、上网行为系统、网络监控系统、运维审计系统、日志审计系统等等。越来越多诸如此类系统的出现,标志着运维管理进入类似制造业的机器生产时代。下一个阶段的发展趋势应该是将这些系统在业务流程和数据上进行整合,朝着自动化与智能化方向挺进。以便更大程度地取代人工,消除人工服务所带来的非标准和质量不稳定的隐患,并进一步地提高服务效率、降低服务成本。
智能化是建立在大数据基础上的,首先要解决的是运维数据的智能采集。根据客户单位的业务需求,确定运维服务的总体目标,明确需要收集哪些数据?是怎么收集这些数据的?收集这些数据的方法是什么?如何确定不同类型数据的采集频率?如何分类和存储数据?
其次是大数据挖掘。设计运维数据分析模型,从海量历史数据中准确找出IT系统存在的问题。以监控系统为例,大部分客户都购买了网络监控系统,证明实际工作中存在这样的刚性需求。但实际上,大多数客户并没有很好地使用这个系统,主要是因为这些系统在数据准确性上并不理想,对大数据的分析和提取也比较薄弱。由于营销的需要,监控系统开发商把主要精力都放在新功能的开发和数据的展示上,对数据的准确性及分析挖掘缺乏深入研究,因而使得监控系统的实用性大打折扣。
然后是如何集成各种 *** 作工具和它们生成的数据的问题。如何将各种运行维护管理工具集成为一个智能化的运行维护管理平台,充分发挥其整体价值。对于需要人工干预的事件,还需要与服务流程管理系统进行接口,以实现人机服务的集成,实现服务流程的智能化。与运维的组织化、标准化、专业化一样,智能化运维也是运维服务行业发展的大趋势。 谁能顺应这一趋势,把握这个发展机遇,谁就赢得了未来!
本文摘要节选自来源于
>
运维,更偏向于业务产品的支持,偏向于背后的英雄,运维团队需要为业务的稳定性,成本等方面负责!
企业需要的IT运维体系,本质上也是需要从稳定性、成本的角度来建立。
(1) 稳定性方面
稳定性,是反应服务访问质量差甚至无法访问的指标。业界流行的的稳定性公式是,服务总在线时间/服务总时间,具体指标数据以几个9表示,比如一般的云计算服务提供上,承诺的稳定性指标是3个9:999%(意味着每年宕机时间不超过875小时),而对于大型互联网公司的业务,对于运维的指标则是9999%(全年宕机时间不超过52分钟),甚至99999%(全年宕机时间不超过8分钟)。
稳定性方面,需要什么样的技术体系支撑呢?
监控体系。现在开源软件已经让企业的运维能力大幅提升,如zabbix,nagios等,已经被很多企业广泛使用。同时,随着人工智能的兴起,监控的智能化精细化水平,也在不断提升,比如,传统的监控无非是发现异常了之后报警,但加入智能化之后,则可以自动分析异常的根本原因在哪里,基于此则可以继续做自动的恢复,避免人工成本。
基础技术体系。包括硬件(服务器,网络等), *** 作系统/内核等,也直接影响到业务的稳定性。现在云计算的技术已经非常成熟,服务器与网络方面可以由类似openstack,cloudstack等IaaS平台管理, *** 作系统/OS等则可以通过docker,以及各类PaaS平台进行维护与管理,实现稳定性的保障。
安全体系。随着现在互联网的飞速发展,伴随而来的网络攻击也越来越疯狂,根据普华永道的调查,针对中国公司的网络攻击频率两年内已经提升了两倍,这也使得安全成为互联网架构中必不可少的环节,waf应用防火墙,数据清洗,防cc,ddos攻击等安全体系,也是必备的技术体系之一。
(2) 成本方面
计算成本。即托管企业运行软件所需要的服务器成本。现在云计算厂商提供的IaaS产品也是已经非常成熟,而且价格也在不断地下调,2016年10月,阿里云宣布了大量云产品的降价,一年内就下降十几次,也使得企业的成本控制方便可以越来有利。
人力成本。包括运维人力,研发人力,运维人力的主要投入来自于业务稳定性的保证,比如,服务异常之后的故障恢复,容灾与服务重建等。业务研发中,业务本身的迭代效率与质量,也间接影响了研发的成本。这方面则可以通过PaaS平台的技术手段来解决。
(3) 商业化
商业化是企业运维体系的更上一层。企业IT运维是每个企业必不可缺的环节之一,因此,运维相关的产品也逐渐受到企业的重视。比如应用性能分析厂商(new relic),则是提供了优化服务运维质量的有效方案,监控等产品也是运维最受欢迎的产品之一。
在互联网行业,运维一直是一个被深深误解的位置,以至于很多人认为IT行业运维的技术含量很低,其实并非如此。
从本质上讲,运维其实就是你用自己的技术储备知识的岗位,保证你管理的IT服务能够正常运行。
在商业上也是一样。软件工程师的任务是通过编写代码将软件以图形化的形式提供给用户,而运维工程师的任务是使软件在计算机或系统上正常运行。但是一旦软件出现问题,大多数人想找的是软件工程师,而不是运维工程师。
就像我们盖房子一样。产品开发负责房子的规划,设计师负责房子的外观设计,开发工程师负责建造房子,运维负责打好房子的地基。而打好地基,并不意味着简单地挖个坑。里面的技术含量很高。必须彻底研究坑的大小、深度、大小、湿度等。
房子盖好后,大家只会关注房子盖好后的风格。很少有人会注意房子的地基,但是一旦房子倒塌,大家就会怀疑地基是否牢固,运维这时候就出来了。回到平底锅。
很多人片面地认为运维没有技术含量。这其实是一种错误的认识。因为运维也是分很多层次的,就看你达到了哪个阶段。基本上,现在一个运维除了掌握基本功,如果你还可以掌握云计算技术和一门编程语言(比如Python语言最适合运维人员),那你就已经是高人了级别,基本上是全栈开发运维人员。这种运维不用担心找不到工作,工资自然比其他普通运维高。
我自己在大公司和小公司都待过。我觉得主要是初级运维太多了,他们做了很多根本不能叫运维的事情。总结了以下几点:
运维必然会做基础工作,比如部署服务,上线,甚至搬机器,重装系统等等。但是运维不能只做这个,所以如何在剩余的时间内做有利于运维技术提升的事情就显得尤为重要。
举个简单的例子:当你做研发的时候,你在其中处于什么位置,你如何体现你的价值和技术能力?如果没有,你基本上是在帮助别人。
广泛的范围包括:硬件、网络、 *** 作系统、数据库、存储、开源软件;职责:部署和调试各种功能,如ldap、samba、nagios等;进一步细化的分工还包括:压力测试、性能优化、内核参数调优、系统问题跟踪等。
很多运维要在不同层次上做太多的事情,导致很多事情只是完成任务,缺乏深入研究,当然也可能缺乏深入研究场景。
其实和第一点关系比较大,因为目标本身没有足够的规划,总结性的介绍不够,技术的提升也比较有限。
举个真实的例子,我认识一个做运维7年多的人。这期间,他在几家公司干了很多事,时间也不短。通常情况下,会有相当多的积累。前段时间,我正要推荐他在内部击球时,我查看了他的简历。我有几个感受: 整个简历都是描述性词汇,没有数据支持;项目工作全是叙述性描述,充满服务搭建和问题解决,没有技术点;唯一的技术工作是一笔带过,没有方案选择和技术能力体现,技术水平无法体现;
我自己也面试过很多人,说实话,这种简历离及格还差得很远。应聘公司拿到这样的简历,怎么能快速的了解到你就是公司需要的人?
如果我们不知道运维的具体内容,我们无权评价运维的技术含量。一般来说,互联网公司的运维内容分为两个层次:
简单的说,就是部署服务、维修电脑、安装系统、安装软件、处理网络问题等等,做各种家务活,甚至弄个路由器、剪网线。
网络运维,即网络工程,必须精通各种网络协议和架构,Cisco、华为、H3C路由和交换,至少两项;
数据库运维,数据库运维应该理解为DBA,至少要精通,并且要精通数据库;
*** 作系统运维必须精通 *** 作系统,了解 *** 作系统内部工作原理,了解一些硬件知识,了解网络协议进行故障排除;
还有很多其他的事情,比如服务器运维,都需要覆盖面广,同时拥有多种技术;
运维技术差,可能只是因为公司小,如果公司规模小,大家看到的运维工作只能是表面和基础的工作,现在很多运维岗位都被云服务取代了。运维的内容是在云平台上运行软件。
事实上,有人认为在平台上 *** 作软件很简单,但实际上,如果没有计算机相关知识的积累,很难知道云平台上的功能实现。在这方面,技术含量不低。
如果公司逐渐成长为大型公司,运维的价值就会凸显。比如云资源和离线资源的管理、数据库管理、网络管理、计算资源、网络资源负载、调度处理,都需要丰富的计算机理论知识和实践经验,否则无法提供稳定、上层的可靠服务。
作为一家提供互联网服务的公司,用户能否稳定可靠地使用互联网服务,是他们生活的基础。想象一家公司每三天失败一次并且服务不可用。虽然强调了运维的存在,但大家还会相信你的产品吗?
运维功能:
首先,BAT在运维上的分工更加细化。通常,系统、数据库和应用运维是完全分离的。因此,它可能更侧重于功能,当然涉及的范围肯定会很窄。
在工作职能方面,运维主要围绕可用性、效率提升和成本控制三个主要方面,与公司和研发目标密切相关。运维所做的大部分工作都是基于这三个目标。拆卸。
在技术改进方面,主要是以项目的形式,利用对服务的理解和技术方案来解决常见问题。
技术工作:
以服务可用性为例。这不仅仅是处理警报。 *** 作时要小心。就像编写一些自动化工具一样简单。
在工作方式上:
严格按照既定计划安排工作、审查、总结。分工的实施是否有明确的规则,什么时间维度准确到季度?月?星期?天?我多久回顾一次?
结合这些方面,BAT运维的同学才有可能实现快速的技术提升。这是我所看到的。
最后说一下运维方向:
为了在运维方面有一个光明的未来,需要几个要素:
至少是已经发展起来并具有一定机器规模的业务。没有必要在这里击球,但选择适合您的。
很多人不喜欢处理问题,然后只想着做高大上的事情。我不想告诉你这个结果,但它没有接地,他们制作的东西没有使用,等等。
所以我觉得运维架构师一定是一个懂业务、熟悉业务、非常熟悉的人。我身边也遇到过这样的人。他们级别很高,通常不处理任何问题,但在关键时刻(例如出现问题时),他可以快速找到关键点并解决它们,有些细节甚至比您还要多。明白了,不得不佩服。运维一定是这样的人!
就算每天重复上线、处理故障问题、响应需求、开发维护脚本,也无所谓。关键是你有没有从你做过的问题中看到业务和运维中的痛点,并使用现有的。技术方案,处理解决!
有很多问题,并不是说解决了很多问题就是一个伟大的人。问题的关键在于如何解决问题,同时体现你的整体视角和技术能力。
举个最简单的例子,一台机器的磁盘快满了。这一定是一个特别小的问题。运维同学应该经常遇到。
如果你只检查磁盘使用情况,然后删除数据或调整删除磁盘的脚本,那是最糟糕的文件;检查磁盘使用情况,确认是单机还是批处理机有问题,为什么此时报告,确认清楚可以解决,这是一个更高的层次;我查看了磁盘占用,彻底发现了磁盘增长的原因,但发现磁盘增长是不可控的,现有的数据删除方法无法避免报警。那么有没有办法保证重要数据正常保留时磁盘不会报警呢?然后用技术方案解决,这是更高的层次。 有很多这样的例子。
你会发现运维其实就是利用你对系统、网络、硬件、规格、服务的熟悉,结合专业知识,用技术方案解决一系列研发测试无法解决或无法解决的常见问题。单独解决。并且可以形成工具、平台、框架,最终为运维部门甚至公司创造价值。这是一个很棒的 *** 作和维护。
所以还是同一句话:没有技术含量低的岗位,全看你怎么做。
随着时代的发展,我们现在使用的任何技术,很多事情都可以通过云计算解决,也有相应的产品和方案来解决,云计算也对运维产生了一定的影响。新的发展趋势由此而来。
第一个是从IOE到开源X86。其实去IOE也有一段时间了,为什么要去IOE? 2008年,全网印象比较深刻。当时,安全已逐渐上升到国家层面。此外,中国本土环境也日新月异。国产化需求和自主研发能力越来越强。一个强大的内部基因被定位。此外,还考虑到无论是国家层面还是企业层面,各行业都希望灵活控制结构的能力。这也是这个行业本地化的需求,这也是去IOE的第二个理由。从长远来看,IOE架构和非IOE架构会长期共存,因为技术系统的升级不是一两天就能解决的,尤其是一些核心数据库、核心应用、核心系统的核心系统。当年经常部署在IOE框架下。
第二个是运维自动化和智能化。这个已经提了好几年了,从接触实践到现在大概有五六年了,现在还在提。事实上,很多行业一直在迭代优化运维的自动化和智能化。它确实可以为我们的运维带来很多优势和优势。
第三个是双态IT运维。在传统向互联网和移动转型的过程中,一方面为了保证现有业务的运营,另一方面为了适应这种新的IT技术的变化。
第四个是研发与运营的融合,即DevOps。 DevOps 在过去的两三年里已经渗透到了千家万户。其核心理念包括精益管理、敏捷等理论,通过持续交付、持续集成工具链,以及一些轻量级的IT服务管理。基于这些概念和工具,形成了从研发到运营的全流程体系。IT运维效率更高,迭代更快,反馈更快,更好地满足内部业务需求和用户需求。这也是研发运营一体化理念的价值所在。
第五个是整合云资源,提供一个更大的平台来支撑大数据、AI智能、运维等一切各行各业 这也是互联场景的一大趋势。这对运维来说既是挑战,也是机遇。为什么?因为这个行业在不断变化,技术也在不断变化,只要顺应大势而变,我们就站在时代的潮流中。
如果我们在之前的运维理念上还是保守的,不上云,不摸云,那你肯定被淘汰了,因为我十年前很难部署一个数据库,各种配置,各种调用,现在就可以直接打开一个RDS,进行优化,集群就完成了。在效率和稳定性上,分分钟达到我们传统的运维水平,这也是我们运维要面对的大势所趋。
基于此,云原生的概念在过去一两年比较流行。事实上,它是对现有云架构系统技术栈进行更深更广的整合,采用Devops、微服务、敏捷的概念,采用类似中国大陆和台湾的概念或者开放的概念来构建和重塑技术体系,更好地支持新业务的快速迭代开发,这其实和DevOps的概念有很多相似之处。
第六个是数字化。这也是近两年在中国的热门话题。事实上,它也是。我们曾经建设过各种各样的信息化,建设了很多系统和平台,但往往也搭建了很多障碍,导致我们很多信息系统不可用,业务碎片化。组织也支离破碎。数字化要解决的问题是通过底层的数据和算法构建新的服务,打通我们的业务。这就是数字化要解决的问题。
大体上讲了这么多趋势,当然也有一些,大体是一样的。以前是用硬件,现在是软件自动定义;过去用服务器,现在用云,我们现在用云,未来可能更混合。云端,云端整合;以前是技术运维,现在从事技术运维的整合;另外,同样重要的是,无论我们现在做什么,网络空间安全现在都提升到了国家层面,在企业里面也提供了企业的最高点,这个网络安全是IT的一个标准。
IT服务是大概念,可分为建设和运维(运行维护)两部分。对项目建设来说,容易被大众接受。
IT运维的重要性:
就是通过结构化的综合布线系统和计算机网络技术,将各个分离的设备(如个人电脑)、功能和信息等集成到相互关联的、统一和协调的系统之中,使资源达到充分共享,实现集中、高效、便利的管理。系统集成实现的关键在于解决系统之间的互连和互 *** 作性问题,它是多厂商、多协议和面向各种应用的体系结构,需要解决各类设备、子系统间的接口、协议、系统平台、应用软件等与子系统、建筑环境、施工配合、组织管理和人员配备相关的面向集成的问题。
IT运维的必要性:
第一,所有的电子产品(硬件设备)都有寿命问题,而信息系统包含大量不同种类、不同功能、不同性能的设备,每种设备的寿命各不相同,长的5—10年、短的3—5年,对信息系统而言,几乎在项目建设完成后即需进入项目运维期,而对某些建设周期需要很多年的信息系统来说,在项目建设后期,便要对前期建设的项目进行运维。这里还没有考虑设备发生故障的情况,而设备发生故障是一定的,只是发生的概率大小而已。对单台设备来说,也许几年不发生一次故障,但对包含数百、数千甚至数万台(套)设备的信息系统而言,故障发生的概率要高很多。
第二,硬件设备更换、升级导致被动运维。由于硬件寿命及技术进步(摩尔定律:当价格不变时,集成电路上可容纳的晶体管数目,约每隔18个月便会增加一倍,性能也将提升一倍。这一定律揭示了信息技术进步的速度),硬件产品会不断升级,导致原来使用的各种软件需被动升级,而系统软件升级也会导致应用软件必须进行升级改造以适应新环境。
第三,系统软件、工具软件由于自身存在各种缺陷(业内称为Bug,现在各种软件都极为庞大、复杂,要在编程中完全杜绝Bug几乎不可能),需要主动修正和完善。
第四,除上面所说的由于运行环境改变而需要被动升级应用软件外,还有就是自己主动升级。主要是随着时间的推移,对系统功能有新要求,或者是政策变化,需要系统功能跟着改变,所有这些问题都需要对系统进行运维,或者说需要升级、改造,不断完善。
第五,应用软件同系统软件一样,其本身也存在各种缺陷需修正和完善,而且应用软件是直接目的用户,不像硬件和系统软件对用户是“透明”的,是在后台发挥作用,有时仅是使用人员因对使用界面不习惯,都需作修正、完善。
运维开发工程师的职责是:负责日常运维工作;推动及开发高效的自动化运维、管理工具,提升运维工作效率;制定和优化运维解决方案,包括但不限于柔性容灾、智能调度、d性扩容与防攻击;探索、研究新的运维技术方向。
运维开发工程师的任职要求是:1、本科及以上学历,年龄在18周岁以上;2、熟悉常见应用服务的配置和优化;3、能熟练使用常用的监控软件;4、善于分析思考问题,有责任心;5、服从工作安排,身体健康。
IT运维管理者需要具备以下技术:
一、微软系统
对于Windows的熟悉是最基本的。当然,作为一个运维经理,可不是整天玩个Windows7或XP就可以交差的。得掌握微软Active Directory及其上层各种服务和应用的搭建。一般常用的有ISA、Exchange、SQL Server。随着Windows 2008的大放异彩,Hyper-V又成了微软工程师不得不掌握的重型武器。
二、Linux/BSD系统
虽然Ubuntu现在很火,但是在公司里使用的大多还都是Redhat系列和Suse系列。得熟悉DNS、NIS、Apache、SMB、DHCP、Sendmail、FTP、MySQL这些常规服务。如果公司的IT业务大规模对外,还得学会LVS或Nginx等负载均衡技术。
三、编程开发
混Windows系统的自觉一点学好Powershell吧。要是说前几年还得看看VBscript的话,未来就都是Powershell的天下了。
“运维”是指:门户网站应用运维,与其它运维如网络、系统的区别还是很大的;然后我们再对大型网站与小型网站进行范围定义,此定义主要从运维复杂性角度考虑,如网站规范、知名度、服务器量级、pv量(PageView)等考虑,其它因素不是重点;因此,我们先定义服务器规模大于1000台,pv每天至少上千万(至少国内排名前20),如sina、alibaba、sohu、baidu、网易等等;其它小型网站可能没有真正意义上的运维工程师,这与网站规范不够和成本因素有关,更多的是集合网络、系统、开发工作于一身的“复合性人才”,就如本版有些同僚将公司的合同采购都纳入了运维职责范围,还有如IDC网络规划也纳入运维职责,这是网络工程师的工作。非常重要一定需要明白:网站应用运维对其它关联工种必须非常了解熟悉:网络运维、系统运维、应用开发、内容。 随着国内软件行业的发展和扩大化,有更多更复杂的系统出现,为了保证系统的稳定运行,需要有更多的运维工程师。维护是软件生命周期中较为重要的一个阶段,当前国内还很少提及运维工程师,很多的工作都是软件开发工程师兼职,在未来,运维工程师应该成为一个专有职业称号。
以上就是关于IT运维管理需要注意什么全部的内容,包括:IT运维管理需要注意什么、IT运维工程师发展前景好吗、企业究竟需要什么样的IT运维等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)