企业运维的自我定位

     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配置信息库，另一方面要将专家的经验直接固化到运维工具中，运维专家系统将是今后运维工具发展的另一个趋势。