敬请阅读《云原生灾备体系规划与建设实践（上篇）》......
参考国标及金融行标，并结合金融行业实践，建议灾备的总体规划为“需求、规划、实施、运营”四大部分内容（或者四个阶段）为最佳，有客户建议增加设计部分，也有客户将设计部分合并到规划，或者将设计部分合并到实施，我个人认为前者比较合适，从多年规划咨询经验来看，绝大部分客户更加期望于“规划”具备落地性、规划内容能够落地，从这个角度来看，如果规划中不包括设计内容，规划是无法落地的。职业生涯中，非常赞同不落地的规划咨询就是耍流氓的俗语，但由于历史上不能落地的规划太多，以至于在众多金融机构中，规划工作被独立立项会非常困难，规划的价值被大打折扣，谁说不是呢？
通常，灾备的总体规划会形成灾备建设蓝图，如下：
云原生灾备蓝图中，需考虑对云上、云下、多云、异构云间的数据同步支持，灾备切换时的联动等关键要素。
以下将按照灾备的总体规划，分别从“需求”、“规划”、“实施”、“运营”等四大部分内容进行讲述......
灾备需求来源于业务连续性中业务影响分析（BIA）结果的输入，但在大多数金融机构中，业务影响分析做的并不到位（其它行业情况会更差），导致业务连续性管理与信息系统灾备管理脱节。
从上图可以看到，灾备管理是在业务连续性管理之下，IT备份恢复发展到灾难恢复规划（DRP），主要增加了灾难恢复预案、IT资源需求、灾备中心管理等工作，形成了对IT数据中心的全面保障；BCP是将灾难恢复从IT视角转向业务视角，用业务来衡量灾备目标的能力实现，增加了业务影响分析、业务恢复预案、人员与通信保障等；BCM则是面向业务基础上，并考虑组织整体的紧急事件响应、危机公关和供应链危机管理等，在金融行业的业务连续性管理，包括了人员、业务场地、业务票据、业务办公设备、外部供应商、信息系统等六大方面，通常称为业务连续性管理六要素，所以信息系统连续性管理只是业务连续性管理其中一部分，同时信息系统灾备管理又是信息系统连续性管理的一部分。
以银行为例，BCM相关工作一般由风险管理部负责，关注银行整体的业务连续性，IT部门的信息系统连续性是业务连续性的六大关键要素之一，IT部门完成信息系统灾备建设是保障信息系统连续性的重要工作内容，IT部门的灾备管理如何与业务连续性管理联动、灾备建设如何支持业务连续性建设，是考验IT部门的重大课题。
BIA工作是业务连续性管理范畴，是IT部门灾备建设的输入，是IT部门灾备需求的重要来源，正常情况下，BIA的结果会形成重要业务列表、关键业务列表、一般业务列表，同时形成业务之间的关系列表（即关联关系及依赖）、业务与信息系统的关系列表、以及每项业务的RPO与RTO，并通过进一步的分析，形成包括信息系统RPO与RTO的灾备建设需求。
BIA是一项难度大、复杂度高、耗时长的关键性工作，关于如何开展该项工作，如果金融机构自己不具备相关能力，则需要开展专项咨询项目，需要专项资金支持。在外部业务交流时，曾被多次问过BIA的方法与模型，甚至提出能否提供BIA的指标列表与算法，其实每个金融机构的实际情况都不一样，要想得到切实可行的BIA指标和算法，都需要经过一个较长的时间去验证、讨论、汇报和决策、同时需要通过试点应用验证，并不是通过简单获取就能形成切实可行的BIA结果和灾备建设需求。这个情况让我想起了魔术，通常情况下，大家都认为魔术是一种娱乐、也是一项技能，都也想学几手，但魔术的背后是知识产权、是不断的创新和勤学苦练，如果花费了大量精力发明的魔术，被随便公开揭秘，谁又愿意去创新魔术呢？即使看到了揭秘，不花费大量的时间练习也不可能达到精彩的表演效果。所以，想要得到适合自身的BIA结果，并能有效的落地实施，则必须要有一个严格的BIA过程。
灾备需求的形成：
通过业务与信息系统的关联关系，完成对信息系统的分类与灾备定级，同时通过信息系统支撑业务的RPO与RTO，形成自身灾备建设的RPO与RTO，信息系统获取RPO与RTO及灾备定级等信息后，即可以完成信息系统的灾备建设需求。
1、灾备建设策略规划
灾备策略规划的重要输入是灾备建设需求。上文讲述了灾备建设需求获取，但往往事与愿违，灾备建设部门面对过时的BIA结果、或者无法落地的BIA结果，结论是根本拿不到切实的灾备建设需求，在大部分金融机构中，灾备建设往往是受等保例行检查、金融监管审计等因素驱动，所以应用系统分类，基础平台及应用系统的灾备定级都不明确，RTO和RPO是科技部门自行定义的结果，这些现实情况会给灾备策略的规划带来困难，往往是需要比较长时间的反复讨论，甚至几个月才能确定灾备策略。
如果没有明确的灾备建设需求输入，那么就需要制定几项“关键假设”，依靠对关键假设的逐步讨论、汇报、决策，逐步统一思想，获得最终的灾备建设需求。
通过灾备建设需求，最终完成灾备策略的规划，内容包括但不限于：
（1）几地几中心：涉及哪些机房，机房定位，只有这些确定了，才能明确灾备的网络架构、网络带宽、机房对应用的承载、机房规模；
（2）灾备模式：包括多活、双活、应用容灾、数据容灾的哪些类别？应用双活模式是应用双活数据单边、还是应用数据同时双活；
（3）建设范围：各种灾备模式的建设范围，应用系统的分类与灾备定级，另外包括IaaS、CaaS、PaaS等基础平台；
（4）建设目标：各种灾备模式的RTO、RPO、灾备目标定义；
（5）灾备技术：各种灾备模式下使用的技术，如多云间、异构云间、云上云下等场景下数据同步技术、以及灾备相关工具等；
（6）灾备管理：组织架构，灾备制度、灾备流程、应急预案、灾备演练等管理体系架构。
2、灾备分层规划思路
分层一直是IT行业中将复杂问题简化的重要手段，也是IT行业架构规划中常用的方法。从C/S架构进化到B/S架构的Java应用，为简化实现推出了MVC分层架构，当前基础资源云架构到应用分布式云原生架构，变得更加复杂，所以更加需要使用分层规划，以增强落地性和实用性。
在云计算技术架构、分布式系统参考架构等标准中，也都分别使用了分层方法，所以在灾备规划中，非常推荐使用分层思想来开展规划。
传统架构下的灾备建设，基本上是面向应用系统进行考虑，考虑因素可以简单理解为应用系统相关数据如何在两中心间同步，基于应用系统的灾备分层规划，可以简单的按照网络、计算、存储等分层规划。
云原生架构下的灾备变的越来越复杂，首先基础资源进行了池化，池化资源时需同时考虑虚拟化和容器两大技术路线，另外云原生架构下的应用需依赖由若干技术组件组成的PaaS平台，虽然受云计算及互联网企业的影响，将DB（数据库）归类到PaaS平台中，但这些归类是源于公有云的框架，在金融机构中的DB绝大多数还是直接部署在物理机或IaaS中，所以在云原生架构下的灾备规划，DB通常以独立的层次考虑。应用系统部署受上云技术路线影响，各技术路线下的部署架构也包括多种类型，所以灾备模式会不尽相同，在规划时也需要以独立的层次考虑。另外，云原生架构下的网络灾备更加复杂，不仅包括IaaS、CaaS中的虚拟局域网，还包括机房与机房之间互联的物理网。
云原生架构下的灾备需同步考虑多云、多技术路线下的灾备情况，同时叠加了异构云下的多种部署模式，云原生灾备的分层需要更加细致，在每一层中需要同时考虑各种情况。
敬请阅读《云原生灾备体系规划与建设实践（下篇）》......
关注本号，获取更多金融行业运维管理原创文章