一,故障处理流程
1.1示例:数据库故障处理
下面是来自网易的一些经验,整理自《深入浅出MySQL》一书。
1.1.1事前:故障处理原则h5> 1)沟通第一
在数据库出现故障时,务必和运维,开发,产品等其他团队保持高效沟通.DBA在遇到故障时,一定不要忘了沟通的重要性,即使时间紧迫,简要的沟通往往也能带来事半功倍的效果。从长远来看,也有利于培养和其他人,其他团队之间的合作和信任关系。
2)关注人为
人为故障占有不小的比例。要通过及时沟通并查看历史记录,确认操作是否有误,要和其他团队沟通是否有特殊操作。当然,解决人为故障最好的方法还是将数据库运维自动化,标准化,规范化。
3)快速恢复
在处理故障的时候,要明确的一个思路是要优先恢复服务,确保服务的最大可用性,其他的不一定要优先考虑。
4)三思后行
有些故障处理方式,可能对数据库造成难以恢复的影响,务必慎重,并尽量做好备份。对于操作本身不熟悉带来额外的问题,要尽量避免。认真考虑命令可能带来的后果,避免对系统造成二次伤害。
5)服务分级
平时应当对服务,应用,数据库做好分级,一旦出现大面积故障,可以按照服务的优先级来恢复核心业务。
1.1.2事中:故障处理流程h5> 1)故障发现
<李>
操作系统指标
<李>负载李
<李> CPU使用率
<李>磁盘空间李
<李> IO使用率
<李>交换使用情况李
<李>
DB指标
<李>数据库存活李
<李>连接数
<李>慢SQL李
<李>主从延迟李
操作系统指标
-
<李>负载李
<李> CPU使用率
<李>磁盘空间李
<李> IO使用率
<李>交换使用情况李
DB指标
-
<李>数据库存活李
<李>连接数
<李>慢SQL李
<李>主从延迟李
2)故障定位
-
<李>
检查操作
-
<李>程序发布李
<李>在线表变更李
<李>在线数据修改李
<李>后台任务,数据统计李
<李>数据库参数调整李
<李>其他误操作
检查操作系统
-
<李>系统进程李
<李> CPU李
<李>内存,交换李
<李> IO李
<李>系统日志李
检查数据库
-
<李>连接李
<李>慢查询李
<李>锁等待李
<李>每秒李
<李>错误日志李
1.1.3事后:故障解决方法
1)慢SQL
-
<李>选择条件上没有索引或者索引效率低。
<李>有索引,但没有用到索引,或者选择了错误的索引。
<李>过滤条件不强,结果集太大。
2) SQL执行频率高
-
<李>恶意攻击
<李>缓存失效李
<李>应用实现逻辑不合理李
<李>业务量突增李
3)锁冲突
-
<李>大事务李
<李>热点问题
4)硬件问题
-
<李> RAID卡缓存问题
<李>硬件损坏
5)参数不合理
1.2示例:全科医生数据库异常处理(我的经验)
下面是我在之前单位总结的,针对全科医生的异常处理流程。图中【】的部分对应具体的处理步骤(对应脚本或操作文档)。
从上述两个示例可以看的出,这是一种“统筹式“的工作方式,而非“应急式“的。它强调的是在出现故障后,按照规划好的原则,步骤进行分析排查,找出核心问题,然后针对既有问题,再按照已有的相关预案进行处理。同时在处理过程中,注意规避风险及沟通协调,以期达到故障的快速解决。显然这种方式,代表着一种对工作的前瞻力,防患于未然,避免了那种忙于救火,使工作永远处于被动之中。上述其实就是一种“结构化思维“的体现。
二、结构化思维
2.1什么是“结构化思维“?
-
<李>思考的时候没有逻辑,大多数时候不知道从哪里下手。
<李>讲话时没有条理,费很多口舌却很难把事说清楚。
<李>处理问题时效率低、东捡西漏,忙得团团转效果却不佳。
<李>当你面临上述窘境时,正是可以考虑训练自己的结构化思维来解决。
