·2017-04-07 11:20

系统工程师·某银行

系统高可用之容灾应急切换演练探讨活动总结

字数 9082阅读 10787评论 1赞 4

随着企业容灾备份的建设，定期进行容灾系统的切换演练，已成为验证系统高可用和练兵的重要窗口，然而容灾演练的现状却不尽人意。要么存在走过场形式化的演练，要么过度消耗资源。前一种，无法面对真实的灾难环境，后一种，给企业造成人力与物力上的浪费。通过本次关于容灾切换演练的活动探讨，让我们运维人对如何使容灾真正做到有备无患、切换演练做到行之有效，有了新的思路。
  
　　在活动中的精彩问题和观点交流时，我们把容灾切换演练的过程与项目管理理论紧密相连，下面就从项目的整体、质量、成本、时间、人力、风险等几个管理领域，对此次活动观点进行整理。
# 1、容灾切换演练中的整体规划
**典型问题：**

- 如何进行容灾应急切换演练的规划？
- 系统的高可用容灾应该建设到什么程度？
- 容灾策略制定过程和那些因素有关？

**观点总结：**

演练的整体规划是要从顶层设计一步步落实到底层实施，越是系统架构不够完善的企业，越要形成容灾的机制。演练，未必一定要选择停机的方式进行，如果之前没有演练过，可以设计好演练的计划和方案，先进行桌面和模拟演练，待系统建设完善和可用性提升后，在进行实操演练。演练，也不是最终目的，目的是进一步完善企业的应急机制。
  
　　在选择我们的容灾方案时候，要根据目前我们系统架构的可用性进行分析。按照国际标准SHARE78，从本地磁盘的备份，到将备份的磁带存储在异地，再到建立应用系统实时的切换的异地备份系统。并结合sla要求、建设预算情况、企业信息发展等进行同步规划。
  
**容灾演练的整体标准如下：**

企业在加强容灾处理能力、增强应急处置能力时。的确应该形成一整套容灾备份的标准和措施。
  
　　标准或者措施的落地，可以通过形成一整套容灾管理体系的文档，其标准应该包括有：
  
- 信息系统容灾备份的建设规范：是企业进行容灾建设的详细方案。从机房选址、网络容灾模式到主机系统、数据库选用方案等各个方面。
- 容灾备份策略和计划：梳理企业信息系统可能会遇到的各种灾难，以及在发生灾难后的应急措施。
- 系统切换演练的操作手册：规范应急恢复的操作步骤、内容详尽应包含演练切换说明、恢复脚本等等。

**在制定演练整体计划时应该遵循如下原则：**

- 目的明确，切记不切实际。如果一个目的不明确的容灾，技术人员很难设计，要数不确定，最好都是耗时耗力领导还不满意。
- 分步实施，循序渐进。容灾是以备不时之需，最重要还是搞好生产系统。容灾的需求项目最终是生产的复制和优化，不可能毕一功为一役。
- 合适最好，易于实现。容灾的模型适合自己的才是最好的，而且也要有利于运维，有利于实现，切莫最求新、大、豪。
- 忠于实际，日积月累。容灾系统建设要契合自己的实际，规章制度都要以实际为首要，不要想天衣无缝，都是过坑跨坎一天一天完善的。

**在整体管理方面对如下几个关键点进行掌控：**

