紧耦合系统的灾备自动化切换如何演练？

同城演练时，对于紧耦合的系统，如果同城网络大二层打通状态，可以分别切换，无需考虑耦合；如果主备机房网络隔离，则必须将紧耦合的系统放在一起进行切换演练，逻辑上作为一个系统。
我们没有对每一套系统分别建设灾备演练的测试环境，过于浪费！只是针对灾备系统使用的技术搭建了AIX集群、HP集群、Linux集群、分别使用SWAP、STAR存储技术以及Oracle、DB2、MySQL等数据库，F5应用集群、使用DNS的服务IP，大约不超过20台物理机+虚拟机完全能覆盖所有灾备技术。这些IT组件的自动化脚本是通用和参数化的，由参数驱动，参数的来源是灾备平台。灾备流程将每套系统每个IT组件和应用的参数从灾备平台中取出来，传递给自动化脚本，下发到目标主机去执行。无论多少套灾备系统，脚本都是同一套，所以无需搭建每一套灾备系统的测试环境。

至于说一起切换时的启停顺序和依赖问题，我在另一个问题中刚刚做了答复，转帖过来：
业务的依赖性，不建议在灾备流程中实现，建议在应用设计中考虑，最好不要深度耦合，尽量采用重试机制来进行探测和重连。
举个简单例子吧，安保系统，对银行其他系统来说非常重要，大多需要依赖，尤其是渠道类如柜面、手机银行、网银等系统。
如果同时进行切换，可能渠道类系统先进入到应用启动的步骤，这时就需要应用端进行探测和等待，直到安保系统完成启动之后，渠道类探测到操作完成，连接到可用的安保平台。
在灾备自动化流程中实现前置和关联检查会造成流程复杂度大大增加，不利于今后的变更和灾备演练。灾备自动化最多依据安保提供的连通性判断脚本或者RESTful接口进行判断，一待完成判断后，立即继续执行渠道类系统的后续操作。
与之相类似，更简单的一种场景就是NFS，当server如果来自另一个系统，尚未完成启动，则nfs client会处于重试状态，NFS server not responding, still trying，会一直重试，直到server和NFS文件系统准备好，之后client端完成NFS挂载，继续执行后续步骤。这应该就是各强关联和强依赖业务系统必须改造，改造后要达到的效果。

对于紧耦合的业务系统一般切换的时候都是按照一个整体一起切换的，尤其是有大量业务数据交互、延迟敏感的业务系统，及时是二层通延时也会成倍增加。不可能针对每一个业务系统都搭建一个测试环境。为了测试容灾切换平台，可以建立一个标准的测试环境，一般就是启动、停止、检查等标准的任务或命令，可以完成一些基本的测试。