前言
我相信你一定遇到过软件上线后出现问题，可以说每次上线应该是软件最容易出现问题的时候，所以也有各种各样预防的措施，比如充分的测试、灰度发布、上线监控、回滚方案等等，这一切都是为了尽量减少版本上线后出问题所造成的损失，一个成熟有经验的团队会非常高效的解决上线后的故障，而缺乏经验的团队遇到问题后则可能无法第一时间做出正确的判断，现在我们来对比一下，看看有哪些可以借鉴学习的地方。
核心步骤
1、评估影响范围
2、根据影响范围确认解决方式
3、复盘、持续优化
4、建立
评估影响范围
一般而言，当上线出现问题后，作为开发人员可能第一反应就是先确认问题原因，也就是熟悉的找bug过程，尤其是自己写的代码出现bug时，可能更着急，也许是为了找出问题后能够尽快的修复，也许是为了找出问题后能够甩锅，但无论如何，你应该提醒自己线上问题已经发生，每耽误一秒就意味着损失就越大。
所以，我们最关心的应该是问题的影响范围，是否是核心业务，如何快速恢复，待生产系统恢复后再去修复bug。
恢复生产、减少损失要牢记。
根据影响范围确认解决方式
影响范围确定后，接下来就是确认解决方式了，虽然快速恢复生产是我们的首要任务，但也可根据影响范围的不同而采取不同的措施。如果影响的范围触及到核心业务，我们应该快速采取版本回滚、服务降级等快速有效的手段来尽快恢复生产，减少损失，如果影响的范围较小且不触及到核心业务流程，那可能我们就会通过修复bug，然后再重新发布一个新的修复版本来解决。
复盘、持续优化
敏捷开发中，每一个迭代结束后一般都会有一个版本回顾会，这是一次非常好的经验总结的机会，特别是当发布版本遇到线上故障时，如果能很好的进行分析、总结、分享，那对于整个团队来说，应对线上故障的能力提升效果是非常明显的，并且有了一次解决线上故障的实际经验之后，下次如果再遇到类似的故障，处理起来也会得心应手。
通过不断的总结、分享，针对不足提出改进方案，真正做到持续优化。
值得借鉴的其他方案
故障监控、告警
如果每次发生线上故障，开发人员总是最后一个知道，或者总是被动通知，那可能就要反省故障发现机制了，要做到最快的处理线上故障，那必然是要让最熟悉系统的人，最快的发现线上故障，毫无疑问，最熟悉系统的人肯定就是开发自己了，所以如何不能第一时间找到开发人员，那势必会增加故障恢复时间，此时一套完善的故障告警机制就至关重要了，而告警数据一般又可以通知完善的监控体系来采集，比如普罗米修斯之类的产品。
轮值机制
当然，当产生故障告警时，就需要让正确的人第一时间做出响应，那正确的人通常是开发，但也不可能让每个开发都24小时待命，所以一般都会采用轮值机制，比如安排2个人值班，一个主要的，出现问题要第一时间响应，一个次要的，如果主要的联系不上，次要的就可以顶上。而作为值班人员一般就需要24小时待命了，手机要保持开机，笔记本要随身携带，如果轮值人员通知不上，就会层层向上通知。
虽然轮值机制需要24小时待命，对于值班人员来说非常辛苦，但有时候也没办法，要想系统故障能够快速恢复，有时候也只能靠开发人员去处理。
实战演习
实战演习就是频繁地对故障进行演练，来测试平时做的这些方案是不是真的可行，这样遇到真正的故障，才不至于手忙脚乱不知道如何应对。其中最有名的就是Netflix的Chaos Monkey（混乱猴子）的系统，这些猴子会在工作日期间随机杀死一些服务，制造混乱，来测试生产环境下的稳定性。