- 做到灾备系统知根知底。谈到灾备系统，首先我们不管是管理者还是执行者，都要对自己的灾备系统有个清晰的了解。首先，我们的灾备系统是基于什么目的来建设的，能达到什么程度的容灾。灾备系统很多，投资力度不同，侧重点也不同。对于自己的灾备系统架构、性能、缺点、优点。了解的越深入越能知根知底，才能做到胸有成竹。
- 做好核心团队建设。再好的灾备系统都需要人来执行，如果说运维人员都没准备好，一切都是扯淡。一个稳定的核心团队建设，也是生产力的体现。团建建设不仅要平时就有的放矢，而且更要注重团队建设。技术运维更是如此，只有做好平时技术积累和训练，才能做到用时能顶的上，下的来。
- 组织上要有分工。真到灾备切换的时候，那就是最后的希望了。到那时，没有人是不紧张的，只要分工明确，职责清晰，才能到时正常运转。技术运维人员要这样，管理领导层更要明确分工，不要真到关键时刻，没有人下命令或者不知如何下命令。
- 协调能力要加强。一个系统可能是多个部门或单位在使用，切换需要各个部门相互配合，技术上切换成功，不代表切换成功。只有所以部门都步调一致，才能把切换成果最大化。
- 风险控制不容忽视。没有百分之百安全的方案，只有万分小心才能换得一次心安。平时要加强监控能力，及时对风险做出准确的判断和及时的预警，才能把风险降到最低。风险来自人力、技术、设备、管理、环境等等方方面面，再怎么重视也不为过。
- 做好各种预案。没有预案，就是耍流氓。做好预案，不仅是管理能力的提高，也是标准化建设能力体现，也是各部门各个人做好工作的前提。没有预案，真到意外时，没章可循岂不是笑话。
- 做好容灾应急演练测试工作。功夫再好，不拉出练练，谁知道行不行。只有经得住检验的容灾切换测试才是真正可靠的。要定期组织相关部门都参与容灾应急演测试，做到认证对待，沟通通畅，测试正常，结果达到预期才算正常。
- 最后一步，容灾切换。前面做的再多也是为最后一步准备，只有容灾切换成功的才是修成正果，得道升天。

# 2、容灾切换演练中的质量控制
**典型问题：**

- 如何通过对灾备中心的有效日常运维，来保障容灾系统的顺利切换？
- 容灾无大小，你都有哪些手段和措施？

**观点总结：**

因人力、成本等各种客观因素，容灾中心的日常运维标准往往不能达到生产中心的水平，下面内容讨论该从哪些方面保障容灾中心日常的运维工作的质量：
  
- 数据完整性、有效性审查机制：在容灾系统中建立起与生产系统的数据同步审查机制，并通过数据核对帮助生产系统发现可能出现的问题，尤其对于选用数据库DR功能的容灾模式，要时刻关注数据库同步状态，并根据预定指标进一步检查数据的一致性、完整性，进一步完善和优化生产系统和容灾系统。
- 系统资源监控：为了保证容灾系统接管生产系统时，不会因为IT因素、基础设施问题而发生接管失败，对IT基础设施所进行的日常例行检查、维护工作。目的是帮助系统组、业务组成员对生产系统及其容灾系统的运行情况进行监控，对故障进行快速准确定位。
- 软件版本管理：在软件版本进行变更、升级过程中，要及时对生产系统及其容灾系统的软件版本进行管理，保证容灾系统能按既定目标顺利接管业务，避免由于版本不一致造成的数据错误、业务接管失败。
- 容灾变更管理：严格控制、管理容灾系统中的变更行为，确保容灾变更平稳实施。严格审查发起，影响及资源评估、接受、执行、变更总结等。

**以数据库复制架构为例:**

- 日常检查（主备库状态、主备库切换状态、主备库日志同步情况、主备库是否有GAP、主备库警告日志、主备库负载情况等等）。
- 容灾技术准备检查（容灾切换手册或者工具有效性检查、环境变化检查、容灾技术体系完善性检查）
- 监控检查（容灾决策依据的监控点是否可用、是否有异常等等）
- 应急机制（流程、工具、人员有效性）

**其他对容灾演练质量控制的细节：**

1. 建立完整的组织体系(可以是虚拟的)，分工要求明确。
2. 灾备日常管理员必须得到上层领导授权。
3. 严格的变更评审机制（每一个关系到灾备系统的变更必须经过灾备管理审批，一旦确认于灾备有关，必须同步启动灾备中心变更）。
4. 严格执行演练手册的变更和版本控制；（在涉及到灾备相关系统的变更时，灾备日常维护人员必须注意演练手册的更新升级）。
5. 定期的组织学习，以及推演（这个很重要，能在过程中发现很多问题）。
6. 定期组织真正的演练。
7. 演练完成后一定要总结，并更新演练手册。

