某政府门户网站维护项目运维方案
时间：2023-04-26 19:03:01 | 来源：网站运营
时间：2023-04-26 19:03:01 来源：网站运营
某政府门户网站维护项目运维方案：
运维总体原则整体性原则
我们将综合考虑XXX目前所有门户网站相关应用系统的现状，提出整体的运行维护策略，有效保障系统运行中各环节的不间断运行，并综合使用不同层次的技术手段，为应用系统和系统依托的基础环境提供全方位的监控管理和服务。
有效性原则
将充分利用各种现代技术手段，选择一款功能丰富、技术先进的系统运维监控软件，结合科学合理的运行管理机制，对系统的稳定可靠运行提供有效的保障。
可靠性原则
对维护工作中后续应用系统模块的开发设计中，应采用成熟可靠的技术和产品，同时配合完善的项目控制规范和质量保证体系，保证互联网站的升级维护中的严格的质量控制，保证系统开发和运行的安全可靠。
反馈性原则
实现运维中发现、需要解决的问题要及时反馈给信息系统的开发商进行完善，利于优化机构、岗位设置，利于业务流程的改进。
防范预警原则
运维系统中应包含各种预案，争取实现在故障、问题出现时有章可循，在紧急状态有应急措施，提高运维效率，将故障代价减小到最小。
运维服务目标
按照网站管理处要求，完成与XXX网站运维相关的日常工作。
项目运维服务方案
运维服务总则
安全性
（1）XXX门户网站及内容管理平台应用的安全性
确保网站能够正常访问；确保网站群动态应用正常，并能够提供正常的服务。
（2）XXX门户网站及内容管理平台数据的安全性
确保数据库中的信息跟网站发布的信息一致；确保数据库数据正确，不被非法破坏，并且及时做数据库和网站数据的备份，当意外发生时，网站能够及时、完全恢复；未经许可，不得将网站数据泄漏给其它个人或组织；由专人负责，保证数据的安全。
稳定性
（1）不间断服务
提供7*24不间断服务，专人值守，监控网站；意外情况下，及时通知信息中心相关负责人，并做好各项应急准备。定期向信息中心相关负责人汇报网站运营情况。
（2）访问响应时间
监控网站群访问速度，如访问相应时间过长，及时查找原因，并向信息中心相关负责人汇报；监控网站群动态应用，对影响应用性能方面因素及时预警，并提出相应解决方案，及时汇报给信息中心相关负责人。
运维服务计划
为了对此次维护服务项目提供良好的管理监控，并对项目中各管理组织之间的持续运作建立恰当联系，我们把整个项目执行分为三个阶段：
1、启动阶段
项目前期的准备工作，包括服务管理制度流程的建立、人员的到位，运维体系中各种因素的交接。
我方将在签订合同后的5个工作日内，提供详细的项目实施工作计划（包括：项目组成员、运维服务的内容、进度安排、应急预案等）。
2、正常服务阶段
正常的执行资产管理和运营维护。
3、收尾阶段
项目的总结移交并达到有序的结束。
启动阶段和运维体系的导入
在此阶段中，主要执行前期的准备工作，为尽快向客户提供高质量的服务打好基础。
该阶段主要工作如下：
1、成立维护服务项目组，确定客户与XXX公司的职责分配
2、相关人员提前到位，提供维护服务的准备工作
3、召开项目启动会议，明确工作范围，制定启动阶段计划
4、项目管理、运营维护等规章制度流程的确定
5、服务工具的安装、运维体系管理文件的草拟
6、与客户方人员一起讨论有关的工作计划和需求
7、系统维护服务实施方案的出台和审核
8、原来的服务商对XXX公司的知识、档案转移，XXX公司进行签收，确保服务的无缝链接
9、对客户的系统信息进行摸底大调查，建立和更新配置管理数据库
10、对现有系统进行分析，得出改进报告，提交用户
正常服务阶段
项目启动后，新的运维服务体系可以实现完成所有设备维护后，即进入正常的服务阶段。在正常服务阶段，所有的工作将按照制定的计划进行，并提供服务级别的承诺。具体的工作如下：
1、服务管理体系和流程的改进
2、正常的维护管理
3、风险评估
收尾阶段
此阶段开始于合同结束前1个月（如合同继续延期续签，则本阶段工作主要以总结为主）。这个阶段的主要工作是和客户充分沟通，移交服务期的工作，争取继续合作的可能。并从此项目的服务实施过程中积极总结经验，以促进提高在未来的项目中的工作绩效。
1、收集服务期中各部分的服务文档资料。
2、汇总、装订，提交用户并存档。
3、项目评估、总结。
4、向甲方或甲方指定的其他组织进行档案和知识转移，人员培训，确保系统的稳定运行。
运维服务体系
IT服务体系的建立
XXX公司作为国内积极参与政府信息化建设的大型企业之一，长期以来积累了丰富的技术支持和运维服务经验，始终视服务为企业生存与发展的生命线，优秀的服务理念成为我们在激烈市场竞争中所体现的鲜明特色。
IT服务体系整体结构
只有高效、稳定、个性化的本地化服务模式才能满足用户随时随地的服务需求；也只有迅速的维护响应才能真正保证用户的利益不受损害。因此我们在自身服务体系的基础上，针对XXX政府门户网站内容管理平台运维项目，特定IT服务体系，由响应体系、维护体系和质量监督体系构成，见下图所示：
IT服务体系架构
1、客户需求在服务协议规定范围内的任何服务请求，包括咨询、问题申报、投诉等。
2、响应体系第一时间受理客户的需求，以最快的速度解决问题，保障客户系统尽快恢复正常。
3、维护体系对客户系统进行主动式服务，发现并解决系统隐患，优化系统性能，并提出合理的改进和升级建议。
4、质量监督体系为保障服务的质量制定相关的服务协议，通过满意度调查等方式评估服务的提供是否正常。
IT服务体系最终都可以通过本次项目建设的ITIL运维体系落实，响应体系对应ITIL运维体系的“事件管理”，维护体系对应ITIL运维体系的“问题管理”，质量监督体系则通过“运维管理”来实现。
响应体系
响应体系包含服务台和突发事件管理，主要任务是受理客户的服务需求，尽快恢复客户系统的正常运行。
客户有问题可以通过热线电话、Email与服务台联系，服务台负责接听技术服务电话、受理客户问题，进行记录，分类并转给相应的工程师处理。二线工程师负责处理服务台分配的事件或问题，当二线工程师需要技术支持时，可以从公司总部获第三方获得到技术支持和实验室环境支持。
| 故障级别 | 服务请求时间 | 响应方式、时间 |
|---|
| 一级故障 | 7×24 | 服务台接到服务请求后，即刻响应，服务人员工作时间内马上到达现场，非工作时间1小时内到达，进行现场服务。 |
| 二级故障 | 7×24 | 服务台接到服务请求后，对于电话未解决故障，15分钟内再次回应，提供电话技术支持，工作时间内服务人员1小时到达现场。 |
| 三级故障 | 7×24 | 服务台接到服务请求后，30分钟内再次回应，提供电话技术支持，工作时间内服务人员2小时到达现场，或与用户协商 |
质量监督体系
为保障向客户提供的服务准时高效，质量监督体系是必须的。运维团队和客户将按照合同的要求，共同制定服务协议书中的各项服务水平要求，以监督保障所提供的服务质量。
质量监督体系的主要工具是满意度调查，衡量的标准即双方认可的服务水平要求。
满意度调查制度及时了解客户对我们事件处理情况的重要手段。也是我们不断改进、完善服务的渠道。
服务满意度调查制度同响应体系事件的调查制度一样，技术服务中心将协同客户一起定期对提供的服务进行全面的满意度调查，以此来提高服务的质量。
满意度调查结果与服务工程师的当期绩效考核挂钩，作为工程师个人业绩评价的参考数据之一。
IT运维体系的建立
ITIL提供了一个概念化、模块化的优秀框架，与其说是解决方案，不如说它更象理论。它提出了建立IT服务管理体系时要考虑哪些流程，提到了应该做哪些，好处在哪儿，但并不详细介绍怎样去做，因此它本身不具备实际操作可能性。
我们在长期的运维项目中积累的丰富的经验，根据XXX门户网站的实际情况，对ITIL进行适当选取、适应和扩展：
- 导入ITIL是一个长期过程，运维运维初期，以“系统日常运行和支持”为主，重点解决服务支持（Service Support）流程，对发生的问题进行维护和处理。在运维后期，运维的服务支持流程步入正轨后，再关注运维服务的长期计划和改进，考虑服务提供（Service Delivery）。
- 针对XXX门户网站，运维的主要任务是解决发生的问题，对IT基础架构进行基本的配置管理，因此主要实现“服务台”、“事件管理”、“问题管理”和“配置管理”，至于变更管理在实际运维中，暂时没有系统工具支持，放在后期在规范流程，并用信息系统化实现。
- 由于初期运维工作内容多，系统繁杂，人员少，为提高运维人员解决问题的能力和效率，运维体系扩展加设“知识库”，以提高运维技术的积累、传承、利用。
经过对ITIL体系进行适当选取、适应和扩展，从适合XXX门户网站，适合运维团队完成任务目标为主，我们制定了个性化的运维体系，如下图所示：
IT运维体系架构个性化的XXX门户网站运维体系设置“服务台”统一接受各种故障受理，包括最终用户直接电话或邮件传来的求助信息和运维监控软件过来的自动报警信息，然后服务台问题分析并归类，力求初步解决用户或系统的故障；不能在线解决的需求问题，启动“事件管理”和“问题管理”流程，运维人员按照既定的流程，在“知识库”和“配置管理”的支持下，解决故障，并把积累的经验知识归入知识库。问题解决后，运维体系反馈于IT系统，促使其更好更稳定运行，并促进其优化和完善。
其中，“知识库”和“配置管理”可以依托运维监控工具实现信息化作业，而“服务台”、“事件管理”和“问题管理”则仍然依照对应的制度人工操作，暂时没有信息化系统辅助运行，可以考虑在后期建设运维平台时优先实现。
所有的事件都应该基于影响度、紧急度和优先级进行分类分级，并提供相应的解决方案和临时方案。
系统运维故障级别定义| 故障级别 | 服务请求时间 | 响应方式、时间 |
|---|
| 一级故障 | 7×24 | 服务台接到服务请求后，即刻响应，服务人员工作时间内马上到达现场，非工作时间1小时内到达，进行现场服务。 |
| 二级故障 | 7×24 | 服务台接到服务请求后，对于电话未解决故障，15分钟内再次回应，提供电话技术支持，工作时间内服务人员1小时到达现场。 |
| 三级故障 | 7×24 | 服务台接到服务请求后，30分钟内再次回应，提供电话技术支持，工作时间内服务人员2小时到达现场，或与用户协商 |
注: 故障级别描述：
一级故障是指系统发生严重故障，业务发生中断，或虽然业务未中断但已经无法保证及时、正确的情况，对用户业务的运行有严重影响。
二级故障是指对于系统发生的非严重故障，业务并未中断，业务仍然及时、正确的情况，但性能有所下降。
三级故障是指系统发生轻微的故障，系统有警告信息等，对系统没有较大影响的故障。
系统运维制度建设
在信息化运维中，制度建设是一道必要的保障。信息化不能一蹴而就，在信息化发展到一定阶段，建设重点应该要从系统实施转向以应用运维提升为主，运维质量保障、安全机制变得重要起来，这时除了技术的保障以外，制度保障越显得重要。
对于IT运维团队来说，可从以下几个方面来进行IT运维制度化：
（一）转变运维观念，树立规范化意识。树立只有建立制度化的IT运维意识，才能在日常繁杂琐碎的工作中有效的区分任务的优先级，将有限的资源投入到最能满足“客户”需要的工作中。
为保证运维工作，把运维工作和制度化紧紧地捆绑到一起。运维工作很琐碎，关键在于规范而不是创新。只有各级运维技术人员一丝不苟、老老实实按规范做，才能够把事情做好。
（二）建立事件处理流程，强化规范执行力度。首先需要建立故障和事件处理流程，利用表格工具等记录故障及其处理情况，以建立运维日志，并定期回顾从中辨识和发现问题的线索和根源。建立每种事件的规范化处理指南，减少运维操作的随意性，在很大程度上降低故障发生的概率。
同时，建立IT运维制度非常重要，但是有了制度还要有人去执行，要强化执行制度比建立制度更重要的观念和意识。
运维管理机制建设
“三分建设，七分管理”，XXX公司采用多重管理制度，并加强沟通机制，力求完善建设ITSM中的服务监督体系。
升级管理机制
升级管理是突发事件管理的重要组成部分。“事件跟踪”将记录从受理用户问题到派单过程中相关人员所做的处理和建议，保证信息的正确传递，记录内容将做为我们向用户提供服务及分析和衡量服务水准的依据。
我们将通过服务系统监控事件的全过程，直至服务结束。当出现的问题在承诺时间内无法有效解决时，“事件跟踪”会自动启用逐级上报升级管理流程，该流程旨在能真正起到督促问题快速有效解决的作用。我们将和用户一起共同制定出适合XXX业务需求的升级流程并指定相应的人员来监督流程的实施。
报告系统
我们将按XXX信息中心要求定期提供标准报告。
- 突发事件管理报告
确保用户的电话被接受、解决并记录，服务范畴之外的问题也会转至第三方。突发事件管理着眼于解决问题的快速，解决问题的高质量，确保用户的满意度并达到承诺的服务级别。突发事件的出现和解决方法将体现在定期的服务报告中。 - 问题管理报告
我们将对重复发生的，主要的突发事件进行问题管理，诊断问题的真正原因。问题管理着眼于获得系统的高可靠，避免问题的再度发生，赢得用户高满意度，达到承诺的服务级别。经常出现及主要的问题，及相应的解决方法将体现在定期的服务报告中。
报告内容包含重点问题分析、潜在服务隐患、优化建议等信息。
月、季度总结机制
我们每月、每季与XXX信息中心召开总结会，共同讨论前一月或季度的服务执行情况。会议时间建议在该月、季度结束后、下一周或每月10日之前，具体时间可以与XXX信息中心协商确定。会前双方应沟通和确定议程并在会前提供必要的报表和报告。
会议主要回顾从上次会议结束到本次会议前一天，我们所提供的服务的绩效，同时讨论和达成为改善服务必须采取的改进措施和行动步骤。
客户满意度调查系统
以目前的客户满意度调查表格为蓝本，与客户共同协商适用于客户的调查选项、格式和方法。下表仅供参考，以和用户协商后的调查表为准。
表：运行维护满意度调查表| 开始时间 | | 结束时间 | |
|---|
| 对主机设备使用评价 | □好 □较好 □ 一般 □差 |
| 原因： |
| 对网络设备使用评价 | □好 □较好 □ 一般 □差 |
| 原因： |
| 对运维服务人员评价 | □好 □较好 □ 一般 □差 |
| 原因： |
| 对整体工作评价 | □好 □较好 □ 一般 □差 |
| 原因： |
| 评价人（签字）： 日期： 年 月 日 |
事件信息发布通知
对于机房的服务事件，例如：设备维护、线路维护、网络故障或主机故障等，运维管理中心通知客户方，内容包括：
1、事件内容
2、事件类型（一般、紧急）
3、发生的时间段
4、影响范围（部分、全部）
5、客户应采取措施（如需要的话）。
投诉管理
- XXX用户可以书面或口头形式对运维商提供服务的服务质量进行投诉。投诉的受理和处理部门由双方事先约定；
- XXX用户可以书面或口头形式对运维商的各部门/各级员工进行投诉；
- 运维商设立投诉专线受理甲方投诉；
- 运维商在受理XXX用户投诉后的8个工作小时内向投诉方提供第一份书面形式的投诉处理情况报告。
项目沟通机制建设
内部团队沟通
在每个角色组或在特定系统工作的所有角色中每天或定期举行简短的会议，提供关键的或时间紧迫的系统和业务问题方面的更新和所需行动的更新。
客户可以根据需要浏览的相关信息和分阶段的操作统计数据，如正常运行时间、客户访问次数、行为趋势、开放问题等等。
在为从发布到生产所作的最后准备工作中与开发和部署组队一起举行的由开发组主持的会议。这一签收表示所有的开发组都已准备就绪。
实施阶段可以承担产品或系统的运行支持工作了，要分发和阅读（例如 e-mail 的格式编写）定期状态报告，提交给 IT 管理层，以及针对操作的关键绩效指标方面的业务内容（例如，依照服务级别协议的量度、服务台日志统计、项目目标实现进展等等）。
外部客户沟通
同其他任何项目一样，有效沟通是事关本项目最终能否成功的非常关键的一个环节。鉴于项目本身的建设内容和牵涉到关系的复杂程度，沟通管理自然显得尤为重要，为此，必须从项目的干系人以及他们之间的工作关系和社会关系出发，详细分析项目所需的各种沟通环节，对其中最主要的沟通环节制定计划进行专门的管理，避免项目因为信息沟通不足而陷入困境或造成不必要的损失。
沟通分为三个层面即：执行层面，主要是各干系单位的工作人员就一些具体工作中涉及的配合问题进行沟通和交流；管理层面，主要是各干系单位的在本项目及其子项目的项目经理及监理单位，沟通的内容主要是有关项目执行中的重要事项、活动和决定；决策层面，主要包括业主领导、开发商领导、运维商领导等，沟通的内容主要是对项目进展过程中间碰到的重大问题的协调、重大事项的决定、重大事件的见证等。
为了实现充分沟通的目的，将主要设立如下沟通手段。
（1）会议或交谈
按需要组织会议进行沟通，或直接找相关的人进行讨论，注意记录沟通和讨论结果。每次正式会议都要形成会议纪要，由项目组文秘做会议纪要，并分发到有关人员手中。
（2）工作联系单
联系单将处理项目执行过程中重要事项的决定、变更或者项目问题报告的多点沟通的一种正式的形式，一般在其他辅助手段沟通无效的情况下采用。联系单上须明确所联系事项的内容概要、紧急程度及其解决请求。在出具的联系单中，一般情况下主送业主或监理单位，抄送其他相关单位，并要求有关单位及时回复或者解决。在接到需我们解决或回复的联系单后，我们也会在第一时间给出答复或者采取行动。
项目实施期间所有收发的工作联系单都代表着项目执行过程中的重要活动的书面依据，都将作为项目执行过程中的档案进行整理存档，在项目终验时移交给业主。
（3）电话或电话会议
通过电话的方式进行信息沟通。对比较重要的事情，需要包括实施地点以外的人员，则需要利用电话会议的方式进行讨论，沟通。实践证明，电话是点到点沟通的最普遍和最常用的形式。
需要声明的是，对于项目中一些重大问题，仅仅通过电话沟通仍然是不够的，在电话确认以后，仍然需要以备忘录、联系单的形式落实到纸面，作为对这些问题的最后确认。
（4）书面报告、备忘录和传真
书面报告、备忘录和传真事点对点沟通的相对比较正式的手段，主要考虑用于对项目过程中的一些重要事件或方案的描述、质询等。
（5）电子邮件
作为现代办公的一种常用手段，电子邮件系统也将成为项目组内部以及项目组合外部沟通的一种非常重要而且高效的沟通手段，应该视为同书面报告和传真具有同等的严肃性。
运维保障机制建设
选择了一个合适的运维商，只是运维项目开始的关键一步，如何确实保障项目走向成功呢我们认为需要针对XXX门户网站运维项目成立专门机构，专人专职，专款专用。
机构保障
建议双方联合成立运维领导小组，增强沟通协调，加强运维组织建设，建立稳定的运维团队。
在XXX政府门户网站内容管理平台运维项目启动阶段，我们就高度重视，并组织人员组建了筹备机构，由丰富经验的资深咨询人员及熟悉政府网站运维的工作人员共同组成工作小组，广泛研究国内外信息化系统运维经验，深入调研分析，“尽我所能”，无私奉献我们在大型项目建设及运维经验。
我们在承担此项目后，将成立独立的部门，采用专职部门、专人专职、专款专用等措施来保障该部门不同于公司其他的项目组织。
人员保障
（一）运维优秀人员
本次项目，我们将按照XXX要求专门组建运维团队，使运维团队具备娴熟的技术和广泛的专业知识，系统运维人员具备高超的技能和丰富的经验。
（二）核心人员备选
我们聚集了国内优秀的IT人员、管理人员，对于进驻XXX运维部核心人员，建立备份替补机制，备份替补人员随时可以进入XXX开始工作。
（三）凝聚人才的企业文化
我们一贯的企业文化，凝聚了大批优秀人才，使整体团队能保持工作激情，传承知识，从而创造一个高效、团结、和谐的工作环境。
我们所有工作人员在企业文化的洗礼下，具有良好的职业素质和道德品质，面对具有历史使命的工作任务，不会讲任何条件，作为战略合作伙伴，坚决服从XXX信息中心领导，服务好XXX政府门户网站内容管理云服务平台！
（四）规范管理规避人员流动风险
通过建立规范的软件开发管理、项目管理、IT服务管理、运维管理等管理体系，和科学的咨询方法等诸多知识体系，保障运维工作的开展，弱化个人能力对整个运维项目的影响，把人员流失造成的风险降低到最低。
根据我们以往的经验可以证明，我们有能力使人员流失的风险在可控范围内。
（五）人员调动须经同意
本次项目的所有人员调离，都要和XXX信息中心协商，经XXX信息中心同意后方可进行。
培训和技术保障
加强对运维人员的培训，提高技术保障能力，成功有效地实施和运营服务管理流程。除此之外，培训还有以下几个方面的作用：
1、促使所有相关人员清楚和理解ITIL计划和有关术语；
2、为相关人员提供讨论的平台；
3、为发现和减少可能的问题和不正确的实施方法提供了平台和知识；
4、帮助发现缺乏的技能并采取相应改进措施；
5、提供大量的培训流程所需的资源。
积极参与XXX信息化建设
我们运维团队在完成运维任务的同时，将积极参与XXX的信息化项目建设，促进系统统筹规划，集中管理，利于运维交接，便于维护。
（一）参与统一规划管理
根据ITIL体系外围工作要求，IT运维还要结合“IT规划管理”和“IT基础架构”的工作，因此我们将积极参与XXX信息中心的信息化建设规划，通过统筹规划，设立信息化战略目标，制定信息化建设规范，解决系统结构不一、开发混乱、成本居高、维护困难、信息孤岛林立、难以集中管理的局面。ITIL体系反馈于IT系统，促进互联网站更好的完善和发展，同时也使运维更加轻松容易。
（二）参与其他系统建设
另外，IT运维还要结合“业务管理”和“应用管理”的工作，我们将把业务目标作为运维部门的战略目标，协调技术和业务发展之间的关系，积极参与业务部门的需求分析、业务系统的开发建设、系统的测试上线等工作。
运维团队组织
组建团队
组建原则
（1）项目运维团队将提供7*24小时应急响应服务能力，在遇到突发情况时及时响应解决问题。
（2）项目实施人员具有良好的职业道德，不损害用户利益。
（3）驻场工程师配置具备完全的稳定性，不出现一个岗位角色频繁更换人员的问题，以便保证工程师对系统的了解和认知，保证运维工作的质量。
（4）美工配置具有良好的网页及平面设计能力、丰富的网站制作经验，精通美工软件Photoshop、Illustrator等，熟悉html、css、dreamweaver等。
（5）在项目实施过程中不随意变换所拟派的项目经理。
基于以上组建团队原则，本次项目的团队将由XXX公司的政府网站运维技术人员组建，科学地分析运维任务，拟定角色职责，设立工作岗位，组成运维机构；再根据人员的技术组成，指定其角色和岗位，这样三定（定人员、定角色、定岗位）后，形成的运维团队专人专职、人尽其才、角色交叉、技能备份，能高效、可控地执行运维工作。
人员角色
IT服务管理是以流程为中心的，针对每个流程，定义了一系列的角色，每个角色被赋予特定的职责和任务，实现责权利的统一。一个角色可能需要多个运维人员来承担，同样一个运维人员有时也可能承担多个角色。
- 任务需求
- 网站应用系统日常维护
维护人员对所管理的网站应用系统进行每日巡检，包括对磁盘空间、系统日志、系统资源占用、访问性能等的检查。 - 网站系统日常监控
对网站系统每天的运行进行监控，及时发现系统的故障，确保系统的可靠稳定运行，并在日常监控的基础上进行安全事件积累、分析。 - 网站内容监控
维护人员每日完成对XXX网站栏目、内容的巡检，对每日网站信息摆渡工作进行监控，为网站信息发布提供技术咨询和技术支持，解答和解决网站发布系统使用过程中出现的问题。 - 网站内容维护
完成XXX网站主站页面、英文版及相关栏目内容的维护；公众互动板块各栏目的维护；XXX网站内容管理系统用户管理等工作。 - 网站栏目调整
指导各单位完成网站栏目、图片和样式的管理，提供阶段性栏目或栏目内容调整、程序修改、信息发布等服务。 - 数据统计
在对网站系统和内容进行监控的基础上，对网站访问量等基础数据进行统计，提供每日统计报表，并根据实际工作需要，进行网站数据统计工作。 - 网站应用系统完善
针对使用过程中提出的网站应用系统改进和完善需求，及时响应小范围应用软件调整的需求，不断完善网站应用系统。 - 网站系统安全测试
积极配合信息中心开展网站系统安全性测试工作，并协助对测试中发现的应用系统问题进行改进。 - 网站信息系统调整
积极配合XXX信息中心开展网站信息系统建设调整工作，包括实现网站信息的分库存储、备份网站系统完善方案和测试系统建设、网站部分历史数据的梳理、补充及信息中心根据网站工作需要提出的其他调整任务。 - 完成XXX信息中心交办的与网站系统相关的其他工作。
- 所需角色及职责
- 运维经理
职责：根据客户方的需求，协调资源完成客户方交办的各项工作 - 技术支持工程师
职责：对网络设备资源信息、服务器资源及网络带宽资源利用综合管理，进行网络拓扑监管、涌塞监测、端口管理、路由管理、性能监视、流量分析、状态监视、CPU，内存，DMA，I/O，DISK，进程等资源。
负责操作系统、数据库系统、应用中间件系统、邮件系统等基础系统软件进行维护和监管，包括监控数据库系统、Web、文件、进程、Mail、应用中间件、FTP、DNS、HTTP等。 - 流媒体工程师
职责：根据客户方的需求，编辑、录制视频并进行发布。 - 网站开发工程师
职责：对用户发现的系统中的bug和小的系统调整进行程序修改和完善；对现行互联网站中新增版块的需求，应协助进行需求分析，起草需求分析报告，然后根据需求组成开发小组，完成模块的开发、上线工作；适当参与XXX内部新建互联网站的开发工作，了解系统的整体架构和设计开发的全过程。
协助信息中心进行新开发的互联网站的用户测试工作；对新增版块，完成模块的测试，协助上线工作。 - 美工设计
职责：业务系统的页面美术设计改善，新增模块的美术设计。 - 中文编辑
职责：负责网站主站页面及相关栏目内容的维护。 - 英文编辑
职责：负责英文网站页面及相关栏目内容的翻译、维护的工作。
工作岗位设置
- 管理岗
运维管理岗配置运维经理，主要职责为：
- 负责整个运维服务项目的具体组织和管理。
- 制作详细的运维方案，在运维过程中及时动态地调整方案，提高工作效率，保证服务质量。
- 给各个管理小组分配任务，随时监控每个小组的运维管理情况，控制服务质量。
- 作为与用户间的接口，负责向用户汇报运维情况、变更需求等情况，并及时将有关要求反馈给管理小组。
- 接受用户投诉和协调用户需求的变化，及时反馈制订应急计划，报告项目领导小组和用户负责人。
- 召集季度总结会和工作协调会。
- 技术岗
- 技术支持工程师
主要职责：
- 负责网站软、硬件平台日常运维。
- 负责网络设备、服务器、存储设备、安全设施等硬件平台的运行和监控。
- 负责服务器操作系统、数据库系统、应用中间件系统等基础系统软件的安装、配置、和应用系统接口、运维及关闭。
- 负责维护数据报表系统的运行，管理数据库表，清除垃圾数据，按时数据更新，产生临时报表。
- 中文编辑
主要职责：
- 负责网站主站页面及相关栏目内容的维护。
- 负责中文版网站主站栏目日常信息编辑、更新发布。
- 负责网站专题专栏选题、栏目策划，信息编辑发布工作。
- 流媒体工程师
主要职责：负责编辑、录制视频并完成在线发布工作。 - 网站开发运维工程师
主要职责：
- 负责软件开发等应用软件相关的运维工作。
- 负责对XXX现有应用系统进行二次开发工作。
- 美工
主要职责：
- 负责网站页面设计及专题、专栏页面设计工作。
- 负责网站LOGO图片设计制作、页面动画制作等工作。
- 英文编辑
主要职责：负责英文网站页面及相关栏目内容的翻译、日常信息维护的工作。
组织机构
在运维组织设计中，将重点考虑人员、角色、岗位三个因素。而本次运维项目，XXX公司将综合职能型组织、矩阵型组织和项目型组织，建立组合型组织架构，既有职能部门完成日常运维工作，又可以为完成各项临时小规模项目开发而设立矩阵型组织或项目型组织。
XXX信息中心和我们共同组建成立“运维联合领导小组”，由双方相关领导组成，主要进行高层协调，制定战略、划清目标，保障运维工作顺利完成。
我们将按照组织机构的工作岗位及角色职责，统筹人力资源，抽调精兵强将，组建专门部门“XXX门户网站运维部”，下设工作台、硬件集成支持组、软件集成支持组、软件开发支持组和内容维护组。“中国XXX门户网站运维部”实际派驻不少于4人在XXX现场，属于“一线”支持人员。
疑难问题会商解决、小规模软件开发等将协调公司总部的其他人员参加，如项目中心、研发中心的技术骨干、软件开发工程师等，属于“二线”支持人员。
个别问题还会涉及到第三方支持，包括原厂商、合作伙伴、其他专家顾问等，属于“三线”支持人员。
“二线”和“三线”支持人员不派驻现场，仅是在运维流程需要的时候才参与其中，流程结束，人员也将退出。
- 故障分级支持
针对XXX政府门户网站内容管理平台运维服务项目，我们将组建现场一线、公司总部二线、外援三线不同技能和专业水平的服务团队，按照基于 ITIL 的服务流程提供服务。
1、一线
服务台是面向客户的统一服务接口，负责受理客户提出的服务需求（包括故障申告）；负责对服务范围内的服务需求（包括故障申告）进行处理和任务分派，并跟踪和反馈处理情况；派驻现场一线的技术支持人员接受故障任务分派后，进行不同岗位的处理和协作。
2、二线
由公司总部技术专家、技术骨干、软件工程师组成，负责解决现场派驻服务不能解决的问题。
3、三线
由第三方供应商、高级技术专家、顾问等组成，负责协助现场服务组处理故障，必要时赴现场处理故障；主动发现、分析和解决问题；负责提供远程监控及按需现场服务中的其他相关服务。 - 技术结构全面
运维人员的技术掌握全面，涵盖软硬件整个层面。硬件方面掌握主流多种网络设备、服务器设备、安全设施、存储器设备等；系统软件方面熟悉Windows、Unix、Linux三大主流操作系统，Oracle、SQL Server、DB2等大型数据库，WebSphere、WebLogic、Tomcat、IIS等多种应用中间件；软件开发方面深入掌握J2EE和Net两大体系，精通B/S开发，精通多种语言。 - 关键角色备份
运维项目中主要涉及到的技术角色有“硬件集成”、“软件集成”、“数据管理”、“内容维护”、“软件开发”、“软件测试”和“美工设计”等，在关键角色职责方面，大部分都可以由2人以上担任，即关键角色重叠备份，提高技术储备能力和实际运维水平，同时也可以防范人员流动造成的部分技术空白风险。
人员安排
XXX运维团队人员安排如下：
| 序号 | 类型 | 人数 | 姓名 | 主要工作内容 | 经验 | 认证 |
|---|
| 1 | 运维经理 | 1 | | 根据客户方的合理需求，协调资源完成客户方交办的各项工作 | ６年工作经验，具有政府网站运维管理经验。 | PMP认证 |
| 2 | 系统架构工程师（技术支持工程师） | 1 | | 网站软、硬件平台日常运维 | ７年政府网络、系统、数据库、中间件运维经验。 | 高级程序员 |
| 3 | 系统架构工程师（技术支持工程师） | 1 | | 网站软、硬件平台日常运维 | ６年政府网站网络、系统、数据库、中间件运维经验。 | 网络工程师 |
| ４ | 中文编辑 | 1 | | 网站主站页面及相关栏目内容的维护。 | ６年政府网站从业经验，能够熟练使用XXX网站信息管理系统。 | |
| ５ | 中文编辑 | 1 | | 网站主站页面及相关栏目内容的维护。 | ６年政府网站从业经验，能够熟练使用XXX网站信息管理系统。 | CEAC国家信息化计算机教育认证 |
| ６ | 英文编辑 | 1 | | 英文网站页面及相关栏目内容的翻译、维护的工作 | ５年相关工作经验。 | 英语专业八级 |
| ７ | 流媒体工程师 | 1 | | 编辑、录制视频并进行发布 | ６年政府网站从业经验，熟悉各类媒体文件特性。 | 高级程序员 |
| ８ | 网站开发工程师 | 1 | | 网站系统改版开发 | ８年网站开发经验；具备基于XXX网站现有内容管理系统进行二次开发能力。 | 高级软件工程师证书 |
| ９ | 美工 | 1 | | 网站页面设计及专题、专栏页面设计 | ６年以上相关工作经验。 | 网页设计师,信息产业部通信行业职业技能鉴定指导中心 |
团队建设
人员培训和发展
IT运维人员的培训与发展是IT运维组织充分挖掘人力资源潜力的一项重要活动。培训的目的和作用是：
1、通过传递和交流知识（信息），提供给有关人员必要的技能，使其成功有效地实施和运营服务管理流程；
2、加速实现持续服务改进计划的预期效益并最大化整体计划成功的可能性；
3、促使所有相关人员清楚和理解整体计划和有关术语；
4、为相关学习小组提供讨论的平台；
5、为发现和减少可能的问题和不正确的实施方法提供了平台和知识；
6、帮助发现缺乏的技能并采取相应改进措施。
培训的必要性
首先，从培训接受者的角度看，培训可能是对其前期工作成绩的奖赏或是长期工作后的一种调剂。但实际上培训是提供高质量产品和服务所必不可少的一项工作，它有助于员工理解组织和客户双方的需求，从而提高他们的工作效率和反应速度。
其次，从组织的角度看，即使培训花费很大且很难计算投资回收，一个训练有素和知识渊博的员工更能理解客户和组织双方的要求，并能更灵活、迅速和有效地处理这些要求。
再次，从客户的角度看，服务人员的灵活性、反应速度、理解能力、移情程度（认同和理解别人的处境、感情和动机）及产品和服务知识都是影响其满意度的重要因素。因此，提供服务的组织必须使员工具有适当的技巧、知识和能力并能跟上商业、客户和行业发展趋势和最佳实践。
最后，很明显，如果提供新的产品和服务给客户，就必须先使员工对这些产品和服务有个全面清楚的了解。这只能，并且最好是，通过培训完成。
培训对象
确定谁应该接受培训很大程度上取决于这个人的工作任务和责任。通过分析培训需求，发现不足，确定相应需要培训的人员，并根据实际情况制定培训计划。
确定接受培训的人员还需考虑组织和客户的业务需求。经常我们会犯的错误是过度重视技术方面的培训而忽略了业务和客户。
此外，确定某人是否要接受培训或接受何种程度的培训还要考虑这个人所承担的任务和责任。任务越多，责任越大，则他接受的培训应该越广泛和深入。比如，服务台经理可能就需要接受全面的IT服务管理经理层次的培训以理解和确保服务台职能与其它关键管理流程如变更管理、问题管理和配置管理之间的协调，同时他还应该接受服务台专业级的培训以获得必要的发展和管理所需的技能。
培训计划
（1）培训要有计划。最好在持续服务改进计划中就制定整体培训计划。这样可以确保整个培训活动是根据组织现状及业务和客户需求制定的，并提早安排进行培训所需资源和解决培训过程中可能会出现的问题，此外，它也有利于员工预先了解自己需要提升之处和需要参加的培训活动并提前做出安排，避免影响正常工作。
（2）培训就像前面提到的“管理沟通”一样，不是“一劳永逸”。它要根据情况的发展、客户需求和期望的变化做出相应的局部或全面调整。
（3）培训讲求的是实际效果，要避免“走过场”。为此，可以强行规定某些员工在规定时间内必须通过某个级别的认证考试，比如IT服务管理基础认证、专家认证和经理认证。
培训方式与内容
培训方式也是一个要考虑的关键问题。主要有五种：
1、外部培训课程；
2、内部培训课程；
3、程序化教学（计算机辅助教学、远程教学和电子教学）；
4、讲座或研讨会（特别适合于针对某个特定主题的）；
5、在岗培训；
到底采用哪种方式受到多个因素的影响，包括培训对象、业务需求和客户需求等。
培训内容主要包括：
1、业务知识；
2、各种技能；
3、ITIL体系；
4、软技能（沟通、倾听和谈判等）；
5、运维制度和工作守则等。
运维协作环境
为了保证网站运维的质量及响应时间，XXX信息中心向XXX公司公司针对本项目组建的运维团队提供以下协作环境：
- 提供给服务商现有的网站运维相关资料、技术相关权限。提供运维项目基本设备、技术资料及相关原厂服务。
- 提供临时驻场工位4至5个、网络接入端口、接入方式、内外网接入设备等，提供相应技术接口人协助驻场人员及相关人员工作。
- 提供驻场人员服务期间入场权限、准入许可。 包括入场权限、系统准入权限、机房准入权限、网络接入权限、相应管理制度。
- 提供招标方购买的第三方服务，协调第三方服务人员配合服务商进行系统故障恢复。
运维服务内容
网站内容保障服务
XXX公司应遵照现行的XXX网站内容管理系列制度及工作流程完成以下工作：
- 按照XXX网站内容管理规范，完善和改进XXX网站主站及XXX机关各子网站建设和管理工作；进行XXX网站的日常内容采集、加工、上传、分发、管理；完成年度内不少于一次的网站改版工作；
- XXX英文版网站内容维护，包括网站内容翻译、互动留言收集整理翻译、英文信息发布等；
- 公众互动板块各栏目的维护；
- XXX网站内容管理系统用户管理；
- 实施《网站业务工作单》中指定的工作内容；
- XXX网站整体版面优化、结构调整的建议、策划和实施；
- 国家重大节日、重大会议、重大事件期间的24小时编辑响应服务；
- 视频信息的数据发布工作；
- 制作XXX网站工作简报（每月）。
日常巡检服务
现场日常巡检服务是XXX公司对XXX数据库设备进行全面检查的服务项目，通过该服务可使客户获得设备运行的第一手资料，最大可能地发现存在的隐患，保障设备稳定运行。同时，XXX公司将有针对性地提出预警及解决建议，使客户能够提早预防，最大限度降低运营风险。
日常巡检安排
公司安排定期（每月/每天/上午下午各一次）例行巡检和预防性维护，内容包括：
- 设备运行物理状态（每月/次）；
- 电源稳定性和线路检查（每天/次）；
- 系统性能检查（每月/次）；
- 逻辑卷检查（每月/次）；
- 内存交换区检查（每月/次）；
- 系统硬件诊断（每月/次）；
- 数据安全存储检查（每天/次）；
- 数据备份状况（每天/次）；
- 系统错误报告的分析、记录和清理（每天/次）；
- 及时更换损坏的或有潜在故障的部件（每月/次）；
- 设备物理检查(包括机体、风扇、风道及过滤器等)与清洁（每月/次）；
- 针对巡检工作应提交完善的巡检报告，并且存档、编辑成册，每月月初提交，以便日后清查。
- XXX网站数据库的巡检工作，XXX网站数据库日常监控，每日至少2次，分上下午分别进行。
出具巡检报告
提供故障报告等触发性报告。
1、日常巡检报告等日常报告。
2、周报、月报、季报、半年报、年报等总结性报告。
报告内容包括：检查内容、操作步骤、检查结果、操作人、操作时间、意见与建议等。
硬件巡检列表（在用）
| 序号 | 设备型号 | 设备用途 | 数量（台） |
|---|
| 1 | | | |
| 2 | | | |
| 3 | | | |
| 4 | | | |
| 5 | | | |
| 6 | | | |
| 7 | | | |
| 8 | | | |
| 9 | | | |
| 10 | | | |
| 11 | | | |
| 12 | | | |
| 13 | | | |
| 14 | | | |
| 15 | | | |
| 16 | | | |
| 17 | | | |
| 18 | | | |
| 19 | | | |
| 20 | | | |
| 21 | | | |
| 22 | | | |
| 23 | | | |
| 24 | | | |
| 25 | | | |
| 26 | | | |
| 27 | | | |
| 28 | | | |
| 29 | | | |
| 30 | | | |
虚拟机巡检列表（在用）
软件巡检列表（在用）
网站安全服务
- XXX网站7X24小时网站监控服务
- 网站安全性检查
按照XXX网站技术规范和安全管理规范，对网站应用软件、中间件以及数据库进行日常安全性检查。 - 网站服务器以及网络安全性检查
按照XXX网站技术规范和安全管理规范，定期对服务器操作系统进行安全性检查以及进行系统杀毒；负责XXX内网论坛（discuz）安全；负责网页防篡改软件（IGuard）安全。 - 数据库备份及备份验证
按照XXX网站技术规范和安全管理规范，对网站数据库进行定期备份以及备份恢复验证，保证数据的安全性、准确性、完整性和可用性。XXX网站数据备份及数据恢复，根据网站情况目前均采用本机进行数据备份及恢复。
XXX网站7X24小时网站监控服务
监控原则
- 我们将对系统进行7*24不间断监控；
- 监控岗保证一直有人值守；
- 每日分别于上、下午对服务器进行巡检，并于当天提交运维监控报告；
监控方案
- 网站访问监控
在网站访问监控功能中，系统监控内容包括网站名称、网址、监控类型、最后检测时间、响应时间及本日产生的上传下载流量等。点击“查看”后可查看更详细的网址监控项目，包括响应时间、连接数、网络流量，以及浏览用户在网站提交的纠错内容等。
- 响应时间
每间隔指定时间Ping指定的网址，并从返回的值中计算指定网站的响应时间。
监控详情：点击菜单“网站访问监控”-“网站访问监控详情”，系统在列表中显示每个已经添加并指定需要监控的网址，并在列表中显示该网址的响应时间。
数据采集：系统按照在“监控网址管理”中的设置，按指定间隔Ping出该网址的响应时间，并将数据保存至监控数据库中。 - 连接数
每间隔指定时间，取得指定网站的连接数。
监控详情：点击菜单“网站访问监控”-“网站访问监控详情”，系统在列表中显示每个已经添加并指定需要监控的网址，并在列表中显示该网址的当前连接数量。
数据采集：系统按照在“监控网址管理”中的设置，按指定间隔测试该网址的当前连接数量，并将数据保存至监控数据库中。 - 网络流量
每间隔指定时间，取得并统计指定网站的网络流量，上传和下载流量分别显示。
监控详情：点击菜单“网站访问监控”-“网站访问监控详情”，系统在列表中显示每个已经添加并指定需要监控的网址，并在列表中显示该网址的累计网络流量。
数据采集：系统按照在“监控网址管理”中的设置，按指定间隔测试该网址的累计网络流量，并将数据保存至监控数据库中。 - 网站页面纠错
在特定（或全部）页面嵌入脚本，当浏览的用户发现页面内容有误时提交后，管理员可以从此功能中发现有误的内容并根据实际情况修正。
监控详情：点击菜单“网站访问监控”-“网站内容纠错”，系统在列表中按日期显示每个页面链接及提交的错误内容，以供管理员参考并更正。
数据采集：当浏览的用户发现页面内容有误时，可以通过选中内容然后按一个快捷键（如Ctrl+Enter）提交，页面直接保存相关信息至数据表中。 - 统计分析
针对网站监控中的各项指标进行统计分析，统计的条件包括时间范围、网址及指标值范围等。
监控情况统计表：统计指定时段内，网站各项监控指标的监控值。
监控预警趋势表：统计指定时段内，网站监控指标的统计值及趋势走向，同时以表格和图表形式展示。
监控预警统计表：统计指定时段内，全部（或指定）网站中，已经产生的（邮件或短信）预警的次数。 - 监控网站管理
添加需要监控的网站，从网址或IP确定需要监控的网站页面。可以选择哪些设备需要发送告警信息。预警级别分为两级，预警级别（蓝色）及告警级别（红色），达到告警级别后系统将按设置发送邮件或短信对管理员进行提醒。
可以更改每个网址的序号，在网址访问监控界面列表显示时，以序号为顺序升序显示。勾选“是否监控”并保存后，系统开始以指定的频率读取相关的监控数值并保存。
- 设备监控
在设备监控界面中，列表显示了全部设备的最近一次监控情况，包括设备名称、IP、最后检测时间、各项监控数值及设备状态是否正常等。可以在左上方选择不同的分组以关注不同分组的设备，也可以勾选右上方的“仅显示异常服务器”以迅速找到运行异常的设备。
- Ping返回时间
每隔一段时间，首先Ping设备判断设备是否能正常连接，以及连接所需的时长等，较长的返回时间或无响应通常表示设备可能已经发生故障。
监控详情：点击菜单“设备监控”-“设备监控详情”，系统在列表中显示每台已经添加并指定需要监控的计算机设备，并在列表显示该计算机设备的Ping返回时间。
数据采集：系统按照在“监控设备管理”中的设置，按指定间隔读取该计算机设备的监控数值，并将数据保存至监控数据库中。 - CPU使用率查询
每隔一段时间，检测目标计算机上CPU的使用率情况。CPU使用率反映的是当前CPU的繁忙程度。
监控详情：点击菜单“设备监控”-“设备监控详情”，系统在列表中显示每台已经添加并指定需要监控的计算机设备，并在列表显示该计算机设备的CPU使用率情况。
数据采集：系统按照在“监控设备管理”中的设置，按指定间隔读取该计算机设备的CPU使用率，并将数据保存至监控数据库中。 - CPU负载
每隔一段时间，检测目标计算机上CPU的负载情况。CPU负载指某段时间内占用CPU时间的进程和等待CPU时间的进程数，这里等待CPU时间的进程是指等待被唤醒的进程，不包括处于wait状态进程。
监控详情：点击菜单“设备监控”-“设备监控详情”，系统在列表中显示每台已经添加并指定需要监控的计算机设备，并在列表显示该计算机设备的CPU负载情况。
数据采集：系统按照在“监控设备管理”中的设置，按指定间隔读取该计算机设备的CPU负载，并将数据保存至监控数据库中。 - 内存使用率
每隔一段时间，检测目标计算机上内存情况。内存使用率指已经使用的物理内存与全部物理内存的比率。
监控详情：点击菜单“设备监控”-“设备监控详情”，系统在列表中显示每台已经添加并指定需要监控的计算机设备，并在列表显示该计算机设备的内存使用率情况。
数据采集：系统按照在“监控设备管理”中的设置，按指定间隔读取该计算机设备的内存使用率，并将数据保存至监控数据库中。 - 磁盘空间使用率
每隔指定时间，检测目标计算机上磁盘空间使用率情况。
监控详情：点击菜单“设备监控”-“设备监控详情”，系统在列表中显示每台已经添加并指定需要监控的计算机设备，并在列表显示该计算机设备的磁盘使用率情况。
数据采集：系统按照在“监控设备管理”中的设置，按指定间隔读取该计算机设备的磁盘使用率，并将数据保存至监控数据库中。 - 网络流量
间隔指定时间，检测目标计算机上网络流量情况，包括网络上传流量与网络下载流量。流量可简略反映计算机的网络传输流量是否在正常范围内。
监控详情：点击菜单“设备监控”-“设备监控详情”，系统在列表中显示每台已经添加并指定需要监控的计算机设备，并在列表显示该计算机设备的网络上传下载流量。
数据采集：系统按照在“监控设备管理”中的设置，按指定间隔读取该计算机设备的网络流量，并将数据保存至监控数据库中。 - 系统进程数
每隔一段时间，检测目标计算机上系统进程数量。系统进程数量表示当前监控的计算机在运行中的进程，进程越多，通常占用的CPU及内存资源也越多。
监控详情：点击菜单“设备监控”-“设备监控详情”，系统在列表中显示每台已经添加并指定需要监控的计算机设备，并显示该计算机设备的系统进程数量。
数据采集：系统按照在“监控设备管理”中的设置，按指定间隔读取该计算机设备的，并将数据保存至监控数据库中。 - 统计分析
针对设备监控中的各项指标进行统计分析，统计的条件包括时间范围、设备名称及指标值范围等。
监控情况统计表：统计指定时段内，设备各项监控指标的监控值。
监控指标趋势表：统计指定时段内，设备监控指标的统计值及趋势走向，同时以表格和图表形式展示。
监控预警统计表：统计指定时段内，全部（或指定）设备中，已经产生的（邮件或短信）预警的次数。 - 监控设备管理
添加需要监控的设备，从IP及端口唯一指定需要监控的设备，并加以描述。可以选择哪些设备需要发送告警信息。预警级别分为两级，预警级别（蓝色）及告警级别（红色，达到告警级别后系统将按设置发送邮件或短信对管理员进行提醒。
可以更改每个网址的序号，在网址访问监控界面列表显示时，以序号为顺序升序显示。
在列表中可以设置每个设备的分组信息，如“外网服务器”、“内网服务器”或“网络设备”，以查看监控情况时能迅速查看及判断设备监控情况。
勾选“是否监控”并保存后，系统开始以指定的频率读取相关的监控数值并保存。
- 应用服务监控
监控指定应用服务（如Apache、WebSphere及Tomcat等）的运行情况，并对无法连接的应用服务，以及监控指标超过指定阈值的情况进行邮件或短信告警。
对于WebSphere的监控，很可能无法取得相关的监控项目值，在这种情况下可能需要通过Tivoli Performance Viewer工具来获得监控项目和数据。 - 数据库监控
监控指定数据库实例的运行情况，并对无法连接的数据库，以及监控指标超过指定阈值的情况进行邮件或短信告警。
日常检查监测表格
网站日常监测表格监测时间： 年 月 日 星期一 (8:30---17:00) 记录人：
| 服务器IP | 服务器功 能 | 监测项目 | 检测方法 | 正常范围 | 实测情况 | 结果 | 备 注 |
|---|
| WEB服务器 | IE浏览 | | | | 正常 | |
| iguard服务进程 | ps aux |grep iguard | 2 | | 正常 |
| Apache进程 | ps aux |grep httpd | 1--30 | | 正常 |
| CPU及系统负载 | top | 0--2 | | 正常 |
| 硬盘占用 | df -h | 空闲20% | | 正常 |
| 内存占用 | free | 5M-4G | | 正常 |
| 系统时间 | date | 1--5分钟 | | 正常 |
| Iguard篡改日志 | more /usr/local/iguard/syncserver/logs/ |grep warn | | | 正常 |
| 用户登录情况 | last lastlog more /var/log/messages | grep failure | 10网段 | | 正常 |
| 公众参与平台 | IE浏览 | | | | 正常 | |
| CPU及系统负载 | Top | 0--2 | | 正常 |
| 硬盘占用 | df -h | 空闲20% | | 正常 |
| 数据库进程 | ps aux | grep oracle ps aux | grep LISTENER | 1--50 | | 正常 |
| WEB_APP进程 | ps aux |grep WebSphereps aux |grep tomcat | 50--200 | | 正常 |
| AppErrolog | more /opt/WebSphere/AppServer/logs/server1/ | | | 正常 |
| AppOutlog | more /opt/WebSphere/AppServer/logs/server1/ | | | 正常 |
| Tomcat errlog | more /home/XXX/XXXwas/XXXwas40/logs/error/ | | | 正常 |
| Oracle_ERR_log | more /home/oracle/admin/WWW/bdump/ | | | 正常 |
| 端口监听情况 | netstat –ntlp (XXX WCM-JAVA:8080 9080 LISTENER:1521) | 运行正常 | | 正常 |
| 用户登录情况 | last lastlog more /var/log/messages | grep failure | 10网段 | | 正常 |
| Wcm_db | 数据库进程 | ps aux | grep oracle ps aux | grep LISTENER | 1-50 | | 正常 | |
| Oracle_ERR_log | more /home/oracle/admin/WWW/bdump/ | | | 正常 |
| Iguard篡改警告 | more /usr/local/iguard/stagingd/logs/ | | | 正常 |
| CPU及系统负载 | top | 0--3 | | 正常 |
| 硬盘占用 | df -k | 空闲20% | | 正常 |
| 系统时间 | date | 1--5分钟 | | 正常 |
| 端口监听情况 | netstat –ntlp(XXXWCM-JAVA:9080 9091 vsftpd:21 LISTENER:1521) | 运行正常 | | 正常 |
| 用户登录情况 | last lastlog more /var/log/messages | grep failure | 10网段 | | 正常 |
| 繁体版 | IE浏览 | | | | 正常 | |
| CPU及系统负载 | top | 0--2 | | 正常 |
| 硬盘占用 | df -k | 空闲20% | | 正常 |
| http进程 | ps aux |grep httpd | 1--20 | | 正常 |
| 端口监听情况 | netstat -ntlp(80 8080 vsftpd:21) | 运行正常 | | 正常 |
| 用户登录情况 | last lastlog more /var/log/messages | grep failure | 10网段 | | 正常 |
| Wcm_app | IE浏览 | | | | 正常 | |
| APP进程 | ps aux |grep Tomcat | wc -l | 1-10 | | 正常 |
| XXX wcm日志 | more /opt/XXXWCMV65/Tomcat/logs/ | | | 正常 |
| Iguard篡改警告 | more /usr/local/iguard/stagingd/logs/ | | | 正常 |
| CPU及系统负载 | top | 0--3 | | 正常 |
| 内存占用 | free | | | |
| 硬盘占用 | df -k | 空闲20% | | 正常 |
| 系统时间 | date | | | |
| 端口监听情况 | netstat –ntlp (gulmd:5006 5008 OraLISTENER:1521 clamd:6001) | | | |
| 用户登录情况 | last lastlog more /var/log/messages | grep failure | | | |
| 新表单 | IE后台浏览 | :9080/wcm | | | 正常 | |
| CPU及系统负载 | top | 0--2 | | 正常 |
| 硬盘占用 | df -k | 空闲20% | | 正常 |
| tomcat进程 | ps aux |grep WebSphere | 1--300 | | 正常 |
| 数据库进程 | ps aux | grep oracleWWW ps aux | grep LISTENER | 1--50 | | 正常 |
| 端口监听情况 | netstat –ntlp java:9080 9090 vsftpd:21 LISTENER:1521 | 运行正常 | | 正常 |
| 用户登录情况 | last lastlog more /var/log/messages | grep failure | 10网段 | | 正常 |
| 工业许可证 | IE后台浏览 | | | | 正常 | |
| CPU及系统负载 | top | 0--2 | | 正常 |
| 硬盘占用 | df -k | 空闲20% | | 正常 |
| tomcat进程 | ps aux |grep tomcat | 1 | | 正常 |
| 数据库进程 | ps aux | grep oracle ps aux | grep LISTENER | 50--120 | | 正常 |
| 端口监听情况 | netstat –ntlp java: 8080 80 vsftpd:21 LISTENER:1521 | 运行正常 | | 正常 |
| 用户登录情况 | last lastlog more /var/log/messages | grep failure | 10网段 | | 正常 |
| XXXBBS | IE浏览 | ./ | | | 正常 | |
| CPU及系统负载 | top | 0--2 | | 正常 |
| 硬盘占用 | df -k | 空闲20% | | 正常 |
| APP进程 | ps aux |grep httpd | 1--500 | | 正常 |
| Mysql进程 | ps aux |grep mysqld | 2 | | 正常 |
| 端口监听情况 | netstat –ntlp 80 mysqld:3306 vsftpd:21 | 运行正常 | | 正常 |
| 用户登录情况 | last lastlog more /var/log/messages | grep failure | 10网段 | | 正常 |
| XXX内网 | IE浏览 | ./ | | | 正常 | |
| CPU及系统负载 | top | 0--2 | | 正常 |
| 硬盘占用 | df -k | 空闲20% | | 正常 |
| APP进程 | ps aux |grep httpd | 1--500 | | |
| 端口监听情况 | netstat –ntlp 80 vsftpd:21 | 运行正常 | | 正常 |
| 用户登录情况 | last lastlog more /var/log/messages | grep failure | 10网段 | | 正常 |
| 流媒体服务 | IE浏览 | :5080/ | | | 正常 | |
| CPU及系统负载 | top | 0--2 | | 正常 |
| 硬盘占用 | df -k | 空闲20% | | 正常 |
| APP进程 | ps aux |grep red5 | wc -l | 1--50 | | 正常 |
| Tomcat进程 | ps aux |grep tomcat | wc -l | 1 | | 正常 |
| 端口监听情况 | netstat –ntlp tomcat:8080 mysqld:3306 vsftpd:21 | 运行正常 | | 正常 |
| 用户登录情况 | last lastlog more /var/log/messages | grep failure | 10网段 | | 正常 |
| 负载均衡 | IE管理 | :9090/admin | | | 正常 | |
| CPU及系统负载 | top | 0--2 | | 正常 |
| 硬盘占用 | df -h | 空闲20% | | 正常 |
| APP进程 | ps aux |grep | 1--20 | | 正常 |
| 端口监听情况 | netstat – :80 | 运行正常 | | 正常 |
| 统计用户连接数 | netstat -na | grep 80 | wc -l | 1--5000 | | 正常 |
| 用户登录情况 | last lastlog more /var/log/messages | grep failure | 10网段 | | 正常 |
注：所有平台需查看/tmp/log/是否有异常及文件大小,磁盘空间无特殊情况空闲空间20%
检查人签字：
网站安全性检查
XXX公司按照XXX网站技术规范和安全管理规范，对网站应用软件、中间件以及数据库进行日常安全性检查。确保网站能够正常访问；确保网站内容正确，发布内容一致；确保网站动态应用正常，并能够提供正常的服务。
针对XXX政府门户网站系统，我们采取有效的方法防止网页被攻击或恶意篡改，杜绝因攻击而带来的恶性事件发生。针对于更为重要的信息数据我们更需要提高安全防护的水平，确保网站系统的数据不被恶意修改，敏感的数据不被非法访问或泄露。具体的从以下几个方面进行：
阻断应用攻击
应用专业的应用防护设备进行防护，通过对输入内容的过滤及请求过滤实现对网站的保护。防止跨站脚本攻击、SQL注入等常见攻击。
屏蔽安全隐患
为了防止服务端敏感信息泄露，我们通过对现有网站的敏感信息进行屏蔽，如备份文件的下载、敏感数据库下载，管理后台的外网尝试等，另外还屏蔽编写程序过程中遗留下的程序注释，对服务出错信息进行有效屏蔽。
防止网页篡改
应用网页防篡改系统有效的防护机制，实时监测网站服务器的相关信息是否给非法更改，一旦发现被改则第一时间通知管理员，并形成详细的日志信息。但对外仍显示篡改前的正常页面，用户可正常访问网站。事后可对原始文件及篡改后的文件进行本地下载比较，查看篡改记录，恢复被篡改的页面。
网站服务器以及网络安全性检查
XXX公司按照XXX网站技术规范和安全管理规范，定期对服务器操作系统进行安全性检查以及进行系统杀毒；负责XXX内网论坛（discuz）安全；负责网页防篡改软件（IGuard）安全。确保网站网络连接正常；定期对服务器操作系统进行安全性检查以及进行系统杀毒，确保服务器设备正常，对具有安全隐患的设备及时更换，并向XXX相关领导及时汇报。
XXX公司对网站服务器及网络安全性检查，内容如下：
| 服务器IP | 服务器功能 | 监测项目 | 检测方法 | 正常范围 | 实测情况 | 结果 | 备 注 |
|---|
| WEB服务器 | IE浏览 | | | | 正常 | |
| iguard服务进程 | ps aux |grep iguard | 2 | | 正常 |
| Apache进程 | ps aux |grep httpd | 1--30 | | 正常 |
| CPU及系统负载 | top | 0--2 | | 正常 |
| 硬盘占用 | df -h | 空闲20% | | 正常 |
| 内存占用 | free | 5M-4G | | 正常 |
| 系统时间 | date | 1--5分钟 | | 正常 |
| Iguard篡改日志 | more /usr/local/iguard/syncserver/logs/ |grep warn | | | 正常 |
| 用户登录情况 | last lastlog more /var/log/messages | grep failure | 10网段 | | 正常 |
| 公众参与平台 | IE浏览 | | | | 正常 | |
| CPU及系统负载 | Top | 0--2 | | 正常 |
| 硬盘占用 | df -h | 空闲20% | | 正常 |
| 数据库进程 | ps aux | grep oracle ps aux | grep LISTENER | 1--50 | | 正常 |
| WEB_APP进程 | ps aux |grep WebSphereps aux |grep tomcat | 50--200 | | 正常 |
| AppErrolog | more /opt/WebSphere/AppServer/logs/server1/ | | | 正常 |
| AppOutlog | more /opt/WebSphere/AppServer/logs/server1/ | | | 正常 |
| Tomcat errlog | more /home/XXX/XXXwas/XXXwas40/logs/error/ | | | 正常 |
| Oracle_ERR_log | more /home/oracle/admin/WWW/bdump/ | | | 正常 |
| 端口监听情况 | netstat –ntlp (XXX WCM-JAVA:8080 9080 LISTENER:1521) | 运行正常 | | 正常 |
| 用户登录情况 | last lastlog more /var/log/messages | grep failure | 10网段 | | 正常 |
| Wcm_app | IE浏览 | | | | 正常 | |
| APP进程 | ps aux |grep WebSphere ps aux |grep vsftpd | 50--300 | | 正常 |
| 数据库进程 | ps aux | grep oracle ps aux | grep LISTENER | 1-50 | | 正常 |
| AppErrolog | more /opt/WebSphere/AppServer/logs/server1/ | | | 正常 |
| XXX wcm日志 | more /home/XXX/wcmlogs/ | | | 正常 |
| Oracle_ERR_log | more /home/oracle/admin/WWW/bdump/ | | | 正常 |
| Iguard篡改警告 | more /usr/local/iguard/stagingd/logs/ | | | 正常 |
| CPU及系统负载 | top | 0--3 | | 正常 |
| 硬盘占用 | df -k | 空闲20% | | 正常 |
| 系统时间 | date | 1--5分钟 | | 正常 |
| 端口监听情况 | netstat –ntlp(XXXWCM-JAVA:9080 9091 vsftpd:21 LISTENER:1521) | 运行正常 | | 正常 |
| 用户登录情况 | last lastlog more /var/log/messages | grep failure | 10网段 | | 正常 |
| 繁体版 | IE浏览 | | | | 正常 | |
| CPU及系统负载 | top | 0--2 | | 正常 |
| 硬盘占用 | df -k | 空闲20% | | 正常 |
| http进程 | ps aux |grep httpd | 1--20 | | 正常 |
| 端口监听情况 | netstat -ntlp(80 8080 vsftpd:21) | 运行正常 | | 正常 |
| 用户登录情况 | last lastlog more /var/log/messages | grep failure | 10网段 | | 正常 |
| 数据库 | 数据库进程 | ps aux | grep oracle ps aux | grep LISTENER | | | | |
| Oracle_ERR_log | more /oracle/app/oracle/admin/WWW/bdump/ | | | |
| HA 进程 | ps aux | grep lock_gulmd ccsd cman fenced rgmanager | | | |
| CPU及系统负载 | top | | | |
| 硬盘占用 | df -k | | | |
| 内存占用 | free | | | |
| 内存异常情况 | vmstat 2 | | | |
| 系统时间 | date | | | |
| 端口监听情况 | netstat –ntlp (gulmd:5006 5008 OraLISTENER:1521 clamd:6001) | | | |
| 用户登录情况 | last lastlog more /var/log/messages | grep failure | | | |
| 新表单 | IE后台浏览 | :9080/wcm | | | 正常 | |
| CPU及系统负载 | top | 0--2 | | 正常 |
| 硬盘占用 | df -k | 空闲20% | | 正常 |
| tomcat进程 | ps aux |grep WebSphere | 1--300 | | 正常 |
| 数据库进程 | ps aux | grep oracleWWW ps aux | grep LISTENER | 1--50 | | 正常 |
| 端口监听情况 | netstat –ntlp java:9080 9090 vsftpd:21 LISTENER:1521 | 运行正常 | | 正常 |
| 用户登录情况 | last lastlog more /var/log/messages | grep failure | 10网段 | | 正常 |
| 工业许可证 | IE后台浏览 | | | | 正常 | |
| CPU及系统负载 | top | 0--2 | | 正常 |
| 硬盘占用 | df -k | 空闲20% | | 正常 |
| tomcat进程 | ps aux |grep tomcat | 1 | | 正常 |
| 数据库进程 | ps aux | grep oracle ps aux | grep LISTENER | 50--120 | | 正常 |
| 端口监听情况 | netstat –ntlp java: 8080 80 vsftpd:21 LISTENER:1521 | 运行正常 | | 正常 |
| 用户登录情况 | last lastlog more /var/log/messages | grep failure | 10网段 | | 正常 |
| XXXBBS | IE浏览 | ./ | | | 正常 | |
| CPU及系统负载 | top | 0--2 | | 正常 |
| 硬盘占用 | df -k | 空闲20% | | 正常 |
| APP进程 | ps aux |grep httpd | 1--500 | | 正常 |
| Mysql进程 | ps aux |grep mysqld | 2 | | 正常 |
| 端口监听情况 | netstat –ntlp 80 mysqld:3306 vsftpd:21 | 运行正常 | | 正常 |
| 用户登录情况 | last lastlog more /var/log/messages | grep failure | 10网段 | | 正常 |
| XXX内网 | IE浏览 | ./ | | | 正常 | |
| CPU及系统负载 | top | 0--2 | | 正常 |
| 硬盘占用 | df -k | 空闲20% | | 正常 |
| APP进程 | ps aux |grep httpd | 1--500 | | |
| 端口监听情况 | netstat –ntlp 80 vsftpd:21 | 运行正常 | | 正常 |
| 用户登录情况 | last lastlog more /var/log/messages | grep failure | 10网段 | | 正常 |
| 流媒体服务 | IE浏览 | | | | 正常 | |
| CPU及系统负载 | top | 0--2 | | 正常 |
| 硬盘占用 | df -k | 空闲20% | | 正常 |
| APP进程 | ps aux |grep rmserver | 1--50 | | 正常 |
| Tomcat进程 | ps aux |grep tomcat | 1 | | 正常 |
| Mysql进程 | ps aux | grep mysqld | 2 | | 正常 |
| 端口监听情况 | netstat –ntlp tomcat:8080 mysqld:3306 vsftpd:21 | 运行正常 | | 正常 |
| 用户登录情况 | last lastlog more /var/log/messages | grep failure | 10网段 | | 正常 |
| 负载均衡 | IE管理 | :9090/admin | | | 正常 | |
| CPU及系统负载 | top | 0--2 | | 正常 |
| 硬盘占用 | df -h | 空闲20% | | 正常 |
| APP进程 | ps aux |grep | 1--20 | | 正常 |
| 端口监听情况 | netstat – :80 | 运行正常 | | 正常 |
| 统计用户连接数 | netstat -na | grep 80 | wc -l | 1--5000 | | 正常 |
| 用户登录情况 | last lastlog more /var/log/messages | grep failure | 10网段 | | 正常 |
数据库备份及备份验证
XXX公司按照XXX网站技术规范和安全管理规范，制定科学有效的数据备份与灾害恢复计划，对XXX政府门户网站内容管理平台范围内要求的网站、应用及数据进行备份。
根据网站情况目前采用已爱数容灾备份系统为主、服务器数据备份及恢复为补充的方式。具体情况如下：
爱数容灾备份：1.系统备份：按每个月对服务器进行系统备份一次，关键业务系统备份1个月，非关键业务系统备份1个月。
2.文件备份：按每月进行一次服务器完全备份，重要服务器每天有1次增量备份，非关键业务每周进行1次增量备份。部分业务占用存储量大按空间进行相应调整。
3.数据库备份：每天进行增量备份，每周进行一次完整备份。部分关键业务可以进行两次完整备份。
服务器数据备份：1、备份数据按每日备份一次。备份到存贮空间服务器的备份数据存放期为一个月，本机备份数据存放期为一年，备份数据保存量由各个服务器的可用空间决定。
1） XXX网站新闻发布数据库服务器相关oracle数据
2）XXX网站互动内容管理服务器相关应用数据及oracle数据
3）XXX网站新闻发布数据库服务器相关应用。
2、备份数据按每日备份一次。备份到存贮空间服务器的备份数据存放期为一个星期，本机备份数据存放期为一年，备份数据保存量由各个服务器的可用空间决定。
1）XXX网站WEB服务器相关应用数据
2）XXX网站APP服务器相关应用数据
3）XXX日志服务器相关应用数据
3、备份数据按每日备份一次。备份到存贮空间服务器的备份数据存放期为一个星期，本机备份数据存放期为一个月，备份数据保存量由各个服务器的可用空间决定。
1）XXX网站内网论坛管理服务器相关应用数据及mysql数据
2）XXX网站内网网站管理服务器相关应用数据
3）XXX门户网站流媒体管理服务器相关流媒体应用数据
4）XXX网站公众留言相关公众留言应用数据及oracle数据
5）全国工业生产许可证查询服务器相关应用数据及oracle数据
应对黑客攻击
XXX公司按照XXX网站技术规范和安全管理规范进行应对黑客攻击，保证网站防篡改系统正常运行且发挥作用，确保XXX网站不被黑客攻破，防止黑客篡改网站内容及数据的破坏。
XXX公司定期监控系统访问记录，及时查找异常访问记录并查找原因，消除隐患；并及时修复不安全漏洞，消除隐患；定期出具服务器运行情况及被攻击情况报告。
1、工作时间内，发现黑客攻击应在第一时间通知具体责任人。
具体责任人接到通知后，应详细记录有关现象和显示器上出现的信息，将被攻击的服务器等设备从中隔离出来，保护现场。同时通知总负责人，召集相关技术人员共同分析攻击现象，提供解决方法，主机系统管理员和应用软件系统管理员负责被攻击或破坏系统的恢复与重建工作。视情况向部领导汇报事件情况。
2、非工作时间内发现的攻击事件，值班人员应首先立即切断被攻击外网服务器的网络连接，并做好相关记录；然后通知具体责任人按流程处理。
网站故障处理
网站在运维过程中出现的系统故障，XXX公司应进行紧急处理和故障修复。在故障处理和修复过程中，XXX公司负责系统故障分析、问题定位并提供系统故障修复方案，XXX认可后并执行系统故障修复方案，在系统故障修复方案中涉及XXX购买的第三方服务，需XXX负责协调第三方服务人员配合XXX公司进行系统故障恢复。
故障恢复后，需要对故障的发生、处理过程和结果进行记录，并形成故障报告，汇报给XXX。
灾备演练
依据XXX信息中心灾难应急预案进行灾备演练。
发生安全事件时，XXX公司人员需1小时内到达现场，一般及较大故障要在1小时内恢复XXX网站页面的正常浏览；对于特别重大而涉及面广的安全事件，要在4小时内恢复XXX网站页面的正常浏览。
发现XXX网站页面和各司局站点页面无法浏览；被黑客攻击等故障现象，经验证之后立刻给网站管理处打电话报告情况，判断为黑客攻击情况得到领导指示，可用vpn关闭和，并第一时间赶到现场。
事件定级
信息安全突发事件级别分为四级：一般(IV级)、较大(III级)、重大(II级)和特别重大(I级)。
一般(IV级)：指能够导致较小影响或破坏的信息安全事件。
较大(III级)：指能够导致较严重影响或破坏的信息安全事件。
重大(II级)：指能够导致严重影响或破坏的信息安全事件。
特别重大(I级)：指能够导致特别严重影响或破坏的信息安全事件。
对于处理故障时间,遇到信息安全突发事件按以下四个级别执行：
一般(IV级)，处理故障时间不能超过4个小时。
较大(III级)，处理故障时间不能超过8个小时；
重大(II级)，处理故障时间不能超过12个小时；
特别重大(I级)，处理故障时间不应超过24小时；
故障解决后24小时内，提交故障处理报告。说明故障种类、故障原因、故障解决中使用的方法及故障损失等情况。
应急处理流程
“IV/一般”级别的信息安全事件由部门通过预警信息沟通，自行处置。
当项目实施小组成员得到 “三级/较大”、“二级/重大”、“一级/特别重大”级别的信息安全事件的报告时，应报请网站处领导，启动应急预案并进入相应的应急响应工作程序。
在“三级/较大”、“二级/重大”、“一级/特别重大”安全事件发生或可能发生的情况下，按照以下流程进行处理：
（1）项目实施小组向网站处领导通报信息安全事件情况，得到指令后立即启动相应的应急处理程序。
（2）项目实施小组及时向网站处领导报告信息安全事件的发展情况，网站处领导应将情况及时上报中心主任。
组织机构与职责
- 应急处理领导小组
职责：组织编制应急处理方案、领导指挥应急处理过程，向上级部门汇报处置情况。 - 值班巡检小组
职责：根据日常巡检制度对系统进行巡检和监控，发现问题时及时根据预案启动应急流程。 - 应急处理小组
职责：执行应急处理措施，向应急领导小组汇报处理过程和结果，并填写应急处理记录。 - 系统运维小组
职责：在非应急状态下负责系统的功能更新、安全加固，并根据环境配置变化及时更新应急处置手册并进行培训。
预案启动前提
当接到网景盛世公司报警电话，项目实施小组系统工程师迅速做出判断并验证故障现象。
例如：发现XXX网站页面和各司局站点页面无法浏览；被黑客攻击等故障现象，经验证之后立刻给网站管理处丰处（丰苏）、单处、郑工打电话报告情况，判断为黑客攻击情况得到领导指示，可用vpn关闭和，并第一时间赶到现场。
详细应急处置流程图如下：
现场故障排查详细流程
- 接到报警
- 当收到网景盛世发送的服务器报警短信息后，第一时间联系丰处，请示相应处理意见。如有网络可以进行相关页面查看，查看是否出现相关问题。
- 得到相关指示要求XXX处理时，最快时间到达XXX现场进行相关业务排查。
- 业务排查
1.查看服务器是否正常连通，进行相关服务器ping服务（如：ping ）
2.如果正常能够ping通，进行访问服务器的进程是不是正常（如：ps –ef | grep tomcat）
3.查看服务器的相关进程是不是正常启动
- 查看网站情况是否正常
- 内网浏览器访问和是不是正常，如果正常说明属于网络的问题，如果不正常说明是服务器的问题。
- 和查看iguard服务进程，查看命令为：ps –ef | grep iguard 如果有相应进程说明igrad同步端正常。
- 查看一下cpu及其负载情况。查看命令为：top 是不是负载过高引起系统运转缓慢。
- 查看一下硬盘占用空间是不是已经满了。查看命令为：df –h 查看空间是不是已经写满。
- 查看内存情况是不是有剩余，查看命令为：free。
- 查看igurad日志是不是正常。查看命令为：more /usr/local/iguard/syncserver/logs/ 查看有无异常情况出现。
如果apache服务有问题，可以进行重新启动，命令如下：
service httpd stop(apache关闭)
service httpd start（apache 启动）
如果iguard进程出现问题，可以联系相关iguard厂商协助解决。
- 查看发布平台
- 内网浏览器访问wcm是不是正常，如果正常说明XXX服务正常，如果不能访问需要查看相应服务器服务是否正常。
- 登陆查看tomcat进程是否正常ps –ef | grep Tomcat。查看iguard发布端是否正常ps –ef | grep igurad。
如tomcat进程不正常可以,
cd /opt/XXXWCMV65/Tomcat/bin
./stop进行关闭
./ 进行启动
如依然不正常可以联系XXX工程师协助解决。
如igurad不正常可以联系iguard工程师协助解决。
如遇到重大情况无法及时解决，将发布系统维护中页面暂时替换首页进行发布。等待问题解决后，按领导指示进行相应替换为正常页面。 - 查看iguard日志文件
cd /usr/local/iguard/stagingd/logs/
查看相应的日志文件alert-201209XX。log
进行分析。 - 查看wcm日志文件
cd /opt/XXXWCMV65/Tomcat/logs/ 查看相应 tail -f 或者more 文件日志。 - 查看cpu及其负载状况：执行命令为:top,查看是否运转正常。
- 查看磁盘运转是否正常，执行命令为：df –k 。
- 查看监听情况，执行命令为:netstat –ntlp 查看22端口和80端口是否正常。
- 查看发布平台数据库
- 查看oracle进程：执行命令为：
ps –ef | grep oracle 查看是否运行正常。
ps –ef | grep LISTENER 查看监听是否正常运转 - 查看监听端口：
执行命令为:netstat –ntlp 。是否为1521端口开放。 - 查看相应日志文件
tail -f /home/oracle/admin/WWW/bdump/
数据备份
XXX数据库文件已经备份到服务器oracle用户下/home/oracle/。
XXX 网页文件备份到服务器/home/liyonghong/目录下。
数据库文件可以拷贝到数据库服务器作为数据库服务器备份。
临时可以应用作为服务器硬件故障的补充。
应急处置工作要求
发生安全事件时，应急处置工作人员30分钟内到达现场（判断为黑客攻击情况，并得到领导指示，可用vpn关闭和），一般情况下一小时内解决故障，恢复运行；对于有些特别重大而涉及面广的安全事件，也要在4小时内解决，不能解决的要及时上报中心领导，并说明原因和处理办法，需要请求中心支援的及时向中心领导报告。
常见故障诊断及处理
- 服务器物理设备故障
- 故障现象
服务器无法正常连接，且设备面板指示灯有异常提示（细节参考服务器随机文档）。 - 检查及处理方式
观察服务器指示灯信号，并根据设备随机手册查找故障说明。
处理方式——检查设备的网线、电源线、光纤线缆是否松脱。
如外接设备无松脱现象，应尽快联系设备售后服务机构现场处理，不得随意拆卸设备部件自行维修。
- 网络设备/链路故障
注：此类故障发生几率一般较小，且通常会被总部先监控到。但当发生网站无法访问的故障时，维护人员应先排除是否由此类故障的可能性之后，再进行下一步排查工作。
- 故障现象
互联网访问链路中断，网站服务器无法被外部访问到。故障现象是内网访问网站正常，但不能通过互联网访问网站。 - 检查及处理方式
检查服务器自身服务是否正常运行
在服务器控制台桌面（注意：指通过服务器设备直连的显示器、键盘、鼠标等设备访问服务器）
打开IE或其他web浏览器，访问，如能正常显示首页，则表示服务器自身服务运行正常，可能是网络故障引起。
在监控终端中，使用如下命令：
ping
ping
如果返回超时，则表明网络故障可能发生在机房，请联系运行处协助处理。
如果返回正常，则表明网络故障可能发生在上一环节，可能是前端的负载均衡设备工作异常或网络链路中断，请同时联系运行处处理。
- XXX网站未能正常运行
- 故障分析
当前网络环境正常，但无法通过内、外网访问网站首页。客户端浏览器显示网站无法访问之类的错误提示。
导致该故障的可能原因有：
服务未启动或启动了错误的Apache版本。
系统自带软件防火墙或安全策略干扰 - 检查及处理方式
检查服务器自身服务是否正常运行
分别登录到两台Web服务器的远程SSH终端或服务器控制台终端，并切换到root帐户，输入如下命令：
ps aux|grep httpd
如果返回结果表明无httpd进程运行，需要重启Apache服务，操作命令为：
service httpd start
如经过以上方式的排查，仍未能解决问题，则可能是Apache配置错误导致网站服务工作不正常，可通过error_log文件进行详细检查。
- XXX网站响应缓慢
- 故障分析
网站能访问，但响应极其缓慢，打开网页时间远超正常范围。
导致该故障的可能原因有：
服务器磁盘设备故障导致I/O性能低下
服务器网卡故障
网络设备或线路繁忙
服务器忙于处理大规模的并发请求（很可能是DDoS攻击）
IHS自身不稳定导致资源耗尽而不能正常工作 - 检查及处理方式
检查机房网管监控中是否有网络流量异常现象。
检查服务器硬盘指示灯是否有故障提示。
检查当前的CPU和内容占用情况，观察httpd进程是否占用资源过多，操作命令：
top
检查服务器当前tcp连接情况，观察对80端口的访问请求是否过多（正常情况一般在1000以下）
netstat –an|grep :80 |wc –l
统计访问日志中的IP地址，观察是否有可疑的IP活动（访问次数明显过高）
cat access_log | awk '{print $1F}' | sort |uniq -c|sort -n
断开网线后，在服务器控制台桌面访问，如果访问速度正常，则表明服务器软、硬件工作正常。
- XXX网站页面更新不及时
- 故障分析
网站能访问，但网站中页面与后台发布信息不一致。
导致该故障的可能原因有：
WCM发布引擎未能正常生成HTML静态页面
文件未能正常同步到web服务器中
未能正常监控到WCM发布目录中文件变化情况 - 检查及处理方式
直接访问WCM服务器，检查页面是否更新正常
如果WCM服务器中网页也未能正常更新，可重新在WCM中发布页面，或重新启动WCM服务器。
如果WCM服务器中网页更新正常，则登录到服务器SSH终端，检查文件iguard服务是否工作正常：
ps aux|grep iguard
如该服务未能正常启动，可通过如下命令启动：
/usr/local/iguard/stagingd/admtool start
如果监控服务已经在运行，则检查web服务器端iguard服务是否工作正常
通过SSH终端登录到中，检查iguard服务是否工作正常
ps aux|grep iguard
如iguard服务未工作，可启动iguard服务
/usr/local/iguard/syncserver/admtool start
如以上方式均检查无问题，可在iguard服务器端，运行同步命令强制同步，并观察是否有错误信息输出。
同时检查web iguard服务器端中是否有错误提示
- 搜索引擎工作不正常
- 故障分析
网站能访问，但网站搜索引擎页面出现错误信息且无法正常返回查询结果。
导致该故障的可能原因有：
搜索引擎中未正常配置搜索相关路径反向代理
搜索引擎服务运行故障 - 检查及处理方式
检查IHS配置文件是否加入对服务器的反向代理
vi /etc/httpd/conf/
如未能加入，则加入相关配置后重新运行Apache
service httpd restart
如已经正确配置，则检查文本搜索引擎是否工作正常，并重启相关服务
- WCM集群版中用户文件不一致
- 故障分析
用户上传的文件无法正常访问。
导致该故障的可能原因有：
WCM集群中的应用通过NFS方式共享文件，如果某一节点中未能正常mount上/opt/XXXWCMV65/WCMData
目录，则可能造成用户无法访问上传的文件。 - 检查及处理方式
分别登录到和XXX..42服务器中，检查相关目录是否绑定到NAS存储中。
mount
如发现未能正常绑定，则重新运行mount命令。
:/opt/XXXWCMV65/WCMData42服务器中，检查相关目录是否绑定到NAS存储中。
mount
如发现未能正常绑定，则重新运行mount命令。
:/opt/XXXWCMV65/WCMData
| | | | | | |
|---|
| | | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | 5M-4G | | |
| | | | |
| | | | |
| | | | |
| | | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | 正常 | |
| CPU及系统负载 | top | 0--2 | | 正常 |
| 硬盘占用 | df -k | 空闲20% | | 正常 |
| APP进程 | ps aux |grep httpd | 1--500 | | 正常 |
| Mysql进程 | ps aux |grep mysqld | 2 | | 正常 |
| 端口监听情况 | netstat –ntlp 80 mysqld:3306 vsftpd:21 | 运行正常 | | 正常 |
| 用户登录情况 | last lastlog more /var/log/messages | grep failure | 10网段 | | 正常 |
| XXX内网 | IE浏览 | ./ | | | 正常 | |
| CPU及系统负载 | top | 0--2 | | 正常 |
| 硬盘占用 | df -k | 空闲20% | | 正常 |
| APP进程 | ps aux |grep httpd | 1--500 | | |
| 端口监听情况 | netstat –ntlp 80 vsftpd:21 | 运行正常 | | 正常 |
| 用户登录情况 | last lastlog more /var/log/messages | grep failure | 10网段 | | 正常 |
| 流媒体服务 | IE浏览 | :5080/ | | | 正常 | |
| CPU及系统负载 | top | 0--2 | | 正常 |
| 硬盘占用 | df -k | 空闲20% | | 正常 |
| APP进程 | ps aux |grep red5 | wc -l | 1--50 | | 正常 |
| Tomcat进程 | ps aux |grep tomcat | wc -l | 1 | | 正常 |
| 端口监听情况 | netstat –ntlp tomcat:8080 mysqld:3306 vsftpd:21 | 运行正常 | | 正常 |
| 用户登录情况 | last lastlog more /var/log/messages | grep failure | 10网段 | | 正常 |
| 负载均衡 | IE管理 | :9090/admin | | | 正常 | |
| CPU及系统负载 | top | 0--2 | | 正常 |
| 硬盘占用 | df -h | 空闲20% | | 正常 |
| APP进程 | ps aux |grep | 1--20 | | 正常 |
| 端口监听情况 | netstat – :80 | 运行正常 | | 正常 |
| 统计用户连接数 | netstat -na | grep 80 | wc -l | 1--5000 | | 正常 |
| 用户登录情况 | last lastlog more /var/log/messages | grep failure | 10网段 | | 正常 |
注：所有平台需查看/tmp/log/是否有异常及文件大小,磁盘空间无特殊情况空闲空间20%
检查人签字：
响应时间保障服务故障恢复服务标准，将严格参照《XXX门户网站安全应急响应预案》执行,XXX公司充分保障对网站内容保障、日常巡检、安全服务、技术支持等方面提供事件分级响应服务。
本预案适用于本预案定义的Ⅰ级、Ⅱ级网站网络与信息安全突发公共事件和可能导致Ⅰ级、Ⅱ级网站网络与信息安全突发公共事件的应对处置工作。
本预案所指网站网络与信息系统的重要性是根据其在国家安全、经济建设、社会生活中的重要程度，遭到破坏后对国家安全、社会秩序、经济建设、公共利益以及公民、法人和其他组织的合法权益的危害程度来确定的。
工作原则贯彻统一领导，分级负责，反应及时，措施果断，依靠科学，加强合作的原则。XXX网站项目突发事故时需以维护部门为中心，相关部门积极配合，协同作战，迅速反应，最大限度地保证业务的连续性和安全性。
遵循预防为主，常备不懈的方针。做好应对突发事件的思想准备和思想教育；加强生产系统的日常监控；通过技术创新和技术进步完善监控和预警手段；加强专业队伍建设和培训；制定完善的单项应急处理流程，提高处理速度。定期进行预演。
应急处置工作要求发生安全事件时，应急处置工作人员30分钟内到达现场（判断为黑客攻击情况，并得到领导指示，可用vpn关闭和），一般情况下一小时内解决故障，恢复运行；对于有些特别重大而涉及面广的安全事件，也要在4小时内解决，不能解决的要及时上报中心领导，并说明原因和处理办法，需要请求中心支援的及时向中心领导报告。
应急组织机构与职责| 组织机构 | 职责 |
|---|
| XXX | 由XXX相关领导、技术负责人、专家组成，对整个应急事件进行统筹安排领导工作，负责重大故障应急对应的决策。 |
| XXX公司 | 由XXX公司相关领导、技术总监、项目经理、技术专家、销售经理等组成。 |
注：具体人员安排及分工在项目试运行初期双方商定组建。
应急事件分级事件分级根据XXX公司信息系统突发事件对服务的社会用户和公司生产、经营和管理的影响范围、程度、可能产生的后果和损失等因素，按从高到低的级别顺序，将信息系统事件分为I 级（重大）、II 级（较大）和III 级（普通）三个等级。
事件说明I级事件XXX网站建设项目发生全局性大规模瘫痪，事态发展超出自己的控制能力，对国家安全、社会秩序、经济建设和公共利益造成特别严重损害的突发公共事件。因下列原因对本单位的生产、经营、管理和信息发布造成特别严重的影响，影响内部用户数超过50%
（1）通道与网络故障；
（2）主机设备、操作系统、中间件和数据库软件故障；
（3）应用停止服务故障；
（4）应用系统数据丢失；
（5）机房电源、空调等环境故障；
（6）自然灾害或人为外力破坏；
（7）其他原因。
II级事件XXX网站建设项目某一部分的网站网络与信息系统瘫痪，对国家安全、社会秩序、经济建设和公共利益造成一定损害，但不需要跨部门、跨地区协同处置的突发公共事件。因下列原因对本单位的生产、经营、管理和信息发布造成特别严重的影响，影响内部用户数超过30%
（1）部分通道与网络故障造成一定小范围影响，但不影响整体访问；
（2）部分主机设备、操作系统、中间件和数据库软件故障，但不影响应用正常使用；
（3）集群中部分节点应用停止服务故障，但不影响整体访问；
（4）非关键应用系统数据丢失；
（5）其他原因。
III级事件XXX网站建设项目中的部分非关键功能点发生故障，不影响用户对系统的访问及关键业务的正常使用，对于此类的事件统称为III级事件；因下列原因对本单位的生产、经营、管理和信息发布造成特别严重的影响，影响内部用户数不超过30%
（1）部分通道与网络故障造成一定小范围影响，但不影响整体访问；
（2）部分主机设备、操作系统、中间件和数据库软件故障，但不影响应用正常使用；
（3）集群中部分节点应用停止服务故障，但不影响整体访问；
（4）其他原因。
应急预案启动前提接网景盛世公司报警电话，项目实施小组系统工程师迅速做出判断并验证故障现象。
例如：发现XXX网站页面和各司局站点页面无法浏览；被黑客攻击等故障现象，经验证之后立刻给网站管理处丰处（丰苏）、单处、郑工打电话报告情况，判断为黑客攻击情况得到领导指示，可用vpn关闭，并第一时间赶到现场。
应急响应应急处理流程“IV/一般”级别的信息安全事件由部门通过预警信息沟通，自行处置。
当项目实施小组成员得到 “三级/较大”、“二级/重大”、“一级/特别重大”级别的信息安全事件的报告时，应报请网站处领导，启动应急预案并进入相应的应急响应工作程序。
在“三级/较大”、“二级/重大”、“一级/特别重大”安全事件发生或可能发生的情况下，按照以下流程进行处理：
（1）运维项目组向网站处领导通报信息安全事件情况，得到指令后立即启动相应的应急处理程序。
（2）运维项目组及时向网站处领导报告信息安全事件的发展情况，网站处领导应将情况及时上报中心主任。
应急处理流程节点描述系统监控进一步完善XXX网站网络与信息安全突发公共事件监测、预测、预警制度。要落实责任制，按照“早发现、早报告、早处置”的原则，加强对各类网站网络与信息安全突发公共事件和可能引发突发公共事件的有关信息的收集、分析判断和持续监测。当发生网站网络与信息安全突发公共事件时，按规定及时向应急领导小组报告，初次报告最迟不得超过半小时，重大和特别重大的网站网络与信息安全突发公共事件实行态势进程报告和日报告制度。报告内容主要包括信息来源、影响范围、事件性质、事件发展趋势和采取的措施等。
初步诊断，及时汇报当在系统监控过程中发生报警，系统监控人员需第一时间搜集故障信息，初步定为问题来源，然后按照应急预案中的内容首先向上级主管部分汇报，并告知故障现象和初步诊断结果。该结果会报告给业务部门和应急领导小组作为决策依据。
判断级别，启动预案应急领导小组和相关业务部门根据监控人员汇总的故障信息和初步诊断报告，定性问题和问题级别，启动相应的应急预案，成立故障解决工作组，统一管理故障解决工作组成员并给予决策，协调督促相关部门给予相关支持以解决故障；
现场故障排查（一）接到报警
- 当收到网景盛世发送的服务器报警短信息后，第一时间联系丰处，请示相应处理意见。如有网络可以进行相关页面查看，查看是否出现相关问题。
- 得到相关指示要求XXX处理时，最快时间到达XXX现场进行相关业务排查。
（二）业务排查
1.查看服务器是否正常连通，进行相关服务器ping服务（如：ping ）
2.如果正常能够ping通，进行访问服务器的进程是不是正常（如：ps –ef | grep tomcat） - 查看服务器的相关进程是不是正常启动
（1）查看网站情况是否正常
1）内网浏览器访问和是不是正常，如果正常说明属于网络的问题，如果不正常说明是服务器的问题。
2)和查看iguard服务进程，查看命令为：ps –ef | grep iguard 如果有相应进程说明igrad同步端正常。
- 查看一下cpu及其负载情况。查看命令为：top 是不是负载过高引起系统运转缓慢。
- 查看一下硬盘占用空间是不是已经满了。查看命令为：df –h 查看空间是不是已经写满。
5）查看内存情况是不是有剩余，查看命令为：free。
6）查看igurad日志是不是正常。查看命令为：more /usr/local/iguard/syncserver/logs/ 查看有无异常情况出现。
如果apache服务有问题，可以进行重新启动，命令如下：
service httpd stop(apache关闭)
service httpd start（apache 启动）
如果iguard进程出现问题，可以联系相关iguard厂商协助解决。
（2）查看发布平台：
1）内网浏览器访问wcm是不是正常，如果正常说明XXX服务正常，如果不能访问需要查看相应服务器服务是否正常。
2）登陆查看tomcat进程是否正常ps –ef | grep Tomcat。查看iguard发布端是否正常ps –ef | grep igurad。
如tomcat进程不正常可以,
cd /opt/XXXWCMV65/Tomcat/bin
./stop进行关闭
./ 进行启动
如依然不正常可以联系XXX工程师协助解决。
如igurad不正常可以联系iguard工程师协助解决。
如遇到重大情况无法及时解决，将发布系统维护中页面暂时替换首页进行发布。等待问题解决后，按领导指示进行相应替换为正常页面。
3）查看iguard日志文件
cd /usr/local/iguard/stagingd/logs/
查看相应的日志文件alert-201209XX。log
进行分析。
4）查看wcm日志文件
cd /opt/XXXWCMV65/Tomcat/logs/ 查看相应 tail -f 或者more 文件日志。 - 查看cpu及其负载状况：执行命令为:top,查看是否运转正常。
6）查看磁盘运转是否正常，执行命令为：df –k 。
7）查看监听情况，执行命令为:netstat –ntlp 查看22端口和80端口是否正常。
（3）查看发布平台数据库：
1）查看oracle进程：执行命令为：
ps –ef | grep oracle 查看是否运行正常。
ps –ef | grep LISTENER 查看监听是否正常运转
2）查看监听端口：
执行命令为:netstat –ntlp 。是否为1521端口开放。
3）查看相应日志文件
tail -f /home/oracle/admin/WWW/bdump/
数据备份
XXX数据库文件已经备份到服务器oracle用户下/home/oracle/。
XXX 网页文件备份到服务器/home/liyonghong/目录下。
数据库文件可以拷贝到数据库服务器作为数据库服务器备份。
临时可以应用作为服务器硬件故障的补充。
故障解决
应急工作组深入现场调查取证定位问题，充分使用相关部门给予的支持快速对问题进行排查，并解决故障。
应急临时解决方案
系统发生故障时，应急工作组应当快速给出解决方案并付出实施以解决故障，但是当系统故障比较严重，致使段时间内无法恢复至正常运行状态的情形时，应当快速执行应急临时解决方案，这些方案包括：
1、当数据库数据丢失，短时间内无法恢复所有数据，应当快速恢复至最近一段时间可以恢复的最完整历史数据，首要保证系统能够运行，当系统运行成功后再将数据恢复至完整状态。
2、当产品文件遭遇损坏无法继续执行时，需将产品原始目录的备份镜像进行恢复，保证系统能够正常运行，如果此次操作导致的部分数据丢失问题，需尽可能的找回原来的用户数据。
3、当问题比较严重无法继续提供服务时，可将测试环境作为生产环境进行切换，继续对外提供服务。
4、当测试环境无法满足需求时，可修改页面将链接跳转至其他业务系统，以替代本系统；
应急结束
网站网络与信息安全突发公共事件经应急处置后，得到有效控制，事态下降到一定程度或基本得到解决，分析各监测统计数据后，确定是否结束应急。
保障措施
通信保障
在系统发生故障时，首先需要确保整个网站群环境的网络是否畅通，应急领导小组应统筹安排相应的运维部门对网络进行排查，保持通信畅通。
物资保障
重要网站网络与信息系统在建设系统时应事先预留一定的应急设备，建立信息网络硬件、软件、应急救援设备等应急物资库。在网站网络与信息安全突发公共事件发生时，由应急领导小组办公室负责统一调用。
技术保障
本预案启动后，立即成立由应急领导小组领导带队的应急响应先遣小组，督促、指导和协调处置工作。应急领导小组办公室根据事态的发展和处置工作需要，及时增派专家小组，调动必需的物资、设备，支援应急工作。参加现场处置工作的各有关部门和单位在现场指挥部的统一指挥下，协助开展处置行动。
资金保障
网站网络与信息系统突发公共事件应急处置资金，XXX相关部门应该对应急保障过程中的所需资金予以支持和保障。
人员保障
按照一专多能的要求建立网站网络信息安全应急保障队伍。由应急领导小组办公室选择若干经国家有关部门资质认可的、管理规范、服务能力较强的部门作为网站网络与信息安全的应急支援单位，提供技术支持与服务。
信息发布
- 当网站网络与信息安全突发公共事件发生时，应急领导小组办公室应及时做好信息发布工作，通过相关单位发布网站网络与信息安全突发公共事件预警及应急处置的相关信息，引导舆论和公众行为，增强公众的信心。
(2)应急领导小组办公室要密切关注国内外关于网络与信息安全突发公共事件的新闻报道，及时采取措施，对媒体关于事件以及处置工作的不正确信息，进行澄清、纠正影响，接受群众咨询，释疑解惑，稳定人心。
后期处置
后期观察
在应急处置工作结束后，要迅速采取措施，抓紧组织抢修受损的基础设施，减少损失，尽快恢复正常工作。统计各种数据，查明原因，对事件造成的损失和影响以及恢复重建能力进行分析评估，认真制定恢复重建计划，并迅速组织实施。有关部门要提供必要的人员和技术、物资和装备以及资金等支持，并将善后处置的有关情况报应急领导小组。
调查与评估
在应急处置工作结束后，主管部门应立即组织有关人员和专家组成事件调查组，对事件发生及其处置过程进行全面的调查，查清事件发生的原因及财产损失情况，总结经验教训，写出调查评估报告，报应急领导小组，并根据问责制的有关规定，对有关责任人员作出处理。特别重大网站网络与信息安全突发公共事件的调查评估报告，经应急领导小组办公室审核后，报应急领导小组，必要时采取合理的形式向社会公众通报。
改进措施
在应急处理完成后，应急办公室要及时组织人员做好后期现场的整理、恢复工作，及时会同相关设备、系统厂商完成设备、系统的善后处理；总结应急过程中的问题，完善应急预案和应急处理流程，并及时整理、归档。
宣传、培训和演练
宣传
要充分利用各种传播媒介及有效的形式，加强网站网络与信息安全突发公共事件应急和处置的有关法律法规和政策的宣传，开展预防、预警、自救、互救和减灾等知识的宣讲活动，普及应急救援的基本知识，提高公众防范意识和应急处置能力。
培训
要加强对网站网络与信息安全等方面的知识培训，提高防范意识及技能，指定专人负责安全技术工作。并将网站网络与信息安全突发公共事件的应急管理、工作流程等列为培训内容，增强应急处置工作的组织能力。
演练
建立应急预案定期演练制度。通过演练，发现应急工作体系和工作机制存在的问题，不断完善应急预案，提高应急处置能力。
为提高突发事件应急响应水平，应急领导小组应定期组织一次预案演练；检验应急预案各环节之间的通信、协调、指挥等是否符合快速、高效的要求。通过演练，进一步明确应急响应各岗位责任，对预案中存在的问题和不足及时补充和完善。
1、模拟紧急事件发生
模拟可能的软、硬件故障等。
由监控人员通知应急小组负责人
小组负责人安排启动应急措施、通知各相关单位人员。
2、故障排查
应急小组各角色根据模拟事件说明自己的工作，操作步骤，汇报对象。
应急小组负责人判断故障处理情况
完成应急处理
3、恢复环境
应急小组各角色说明自己的工作，操作步骤。
应急小组负责人宣布应急工作完成，安排值守人员，解散应急小组
负责人向领导小组汇报
附录
XXX网站建设系统突发事件应急报告表
| 报告时间：年月日时分 |
|---|
| 单位名称 | | 报告人 | |
| 联系电话 | | 通讯地址 | |
| 传真 | | 电子邮件 | |
| 本次事件发生时间 | |
|
|
| 本次事件的简要描述 | |
|
|
| 初步判定的事件原因 | |
|
|
| 采取的应对措施 | |
|
|
| 本次事件的影响状况 | |
|
|
XXXXXX系统应急预案
| 编号： 日期时间 月日 |
|---|
| 预案名称 | | 等级 | |
| 涉及部门 | |
| 涉及人员及联系方式 | |
|
|
| 预案事件描述 | |
|
|
| 预案启动条件 | |
|
|
| 应急处置过程用时 | |
|
|
|
| 应急处置结果 | |
|
|
|
| 预案处理要求 | |
| 演练要求 | |
|
| 预案流程要求 | |
| |
| 备注： |
编制人： 审批人： 抄送：
XXX专业的客服中心
XXX公司公司设有专门的技术支持与售后服务机构——客户服务中心，在杭州具有优秀的技术人员和雄厚的技术力量，并且为本项目指定了专职服务经理负责技术支持与售后服务的统一协调工作。
XXX公司公司的技术支持与售后服务队伍接受过良好的培训并且富有经验，我们对本项目中可能出现的技术问题已经做好了充分的技术准备。XXX公司公司将协调其他相关承建单位和设备厂商共同为项目单位提供全面的技术支持和售后服务。
日常工作管理保障服务
工作总则
运维驻场工程师将认真学习和遵守XXX所有有关外来人员管理的规章制度，且有义务不对外透露在XXX获得的一切信息。
项目组成员在XXX的一切工作都在得到信息中心管理人员的授权之后进行。
项目组成员一旦发生政治事件、泄密、盗用用户资料、擅自更资料、故意隐瞒、超越授权操作导致恶性事件或给XXX带来影响重大的事件等事件，即视为安全事故。
全面配合XXX信息中心积极参与对其派驻工程师的有效的监督和管理，遵守XXX的相关规章制度。
建立奖励机制，同时参考XXX的建议，为优秀员工提供培训机会，或参加各种认证考试，以激励员工不断提升工作能力。
坚决杜绝因项目组成员发生的安全问题。
保证其项目组成员符合一定的技术水平，XXX有权对不满足工作要求的运维组成员向XXX公司提出更换的要求；工作中坚决杜绝弄虚作假的现象出现。
服务时间
在5×8 小时工作时间内设置专人职守。
在非工作时间设置有专人7×24 小时接听的移动电话热线，用于解决内部的技术问题。
汇报管理
要加强日常巡检和节假日、重大政治活动、重要敏感时期的应急值守与实时监控；配合网站运行处和其他服务厂商（防篡改iguard、linux）加强技术防护手段，健全安全防范体系，提高网站安全防护能力。
按时提交相关报表，具体包括：根据每日实际工作情况提交《系统每日运维监控报告》、《XXX网站维护周报》、《XXX网站工作简报》（即月报）。
对需在后台操作的工作认真填写处理《XXX网站运维业务处理单》。
网站相关事件在《工作备忘录》中作出详细记录。
出现事件时依情况严格按照《回退方案》、《应急预案》、《备机切换方案》执行，并实时记录事件过程，事后及时总结经验。
问题管理
根据多年的运维服务数据分析，我们发现，在日常运行服务项目中，70%的问题，都是曾经出现过的，如果能够对服务进程中遇到的所有问题及解决办法都作好详尽的记录，并将此作为服务项目组培训的素材，讲大大的缩短故障处理时间，降低服务成本。
知识库管理
运维项目组每周提交技术文档，并由服务中心将技术资料整理后输入到知识库系统中，项目服务人员可从系统中找到相应的技术资料，提高日常维护的工作效率，一般用户可以通过查询知识库，提高用户的操作水平及技能.
服务记录管理
我司使用《运维服务单》作为服务记录，记录分别由服务受理人员、服务工程师以及被服务的客户三方完成，并且由客服中心服务台统一进行定期回访，每季度根据服务单统计服务信息并形成服务报告提交给客户。
我方运维人员如需发生变更时，要保证网站运行的连续性，需进行内部知识转移，确保运维工作无间断或质量下降。
售后服务保障方案
售后服务组织机构
在XXX网站项目的售后服务阶段，XXX公司将组建以下的售后服务组织机构：
售后服务组织结构本项目售后服务将由如下几个小组组成：
1、售后服务总体组负责管理现场服务组、远程服务组两个服务组，制定各个服务小组的服务计划和服务管理制度，定期汇总和整理各服务小组的服务报告并提交给甲方相关领导；负责协调甲方与各服务小组之间的各类事务，负责协调与各服务小组对专业服务机构的指导和配合工作。
2、现场服务组本组为常设机构，项目验收后，系统正式运行时组建，服务对象为甲方的业务、管理、技术人员和领导，主要负责解决上述人员在系统使用过程中所遇到的各类问题，定期向甲方提交服务报告。服务内容主要包括：
（1）现场贴身服务：派遣经验丰富的工程师根据项目支持需要提供用户现场服务，主要负责解决上述人员在本项目中所遇到的各类问题。
（2）定期回访服务：我公司将采取巡检制度，每季度由公司服务组负责人带队拜访—次用户，了解系统的质量、服务问题，调查维护情况，帮助用户解决实际应用中的问题，及时协调服务人员的分工协作以期提供全面的服务与支持。听取用户意见，征询用户需求的解决情况以及对服务的满意度情况，在对客户进行关怀服务的同时，监督服务人员的服务质量，并作为服务工程师综合评定和奖惩的重要依据和指标。
（3）专项服务：将根据甲方的特别需求，提供有针对性的服务。
（4）定期巡检服务：我公司对本项目在系统安装验收后定期派工程师对系统进行系统巡检，现场对系统进行测试及优化，及时发现系统存在的故障或潜在的问题，提早消除故障隐患，确保系统安全、稳定、高效地运行。此外，我们还将同各个软硬件厂商进行协作，将各厂商新近发现的重要问题与缺陷(Bugs)及时通知用户，使用户防患于未然。
3、远程服务组本组为常设机构，主要服务对象为甲方的各类相关人员。主要提供电话和传真支持服务、短信支持服务、邮件支持服务、网上服务和即时通讯工具支持服务。负责维护本项目服务网站，及时更新网站内容，定期更新网站功能，利用网络资源解答并回复有关本项目的各类问题，同时负责，同时定期整理各类问题和需求，与工作报告一起向售后服务总体组提交服务报告。
售后服务规范
1、规范的服务行业
XXX公司公司为了更好地为XXX服务，技术服务人员在为XXX提供服务时，务必实时以此服务规范自我约束、自我监督。为了保证客户服务中心能够提供让XXX满意的服务，我们制定了相应的技术支持与售后服务行为规范：
| 客户服务中心行为规范1、客户服务中心所有人员在接到XXX电话时，必须使用礼貌用语，如：“您好”、“请”、“谢谢”等。2、客户服务中心所有人员必须对XXX提出的任何问题给予耐心的解答，不得以“不知道”、“这不是我们的服务范围”等用语回答客户；对于无法立即回答的问题要向XXX说明原因，并告知XXX解答时间。3、客户服务中心对XXX的一切服务需求必须给予正确、实质的响应，为XXX提出合理、可行的解决方案。4、在客户现场工作时，工程师必须严格遵守客户方的管理规范和管理制度，并严禁接受客户馈赠。5、严禁在客户现场吸烟、玩游戏及做与工作无关的事情。6、除非工作需要并获得客户许可，否则不得使用客户的电话。7、除非工作需要并获得客户许可，否则严禁在客户现场上网。8、未经客户许可，不得擅自登录客户系统，不得擅自打开客户的设备。9、调整客户原有（尤其是正在使用的）设备（包括参数调整）之前，必须获得用户的许可。10、施工结束后，必须将实施现场清理干净，并经客户检查后方可离开。无论任何情况，不许与客户发生争吵。 |
|---|
2、严谨的服务制度
为了更好地完成对XXX网站项目的技术支持与售后服务工作，我们将对参与项目的所有技术支持与售后服务人员进行统一的培训和管理，制定专门的服务制度，将人员管理、各项业务指标与项目的特点相结合，以严谨、一贯化、制度化、高效率为主要特色，强调统一纪律、统一指挥、统一步调、统一制度、统一执行。
3、高效的服务模式
XXX公司规定员工在技术支持与售后服务上一定要做到准确、迅速。通过形成这种快速敏捷、雷厉风行的作风，为XXX提供满意的服务。
售后服务方式及内容
我公司为XXX提供了全方位的技术支持与售后服务方式，使得XXX能够及时、便捷地获得相应的技术支持与售后服务，主要的服务方式包括电话、传真、邮件、网站、现场服务、投诉受理等。
呼叫中心（内含本项目运维组）
XXX公司会对项目单位提供长期的免费电话支持服务。客户服务中心本部电话为XXXXXXXXXX，传真为（010）XXXXXXXXXXX，服务时间为9:00 – 18:00，周一至周五（国家法定的休息日和节假日除外）。
XXX可以通过客户服务中心热线电话得到支持和服务，在非工作时间，可以通过手机与专职服务经理或技术人员取得联系。此外，XXX公司客户服务中心全部人员的手机24小时开机，确保项目单位能够及时与技术支持人员取得联系。
在接到XXX的技术支持请求或故障报告后，客户服务中心将立即以电话方式同该单位技术人员取得联系，详细了解其所需的服务内容，提供相应解答，并且编写详细的记录表单。
对于技术咨询，技术人员会结合实际情况及时为XXX提供相应的答复；对于系统运行故障，技术人员首先会了解其信息系统问题的详细情况，同时派出技术人员，在客户服务中心本部技术人员的配合下进行系统分析，逐步解决故障。
邮件服务
客户服务中心为本项目特别设置了专门的电子邮件信箱，同时公布了所有相关技术人员的个人邮箱，项目单位技术人员可以通过电子邮件将技术支持请求发送到客户服务中心，专职服务经理或技术人员在接到报告之后，会立即与XXX取得联系，为其提供相应的技术支持服务。
客户服务中心也将通过电子邮件为XXX提供解决方案，或者根据业务系统需要发送相关的技术资料。
服务网站
用户方可通过XXX网站项目建设，进入XXX公司专门为本项目建立的信息园地，内容包括产品信息、软件信息、工程及应用经验、常见问题及解决方法等，还会把本项目运行期间出现的故障及解决办法整理汇总后公布于此，方便项目单位查询。
我们还在网站上专门为本项目设立讨论区，便于项目单位的技术人员与客户服务中心的技术人员进行交流。
远程培训
我公司将把本项目系统的培训内容、应用实例、经典案例以及优秀推广经验作为共享知识资源，制作成简明易懂、形象生动的学习课件，放置在服务网站的学习园地中，系统用户只需要提供登陆的用户名和密码就可以获取到以往所有培训课程的课件资料，方便用户重复学习与提高。系统用户如在系统使用过程中遇到疑问可以登录服务网站提出相关问题我公司将安排专业技术人员常年负责这方面的管理工作，负责解答各类问题，收集系统使用过程中反馈意见和客户需求。
投诉受理服务
为了提高服务质量，加强与客户的沟通和交流，我公司均设立多种客户投诉渠道倾听客户对售后服务的意见。
我公司指派专人负责集中受理客户投诉，它通过客户投诉处理系统把用户投诉转到相关责任部门去处理，并跟踪和记录处理过程。在投诉处理过程中，投诉受理人员会主动征询客户意见，如客户对处理结果不满意，将重新启动客户投诉流程，直至客户满意关闭投诉。
售后服务流程及跟踪
售后服务流程
在XXX需要售后技术支持服务时，可以以热线电话、传真或者电子邮件的形式通知本项目售后服务组。售后服务组的技术人员将在第一时间与用户联系，了解用户的准确需求，如果是软件系统运行问题，技术人员将会对问题的相关现象进行详细记录，同时为用户提供解决方案，或者告知明确的答复时间，随后组织相应的技术力量对问题进行分析，制定解决方案。
在系统运行过程中，出现的故障主要存在以下几类：操作错误、配置错误、通讯线路错误或硬件故障、软件完善性问题、软件错误，售后服务组在得到了用户的故障服务请求之后，将搜集充分的故障信息，分析故障的种类，根据不同故障采取相应的解决方案，视具体情况对用户进行电话支持或者现场服务，必要时协调原厂商的技术人员共同研究并解决问题。在故障排除之后，将问题的详细描述以及解决方案进行备份，以便为日后的技术支持工作提供参考。
售后服务处理流程如下图所示：
售后服务流程正如前面的流程图所示，整个服务流程体系的设计是根据服务所处环节逐步进行的完整体系结构。
售后服务流程描述：
1、当用户开始使用我们的产品时，如果用户存在疑问或系统设备出现故障，我们会马上开始进入到这个技术支持与服务的流程里，准备提供我公司全方位的服务。
2、第一步，当用户出现问题，有疑问需要解决时，可首先通过热线向技术服务中心咨询；
3、当我中心接到用户的咨询电话时，技术工程师先判断基本属于什么问题，若可以通过电话支持或远程登陆调试设备的，会立刻给与解决；
4、如通过电话和远程登陆不能给予解决的问题，技术支持人员会判断是否是有硬件设备需要更换；
5、在与用户沟通后，有用户决定是否需要对现有设备进行更换；
6、如果用户觉得不需要更换的，我们的技术支持人员会继续提供热线电话技术指导或远程登陆调试支持服务；
7、如果用户觉得需要对现有设备进行更换的，我公司会派出技术工程师到现场进行服务；
8、对用户的电话技术指导或远程登陆调试，不能达到修复问题的情况下，我公司也会派出技术工程师进行现场服务；
9、如果电话即使知道或远程登陆调试将问题成功解决，我公司负责技术支持的相关人员将会把所填写的客户服务报告归档；如果我公司派出技术支持工程师进行现场服务解决问题，我公司负责技术支持的相关人员将会把所填写的客户服务报告归档。
10、在我公司提供服务的整个过程中，我公司还会定期对客户进行回访；
11、回访可通过热线电话或远程登陆进行，也可能会派出技术支持工程师做现场巡查；
12、在回访中，如果发现问题，技术支持工程师会马上在现场给与解决；
13、如果没有发现问题，设备环境运行正常，即为整个技术支持与服务流程完整结束。
售后服务跟踪
售后服务人员会定期回访客户，进行后续跟踪工作，并通过服务热线和服务网站进行问题的跟踪管理。
还将定期派人对用户系统的工作环境、运行状态、性能、安全性等方面进行检查。如有问题则进行维修。
1、定期电话回访
公司每隔一定时间会对以往的技术支持售后服务进行电话回访，征询用户需求的解决情况以及对服务的满意度情况，以此监督技术人员的服务质量，作为工程师重要的考评指标。
2、定期系统巡查
公司也将每月定期对用户系统进行巡回检修服务，到用户现场进行系统检查、专业咨询等服务。
售后服务保障措施
售后服务具体措施
基础措施主要针对的是日常的、有序的服务，主要包括：
- 7×24小时的服务网站；
- 7×24小时的服务热线；
- 7×24小时的售后服务办公室值守；
- 各类专项服务；
- 总公司、地方分公司和办事处提供的本地化服务；
- 定期巡检各个应用系统及平台。
售后服务应急措施
系统提交用户使用以后，如用户请求技术支持，如果通过服务热线支持可以解决的问题通过电话进行指导解决；重大技术问题及时现场技术支持，技术支持工程师将在最短时间内赶到用户现场：
1、灾难性事件：由于经过大量的测试，系统本身应不含有可引起灾难事件的隐患，但如果因其他原因造成灾难事件发生，本公司立即组织开发队伍进行协作处理。如果系统由于病毒或其他非应用系统原因造成的灾难性事件（包括系统不能启动等），需要恢复到可运行状态，本公司承诺协作解决；
2、严重程序错误：如果确因系统开发问题而可能造成数据错误（必要的话会到现场对事件进行调研），本公司立即组织开发队伍进行修改，并尽快到现场升级原有系统，同时，通过软件分发渠道对所有使用该软件的操作者进行升级，需要现场升级的本公司提供上门服务；
3、一般程序错误：如果程序出现开发上的“笔误”，不会造成严重的数据损失，本公司立即组织开发队伍进行修改；
4、属于用户使用不当问题的，本公司将通过电话进行指导。
当客户的系统发生一个技术问题后，本客户服务系统允许客户定义自己的严重程度和委托响应时间，客户可以从以下几种严重程度中选择一种：灾难性的，严重的，一般的。
在下面的表格中，“立即通知”表示本公司将立即把客户的需要告诉相应的工程师，“客户方便”表示客户可以选择一个对客户和本公司都比较方便的服务时间。
| 分类 | 严重程度 | 委托响应时间 |
|---|
| 服务热线（传真） | 到达现场 |
| 已在现场 | 任意 | 立即 | 立即 |
| 未在现场 | 灾难性(系统严重损坏) | 立即通知 | 在接到服务请求电话后1小时内组织出发，到达现场后2小时内给出故障诊断 |
| 未在现场 | 严重(系统错误) | 在接到电话后立即响应 | 1小时内组织出发，到达现场后2小时内给出故障诊断 |
| 一般 | 在接到电话后的1小时内响应 | 根据实际情况到达现场或客户方便 |
到场维护时间：如果系统发生灾难性和严重故障，本公司将在电话回复之后，以最快的方式赶到客户现场提供维护服务。
售后服务档案机制
在项目建设过程中将为XXX建立专有的服务档案，并同步更新至服务网站进行注册和档案建立工作，XXX可以通过服务热线、服务网站等多种形式提出问题，售后服务人员将通过查询问题库、知识库和与项目建设人员的沟通在第一时间解决问题，及时反馈给用户。并登记售后服务登记单和更新售后服务档案，进行备案，同时更新问题库和知识库，方便查找和积累。售后服务人员会定期回访客户，进行后续跟踪工作，并通过服务热线和服务网站进行问题的跟踪管理。如下图所示：
图：售后服务跟踪流程售后服务监督机制
监督管理机制在我们的工作和服务过程当中是非常的重要，在服务方面监督管理是非常必要的。
为保证整个工程的顺利实施和提供优质售后服务，公司对所提供的技术支持与售后服务，执行严格的监督管理机制，提供监督投诉电话。
如果用户对我公司的技术服务人员存在不按合同服务标准提供相应服务的或是对售后服务人员的工作态度和质量不满意，可以直接拨打公司的服务监督电话进行投诉。
我公司保证在接到用户投诉的一个工作日内给予调查和回复，并会根据实际情况需要另行安排更高级技术服务人员亲赴现场，以圆满解决问题。
售后服务提交文档
- 售后服务方案及服务计划；
- 系统巡检报告；
- 系统维护记录；
- 客户支持日志；
- 变更请求与处理单；
- 用户现场交流记录（现场填写、打印、签字）；
- 维护工作检查单；
- 维护工作考评表；
- 其他合同要求提高的服务相关文档。
售后服务承诺
我公司郑重承诺：严格按照招标文件要求在规定时间内完成XXX政府门户网站维护项目服务。
在线咨询
