原文地址：
https://mp.weixin.qq.com/s/a6AqbGnfMrTfG55bgoT_qg
一次线上游戏卡死的解决历程
事故的处理过程还原
解决线上问题的“四部曲”
-
望：就是观察的意思，出了问题最重要一点就是观察线上问题发生的规律，切忌有病乱投医，一上来就先各种偿试各种改的。除了观察现象外，我们还要观察各种日志、监控和报警系统，具体如何搭建“大数据日志监控系统”请参照作者书的第四章。
-
问：就是问清楚现在问题发生的情况，这个很重要，后面会重点介绍具体需要问清楚的哪些问题。
-
闻：就是认真听取别人的意见，有时线上出了问题，我们大多数心里还是比较抵触别人说这说那的，不过在这种情况下，我们更应该多听，找到可能引起问题的情况或有关的事情，同时也为后面的“甩锅”技巧打开思路。
-
切：就是动手实践验证了，通过前面的观察、询问问题，我们心中应该能有些假设和猜测的线索了，这时候就需要动手在测试环境或预生产环境上进一步验证我们的假设是否成立了。
前面通过对“四部曲”的介绍，大家可能会觉得很抽象，不过它是我们解决线上问题的指导方针、核心思想，那我们在实际项目中又是如何“望问闻切”的呢？
首先是如何发现问题
发现问题通常通过自动化的监控和报警系统来实现，线上游戏服搭建了一个完善、有效的日志中心、监控和报警系统，通常我们会对系统层面、应用层面和数据库层面进行监控。
对系统层面的监控包括对系统的CPU利用率、系统负载、内存使用情况、网络I/O负载、磁盘负载、I/O 等待、交换区的使用、线程数及打开的文件句柄数等进行监控,一旦超出阈值, 就需要报警。对应用层面的监控包括对服务接口的响应时间、吞吐量、调用频次、接口成功率及接口的波动率等进行监控。
对资源层的监控包括对数据库、缓存和消息队列的监控。我们通常会对数据库的负载、慢 SQL、连接数等进行监控；对缓存的连接数、占用内存、吞吐量、响应时间等进行监控；以及对消息队列的响应时间、吞吐量、负载、积压情况等进行监控。
其次是如何定位问题
定位问题，首先要根据经验来分析，如果应急团队中有人对相应的问题有经验，并确定能够通过某种手段进行恢复，则应该第一时间恢复，同时保留现场，然后定位问题。
在应急人员定位过程中需要与业务负责人、技术负责人、核心技术开发人员、技术专家、 架构师、运营和运维人员一起，对产生问题的原因进行快速分析。在分析过程中要先考虑系统最近发生的变化,需要考虑如下问题。
-
问题系统最近是否进行了上线?
-
依赖的基础平台和资源是否进行了上线或者升级?
-
依赖的系统最近是否进行了上线?
-
运营是否在系统里面做过运营变更?
-
网络是否有波动?
-
最近的业务是否上量?
-
服务的使用方是否有促销活动?
然后解决问题
解决问题的阶段有时在应急处理中，有时在应急处理后。在理想情况下，每个系统会对各种严重情况设计止损和降级开关，因此，在发生严重问题时先使用止损策略，在恢复问题后再定位和解决问题。解决问题要以定位问题为基础,必须清晰地定位问题产生的根本原因，再提出解决问题的有效方案，切记在没有明确原因之前，不要使用各种可能的方法来尝试修复问题，这样可能还没有解决这个问题又引出另一个问题。
最后消除造成的影响
在解决问题时，某个问题可能还没被解决就已恢复，无论在哪种情况下都需要消除问题产生的影响。
-
技术人员在应急过程中对系统做的临时性改变，后证明是无效的,则要尝试恢复到原来的状态。
-
技术人员在应急过程中对系统进行的降级开关的操作，在事后需要恢复。
-
运营人员在应急过程中对系统做的特殊设置如某些流量路由的开关，需要复。
-
对使用方或者用户造成的问题，尽量采取补偿的策略进行修复，在极端情况下需要一一核实。
-
对外由专门的客服团队整理话术统一对外宣布发生故障的原因并安抚用户，话术尽量贴近客观事实，并从用户的角度出发。
当我们详细地了解了如何发现问题、定位问题、解决问题和消除造成的影响后，接下来让我们看下本次解决线上游戏卡死过程中是如何具体的应用的。