XXXX政府门户网站维护项目运维方案.docx

XXXX政府门户网站维护项目运维方案.docx

《XXXX政府门户网站维护项目运维方案.docx》由会员分享，可在线阅读，更多相关《XXXX政府门户网站维护项目运维方案.docx（128页珍藏版）》请在冰豆网上搜索。

XXXX政府门户网站维护项目运维方案

XXXXXXX政府门户网站维护项目

运维方案

XXX公司

2017年5月

第一章运维方案

一.1运维总体原则

一.1.1整体性原则

我们将综合考虑XXX目前所有门户网站相关应用系统的现状，提出整体的运行维护策略，有效保障系统运行中各环节的不间断运行，并综合使用不同层次的技术手段，为应用系统和系统依托的基础环境提供全方位的监控管理和服务。

一.1.2有效性原则

将充分利用各种现代技术手段，选择一款功能丰富、技术先进的系统运维监控软件，结合科学合理的运行管理机制，对系统的稳定可靠运行提供有效的保障。

一.1.3可靠性原则

对维护工作中后续应用系统模块的开发设计中，应采用成熟可靠的技术和产品，同时配合完善的项目控制规范和质量保证体系，保证互联网站的升级维护中的严格的质量控制，保证系统开发和运行的安全可靠。

一.1.4反馈性原则

实现运维中发现、需要解决的问题要及时反馈给信息系统的开发商进行完善，利于优化机构、岗位设置，利于业务流程的改进。

一.1.5防范预警原则

运维系统中应包含各种预案，争取实现在故障、问题出现时有章可循，在紧急状态有应急措施，提高运维效率，将故障代价减小到最小。

一.2运维服务目标

按照网站管理处要求，完成与XXX网站运维相关的日常工作。

一.3项目运维服务方案

一.3.1运维服务总则

一.3.1.1安全性

（1）XXX门户网站及内容管理平台应用的安全性

确保网站能够正常访问；确保网站群动态应用正常，并能够提供正常的服务。

（2）XXX门户网站及内容管理平台数据的安全性

确保数据库中的信息跟网站发布的信息一致；确保数据库数据正确，不被非法破坏，并且及时做数据库和网站数据的备份，当意外发生时，网站能够及时、完全恢复；未经许可，不得将网站数据泄漏给其它个人或组织；由专人负责，保证数据的安全。

一.3.1.2稳定性

（1）不间断服务

提供7*24不间断服务，专人值守，监控网站；意外情况下，及时通知信息中心相关负责人，并做好各项应急准备。

定期向信息中心相关负责人汇报网站运营情况。

（2）访问响应时间

监控网站群访问速度，如访问相应时间过长，及时查找原因，并向信息中心相关负责人汇报；监控网站群动态应用，对影响应用性能方面因素及时预警，并提出相应解决方案，及时汇报给信息中心相关负责人。

一.3.2运维服务计划

为了对此次维护服务项目提供良好的管理监控，并对项目中各管理组织之间的持续运作建立恰当联系，我们把整个项目执行分为三个阶段：

1、启动阶段

项目前期的准备工作，包括服务管理制度流程的建立、人员的到位，运维体系中各种因素的交接。

我方将在签订合同后的5个工作日内，提供详细的项目实施工作计划（包括：

项目组成员、运维服务的内容、进度安排、应急预案等）。

2、正常服务阶段

正常的执行资产管理和运营维护。

3、收尾阶段

项目的总结移交并达到有序的结束。

一.3.2.1启动阶段和运维体系的导入

在此阶段中，主要执行前期的准备工作，为尽快向客户提供高质量的服务打好基础。

该阶段主要工作如下：

1、成立维护服务项目组，确定客户与XXX公司的职责分配

2、相关人员提前到位，提供维护服务的准备工作

3、召开项目启动会议，明确工作范围，制定启动阶段计划

4、项目管理、运营维护等规章制度流程的确定

5、服务工具的安装、运维体系管理文件的草拟

6、与客户方人员一起讨论有关的工作计划和需求

7、系统维护服务实施方案的出台和审核

8、原来的服务商对XXX公司的知识、档案转移，XXX公司进行签收，确保服务的无缝链接

9、对客户的系统信息进行摸底大调查，建立和更新配置管理数据库

