我相信，在日常工作中，dba们都遇到过各类大小事故。很多时候，我们也是在各种事故中不断成长起来的。有的可能是硬件、产品、网络等等我们不可控因素造成，有的时候是人为因素使然。
刚入行的时候，我非常害怕事故，哪怕不是和自己直接相关的，在处理的时候都心脏快速跳动，血压升高。伴随着经验不断丰富，处理过的问题越来越多，终于慢慢组织总结了很多东西。然而很多时候，我遇到过相当数量的同行，在处理完事故之后，反而一身轻松，觉得万事大吉了。现实中一次事故解决之后，可能只是整个事件的刚开始。针对不同类型的事故，处理之后，该怎么应对，我也有一些自己的心得，最终的目的都是避免此类事故再度发生。
类型1：低级错误造成的事故
这一类不仅仅是在新手dba中，哪怕一些老dba仍然有可能发生。去年国庆假期，我收到公司报警系统的通知，一台sql server的数据磁盘空间报警，触发了90%和95%的阈值。那会还在外面，根据以往经验，这是月初结账导致，过了第一周，后面数据增量不会太快，节后返工处理即可。于是就手机ack掉。
谁知节后回到工作中，一下子很多东西都压过来，一时之间竟把这事给忘了，终于在10月的第三周一个下班回家的路上，磁盘写满了。恰好还是部门一把手用相关应用报警先发现，而不是业务们先发现，总算给部门保留了最后一丝颜面。紧急扩容处理之后，第二天来到公司，就被狠狠批了一顿。我曾经一度想编个其他理由去蒙混过关，思量再三，还是和盘托出，这是一个低级错误的事实。那会的部门一把手是个性子很直的人，我又是他非常信任的人，所以在他看来，这件事情实在不该发生。
之后我将公司的报警平台机制做了调整，在监控级别上给自己多上了一把锁。同时与其他dba同事进行了相关讨论，遇到这种95%级别的报警，如果自己不在公司或者短期内不能登录电脑工作，就第一时间在群里找其他dba或者操作系统的sa，紧急做扩容或者清理，处理完成后在群里反馈结果。同时，如果长假，尽量确保组内dba与sa，至少有一个人在当天能够登录系统，哪怕采用轮流值班的方式，确保类似事件不再发生。在工具、流程和人的三个层面做好保险，从而确保类似的事件不再出现。
很多dba，尤其是资深dba，通常在发生低级错误导致事故的时候，内心都多少有些抗拒，往往只是草草处理收场。然而一个经验丰富的dba出现低级错误的时候，恰恰可能就是某个环节出现了问题。和一些冷门问题不同的是，这些某个环节存在问题的场景，很可能在不同的时机再次触发从，可能引起更大的事故造成更多的损失。千万不要得过且过，勇敢诚实面对这些东西，将隐患的环节通过整改，避免下次再度出现才是重中之重。
类型2：因设备自身造成的事故
这一类事故是平时比较多的，尤其一些公司，设备老旧甚至超龄服役多年时，就会经常发生。
几年前的年底财务结算期间，我们负责核心财务系统的exadata出了一次事故。三个存储节点，短时间内坏了两个。确切说，是第一个节点坏了报修之后到原厂工程师上门修复之前的时间段，另一个也故障了。事后oracle原厂工程师说，这事除了倒霉，真没法解释了，他做了多年硬件售后，也没有遇到过不到4小时内连续坏两个的情况。然而这种黑天鹅事件，恰恰就发生了。
然而我们的备用服务器是配置只有生产环境一半的另一台exadata，平时的业务量是可以扛住，但是年底财务结算，业务量是平时数倍的情况时，根本扛不住。更糟糕的是，这台备用服务器之前被我们当做备件库用，生产环境的硬件如果出问题，例如交换机或者主板，我们会优先拔下它上面的硬件给生产环境用。上面的硬件几乎都已经被换了个遍，谁也不敢保证，这台机器上的硬件拆下来能够给主机用，一旦备机也出了问题，就意味着所有热数据都没有了，只能从带库恢复，这中间还有备份和生产的时间差。最后部门一把手和财务一把手开了一晚上的会，拍板决定，尽快抢修生产环境，业务临时中止至第二天早上上班。经过一晚上的抢修，终于恢复了两个存储节点中的一个。数据库得以恢复，而另一个换过主板之后仍然不能修复，只能由更资深的工程师到达现场来检查修复。
前后折腾了半个月，这期间还因为元旦跨年耽搁了几天。两台存储节点都修复之后，我们还惊魂未定。然而对我们来说，整个事故的复盘总结才刚刚开始。这台exadata服役时间已经超过4年，进入了硬件故障开始频出的阶段。而部门一把手愤怒的点在于，这么重要的事情，居然提前没有知会他，等到故障出来了，他才知道这台机器已经服役了这么久，硬件都频繁更换过。这类问题该怎么规避，成为了后来复盘的关键点。
从流程上来说，当第一个节点硬件出了问题后，我们没有立即联系oracle原厂工程师，尽快上门检查，这中间耽误了两小时，如果原厂工程师早些到达，也许第二个故障节点的隐患会被提前发现，从而有准备地停机更换。对于核心财务这种任何公司都是最优先保障的系统，应当第一时间联系售后的负责人，行动越早，耽误的时间就越少。而从运维的角度，我们每年一次的服务器巡检，显然已经不足以应对这台服役快5年的老服务器。事后我们决定，每年多买些原厂人天，除了将例行巡检提高到半年一次的频率，在年结保障期间，由原厂oracle工程师一对一在公司驻场，遇到问题第一时间相应解决。此外，由部门一把手与财务部门开会，讲述硬件问题可能后续带来的风险，并建议业务部门尽早追加预算购买新设备替代。
应对这类事故，我的建议是，不要抱着侥幸心理，任何的硬件设备都是有寿命的。在进入高龄服役阶段，一定要及时向领导反馈。并且胆大向领导提出及时更换硬件的建议。而在事故发生的第一时间，联系原厂售后人员上门。不要抱着自己想办法解决的一根筋想法，即便是售后人员到来之前，你自己解决了，这也是在正常不过的。而他们第一时间收集各类信息和反馈，回到公司提交给相关人员，同样是有价值的。不要在山崩雪崩的时候想着怎么秀肌肉展现自己，而是要动用各种自己想到的资源和途径解决问题。此外，和业务部门建立起快速的沟通渠道，一旦出了问题，第一时间沟通协调，将业务损失降到最低。
类型3：其他人或其他系统造成的事故
之前公司为了节省硬件成本，曾经把一些平时负载不高的数据库以不同的实例或schema放在了同一套硬件服务器上。这些业务共享一套硬件，跑了两年相安无事。
直到有一天，在下午交易时间里，突然报警系统发出了告警，磁盘io过高，此外归档日志的生成肉眼可见同样在飞速增长。之前可以撑一周的归档日志空间，短时间内写满了，而系统自动备份的频率跟不上，终于数据库报了无法归档的错误，导致几个相关业务全部中断。几个应用系统的负责人几乎是脚前脚后给我打电话或者发信息，质问我到底怎么回事。这一刻我成了靶子，密密麻麻被打满了躺枪的弹孔。
我只好把归档日志临时挪到其他磁盘，保证归档正常进行，同时去检查到底哪些语句执行导致。最后发现，有几个表，insert和update的次数都高的吓人。然后把语句发给了相关应用负责人后，我才勉强不被几个人同时diss。经过排查才发现，应用运维的人员，下午误操作，执行了一个之前用于版本升级调试的应用任务，这个任务就在后台疯狂生成着归档日志。停掉之后，这才恢复正常。
这个事故原因本身不复杂，但是在交易时间造成几个应用业务中断，却是一个不小的事故。如果再多几分钟，怕是就要上报监管机构，这就不是一个技术问题了。第二天我们开会复盘，重点就是如何避免这类事情再度发生。因为是应用系统那边的问题，所以最终的结果也是由该系统的负责人负责内部团队的建设和整改，确保此类事件不要再发生。但是从dba的角度，这件事情却给了我很大的心理阴影。如果核心交易系统出现这种问题，会不会我们这帮人就都被一锅端拿补偿回家了。
后来我总结出几个办法，第一个是，要求应用团队在交易时间里每一个操作，都必须在群里发出。确保开市时间每一次操作都有迹可循，如果某个时间点之后系统出现哪些异常，就可以直接追溯到之前最近的一次操作内容。第二个是，将相关数据库每天自动生成的健康报告同样发送给应用负责一份。让他们对自己系统所使用的数据库情况做一个常规了解，其中包括备份情况、磁盘使用率、过去一天归档增长数量、用户登录情况等等。这也为后来我自己的工作节省了很多麻烦事。
类型4：dba知识经验不足问题造成的事故
这类问题也是比较常见的，同时也是很杂的。很多商业数据库经过几十年的迭代，已经无比复杂。一个dba学习和工作5年，可能都不见得遇到特定的场景。一旦某个场景触及到自己知识盲区的时候，再正常不过了。
之前我曾经把一套数据库从oracle10g迁移到11g，那时候刚工作没多久，也是我第一次做大版本迁移。做完以后测试各种一些基础功能没有问题，也就交给了应用团队。而应用团队在开始使用之后开始发行问题，有个别业务场景性能有了明显的下降。应用负责人找到我，让我帮忙看。我尝试着把有问题的业务场景的表找出来，再找到相关的sql语句，查看执行计划。非常奇怪的是，同一条语句，新库旧库的执行效率差异还挺大。一时之间有点懵，折腾了一个下午，也没能有效解决。乙方的dba给我打电话，问我统计信息是否重新收集，我这才知道，原来数据库迁移之后，这些东西要重新做。当时我假装自己忘了这一步，掩盖过去不知道这件事情的事实。
这类问题我认为是事后分析解决反而容易的，因为事故触及了自己哪些知识盲区，dba自己是心中有数的。在遇到问题并解决问题的过程，也是不断增加自己经验的过程。遇到这类事情，要在事故解决之后，第一时间把事故报告写好，尽量详细。这对于以后遇到类似场景规避问题有着很重要的作用。同时，做到根据事故报告里自己的经验和知识盲区，举一反三，深入学习探索，是一个很快提高自己的途径。
六年前，跟我同期入职的一个dba，我负责oracle，他负责sql server，甚至比我早入行还早了两年。四年的工作下来，我总结了很多事故报告和经验，在处理问题方面越来越得心应手。而他基本上都是凭记忆去处理，两个人处理问题的能力慢慢就被拉大。有时候甚至有些sql server的重现的问题，我都已经大概记住了思路，而他还要重新去翻各种文档。在我离职之后，他也慢慢放起了自己的dba之旅，开始朝着运维流程管理的方向前进。也许对他来说，也不失是一个更好的职业路径。
总而言之，每一次事故，在发生解决后，我们仍然要去反思，为什么会发生，为什么要这么处理，如何应对才能以后尽量规避。不同类型的事故，暴露出来的问题也是不同的，流程的、人员的、技术认知的甚至有的短期内都不一定找得到真正的根源。有时候多思考一下，多走一步，就会给你未来的工作减轻很多负担，规避很多风险。