主机运维应急预案简介

主机运维应急预案简介

●崔志昂 上海超级计算中心 上海 ２０１２０３ ｚａｃｕｉ＠ｓｓｃ．ｎｅｔ．ｃｎ

●魏玉琪 上海超级计算中心 上海 ２０１２０３ ｙｑｗｅｉ＠ｓｓｃ．ｎｅｔ．ｃｎ

引言：

高性能计算技术及应用水平已成为显示综合国力的一种标志。高性能计算机持续不间断地为用户提供高性能计算服务，而运维应急预案是主机运行中处理突发事件的依据和方法，是主机系统稳定运行的保障。本文简要介绍上海超级计算中心主机运维应急预案，供同行参考。

１．　主机和运维管理制度简介

超级计算机是功能最强、运算速度最快、存储容量最大的一类计算机。目前只有少数国家掌握研发技术，系统造价非常昂贵，多用于国家高科技领域和尖端技术研究，是国家科技发展水平和综合国力的重要标志。上海超级计算中心作为上海信息港主体工程之一，国家和上海市政府投资先后引进神威－Ｉ超级计算机、神威－６４Ｐ集群计算机、曙光４０００Ａ超级计算机系统并投入商业化运行。

上海超级计算中心自２００１年正式开通至今，这些高性能计算机系统已安全、稳定运行七年多时间，上机用户取得了丰硕的科研成果和社会效益。在这七年中，为保障这些高性能计算机系统安全、稳定、不间断地运行，技术支持部在中心引进第一台高性能计算机－－神威－Ｉ超级计算机系统的同时，建立了机房应急预案、运行记录、设备运行参数等基础运维制度，在二期引进曙光４０００Ａ超级计算机系统过程中，不断完善原有运维制度，并针对该主机系统特点编写了大量操作方法和应急预案。

中心自２００６年获得ＩＳＯ２７００１（ＢＳ７７９９）信息安全认证以来，技术支持部根据其要求规范了文档体系建设，形成了机房管理制度、应急预案、操作方法、运行情况记录的四大类运维文档。

正是这些运维管理制度的不断完善和有效执行，才确保了资产价值高、服务对象广、社会影响大的中心主机系统安全、稳定运行，保障重点项目、用户服务的连续性。

２．　应急预案重要性

上海超级计算中心机房运维管理文档划分为机房管理制度、应急预案、操作方法、运行记录共四

大类（如图１所示）。

图１ 应急预案分类

应急预案在应急系统中起着关键作用，它明确了在突发紧急情况发生之前、发生过程中以及刚刚结束之后，谁负责做什么、何时做，以及相应的策略和资源准备等。它是针对可能发生的重大事故，按照其影响和后果严重程度，在应急准备、响应、操作各个方面预先做出的详细安排，是开展及时、有序和有效事故应急工作的行动指南。因此，应急预案在这四类运维管理文档中处于最为重要的地位。

３．　应急预案分类

应急预案按重要性和事件种类，可以划分为消防预案、断电预案、空调预案、其他预案共４种，预案各文档之间彼此独立又互为关联，具有非常强的可操作性。制定预案的指导原则是尽一切可能，最大限度地确保向用户提供的服务不中断。在紧急事件发生的情况下，保证核心设备连续运行，避免存储数据丢失。在事件处置完成后，能快速恢复高性能计算服务。

３．１　消防预案

消防预案是主机房最重要的应急预案。该类预案根据《上海超级计算中心灭火和应急疏散预案》的原则并结合主机房主机设备和消防设备的运行特性而制定。主要由《主机房消防应急预案》和《主机房气体喷淋消防系统启动撤离及处置应急预案》２个文档组成。

消防应急预案：该预案着重规范了火警事件发生后，所有主机维护人员如何根据所属区域和现场情况，判断和选择正确的处理方法，同时配合中心物业人员处置，降低事件带来的影响。

对于设备发生烟雾，主机维护人员协同物业人员寻找烟雾点予以切断相关区域电源；当设备发生可以控制火情，协同物业人员灭火；当主机房发生火灾而无法控制，应采取施救方法等措施。

气体喷淋预案：该预案描述主机房气体喷淋系统启动的响应和确认并具体规定了撤离机房路线、善后处置。

这两个预案中，消防应急预案作为消防预案的主体，涉及到如何处理与消防有关情况的各个方面。气体喷淋预案是主机房发生重大火灾时应对的最终灭火手段和人员撤离引导方法。

３．２　断电预案

断电预案的重要性仅次于消防预案。该类预案根据中心供配电系统实际情况和各种断电影响范围下对主机运行的最小保障要求而制定的。主要由《主机房断电应急预案》、《曙光４０００Ａ超级计算机系统紧急关机操作方法》、《曙光４０００Ａ超级计算机系统双路断电关机操作方法》等多个文档组成。

主机房断电应急预案：该预案用于断电情况下，主机维护人员如何与中心物业部门联系控制主机房供电情况，并且负责对主机系统运行受断电影响程度做出正确判断。指导维护人员按影响程度，分别选用预案中对应的操作方法。本预案在所有断电预案中起指导思想作用。

紧急关机操作方法：该预案制定了主机系统在紧急情况下，最快速度关机的操作步骤。主要用于发生烟雾、明火或消防、断电预案需在数分钟内关机断电的事件。

双路断电关机操作方法：该紧急操作预案主要用于在外界双路供电全部中断情况下的操作。

该预案的关机原则是：根据实际电力供应考虑操作步骤，宁慢勿快，在时间允许的情况下，最大程度保证存储节点、ＳＡＮ和ＳＣＳＩ存储设备、工程用户的计算节点的运行，尽可能减少关闭范围，以确保能在恢复供电的情况下，主机尽快恢复正常运行状态，减少影响范围。３．３　空调预案

超级计算机系统在运行中消耗大量电能，在提供高性能的计算能力同时产生大量的热量，必须采用专用空调系统，以保持主机系统适当的温、湿度、空气洁净度等运行环境需求。因此，专用空调系统与主机系统密切相关，空调预案是主机房必备的应急预案。

制定该预案的原因在于，断电情况下，空调与主机系统存在互相牵制的现状。主机和空调系统均为外界双路供电，主机系统配有ＵＰＳ不间断电源系统，而空调系统无ＵＰＳ支持。在双路停电情况下，主机系统可获得ＵＰＳ电池组支持运行若干分钟，空调系统无ＵＰＳ支持只能停机。由于在无空调冷却情况下，主机系统会在短时间内积聚大量热量导致超过运行警戒温度，主机系统在有可供电余量的情况下，仍将被迫关机。因此，确保空调中断情况下的主机运行环境是该预案的制定原则。

预案根据各台主机配备的空调系统特点制定，由《曙光机房空调系统故障应急预案》和《神威机房空调系统应急预案》２个文档组成，这里仅介绍曙光机房空调系统应急预案。

该预案的第一步：考虑增强主机系统散热效果，采用打开主机机柜前后门，和机房周边木门，在通风道上布置有ＵＰＳ支持的应急风扇，形成空气对流，带走热空气，从而增强主机系统散热效果，降低升温速度。

该预案的第二步：在采取上述措施并持续升温到一定温度之上的情况下，考虑紧急关闭部分或全部计算节点，减少热量生成，确保主机系统的核心存储和网络系统不受影响，确保空调系统修复后，主机系统能快速恢复运行。

３．４　其他预案

除了固定的三类预案之外，技术支持部还根据主机系统实际运行中出现的各种意外情况，随时制定具有针对性的预案。

如《大楼顶棚坍塌应急操作方法》的制定，就是由于２００８年１月连续发生雨雪等灾害性天气，中心大楼顶棚大量积雪且难融化，物业预计存在情况继续恶化，有发生顶棚坍塌事故的可能，一旦发生将影响一楼主机运行。

针对该突发的隐患，中心技术支持部制定应急操作方法，对维护巡查频度范围、漏水可能发生位置、如何处理受漏水影响的主机设备等操作步骤进行严格界定。即使在最后，中心大楼顶棚经受住灾害性天气的考验，该预案并未发挥作用，这正体现了应急预案的备而不用的特点。而且通过各种意外

