提问/ 作为DBA运维的你是否有过这些苦恼？
1）什么？又有告警啦，CPU咋又飙高啦？IO又打满啦？
- 对服务器赶紧一顿操作猛如虎，然并卵，故障犹如股市大盘，依然坚挺，还有客户、领导在后面排队督军，此时谁来help我呢？
2）有时候出去面试，明明感觉和面试官聊的很好，但面试完成后就没有后续，是否有过疑惑，这是why？
- 面试官：请给出数据库实例所在的物理机上CPU飙高及IO飙高的故障排查思路。
- 应聘者：可以先查看当前系统的性能，然后在查看一下数据库的会话，一般都是慢日志导致的，针对慢sql优化进行话题展开。
- 面试者：如果io飙高确认不是慢sql导致的，该如何排查呢？
- 应聘者：啥？啥？啥？弄啥嘞？这该怎么回答，我也没遇到过啊，心中万只草泥马在奔腾。
其实站在面试官的角度看，也合乎情理。为啥嘞？可以细想一下：当同一个问题让你问上无数遍，而得到的答案都是类似的，你是否也会厌倦？但如果面试官有丰富的故障排错经验或处理过非慢sql导致的疑难杂症，他会怎么做呢？所以，我们不要再让慢sql背锅了，有些疑难杂症慢sql也是背不动的，既然如此，该如何处理呢？
别急让我们往下看
1、心中有章，遇事不慌
比生活中买彩票中奖率高的就是我们运维中遇到的一些性能问题了：业务接口响应慢了、数据库卡了、服务器性能飙高了、数据库异常宕机了、业务时快时慢等意想不到又在情理之中的问题。那么，我们第一次（或多次）遇到又该如何处理呢？可以关注公众号，让小编为你排忧解难~
星星宝典
整套故障排查及应对策略送给你，让你像包拯一样断案如神：
首先
我们碰到问题之后要做到心中有章（章程），遇事不慌。先沉着冷静，仔细了解故障现象（如果收到报警信息，则需要进行报警信息确认；如果是客户/用户反馈问题，要和客户确认现象，有时客户/用户反馈的问题不一定准确，为了缩短故障判断，我们需要确认故障现象来避免我们问题排查时进入思想误区）；
其次
我们需要根据故障现象来进行初步分析，例如：操作系统性能，我们要先查看操作系统当前的性能指标，确定是哪个应用程序导致的，如果是某个应用程序有问题（MySQL宕机），则需要进行日志收集；
然后
确定了应用程序后我们可以进行具体分析。例如查看日志输出，使用性能工具进行分析（perf、pstack、pidstat、strace等）；
接着
通过日志或者现象我们可以得到部分结论，通过部分结论继续排查及论证，类似于包拯破案，层层抽丝剥茧，完善整个故障链条，针对同一个故障现象进行反复论证，防止出现冤假错案，也使最终结论更有说服力及专业性，让领导、客户、用户、伙伴都认可放心；
最后
我们针对问题已经有了具体分析，也有了结论，我想故障该如何解决并避免等后续问题，你心中应该有答案了。此时就可以梳理成故障报告，昭告天下喽~
2、真实案例，我们能赢
说了这么多理论，想必你感兴趣的是货真价实的实践了，那么我们就拿一个真实案例进行分析——当数据库所在的实例IO高，该如何分析处理：
故障处理场景
岁月静好，阳光慵懒的午后，某人正在享受熟睡的香甜。突然的信息打破了温馨的画面...
什么！？？？
收到一条某客户的数据库实例所在的宿主机磁盘io利用率高的报警信息！这会导致客户的业务系统运转缓慢。
运维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 by和order by，同时通过会话列表进行确认
（故障已定位并反馈，进行相应的应急处理….）
故障汇报后：分析一下慢sql，并和客户业务方沟通处理
大脑报告：已在进行中
具体的实操步骤请详见故障分析 | linux 磁盘io利用率高，分析的正确姿势（该案例根据真实案例改编）
经过上述一顿猛如虎的操作和排查，1-2分钟内快速定位了问题原因，且及时和客户业务方进行沟通，最大化地减少并避免了业务受到的影响。同时，在故障排查过程中保留了排查步骤及结果图，故障处理完成后进行故障报告编写，全流程专业、顺畅、有序的操作得到了客户的认可与肯定。
3、复盘
3.1继续完善及挖掘监控漏洞
本次故障是监控系统先于业务发现故障，在业务感知前及时发现并进行了处理，没有造成任何对业务不利的影响，在监控预警阶段就把问题扼杀在摇篮里，充分体现了监控预警的重要性，后续还得继续挖掘及完善目前监控不到的信息，保障监测全面、准确；
3.2继续整理各种故障场景预案
针对常见的不同类型故障场景做好预案方案的梳理和筹划，形成完备的故障处理操作指南库，指导实际业务中的工作有序、快速、准确完成；
3.3针对特定的故障排查思路制作自动化工具
DBA团队针对特定或相同的工作流程进行工具化处理，实现自动分析，缩短人为处理的时间，最大程度实现重复、简单工作的自动化、智能化响应处理。
说了这么多干货和方法，小编想告诉大家：
作为一名从业多年的DBA运维人员，业务系统出现故障并不可怕，可怕的是我们没有任何思路和解决方案，出现问题时措手不及，影响了客户的业务运转，引发客户对公司技术团队专业能力的质疑。
因此，运维团队要不断完善监控预警系统监控的信息和维度，尽可能保障监测的全面性、充分性；另一方面也要针对常见的不同故障场景制定各类预案和实施计划，防范问题于未然；再者，针对简单、重复的一些工作流程。
Enjoy GreatSQL 🙂
