工作中我们常常会接收到例如来自预警系统的告警邮件或者你的领导转发来的线上问题，那么当我们遇到这类问题的时候该如何去完成处理这个任务呢？以下的处理方法步骤可以提供参考建议。
一、一般我们目前线上问题的来源：
1.主动发现
相关owner每天查看系统监控情况，主动发现了一些异常的现象。
2.监控系统告警
比如应用响应时间在某个时间段上升了，资源层面cpu、内存、io、tcp连接数、disk、线程数、GC、连接池等各个服务器指标异常，可能是某台的服务器出现了异常，但是业务还未受到大面积影响
3.你的领导转发来自来组邮件或者产品
通常这类邮件会有明确的uid,日期时间，服务名称，问题现象。
4.来自微信
通常有截图，这个时候可以问清楚具体触发时间点，重复3的操作，遇到非必现问题，可以尝试多种操作来还原场景
5.生产故障邮件
OPS的发来的邮件
二、查问题的基本步骤
—了解问题概况，评估影响的范围
根据问题的来源，我们首先要确认的是这到底不是线上的故障？ 还是个别的极端case问题？极端的case引起的一般我们会降低优先级。 比如不能下单这样的就是大大大大大大大大大大大大问题。
【tips:针对不同的问题范围直接会影响处理问题的优先级哦~~~】
如果已经确定了是线上故障，我们需要快速响应去定位故障点，找其原因。
稍大一点的公司，一般都有自己的监控系统（服务器监控，服务监控，业务监控）和日志系统。具体分析问题现象，定位问题，看log还是数据。一般能快速判是功能还是性能的问题。
如果是确定功能问题，我们一般可以从日志系统的trace入手：
若有抛错误，通过跟踪日志信息或者特定用户问题追溯来确定，一般这样的日志系统都有唯一的标识id串联上下游，日志是实时的，且支持过滤，统计等查询，可以查看一段时间的趋势情况
如果是确定性能问题，我们一般除了日志系统还会更多的结合监控系统并行灵活组合来看：
日志系统一般都会有各类型的埋点（自定义埋点，实时统计类埋点，PV)，所有数据都是实时埋点，很短的delay。
监控系统里面一般会有应用监控，也包括上下游的服务，调用SOA，被调SOA，调redis监控，调用DAL监控，系统本身的监控，C#的应用还有IIS的监控，java的有VM的监控等
—协调资源
判断故障的影响面，这点很重要，你需要给一个明确的范围，配合关联的产品经理，告知有多少用户（百分比，订单量）会受到影响；
再结合影响面，找你的头，要么申请hotfix，要么放在就近版本修复，如果要修复，一定要让相关人员（主管，产品，测试，关联开发）清楚这个事情的来龙去脉。
—深入分析
针对上面的系统查看，我们一般能找到切入关键点，之后是一个复杂的收集信息-假设-验证—收集信息-假设-验证的循环过程，直到我们找到重现，找到根源。
这里简单列举下常见的一些疑点方向：
- 刚发布新版本不久后，线上在很短的时间内就出了问题。---那很大程度上是由于这次上的版本带来的问题，重点可以检查这次代码的改动点是什么。
- 版本是之前的，突然出现内存方面的错误，严重导致服务不可用。---可能是之前潜在的重大的bug。
- 线上之前一直稳定运行，业务量突增，各服务的响应时间增长，QPS先陡增然后下降，最后大量报错，最严重的时候出现服务不可用。---这种情况很大情况下是上游调用方的突然增加流量，或者是遭遇异常的攻击。
- 版本是之前上线的，QPS正常，服务响应时间增长，日志中出现警告。---可能是数据库，Redis的连接问题，或者定时任务出了问题，导致等等。。。
- 版本是之前上线的，QPS正常，但服务响应时间下降，错误率上升。---可能是下游依赖的服务有异常。
- 很多服务大面积出现短暂的业务失败。---很大可能是网络问题导致。
—问题重现，故障排除
确定好问题的范围后，接下来就是问题重现：
功能类问题，一般比较好重现，如果遇到不是每次都能重现的问题。如果是APP问题，还可以尝试借来手机还原场景，或者通过DEBUG模式尝试定位Dump文件。
根据前面掌握的基本信息，帮助我们快速去理清楚业务发生的时序，比如进入App页，会发生什么事情，Native逻辑做了什么，发起了什么请求（上传参数，内容），服务下发是否为空（检查服务下发），是否正常触发了业务回调，业务回调处理完毕页面内容渲染是否完成。
如果确定是性能问题，需要进行重现，这个过程有时候是比较困难的。。
- 要先拉取当前线上的发布版本，发布到测试环境，分析场景，准备相关的数据
- 我们要看上的机器配置 CPU ，内核，磁盘，物理机还是虚拟机 ，内存， 网络io 等
- JDK版本 ，JVM的参数
- 应用开关配置，数据库， 缓存， redis
- 接口平均的响应时间RT 是的多少， 接口的QPS是多少 平常的性能如何
6.。。
—-验证问题是否解决
通常情况下，对于性能问题的验证：
- 如果线上直接保存了dump文件，直接拉下来分析，若无，转2
- 一般会拉取当前线上有问题的版本看是否能重现问题
- 然后先拉取生产一个稳定的版本，进行两者比对。
- 如果是上线前压测过的版本，我们要详细分析压测的场景。
- 再切换压测一个开发修复后的版本进行对比，还要和基线版本对比。
- 其中比对包括各项性能指标，有的还必须针对dump文件进行对比分析 。 最终的结果是一定要所有修复后的版本性能不能比原来生产稳定的版本差。
- 针对内存的问题，我们一般压测的时间会相对而言比较长一点，观察其趋势。
—上线验证
验证修复后的版本，确认OK后，进行上线，一般都是灰度发布完成后进行观察，看是否正常。
三、如何快速恢复(这个步骤应该和二并行做）
因为系统的可用性决定着公司的客户利益，影响公司的收益和信誉，所以一般我们遇到生产故障的第一要务是，恢复服务，尽可能的把对线上服务影响降到最低。
怎么来快速保障把影响减少到最小呢。一般会参考以下的方法：
- 版本回退：大量报错的情况下，又没有办法快速定位问题根源。一般我们都是功能测试人员负责版本上线，如果在是新版本上线后观察出现了问题，一般都是快速回退，切到近期稳定的一个版本。一般大一点的公司发布系统都做的比较好，可以快速切换版本，且大部分都采用的是灰度发布，可以将范围尽可能减少。
- 备份以及失效转移： 对于服务而言，一但某个服务器宕机，就将服务切换到其他可用的集群服务器上去。对于数据而言，如果某个磁盘出现损坏，就从备份的磁盘读取数据（一般都是事先就做好了数据的同步复制），这个一般都是DBA或者运维人员去操作。
- 切流量： 一般都会有开关控制，如果出现问题，进行关闭一部分流量。 这个发布人员都有权限。但需要事先和相关人员沟通好。
- 扩容机器：线上访问压力大，不能重启机器，或者重启也无法解决时，增加集群机器。
- 重启：当某台服务器的CPU高，或者连接数飙升时，会采取这种方法。这个一般也是运维的人员去完成该操作。
四、如果避免下次再入坑
等找到了根本原因，解决了问题之后，我们需要总结，举一反三，想想在这个故障排查和处理过程中，有哪些环节存在弱点？哪些流程/规范/制度需要优化？
这类似的问题是否在其他系统，模块或者团队中也存在？不断完善，以避免再次踩坑，也在团队中交流经验，共同提高。
再来聊聊我们的架构的一些保护机制
现在一般随着用户的访问增多，大的系统一般做到一定的规模后，架构都会经历过好几次的变迁，巨无霸的系统架构一般都是纵向和横向进行了拆分的，都是将各个模块独立部署，降低了系统的耦合性。这样的架构也更好的方便了我们能够快速排查问题。
总之，线上问题来临肯定有压力的，但不要怕！！！！！
