分类： 系统运维
2009-06-29 16:47:06
网管≠运维，这个公式的成立是因为网管只是运维的基础，更重要的是通过有效的故障跟踪和故障管理的手段不断提高IT服务质量和用户满意度。
传统网管体系的瓶颈
网管，这个词也许正和他的字面意思一样——网络管理，基于网络拓扑而发展网络拓扑，也是这么多年以来人们对网管的普遍认识，现代IT体系越来越复杂，单从网络上来进行管理，越来越显得心有余而力不足了，所以，慢慢出现了主机监控、应用平台监控等等来满足不同关注点的运维人员的需求，但是，却由于IT运维业务划分的原因导致网络、主机、应用等区域各自为政，加长了故障分析和处理的时间，同时也形成了管理孤岛，投资与回报不能形成正比，不能有效的整合起来贯穿于网络、主机、应用之间，也就不能做到真正意义上的故障初步分析和判断，这是目前的现状，也是监控方面的瓶颈之一。
如果说网管系统的基本关注点，一直以来的做法都是基于IT资源的，但通常面对大量的不同种类的IT资源，管理员并不能知道某台设备的故障对IT部门来说意味着什么，也就有可能出现多个机器出现故障后失去了对紧急优先处理的判断，延误了处理时间带来的可能就是更大的用户投诉量，所以，如果换一种出发点，以业务应用系统作为基本关注点，知道哪些范围的用户使用哪个业务系统，再通过这个关系下钻到这个业务系统包含哪些IT资源，这样一来通过最直观的仪表盘方式的展现就可以知道IT与业务的关系了，对事故处理上也会具有很大的辅助分析效果和紧急优先处理的判断，来降低用户投诉，但目前的网管系统并不具备这一点，也是监控方面的瓶颈之二。
其实作为监控来讲，很早之前没有自动化监控手段的时候就有些技术工程师自己写一些监测脚本来进行IT资源健康状态的监视，只有写这个脚本的工程师自己才知道怎么去使用，为了具有通用性，网管系统把这些内容以文字的方式发送给管理员，由于文字的形式看起来不太直观，所以出现了图形化的展现，说了这么多无非也就是人机交互方式的演变，作为监控系统来讲，人机交互显得更加重要，因为更多应用平台变得越来越复杂，如果不是非常专业的技术人员，相信即使报警出来之后，管理员面对报警信息也会觉得无从下手，同时需要看到的现状是，绝大多数管理员并不能做到对每种应用平台都非常专业，所以，如果有一套可视化的管理界面，实时动态的展现复杂IT资源的健康状态，同时将重要组件都放在醒目位置配以帮助信息，告诉管理员每个组件的作用和超标后可能出现的现象，相信就会打开一条人与IT资源信息交互的通道，而这是目前的网管系统所不具备的，也是监控方面的瓶颈之三。
故障是不可能完全避免的，那么作为网管系统而言，不仅需要及时的预警和报警，最重要的还有两点，一个是快速的故障恢复，一个是故障处理，快速的故障恢复指的是当发生宕机之后，可以有一种行为接口，按照管理员自己的意向收集日志、重启服务等操作，这种方式可以称为是监控到对应级别的事件后网管系统自身的一个紧急Action执行机制；作为故障处理来讲，举个例子，当用户电话告诉管理员说ERP系统访问不了的话，管理员做得第一件事情是什么？当然是先验证一下故障现象是否存在，然后判断一下外围可能存在的问题，比如端口、IP等等之类，接下来才会关注到具体的故障点的深层次指标，所以如果网管系统可以具备这两种机制，那么对IT服务的正常运行和故障分析来讲就是一个大大的利好了，但目前的网管系统并不具备这一点，所以，这也是监控方面的瓶颈之四。
监控系统的作用是什么，可能大家会说是报警，对，传统的网管系统其实做的事情只有一个，就是监控到异常的时候报警，但其实看到报警之后的现实情况是，网管系统的工作结束了，管理员的工作开始了，分析原因、处理故障等等，所以，以报警作为终点就是网管系统另外一个瓶颈，因为这只是运维工作的起点，没有一种好的方式可以做到在故障分析和处理时提供处理参考依据，也没有一种有效的故障跟踪和故障管理的手段，当然，如果我们的目的仅限于监控的话，那么效果既可以达到，无非就是每次报警后都有专门的人去处理，每个类似的故障都花费很大量的时间，并且对人的依赖性很强，故障处理经验在人员调动后随即消失，但这样对IT部门的人力来讲是一种浪费，也不利于IT部门长远的发展，所以我们讲，网管监控只是第一步，如果说瓶颈的话，那么网管本身就是一个瓶颈，突破这个瓶颈的方法就是运维，来考虑报警之后的事情。
传统运维体系的瓶颈
运维体系的建立大多基于ITIL框架进行设计，遗憾的是ITIL提供给我们的只是一个框架和目标，并没有提供给我们实施步骤，所以在国内的ITIL实施方面面临着很大的问题，国外的东西能否拿过来直接用呢？目标可以，但过程不行，毕竟国内和国外的国情、运维方式、使用习惯等各方面都存在着很大的差距，套用一句老话，“理论结合实践”，理论指ITIL的目标，实践当然不能直接拿过来，需要结合国内企业或机构内历史既有的运维经验和运维状况，所以，运维体系的建立，国外厂家帮不上，国内多数厂家又没有充足的企业实际运维经验积累，缺少实际可用的实施方法论，也就造成了运维体系建立的瓶颈之一。
运维系统的建立和推动都是一件比较困难的事情，规范事故处理阶段需要流程的辅助，这里面最直接体现的就是人员组织架构和流程灵活定义方面的问题，现阶段推出的一些运维系统通常要么需要更改用户方面的人员组织结构来满足运维流程的需要，要么在流程的个性调整上需要更改系统代码来实现，往往需要花费很大的精力，同时这些事情的推动又会涉及到多个部门的协调，实施起来难上加难，也就造成了运维体系建立的瓶颈之二。
在运维体系中存在诸多的重要阶段，比如CMDB的建立、服务台统一故障处理出入口的建立、问题管理的建立、变更管理的建立、发布管理的建立、知识库的建立、SLM的建立等等，大量的模块需要纳入企业或机构的统一管理，从各个模块的初始化到实际用起来往往是一个长期的过程，关键就在于大多数的运维体系都没有提供向导式的初始化方式和随处可见的帮助提示信息来指引ITIL实施过程中的规范，也就造成了运维体系建立的瓶颈之三。
运维真正可以用的起来，不是流程建立的有多完善，而是怎么可以让事故处理可以做到真正的有据可寻，举个例子来说，一个事故发生了，这类型的事故也许曾经出现过，那是不是可以自动的将这些曾经出现的同类型的案例调出来供运维人员参考？如果这个故障点需要进行变更处理，那是不是可以自动的将这个故障点周围的IT资源依赖关系展现清楚，以避免“拆东墙补西墙”的现象出现，避免解决了一个问题的同时引发新问题的尴尬局面，这些都是目前大多数运维体系做不到的，也就形成了运维体系建立的瓶颈之四。
大家都知道，运维体系的核心是CMDB，而CMDB的建立并不是那么简单的，作为核心来讲，既要保证大量IT数据的自动数据发现，又要可以支持各个运维流程阶段与知识库的紧密连接，还需要保证CMDB数据的统一性和完整性，但目前来看，诸多所谓的运维系统都存在断点，即无法真正的实现把CMDB作为运维核心，失去了运维流程阶段与各个ITIL元素之间的联系，也就失去了真正意义上对故障处理的辅助和规范上的参考，这也就形成了运维体系建立的瓶颈之五。
同时，知识库之外也许可以多一种机制，来实现“一箭双雕”的效果，比如设立自助服务台，将一些常见的客户机问题列入FAQ范围，业务用户通过自助服务台不仅可以多出来一种事故申报的途径，而且如果用户需要咨询的是一些简单问题，那么在自助服务台的FAQ中又可以自行解决这个问题，对IT部门来讲，那就是即拓展了IT服务渠道，又减轻了IT部门人员的工作量，按照常规情况，一个IT支持人员每天接收的常见小问题的数量在全天处理的问题中的比例占30%，如果这30%的工作量都可以通过自助服务台过滤掉，那么省下来的就不仅仅是人工的成本了，这也就形成了目前国内运维体系建立的瓶颈之六。
上面讲到的各个方面都是运维体系建立的重点，在规范事故处理阶段，使用有效的技术手段来提高事故处理辅助方面的同时，也需要量化的数据来体现IT部门的运维效果，比如一天不同类型的事故共处理了多少？有多少个是可以马上解决的，有多少个是升级到问题管理阶段的，等等，这些KPI的统计其实很大程度上可以给IT部门的管理者用以及时了解运维现状，辅助日后的运维规划，度量运维执行的SLA等，这就形成了目前国内运维体系建立的瓶颈之七。
要运维，而不仅仅是网管
网管是一个过渡，现代化复杂且多变的IT体系结构提高了对IT服务的要求，在网管之后，我们更多考虑的已经不仅仅是如何监控，也不仅仅是在监控中如何打破历史的监控断点，而是以监控作为自动化运维的前提，来规范事故的处理阶段，提供最大化的事故处理辅助。事故是难免的，关键还是在报警之后的一系列IT运维管理工作。
选择合适的运维平台
适合企业或机构自身的运维平台，按照自身的IT规模和实际运维情况来选择运维实现的程度。
如果只需要监控，那么在这套体系的建设中至少应该可以打破传统监控断点的约束，让监控资源之间产生必要的关联，来辅助事故的分析，同时，可视化实施动态的人机交互方式是这种规模下的企业或机构必备的，将复杂的IT资源以最简单的方式呈现出来，做到投资回报最大化。
如果需要建立的是完整的运维体系，除了上述基础监控的部分之外，运维体系建设方面的产品选型，需要照顾到实施过程、实施时间、实施难度、实施向导化，真正的让运维体系帮助运维支持人员做到故障处理真正的自动化的有据可查，真正自动化的故障点关联裙带的风险性控制，同时为个性化的流程扩展留下最低成本的可扩展方式，照顾到运维执行KPI的统计，实现运维的规范化流程化自动化，最终提升IT服务质量，获得最大化的用户满意度。
查看完整内容，请点击
