【IT168 厂商动态】IT架构和IT业务的技术发展是运维发展的源动力和推手，所以运维的发展总是稍微滞后于IT技术进步的脚步。随着IT大集中、SDN、云计算、大数据等技术的不断涌现， IT资源架构的复杂度不断增加和IT资源规模的不断扩大进一步增加了运维的复杂度和难度，IT的可运维性往往在第一轮建设后成为用户关注的焦点，运维问题也逐步成为IT主管不断关注的首要问题。

　　从早期的纯手工运维到后来依赖网管工具、流程工具、 报表工具为主的工具化运维，再到将工具关联或融合后的平台运维，以及现在流行的智能和自动化运维系统，运维领域经历一次又一次技术的变革。新工具的产生并不意味旧的工具被彻底淘汰，而是不同工具并存一起解决实际运维问题。新的工具进一步解放了运维的生产力。

　　在云时代，如何选择合适的运维模式，如何选择合适的运维工具，以及如何设置合理的组织架构和管理制度都是IT主管需要重新考虑的问题。

　　面对运维的多维度属性，企业如何自我定位

　　在讨论运维时，人们往往只会考虑技术本身，而忽略场景的差异性，单纯追求技术领先性和上层建筑，往往只会事倍功半，不容易达成预期效果。实际上运维在不同场景中的差异是非常大的，一味的求新、求快，未必能达到良好的运维效果。基于这几年在运维领域内的理解，我总结出以下几个影响运维工具选择的属性，分别为行业属性，成熟度属性，规模属性和位置属性。

　　运维的行业属性

　　首先说行业属性，不同行业由于业务特点不同，关注内容和运维模式有很大的差异。以互联网为例，互联网业务发布快，更新快，服务器数量多，研发能力强，往往一周内有几个甚至几十新业务发布，同时有几十或更多的新版本发布。基于ITIL的变更和发布流程虽然考虑周全、过程严谨，但是节奏缓慢，周期较长。在互联网业务快速更迭的行业背景下，传统的变更发布流程容易让互联网企业丧失产品的市场机会窗，所以互联网运维会选择自动化和自运维等高效的运维模式，要作自动化必须建立准确的CMDB，要想高效必须推行敏捷开发、DevOps、灰度发布和开源结合的模式。所以互联网的运维模式主要关注点是运维效率。

　　政府运维以核心业务保障为主，新业务增速比较缓慢，安全性要求高，注重管理、关注绩效，往往有分级管理要求，同时也关注数据潜在价值。政府自身研发能力有限，运维主要依赖于商业产品，但是分散的管理工具无法提升运维的效果和效率。所以政府选择运维产品时，更加注重一体化运维、智能故障定位、业务级资源监控和安全运维，传统的ITIL流程对政府的管理具有相当的指导作用，也是政府比较关注运维选项。

　　大型企业与政府的特性非常类似，除了部分大企业IT基础设施规模庞大，有自动化要求外，大型企业对运维的需求与政府基本一致。

　　另一个比较有特点的行业是金融。金融的最核心业务是交易业务，其他业务都是围绕交易业务展开的，所以核心数据库的备份、恢复、演练是金融运维的例行工作。金融的运维规范性也是其他行业中最强的，多数银行在几年前就引入了ITIL流程工具，在运维流程上大行也花费了大力气进行梳理。近几年金融业受到互联网行业的影响，增加了在线支付产品，推动金融向互联网靠近。所以金融行业在选择运维产品时，更加注重交易级监控，自动化和一体化运维。另外大型银行有自己的研发团队，在运维发展路线上大型银行逐步在向互联网靠近，DevOps可能会是大型银行今后的选择。

　　运维的成熟度属性

　　不同行业受到各自业务特点的影响，其运维模式、关注点和工具选择都各有不同，同时影响运维工具选择的是运维的成熟度。这就好比人类社会不能从原始社会直接跳跃到资本主义社会一样，运维成熟度也是制约企业运维发展的关键因素。ITIL有一个核心的方法论是PDCA(Plan计划、Do 执行、Check 检查、 Action 改进)，这个方法论向我们阐述了运维的简单原则就是循序渐进、螺旋式上升的模式。不同的运维成熟度决定着运维所处不同阶段，也决定了不同时期的用户应该重点关注的内容。运维时选择脱离实际处境的激进作法往往只会起到拔苗助长的效果，最后还要推倒重来，反而得不偿失。很多用户以前并没有注重这一客观规律，在没有作好监控的情况下，直接建设运维流程，从而造成运维流程和监控脱节，流程给予运维管理员的帮助非常有限，沦落成为走单工具，时间长了往往用不起来。另一个经常犯的错误就是CMDB的建设中过度的追求完美，没有和当前的监控能力结合，没有利用自动化手段简化CMDB的维护工作量，反而在CMDB的设计上过分追求精细化，以至于CMDB的维护成本过高，甚至超过了其实际使用价值，造成最终CMDB项目的破产。经过多年的探索，我建议将运维简单分为4个步骤：

　　第一步，作好一体化监控，将所有IT资源统一监控起来;

　　第二步，基于一体化监控，建设CMDB;

　　第三步，基于一体化监控和自动化CMDB建设ITIL运维流程体系;

　　第四步，基于ITIL进行改进，实现更多的自动化、智能化。

　　基于上述步骤运维管理员就可以脚踏实地的将运维成熟度一步一步推向前进。