情况的迅速分析、应对和实践操练，不断锻炼主机维护队伍，使之走向成熟。

４．　在实际案例中，应急预案的作用

在主机系统年复一年的运行中，我们希望这些设备正常稳定运行，应急预案永远不会被使用，然而在实际运行中，总免不了因突发事件执行应急预案。

而每次突发事件是检验应急预案制定是否科学、有效的最好证明。

４．１　双路断电，ＵＰＳ正常运行案例

２００６年８月某天，因打雷导致供电一路跳闸自动换至另一路供电，曙光机房２台空调掉电。

主机维护人员立即按应急预案操作，电话通知物业人员恢复空调运行，恢复过程中所有空调相继出现高温报警，机柜液晶屏平均温度３５度，开启全部曙光机柜前后门，打开神威－曙光玻璃门并调集应急电扇，于１２：４５恢复正常。

１２：５０再次出现双路供电中断，曙光空调因无ＵＰＳ支撑全部断电，启动断电应急预案，开启５、６号木门，开启神威机房全部空调，布置电扇，将冷气导入曙光机房，热量从６号木门的外部通道排出，选择性杀除部分作业，至１３：０５供电恢复，曙光空调开始工作，１３：２０环境恢复正常。全机在此过程中，正常运行未停机，只损失了部分不重要的作业。

４．２　单路断电，ＵＰＳ失效案例

２００７年８月某天，因低压配电柜开关至ＵＰＳ房间Ｘ－ＪＭ柜电缆发生相对地短路，造成ＵＰＳ机组逆变器自身保护动作，关闭ＵＰＳ机组，导致曙光主机系统失电。

全机掉电后，主机维护人员迅速按应急预案手工关闭所有电源开关。１０：３０恢复供电，环境温湿度恢复正常后，全机加电，恢复过程中修复ｓｔｏｒａｇｅ００１、００５、０１０三个盘阵的９个用户文件系统，修复１５个节点加电故障，除ｃｎｏｄｅ００９、ａｎｏｄｅ０２９电源模块故障，于当日１５：１０全机系统恢复正常。

由于处置及时，主机受影响范围很小，在恢复供电后数小时即成功开启全系统。

５．　随时保持应急预案的适用性

主机长年累月的运行，故障和问题的发生，往往是必然的，也是客观、无法回避的。因此，要求在维护工作中，预先考虑到可能的问题和故障，制定完善的应急预案。应急预案不可能包含所有的故障和问题，但应根据维护经验，尽可能地设想各种危机情况下的处置措施。做到预想到各种可能的问题。

而在形成应急预案后，更重要的是持续地在运行中加以完善、测试和演练，尽可能模拟实际情况，做到即使只有１名维护人员在场，也能在真正发生危机时，以最短时间独立处置故障。

以目前中心的主机运维工作为例，三年内，仅断电预案就已根据实际运行情况的变化，制定并更新了５￣６个版本，针对夏季突发断电也有专用预案。这样的措施，直接保障了２００６年８月突发断电事件中的主机连续运行。而２００７年８月的突发断电事件中，由于预案在之前刚根据实际情况进行过演练和修改，主机维护人员仅用半小时就完成所有应急操作动作，整机仅有个别设备故障，确保了主机设备未因突发断电而发生大范围损坏现象，恢复供电后直接完成开机。

实践证明，完善而适用的应急预案能保障向用户提供稳定的高性能计算服务。

６．　结束语

完备而适用的应急预案能有效降低主机系统因意外事件发生带来的运行风险，对可能发生的意外来说，是一种事前防范措施。但对整个主机系统产品而言，是一种事后防范措施。如果主机系统生产厂商能把这些防范措施纳入整个系统设计过程中，使操作方法更加简便、更趋于人性化，这将帮助主机维护人员更为妥善处理意外事件，用户得到更为稳定的高性能计算服务。我们相信未来国产的高性能计算机能做到这一点，期待着这一天早日到来。

（为帮助了解，特在附录中节选部分双路断电关机预案内容）

附录：《曙光４０００Ａ超级计算机系统双路断电关机操作方法》（省略具体操作步骤）

曙光４０００Ａ超级计算机系统双路断电关机操作方法

注意：１、本方法专用于主机房发生双路同时断电紧急操作使用。（包括单线断电切换失败）。

２、本方法作为《曙光－４０００Ａ超级计算机系统紧急关机操作方法》（ＳＳＣＳ（ＴＳ）－ＸＸＸＸ－ＸＸＸＸ－ＸＸＸＸ）的附件。　１．　断电确认及操作：

主机房内一旦发现断电，并接物业明确通知为双路断电，首先执行如下操作（即确保节点温度）：

１．１　打开机房门便于散热，……

１．２　机房通道上布置应急风扇加强冷热空气对流，夏季：应急风扇布置……；冬季：应急风扇布置……，使曙光机房的温度尽量降低。

１．３　打开所有机柜前、后门。

１．４　密切注意机房节点平均温度（专指各机柜液晶面板所示之环境温度值）。

２．　紧急关机条件确认：

在完成上述操作后，密切观察主机房环境。一旦有如下任何一个条件满足：

２．１　自断电发生起，已达到ＸＸ分钟仍未恢复供电；

２．２　采取上述紧急通风措施，节点温度持续上升，超过ＸＸ℃；

可认定为紧急断电事件，即刻按下列紧急关机操作方法进行操作。

３．　紧急关机操作步骤：

注意事项：

３．１　……

３．２　关机操作的全过程中，注意随时保持和物业的通讯联系。除根据情况随时联络外，应严格保证每ＸＸ分钟与物业联系一次，询问ＵＰＳ可支撑时间及恢复供电可能。（分机、手机、对讲机等）

３．３　应理解关机原则为：根据实际电力供应考虑操作步骤，宁慢勿快，在时间允许的情况下，最大程度保证Ｘ排节点、存储节点、ＳＡＮ和ＳＣＳＩ存储设备的运行，尽可能减少关闭范围，以确保恢复。

第一级操作：（首先执行）

关闭主机系统外围设备……

第二级操作：（完成上述操作后，当再次发现ＵＰＳ电池低于ＸＸ分钟或节点平均温度超过ＸＸ℃，任一条件满足，执行如下操作）

关闭非重要用户计算节点（ＡＢＣ组）……

第三级操作：（完成上述操作后，当再次发现ＵＰＳ电池低于ＸＸ分钟或节点平均温度超过ＸＸ℃，任一条件满足，执行如下操作）

关闭所有用户计算节点（Ｄ组）……

第四级操作：（完成上述操作后，当再次发现ＵＰＳ电池低于ＸＸ分钟或节点平均温度超过ＸＸ℃，任一条件满足，执行如下操作）

关闭ＳＡＮ存储设备和ＬＳＦ数据库服务器……

第五级操作：（完成上述操作后，当再次发现ＵＰＳ电池低于ＸＸ分钟或节点平均温度超过ＸＸ℃，任一条件满足，完成关机操作）

关闭ＳＣＳＩ磁盘阵列和所有存储节点……

特别关注：

１．　如时间非常紧急，ＵＰＳ电池低于ＸＸ分钟：

直接执行关机脚本：……

此脚本可分别将计算节点、接入节点、存储节点进行关闭。

２．　如时间极其紧急，ＵＰＳ电池低于ＸＸ分钟，可按《曙光－４０００Ａ超级计算机系统紧急关机操作方法》（ＳＳＣＳ（ＴＳ）－ＸＸＸＸ－ＸＸＸＸ－ＸＸＸＸ），直接拉闸操作。

（上述二个方法仅用于突发情况，非极其必要情况下严禁使用，应使用前列方法操作）

３．　如遇主机失电（如关机操作不及已掉电或突发自动掉电）应关闭所涉范围所有设备电闸开关。……

平台安全系统运维保障方案设计

