应急预案演练究竟是流于形式还是有具体针对性？

参与过一次核心系统的灾备中心切换演练，时间是凌晨，交易量比较小的时候，同时也找了几个业务在演练的时候做一些交易来验证。演练的目的主要还是练兵，以及验证切换脚本、应计预案，并非只是应付。收起

演练和实际故障处置，是有差异的，演练的时候都是万事俱备，实际故障一定有很多资源缺失收起

我们目前做法是实际核心系统一年两次灾备，外围系统一年一次灾备
模拟故障方法每次都会有区别，比如使用宕机、数据库stop的方式  
其实灾备这东西就是敢不敢做以及对基础架构厂商的依赖程度问题
“越不做越不敢做"  。
所以主要看自己对自身技术架构、灾备方案的熟悉程度，同时也受下面两个条件制约：
1.内部开发与运维的关系
2.对厂商的依赖度收起

这就要看各单位的要求了，灾备演练是自己的事情，真的出了问题，那就只有自己扛着了。目前监管机构在演练检查方面越来越严格，非常专业。通常都会要求进行带生产的切换，涉及服务器，存储，网络，应用等多个方面。收起

应急预案演练是部分典型场景的模拟，有一定的理想化、意想化和应付内外监管机构的成份，所以仅仅靠这个是远远不够的。在实际应急故障发生时，要想获得有效、高效的应急效果，取决于两个“功在平时、利在一时”的要素：1、所有的设备配置符合厂商规范和业内最佳实践，并且能够持续优化，确保设备本身能够稳定、持续运行；2、一旦故障发生，人就是最关键的因素，必须有一批“技术扎实、技术全面、理解业务流向、理解管理流程”的高手，快速定位、恢复业务、定位故障、事后完善。收起

不过话又说回来，银行数据容不得一点疏忽，真有点事，谁也担不起那个责任。演练真是一个矛盾体！这个度的把握您有啥建议？收起

我个人觉得应急演练就应该具有一定的破坏性，但现在的演练大多数都是业务停止后，手动切换一下，感觉灾备就是为了应付监管制度砸钱。收起