　　运维的另一个成熟度是指人员的成熟度模型。这里面涉及运维人员的技能成熟度、组织流程成熟度和开发能力成熟度。技能成熟度包括运维人员对网络、计算、存储、虚拟化以及业务的熟悉程度和问题处理能力。技能成熟度越高，问题处理和反应速度越快，反之运维技能不足的管理员会延长故障恢复时间。所以如何让运维减少对个人的技能和知识的依赖也是对运维工具的重要考量。传统的基于知识库的建设体系，在实际操作中效果并不理想。要想根本解决这个问题，一方面要建立起来准确的CMDB配置信息库，另一方面要将专家的经验直接固化到运维工具中，运维专家系统将是今后运维工具发展的另一个趋势。

　　当今开源软件的数量和成熟度都越来越高，如果能够充分利用开源软件自己开发，无论从业务维度还是运维维度都是非常好的选择，但是这也同时提高了对运维人员的开发能力成熟度的要求。开发能力的成熟度，体现了运维人员的需求分析能力、框架设计能力、编码能力、开源软件熟悉程度、业务背景知识和对软件开发过程的理解能力。DevOps在运维界的流行说明了开发和运维的逐步融合，这无疑也是今后运维发展的趋势之一，然而在没有充分开发人力和敏捷过程储备的前提下，贸然选择DevOps(开发即运维)模式，有可能会面临巨大的风险。

　　所以企业要看清自己所处的运维阶段、运维人员成熟度，选择更加务实的运维策略，寻求逐步改进，水到渠成的方式。

　　运维的规模属性

　　另一个需要关注的是规模属性，这里的规模包含设备(服务器和网络)、业务规模和运维人员规模。用户有50台服务器还是200台服务器、1000台服务器或上万台服务器对于运维来讲区别是很明显的。当设备数量比较少时，很多事件通过人工管理就可以了，但是随着被管理的设备数量的增加，运维工作量会直线上升，这时运维难度实际成指数级上升，再依赖人工运维几乎成为不可能完成的任务。规模运维必须依赖自动化监控工具、自动化配置工具、自动化部署工具和自动化流程工具来辅助实施。当运维规模进一步上升，传统运维就会演变成海量运维。海量运维不单纯是运维工具的变化，海量运维带来技术价值观的改变，技术手段的改变以及运营意识的改变，影响到深度运维方法论的变革。海量运维的变化归纳起来是分层(服务等级分层)、基于业务的合理取舍(CAP理论)、敏捷开发和务实运维概念的整合。下图总结了海量运维中的一些指导原则：

　　图1.海量运维指导原则

　　另一个影响运维的是运维人员的规模，如果运维人员在8个以内，就要慎重考虑是否需要复杂的运维流程建设。流程的设置解决了运维事件的闭环跟踪、责任认定和规范性等问题，但是如果企业运维人数很少，建立复杂的流程反而会降低运维的效率增加运维成本。但是如果企业运维人员数量超过20个，运维过程的规范性管理就重要起来，同时在运维人员的绩效管理方面也需要运维流程辅助，这时运维流程的重要性就凸显出来。但是随着时代的发展，自动化和智能化技术逐步普及，运维流程的发展趋势是越来越轻量化，ITIL完整流程体系的建设今后会越来越少。

　　运维的位置属性

　　最后再探讨一下运维的位置属性，这里的位置包含网络位置和逻辑位置。被运维对象所处网络位置大致可以分为接入网、广域网和数据中心。由于所处网络位置不同，这三部分的运维差异性非常大。前面讨论的大部分内容谈论的都是数据中心的运维，下面主要讲讲接入网运维。接入网运维涉及终端(类型、系统)、接入方式(无线、有线)、身份认证等方面，由于终端类型复杂，接入人员水平参差不齐，接入网运维的复杂度也比较高，运维人员不仅需要具备多方面的运维知识，还需要有足够的耐心，运维经验对接入网运维也非常关键。对于接入网运维固化的运维经验的专家系统是今后发展的方向。广域网运维相对要简单些，对于多数企业而言，广域网一般是租用为主，所以广域网运维主要是监控线路的时延、丢包、抖动和占用容量。

　　运维的另一位置属性是运维的逻辑位置，随着云计算的普及，运维人员出现了分化，一部分是云建设方，另一部分是云的租户。云建设方的特点有点类似传统的运营商，重点关注的是资源(物理的和虚拟资源)的运行状况和利用率。云建设方同时需要考虑数据中心的成本控制以及风险控制。如何利用虚拟化和容器提升整体的资源利用率同时，保证业务风险在可控的范围内，以及如何及时回收由于云化带来的无效资源浪费的问题，都是云建设人员的重要考量。所以对于云建设人员而言，集群容量管理，数据中心容量，机房容量管理等多维度的容量管理在云运维中成为必备的需求。

　　云租户没有资源的管理权，只有资源的使用权，所以租户更关注的是自己业务的运行情况和资源的占用容量信息。云租户负责运维操作系统以上的内容，关注重点是应用和业务的运行情况和资源的利用率。如何将众多的应用层基础监控数据规整成简单、直观的监测仪表盘，是租户运维工具的重要考量。另一方面租户管理员需要了解业务的资源占用情况和趋势，在必要时业务资源能否在成本可控的情况下得到及时扩展也是租户管理员关注的问题，所以业务容量管理对租户管理员而言也非常关键。

　　当然还有相当多企业，没有租户的概念或者没有明确云建设方和云租户的地位，所有的运维工作由统一团队负责。这时云融合运维团队要兼顾上述两者的职责，既对业务负责又对资源和成本负责。

　　前面介绍了运维的行业属性、成熟度属性、规模属性和位置属性，企业运维主管只有明确自身所处的位置、阶段才能确定自身运维的发展思路，跳跃式发展可能会付出额外的代价。运维体系正象自然界的生命一样在不断进化，长远来看，今后的数据中心一定是自运维的体系。但是要达成还需要很多的路要走，除了运维本身技术、工具的发展外也依赖于其他IT技术的支撑。希望读者看完本篇文章后能够向后迈好坚实的一步。