实用文档 平台运维保障方案 1.目的 为了保障平台各项业务的正常开展，确保信息系统的正常运行，规范信息系统日常操作及维护阶段安全要求，特制订此方案。 2.系统日常操作及维护管理 2.1.建立双向联动责任人机制 所有涉及到业务平台的资源，包括主机操作系统、应用系统、网络设备和安全设备，指定电信接口人和支撑单位接口人双向联动，由电信公司指定维护接口人专门负责对接支撑单位的技术负责人和维护人员，电信公司的接口人对支撑单位的日常工作进行监督，支撑单位对业务系统的日常操作和维护按照本方案进行记录，做到责任到人，保证各个业务平台的正常运行。 2.2.操作系统日常操作及维护 (1)必须严格管理操作系统账号，定期对操作系统账号和用户权限分配进行检查，系 统维护人员至少每月检查一次，并报信息技术管理员审核，删除长期不用和废弃 的系统账号和测试账号。 (2)必须加强操作系统口令的选择、保管和更换，系统口令做到： ●长度要求：8位字符以上； ●复杂度要求：使用数字、大小写字母及特殊符号混合； ●定期更换要求：每90天至少修改一次。 (3)支撑单位维护人员需定期进行安全漏洞扫描和病毒查杀工作，平均频率应不低于 每月一次，重大安全漏洞发布后，应在3个工作日内进行上述工作。为了防止网 络安全扫描以及病毒查杀对网络性能造成影响，应根据业务的实际情况对扫描时 间做出规定，需安排在非业务繁忙时段。技术负责人应为每个系统指定专门的系 统维护人员，由系统维护人员对所负责的服务器进行检查，至少每天一次，确保

各系统都能正常工作；监控系统的CPU利用率、进程、内存和启动脚本等使用情况。 (4)当支撑单位维护人员监测到以下几种已知的或可疑的信息安全问题、违规行为或 紧急安全事件系统时，应立即报告技术负责人，同时采取控制措施，并进行记录： a)系统出现异常进程； b)CPU利用率，内存占用量异常； c)系统突然不明原因的性能下降； d)系统不明原因的重新启动； e)系统崩溃，不能正常启动； f)系统中出现异常的系统账户； g)系统账户口令突然失控； h)系统账户权限发生不明变化； i)系统出现来源不明的文件； j)系统中文件出现不明原因的改动； k)系统时钟出现不明原因的改变； (5)系统日志中出现非正常时间登录，或有不明IP地址的登录； (6)系统维护人员对操作系统的任何修改，都需要进行备案，对操作系统的重大修改 和配置（如补丁安装、系统升级等操作）必须向技术负责人提交系统调整方案，由信息技术管理员审核通过后方可实施。操作系统的配置和修改必须在非业务时间进行，重大调整必须提前准备应急预案和回退方案。 (7)保证操作系统日志处于运行状态，系统维护人员应定期对日志进行审计分析，至 少每月审计一次，重点对登录的用户、登录时间、所做的配置和操作做检查，在发现有异常的现象时及时向信息技术管理员报告。 (8)系统维护人员应设置操作系统日志归档保存功能，历史记录保持时间不得低于一 年。

运维应急预案

项目部运维应急预案 一、停电应急措施 1.当突然停电时，各部人员接到通知后，应立即赶赴现场，检查应急灯、走火通道指示等情况及停电原因，共同组织维持现场 的秩序； 2.检查机房设备，查看指示灯，确保设备在不间断电源提供的电力下正常运转。 3.如果属于阳蓄项目部营地内发生故障而引起停电的，积极配合检测排查。 4.后勤部门打开发电机前，通知业主关闭各自连接终端设备的排插电源。发电机启动后，快速检查用户终端设备是否又因突然 停电而引起的终端设备故障。 5.恢复供电后，各部门要检查各类电器设备是否完好，运行是否正常； 6.向业主及相关方反馈停电所造成的通讯设备及终端设备的情况。 二、台风应急措施: 1.各工作岗位人员应坚守岗位，未经允许或接替决不可离岗。 2.对电话线、网线等进行检查，必要时予以加固。应做好电力设备的保障工作，防止因台风引起线路故障或电击伤人事故。 3.关紧机房门窗及设备的框架的铁门，确保设备勿因外力而造成故障。 4.定点定时加强巡视，确保项目部内的各通讯设备的正常运行。 三、重大活动技术支持 1.重大活动由业主定义。 2.随时配合业主做重大活动现场技术支持 3.按业主要求进行现场的环境搭建及服务支持。 4.重大活动前，对系统进行调试检查工作。 5.重大活动期间，对信息系统设备进行定时巡视服务。 6.重大活动期间，如发生问题进行快速故障排除，必要时应聘请原厂服务人员保证重大活动过程中信息设备的稳定运行。 在紧急事故处理中应随时关注,预先防范,沉着应对,维持现场,拍照记录!

阳蓄项目部火警、火灾应急预案流程图 善后处理，记录备案。 阳蓄项目部停电、停水应急预案流程图

运维服务技术研发规划

1. 目的 在运行维护服务实施过程中，随着运维业务的扩大，可能面临各种问题（如硬件故障）、风险（如安全漏洞）以及新技术和前沿技术应用所提出的新要求，因此为解决相应的问题满足运维需求，制定本技术手册研发规划，用以解决在运维过程中面临的各种问题、应用所提出的新要求。我公司针对运维实施过程中可能出现的各种问题，提出相应的解决方案，及时发现解决问题和控制风险，提高IT 运维水平，同时在本研发规划中明确了研发方向、研发投入、研发进度计划以及研发成果等。 我公司在运行维护服务的主体定位于数据中心机房、智能化系统、桌面外设、操作系统等各种运行维护，通过系统监测和例行巡检等方式，及时发现并解决设备、系统运行中存在 受 控 分发号

的安全隐患和发生的故障，确保系统稳定、高效的运行，并制定了应急预案，确保了用户的系统持续性运行。技术研发体系依据公司运维服务的要求、结合目前主流的监控工具使用技术，为运维提供技术的解决方案，研究使用运维工具，辅助提高运行维护效率，为运维实施提供服务支撑和技术保障。 2.研发方向 4.技术手册研发规划

GFA6700用户手册2015.3.16 2015.4.16 NTSC9000网络服务器使用说明2015.4.10 2015.5.10 慧锐高清平台系统操作手册2015.4.25 2015.5.10 IBM TS3200带库操作指南2015.5.10 2015.6.10 IBM BladeCenter H SMM管理 使用手册2015.5.15 2015.6.25 BRT网络系统培训教材2015.6.28 2015.7.30 廉政宣传教育 基地 5.监控工具综合使用研发规划 类型研发内容启动日期结束日期部署项目 监控工具Watch up 网络监控软件 使用 2015.01.20 BRT中心机 房，市行政 服务中心 排队叫号主机监控工具 使用 2015.3.10 市行政服务 中心卓豪监控软件应用2015.06.21 廉政宣传教 育基地 6.应急预案规划 类型研发内容启动日期部署项目 应急预案BRT中心机房突发事件应急 处理预案 2015.1.24 BRT中心机房机房断电应急方案2015.3.10 市行政服务中心机房突发事件应急处理预案2015.3.10 市行政服务中心排队叫号系统应急预案2015.3.10 市行政服务中心网络系统应急预案2015.10.15

桌面终端设备运行维护和技术支持服务-服务流程及应急预案

桌面终端设备信息系统运行维护和技术支持 服务流程及应急预案 编制：****

