XXX运维方案
1.3.3.2 IT运维体系的建立
ITIL提供了一个概念化、模块化的优秀框架，与其说是解决方案，不如说它更象理论。它提出了建立IT服务管理体系时要考虑哪些流程，提到了应该做哪些，好处在哪儿，但并不详细介绍怎样去做，因此它本身不具备实际操作可能性。
我们在长期的运维项目中积累的丰富的经验，根据XXX门户网站的实际情况，对ITIL进行适当选取、适应和扩展：
(1)导入ITIL是一个长期过程，运维运维初期，以“系统日常运行和支持”为主，重点解决服务支持（Service Support）流程，对发生的问题进行维护和处理。在运维后期，运维的服务支持流程步入正轨后，再关注运维服务的长期计划和改进，考虑服务提供（Service Delivery）。
(2)针对XXX门户网站，运维的主要任务是解决发生的问题，对IT基础架构进行基本的配置管理，因此主要实现“服务台”、“事件管理”、“问题管理”和“配置管理”，至于变更管理在实际运维中，暂时没有系统工具支持，放在后期在规范流程，并用信息系统化实现。
(3)由于初期运维工作内容多，系统繁杂，人员少，为提高运维人员解决问题的能力和效率，运维体系扩展加设“知识库”，以提高运维技术的积累、传承、利用。
经过对ITIL体系进行适当选取、适应和扩展，从适合XXX门户网站，适合运维团队完成任务目标为主，我们制定了个性化的运维体系，如下图所示：
第 10 页
XXX运维方案
运维工具监控自动报警监控时间管理运维团队运维体系服务台问题管理反馈知识库配置管理国家质检总局门户网站热线求助报警总局用户使用
图2：IT运维体系架构
个性化的XXX门户网站运维体系设置“服务台”统一接受各种故障受理，包括最终用户直接电话或邮件传来的求助信息和运维监控软件过来的自动报警信息，然后服务台问题分析并归类，力求初步解决用户或系统的故障；不能在线解决的需求问题，启动“事件管理”和“问题管理”流程，运维人员按照既定的流程，在“知识库”和“配置管理”的支持下，解决故障，并把积累的经验知识归入知识库。问题解决后，运维体系反馈于IT系统，促使其更好更稳定运行，并促进其优化和完善。
其中，“知识库”和“配置管理”可以依托运维监控工具实现信息化作业，而“服务台”、“事件管理”和“问题管理”则仍然依照对应的制度人工操作，暂时没有信息化系统辅助运行，可以考虑在后期建设运维平台时优先实现。
所有的事件都应该基于影响度、紧急度和优先级进行分类分级，并提供相应的解决方案和临时方案。
表1：系统运维故障级别定义
故障级别 服务请求时间 第 11 页
响应方式、时间 XXX运维方案
一级故障 7×24 二级故障 7×24 三级故障 7×24 服务台接到服务请求后，即刻响应，服务人员工作时间内马上到达现场，非工作时间1小时内到达，进行现场服务。 服务台接到服务请求后，对于电话未解决故障，15分钟内再次回应，提供电话技术支持，工作时间内服务人员1小时到达现场。 服务台接到服务请求后，30分钟内再次回应，提供电话技术支持，工作时间内服务人员2小时到达现场，或与用户协商 注: 故障级别描述：
一级故障是指系统发生严重故障，业务发生中断，或虽然业务未中断但已经无法保证及时、正确的情况，对用户业务的运行有严重影响。
二级故障是指对于系统发生的非严重故障，业务并未中断，业务仍然及时、正确的情况，但性能有所下降。
三级故障是指系统发生轻微的故障，系统有警告信息等，对系统没有较大影响的故障。
1.3.3.3 系统运维制度建设
在信息化运维中，制度建设是一道必要的保障。信息化不能一蹴而就，在信息化发展到一定阶段，建设重点应该要从系统实施转向以应用运维提升为主，运维质量保障、安全机制变得重要起来，这时除了技术的保障以外，制度保障越显得重要。
对于IT运维团队来说，可从以下几个方面来进行IT运维制度化： （一）转变运维观念，树立规范化意识。树立只有建立制度化的IT运维意识，才能在日常繁杂琐碎的工作中有效的区分任务的优先级，将有限的资源投入到最能满足“客户”需要的工作中。
为保证运维工作，把运维工作和制度化紧紧地捆绑到一起。运维工作很琐碎，关键在于规范而不是创新。只有各级运维技术人员一丝不苟、老老实实按规范做，才能够把事情做好。
（二）建立事件处理流程，强化规范执行力度。首先需要建立故障和事件处理流程，利用表格工具等记录故障及其处理情况，以建立运维日志，并定期回顾从中辨识和发现问题的线索和根源。建立每种事件的规范化处理指南，减少运维操作的随意性，在很大程度上降低故障发生的概率。
第 12 页
XXX运维方案
同时，建立IT运维制度非常重要，但是有了制度还要有人去执行，要强化执行制度比建立制度更重要的观念和意识。
1.3.3.4 运维管理机制建设
“三分建设，七分管理”，XXX公司采用多重管理制度，并加强沟通机制，力求完善建设ITSM中的服务监督体系。
1.3.3.4.1 升级管理机制
升级管理是突发事件管理的重要组成部分。“事件跟踪”将记录从受理用户问题到派单过程中相关人员所做的处理和建议，保证信息的正确传递，记录内容将做为我们向用户提供服务及分析和衡量服务水准的依据。
我们将通过服务系统监控事件的全过程，直至服务结束。当出现的问题在承诺时间内无法有效解决时，“事件跟踪”会自动启用逐级上报升级管理流程，该流程旨在能真正起到督促问题快速有效解决的作用。我们将和用户一起共同制定出适合XXX业务需求的升级流程并指定相应的人员来监督流程的实施。
1.3.3.4.2 报告系统
我们将按XXX信息中心要求定期提供标准报告。 (1)突发事件管理报告
确保用户的电话被接受、解决并记录，服务范畴之外的问题也会转至第三方。突发事件管理着眼于解决问题的快速，解决问题的高质量，确保用户的满意度并达到承诺的服务级别。突发事件的出现和解决方法将体现在定期的服务报告中。
(2)问题管理报告
我们将对重复发生的，主要的突发事件进行问题管理，诊断问题的真正原因。问题管理着眼于获得系统的高可靠，避免问题的再度发生，赢得用户高满意度，达到承诺的服务级别。经常出现及主要的问题，及相应的解决方法将体现在定期的服务报告中。
报告内容包含重点问题分析、潜在服务隐患、优化建议等信息。
1.3.3.4.3 月、季度总结机制
我们每月、每季与XXX信息中心召开总结会，共同讨论前一月或季度的服务
第 13 页
XXX运维方案
执行情况。会议时间建议在该月、季度结束后、下一周或每月10日之前，具体时间可以与XXX信息中心协商确定。会前双方应沟通和确定议程并在会前提供必要的报表和报告。
会议主要回顾从上次会议结束到本次会议前一天，我们所提供的服务的绩效，同时讨论和达成为改善服务必须采取的改进措施和行动步骤。
1.3.3.4.4 客户满意度调查系统
以目前的客户满意度调查表格为蓝本，与客户共同协商适用于客户的调查选项、格式和方法。下表仅供参考，以和用户协商后的调查表为准。
表：运行维护满意度调查表
开始时间 对主机设备使用评价 对网络设备使用评价 对运维服务人员评价 对整体工作评价 结束时间 □好 □较好 □ 一般 □差 原因： □好 □较好 □ 一般 □差 原因： □好 □较好 □ 一般 □差 原因： □好 □较好 □ 一般 □差 原因： 评价人（签字）： 日期： 年 月 日 1.3.3.4.5 事件信息发布通知
对于机房的服务事件，例如：设备维护、线路维护、网络故障或主机故障等，运维管理中心通知客户方，内容包括：
1、事件内容
2、事件类型（一般、紧急） 3、发生的时间段
4、影响范围（部分、全部） 5、客户应采取措施（如需要的话）。
1.3.3.4.6 投诉管理
第 14 页
XXXX政府门户网站维护项目运维方案
