运维DBA小伙伴瞬间惊醒，开始在键盘上运指如飞，大脑指令也在飞速运转。报警10s后：登录涉事服务器检查一下当前系统状态 大脑报告：目前系统load负载高，成上升趋势，cpu等待io的响应时长较高，说明故障刚发生没多久，可能存在磁盘io压力报警12s后：检查当前各个设备的磁盘IO情况 大脑报告：目前数据库所在的sda磁盘块设备io读写压力较大报警17s后：检查sda磁盘块的每秒读写比例 大脑报告：目前sda磁盘块压力较大，每秒写入比每秒读差距较大，说明当前存在大量的io写入报警23s后：快速检查一下sda磁盘中哪个应用程序占用的io较高（单台物理机多实例部署） 大脑报告：通过pidstat发现，确实是数据库（某个实例）的io比较高，且该实例部署在sda磁盘中，pid为73739报警30s后：快速分析该数据库实例哪一个线程占用io比较高 大脑报告：目前是74770这个线程占用的io比较高报警40s后：分析这个线程在干什么 大脑报告：目前这个线程在写入多个文件，文件句柄号有64、159报警50s后：看看这个文件句柄是什么 大脑报告：这个线程在大量写入临时文件报警60s后：通过线程号，看一下对应的会话信息 大脑报告：目前有一个sql执行了67s，且此sql使用了group%20by和order%20by，同时通过会话列表进行确认（故障已定位并反馈，进行相应的应急处理….）故障汇报后：分析一下慢sql，并和客户业务方沟通处理 大脑报告：已在进行中具体的实操步骤请详见 故障分析%20|%20linux%20磁盘io利用率高，分析的正确姿势 （该案例根据真实案例改编）经过上述一顿猛如虎的操作和排查，1-2分钟内快速定位了问题原因，且及时和客户业务方进行沟通，最大化地减少并避免了业务受到的影响。同时，在故障排查过程中保留了排查步骤及结果图，故障处理完成后进行故障报告编写，全流程专业、顺畅、有序的操作得到了客户的认可与肯定。

编辑 复盘： 故障排查结束后、万里的技术团队在做什么？

#1 继续完善及挖掘监控漏洞本次故障是监控系统先于业务发现故障，在业务感知前及时发现并进行了处理，没有造成任何对业务不利的影响，在监控预警阶段就把问题扼杀在摇篮里，充分体现了监控预警的重要性，后续还得继续挖掘及完善目前监控不到的信息，保障监测全面、准确；#2 继续整理各种故障场景预案针对常见的不同类型故障场景做好预案方案的梳理和筹划，形成完备的故障处理操作指南库，指导实际业务中的工作有序、快速、准确完成；#3 针对特定的故障排查思路制作自动化工具万里DBA团队针对特定或相同的工作流程进行工具化处理，实现自动分析，缩短人为处理的时间，最大程度实现重复、简单工作的自动化、智能化响应处理。

编辑

#说了这么多干货和方法，小编想告诉大家：作为一名从业多年的DBA运维人员，业务系统出现故障并不可怕，可怕的是我们没有任何思路和解决方案，出现问题时措手不及，影响了客户的业务运转，引发客户对公司技术团队专业能力的质疑。因此，万里数据库的技术运维团队，一方面不断完善 监控预警系统监控的信息和维度，尽可能保障监测的全面性、充分性；另一方面也 针对常见的不同故障场景制定各类预案和实施计划，防范问题于未然；再者，针对简单、重复的一些工作流程，万里数据库还制定了 专门的自动化工具，三管齐下，为客户的业务系统全面保驾护航。

编辑

把数据库运维工作交给万里数据库，

我们用心，

客户放心。