一、运维服务方式 为了保证项目涉及的所有软硬件设备的正常运行，我方提供了灵活的服务方式，可以充分满足项目对运维服务及应急故障处理的需求，服务方式有以下几种：现场服务——派驻工作人员于工作日内提供技术支持、现场维护服务。 服务台——提供技术咨询、服务请求受理、任务分派、意见受理、客户服务专员快速通道、服务查询等服务。 远程支持服务——为远程终端用户提供远程技术维护、技术支持服务。 1.1、现场服务 我方将分派专业的技术工程师至现场提供运行维护服务及技术支持，不分节假日至少保证1人24小时值班。现场服务工程师严格履行合同中的各项指标承诺，对故障问题进行处理、分析和总结，保证项目涉及的软硬件系统满足客户的日常工作及应急处理的需求。 1.2、服务台 延伸了服务的范围，使业务流程与服务实施相结合，服务台人员对所有用户提交的服务请求、故障和问题等在服务系统进行记录、分派等操作，服务台提供以下的服务： ●对问询服务电话实时应答 ●直接处理简单的请求和投诉 ●记录事件/服务请求到服务管理系统 ●对所有事件进行初始化分析和设计解决方案 ●首先尝试解决事件再寻求二线支持 ●对所有事件监控与升级管理 ●提交服务管理报告 1.3、远程支持服务 我方为用户提供远程支持与协助服务，由远程技术支持工程师负责对终端客户的服务请求进行解答、指导和远程操作。 1）、电话支持

通过电话的方式协助用户完成设备故障排查、优化配置等工作。 2）、邮件支持 提供技术支持邮箱，可以通过邮件沟通，解决用户邮件咨询的问题。 3）、远程软件支持 通过远程协助软件，运用远程直接访问的方式，远程协助用户操作并解决问题。 二、服务流程 为保证运维服务工作的质量，我们制订了贯穿整个运行维护过程的服务流程，这个流程是服务成功实施的重要保障，有效的将人力和事件融合到流程中，用流程贯穿整个过程，将有效的提高服务质量。针对项目，我方将采用以下流程，并固化到服务台中，以更好地提供服务，保障项目服务水平达到项目要求，流程图包括： ●服务台及现场服务流程图 ●应急服务流程图 ●健康检查服务流程图 ●第三方服务流程图 ●其他服务流程图 2.1、服务台及现场服务流程图 为保证现场服务实施的质量能够稳定并不断有所提升，保障客户需求能够得到有效满足，保障现场服务实施团队为客户提供统一、标准化的服务支持，并为客户设立专门的客户服务专员，对运维进行全程跟踪，提升服务实施专业性，制定服务流程： 服务台及现场服务流程图

IT系统运维事故应急预案

1.编制目的 建立健全项目事故应急机制，提高XXXXXXXX应对项目实施过程中突发事故的能力，保持实施体系稳定，保障客户方权益和客户满意度，促进业务健康、可持续发展 1.1.编制依据 依据XXXXXXXXPMO发布《项目质量事故预防及处理制度》，制定本预案。 1.2.事故分级 按照突发事故严重性和紧急程度，突发质量事故分为特别重大质量事故、严重质量事故、一般质量事故和轻微质量事故四级。 a)重大：由于项目组的不规范操作、不规范管理，对系统生产环境造 成严重的数据丢失、系统崩溃、当机，以及造成重大经济损失，严 重影响客户满意的质量事故，定义为重大质量事故。 b)严重：由于项目组不规范的情况下对系统生产环境所做操作，而造 成对系统生产环境的严重影响（如造成数据丢失、数据混乱）、造 成一定程度经济损失，但能通过应急措施补救、挽回部分损失的事 故，定义为严重质量事故。 c)一般：由于项目组在未得到客户方授权的情况下对系统生产环境所 做操作，而造成对系统生产环境数据损坏或混乱，但未造成较大程 度经济损失，通过应急措施可以有效保证数据完备的事故，定义为 一般质量事故。 d)轻微：未对系统生产环境造成数据影响，但不符合规范化操作和管 理要求，对系统整理质量存在较大风险，且造成项目资产的不完整， 造成轻微经济损失的。如未对代码做及时定期的备份，导致代码版 本的不完整或代码版本管理混乱的，定义为轻微质量事故。 1.3.适用范围 本预案适用于XXXXXXXX负责实施、管理的全部项目。

2.组织指挥及职责 2.1.应急责任人 项目经理为项目应急责任人。 2.2.应急协调人 项目经理必须在发生质量事故后2小时内，向所在部门经理客观反馈问题，由项目经理初步判定项目事故等级。 级别在一般（包含）以下的事故，由项目经理作为应急处理协调人，负责总体监督、协调。 级别在严重（包含）以上的事故，由部门经理作为应急处理协调人，负责总体监督、协调。 2.3.专家组 实施支持中心作为实施专家团队，负责应急处理支持，由应急责任人在接到事故时，进行协调通报。 级别在严重（包含）以上的事故，实施专家团队必须指定专人参及事故应急处理，负责支持进行项目影响评估、损失弥补方案等工作。 2.4.涉及外包项目 整体或部分外包项目发生事故时，外包商必须指派项目经理的直属上级作为应急处理外包方协调人，外包方项目经理作为外包方负责人，由外包方负责人直接参及项目事故应急处理，协调人负责资源协调；涉及外包人员事故，该人员必须直接参及应急处理。事故应急处理完毕后再根据公司制度对上述公司或个人执行惩罚。 2.5.涉及第三方供应商 涉及第三方供应商的项目事故，第三方商必须指派专人负责，直接参及项目事故应急处理，事故应急处理完毕后再根据公司制度执行惩罚。3.事故处理程序 3.1.事故响应

(完整word版)运维系统及中心机房应急预案

运维小组应急预案 随着网络信息化建设的不断深入，加强机房各类设备、系统以及信息与网络安全等方面应对突发事件的处理能力将是我们目前面临的一项重要任务。为确保系统及机房安全与稳定，以保证正常运行为宗旨，按照“预防为主，积极处置”的原则，本着建立一个有效处置突发事件，建立统一指挥、职责明确运转有序、反应迅速处置有力的机房安全体系的目标，将正在发生或已发生事故的损害程度减轻到最低，确保员工安全，特制定本应急处置预案。 本预案共分为应用系统故障应急流程和机房突发事件应急流程 系统故障应急流程 一、系统故障应急流程说明 1、故障发生 系统运维服务小组可从以下途径得知故障的发生： 1.1、运维服务中心通过网管告警发现故障 1.2、维护站点通过维护巡检发现故障 1.3、用户发现故障，报给呼叫中心 1.4、驻场工程师发现故障 2、报障受理 监控系统运维服务小组得知系统故障发生后，立即响应，并向报障人或单位详细了解系统故障情况。 3、信息研判 运维服务小组根据了解到的系统故障情况进行分析判断，以确定采用一般故障处理流程还是立即启动系统突发故障应急处理预案。 4、预案启动 如需启动应急预案，则立刻通知系统突发故障应急领导小组，由领导小组启动应急预案，对系统突发故障应急事件进行全面管控处理。 5、资源确认

系统突发故障应急预案启动后，首先是根据现场突发故障实际状况、紧急程度、技术难度、备品备件等情况对相关资源（主要是参与人员）依据经验进行调度和确认，主要有以下资源： 我公司技术支持人员； 相关厂家技术支持人员； 我公司聘请的技术专家 6、预案执行 按照既定的预案进行突发故障抢修，如遇到问题及时向系统突发故障应急领导小组汇报。 7、预案终止 预案的终止时间由故障现场技术人员根据现场的实际进展情况，在与用户单位有关部门协调后报系统突发故障应急领导小组决定。 8、结果上报 预案中止后，相关预案参与人员将整个事件过程中的经验和教训，修改、完善事件应急预案。然后集中上报至系统突发故障应急领导小组。

网络运维-机房应急预案

