如果你遇到了某个重大的运维问题，采取什么样的措施才是正确的呢？搞清楚这一点相当重要，如果出现策略选择错误，那很可能会丢饭碗的。前几天和一个经历过十年前一次十分著名的大故障的DBA聊天，最后难免会问到那次事故。我十分喜欢听别人谈教训而不是谈经验，因为成功的经验往往大同小异，唯有教训才是金钱也买不来的。虽然回顾惨痛的教训对于当事者而言有些残酷，不过这种回顾往往是价值的提炼。
他回顾完这个事件后说，当时我们的最大错误决策是按照厂家的建议去停了那个第三方复制设备，其实在这种业务高峰叠加设备性能故障的场景中，很多因素是不确定的，对于第三方设备的特性我们也是知之甚少，当时不应该做这种操作，而是应该先通过业务限流的方式让系统能维持运行，等营业厅下班后，非业务高峰期再去做高风险的动作。如果那样，那次事故可能能避免了。
他谈到的这个问题就是我今天要谈的第一条原则，在各种处置策略中，先选择最为简单的，风险小的处置策略；在承担的责任中，要选择责任小的责任来承担，比如说系统运行性能虽然大幅下降，但是还在业务能忍受范围内，并无恶化迹象的时候，我们可以选择承担这次性能故障的责任。如果我们不想承担这个责任，非要在短时间内解决问题，那么也要尽可能在自身能力范围内去做优化调整。如果当时的故障已经超出了自身的能力范围，那么宁可承担这个小一点的责任也不要冒险去犯错误，从而承担更大的责任。
在实际工作中，能够想明白这一点，并按照上面的原则去做并不容易，我们在实际工作中看到的往往是一些更小的运维故障因为处置不当而导致超级大故障的案例。比如说Oracle RAC有一个节点故障宕机了，这时候我们应该做什么操作呢？大多数朋友可能会选择重新启动一下，也有些朋友会选择观望，什么都不做。
实际上，如果是一些负载较高的核心业务系统，那么我们应该首先检查活着的节点的日志，看看是否存在异常，是否存在也宕机的风险。然后去观察活着节点的活跃会话数、会话数、负载、等待事件等，看看有没有风险。如果存在风险，先通过杀会话把系统稳定住。等一切稳定后，才去分析宕机的原因，并判断重启故障实例的风险。
如果你无法判断风险，而当时正好是业务高峰，那么你可以选择暂时不重启故障节点，等业务高峰过去后再去处理。最为忌讳的是，RAC故障切换后不久，业务还没有稳定之前就去重启故障节点。采取这种做法的惨痛案例比比皆是。
第二个原则是不要以为一切都在你的掌握之中，作为DBA ,数据中心里你不了解的东西太多了，因此考虑问题的时候必须要留有余地。不要选择看似最佳的解决方案。
大概是十五年前吧，某企业的数据中心经历了一次机房双路停电的事故。虽然数据中心是两路供电的，但是供电公司的两路电同时故障。这种故障是因为数据中心建设时选择双路供电时为了省钱导致的，虽然两路电来自于两个220KV变电站，但是上位变电站是同一个，上位站故障两路电就都没了，而且供电公司无法给出明确的修复时间。
在应对这个问题的时候，我和他们的IT主管通电话讨论策略，我的策略是先把核心业务系统和存储都停了，外围系统先跑着。我的理由是适逢盛夏，如果三四个小时不来电，UPS虽然能撑得住，但是机房温度会过高，把核心系统停了，也就是几个小时的停机。但是IT主管不同意这个方案，他认为如果把外围系统都停了，八个小时内能恢复供电，他的UPS也都撑得住，保住了核心系统，那就是大功一件。对于机房温度的事情，他立即找到了制冰公司，让他们送冰块到机房降温。
最后的结局机房温湿度超标导致核心存储系统自动保护，有损自动关机。核心系统数据库出现大量坏块，ADG备机存储同样故障，磁带库磁带损坏，无法恢复。最后我们通过BBED帮他忙强行拉起了数据库，把数据导出后重新建库、补充丢失数据。核心系统2天后才恢复对内服务，一星期后才恢复对外提供查单业务，给企业声誉造成了很大的影响。
在一些特别严重的运维故障发生时，以自己的能力范围来选择采取的措施，先考虑那些风险与危害较小，自己比较擅长的方式去处置，是DBA保命的重要原则。这种事故一旦变成大故障，肯定是要有人出来担责的，DBA是最好的替罪羊。