10、对现有系统进行分析，得出改进报告，提交用户

一.3.2.2正常服务阶段

项目启动后，新的运维服务体系可以实现完成所有设备维护后，即进入正常的服务阶段。

在正常服务阶段，所有的工作将按照制定的计划进行，并提供服务级别的承诺。

具体的工作如下：

1、服务管理体系和流程的改进

2、正常的维护管理

3、风险评估

一.3.2.3收尾阶段

此阶段开始于合同结束前1个月（如合同继续延期续签，则本阶段工作主要以总结为主）。

这个阶段的主要工作是和客户充分沟通，移交服务期的工作，争取继续合作的可能。

并从此项目的服务实施过程中积极总结经验，以促进提高在未来的项目中的工作绩效。

1、收集服务期中各部分的服务文档资料。

2、汇总、装订，提交用户并存档。

3、项目评估、总结。

4、向甲方或甲方指定的其他组织进行档案和知识转移，人员培训，确保系统的稳定运行。

一.3.3运维服务体系

一.3.3.1IT服务体系的建立

XXX公司作为国内积极参与政府信息化建设的大型企业之一，长期以来积累了丰富的技术支持和运维服务经验，始终视服务为企业生存与发展的生命线，优秀的服务理念成为我们在激烈市场竞争中所体现的鲜明特色。

一.3.3.1.1IT服务体系整体结构

只有高效、稳定、个性化的本地化服务模式才能满足用户随时随地的服务需求；也只有迅速的维护响应才能真正保证用户的利益不受损害。

因此我们在自身服务体系的基础上，针对XXX政府门户网站内容管理平台运维项目，特定IT服务体系，由响应体系、维护体系和质量监督体系构成，见下图所示：

图1：

IT服务体系架构

1、客户需求

在服务协议规定范围内的任何服务请求，包括咨询、问题申报、投诉等。

2、响应体系

第一时间受理客户的需求，以最快的速度解决问题，保障客户系统尽快恢复正常。

3、维护体系

对客户系统进行主动式服务，发现并解决系统隐患，优化系统性能，并提出合理的改进和升级建议。

4、质量监督体系

为保障服务的质量制定相关的服务协议，通过满意度调查等方式评估服务的提供是否正常。

IT服务体系最终都可以通过本次项目建设的ITIL运维体系落实，响应体系对应ITIL运维体系的“事件管理”，维护体系对应ITIL运维体系的“问题管理”，质量监督体系则通过“运维管理”来实现。

一.3.3.1.2响应体系

响应体系包含服务台和突发事件管理，主要任务是受理客户的服务需求，尽快恢复客户系统的正常运行。

客户有问题可以通过热线电话、Email与服务台联系，服务台负责接听技术服务电话、受理客户问题，进行记录，分类并转给相应的工程师处理。

二线工程师负责处理服务台分配的事件或问题，当二线工程师需要技术支持时，可以从公司总部获第三方获得到技术支持和实验室环境支持。

故障级别

服务请求时间

响应方式、时间

一级故障

7×24

服务台接到服务请求后，即刻响应，服务人员工作时间内马上到达现场，非工作时间1小时内到达，进行现场服务。

二级故障

7×24

服务台接到服务请求后，对于电话未解决故障，15分钟内再次回应，提供电话技术支持，工作时间内服务人员1小时到达现场。

三级故障

7×24

服务台接到服务请求后，30分钟内再次回应，提供电话技术支持，工作时间内服务人员2小时到达现场，或与用户协商

一.3.3.1.3质量监督体系

为保障向客户提供的服务准时高效，质量监督体系是必须的。

运维团队和客户将按照合同的要求，共同制定服务协议书中的各项服务水平要求，以监督保障所提供的服务质量。

质量监督体系的主要工具是满意度调查，衡量的标准即双方认可的服务水平要求。

满意度调查制度及时了解客户对我们事件处理情况的重要手段。

也是我们不断改进、完善服务的渠道。

服务满意度调查制度同响应体系事件的调查制度一样，技术服务中心将协同客户一起定期对提供的服务进行全面的满意度调查，以此来提高服务的质量。

满意度调查结果与服务工程师的当期绩效考核挂钩，作为工程师个人业绩评价的参考数据之一。