网络运维小组应急预案 随着网络信息化建设的不断深入，加强机房各类设备、系统以及信息与网络安全等方面应对突发事件的处理能力将是我们目前面临的一项重要任务。为确保系统及机房安全与稳定，以保证正常运行为宗旨，按照“预防为主，积极处置”的原则，本着建立一个有效处置突发事件，建立统一指挥、职责明确运转有序、反应迅速处置有力的机房安全体系的目标，将正在发生或已发生事故的损害程度减轻到最低，确保员工安全，特制定本应急处置预案。 本预案共分为应用系统故障应急流程和机房突发事件应急流程 系统故障应急流程 一、系统故障应急流程说明 1、故障发生 系统运维服务小组可从以下途径得知故障的发生： 1.1、运维服务中心通过网管告警发现故障 1.2、维护站点通过维护巡检发现故障 1.3、用户发现故障，报给呼叫中心 1.4、驻场工程师发现故障 2、报障受理 监控系统运维服务小组得知系统故障发生后，立即响应，并向报障人或单位详细了解系统故障情况。 3、信息研判 运维服务小组根据了解到的系统故障情况进行分析判断，以确定采用一般故障处理流程还是立即启动系统突发故障应急处理预案。 4、预案启动 如需启动应急预案，则立刻通知系统突发故障应急领导小组，由领导小组启动应急预案，对系统突发故障应急事件进行全面管控处理。 5、资源确认

系统突发故障应急预案启动后，首先是根据现场突发故障实际状况、紧急程度、技术难度、备品备件等情况对相关资源（主要是参与人员）依据经验进行调度和确认，主要有以下资源： 我公司技术支持人员； 相关厂家技术支持人员； 我公司聘请的技术专家 6、预案执行 按照既定的预案进行突发故障抢修，如遇到问题及时向系统突发故障应急领导小组汇报。 7、预案终止 预案的终止时间由故障现场技术人员根据现场的实际进展情况，在与用户单位有关部门协调后报系统突发故障应急领导小组决定。 8、结果上报 预案中止后，相关预案参与人员将整个事件过程中的经验和教训，修改、完善事件应急预案。然后集中上报至系统突发故障应急领导小组。

系统运维事故应急预案

项目事故应急预案 1.编制目的 建立健全项目事故应急机制，提高XXXXXXXX应对项目实施过程中突发事故的能力，保持实施体系稳定，保障客户方权益和客户满意度，促进业务健康、可持续发展 1.1.编制依据 依据XXXXXXXXPMO发布《项目质量事故预防与处理制度》，制定本预案。 1.2.事故分级 按照突发事故严重性和紧急程度，突发质量事故分为特别重大质量事故、严重质量事故、一般质量事故和轻微质量事故四级。 a)重大：由于项目组的不规范操作、不规范管理，对系统生产环境造 成严重的数据丢失、系统崩溃、当机，以及造成重大经济损失，严 重影响客户满意的质量事故，定义为重大质量事故。 b)严重：由于项目组不规范的情况下对系统生产环境所做操作，而造 成对系统生产环境的严重影响（如造成数据丢失、数据混乱）、造 成一定程度经济损失，但能通过应急措施补救、挽回部分损失的事 故，定义为严重质量事故。 c)一般：由于项目组在未得到客户方授权的情况下对系统生产环境所 做操作，而造成对系统生产环境数据损坏或混乱，但未造成较大程 度经济损失，通过应急措施可以有效保证数据完备的事故，定义为 一般质量事故。

d)轻微：未对系统生产环境造成数据影响，但不符合规范化操作和管 理要求，对系统整理质量存在较大风险，且造成项目资产的不完整， 造成轻微经济损失的。如未对代码做及时定期的备份，导致代码版 本的不完整或代码版本管理混乱的，定义为轻微质量事故。 1.3.适用范围 本预案适用于XXXXXXXX负责实施、管理的全部项目。 2.组织指挥与职责 2.1.应急责任人 项目经理为项目应急责任人。 2.2.应急协调人 项目经理必须在发生质量事故后2小时内，向所在部门经理客观反馈问题，由项目经理初步判定项目事故等级。 级别在一般（包含）以下的事故，由项目经理作为应急处理协调人，负责总体监督、协调。 级别在严重（包含）以上的事故，由部门经理作为应急处理协调人，负责总体监督、协调。 2.3.专家组 实施支持中心作为实施专家团队，负责应急处理支持，由应急责任人在接到事故时，进行协调通报。 级别在严重（包含）以上的事故，实施专家团队必须指定专人参与事故应急处理，负责支持进行项目影响评估、损失弥补方案等工作。 2.4.涉及外包项目

运维故障应急预案

运维故障应急预案 V 1.0

深圳市XX 科技有限公司 修订记录 版本编号版本日期修订人说明1.0 2014-5-13 CC 初稿1.1 1.2 1 机房失火，断电，断网 1.1 紧急预案 1）全国各区域陆续反馈访问网站出现无法访问。

2）运维人员通过监控状态，无法远程登录服务器，ping 不通服务器。并紧急联系机房人员，询问初步情况，则可判断是否出现机房失火，断电，断网。3）技术部给业务部门、市场部门以及相关领导发出网站异常的通告，通告分为两部分。一 部分是对公司内的通告，包括事故的影响、恢复的时间；一部分是对公司外，描述因为系统 升级，而导致网站不能访问。4）再次紧急联系机房供应商，询问故障的发生原因，故障的严重性，是否后续能正常恢复 服务。 5）如故障严重，先能否挽救服务器，以存储服务器为优先。若存储服务器受损，则想办法 恢复数据；若无法恢复数据，则修改通告内容，告知业务部门要重新导入全部数据。6） 视故障影响范围，统计出未受影响的服务器。 7）如果是机房失火，断电，断网导致机房不可用，则尽快联系新的机房，开始重新搭建服 务。 8）评估网站恢复的时间点，修改通告内容。 1.2 风险预防 杭州和深圳均实施数据跨机房备份。 2. 区域性网络故障问题 1.1 紧急预案 1) 全国某个区域短时间内有多个客户反映无法访问网站，其他区域访问正常。 2) 运维人员通过监控状态，远程登录服务器查看机房服务器服务状态，判断是否存在服务 异常。

3) 如机房服务正常，运维人员测试出现故障区域的网络连接与dns 解析是否正常。 4）如果网络连接或者dns 解析不正常，则可认为出现了区域性网络故障问题。5） 给业务部门、市场部门以及相关领导发出网站异常的通告，通告分为两部分。一部分是 对公司内的通告，包括事故的影响、恢复的时间；一部分是对公司外受影响的区域客户，描 述因为客户所在区域网站故障，而导致网站不能访问。6）尽快联系当地运营商，询问网络故障的情况及恢复时间。 1.2 风险预防 网站CDN 镜像。 3. 域名失效故障 1.1 紧急预案 1）全国各区域陆续反馈访问网站出现无法访问。 2）运维人员通过监控状态，远程登录服务器查看机房服务器服务状态，判断是否存在服务 异常。 3）如服务器服务正常，再通过DNS 检测工具并发现域名IP 指向异常，则认为出现了域名 失效故障。4）给业务部门、市场部门以及相关领导发出网站异常的通告，通告分为两部分。一部分是 对公司内的通告，包括事故的影响、恢复的时间；一部分是对公司外，描述因为域名运营商DNS 解析故障，导致网站不能访问。 5）登录并查看域名供应商平台设置解析配置，若是域名供应商配置有问题，则修正该配置；若是DNS 解析平台故障，则寻找另外的DNS 解析平台，重新配置DNS 解析。

IT系统运维事故应急预案

I T系统运维事故应急预 案 Document number：BGCG-0857-BTDO-0089-2022

1.编制目的 建立健全项目事故应急机制，提高XXXXXXXX应对项目实施过程中突发事故的能力，保持实施体系稳定，保障客户方权益和客户满意度，促进业务健康、可持续发展 1.1.编制依据 依据XXXXXXXXPMO发布《项目质量事故预防与处理制度》，制定本预案。 1.2.事故分级 按照突发事故严重性和紧急程度，突发质量事故分为特别重大质量事故、严重质量事故、一般质量事故和轻微质量事故四级。 a)重大：由于项目组的不规范操作、不规范管理，对系统生产环 境造成严重的数据丢失、系统崩溃、当机，以及造成重大经济 损失，严重影响客户满意的质量事故，定义为重大质量事故。 b)严重：由于项目组不规范的情况下对系统生产环境所做操作， 而造成对系统生产环境的严重影响（如造成数据丢失、数据混 乱）、造成一定程度经济损失，但能通过应急措施补救、挽回 部分损失的事故，定义为严重质量事故。 c)一般：由于项目组在未得到客户方授权的情况下对系统生产环 境所做操作，而造成对系统生产环境数据损坏或混乱，但未造 成较大程度经济损失，通过应急措施可以有效保证数据完备的 事故，定义为一般质量事故。

