企业如何实现高效灾备切换管理？关键回顾与经验复盘

Posted 2022-02-04 嘉为科技

一、灾备系统建设背景

为了更高的业务连续性和更安全的数据保护，以及响应监管的要求，现在越来越多的企业建设灾备切换系统。

灾备切换系统能够保障在主系统有问题或业务受损的情况下，业务仍旧能正常运行。

在最开始的时候，建设灾备系统的大多是金融机构，不过随着IT基础设施的发展，现在一些能源行业如电力等也开始针对业务系统进行灾备环境建设。

除此之外，一些互联网公司如电商平台和内部供应链也会建设灾备系统。

建设了灾备系统之后，每年需要通过灾备演练检验系统是否可用，不然等到实际出现问题时再进行修复又为时过晚。

1. 灾备切换演练的必要性和目的

通常，一个核心系统至少每年需要进行一次灾备演练。灾备切换演练的目的，总结起来有四个：

· 验证突发事件应急预案可行性：可以是验证技术层面、角色层面或流程层面，通常也会涉及到灾备系统的切换。

· 验证灾备系统可用性：主要是验证技术层面，通过演练的方式验证系统是否可用。

· 检验和完善切换手册和文档：在演练过程中，检验之前沉淀的文档或指引手册是否能够有效地指导切换工作，如果不行的话，需要进行完善和补充。

· 提高参演人员的应急处理能力，熟悉切换流程：提高参演人员的应急处理能力，提高人员灾备切换流程的衔接。

2. 灾备系统使用复杂

灾备切换系统虽然是为了保障业务而建，但实际上，由于灾备系统较为复杂，企业实施切换的意愿不强烈。

灾备系统的复杂主要有三点：灾备环境不同、技术多且复杂、协作复杂。

· 灾备环境不同：环境可能涉及冷备、双活（同城、异地）、两地三中心。环境的不同导致需要涉及的技术和切换过程不同，因此造成了切换的困难。

· 技术多且复杂：在灾备切换过程中涉及到的切换对象种类丰富，比如中间件、数据库、Web前端、存储等的切换。

· 协作复杂：切换动作需要人为的配合和协调，甚至需要跨部门的多人配合，因此在组织效率上有所影响。

二、典型场景案例分享

基于以上背景，我们将结合一个具体的案例进行分析，一起来看在实际灾备切换的过程中，有没有较好的方式去提升切换效率和成功率。

根据个人理解，切换过程共分为三个环节：事前、事中和事后。

事前工作是灾备切换的一些准备工作，也是在切换中耗时最长的环节。事中是执行灾备的过程，事后就是灾备的收尾工作，比如灾备的复盘。

1. 事前：准备工作

简单分为四个准备工作：组建切换工作小组、指定方案、确认方案、获得授权。

但是随着业务系统的复杂程度升高，可以在这四个工作的基础上修改。具体细节如下图：

1）事前准备的传统方式

在传统的切换演练里，一个单向切换（不考虑回切），就需要23步。

每一步的具体动作，由一个人负责。负责人通过图形界面的操作去执行命令，完成之后对时间进行记录。

其中，穿插着不同的人员进行协作，有可能第一步执行的人和第十步执行的人是同一个人，做完第一步后就得等到第九步执行完成后再去做。

下图是某个银行的客户为了切换演练打印出来的表格，负责人通过表格指引切换操作和记录。

2）事前准备的高效方式：预案

我们在客户那里部署了嘉为lanjing的灾备切换自动化SaaS，本次不会详细介绍SaaS的使用方法，只会阐述这个SaaS在灾备切换时如何发挥作用。

首先SaaS通过跨业务调度的自动化能力，在主系统和灾备系统之间实行切换，能够提供指挥大屏，供人员清晰地看到整个灾备演练过程。

拿核心系统的数据库切换举例，把整个过程拆解成20步，每一步是串行还是并行，都可以灵活并排。

我们把一个灾备切换的过程叫做预案，可以把回切编排成一个预案，正向切换也编排成一个预案。