一.3.3.2IT运维体系的建立

ITIL提供了一个概念化、模块化的优秀框架，与其说是解决方案，不如说它更象理论。

它提出了建立IT服务管理体系时要考虑哪些流程，提到了应该做哪些，好处在哪儿，但并不详细介绍怎样去做，因此它本身不具备实际操作可能性。

我们在长期的运维项目中积累的丰富的经验，根据XXX门户网站的实际情况，对ITIL进行适当选取、适应和扩展：

（1）导入ITIL是一个长期过程，运维运维初期，以“系统日常运行和支持”为主，重点解决服务支持（ServiceSupport）流程，对发生的问题进行维护和处理。

在运维后期，运维的服务支持流程步入正轨后，再关注运维服务的长期计划和改进，考虑服务提供（ServiceDelivery）。

（2）针对XXX门户网站，运维的主要任务是解决发生的问题，对IT基础架构进行基本的配置管理，因此主要实现“服务台”、“事件管理”、“问题管理”和“配置管理”，至于变更管理在实际运维中，暂时没有系统工具支持，放在后期在规范流程，并用信息系统化实现。

（3）由于初期运维工作内容多，系统繁杂，人员少，为提高运维人员解决问题的能力和效率，运维体系扩展加设“知识库”，以提高运维技术的积累、传承、利用。

经过对ITIL体系进行适当选取、适应和扩展，从适合XXX门户网站，适合运维团队完成任务目标为主，我们制定了个性化的运维体系，如下图所示：

图2：

IT运维体系架构

个性化的XXX门户网站运维体系设置“服务台”统一接受各种故障受理，包括最终用户直接电话或邮件传来的求助信息和运维监控软件过来的自动报警信息，然后服务台问题分析并归类，力求初步解决用户或系统的故障；不能在线解决的需求问题，启动“事件管理”和“问题管理”流程，运维人员按照既定的流程，在“知识库”和“配置管理”的支持下，解决故障，并把积累的经验知识归入知识库。

问题解决后，运维体系反馈于IT系统，促使其更好更稳定运行，并促进其优化和完善。

其中，“知识库”和“配置管理”可以依托运维监控工具实现信息化作业，而“服务台”、“事件管理”和“问题管理”则仍然依照对应的制度人工操作，暂时没有信息化系统辅助运行，可以考虑在后期建设运维平台时优先实现。

所有的事件都应该基于影响度、紧急度和优先级进行分类分级，并提供相应的解决方案和临时方案。

表1：

系统运维故障级别定义

故障级别

服务请求时间

响应方式、时间

一级故障

7×24

服务台接到服务请求后，即刻响应，服务人员工作时间内马上到达现场，非工作时间1小时内到达，进行现场服务。

二级故障

7×24

服务台接到服务请求后，对于电话未解决故障，15分钟内再次回应，提供电话技术支持，工作时间内服务人员1小时到达现场。

三级故障

7×24

服务台接到服务请求后，30分钟内再次回应，提供电话技术支持，工作时间内服务人员2小时到达现场，或与用户协商

注:

故障级别描述：

一级故障是指系统发生严重故障，业务发生中断，或虽然业务未中断但已经无法保证及时、正确的情况，对用户业务的运行有严重影响。

二级故障是指对于系统发生的非严重故障，业务并未中断，业务仍然及时、正确的情况，但性能有所下降。

三级故障是指系统发生轻微的故障，系统有警告信息等，对系统没有较大影响的故障。

一.3.3.3系统运维制度建设

在信息化运维中，制度建设是一道必要的保障。

信息化不能一蹴而就，在信息化发展到一定阶段，建设重点应该要从系统实施转向以应用运维提升为主，运维质量保障、安全机制变得重要起来，这时除了技术的保障以外，制度保障越显得重要。

对于IT运维团队来说，可从以下几个方面来进行IT运维制度化：

（一）转变运维观念，树立规范化意识。

树立只有建立制度化的IT运维意识，才能在日常繁杂琐碎的工作中有效的区分任务的优先级，将有限的资源投入到最能满足“客户”需要的工作中。

为保证运维工作，把运维工作和制度化紧紧地捆绑到一起。