d)轻微：未对系统生产环境造成数据影响，但不符合规范化操作 和管理要求，对系统整理质量存在较大风险，且造成项目资产 的不完整，造成轻微经济损失的。如未对代码做及时定期的备 份，导致代码版本的不完整或代码版本管理混乱的，定义为轻 微质量事故。 1.3.适用范围 本预案适用于XXXXXXXX负责实施、管理的全部项目。 2.组织指挥与职责 2.1.应急责任人 项目经理为项目应急责任人。 2.2.应急协调人 项目经理必须在发生质量事故后2小时内，向所在部门经理客观反馈问题，由项目经理初步判定项目事故等级。 级别在一般（包含）以下的事故，由项目经理作为应急处理协调人，负责总体监督、协调。 级别在严重（包含）以上的事故，由部门经理作为应急处理协调人，负责总体监督、协调。 2.3.专家组 实施支持中心作为实施专家团队，负责应急处理支持，由应急责任人在接到事故时，进行协调通报。

技术运维应急预案

IT应急预案 1.目的 提高公司处理IT设备、信息网络以及业务系统突发事件的能力，形成科学、有效、反应迅速的应急工作机制，最大限度地减少突发故障带来的危害。 2.适用范围 适用于佰融集团及集团下属分、子公司各部门 3.预案内容 3.1 工作原则 3.1.1预防为主。立足安全防护，加强预警，重点保护基础信息网络和重要信息系统，从预防、监控、应急处理、应急保障和防止恶意攻击等环节，采取多种措施，共同构筑安全保障体系。 3.1.2快速反应。在突发事件发生时，按照快速反应机制，及时获取充分而准确的信息，迅速处置，最大程度地减少危害和影响。 3.1.3以人为本。保障公司利益以及员工合法权益的安全，及时采取措施，最大限度地避免公司财产遭受损失。 3.1.4分级负责。按照“谁主管谁负责、谁使用谁负责”以及“条块结合”的原则，建立和完善安全责任制及联动工作机制。根据部门职能，各司其职，加强协调与配合，形成合力，共同履行应急处置工作的管理职责。 3.2相关措施 3.2.1建立安全、可靠、稳定运行的机房环境，防火、防盗、防雷电、防水、防静电、防尘；建立备份电源系统；加强所有人员防火、防盗等基本技能培训。3.2.2重要系统采用可靠、稳定硬件，落实数据备份机制，遵守安全操作规范；安装有效的防病毒软件，并及时更新升级；加强对员工的安全技术培训。 3.3应急预案 3.3.1设备发生被盗或人为损害事件应急预案 3.3.1.1发生设备被盗或人为损害设备情况时，使用者或管理者应立即报告设备管理员，同时保护好现场。 3.3.1.2设备管理员接报后，通知主管领导、总裁办公室，一同核实审定现场情况，清点被盗物资或盘查人为损害情况，做好必要的影像记录和文字记录。 3.3.1.3 事发部门和当事人应当积极配合相关部门进行调查，并积极汇报相关情况。 3.3.1.4设备管理员、安全员及时恢复设备正常运行，并对事件进行调查。在调查结束后一日内书面报告规划采购部。 3.3.2设备故障应急预案 3.3.2.1设备发生故障后，使用人应立即将故障现象通知IT设备管理员，IT设备管理员先进行检查故障原因，确定是否能够自己解决。 3.3.2.2不能自己解决，如有备用设备则启用备用设备，然后以维修申请单形式报送IT部部长。 3.3.2.3IT部部长接到维修申请单后，根据设备保修期情况，确定如何维修。

运维故障应急预案

运维故障应急预案文件编码（GHTU-UITID-GGBKT-POIU-WUUI-8968）

运维故障应急预案 V1.0 深圳市XX科技有限公司 修订记录 1机房失火，断电，断网 1.1紧急预案 1）全国各区域陆续反馈访问网站出现无法访问。 2）运维人员通过监控状态，无法远程登录服务器，ping不通服务器。并紧急联系机房人员，询问初步情况，则可判断是否出现机房失火，断电，断网。 3）技术部给业务部门、市场部门以及相关领导发出网站异常的通告，通告分为两部分。一部分是对公司内的通告，包括事故的影响、恢复的时间；一部分是对公司外，描述因为系统升级，而导致网站不能访问。 4）再次紧急联系机房供应商，询问故障的发生原因，故障的严重性，是否后续能正常恢复服务。 5）如故障严重，先能否挽救服务器，以存储服务器为优先。若存储服务器受损，则想办法恢复数据；若无法恢复数据，则修改通告内容，告知业务部门要重新导入全部数据。6）视故障影响范围，统计出未受影响的服务器。 7）如果是机房失火，断电，断网导致机房不可用，则尽快联系新的机房，开始重新搭建服务。 8）评估网站恢复的时间点，修改通告内容。

1.2风险预防 杭州和深圳均实施数据跨机房备份。 2.区域性网络故障问题 1.1紧急预案 1)全国某个区域短时间内有多个客户反映无法访问网站，其他区域访问正常。 2)运维人员通过监控状态，远程登录服务器查看机房服务器服务状态，判断是否存在服务异常。 3)如机房服务正常，运维人员测试出现故障区域的网络连接与dns解析是否正常。 4）如果网络连接或者dns解析不正常，则可认为出现了区域性网络故障问题。 5）给业务部门、市场部门以及相关领导发出网站异常的通告，通告分为两部分。一部分是对公司内的通告，包括事故的影响、恢复的时间；一部分是对公司外受影响的区域客户，描述因为客户所在区域网站故障，而导致网站不能访问。 6）尽快联系当地运营商，询问网络故障的情况及恢复时间。 1.2风险预防 网站CDN镜像。 3.域名失效故障 1.1紧急预案 1）全国各区域陆续反馈访问网站出现无法访问。 2）运维人员通过监控状态，远程登录服务器查看机房服务器服务状态，判断是否存在服务异常。 3）如服务器服务正常，再通过DNS检测工具并发现域名IP指向异常，则认为出现了域名失效故障。

运维故障应急预案

运维故障应急预案 V 1.0 深圳市XX科技有限公司 修订记录 1 机房失火，断电，断网 1.1 紧急预案 1）全国各区域陆续反馈访问网站出现无法访问。 2）运维人员通过监控状态，无法远程登录服务器，ping不通服务器。并紧急联系机房人员，询问初步情况，则可判断是否出现机房失火，断电，断网。 3）技术部给业务部门、市场部门以及相关领导发出网站异常的通告，通告分为两部分。一部分是对公司内的通告，包括事故的影响、恢复的时间；一部分是对公司外，描述因为系统升级，而导致网站不能访问。 4）再次紧急联系机房供应商，询问故障的发生原因，故障的严重性，是否后续能正常恢复

服务。 5）如故障严重，先能否挽救服务器，以存储服务器为优先。若存储服务器受损，则想办法恢复数据；若无法恢复数据，则修改通告内容，告知业务部门要重新导入全部数据。 6）视故障影响范围，统计出未受影响的服务器。 7）如果是机房失火，断电，断网导致机房不可用，则尽快联系新的机房，开始重新搭建服务。 8）评估网站恢复的时间点，修改通告内容。 1.2 风险预防 杭州和深圳均实施数据跨机房备份。 2. 区域性网络故障问题 1.1 紧急预案 1)全国某个区域短时间内有多个客户反映无法访问网站，其他区域访问正常。 2)运维人员通过监控状态，远程登录服务器查看机房服务器服务状态，判断是否存在服务异常。 3)如机房服务正常，运维人员测试出现故障区域的网络连接与dns解析是否正常。 4）如果网络连接或者dns解析不正常，则可认为出现了区域性网络故障问题。 5）给业务部门、市场部门以及相关领导发出网站异常的通告，通告分为两部分。一部分是对公司内的通告，包括事故的影响、恢复的时间；一部分是对公司外受影响的区域客户，

