IT运维的管理现状

　信息系统关系着企业的安全连续运行是IT运维管理追求的目标。IT运维管理与IT运维的成本、质量、速度有着很大的关系，当然也与IT系统的安全、连续和可用联系紧密。现今市场状况下，IT外包模式下许多IT运维管理都出现了许多问题，主要包括IT资产管理问题、IT外包管理问题、IT运维成本问题以及IT运维技术问题。it运维常见问题有哪些

1 IT资产管理问题

当不同的IT资产运维被外包后,相对应会增加一部分责任人,无论是对它的维护还是更新升级改造，都会影响到IT资产的价值,同时也会对你IT资产的使用年限和配置信息产生影响，导致发生一定的变化,从而造成物理位置与实际不符、账实不符、安全责任无落脚、人机不符等问题。分散的、动态的IT资产管理是无法提供清晰的结构脉络给相关管理人员和服务人员的。

2 IT外包管理问题

完善的IT外包管理：选择外包商-使用外包商-考核评价外包商-优化外包商。信息技术基础构架库标准体系现在被许多企业采用，这种管理使外包服务过程更加的流程化。然而,它对企业对于外包商的选择、考核、评价优化均未提及。因此,就算流程管理做好了,IT运维管理外包还是没有到位。

3 IT运维成本问题

招标或者议标易确定外包价格,但是很难界定价格的合理性,也无法确定价格涵盖的服务项目。当甲方遇到突发状况时,部分服务商往往不能快速响应，可能服务人员不在本地,还有超出服务范围要追加费用这种情况的出现。有的时候公司付出高,回报低,影响到公司的未来生存发展，无法保证长期稳定的良好服务。如何衡量服务成本来确定服务价格是IT运维管理外包中的主要问题之一。

4 IT运维技术问题

针对不同的IT运维服务对象应采取相对应的技术方法。不能仅仅依靠对技术人员进行管理从而达到管理技术的目的。这样只会制约IT运维服务发展速度和质量。

事实上如何使IT运维管理外包安全稳定运行是一个既简单又复杂的问题，但是只要注意IT外包过程中所出现的一系列问题并寻找有效的解决办法，就可以保证企业的正常运行发展。

在互联网行业，运维一直是一个被深深误解的位置，以至于很多人认为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运维同时成为了企业效率的加速。同时，计算机硬件系统和软件系统的运维已成为了各行各业单位，尤其是信息服务部门普遍头痛的事情。本文以下内容总结几个头痛的主要因子，拿出来供大家参考指导，并接下来的系列课题中会对针对这些现状提出改进措施 。

现状一：IT运维人员成本偏高

据专业调查，大多数CIO表示最关心的是IT运维成本过高。原因是在过去的5年中,很多企业都实施了很多IT系统,使得IT运行越来越复杂,也越来越难管理。同时，其中有50%的受访CIO认为IT运维成本过高的一个原因是IT运维的自动化做得还不够好,依靠手工流程来管理,不但使到运维效率不高,而且人力成本更是花费惊人。

同时，另一家国际知名调查机构Gartner调查发现,在IT运维成本中,源自技术或产品(包括硬件、软件、网络等)成本其实只占20%,而流程维护成本占40%,运维人员成本占40%。流程维护成本包括日常维护、变更管理、测试成本等;人员成本包括训练、教育、人员流失、招聘成本等。

从图中，我们可以看出， “流程维护”类和“运维人员”两者都与软性方面的成本相关非常紧密。而且三者的关系可以用下图来表示：

备注：C类成本的大小很大程度取决于B和D类。

现状二：处在“救火式”的IT运维控制

国内在IT运维过程中,IT员工大多数只是处在被动低效率手工救火的状态,只有当事件已经发生并已造成业务影响时才能发现和着手处理。这种被动“救火”会导致：①IT运维人员终日忙碌，IT运维人员日常大部分时间和精力是处理一些简单重复的问题;②IT运维本身质量很难提高;③再加上故障预警机制的不完善,往往是故障发生后或报警后才会进行处理,不但事倍功半而且故障还常常会出现恶性连锁反应;④IT部门和业务部门对IT运维的服务满意度都不高。

现状三：简单的自动化程度起了“反作用”

