暂无图片
暂无图片
16
暂无图片
暂无图片
暂无图片

事故之后,DBA该如何应对

原创 多明戈教你玩狼人杀 2021-11-15
2618

我相信,在日常工作中,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之旅,开始朝着运维流程管理的方向前进。也许对他来说,也不失是一个更好的职业路径。


总而言之,每一次事故,在发生解决后,我们仍然要去反思,为什么会发生,为什么要这么处理,如何应对才能以后尽量规避。不同类型的事故,暴露出来的问题也是不同的,流程的、人员的、技术认知的甚至有的短期内都不一定找得到真正的根源。有时候多思考一下,多走一步,就会给你未来的工作减轻很多负担,规避很多风险。

最后修改时间:2021-11-17 10:56:19
「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
3人已赞赏
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论