运维应急预案.

运维应急预案 随着网络信息化建设的不断深入，加强机房各类设备、系统以及信息与网络安全等方面应对突发事件的处理能力将是我们目前面临的一项重要任务。为确保系统安全与稳定，以保证正常运行为宗旨，按照“预防为主，积极处置”的原则，本着建立一个有效处置突发事件，反应迅速、处置有力的安全体系的目标，将正在发生或已发生事故的损害程度减轻到最低，特制定本应急处置预案。 一、系统故障流程说明 1. 故障发生获取途径 1.1 监控系统告警发现故障 1.2 用户发现故障 1.3 维护中心发现故障 2. 故障受理 系统故障发生后，运维人员立即响应，并向相关人员了解系统故障情况。 3. 信息研判处理 运维人员根据了解到的系统故障情况进行分析判断，以确定采用哪种处理方式。 4. 故障解除 故障解除时间由运维人员及现场技术人员根据现场的实际进展情况，在与用户协调后确认故障解决。 5. 结果处理 故障解决后，书写详细的故障报告提交给相关人员。 二、日常维护 1. 正常工作日内，对设备及系统的运行情况做监控，发生异常情况及时处理。 2. 节假日期间，保持通信畅通，遇有问题，尽快及时解决。 3. 认真做好数据备份工作，定期做好数据库的备份，每周检查服务器的运行和备份情况。 三、故障处理 1. 故障流程 2. 故障预案 2.1 发生通信线路中断、路由故障、流量异常等，经初步判断后及时联系IDC机房或者其

它相关人员，配合他们及时解决网络故障。 2.2 发生服务器软件系统故障，如有备份服务器，立即切换到备机上；如果没有备机，以快速解决为首要目标，故障出现的原因后续去排查；总之优先保证服务器能正常运行。 2.3 发生大流量网络攻击时，立即联系IDC机房及时处理。 2.4 发生服务器硬件故障后，联系硬件设备厂商，要求其快速上门处理。 2.5 发生业务数据损坏时，检查和备份当前业务系统数据，再调用备份数据来恢复。

云平台故障应急方案

云计算管理平台故障应急方案 目录 云计算管理平台故障应急预案 (2) 1目的 (2) 2 适用范围 (2) 3 预案流程 (2) 3.1 上报 (2) 3.2 了解和分析 (2) 3.3 处理方法 (3) 4 有关应急预案 (4) 4.1服务器操作系统的故障应急预案 (4) 4.2服务器软件系统故障应急预案 (4) 附件：云平台一般故障诊断表 (5)

云计算管理平台故障应急预案 1目的 为了确保云计算管理平台（以下简称云平台）使用过程中遇到突发事件后能正确、有序、高效地进行应急处理，保障工作的正常运转，结合实际，特制定本预案。 2 适用范围 本预案适用于云平台中可能出现的各类突发事件。 3 预案流程 云平台服务故障预防措施包括分析风险，建立检测体系，准备应急处理措施，控制影响扩大。 3.1 上报 各部门在云平台使用过程中遇到突发问题导致系统无法正常运 转时，报本部门管理员登陆确认，情况属实立即报知数据中心运维人员。 3.2 了解和分析 根据实际情况，我司安排应急值班，确保到岗到人，联络畅通，技术人员即时开展软件的检修工作，对具体情况进行了解并进行初步判断、处理，并将初步情况上报数据中心运维人员知晓。

3.3 处理方法 3.3.1 如突发问题为操作系统引起 首先由技术人员对突发问题进行分析，确定引起问题的具体原因，如操作系统已无法启动，则由技术人员将具体情况通报数据中心，进行系统备份恢复，如操作系统可启动，则由技术小组根据实际情况进行妥善快速处理。 3.3.2 如突发问题为软件引起 首先由技术人员收集系统日志，对突发问题进行分析，确定引起问题的具体原因，通过讨论确定初步解决方案，并对突发问题进行初步解决，如仍无法解决，则由技术人员备份数据库后，重装云平台解决。 3.3.3 如突发问题为网络引起 技术人员先将问题反馈给数据中心运维人员，协调网络管理员进行初步检查后确定问题原因，并在最短时间内给予解决。 在事件处理过程中，技术人员要随时将突发问题处理情况上报数据中心运维人员。

桌面终端设备运行维护和技术支持服务服务流程及应急预案

桌面终端设备运行维护和技术支持服务服务流 程及应急预案 Document number【SA80SAB-SAA9SYT-SAATC-SA6UT-SA18】

桌面终端设备信息系统运行维护和技术支持 服务流程及应急预案 编制：**** 一、运维服务方式 为了保证项目涉及的所有软硬件设备的正常运行，我方提供了灵活的服务方式，可以充分满足项目对运维服务及应急故障处理的需求，服务方式有以下几种：现场服务——派驻工作人员于工作日内提供技术支持、现场维护服务。 服务台——提供技术咨询、服务请求受理、任务分派、意见受理、客户服务专员快速通道、服务查询等服务。

远程支持服务——为远程终端用户提供远程技术维护、技术支持服务。 、现场服务 我方将分派专业的技术工程师至现场提供运行维护服务及技术支持，不分节假日至少保证1人24小时值班。现场服务工程师严格履行合同中的各项指标承诺，对故障问题进行处理、分析和总结，保证项目涉及的软硬件系统满足客户的日常工作及应急处理的需求。 、服务台 延伸了服务的范围，使业务流程与服务实施相结合，服务台人员对所有用户提交的服务请求、故障和问题等在服务系统进行记录、分派等操作，服务台提供以下的服务：对问询服务电话实时应答 直接处理简单的请求和投诉 记录事件/服务请求到服务管理系统 对所有事件进行初始化分析和设计解决方案 首先尝试解决事件再寻求二线支持 对所有事件监控与升级管理 提交服务管理报告 、远程支持服务 我方为用户提供远程支持与协助服务，由远程技术支持工程师负责对终端客户的服务请求进行解答、指导和远程操作。 1）、电话支持 通过电话的方式协助用户完成设备故障排查、优化配置等工作。 2）、邮件支持 提供技术支持邮箱，可以通过邮件沟通，解决用户邮件咨询的问题。 3）、远程软件支持 通过远程协助软件，运用远程直接访问的方式，远程协助用户操作并解决问题。 二、服务流程 为保证运维服务工作的质量，我们制订了贯穿整个运行维护过程的服务流程，这个流程是服务成功实施的重要保障，有效的将人力和事件融合到流程中，用流程贯穿整个

运维故障应急预案

运维故障应急预案 V 1.0 深圳市XX科技有限公司

修订记录 版本编号版本日期修订人说明 1.0 2014-5-13 CC 初稿 1.1 1.2 1 机房失火，断电，断网 1.1 紧急预案 1）全国各区域陆续反馈访问网站出现无法访问。 2）运维人员通过监控状态，无法远程登录服务器，ping不通服务器。并紧急联系机房人员，询问初步情况，则可判断是否出现机房失火，断电，断网。 3）技术部给业务部门、市场部门以及相关领导发出网站异常的通告，通告分为两部分。一部分是对公司内的通告，包括事故的影响、恢复的时间；一部分是对公司外，描述因为系统升级，而导致网站不能访问。 4）再次紧急联系机房供应商，询问故障的发生原因，故障的严重性，是否后续能正常恢复服务。 5）如故障严重，先能否挽救服务器，以存储服务器为优先。若存储服务器受损，则想办法恢复数据；若无法恢复数据，则修改通告内容，告知业务部门要重新导入全部数据。 6）视故障影响范围，统计出未受影响的服务器。 7）如果是机房失火，断电，断网导致机房不可用，则尽快联系新的机房，开始重新搭建服务。 8）评估网站恢复的时间点，修改通告内容。 1.2 风险预防 杭州和深圳均实施数据跨机房备份。 2. 区域性网络故障问题 1.1 紧急预案 1)全国某个区域短时间内有多个客户反映无法访问网站，其他区域访问正常。 2)运维人员通过监控状态，远程登录服务器查看机房服务器服务状态，判断是否存在服务异常。 3)如机房服务正常，运维人员测试出现故障区域的网络连接与dns解析是否正常。

