运维应急故障处理方案(共11页).doc

精选优质文档-倾情为你奉上运维应急故障处理方案文件编码AQ2I-02-S001版本 V03文件层级 一阶 二阶 三阶文件类别体系文件技术文件编制部门运维部机密等级内文 秘密机密 绝密编制人文件类别通用项目 审核编制日期审批生效日期总页数9分发编号01文件发布盖章 文件制/修订记录页码章节制/修订记录版本修订人修订日期备注修订前修订后全部全部首次制定无V012,34,5职责/作业内容V01V02全部全部按新的角色职责定义更新角色V02V031 目的用于突发性事件发生后的应急处理措施，确保在紧急情况下仍能保证系统平台正常运行2 适用范围本程序适用于所有在系统平台运行过程中能事先预测到的非自然灾害所产生的突发性事件。3 术语和定义突发事件:由于系统软件，硬件，接入线路，机房电力，温度等发生问题和突发意外，引起故障时间达30分钟以上，造成关键服务不可用，形成重大影响的事件。4 职责4.1运维工程师：负责突发性事件应急处理计划和对策的拟定和执行。4.2 平台研发部，移动应用部，客户服务部，服务营销部：由部门负责人及相关人员共同处理突发性应急事件。4.3质量管理工程师：负责突发性事件应急处理计划和对策的监督执行。5 作业内容5.1突发事件分类和应急处理5.1.1 基础设施环境不可用包括运营商网络割接、机房电力、空调、线路接入等基础设施出现故障，且影响时间高于30分钟的。对于运营商已告知问题原因时处理方案：1.提前通知相关运营人员和客户服务部2.通告影响时间，影响范围3.公告用户4.调整域名解析，启用容灾机房对于运营商未告知问题原因时处理方案：1.紧急联络机房接口人2.了解故障原因，和影响时间，评估影响范围3.紧急公告，启用预案同已知问题处理5.1.2 设备不可用服务器硬件故障、交换机及防火墙等网络设备发生故障，且影响时间高于30分钟的故障处理方案：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服务器；屏蔽公网访问核心服务端口；设定iptables 策略。4.病毒入侵等情况操作内容：定期扫描系统和应用软件漏洞；定期升级系统Patch；利用云服务。对于已经执行上述措施，仍无法抵御攻击的情况，将部分服务迁移到公有云上，利用云服务进行容灾。5.1.4 正常业务量徒增处理方案：1.和相关运营部门建立即使沟通机制，了解产品推广活动2.购置IDC富余带宽，用于抗峰值3.将关键服务分布式部署5.2 故障记录和备案5.2.1建立【事件记录表】5.2.2分析故障原因，制定解决方案，避免相似故障再次发生5.3 应急预案演练5.3.1明确演练范围和参与人员如果组织是第一次进行灾难恢复演练，不要尝试在演练中测试整个业务连续性计划，而应该选择计划中的一两个部分来进行测试。多次小规模的演练比一次大规模的演练能够让组织获得更多的价值。    在明确了演练的范围后，组织需要确定演练的参与人员。参与人员通常是与演练范围相对应的执行人员，同时也可以包括熟悉演练范围的管理人员。    预先明确演练范围和参与人员的好处在于，能够深入演练，加深理解，并控制规模。当组织逐渐适应这种演练时，就可以开始进行复杂的、测试整个计划的演练了。5.3.2组建演练规划小组这是一个关键的步骤，组织需要将一小部分演练参与人员纳入到规划小组中。小组成员也可以包括非具体执行人员，但他们必须了解演练范围内的业务和流程。规划小组至少应该包含一位公司高层，以增强规划的可信度。5.3.3设定演练目标  让规划小组的每一个成员都了解本次演练的范围，并通过讨论设定演练的目标。组织第一次进行演练，目标应该设定在三个到五个之间尽量简化每一次演练。并且，在测试过程中尽量让这些目标量化或者可视化。 以下是演练目标设定的一些例子： 验证灾难恢复流程的有效性 验证应急通讯列表的可用性并及时更新 让高层管理人员熟悉他们的角色和责任 测试并提高员工的灾难恢复意识 验证恢复时间目标（RTO）5.3.4 设计演练场景灾难场景可以很简单，也可以很复杂。它可能是简单的一次火灾，也可能是恶劣天气之后的一系列事件。不论如何，该场景必须能够对预定的业务连续性计划某一（些）部分进行测试，并能够达到规划小组所设定的目标。    在创建场景的时候，可以思考以下几个问题：场景是否可信？参与人员会相信该场景的可能性吗？该场景是否可能发生？是否能够获得一个积极的结果？是否足够简单？是否含有过于专业的术语以至于观众无法听懂？是否超越了参与 人员的知识范围？场景解决方案是否过于简单？参与人员是否适合这一场景的设定？    组织可以考虑使用一个曾经发生过的灾难事件作为场景，这一事件可能导致，或者曾经导致了组织的业务中断。同时，组织也可以通过参考风险分析报告，选择一个最有可能发生的会影响到业务的事件。当然，风险分析报告内的事件排序必须要被所有参与人员认可。还有一个方法是设计一个会突出已知缺点的场景，这种情况下，需要在演练中引导参与人员，让他们逐渐意识到这些缺点。    设计灾难场景时，使用参与人员都知道的真实的地点，并使用城市、当地媒体、消防部门的名称，可以帮助提高场景的真实性。    在演练的过程中，主持人需要逐渐给出更多的场景信息，并引导参与人员进行讨论，这要求掌握好时机，并最终能够导出一个具有逻辑性的结论。场景设计的一些例子包括： 上午10点5分，大楼报出火警 上午10点15分，火灾应急响应小组报告服务器机房起火 上午10点20分，部门经理报告一个小组成员尚未找到，可能还在火灾大楼里    这些能够引起讨论的信息可以通过各种方式传递给参与人员，例如，可以发送到参与人员的Email地址，也可以现场发放复印件，或者只是主持人口头说明这些信息，不论选择了哪种方式，要适合参与人员，并且在加入时尽量使信息更加生动有趣。5.3.5 设计演练评估清单在明确了演练范围、设定好演练目标后，为了恰当地衡量这些目标是否达成，需要设计一份演练评估清单，用以在演练中跟踪和记录目标的达成情况。    评估清单应该包括评估者的姓名、需要评估的目标、评估的标准等，并为评估者预留出进行评论和做笔记的地方。一份好的评估清单能够帮助组织： 确保对演练进行很好的评估 突出与理想状态之间的差距 可以在培训和宣传中突出缺点 突出设施设备的不足之处 强调执行人员的支持和意见的必要性 强调持续维护和演练的必要性5.3.6选择员工担任演练中的角色灾难恢复演练中有几个基本的角色，即参与者、观察者、评估者和主持人，每个角色都很重要，并且需要在演练前进行相应的指导与培训。    参与者：通常负责业务连续性计划特定部分的具体执行，他们不必参与到演练的规划。    观察者：可以是组织中的任何人，只要他们对组织的业务或者流程有基本的了解即可。这些人需要一直参与到演练中，并允许在演练的任何部分提出具有建设性的评论和意见。    评估者：负责评估演练和填写评估清单，观察演练中的一个或多个目标是否达成。    主持人：负责整个演练的管理、参与人员之间的沟通，提供额外的信息以逐渐推进讨论，负责演练后的总结，并完成演练报告。5.3.7 召开演练前的指导会议在演练实施前，召开辅导会议，向参与人员解释参与者、观察者和评估者的角色，允许他们提问，并为每一个人提供演练日程、地点和其它信息。    最重要的是要向参与人员明确一些基本规则，以帮助参与人员消除紧张情绪，这些规则包括： 是整个组织在进行测试，不是某一个参与人员 学习业务连续性计划，并将演练当作一次培训 开诚布公地进行对话 尊重他人 讨论时不准用手指指着别人 不要期望演练能够解决所有问题 保持心情愉快5.3.8进行演练后的总结演练后的总结是整个演练过程中最重要的步骤之一。总结会议应讨论并记录演练中观察到的优点、缺点，以改进、提升组织的业务连续性计划。总结会议可以在演练后立刻举行，但更好的建议是放在演练后的一到两天，以便给每一位参与人员时间来整理和完善他们的反馈意见。最终形成【应急预案演练记录表】5.3.9发现不足及时完善6.表单应急预案演练记录表保存期 4年专心-专注-专业