# 3、容灾切换演练中的风险规避
**典型问题：**

- 容灾演练隐患剖析
- 在做容灾应急切换的时候应该有哪些需要注意的风险点
- 应急演练的矛盾
- 影响容灾演练不成功的因素有哪些？

**观点总结：**

- **隐患之一容灾组织建设不健全：**

容灾团队需要有一个包括决策组、执行组、行政组的完整组织机构。需要有团队组织和完成日常管理、预警、演练、测试、培训等工作。
  
　　但很多企业建成容灾中心后，维护的工作量增加很多。但却忽视了要增加相应的维护人力资源，致使系统切换的执行人员保障不到位；再者，当发生灾难时，由于决策成员对于容灾中心的关注度不够，无法做出决策；行政组更是形同虚设，诸如人员调配、信息发布和公共关系等工作，都只能由技术部门完善。
  
- **隐患之二缺乏预警流程：**

企业当面对灾难时，很难严格按照预警流程执行，往往各个部门乱作一团，缺乏响应的预警流程机制，使容灾系统无法起到应有的作用。
  
　　结合演练工作将预警流程可以分为以下几个主要步骤：风险上报--风险评估--风险决策--风险告知--发起系统切换。
  
1、风险上报主要包括风险信息获知、收集、上报。风险获知后，应验证风险的真实性，完整性。
2、风险评估需要容灾团队根据上报资料做出全面评估，必要时形成评估报告，应包括造成灾难的几率、影响程度、发展趋势等。
3、风险决策需要领导组根据风险评估报告决定后续的处理，包括是否提前启动切换，进入风险警备状态。
4、风险告知需要行政管理组将有关风险的信息及时对内对外发布，保持消息沟通顺畅。
5、系统切换过程是在领导组在做出切换系统的决策后，按照应急预案和相关操作手册直接进入灾难恢复启动步骤。

- **隐患之三容灾演练流于形式：**

企业没有建立起完善的容灾演练机制，容灾演练利于形式，没有形成针对各灾难场景行之有效的演练模式。
　　
　　容灾演练不仅要检验灾难恢复流程的有效性，而且也要验证容灾系统是否能够实现正常的切换和回切。容灾演练的主要步骤应至少包括：制定演练计划、审批、演练启动、消息发布、演练切换、业务验证、演练回切、总结等。
  
　　在容灾演练切换过程中，应详细记录各个重要环节的时间点，并分析切换演练是否能够达到容灾系统和生产系统的各项指标。在演练后应及时总结经验，对发现的问题应及时解决，修改或优化演练的应急流程，完善演练应急预案。
  
- **隐患之四容灾测试不及时：**

如果对容灾系统的数据、功能、性能等方面没有充分的测试验证，就难以保证容灾系统实现数据保护和业务接管的功能。
  
　　进行测试时，尽可能采用测试脚本，避免人为误操作。测试环境尽可能与生产系统隔离。在不发生系统变更时，最好每月测试一次，否则须即时测试。
  
- **隐患之五没有做好容灾培训：**

通过容灾培训，可确保相关人员及时准确地了解容灾系统结构，熟悉测试、演练、灾难恢复流程，明确自身职责，使沟通、协作顺畅，提高工作技能和灾难应对能力。
  
　　培训计划由执行组与人力资源部门共同制订和执行。培训内容主要包括：容灾基础培训、容灾流程培训、容灾技术培训等。
  
　　以上所述的五个方面的隐患，任何一个环节的缺失都可能致使容灾中心形同虚设。养兵千日，用兵一时。所以任何一个环节都不能忽视。

其实对于容灾本身来讲，这是不仅仅是一个技术问题，更是一个考验组织、管理、流程的重要场合：
  