运维工作很琐碎，关键在于规范而不是创新。

只有各级运维技术人员一丝不苟、老老实实按规范做，才能够把事情做好。

（二）建立事件处理流程，强化规范执行力度。

首先需要建立故障和事件处理流程，利用表格工具等记录故障及其处理情况，以建立运维日志，并定期回顾从中辨识和发现问题的线索和根源。

建立每种事件的规范化处理指南，减少运维操作的随意性，在很大程度上降低故障发生的概率。

同时，建立IT运维制度非常重要，但是有了制度还要有人去执行，要强化执行制度比建立制度更重要的观念和意识。

一.3.3.4运维管理机制建设

“三分建设，七分管理”，XXX公司采用多重管理制度，并加强沟通机制，力求完善建设ITSM中的服务监督体系。

一.3.3.4.1升级管理机制

升级管理是突发事件管理的重要组成部分。

“事件跟踪”将记录从受理用户问题到派单过程中相关人员所做的处理和建议，保证信息的正确传递，记录内容将做为我们向用户提供服务及分析和衡量服务水准的依据。

我们将通过服务系统监控事件的全过程，直至服务结束。

当出现的问题在承诺时间内无法有效解决时，“事件跟踪”会自动启用逐级上报升级管理流程，该流程旨在能真正起到督促问题快速有效解决的作用。

我们将和用户一起共同制定出适合XXX业务需求的升级流程并指定相应的人员来监督流程的实施。

一.3.3.4.2报告系统

我们将按XXX信息中心要求定期提供标准报告。

（1）突发事件管理报告

确保用户的电话被接受、解决并记录，服务范畴之外的问题也会转至第三方。

突发事件管理着眼于解决问题的快速，解决问题的高质量，确保用户的满意度并达到承诺的服务级别。

突发事件的出现和解决方法将体现在定期的服务报告中。

（2）问题管理报告

我们将对重复发生的，主要的突发事件进行问题管理，诊断问题的真正原因。

问题管理着眼于获得系统的高可靠，避免问题的再度发生，赢得用户高满意度，达到承诺的服务级别。

经常出现及主要的问题，及相应的解决方法将体现在定期的服务报告中。

报告内容包含重点问题分析、潜在服务隐患、优化建议等信息。

一.3.3.4.3月、季度总结机制

我们每月、每季与XXX信息中心召开总结会，共同讨论前一月或季度的服务执行情况。

会议时间建议在该月、季度结束后、下一周或每月10日之前，具体时间可以与XXX信息中心协商确定。

会前双方应沟通和确定议程并在会前提供必要的报表和报告。

会议主要回顾从上次会议结束到本次会议前一天，我们所提供的服务的绩效，同时讨论和达成为改善服务必须采取的改进措施和行动步骤。

一.3.3.4.4客户满意度调查系统

以目前的客户满意度调查表格为蓝本，与客户共同协商适用于客户的调查选项、格式和方法。

下表仅供参考，以和用户协商后的调查表为准。

表：

运行维护满意度调查表

开始时间

结束时间

对主机设备使用评价

□好□较好□一般□差

原因：

对网络设备使用评价

□好□较好□一般□差

原因：

对运维服务人员评价

□好□较好□一般□差

原因：

对整体工作评价

□好□较好□一般□差

原因：

评价人（签字）：

日期：

年月日

一.3.3.4.5事件信息发布通知

对于机房的服务事件，例如：

设备维护、线路维护、网络故障或主机故障等，运维管理中心通知客户方，内容包括：

1、事件内容

2、事件类型（一般、紧急）

3、发生的时间段

4、影响范围（部分、全部）

5、客户应采取措施（如需要的话）。

一.3.3.4.6投诉管理

（1）XXX用户可以书面或口头形式对运维商提供服务的服务质量进行投诉。

投诉的受理和处理部门由双方事先约定；

（2）XXX用户可以书面或口头形式对运维商的各部门/各级员工进行投诉；

（3）运维商设立投诉专线受理甲方投诉；

（4）运维商在受理XXX用户投诉后的8个工作小时内向投诉方提供第一份书面形式的投诉处理情况报告。

一.3.3.5项目沟通机制建设

一.3.3.5.1内部团队沟通

