云时代架构读后感二
今天阅读了微信公众号的文章，关于一次游戏卡死的解决历程。
地址：https://mp.weixin.qq.com/s/a6AqbGnfMrTfG55bgoT_qg
作者用google play上推荐的一款游戏展开话题，内网测试环境（Testing Environment）和预生产环境（Staging Environment）一切都测试正常，随时等待更新线上正式坏境了。慢慢地游戏内的聊天中开始有玩家反馈这次更新后游戏太卡，而且反馈的用户越来越多，我这才意识到问题的严重性了，游戏服肯定哪里操作太慢反应迟钝了。接下来一步步解决游戏卡死问题。
事故的处理过程还原
首先是如何发现问题
发现问题通常通过自动化的监控和报警系统来实现，线上游戏服搭建了一个完善、有效的日志中心、监控和报警系统，通常我们会对系统层面、应用层面和数据库层面进行监控。
对系统层面的监控包括对系统的CPU利用率、系统负载、内存使用情况、网络I/O负载、磁盘负载、I/O 等待、交换区的使用、线程数及打开的文件句柄数等进行监控,一旦超出阈值, 就需要报警。对应用层面的监控包括对服务接口的响应时间、吞吐量、调用频次、接口成功率及接口的波动率等进行监控。
对资源层的监控包括对数据库、缓存和消息队列的监控。我们通常会对数据库的负载、慢 SQL、连接数等进行监控；对缓存的连接数、占用内存、吞吐量、响应时间等进行监控；以及对消息队列的响应时间、吞吐量、负载、积压情况等进行监控
其次是如何定位问题
定位问题，首先要根据经验来分析，如果应急团队中有人对相应的问题有经验，并确定能够通过某种手段进行恢复，则应该第一时间恢复，同时保留现场，然后定位问题。
在应急人员定位过程中需要与业务负责人、技术负责人、核心技术开发人员、技术专家、 架构师、运营和运维人员一起，对产生问题的原因进行快速分析。在分析过程中要先考虑系统最近发生的变化,需要考虑如下问题。
- 问题系统最近是否进行了上线?
- 依赖的基础平台和资源是否进行了上线或者升级?
- 依赖的系统最近是否进行了上线?
- 运营是否在系统里面做过运营变更?
- 网络是否有波动?
- 最近的业务是否上量?
- 服务的使用方是否有促销活动?
然后解决问题
解决问题的阶段有时在应急处理中，有时在应急处理后。在理想情况下，每个系统会对各种严重情况设计止损和降级开关，因此，在发生严重问题时先使用止损策略，在恢复问题后再定位和解决问题。解决问题要以定位问题为基础,必须清晰地定位问题产生的根本原因，再提出解决问题的有效方案，切记在没有明确原因之前，不要使用各种可能的方法来尝试修复问题，这样可能还没有解决这个问题又引出另一个问题。
最后消除造成的影响
在解决问题时，某个问题可能还没被解决就已恢复，无论在哪种情况下都需要消除问题产生的影响。
- 技术人员在应急过程中对系统做的临时性改变，后证明是无效的,则要尝试恢复到原来的状态。
- 技术人员在应急过程中对系统进行的降级开关的操作，在事后需要恢复。
- 运营人员在应急过程中对系统做的特殊设置如某些流量路由的开关，需要复。
- 对使用方或者用户造成的问题，尽量采取补偿的策略进行修复，在极端情况下需要一一核实。
- 对外由专门的客服团队整理话术统一对外宣布发生故障的原因并安抚用户，话术尽量贴近客观事实，并从用户的角度出发。