尽管IT运维管理的技术在不断进步,但实际上很多IT运维人员并没有真正解脱出来，主要原因是自动化不高而导致的。技术虽然能够获取IT设备、服务器、网络流量,甚至数据库的警告信息,但成千上万条警告信息堆积在一起根本没法判断问题的根源在哪里。还有,许多企业的更新管理绝大多数工作都是手工 *** 作的。即使一个简单的系统变更或更新往往都需要运维人员逐一登录每台设备进行手工变更,当设备数量达至成百上千时,其工作量之大可想而知。而这样的变更和检查 *** 作在IT运维中往往每天都在进行,占用了大量的运维资源。因此,实现运维管理工作的自动化对企业来说已迫在眉睫。

就如图中一样，所有信息(杂乱)都从各个地方被收集到了这个圆圈(容量不变)里面，信息进去后不能主动流出来。可能会出现的情况：这个圆圈容器装满后会爆破，或者是溢出来;圆圈的运行速度会慢慢降下来，从而导致信息输入的速度也会变慢。

现状四：本是同家兄弟，却不经常来往

这个问题主要是发生在拥有许多子公司的企业，每个子公司的系统都是独立的，下面主要以国内银行业为例。以前国内的银行业没有搞集中建设，每家银行的各个地方分行都单独建设和维护自己的核心业务系统，都各自配备开发人员和维护人员。

同时在运行维护方面，对故障的解决，完全依靠运行维护部门的工程师的上门服务。不管问题大小，工程师都要来回去现场解决。遇到一些技术难度大的问题，如果工程师的水平高，处理起来就快;如果水平低，甚至花上几个小时，可能也解决不了。

虽然国内银行业的IT运行维护管理水平，有点接近国外80年代末90年代初银行业的水平，银行IT结构上都采用了大集中模式。从硬件设备上来看，国内银行不比别人差，甚至还有些领先，但IT运维管理还没达到国外当时的水平，尤其是呼叫中心、客户服务方面。”

结束语

从上面三个现状来看，主要是有关软性方面的。的确如此，国内借着近十几年高速发展，硬件方面的发展取得了重大进步，某些方面的水平甚至是超过了国外的水平，并且IT硬件的生产厂商也是出现了很多与国外厂商同等秀舞的水平，如华为、中兴等。但是往往是硬件易学，知识技巧难寻。这不仅与国内教育环境有关外，还与知识经验的继承有关。

管理要动态匹配业务需求

IT部门还会经常联合HR、法务等部门一起做跨部门的沟通，面对的对象是各部门的管理层，让他们理解企业的IT策略。

说到北京it外包，大家首先映入脑海的就是比较权威、信息比较全面的专业的IT运维网站。在中国北京it外包里，你可以浏览业内最新的it运维相关信息，也可以看到国家it行业发展的最新动向，除了这些，还有一些it运维企业在运维过程中总结出来的经验供大家学习和分享。在这些对我们来说非常宝贵的经验里，我们可以运用它解决我们常见的it运维问题，也可以学习到一些知识，比如对于it运维来说，什么样的it运维服务才是合格的。

　在北京it外包，我们找到了一些关于合格的it运维服务的描述。首先，北京it外包告诉我们，常见的一些it运维服务包括it基础设施运行维护、it应用系统运行维护、it安全管理、网络管理和综合管理等相关的服务。要想让这些服务达到合格的标准，就必须做到能够让企业所使用的软件产品保持低风险、高质量的运行，这就要求it运维服务要有完善的检修设施以及监控机制，监控的范围既包括对硬件的监控和检查，还包括对软件的监控和检查，比如加强对脚本、软件运行状况、cpu使用率等的监控检查力度。

其次，通过浏览北京it外包的其他相关信息，我们了解到，想要做到合格的it运维服务也应该针对不同的软件系统制定不同的应用系统服务方案，我们在企业中常见的应用系统包括员工管理系统、政府企业管理系统、城市信息关系系统等等应用系统。不同的系统面向不同的用户，因此保证这些系统的良好运行对用户数据的管理以及系统相关的运行机制的管理都是相当重要的。

想要做到合格的it运维服务是非常难得，除了要有专业的知识积累，更重要的就是专业技术，这也是目前很多企业最看重的一点，毕竟运维在整个企业系统中的作用是相当重要的，可以说会直接影响人员办公效率。目前很多企业在it运维这块比较倾向外包模式，这对于it运维厂商来说是机遇也是挑战，it运维厂商在专注自身技术的同时，更应该与时俱进，多多关注北京it外包最新消息。

以上就是关于it运维常见问题有哪些全部的内容，包括:it运维常见问题有哪些、运维真的是整个IT行业技术含量最低的岗位吗、IT运维的管理现状等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！