- 容灾架构。这是个技术问题，也是个成本问题。我们可以从技术角度将容灾架构打的坚实一点，先进一点，避免问题出在技术架构本身上。比如说选择什么样的数据复制架构，什么样的网络双活架构，什么样的应用负载架构等等。
- 容灾切换。首先这个容灾切换从技术上是否可行？RTO&RPO分别能保障到什么程度。然后对于切换本身来讲是否执行过或者验证过，验证的场合和真实的场合有哪些差异，做过哪些差异分析。
- 切换决策。这是个管理科学和决策科学。容灾切换的判定标准，容灾切换的流程设置，容灾切换的管理体系等直接决定灾难判定的准确率及时率，直接决定容灾决策和实施之间的时间效率。
- 很多企业在运行稳定后逐渐缩减运维部门人员，缩减运维资金投入，一种飞鸟尽，良弓藏的感觉，在这种情况下，在勉强开始把容灾演练推给IT运维部门，主观的认为这是IT运维部门的事，缺少整体团队配合。缺少领导的执行力，最终导致多种问题出现在容灾演练中。
# 4、容灾切换演练中的成本分析

**典型问题：**

- 关于容灾，IT在技术和人员的投入都有哪些？
- 容灾和灾备的建立是否都是不可或缺的？数据中心的初期建设重点应放在哪方面？
**观点总结：**

建设初期，无论从用户观念还是项目团队来说都是先要把数据中心稳定运行起来。只有吃过亏的运维人员才会这么重视数据容灾和灾备，从资金投入上初期也肯定会把重点都放在平稳运行上，但在初期有两个事情是要重视的：
  
- 可以没有容灾，可以没有灾备，但一定不能没有数据备份。哪怕最基础的数据备份，系统备份。这个在初期一定要有。
- 在初期的时候，一定给用户灌输数据容灾的重要性，让他知道在数据中心平稳运行后随着数据中心的重要级别建立相应的容灾或者灾备。在项目初期的方案设计中，也要提及数据容灾的内容。用户可以不做。但我们不能不说。

**对于IDC前期成本的投入：**

- IDC成长期，稳定远比容灾重要：IDC初期，系统建设、维稳远比想象中的复杂，很多系统都是经过一段时间的沉淀才能逐渐定型，运维人员也要经过一番折腾才能吃下系统。对于IDC最初起步的五年，时间精力基本全投入在系统成长、服务稳定这个点上。在有限的时间和资源上，很难再考虑容灾，即使允许规划，也仅仅是规划。
- 项目资金、资源的局限：项目规划得再好，没钱使之落地也是白搭。IDC初期建设，项目资金和资源基本耗尽，接下来的几年肯定侧重保护业务系统的发展。加之容灾备份这块，很多企业并不视为第一要务，所以在项目资金、资源上也会比较困难。
- 传统备份容灾已经能满足IDC当前需求：IDC初建之后，最适合IDC当前保护需求的肯定是传统的容灾备份技术，成本低、方便管理、维护成本低，换句话说最低的成本满足了预期需求。因此往往很多中小企业在IDC初期都会选择传统备份作为容灾保障。

企业对于容灾中心的态度就并不是过于重视，把容灾中心完全的推给运维，而并没有把有效的资金，人力，执行力持续的投入到容灾中心中。导致容灾中心虽然建立。建立的初期也一切运行正常。但慢慢的开始投入不足。人员不足。容灾中心开始无法与数据中心保持高度的一致和同步。没有足够的人员进行运维，巡检。在突发事件的时候，没有有效的执行力调度所有部门配合，而更多的是应用部门的抱怨和只能部门的不断催促，导致容灾中心运行多年到真正发挥时间无法正常运行。
  
　　容灾也好，数据备份也好，我觉得都和买保险一样。很多企业觉得这个保险的费用太高了。所以更多的时候选择不买，靠运气，靠运维。真正让企业的信息管理部门重视数据的重要性，才会让他们下定决心去支持容灾中心的建立和制度的完善。
  
# 5、容灾切换演练中的时间管理
**典型问题：**

- 容灾切换应急演练一年举行几次为宜？
- 7*24运行的生产系统，选择什么时间段切换演练最好？怎样决策？

