一、标准的CaseStudy
1.为什么要写CaseStudy？
记录事件并且跟踪后续改进
吸取教训，分析发现问题并杜绝改善
促进团队学习和成长
增进团队合作以及团队内的信赖关系
2.写CaseStudy的方法是什么？
事故描述：时间、人物、简述。
时间需要精确到分钟。
人物需要写明跟进人，如果责任人明确，需要写上责任人。
事故简述：需要用1-2句话简短的描述问题。
事故详情：详细阐述case发生的每个时间点所发生的事情。什么时间、现象、如何发现、做了什么事情、如何解决的问题等。按照时序图尽可能的还原事故现场以及解决步骤。
影响和损失：客观地评估影响。例如：损失的金钱，受影响的请求书/用户数/订单数/受影响的时间。要用具体数字予以量化，不能用“较多”、“部分”这种模糊词。
分析原因：刨根问底，找到case的根源，以及解决的办法。可以采用5whys分析法。一步一步往深追，一层一层找原因，尽可能达到一个真相大白的境地。
二、非标准的事实
1.追查问题的一般思路
确认任务：XX系统XX功能出现了XX的问题
复现问题：线上出现慢查询问题：追查原因发现是因为value＝null所导致。
定位问题：查看日志，监控，调试。利用一切可以采用的方法，大胆假设，小心论证，不断缩小范围，逼近真相。
解决问题：解决问题的时候要避免引入新的问题，不能因为着急引发连环Case。
预防问题：杜绝根本原因，吸取接受的教训。例如在框架里面做预防，凡是value为null不查数据库。
2.实际情况：
偶尔出了问题，后来又好了，但是去查日志，确实是有异常的。但是无论如何都复现不了。
应对策略：（多加日志，善于报警，事前预防，便于事后分析）
三、部分CaseStudy实例
由于顺手将expireTime的的类型由Integer改为Long导致的问题。最终导致白名单读取失败，拦截正常用户3434个；黑名单读取失败放过作弊用户。
由于流量组更换了数据源，在信息不对称的情况下仅仅更改了几个文字，重新上线后导致tatooine廊坊机器停止服务40分钟。
无法复现。线上流量过大，服务性能特别差。平时10ms左右，故障时间达到100ms～300ms，增加超时时间。导致队列堆积，导致报警。
追查问题：1.监控没有做到位，业务方反馈得到的消息。2.最后没有查处问题具体原因，但是上线了定时压测系统，把系统的服务做高了。
四.结尾总结
1.相关建议
上线前充分测试，上线后确认功能正常
上线服务前增加充足的监控
不要操作线上机器，数据
服务器的处理能力准备一些冗余
解决问题必须彻底，完美
可能踩坑的地方一定会踩到，有可能犯错的地方一定会犯错。（墨菲定律）
不要把问题都留给QA，自己应该养成review的好习惯。
2.减少事故损失的一些办法
立即回滚代码
服务的部署尽量独立和隔离
做好服务降级备案
上线避开高峰期或选择灰度发布
重大上线做好回滚预案，添加足够监控
好的业务实现设计，多思考各种异常情况下的程序处理方式，对外部系统错误的良好应对，有效的正常或异常日志
3.讲师的体会
问题追查!=追究责任
更重要的是从中吸取到的教训和问题的总结和改进
一些问题如果反复出现，一定要重视，不可以忍受
后续改进要落实！避免问题再次发生。