分享是最有效的学习方式。
从最近一个经历说起
周五了，轻松点儿，今天破例不写纯技术类的干货文了，聊聊最近一个比较郁闷的经历，这事儿发生在老猫自己身上，不是"总是遇到事故深陷于系统重构泥潭的倒霉小猫"，也不是苦苦面试找工作的"张小帅"（如果想要知道小猫和张小帅的故事，欢迎订阅专栏）。
春节假期即将结束，去了趟老丈人家拜了年，准备坐高铁回来的路上悲剧斜跨背包丢了，现金、银行卡、驾照、身份证、最爱的文玩串串、耳机等等都没了。细节就不多聊了，越想越心痛。证件现金等等都可以不论，尤其是盘了多年的文玩串串，之前一天刚在朋友圈嘚瑟，结果第二天就给丢了，真的是后悔懊恼万分。
当意识到事情发生之后，大脑一片空白，口干舌燥，着急万分，因为距离高铁发车还有40分钟的时间，在这个时间段内要找到，简直就是痴人说梦。于是草率下定决心，要是监控调不出来就不走了，一定要找到，当时冲动之后也就只有这一个想法......后来媳妇的一句话让我冷静了下来，"事情都发生了,着急有什么用，最多损失一个包，人都还在慌什么？"。是啊，遇到突发状况究竟在慌什么呢？做好最坏的打算去争取解决问题就行了。于是就有了下面这样的流程。
事儿已经发生了，现在也已过去多日，老猫觉得上述的决策可能不是最好，但是大家都安全返程了，并且没有耽误上学和工作，这是最好的。当然这是老猫遇到的"生活Bug"。
这件事情算是翻篇了，虽然最近还是在挂失办理各种证件，但是这个事情发生之后，老猫还是以程序员的角度去复盘了这么一个事情，如果我们日常工作中遇到突发困难，对应的我们又该是如何去做呢？
一点小小的经验总结，和大家分享一下。
面对问题的基本认知
~看着自己的麻烦，清楚地知道，是你，就是你自己，而非他人所致。这真是件痛苦的事情------------索福克勒斯《埃阿斯》~
当我们接手一个系统之后，很多时候往往也会躺枪，就像小猫那样,【前开发在代码里下毒】。
我们很多时候会去抱怨，就像老猫丢包发生之后就在抱怨，如果不吃那个丈母娘煮的鸡蛋就不会肚子疼，不会肚子疼就不会想上厕所也就不会丢包了，所以归根到底还是得怪丈母娘煮的那个鸡蛋。
相信我们大部分人在发现是别人的Bug导致事故的时候，也同样会费时费力地把责任推到罪魁祸首身上。在一些工作场所，这是文化的一部分，而且可能有助于宣泄。
但是在技术领域，我们还是得把精力集中到解决问题上，而不是归咎于他人。
Bug是我们的错还是别人的错无关紧要，无论谁的错，问题还是得有当前系统负责人的我们来解决。
不要恐慌
人们很容易陷入恐慌，比如刚意识到丢包的老猫也是一样。在工作中，或者在问题发生之后，或者是最后期限逼近，老板和客户站在背后"死亡凝视"的时候，我们其实不能把注意力过度转移到老板和客户身上。亦或者说，在此期间我们不能把注意力过度放到结果所造成的影响上，因为事情已经发生了。如果注意力转移了，那么期间，我们花费解决问题的时间可能就会更久，或者直接就搞不定，因为心态已经崩了。
不应病急乱投医，错上加错
老猫试想了如果当时一时冲动，选择留在高铁站查一天监控，最终也还是一无所获，不仅耽误了几天上班的时间，而且还耽误证件补办的时间，如果错过最好的挂失时间，可能还会被盗刷，简直是"赔了夫人又折兵"。
写到这里，让老猫又想到多年前经历的一次支付事故。由于疏忽将第三方支付工具的回调状态&符号写成了||,造成了资损。当时心里想着的是尽快找到问题，并且解决掉，不能再造成更大的资损了。然而匆匆忙忙中找到的问题大部分是错误的，在二次订正想要修复问题的时候，被领导给制止了。
事后才发现，领导是对的，我匆匆赶工修复的方案也是存在一定的问题。事情已经发生了。在万无一失的方案还没有出来之前就不要去碰现状系统了。因为慌慌张张地改造修复往往只会给现有的错误系统带来更多的"熵"。
所以当事情发生之后，冷静地去分析去思考，去衡量解决方案的利弊和得失，能够从最坏的角度去分析并且制定出有效挽回损失的方案才是最明智的选择。
复盘从而避免二次踩坑
经历了这事儿以后，老猫也是被深刻地教育了，"今后出门就别带钱包了，顶多带个身份证就够了，互联网的世界，手机在到处都能搞定。也别背那么多串串了，选一串能套手上戴着的就行"。看，这就是事故复盘的魅力。
老猫在写这篇文章的过程中其实就是在复盘，在这里老猫的收货可能是锻炼了自己的分析问题，定位问题的能力，并制定有效的解决方案，培养透过现象看本质的思维方式。
日常工作中也是一样，出了事故不可怕，可怕的是同样的事故，出了多次。所以复盘的核心价值就是让犯过的错误不再重犯，不在同一个地方反复跌倒。对于软件系统体系而言复盘故障能够帮助深挖问题的根因，找到目前稳定性的薄弱环节，并进行系统化的分析，从而变成未来提升优化动作的抓手。
总结
以上就是老猫由一次"生活事故"引发的一系列的对于日常工作的思考，如果有其他看法的小伙伴也欢迎留言。