最近我负责的一个平台型服务遇到了故障，导致一个用到它的业务部门出现连锁反应，最终发生P0级（公司内部认定的最高级别）事故。
事故恢复后，我这边也做了一些措施可以有效防止再次发生类似的问题，搞定这些事情后，我觉得有必要踏下心来反思一下为什么会出现这个问题了。
对我负责的平台服务的反思
我负责的这个平台服务，是今年5月份从离职的同事手中接手过来的，这个服务之前由一个团队负责，也算是稳定运行了很多年了。
交接过程由于各种原因显得很匆忙，我当时也没有把这个系统全部搞清楚，接手后不久由于服务故障也导致了一次线上事故。
由于我对代码很多不熟悉的地方，当时故障恢复的很慢，最终是自己在线上做代码调试才找到了问题的原因，整个故障恢复时间达到了1天之久。
故障的核心原因，是由于系统架构方面存在一个很严重的问题，想彻底修复需要一定的开发工作量，且还有一些别的原因导致开发上线存在很大的风险性，总之我当时没有选择去修复这个问题，这也为这次的事故埋下了隐患。
为了让服务稳定，我当时确定的方案，是一个长期的系统改造方案，顺利完成的话，即可以修复现有系统的多方面问题，还可以从中学到很多东西，提升自己的技术能力，所以就决定这样做了。
事实证明，由于开发周期较长，中间各种事情的骚扰，导致新系统迟迟无法完成，旧系统最终再次出现问题，导致了这第二次的事故。
随着对旧系统的了解越来越多，这次事故后，我最终想到了几个解决旧系统稳定性的方案：
- 代码中做一些和旧系统风格不一致的编码，甚至有对出问题的重点业务的硬编码在里面，但可以做到快速有效解决重点业务的稳定性问题；
- 部署上也是，调整了接手前一直使用的旧方案，使用新方案替代，大大降低重点业务的风险。
上面这两部分改造，大致经过不到1周的深入思考和1周多的开发部署，目前已经接近完成，正在灰度上线中，相信可以极大的提升系统的稳定性。
那么问题来了，这个方案也是我想到的，思考和实施的时间并不算长，如果今年第一次事故后就想到这个方案，然后做了，那岂会有第二次的事故呢？当时没有想到和没有这样做的原因是什么呢？
下面是自我批评：
自大
我自己对编码有着很高的热情，对自己不认可的系统实现，通常是零容忍的。
也正是因为这样，所以当时我了解了这个系统的现有问题后，从心底里设计的改造方案，就是个推倒重建的方案，压根儿就没想别的，甚至于对现有代码的关注也很少，系统没有发现的问题，自己也不去关心了。
我想，这是个心态的问题，说的直白点，纯属自命不凡。在这种心态的驱使下，自然无法想到更好的解决方案。另外，旧系统跑了这么多年，公司这么多业务在用，自然有它的可取之处，由于我对它的排斥，也让我对它的优点视而不见，没有很好的去思考作者的思路，自身提升自然有限。
做事方法
我在公司做事，自身是有需求的，但更重要的是，我需要明确我所承担的责任，当所做的事情不能很好履行自己的责任时，要好好想想自己做的究竟是不是对的，或是说，是否合适，不合适的话，是否有更好的解决方案。
我想，这也说明自己做事情还非常的不成熟。
赌徒心理
先简单说下旧系统现存的一个最终要的问题：如果集群中的一台机器宕机，服务受损，恢复受损部分需要集群整体重启。
所以我当时一个心态是：赌我开发完成新系统替换旧系统期间，机器不会宕机。
我这些年执行过很多冒险的策略，正所谓非常时期非常手段，我自己本身对这种做事方法是认可的，但是，这次我没有把握好度。
回想之前成功的那些，我自己通常都能完全cover住所有风险，这也是因为我对系统的了解程度非常的高，所以对风险的预期，出问题的把控做的很好。
但这次，由于我的心态问题，导致我对这个系统的了解程度太低了，无法conver住这个风险。另外，一个长期的开发计划，期间会因为各种各样的原因导致服务未能按时完工，无形中风险被无限放大。
这样想来，出事应该还算老天对我的眷顾，给我个当头棒喝，否则我只会沉浸在自己的小世界中无法自拔。
对业务的反思
业务不是我负责的，所以具体情况我并不完全清楚。
我之前也负责过公司重要部门的重要业务，当时也是因为做的还算好，几乎没有出现过重大事故，所以才能有机会调到现在的部门，负责公司重要的平台型业务。
我想当时我负责的重要业务，之所以没有出现过重大事故，很重要的一个原因，就是无论我使用任何一个外部提供的服务，都不会信任它，把它作为生命线服务。如果是强需要，那么也一定会考虑好当它出现问题时的降级方案，不光纯粹从技术上去考虑，也会从产品层面去考虑这个问题。
今年的事故，也多次暴露了这个问题的重要性，如果我将来还会参与重要项目的开发，这一点是一定要坚持的。
总结
总结一下，首先自己的心态很重要，这个会决定了自己的判断；其次，成熟的做事方法，找到最重要的事情去做；最后，千万不要相信别人告诉你它的东西有多么多么的好，自己觉得自己的东西重要的话，那就要自己想好退路。
我不奢望自己能一次性改正所有问题，但求能不断反思，不断进步！
