故障问题处理指南
- 工作小总结
- 时间：2021-07-20 10:29
- 2891人已阅读
🔔🔔🔔好消息!好消息!🔔🔔🔔
有需要的朋友👉:联系凯哥
一、概述
线上故障问题处理一般分为以下几个步骤：
故障发现
故障处理
故障复盘
在故障处理期间，无论是哪一个阶段，要记住我们的首要目标是“止损”，尽快恢复、消除故障影响，这并不代表我们完全定位了故障问题，也不代表解决方案是完美的，因为这些是可以恢复后复盘的。
二、故障发现
及时发现故障是处理故障的前提，越早发现问题，就越能减少故障带来的影响，我们应当尽可能通过自动化的方式主动发现问题。
主动发现
是指通过技术指标监控报警，业务指标监控报警，巡查手段发现线上问题。值班期间应当主动巡查负责系统的各项指标，各类监控是否正常。
常用的监控类型：
监控类型 | 监控指标 | 备注 |
|---|---|---|
| 服务器监控 | 负载、内存、IO等 | |
| 服务监控 | 吞吐量、接口性能、响应时间等 | |
| 业务监控 | 访问量，业务量，错误率，转化率等 | |
| Paas | 类型监控项mysql慢查询、负载、线程数、死锁squirrel慢查询、大key、单机/集群qpsrocketmq消息积压数、消息量等 |
被动发现
被动发现是非自身技术监控发现的问题，如通过其他系统负责人、产品、运营、客服的反馈才发现问题，团队应当确保团队成员都加入到问题处理群：
渠道 | 关注 |
|---|---|
| 钉钉 | xxx群 |
三、故障处理
核心原则：
语音沟通 优于 文字沟通
团队协作 优于 孤军奋战
优先止损 优于 优先究因
断臂防崩 优于 深陷泥潭
识别
无论主动或是被动，值班人员接到故障后，第一件需要做的事情是识别故障的特征。业务高峰期值班我们要求接到问题立刻开始处理
识别问题的优先级
级别 | 描述 | 判断标准 | 举例 |
|---|---|---|---|
P0 | 重要且紧急 |
|
|
P1 | 重要不紧急 |
|
|
P2 | 不重要不紧急 |
|
|
总结判断点，
范围，影响面
金钱，影响金额
关键渠道，新东方在线、新东方在线中小学、小程序。
核心路径，上课，购买流程
处理
故障处理方法的核心要点有三，团队作战，优先止损，深究根因。
在当前服务化架构的线上系统环境下，我们最看中的指标是系统的可用性，特别是核心业务流程的业务可用性。
因此最怕的是线上故障造成系统雪崩，导致长时间的不可用。线上故障处理也可以有“黄金5分钟”的概念，在大流量下，故障发生最初的5分钟如果介入处理，快速定位到根因，作出正确的决策处理，能最大程度避免系统出现雪崩，出现长时间不可用的情况。
团队
业务高峰期间进行故障处理，尽量组成团队作战。这个团队有如下几种角色分工：
角色 | 职责 | 举例 |
|---|---|---|
| 指挥者 |
|
|
| 处理者 |
|
|
| 操作者 |
|
|
附故障通报格式
故障标题：
影响范围：
发现时间：
原因简述：
处理人：
预计恢复时间：
止损
故障处理的第一要务 优先止损！优先止损！优先止损！
非关键流程的功能故障，优先选择降级。以快速屏蔽问题功能为第一目标。
关键流程的资源故障，优先操作限流。以保护系统不被拖垮，不雪崩为第一目标。
非同步流程的功能故障，优先选择降级。
通常来讲，立即回滚刚上线的代码都是有效的。
究因
止损操作完成后，还需要进一步确认问题的根因是什么。
如果是功能类故障，需要及时找到问题逻辑，修改代码，在当天的低峰期上线完成fix，恢复降级。如果是资源类故障，需要及时申请资源，完成扩容或者替换，恢复限流。
四、故障复盘
每个人都会犯错，主要的区别在于，成功人士能从错误中吸取教训，而普通人则不能。我们允许犯错，但不容忍妄顾教训、一错再错。
通过编写CaseStudy总结问题， CaseStudy的目的不是为了追究责任，是要避免同类型问题的发生，模板参考YYYYMMDD-用户产品研发部CaseStudy模板。
上一篇： 5whys分析法在美团工程师中的实践
下一篇： 接口规范