一个预案里面可以有单个应用或多个应用，支持一大批应用做一个整体的编排。因此，用户可以通过预案管理整个切换的所有步骤。

① 判断任务是否成功执行

方案里要明确第一步做完后，下一步要去做什么。

那么如何去判断第一步是否完成呢？

人工模式下可以通过命令、或者直接看执行命令的返回来判断。

在做预案的时候，需要在预案里设定怎么去验证任务是否成功执行，通常可以通过一些脚本、命令去执行这个目的。

② 自动执行下一步

同时，也可以进行人为干预。

比如第一步数据库全部停止并验证完毕，但暂不打算执行下一步，此时可以穿插一个人工执行或自动执行进行打断。

也就是说，并不是判断完成后就直接执行下一步，可以选择性的去暂停。

2. 事中：正式切换

按传统的方式，每个小组按照已经编排好的切换方案逐步去执行对应动作。

所以，在事中阶段不需要进行可行性评估或者方案的审核，只需要去做执行即可。执行分为四个部分：

· 命令执行：命令操作和人工操作都会有所涉及。

· 每项任务执行结果人工验证和上报：需要上报是否完成，并对结果、时间等进行记录

· 多部门人员穿插依次执行任务：可能存在一个人做完自己的第一步的工作之后，第十步又需要做另外一个动作，在这个过程中会有多部门的人员穿插依次执行。

· 切换过程中问题排查处理：在切换过程中如果遇到了问题，需要进行排查。

以上是事中切换的时候执行的事情，整体来看流程比较单一、固定。

既然如此，我们能不能把这个流程自动化呢？

1）典型场景——流程灵活编排

案例中的客户采用了我们嘉为lanjing的灾备切换自动化SaaS，把每个切换步骤全部做了原子化拆解。

原子化拆解，简单来说就是把每个步骤拆解的很细。

拆的很细的好处就是每个环节比较分明，并且每个环节之间的衔接关系可以自由编排。

把其中的一个任务拆解到嘉为lanjing的作业平台中，从而实现原子化的操作。

当步骤被拆解的很细的时候，能够支撑复杂程度更高的操作自动化。

拿核心系统的数据库切换举例，把整个过程拆解成20步，每一步是串行还是并行，都可以灵活并排。

3）典型场景——单步骤标准运维流程2

链条最长的有20步，即把数据库重启这个步骤拆成20步，这样做的好处是能够进行灵活编排。

4）典型场景——长链条切换流程

把拆解的各个步骤灵活组合，比如这里就把6个小步骤组合成第一个大步骤。

在6个小步骤中，第一个小步骤可能就有20步，也可能只有2-3步。

把这些大步骤串在一起后，就形成了完整切换的预案，完成长链条切换流程的编排。

这一个核心系统里，总共涉及到了27步长链条的切换，合并后就是6个大步骤的切换。这27步中的最复杂的一步，就是前面所展示出来的20个原子化的步骤。

5）典型案例——关联系统多且复杂

在这6个大步骤里涉及到的并非单一系统，而是高达10个系统，还会涉及到周边系统的插入。

通常来说，周边系统的插入都是跨业务的，比如实现不同系统之间进行调度，这些在嘉为lanjing灾备切换自动化SaaS的解决方案里可以实现。

6）早期的灾备切换管理软件

在早期，嘉为lanjing还没有研发灾备切换自动化SaaS的时候，市面上也有一些国外的厂商在卖灾备切换自动化的工具。

这些厂商具有一定的先天优势，因为它们在数据还原上有技术积累。

比如下图所展示的，就是早期一家国外厂商做的灾备切换管理软件，它的切换步骤看起来较为扁平化。

扁平化的切换步骤在逻辑性上来说，没有那么强。

因此，若步骤数量过多，负责人员又恰好更换的话，重新学习的难度高，维护成本也相应增高。

同时，界面的操作的语言大多为英语，对于多数企业来说体验感稍差。

3. 事后：切换验证及收尾

切换的最后一个环节，就是做切换验证及收尾。

