今天睡了个懒觉，凌晨4点电话突然响起来了，一个老客户做同城演练的 时候，数据库服务器很正常切换了，但是一台应用服务器存在问题，在这台服务器上执行sqlplus出现segmentation fault的报错。这个错误是十分头痛的，和很多因素有关。
他们采用的是同城存储复制的灾备方案，数据库安装在复制卷上 ，平时服务器是启动的，只需要停掉复制，Mount复制卷，就可以拉起应用了。而且这种容灾演练每年2次，这台服务器装了二十年了，每年都会被激活。按照他们的说法，这几年操作系统和数据库都没升过级，而且存储专业的同事也说断开复制的时候没有任何异常。
按照这种说法，这个错误就不应该出现才对。不过出了问题，那就说明肯定哪个环节出了问题。他们在发现问题5分钟后拨通了我的电话，几分钟后，我睡眼惺忪地坐在电脑边上的时候，大致了解了问题的大概脉络。
出现这种问题，大致的可能性是：1)OS和Oracle的兼容性问题，如果真的最近没有做过OS/数据库的升级，那么可能性不大;2)环境变量的设置，特别是LD_LIBRARY_PATH等参数，其实TZ、LANG等参数的设置不合理也会遇到一些问题，这些都是必须要检查的，根据电话里的描述，这些他们都检查过了，没有问题;3)文件系统是否MOUNT为READ ONLY了或者MOUNT时候报错了。他们已经检查过了ERRPT，并没有发现问题;4)文件系统存在其他问题，这个他们也认为不大可能;5)内存等服务器硬件存在问题，这个较难定位，有些时候ERRPT会有报错，有些时候甚至看不到报错。
分析这个问题是用dbx/truss/tucs/strace等工具进行诊断。在我们的探讨中，他们尝试了truss，不过显示内容十分复杂，他们看了一下感觉在短时间内分析问题的难度太大，先暂时放弃。
解决这个问题的方法有几个，最为常用的是relink Oracle Client，稍微保险一点的是从OS版本完全一致的地方tar一个客户端过来。我们是通过微信群的语音沟通，这样几个人之间的沟通效率最高。对于relink,大家是比较心动的，我以前遇到过的几个类似案例也都是利用relink解决的。但是在这个环境里，relink一旦失败的后果十分严重，因为错误会被反向复制到生产环境中，一旦失败，生产环境也将失败，因此relink最先被否定。tar一个客户端过来风险较小，不过所需时间较长。
最后还有一个比较快的方案，不过这个方案成功的机会较小。这套环境是一个HA环境，有主备机，按理说主备机的OS版本环境是完全相同的，切换到另外一台服务器上尝试的成功机会并不多。不过在这种情况下，所有可能恢复的可能性都要优先尝试，于是大家决策决定先切备机，如果备机切换不成功，直接回切生产数据中心，哪怕宣布本次演练失败，也不能让产生更严重的后果。
幸运的是，切备机成功了。本次演练成功完成，虽然略微超出了RTO的目标，不过超的并不多。从故障发生，到完成决策的总时间不到20分钟。虽然采用了一个看似比较LOW的方案，也带有一定的运气成分。不过当紧急故障发生时，这个结局是最好的结局了。
案例说不应该成功的方案居然成功了，说明我们所掌握的信息可能存在缺陷，失败的那台服务器的OS有没有打过什么特殊的安全补丁，或者安装过什么软件?虽然当时大家认为没有，但是不经过仔细排查，是不敢全信的。失败的服务器的硬件真的没有任何问题吗?虽然ERRPT没有报错，但是这台二十多年高龄的服务器真的没任何问题吗?没有人敢保证。
紧急故障发生的时候，及时止损是首要考虑的问题，不过很多朋友都会选择较为完美地解决问题，或者说在选择策略的时候忽略了某些方案的风险。一旦意识到风险存在，可能已经悔之晚矣。今早的案例成功的避开了这些坑，可以算是一次比较经典的风险应急。
总结起来，大家可以参考的经验有几条：1)群体决策，今早的所有决策都是三个人共同决策的，期间避开了大量的风险决策;2)对风险的全面评估，对于每个决策，都会周密评估风险，所以排除了风险最大的RELINK操作;3)经验丰富，今早的三个决策者都是十五年以上运维经验的老手，相对来说都比较沉稳，没有任何违反纪律的随意操作，随意操作是应急处置的大患;4)领导充分信任，在这个处置过程中，公司领导只打了一个电话表示关注，了解到正在处置后，领导没有啰嗦，立即挂掉电话。这样大大减少了现场应急人员的压力，也没有浪费时间。
应急处置中，其实有时候不需要很高的技术手段，更重要的是采取合理的处置策略，及时止损是十分关键的。凡是违反了及时止损原则的应急处置，大概率会往最坏的方向发展。