**观点总结**

总体来说每个系统1-2次为宜，建议在年初统筹制定演练工作计划，根据维护窗口、重要业务变更日等时间节点，确定好演练次数。
  
　　同时，整理好要进行演练的重要系统，根据各系统的高可用建设模式，确定演练的方式，可以先进行桌面和模拟演练，在实战演练前，务必把每一个时间点的操作烂熟于心。
  
　　特别是要进行演练的系统较多时，更要做好统筹安排。比如，网络和系统的演练尽量不要安排在一起，如果因停机窗口等原因实在需要一起演练，一定要演练一套，验证一套，避免出现问题后，排查困难。
  
**演练的时间段应尽量选择业务最低谷进行，在做决策时，建议考虑以下几点：**

- 首先，确定要参加演练的业务系统，制定演练技术方案，若演练会造成停机，要确定其影响范围，和影响时间。
- 之后，制定完整的演练进度计划，对演练要做的每项具体技术工作，作出合理的时间估计，并细化完整的演练时间计划，并对演练进度进行监控。
- 最后，要严格控制好演练的时间进度，详细了解每个业务系统及其与其他业务系统之间的关联关系，建议您利用关键路径合理调整每个业务系统的切换顺序，保障演练在预定时间内完成，避免造成时间过长的停机。

**演练时间管理的细节如下：**

- 选择业务量少的时期，比如休息日，凌晨1-5点，生产线大型检修期。
- 无论什么时间。在进行演练之前一定要协调好所有部门。保证各个关键系统有主要人员驻留，保证一旦某个环节出现问题的时候可以找到人，找到备件，找到技术手册，找到密码。甚至找到一个房间的钥匙。
- 在演练之前做好应急预案，一切做最好的准备，最坏的打算。应急方案通知给相关所有的部门人员。
- 要有绝对的领导者对应急预案进行指挥，协调。做到遇到突发事件忙而不乱，各司其职，有序进行。不受外界因素摆布而打乱整个计划。
# 6、容灾切换演练中的人力管理

**典型问题：**

- 容灾应急切换由谁来组织
- 关于容灾，IT在技术和人员的投入都有哪些？
**观点总结：**

每个单位的信息化部门结构都不太相同，有的信息化部门属于管理部门。有的信息化部门属于服务部门，对于需要协调公司多数业务部门来进行的容灾应急切换演练。各个单位都是有那些部门来牵头组织实施呢。在实施过程中，信息运维部门又担当一个什么角色呢？
  
　　麻雀虽小，五脏俱全。容灾演练的组织架构应该不断完善健全。虽然每个单位的组织架构、规模各不相同，但在容灾实施过程中，应至少下设如下组织机构，才能在演练切换工作在组织架构和职责分工上得以明确。
  
- 领导组来负责决策，下达演练指令给指挥组。人员构成应包括公司领导（CIO）、技术部及风险部门的领导等
- 指挥组来负责具体的演练工作及整个演练的进度和过程控制。人员构成包括技术部门领导、参演业务部门等。
- 演练实施组来负责容灾环境搭建、应用系统的切换、容灾场景制定等。人员构成有技术部门的网络、系统、应用恢复人员。
- 演练保障组负责各项后勤工作，如信息发布、人员调配等。人员可以有行政部门、技术部门、维保厂商等。
- 演练验证组来负责对演练切换、回切后的业务验证。人员由参演业务验证部门人员构成。

总得来说，组织部门可以是专门的风险合规部门，由他们牵头；但实施和上报是科技部门的责任；业务部门负责验证；后勤部门负责后勤；领导把控大局。
  
**容灾切换演练中人力管理存在的痛点：**

信息化运维部门，属于服务部门。缺少管理权限，上层有信息化管理部门。但对业务完全不同。一个空头部门，基本不起作用。在网上的公司管理层对信息化重视程度不够。所以我们的业务变更，切换，都是由我们提出报告，实施，但由于缺少管理权，所以以前就有过业务迁移过程中各个应用部门还在不断催促，询问什么时候恢复业务，其实这个在之前就已经下达过通知，但真正执行的时候还是会受到各个部门的影响，有时候甚至为了迁就重要部门或者领导而不得不临时变更计划。
  
