一次问题排查

0，首先要有一个靠谱的架构，每个环节都要安全可靠的。

1，其次是要建立完善的预警（注意不止是告警）机制，包括架构中节点的服务器系统监控指标，服务应用监控指标，需要具备完善的（针对各个服务器，各个应用）全面的（区分普通的，警告的，错误的）监控信息和通知机制。第一时间（早于用户感知）帮助感知到系统风险，第二时间（系统已经崩掉时）帮助分析问题源头。

2，接口超时了可能什么原因？常规的几个超时接口要积累已知的原因和解决方案。比如首页接口/get_course_detail接口，这几个接口常规耗时处理方案就是提前预知高并发流量进行压测评估并临时升配处理，需要和产品建立一个直播或者活动上线的信息同步机制。

3，其他新增的接口超时现象一旦出现，标准步骤有两步：重启和回滚。首先重启服务，并查看项目/对应服务/超时接口是否最近有修改，如果有第一时间线上回滚涉及到的服务。

4，如果前面三个都不能定位问题，除了临场分析没有别的办法。需要知流程（架构）的所有同事一起，从现象出发，按照链路从上到下排查异常，逐个环节节点临场分析确定是否正常。临场排查问题最大的困难有三点：容易漏掉某些线索，跟进的线索可能距离原因很远，同事配合效率很低。在监控不足的前提下，一种乱拳打死老师傅的方法是，现场分析日志，特别分析error日志，其次warning日志。如果error/warning日志都不完善，timeout/Trac/error/异常/not fount/gone away等关键字是没有办法的办法。如果这些关键字都没有思路，只能最笨的办法：从客户端找问题接口，逐层向下排查（一定不要放过任何一个环节节点的任何一个指标和日志）。

上周六的排查过程，其实就属于走到第4步的情况，最大的问题是，在常规1/2/3思路不通的时候（各种重启会滚，已经过去了半小时，9.30了仍然没有解决问题），没有一个主心骨的成熟套路去排查定位问题，也没有一个统筹全局的人去管理分工合作（每个人都没有套路，而且还可能影响别人的节奏）。

（9.47）我直接观察下游服务响应是非常快的，而且发现下游服务接收的请求量和上游发起的请求量存在大幅度的偏差（上游发起上万次请求，下游几百次）。这个现象我一时没有很好的思路，这是一个严重的失误。应该及时去分析内部nginx机器。

（10.17）后来继续跟进第二个耗时接口的时候，又发现一个接口出现类似的情况（下游服务接收的请求量和上游发起的请求量存在大幅度的偏差）。

（12.20）的时候，再次跟进第三个耗时接口的时候，发现第三个内部api都是这种9～10点流量骤减现象。

（12.40） 开始找阿里云跟进。

（13.40）通过分析阿里云后台监控发现ecs连接数异常。

这中间自己虽然整体是按照第4点经验去做的，但是种种原因执行节奏也比较乱。

最后总结一句：日志是最关键的信息，完善的日志需要周密的思考加丰富的经验去搭建的，需要经历一次又一次的故障中总结迭代完善的。warning是最重要的信息，需要有预测性的思维去维护。error是最有用的信息，也是最接近解决方案的。(或者说先关注error信息，要有完备的error日志；其次要关注warning信息，要有完备的warning信息。前者比如traction，后者比如timeout，排查问题先找最突出的信息，比如超时最长的)。

这次问题最终定位到python同步调用导致的，A同步调用B，A/B都是tornado，A阻塞占用进程。

一切都解释了，找到一个调用环，而且是python的同步调用。死锁了。

解决方法：加超时，加缓存，或者直接异步调用。