企业IT系统越来越多，网络、设备和产品越来越复杂，业务越来越依赖于稳定可靠的系统运行，公司内部和外部用户对IT部门的支持服务和协调管理也提出了更高的要求。此时IT部门如果缺乏快速有效的协调机制和必要的辅助管理工具，就会出现“救火队式”的混乱局面，其主要表现如下：被动响应式的工作方式。很难及时发现和预见问题的发生。问题出现后，很难快速、准确地找到根本原因，并及时地找到相应的人进行修复和处理。问题找到后，缺乏流程化的故障处理机制。重复、丢失、忘记用户的请求和信息。支持过程总是被打断和干扰。关键人员的工作负载过重。缺乏过程和变化的跟踪记录。 IT支持部门面临不断改进服务和降低成本的压力。资源和人力成本计算工具匮乏。服务请求的响应时间和质量无法衡量。决策基于“我认为”而不是“我知道”。结果造成IT部门整天疲于奔命，却仍被投诉，无法满足服务时效性和稳定性的需求。这种工作模式下的IT资源管理，不仅IT部门吃力不讨好，而且也无法发挥IT系统的整体性能和功能。

自诞生之日起，服务水平管理（Service Level Management，简称SLM）就定位于对IT服务质量的评估、量化与改进。随着ITIL的广泛普及，其弥合IT与业务部门分歧、确保IT服务高效和有序运营的效用逐渐显现。

IT服务水平管理（SLM）应用解读

 “IT与业务融合”是最近几年来IT应用领域持续的讨论热点。但是时至今日，企业中的IT部门和业务部门似乎仍然无法找到一种让双方能够顺畅沟通的方式。长期浸淫于这种错综复杂IT应用氛围中的人士应该深有体会，IT部门和业务部门有着太多“剪不断，理还乱”的关系。要解决“IT与业务融合”的难题，除了IT部门要加快自身“向服务部门转型”的步伐外，与业务部门共同修订IT应用的服务质量标准也是一个关键环节。而这正是SLM及SLA（Service Level Agreement，服务水平协议）诞生的初衷。

 “企业在可接受的成本条件下，就IT服务质量所做出的包括谈判、定义、评估、管理、改进等一系列的管理活动”是SLM原始的定义。而随着ITIL最佳实践框架的日趋成熟，SLM的内容和价值都得到了进一步地演进。在ITIL v2版本中，SLM流程实际包含了对服务目录和服务水平的管理，对服务目录方面的描述较为薄弱。而在2007年5月发布的ITIL v3最新版本中，围绕SLM的最大变化就是，新增了对服务目录管理流程的描述。

 SLM应用依托于一套由资源模型支撑的服务模型。在ITIL v3中，服务目录管理的目标为，主要对所有已导入或即将导入运行环境中的服务的相关信息进行维护。其中服务目录由两方面的内容组成，即业务服务目录和技术服务目录，两者共同构成了端到端的服务内容。

 其中，业务服务目录包含所有提供给客户的IT服务细节，以及业务单元和业务流程依赖IT服务的关系，这就是服务管理的客户视角；而技术服务目录则包含所有提供给客户的IT服务细节，以及支持服务、共享服务、必要的组件和配置项支持与业务服务的关系。技术服务是业务服务目录的支撑，并非客户视角的组成部分。

客户领导日理万机，时间非常宝贵，所以IT部门对他们提供的服务，更加不能出现差错。但是，往往IT部门都是被动的解决领导遇到的IT问题，都是事后领导先发现问题，才硬着头皮解决。VIP服务会监控领导使用VPN服务的反应时间，一旦反应时间不能满足SLA的定义，系统管理员会第一时间知道，并且能主动解决领导的问题。

SLM，度量运维效率，降低服务风险

IT部门也能定期通过评审对其内部服务进行内部的评审，并能对SLM做出未来的规划和优化, 可根据设定的评审周期，自动在每周一/每月1日/每三个月的1日触发SLA评审报告，同时可支持在服务台事故处理过程中，按照服务目录中的定义对事故处理的不同阶段进行自动统计，记录事故处理阶段的SLA执行进度，并以不同颜色的进度条提醒运维人员事故处理的优先级。

     按照指定的周期，对不同类别、不同级别、不同业务服务等的事故请求，按照与业务用户服务保障的合同细节及SLA时限，统计运维执行并实现自动化报告，辅助IT部门管理者对运维现状的管理控制，以及后续运维的决策。

系统提供了预置的统计图表供用户进行查看，但不支持用户自定义和删除统计图表SLA统计。

SLA目录过期提醒功能：设置制订的SLA，距离结束日期前多少天提醒用户该SLA即将过期。服务台请求SLA将逾期提醒：设置服务台请求的处理时间到达SLA规定时间的百分多少时，视为服务台请求的SLA 将逾期，并在跑马灯中显示提醒信息。 邮件通知：设置当SLA被新建、修改、删除后，系统自动发邮件通知的人员。

何时切入SLM

当IT部门还忙于流程定制、监控体系构建等问题是，SLM部署并不处在企业IT建设的优先序列。而在把这些部分搞定后，IT管理者的注意力自然会转回到SLM身上。所以，SLM进入企业IT环境需要等待一个良好的切入时机。

    这样的等待无疑是需要耐心的，但SLM也并不一定是企业实现ITSM或BSM目标所攻克的最后一个堡垒。根据国外的实施经验，有一部分企业在实际部署时同时购买了服务台和SLM模块，然后再渐进式地部署变更管理、资产管理等模块。这种先对IT事件管理的水平、绩效进行管理，然后再逐步展开的SLM实施方式被证实是一条切实可行的路径。

    结合国内应用现状，企业也可以针对不同的业务目标确定SLM实施的不同范围。例如，有的企业先在IT部门开展类似OLA的项目，以此积累部署跨IT和业务部门SLM系统的经验。目前，IT部门对SLM重要作用的认识已经有了显著的提升。虽然碍于业务的多样性、企业组织结构的复杂程度，大多数的企业暂时无法签订正式的SLA，但是IT部门内部还是在积极摸索变通的方法，意图在内部先形成相对成熟的SLM运营机制。

另外，ITIL v3所提出的“服务生命周期”理念使SLM的重要作用进一步凸现。分析SLM流程与其他管理流程的关系和数据流向，我们发现SLM流程与配置管理、事件管理、变更管理、发布管理、可用性管理等流程模块存在紧密的互动，并处在整个流程框架的核心位置。由此可见，SLM将是企业实现ITSM或BSM的不可或缺的实施环节。因此，在企业明确IT应用服务化、量化IT服务质量的目标后，SLM便应该被纳入企业的IT系统建设规划之中。

总之，业务级别管理逐渐使企业从被动支持模式变为主动支持模式，在这种模式下，网络可用性和业务级别由业务要求来确定，而不是由最近的一系列故障来确定。该进程有助于建立一个不断提高业务级别的环境，并提高企业的竞争力。另外，业务级别管理还是主动网络管理的最重要组成部分。因此，我们极力建议在任何网络规划和设计过程中都采用业务级别管理，并在最新定义的网络结构中采用。这可以使企业在开始阶段就能正确地执行解决方案，并使故障时间和重复工作量降到最低。

摩卡做得更多

摩卡软件十年为通信，金融等行业的运维经验更加懂你的需求。