平台或系统的容灾方案，该如何考量和设计？
日常生活当中，我们经常会接触到因平台系统故障服务无法正常访问的情况。在过去的一年，很多头部游戏、生活服务类产品接连爆出宕机事故，因为涉及面广、影响范围大，产生了很多“名场面”，在网络上也是被频繁的讨论。
产品经理在规划系统和设计容灾方案时，需要从数据安全、业务稳定、经济可行等角度出发，考量各种故障场景，明确产品或系统应保持的容灾级别或范围，通过架构升级、建立容灾响应机制等手段，保证在发生意外故障后，业务系统仍能不间断地运行。
本文也是结合自身工作当中接触到的的一些云平台容灾经历，做了部分归纳整理，供相互学习和交流。
一、常见的故障场景
一般平台产品故障场景主要包括单产品故障、服务器断电或断网和硬件故障场景。当然也存在一些其他的原因，像编码的逻辑问题或漏洞、用户的运行环境和生产环境功能不一致等问题，这类情形一般是流程管控上的瑕疵，通过加强制度审查，是能规避掉大部分潜在风险的。
1. 单产品故障
单产品故障是指组成我们业务平台的某一项产品服务发生了管控故障，不能正常履行既定职能，导致服务中断的情况，故障主要包括以下场景：
- 产品部署的资源夯死，数据读写异常；
- 未知问题产生的进程阻断；
- 产品所在的容器异常；
- 服务器宕机，无法访问。
2. 断电断网
断电场景主要是指支撑业务平台的服务器机房整体断电了或部分机柜断电了，从而导致的异常。
断网场景则是因为平台上行链路和数据中心出口设备故障产生了异常。
3. 硬件故障
核心设备硬件损伤后无法恢复引起的故障。
二、明确容灾级别或范围
在规划产品或系统容灾方案过程中，首先要明确自身的具体需求，是要保障核心服务还是要保障所有服务，当故障发生后需要在多长时间内响应和处理问题，诸如此类的问题都要好好考虑清楚。
1. 容灾级别
从容灾保障对象层面来看，容灾大致分为两个级别：平台级容灾和业务级容灾。平台级容灾仅实现核心的数据备份、核心服务的双活或主备，不涉及全量的业务应用。而业务级容灾则是在平台级容灾的基础上，根据业务系统的容灾需求，从业务系统网络层、应用层、数据库层等构建跨站点集群，以实现网络双活、应用双活、数据主从。
2. 主备和双活
定义好容灾级别后，就要考虑具体的容灾形式。通常情况下可以考虑两种容灾方式，双活模式和主备模式。
- 主备模式是依托两套环境，一套为主环境，另一套作为备用环境。正常情况下由主环境系统提供服务，另一个环境系统不承担任何流量，数据在主备之间同步复制。只有在主环境生产系统瘫痪，备用环境系统才会切换启用。
- 双活模式同样也是两套环境的业务系统，和主备不同的是两个环境会同时处于运行当中，类似于负载均衡，流量指向可通过工具控制，数据同步也是实时的，所以也就无所谓谁是主、谁是备了。
以上提到的容灾级别和容灾形式是做容灾方案规划设计时需要去考虑的，当然所有落地的方案都要基于实际去考量，不过度规划，合适的才是最好的。
三、建立容灾响应机制
在明确实施路径后，还应在制定应急响应计划，其中有几个关键因素需要特别注意。
首先，确定合理且完整的演练方案和应急响应流程。制定的计划中要明确每个人的任务和职责，充分培训和训练演练的参与人员，使其能够熟练掌握操作技能和相关知识。
其次，应建立健全的沟通机制和协调机构，确保各个环节的信息和指令能够及时传达和执行。
1. 容灾演练
容灾演练是为了最大程度降低因故障引起的影响，确保产品或系统可持续提供对外服务，持续不断的去完善故障恢复应急保障机制，检验故障发生后的快速恢复效果，提升运维人员的应急处置能力，验证容灾处理重大问题的能力，夯实产品或系统的运行基础。
- 验证故障恢复处置能力，包括故障发现、故障处置、故障恢复等；
- 熟悉故障发生时的应急操作，锻炼运维团队应急能力；
- 根据容灾演练结果，逐步沉淀形成故障应急预案指导手册，形成标准化的应急处置流程。
2. 容灾演练流程
容灾演练流程主要包括演练切换阶段、演练回切阶段和演练总结阶段。演练切换阶段包括演练准备与环境检查、模拟故障、容灾切换和结果验证；演练回切阶段主要包括故障恢复、检查恢复结果、容灾切换（回切）和结果验证等；演练总结阶段包括演练问题消缺、容灾方案完善、演练数据整理和产品消缺等工作。
最后
在规划设计容灾方案的时候，一定要考虑清楚想要的是什么，结合业务的具体需要，并不是越高大上越好。选定方案要综合考虑到成本、架构、业务诉求等诸多方面，选择更合适、更有性价比的方案，容灾是手段，系统稳定运行是目的。
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
