灾备系统建设，运维与保障的一些思考
核心观点：以战略，全局的眼光来建设灾备系统；以运动，发展的思想来维护灾备系统；以制度流程，测试演练来保障灾备系统效
能。
对灾备系统的建设，不管是从行业监管的要求，还是从各机构自身业务安全的角度出发，大家都是不吝于花费大把银子的。现
实情况是灾备系统很多时候没有起到预期的效果，或是不能实现建设时的业务目标，或是在实际切换过程中出现这样那样的问题。
因此如何建设和运维好灾备系统，确保灾备系统可用，可靠是我们一直都在思考的事情。
灾备系统如何建设首先需要拿到公司战略层面来考量，说白了还是人和资源的问题；然后要从业务全局上进行分析，审慎决策
各灾备中心的业务涵盖面与分布策略，制定明确的灾备业务目标，界定好灾备责任的业务边界，灾备处置的各个条线的职责。灾备
系统解决的是业务的活，需要技术来支撑，技术上的全局通盘考虑是根本，个人认为简单实用是最重要的，要做到快，准，狠确实
是不容易，而且灾备系统的建设涉及到的技术层面实在是太多，整个灾备中心涉及到许多的子系统，每个子系统涉及到的网络，存
储，主机，操作系统，数据库，中间件，应用都要考虑到整体解决方案里。
这里有一个难点是软件范畴的单点故障，以应用来举例，不管有多少的运营中心，同构的应用系统软件故障可能导致系统整体
问题。因此，对核心或重要的应用系统而言，可能还要考虑应用异构容灾。这可能倒逼我们对整体解决方案进行一定规模的调整。
就维护工作而言，我觉得应该坚持一个运动与发展的思想，并且要在公司整体上要有这种思想。灾备系统的建设不是一锤子交
易，业务本身是不断发展变化的，系统本身是处在不断的升级更新过程中，灾备系统也是在不断的运动当中，不管灾备系统是什么
模式，当下的系统变更需要同步考虑变更灾备系统，并确保变更后的可靠性，同时对业务发展的前瞻性考虑也应激发对灾备系统未
来可能调整的考虑与设计。实际运维中可能会用到一些自动化平台，全面所述的变更还需要同时变更自动化流程的设计以及相应的
功能单元执行内容。一个运动的人需要集中注意力才能避免摔倒，一个运动的系统也需要你时刻把目光聚焦给它。
灾备系统建起来了，如何保障可靠性，在关键时候能顶的上？在真正需要决策的时候，可以很明确且信心十足的告诉领导“可
以切，没问题”。这真是一个沉重的话题。除了多操练以外办法真的不多。当然前提是要有明确的制度与责任落实，要执行严密，
细致，明确的操作流程。实战演练，沙盘推演... 各种方式如何搭配见仁见智，相信大家也经常的折腾，落下过一地的汗水。
这里主要提了我的一些感触，不一定正确，有好多方面也没有提及，算是抛块砖，希望能学习到宝贵的意见。
能。
对灾备系统的建设，不管是从行业监管的要求，还是从各机构自身业务安全的角度出发，大家都是不吝于花费大把银子的。现
实情况是灾备系统很多时候没有起到预期的效果，或是不能实现建设时的业务目标，或是在实际切换过程中出现这样那样的问题。
因此如何建设和运维好灾备系统，确保灾备系统可用，可靠是我们一直都在思考的事情。
灾备系统如何建设首先需要拿到公司战略层面来考量，说白了还是人和资源的问题；然后要从业务全局上进行分析，审慎决策
各灾备中心的业务涵盖面与分布策略，制定明确的灾备业务目标，界定好灾备责任的业务边界，灾备处置的各个条线的职责。灾备
系统解决的是业务的活，需要技术来支撑，技术上的全局通盘考虑是根本，个人认为简单实用是最重要的，要做到快，准，狠确实
是不容易，而且灾备系统的建设涉及到的技术层面实在是太多，整个灾备中心涉及到许多的子系统，每个子系统涉及到的网络，存
储，主机，操作系统，数据库，中间件，应用都要考虑到整体解决方案里。
这里有一个难点是软件范畴的单点故障，以应用来举例，不管有多少的运营中心，同构的应用系统软件故障可能导致系统整体
问题。因此，对核心或重要的应用系统而言，可能还要考虑应用异构容灾。这可能倒逼我们对整体解决方案进行一定规模的调整。
就维护工作而言，我觉得应该坚持一个运动与发展的思想，并且要在公司整体上要有这种思想。灾备系统的建设不是一锤子交
易，业务本身是不断发展变化的，系统本身是处在不断的升级更新过程中，灾备系统也是在不断的运动当中，不管灾备系统是什么
模式，当下的系统变更需要同步考虑变更灾备系统，并确保变更后的可靠性，同时对业务发展的前瞻性考虑也应激发对灾备系统未
来可能调整的考虑与设计。实际运维中可能会用到一些自动化平台，全面所述的变更还需要同时变更自动化流程的设计以及相应的
功能单元执行内容。一个运动的人需要集中注意力才能避免摔倒，一个运动的系统也需要你时刻把目光聚焦给它。
灾备系统建起来了，如何保障可靠性，在关键时候能顶的上？在真正需要决策的时候，可以很明确且信心十足的告诉领导“可
以切，没问题”。这真是一个沉重的话题。除了多操练以外办法真的不多。当然前提是要有明确的制度与责任落实，要执行严密，
细致，明确的操作流程。实战演练，沙盘推演... 各种方式如何搭配见仁见智，相信大家也经常的折腾，落下过一地的汗水。
这里主要提了我的一些感触，不一定正确，有好多方面也没有提及，算是抛块砖，希望能学习到宝贵的意见。
0同行回答
“答”则兼济天下，请您为题主分忧！
主持人好，大家好，很高兴可以就这个话题进行互动。
谈到“应用异构冗灾”，我们要先谈一个“软单点故障”的话题。
我们以为，若系统内某个层面（网络、系统结构各环节）使用同样的”软件“（设备、程序代码等），则该系统在该层面存在单点，区别于硬件物理设备的单点，把这种情况理解为该系统存在”软单点“，软单点“发生故障称为”软单点故障“。
近几年来，金融行业每年都会发生比较严重的技术事故，甚至在金融行业里被公认为技术能力最强、技术投入最大的银行业也是重大技术事故屡次发生。这些发生事故的公司从系统建设、管理规范、资源投入等方面可以说在银行业内都还名列前茅，并且这些事故不是简单的硬件损坏，不是因为没有建设热备、灾备系统、不是人员的误操作、不是业务功能逻辑错误、也不是因为公司没有制定应急预案，这都促使我们进一步思考，究竟是为什么呢？
归类分析这些冗余设计，几乎所有的“无单点故障”设计方案是主、备、灾容灾体系是建立在同源、同构基础上的，都是针对硬件层面、部署层面的，也就是说是“无硬件单点故障”；而对于软件层面的无单点故障设计则没有全面分析和防范，也就是说，虽然是“无硬件单点故障”，但存在着很多有意或无意忽视的“软单点故障”暗礁。而“软单点故障”正是造成前述那么多银行重大技术事故的罪魁祸首。
目前我们也在思考如何解决这类问题的方案。
针对证券行业集中交易体系“软单点故障”大都是比较难处理的问题，研究和制定应对手段不会是一件简单和容易，找到合适的应对手段将会是行业内一项长期的工作，应对手段可以多样化，例如：
1） 从理论上说可以采取主、备、灾使用不同的操作系统，或在“备”中使用多种方式来备
2） 在目前很多公司建设多交易中心的时候，能否实现不同厂商交易系统的互备（或容许损失某些功能特性）。
3） 网上交易软件选择两家或以上不同厂商的系统，同时制定其中一套网上交易系统出问题后客户的通知、引导、下载另一套网上交易软件的整体方案。
此类尝试的解决方案的核心思想是建立异构化的非同源应用系统作为现有“同构、同源”灾备体系的补充用来应对软单点故障，即“异构化容灾”。
当然，目前更多的是探索，希望大家多提想法和意见，谢谢。收起
谈到“应用异构冗灾”，我们要先谈一个“软单点故障”的话题。
我们以为，若系统内某个层面（网络、系统结构各环节）使用同样的”软件“（设备、程序代码等），则该系统在该层面存在单点，区别于硬件物理设备的单点，把这种情况理解为该系统存在”软单点“，软单点“发生故障称为”软单点故障“。
近几年来，金融行业每年都会发生比较严重的技术事故，甚至在金融行业里被公认为技术能力最强、技术投入最大的银行业也是重大技术事故屡次发生。这些发生事故的公司从系统建设、管理规范、资源投入等方面可以说在银行业内都还名列前茅，并且这些事故不是简单的硬件损坏，不是因为没有建设热备、灾备系统、不是人员的误操作、不是业务功能逻辑错误、也不是因为公司没有制定应急预案，这都促使我们进一步思考，究竟是为什么呢？
归类分析这些冗余设计，几乎所有的“无单点故障”设计方案是主、备、灾容灾体系是建立在同源、同构基础上的，都是针对硬件层面、部署层面的，也就是说是“无硬件单点故障”；而对于软件层面的无单点故障设计则没有全面分析和防范，也就是说，虽然是“无硬件单点故障”，但存在着很多有意或无意忽视的“软单点故障”暗礁。而“软单点故障”正是造成前述那么多银行重大技术事故的罪魁祸首。
目前我们也在思考如何解决这类问题的方案。
针对证券行业集中交易体系“软单点故障”大都是比较难处理的问题，研究和制定应对手段不会是一件简单和容易，找到合适的应对手段将会是行业内一项长期的工作，应对手段可以多样化，例如：
1） 从理论上说可以采取主、备、灾使用不同的操作系统，或在“备”中使用多种方式来备
2） 在目前很多公司建设多交易中心的时候，能否实现不同厂商交易系统的互备（或容许损失某些功能特性）。
3） 网上交易软件选择两家或以上不同厂商的系统，同时制定其中一套网上交易系统出问题后客户的通知、引导、下载另一套网上交易软件的整体方案。
此类尝试的解决方案的核心思想是建立异构化的非同源应用系统作为现有“同构、同源”灾备体系的补充用来应对软单点故障，即“异构化容灾”。
当然，目前更多的是探索，希望大家多提想法和意见，谢谢。收起
相信第一感觉！收起
浏览2601