4）如果网络连接或者dns解析不正常，则可认为出现了区域性网络故障问题。 5）给业务部门、市场部门以及相关领导发出网站异常的通告，通告分为两部分。一部分是对公司内的通告，包括事故的影响、恢复的时间；一部分是对公司外受影响的区域客户，描述因为客户所在区域网站故障，而导致网站不能访问。 6）尽快联系当地运营商，询问网络故障的情况及恢复时间。 1.2 风险预防 网站CDN镜像。 3. 域名失效故障 1.1 紧急预案 1）全国各区域陆续反馈访问网站出现无法访问。 2）运维人员通过监控状态，远程登录服务器查看机房服务器服务状态，判断是否存在服务异常。 3）如服务器服务正常，再通过DNS检测工具并发现域名IP指向异常，则认为出现了域名失效故障。 4）给业务部门、市场部门以及相关领导发出网站异常的通告，通告分为两部分。一部分是对公司内的通告，包括事故的影响、恢复的时间；一部分是对公司外，描述因为域名运营商DNS解析故障，导致网站不能访问。 5）登录并查看域名供应商平台设置解析配置，若是域名供应商配置有问题，则修正该配置；若是DNS解析平台故障，则寻找另外的DNS解析平台，重新配置DNS解析。 6）告知业务部门，临时处理解决方法。发出修改hosts的bat脚本给各区域销售和客服团队，并告知允许脚本前要先退出QQ管家。 7）跟进全国域名解析的进展。 8）全国域名恢复后，撤出通告，并通知内部人员。 1.2 风险预防 1）DNS加固安全锁。 2）每个月更换域名供应商和DNS解析平台的密码。 4. 机房网络设备，服务器故障 1.1 紧急预案 1）全国各区域陆续反馈访问网站出现无法访问。 2）运维人员通过监控状态，远程登录服务器查看机房服务器服务状态，判断是否存在服务异常。 3）如无法正常登录服务器，ping服务器不通，并紧急联系机房人员，并询问初步情况，则判断是否出现机房网络设备，服务器故障。 4）给业务部门、市场部门以及相关领导发出网站异常的通告，通告分为两部分。一部分是对公司内的通告，包括事故的影响、恢复的时间；一部分是对公司外，描述因为网站升级改造，导致网站不能访问。 5）逐个设备，服务器登录检查，找出有故障的设备，服务器。再次联系机房人员，检查相应的设备，看是否能正常恢复运作。 6）收到机房人员的反馈后，若设备，服务器还可用，则与机房供应商共同执行修复措施；若设备，服务器完全损坏，则让机房供应商协助购买新设备，服务器或者借用现有设备，服

桌面终端设备运行维护和技术支持服务服务流程及应急预案样本

桌面终端设备运行维护和技术支持服务服务流程及应急 预案

桌面终端设备信息系统运行维护和技术支持 服务流程及应急预案 编制：****

一、运维服务方式 为了保证项目涉及的所有软硬件设备的正常运行，我方提供了灵活的服务方式，能够充分满足项目对运维服务及应急故障处理的需求，服务方式有以下几种： 现场服务——派驻工作人员于工作日内提供技术支持、现场维护服务。 服务台——提供技术咨询、服务请求受理、任务分派、意见受理、客户服务专员快速通道、服务查询等服务。 远程支持服务——为远程终端用户提供远程技术维护、技术支持服务。 1.1、现场服务 我方将分派专业的技术工程师至现场提供运行维护服务及技术支持，不分节假日至少保证1人24小时值班。现场服务工程师严格履行合同中的各项指标承诺，对故障问题进行处理、分析和总结，保证项目涉及的软硬件系统满足客户的日常工作及应急处理的需求。 1.2、服务台 延伸了服务的范围，使业务流程与服务实施相结合，服务台人员对所有用户提交的服务请求、故障和问题等在服务系统进行记录、分派等操作，服务台提供以下的服务：

●对问询服务电话实时应答 ●直接处理简单的请求和投诉 ●记录事件/服务请求到服务管理系统 ●对所有事件进行初始化分析和设计解决方案 ●首先尝试解决事件再寻求二线支持 ●对所有事件监控与升级管理 ●提交服务管理报告 1.3、远程支持服务 我方为用户提供远程支持与协助服务，由远程技术支持工程师负责对终端客户的服务请求进行解答、指导和远程操作。 1）、电话支持 经过电话的方式协助用户完成设备故障排查、优化配置等工作。2）、邮件支持 提供技术支持邮箱，能够经过邮件沟通，解决用户邮件咨询的问题。3）、远程软件支持 经过远程协助软件，运用远程直接访问的方式，远程协助用户操作并解决问题。 二、服务流程

PPP项目运营维护应急预案

PPP项目运营维护应急预案 应针对自然灾害、重特大事故、环境公害及人为破坏等突发情况建立应急预案和相应的组织、指挥、设备等保障体系，并保证在出现突发情况时其保障体系能够正常启动。应急预案考虑发生重大或紧急事故时，能随时启动响应机制，配合相关责任或实施主体， 3.3.1成立应急组织机构 项目部成立上述突发事件应急领导小组，下设技术保障组、现场抢险组、、对外协调组、后勤保障组、物资保障组、事故调查组、善后处理组等专职组，负责指挥和协调处理安全生产事故紧急情况，保证事故应急救援预案的顺利执行。 应急领导小组以项目经理为组长，项目副经理为和安全部长为副组长，项目部各部门职员为成员的应急反应领导小组。 3.3.2应急小组机构框架图 应急小组机构框架图 组长：总经理

3.3.3应急管理职责 针对突发紧急事故特征，各专职组具体分工如下： 1、组长：制定和实施抢险方案，负责应急救援的组织、资源调配和事故上报；组织召开事故分析会，并提出预防措施；适时发布信息，将事故的原因、责任及处理结果公布于众，接受社会的监督 2、副组长：根据抢险方案，负责事故现场应急抢险救援的组织和协调工作，并及时将抢险进展情况上报应急组长。 副组长：副经理 副组长：技术总工 联 络 组 ： 办 公 室 抢 险 组 ： 工 程 部 救 护 组 ： 计 划 部 治 安 组 ： 安 质 部 调 查 组 ： 副 经 理 后 勤 组 ： 财 务 部 义 务 救 援 队

3、联络组：负责立即同医院、公安等救援单位进行联系，说明详细的事故地点、事故情况，并派人到路口接应； 4、抢险组：负责立即组织人员进行抢险和控制险情，疏通到达伤员位置的通道，为医疗救护组进入抢救伤员提供安全保障；负责事故现场贵重物资及设备的抢救、危险品的转移等。 5、救护组：负责组织人员疏导被困人员，根据伤员情况对伤员进行必要的护理，清除掉倒压在伤员身上的重物，及时组织护送重病伤员到医疗中心救治。不得盲目搬动重伤伤员，以免加重伤势，在这种情况下，应先与医院进行电话联系，向医生详细汇报情况后，征求医生建议。 6、治安组：负责事故现场的警戒和外来救援力量的引导，危及周边环境时，配合做好交通管制、人员疏导工作； 7、后勤组：协助制订应急反应物资资源的储备计划，按已制订的项目施工生产的应急反应物资储备计划，检查、监督、落实应急反应物资的储备数量，收集和建立并归档；定期检查、监督、落实应急反应物资资源管理人员的到位和变更情况及时调整应急反应物资资源的更新和达标；定期收集和整理各项目经理部施工场区的应急反应物资资源信息、建立档案并归档，为应急反应行动的启动，做好物资源数据储备；应急预案启动后，按照指挥部署，有效地组织应急反