QQ作为IM的业界翘楚，已经在IM方面积累了相当的经验，这次的事故（其实也不能叫事故，只是PV稍微受到了一点影响）是一次典型的沟通问题，也在一定程度上反映了目前一些监控的效率问题。
8月14日晚间大约7点半，我发布了后台的一部分服务，这是这次事件的触发点。
由于本次更新调用了另一个部门的接口，并且由于部门间合作项目的急于上线，我在之前的基础上调用了原来对方提供的接口。这个服务按照原来的设想是全量上线，也就是说，线上几乎所有的write都会经过这个服务调用的过滤和判断。这个服务是后端早已存在的，也在之前的逻辑中有交互，刨除负载均衡和链路传输的各种优化（都是内部组件恕我不能说明），应该不会有问题；但到了晚间8点半左右开始，该调用服务产生大量超时：Timeout 200以上，甚至有30%左右的请求达到了1000-2000的延时，直接的影响就是移动客户端开发的速度明显变慢，且这个情况在晚间高峰（21点-次日凌晨1点）一直存在，影响了整体的服务体验！
这个问题到了次日早上终于被定位到：由于调用的服务对请求量的估计不足，导致了服务请求将对付服务器跑满，处理队列难以承受高压而几近崩溃。
回头总结会议再次定位时，还发觉前一天有我方的服务器宕机，虽然影响了大概一小时，但被容灾组件剔除后恢复，又加入了大量服务容错的机组，一直处于较为不稳定的状态，这可能也有一部分原因。
时间线大致如下：
（1）7：30 后台相关发布
（2）8：40 发现请求延时上升，后台一台机器出现oom
（3）9：30-10：00左右 后端leader查出pv视图异常，开始联系大家自查
（4）10：50 剔除后台故障机器，观察发现整体延迟没有明显改善
（5）11：20 系统完全恢复正常
这里暴漏的问题不少：
1. 后台告警梳理，避免过多的告警影响重要告警的发现。此次问题持续了大概一整晚的时间，到次日早上才得以平缓，警告的作用没有很好的发挥。平时很多监控视图的警告，甚至有一些同学为了查看自己带量情况而加入的“伪警告”和正常情况下警告，严重影响了警告的效率，使得真正有用的警告却被湮没。
2. 模块分离部署，避免故障影响其他模块。在调用其他部门其他服务时，最好将模块分离，一旦有问题可以及时拔插，这也是估计上的不足，但对方并没有对IM这种大型的服务做出评估质疑也相对失误。
3. 后端服务宕机和oom故障后续处理流程，后续需要更谨慎一些，加强对发生过的机器的视图观察，避免可用性的下降。
4. 视图基础属性问题分析，监控存在一些基础属性错误上报，需要梳理。
5. 监控细化，对各个调用步骤分别监控，争取能在第一时间定位到问题。
6. 单机故障引起整个系统延迟大规模上升的问题，仍然需要进一步分析，预防。
7. 在今后的联合部署发布中，需要认真周密的与对方沟通请求量的情况；督促对方增加对服务质量的监控。
Comments
Lo: 学习了