　　各个行业不一样，即使同一个行业也不尽相同，有的是科技部牵头，有的是风险管理部，有的是总行组织的，所以切换要看级别，有的就是一个基于科技内部的，有的是演给监管部门看到，有的是演给自己看的。
# 容灾切换演练流程

最后，结合本次活动中会员们提出的精彩观点，对演练流程做一个全面的梳理：
  
容灾切换演练主要由以下4个阶段构成:
  
- **阶段一演练：演练前期准备**

前期准备主要有如下具体工作：

1、演练方案的提交与发布：首先演练项目组要根据本次容灾演练系统 的自身特性，结合硬件资源和容灾中心现状，制定容灾演练方式和技术实现手段，通过与容灾演练应用系统的应用开发商进行访谈沟通，确认容灾演练应用系统对应的容灾场景和技术实现手段，做出详细的演练方案。包括存储系统的切换，应用系统的切换，网络系统及防火墙的切换。

2、演练项目组组织召开方案评审会：请容灾演练领导和专家、容灾中心领导和专家就容灾演练方案进行综合评审，最终确定容灾演练方案。

3、业务验证案例准备：演练项目组要督促本次进行演练的业务部门进行业务验证案例的准备，并和业务专家一起综合评审，最终确定业务验证案例方案。

4、演练项目组要组织相关人员进行人员联系表、分时计划、人员签到表、演练记录表等表的编写和更新，上报本次参演部门及参演人员给演练领导组并得到批准。

- **阶段二演练前的准备工作**

这个阶段主要进行当日正式演练开始前的准备工作。当时在较早时间要发“演练通知提醒”，提醒当时参加演练的相关人员进行演练前的准备及准时到岗。演练项目组通知本次演练的系统小组进行应用系统的检查，网络小组进行网络的检查，保证演练正式幵始能进行切换。并将检查结果上报演练指挥组。如果出现检查不通过情况，由演练指挥组请求演练领导组决定是否进行这次演练。
  
- **阶段三演练执行**

1、系统切换操作

这一阶段为正式演练的开始。当进入正式演练的幵始时间，演练指挥组将发出“演练开始”命令。整个演练将按照“演练计划方案”进行。进行系统的 切换和网络的切换。
  
2、测试验证

首先由系统组进行各系统的测试验证，业务部门依据容灾演练方案中由应用开发商提供的容灾演练应用系统的业务测试场景和详细测试步骤进行容灾演练应用验证，认真仔细核对业务测试场景得出的结果与测试脚本在生产系统中测试查询结果是否一致，如果结果一致，容灾演练业务场景成功结束，如果不一致需要找出问题的原因，重新进行容灾演练。此阶段的结果决定此 次演练的成功与失败。
  
3、系统回切恢复

此阶段进行演练恢复阶段。进入此阶段，不管之前演练的成功与失败，为保证不影响第二业务的正常运转。都必须进行业务系统的恢复。系统组和网络组进行系统恢复。
  
4、回切后业务验证

系统组和网络组进行系统恢复后，业务部门还要进行业务验证。保证生产系统的正常运转。
  
- **阶段四演练总结**

容灾演练结束后，召开容灾演练总结会，容灾项目组和容灾演练参与人员要就整个演练过程中出现的问题进行总结，针对每个问题都要找到是什么原因引起来的，应该如何解决和避免同样的问题再次出现，汇总问题列表并 提出改进建议和方法。至此整个容灾演练圆满结束。

容灾切换演练

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论1 条评论

gz_kevin系统工程师www.gzzknt.cn
2017-04-07 11:54

总结的非常到位

Ctrl+Enter 发表

匿名评论

系统高可用之容灾应急切换演练探讨活动总结

添加新评论1 条评论

本文隶属于专栏

作者其他文章

相关问题