在每个角色组或在特定系统工作的所有角色中每天或定期举行简短的会议，提供关键的或时间紧迫的系统和业务问题方面的更新和所需行动的更新。

客户可以根据需要浏览的相关信息和分阶段的操作统计数据，如正常运行时间、客户访问次数、行为趋势、开放问题等等。

在为从发布到生产所作的最后准备工作中与开发和部署组队一起举行的由开发组主持的会议。

这一签收表示所有的开发组都已准备就绪。

实施阶段可以承担产品或系统的运行支持工作了，要分发和阅读（例如e-mail的格式编写）定期状态报告，提交给IT管理层，以及针对操作的关键绩效指标方面的业务内容（例如，依照服务级别协议的量度、服务台日志统计、项目目标实现进展等等）。

一.3.3.5.2外部客户沟通

同其他任何项目一样，有效沟通是事关本项目最终能否成功的非常关键的一个环节。

鉴于项目本身的建设内容和牵涉到关系的复杂程度，沟通管理自然显得尤为重要，为此，必须从项目的干系人以及他们之间的工作关系和社会关系出发，详细分析项目所需的各种沟通环节，对其中最主要的沟通环节制定计划进行专门的管理，避免项目因为信息沟通不足而陷入困境或造成不必要的损失。

沟通分为三个层面即：

执行层面，主要是各干系单位的工作人员就一些具体工作中涉及的配合问题进行沟通和交流；管理层面，主要是各干系单位的在本项目及其子项目的项目经理及监理单位，沟通的内容主要是有关项目执行中的重要事项、活动和决定；决策层面，主要包括业主领导、开发商领导、运维商领导等，沟通的内容主要是对项目进展过程中间碰到的重大问题的协调、重大事项的决定、重大事件的见证等。

为了实现充分沟通的目的，将主要设立如下沟通手段。

（1）会议或交谈

按需要组织会议进行沟通，或直接找相关的人进行讨论，注意记录沟通和讨论结果。

每次正式会议都要形成会议纪要，由项目组文秘做会议纪要，并分发到有关人员手中。

（2）工作联系单

联系单将处理项目执行过程中重要事项的决定、变更或者项目问题报告的多点沟通的一种正式的形式，一般在其他辅助手段沟通无效的情况下采用。

联系单上须明确所联系事项的内容概要、紧急程度及其解决请求。

在出具的联系单中，一般情况下主送业主或监理单位，抄送其他相关单位，并要求有关单位及时回复或者解决。

在接到需我们解决或回复的联系单后，我们也会在第一时间给出答复或者采取行动。

项目实施期间所有收发的工作联系单都代表着项目执行过程中的重要活动的书面依据，都将作为项目执行过程中的档案进行整理存档，在项目终验时移交给业主。

（3）电话或电话会议

通过电话的方式进行信息沟通。

对比较重要的事情，需要包括实施地点以外的人员，则需要利用电话会议的方式进行讨论，沟通。

实践证明，电话是点到点沟通的最普遍和最常用的形式。

需要声明的是，对于项目中一些重大问题，仅仅通过电话沟通仍然是不够的，在电话确认以后，仍然需要以备忘录、联系单的形式落实到纸面，作为对这些问题的最后确认。

（4）书面报告、备忘录和传真

书面报告、备忘录和传真事点对点沟通的相对比较正式的手段，主要考虑用于对项目过程中的一些重要事件或方案的描述、质询等。

（5）电子邮件

作为现代办公的一种常用手段，电子邮件系统也将成为项目组内部以及项目组合外部沟通的一种非常重要而且高效的沟通手段，应该视为同书面报告和传真具有同等的严肃性。

一.3.3.6运维保障机制建设

选择了一个合适的运维商，只是运维项目开始的关键一步，如何确实保障项目走向成功呢？

我们认为需要针对XXX门户网站运维项目成立专门机构，专人专职，专款专用。

一.3.3.6.1机构保障

建议双方联合成立运维领导小组，增强沟通协调，加强运维组织建设，建立稳定的运维团队。

在XXX政府门户网站内容管理平台运维项目启动阶段，我们就高度重视，并组织人员组建了筹备机构，由丰富经验的资深咨询人员及熟悉政府网站运维的工作人员共同组成工作小组，广泛研究国内外信息化系统运维经验，深入调研分析，“尽我所能”，无私奉献我们在大型项目建设及运维经验。