切换完成后，整个技术切换动作也完成了，此时需要让业务真正的投入使用之前，要对切换结果进行检查。

其中，包括数据的一致性、可控完整性、系统的可用性等，这些都由测试人员去检查。

检查完毕后，由灾备负责人再向上进行汇报，并通知业务部门或营业部发通告，宣布切换完成，业务可以正常使用了。

1）典型场景——切换步骤可追溯

通过嘉为lanjing灾备切换自动化SaaS，我们可以追溯切换的状态，即结果是成功还是失败。

同时，每个环节的日志都是可查询的，方便对每个环节进行定位。

2）典型场景——可视化展示

可视化的展示能够直观的展现切换过程消耗的时间，如果在切换过程中发生问题，大步骤的状态就会变红，提示现场人员进行人工干预。

由于原子化拆解出来的步骤较细，因此在出现错误时，能够很明确的定位到问题，从而快速解决。

我们可以看到上图中显示的切换时间是43分钟，而若按照传统人工方式去切换，根据以往切换工作的统计大约需要3个小时。

因此，可见采用自动化灾备演练切换系统能够极大地提高切换效率，也能避免人工操作带来的失误。

三、嘉为lanjing灾备切换自动化SaaS

1. 嘉为lanjing灾备切换自动化SaaS的定位

嘉为lanjing灾备切换自动化SaaS的定位是灾备切换及恢复的预案管理和操作自动化。

主要是做切换的预案管理，也会涉及到回切预案管理，这两者其实是相互的，即互为主备两个系统的切换。

对整个灾备系统建设来说，由于各个系统差异性较高，如果在系统建设这块做统一的管理工具，其可行性和成本都很高。

我们建设灾备系统时，如果要用统一的工具建设，肯定每一套都是单独定制，因此不存在复用性，所以要把关注点放在切换环节，去解决切换难的问题。

嘉为lanjing灾备切换自动化SaaS的管理理念是将步骤拆分进行原子化，方便编排，也方便在遇到问题时能够快速定位。

除了一些物理的动作比如网线拔插、主机搬运等外，其他软件层面的动作都可以通过SaaS来实现。

其特点是基于IT对象长链条、复杂的场景实现灵活编排。

3. 嘉为lanjing灾备切换自动化SaaS的优势

· 灵活配置的切换流程引擎

· 可视化的切换过程管理

· 兼容手工操作步骤和审批环节

· 可追溯、可审计

四、对灾备的思考

1. 灾备切换是一种复杂的运维管理场景

嘉为lanjing灾备切换自动化SaaS主要在操作层面将对人难的操作自动化，从而提升灾备切换的效率和准确率。

2. 没有完美的灾备切换系统

灾备切换系统既有灾备中心，也有数据中心，需要对数据进行复制。

数据复制要遵循计算的CAP理论，即一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）。

在实际情况中这三点不能同时满足，需要做一定的取舍。

精选互动问答

问:随着资源和架构的变化，如何保障切换流程和检查的准确性，后续随时可以作为应急预案？

答: 在使用了灾备切换自动化SaaS之后，组织资源和架构的变化对切换流程的影响已经大大降低。

相较表格和人工制定计划的方式，固化后的预案知识传递的准确度更高，当然切换前对预案进行复核的动作也是必要的。

问:如何保证预案随应用变化而变化呢？

答: 在灾备系统自身的变化的场景中，保障灾备切换预案可用的最佳方式是将预案的更新加入到应用变更的流程中。

可以是自动化的方式也可以是手动的方式，在应用变更时加入预案更新的判断，通过企业内的流程管理系统自动更新预案的配置参数。

问:后续变化的管控，是否有实践案例呢？

答: 目前已经建设的客户中，仍是主要采用人工更新的方式对预案进行维护，季度周期性的review是否需要更新。部分场景比如更换IP的自动化更新的方式可通过定制开发实现，不过场景的多样性决定了目前手动为主。管控手段是作为定期工作任务添加到工作内容要求和流程中。