咱们一同窗学遇到严重运维疑问时的保命准则

假设你遇到了某个严重的运维疑问，采取什么样的措施才是正确的呢？搞分明这一点相当关键，假设出现战略选用失误，那很或许会丢饭碗的。前几天和一个阅历过十年前一次性十分驰名的大缺点的DBA聊天，最后不免会问到那次意外。我十分青睐听他人谈经验而不是谈阅历，由于成功的阅历往往迥然不同，唯有经验才是金钱也买不来的。只管回忆惨痛的经验关于当事者而言有些严酷，不过这种回忆往往是价值的提炼。

他回忆完这个事情后说，过后咱们的最大失误决策是依照厂家的倡导去停了那个第三方复制设施，其真实这种业务高峰叠加设施性能缺点的场景中，很多要素是不确定的，关于第三方设施的特性咱们也是知之甚少，过后不应该做这种操作，而是应该先经过业务限流的模式让系统能维持运转，等营业厅任务后，非业务高峰期再去做高危险的举措。假设那样，那次意外或许能防止了。

他谈到的这个疑问就是我当天要谈的第一条准则，在各种处置战略中，先选用最为便捷的，危险小的处置战略；在承当的责任中，要选用责任小的责任来承当，比如说系统运转性能只管大幅降低，然而还在业务能忍受范围内，并无好转迹象的时刻，咱们可以选用承当这次性能缺点的责任。假设咱们不想承当这个责任，非要在短期间内处置疑问，那么也要尽或许在自身才干范围内去做提升调整。假设过后的缺点曾经超出了自身的才干范围，那么宁肯承当这个小一点的责任也不要冒险去犯失误，从而承当更大的责任。

在实践任务中，能够想明白这一点，并依照下面的准则去做并不容易，咱们在实践任务中看到的往往是一些更小的运维缺点由于处置不当而造成超级大缺点的案例。比如说Oracle RAC有一个节点缺点宕机了，这时刻咱们应该做什么操作呢？大少数好友或许会选用从新启动一下，也有些好友会选用张望，什么都不做。

实践上，假设是一些负载较高的中心业务系统，那么咱们应该首先审核活着的节点的日志，看看能否存在意外，能否存在也宕机的危险。而后去观察活着节点的生动会话数、会话数、负载、期待事情等，看看有没有危险。假设存在危险，先经过杀会话把系统稳固住。等一切稳固后，才去剖析宕机的要素，并判别重启缺点实例的危险。

假设你不可判别危险，而过后正好是业务高峰，那么你可以选用临时不重启缺点节点，等业务高峰过去后再去处置。最为禁忌的是，RAC缺点切换后不久，业务还没有稳固之前就去重启缺点节点。采取这种做法的惨痛案例亘古未有。

第二个准则是不要以为一切都在你的把握之中，作为DBA ,数据中心里你不了解的物品太多了，因此思考疑问的时刻必要求留缺乏地。不要选用看似最佳的处置打算。

大略是十五年前吧，某企业的数据中心阅历了一次性机房双路停电的意外。只管数据中心是两路供电的，然而供电公司的两路电同时缺点。这种缺点是由于数据中心树立时选用双路供电时为了省钱造成的，只管两路电来自于两个220KV变电站，然而上位变电站是同一个，上位站缺点两路电就都没了，而且供电公司不可给出明白的修复期间。

在应答这个疑问的时刻，我和他们的IT主管通电话探讨战略，我的战略是先把中心业务系统和存储都停了，中心系统先跑着。我的理由是适逢隆冬，假设三四个小时不联络，UPS只管能撑得住，然而机房温度会过高，把中心系统停了，也就是几个小时的停机。然而IT主管不赞同这个打算，他以为假设把中心系统都停了，八个小时内能复原供电，他的UPS也都撑得住，保住了中心系统，那就是大功一件。关于机房温度的事情，他立刻找到了制冰公司，让他们送冰块到机房降温。

最后的终局机房温湿度超标造成中心存储系统智能包全，有损智能关机。中心系统数据库出现少量坏块，ADG备机存储雷同缺点，磁带库磁带损坏，不可复原。最后咱们经过BBED帮他忙强行拉起了数据库，把数据导出后从新建库、补充失落数据。中心系统2天后才复原对外敷务，一星期后才复原对外提供查单业务，给企业声誉形成了很大的影响。

在一些特意严重的运维缺点出现时，以自己的才干范围来选用采取的措施，先思考那些危险与危害较小，自己比拟长于的模式去处置，是DBA保命的关键准则。这种意外一旦变成大缺点，必需是要有人进去担责的，DBA是最好的替罪羊。