运维应急故障处理方案

运维应急故障

处理方案

文件编码AQ2I-02-S001 版本V03

文件层级□一阶□二阶

■三阶

文件类别

■体系文件

□技术文件

编制部门运维部机密等级■内文□秘密□机密□绝密

编制人文件类别■通用□项目

审核编制日期

审批生效日期

总页数9 分发编号01 文件发布盖章

公司名称文件编码AQ2I-02-S001 文件名称运维应急故障处理方案页次/总页码 1 /9

文件制/修订记录

页码章节制/修订记录

版本

修订人修订日期备注修订前修订后

全部全部首次制定无V01 2,3 4,5 职责/作业内容V01 V02

全部全部按新的角色职责

定义更新角色

V02 V03

公司名称文件编码AQ2I-02-S001

文件名称运维应急故障处理方案页次/总页码 2 /9

1 目的

用于突发性事件发生后的应急处理措施，确保在紧急情况下仍能保证系统平台正常运行

2 适用范围

本程序适用于所有在系统平台运行过程中能事先预测到的非自然灾害所产生的突发性事件。

3 术语和定义

突发事件:

由于系统软件，硬件，接入线路，机房电力，温度等发生问题和突发意外，引起故障时间达30分钟以上，造成关键服务不可用，形成重大影响的事件。

4 职责

4.1运维工程师：

负责突发性事件应急处理计划和对策的拟定和执行。

4.2 平台研发部，移动应用部，客户服务部，服务营销部：

由部门负责人及相关人员共同处理突发性应急事件。

4.3质量管理工程师：

负责突发性事件应急处理计划和对策的监督执行。

5 作业内容

公司名称文件编码AQ2I-02-S001

文件名称运维应急故障处理方案页次/总页码 3 /9

5.1突发事件分类和应急处理

5.1.1 基础设施环境不可用

包括运营商网络割接、机房电力、空调、线路接入等基础设施出现故障，且影响时间高于30分钟的。

对于运营商已告知问题原因时处理方案：

1.提前通知相关运营人员和客户服务部

2.通告影响时间，影响范围

3.公告用户

4.调整域名解析，启用容灾机房

对于运营商未告知问题原因时处理方案：

1.紧急联络机房接口人

2.了解故障原因，和影响时间，评估影响范围

3.紧急公告，启用预案同已知问题处理

5.1.2 设备不可用

服务器硬件故障、交换机及防火墙等网络设备发生故障，且影响时间高于30分钟的故

公司名称文件编码AQ2I-02-S001 文件名称运维应急故障处理方案页次/总页码 4 /9

障处理方案：

1.通知相关运营人员和客户服务部

2.启用备份设备

3.分析故障原因，通知厂家售后

5.1.3服务不可用

软件程序问题，且影响时间高于30分钟的故障处理方案：

1.通知相关运营人员和客户服务部

2.回滚到上一个稳定软件版本

3.保存日志文件，分析定位问题原因

4.通知开发人员修正软件缺陷

5.测试通过之后重新上线

数据库问题，且影响时间高于30分钟的故障处理方案：

1.通知相关运营人员和客户服务部.

2.提前建立数据库集群

3.从库出现问题，访问解析到其它从库上

4.主库出现问题，将一台从库提升为主库

5.定期全备份和增量备份数据文件

5.保存日志操作文件

遭受恶意攻击，且攻击时间高于30分钟的故障处理方案：

1. 通知相关运营人员和客户服务部.

2.在防火墙上操作内容：

定期检查更新防火墙策略；

屏蔽恶意IP；

限制每秒的连接数。

3.在服务器上操作内容：

提前部署cache服务器；

屏蔽公网访问核心服务端口；

公司名称文件编码AQ2I-02-S001

文件名称运维应急故障处理方案页次/总页码 5 /9

设定iptables 策略。

4.病毒入侵等情况操作内容：

定期扫描系统和应用软件漏洞；

定期升级系统Patch；

利用云服务。

对于已经执行上述措施，仍无法抵御攻击的情况，将部分服务迁移到公有云上，利用云服务进行容灾。

5.1.4 正常业务量徒增

处理方案：

1.和相关运营部门建立即使沟通机制，了解产品推广活动

2.购置IDC富余带宽，用于抗峰值

3.将关键服务分布式部署

5.2 故障记录和备案

5.2.1建立【事件记录表】

5.2.2分析故障原因，制定解决方案，避免相似故障再次发生

5.3 应急预案演练

5.3.1明确演练范围和参与人员

如果组织是第一次进行灾难恢复演练，不要尝试在演练中测试整个业务连续性计划，而应该选择计划中的一两个部分来进行测试。多次小规模的演练比一次大规模的演练能够让组织获得更多的价值。

在明确了演练的范围后，组织需要确定演练的参与人员。参与人员通常是与演练范围相对应的执行人员，同时也可以包括熟悉演练范围的管理人员。

预先明确演练范围和参与人员的好处在于，能够深入演练，加深理解，并控制规模。当组织逐渐适应这种演练时，就可以开始进行复杂的、测试整个计划的演练了。

公司名称文件编码AQ2I-02-S001

文件名称运维应急故障处理方案页次/总页码 6 /9

5.3.2组建演练规划小组

这是一个关键的步骤，组织需要将一小部分演练参与人员纳入到规划小组中。小组成员也可以包括非具体执行人员，但他们必须了解演练范围内的业务和流程。规划小组至少应该包含一位公司高层，以增强规划的可信度。

5.3.3设定演练目标

让规划小组的每一个成员都了解本次演练的范围，并通过讨论设定演练的目标。组织第一次进行演练，目标应该设定在三个到五个之间——尽量简化每一次演练。并且，在测试过程中尽量让这些目标量化或者可视化。

以下是演练目标设定的一些例子：

?验证灾难恢复流程的有效性

?验证应急通讯列表的可用性并及时更新

?让高层管理人员熟悉他们的角色和责任

?测试并提高员工的灾难恢复意识

?验证恢复时间目标（RTO）

5.3.4 设计演练场景

灾难场景可以很简单，也可以很复杂。它可能是简单的一次火灾，也可能是恶劣天气之后的一系列事件。不论如何，该场景必须能够对预定的业务连续性计划某一（些）部分进行测试，并能够达到规划小组所设定的目标。

在创建场景的时候，可以思考以下几个问题：场景是否可信？参与人员会相信该场景的可能性吗？该场景是否可能发生？是否能够获得一个积极的结果？是否足够简单？是否含有过于专业的术语以至于观众无法听懂？是否超越了参与人员的知识范围？场景解决方案是否过于简单？参与人员是否适合这一场景的设定？

组织可以考虑使用一个曾经发生过的灾难事件作为场景，这一事件可能导致，或者曾经导致了组织的业务中断。同时，组织也可以通过参考风险分析报告，选择一个最有可能发生的会影响到业务的事件。当然，风险分析报告内的事件排序

公司名称文件编码AQ2I-02-S001

文件名称运维应急故障处理方案页次/总页码7 /9

必须要被所有参与人员认可。还有一个方法是设计一个会突出已知缺点的场景，这种情况下，需要在演练中引导参与人员，让他们逐渐意识到这些缺点。

设计灾难场景时，使用参与人员都知道的真实的地点，并使用城市、当地媒体、消防部门的名称，可以帮助提高场景的真 …… 此处隐藏：2804字，全部文档内容请下载后查看。喜欢就下载吧 ……