????????对于职场老司机来说，故障处理肯定是会遇到很多次的。这里总结下常见的故障及处理方式。
? ? ? ? 想要得心应手的处理故障，那么故障前的准备是必不可少的。可以分为两个方面。
? ? ? ? ?????服务级别的监控。
?????????????所有用到或者依赖的外部应用都需要有监控。数据库、redis内存及CPU使用情况，慢sql监控。kafka的消息积压情况，es的负载情况。项目各节点是否都活着，及对应的内存和cpu。对应这些监控都需要设定指标，超过指标则需要告警到群里。
? ? ? ? ? ? 业务级别的监控
????????????流量网关的各接口请求量或者失败量需要做成排名。一些关键的业务更是需要重点监控。比如5分钟以内的建单量，或者5分钟内某关键接口的调用量等。? ? ? ? ? ?
? ? ? ? 如果故障真的来了，操作一般有几个。回滚，降级，重启，限流，快速处理。
? ? ? ? ? ? ? ? 1，刚发布新代码则发现大量告警，或者大量用户反馈功能无法正常使用。这种情况直接回滚操作。如果特殊场景下无法快速回滚，比如app端。这种情况就要预留业务功能开关，以便能快速业务降级。一般发布生产前都会先发布灰度环境，保证部分用户先体验过该功能。
? ? ? ? ? ? ? ? 2，没有发布过新代码。突然收到某服务的告警，然后引发了更多服务的告警。
????????这种情况一般会叫上各项目负责人一起拉起会议马上诊断问题。看各自项目的报错基本都报的什么有一个初步的判断。下面提供几个思路：
? ? ? ?1）查看流量监控。是否某接口突发流量把负载拉高。如果是则需要限流。
? ? ? ?2）查看数据库的负载情况。比如cpu使用线突然拉高，那就的看下现在是否有慢sql。监控平台可以查看到，叫运维杀掉，快速处理。
? ? ? ?3) 网络是否故障，ping下机器。
? ? ? ? 4）看下服务器的各节点运行情况。比如某台机器内存打满了，那么这时其实重启它可快速恢复。如果是某个服务的很多节点都负载变高了，且流量也变大了。那是否需要马上加节点。
? ? ? ? 我就遇到过很多线上故障：比如每个用户的缓存过期时间设置的一样，那么同时过期会导致大量请求走到数据库，数据库负载一下就拉高了。
? ? ? ? 有些陈年老代码里面的查询，走的是大表的全表扫描。这种接口半年都调不了一次，但是一旦调用到了就完蛋。所以平时还的把这些梳理出来并整改才行。
? ? ? ? 还有提供给三方调用的接口，以前没做限流裸奔。被他们bug性的直接疯狂调用，导致我们服务打满。
这里故障处理有个原则：尽快恢复，降低影响范围。? ?
? ? ? ? 其实想要做到对故障应对得心应手，那还需要平时做故障演练。演练多了问题也就变得简单了。??