线上服务宕机问题排查思路

第一步 — 不要慌张，尽快恢复服务可用或者降级

出现线上问题的时候，紧张在所难免，有一篇文章讲解新手与老手处理线上问题的差别：新手遇到问题后，都是忙于排查问题，“这个是怎么回事”，“怎么突然宕机了”，老手会首先想“是否有服务降级策略”，“怎么快速恢复服务”，“重启吧，90%的问题能够靠重启解决”，“是不是上游或者下游有异常”。

在分布式系统横行的今天，大部分故障可分为一下几类：

1. 系统资源不够用（单机内存/CPU/网络流量等等）
2. 上游流量上涨，超过下游承受的最大能力
3. 下游故障，导致依赖的接口的时长或者服务挂掉
4. 代码bug，线程池或者对象池使用不当、内存泄漏、死循环等等
5. 硬件问题
6. 第三方服务影响：多个服务共享某些资源（Redis实例、Mysql实例部署在同一台实体机，多个服务共同部署在一台实体机），当其中一个服务发生异常的时候，会影响到别的服务。比如线上经常看到的有redis的内存被某个服务耗尽了，别的服务缓存的数据就被LRU策略驱逐；mysql出现慢查询或者突然的大批量的insert等擦操作；多个服务在同一个实体机，如果其中一个服务的流量突然暴涨，就会导致别的服务的网卡流量降低。

第二步 — 保留现场

在上面的各个类型中，主要讲解如何排查代码bug造成的问题，这一类的问题有几个共性：

1. 通常表现为系统运行一段时间后突然宕机或者服务响应突然变得奇慢无比
2. 通用的解决方案是，将集群重启，但是留下一台或者几台机器做分析（视情况而定，很多时候使用jmap很容易导致服务挂掉，从而丢失现场）

第三步— 分析解决问题

通常情况下，bug的表现也可以做分类：

1. CPU和load飙高
2. CPU低但是load高
3. 内存耗尽
4. 线程池耗尽
5. TCP指标飙高

针对不同情况，可以使用不同方案。
但是但是，首先

对比问题出现前和出现后的代码差异，通常能够解决90%的问题。
很多时候bug都是一些低端问题，可能就是昨天晚上熬夜想着小姐姐时候写出的爱心bug。

今天先写到这，后面会针对每一个类型或者多个类型组合的原因进行分析。。该吃饭了哈哈