我们在承担此项目后，将成立独立的部门，采用专职部门、专人专职、专款专用等措施来保障该部门不同于公司其他的项目组织。

一.3.3.6.2人员保障

（一）运维优秀人员

本次项目，我们将按照XXX要求专门组建运维团队，使运维团队具备娴熟的技术和广泛的专业知识，系统运维人员具备高超的技能和丰富的经验。

（二）核心人员备选

我们聚集了国内优秀的IT人员、管理人员，对于进驻XXX运维部核心人员，建立备份替补机制，备份替补人员随时可以进入XXX开始工作。

（三）凝聚人才的企业文化

我们一贯的企业文化，凝聚了大批优秀人才，使整体团队能保持工作激情，传承知识，从而创造一个高效、团结、和谐的工作环境。

我们所有工作人员在企业文化的洗礼下，具有良好的职业素质和道德品质，面对具有历史使命的工作任务，不会讲任何条件，作为战略合作伙伴，坚决服从XXX信息中心领导，服务好XXX政府门户网站内容管理云服务平台！

（四）规范管理规避人员流动风险

通过建立规范的软件开发管理、项目管理、IT服务管理、运维管理等管理体系，和科学的咨询方法等诸多知识体系，保障运维工作的开展，弱化个人能力对整个运维项目的影响，把人员流失造成的风险降低到最低。

根据我们以往的经验可以证明，我们有能力使人员流失的风险在可控范围内。

（五）人员调动须经同意

本次项目的所有人员调离，都要和XXX信息中心协商，经XXX信息中心同意后方可进行。

一.3.3.6.3培训和技术保障

加强对运维人员的培训，提高技术保障能力，成功有效地实施和运营服务管理流程。

除此之外，培训还有以下几个方面的作用：

1、促使所有相关人员清楚和理解ITIL计划和有关术语；

2、为相关人员提供讨论的平台；

3、为发现和减少可能的问题和不正确的实施方法提供了平台和知识；

4、帮助发现缺乏的技能并采取相应改进措施；

5、提供大量的培训流程所需的资源。

一.3.3.6.4积极参与XXX信息化建设

我们运维团队在完成运维任务的同时，将积极参与XXX的信息化项目建设，促进系统统筹规划，集中管理，利于运维交接，便于维护。

（一）参与统一规划管理

根据ITIL体系外围工作要求，IT运维还要结合“IT规划管理”和“IT基础架构”的工作，因此我们将积极参与XXX信息中心的信息化建设规划，通过统筹规划，设立信息化战略目标，制定信息化建设规范，解决系统结构不一、开发混乱、成本居高、维护困难、信息孤岛林立、难以集中管理的局面。

ITIL体系反馈于IT系统，促进互联网站更好的完善和发展，同时也使运维更加轻松容易。

（二）参与其他系统建设

另外，IT运维还要结合“业务管理”和“应用管理”的工作，我们将把业务目标作为运维部门的战略目标，协调技术和业务发展之间的关系，积极参与业务部门的需求分析、业务系统的开发建设、系统的测试上线等工作。

一.3.4运维团队组织

一.3.4.1组建团队

一.3.4.1.1组建原则

（1）项目运维团队将提供7*24小时应急响应服务能力，在遇到突发情况时及时响应解决问题。

（2）项目实施人员具有良好的职业道德，不损害用户利益。

（3）驻场工程师配置具备完全的稳定性，不出现一个岗位角色频繁更换人员的问题，以便保证工程师对系统的了解和认知，保证运维工作的质量。

（4）美工配置具有良好的网页及平面设计能力、丰富的网站制作经验，精通美工软件Photoshop、Illustrator等，熟悉html、css、dreamweaver等。

（5）在项目实施过程中不随意变换所拟派的项目经理。

基于以上组建团队原则，本次项目的团队将由XXX公司的政府网站运维技术人员组建，科学地分析运维任务，拟定角色职责，设立工作岗位，组成运维机构；再根据人员的技术组成，指定其角色和岗位，这样三定（定人员、定角色、定岗位）后，形成的运维团队专人专职、人尽