对我负责的平台服务的反思

我负责的这个平台服务，是今年5月份从离职的同事手中接手过来的，这个服务之前由一个团队负责，也算是稳定运行了很多年了。

交接过程由于各种原因显得很匆忙，我当时也没有把这个系统全部搞清楚，接手后不久由于服务故障也导致了一次线上事故。

由于我对代码很多不熟悉的地方，当时故障恢复的很慢，最终是自己在线上做代码调试才找到了问题的原因，整个故障恢复时间达到了1天之久。

故障的核心原因，是由于系统架构方面存在一个很严重的问题，想彻底修复需要一定的开发工作量，且还有一些别的原因导致开发上线存在很大的风险性，总之我当时没有选择去修复这个问题，这也为这次的事故埋下了隐患。

为了让服务稳定，我当时确定的方案，是一个长期的系统改造方案，顺利完成的话，即可以修复现有系统的多方面问题，还可以从中学到很多东西，提升自己的技术能力，所以就决定这样做了。

事实证明，由于开发周期较长，中间各种事情的骚扰，导致新系统迟迟无法完成，旧系统最终再次出现问题，导致了这第二次的事故。

随着对旧系统的了解越来越多，这次事故后，我最终想到了几个解决旧系统稳定性的方案：

上面这两部分改造，大致经过不到1周的深入思考和1周多的开发部署，目前已经接近完成，正在灰度上线中，相信可以极大的提升系统的稳定性。

那么问题来了，这个方案也是我想到的，思考和实施的时间并不算长，如果今年第一次事故后就想到这个方案，然后做了，那岂会有第二次的事故呢？当时没有想到和没有这样做的原因是什么呢？

下面是自我批评：

我自己对编码有着很高的热情，对自己不认可的系统实现，通常是零容忍的。

也正是因为这样，所以当时我了解了这个系统的现有问题后，从心底里设计的改造方案，就是个推倒重建的方案，压根儿就没想别的，甚至于对现有代码的关注也很少，系统没有发现的问题，自己也不去关心了。

我想，这是个心态的问题，说的直白点，纯属自命不凡。在这种心态的驱使下，自然无法想到更好的解决方案。另外，旧系统跑了这么多年，公司这么多业务在用，自然有它的可取之处，由于我对它的排斥，也让我对它的优点视而不见，没有很好的去思考作者的思路，自身提升自然有限。

我在公司做事，自身是有需求的，但更重要的是，我需要明确我所承担的责任，当所做的事情不能很好履行自己的责任时，要好好想想自己做的究竟是不是对的，或是说，是否合适，不合适的话，是否有更好的解决方案。

我想，这也说明自己做事情还非常的不成熟。

先简单说下旧系统现存的一个最终要的问题：如果集群中的一台机器宕机，服务受损，恢复受损部分需要集群整体重启。

所以我当时一个心态是：赌我开发完成新系统替换旧系统期间，机器不会宕机。

我这些年执行过很多冒险的策略，正所谓非常时期非常手段，我自己本身对这种做事方法是认可的，但是，这次我没有把握好度。

回想之前成功的那些，我自己通常都能完全cover住所有风险，这也是因为我对系统的了解程度非常的高，所以对风险的预期，出问题的把控做的很好。

但这次，由于我的心态问题，导致我对这个系统的了解程度太低了，无法conver住这个风险。另外，一个长期的开发计划，期间会因为各种各样的原因导致服务未能按时完工，无形中风险被无限放大。

这样想来，出事应该还算老天对我的眷顾，给我个当头棒喝，否则我只会沉浸在自己的小世界中无法自拔。

对业务的反思

业务不是我负责的，所以具体情况我并不完全清楚。

我之前也负责过公司重要部门的重要业务，当时也是因为做的还算好，几乎没有出现过重大事故，所以才能有机会调到现在的部门，负责公司重要的平台型业务。

我想当时我负责的重要业务，之所以没有出现过重大事故，很重要的一个原因，就是无论我使用任何一个外部提供的服务，都不会信任它，把它作为生命线服务。如果是强需要，那么也一定会考虑好当它出现问题时的降级方案，不光纯粹从技术上去考虑，也会从产品层面去考虑这个问题。

今年的事故，也多次暴露了这个问题的重要性，如果我将来还会参与重要项目的开发，这一点是一定要坚持的。

总结一下，首先自己的心态很重要，这个会决定了自己的判断；其次，成熟的做事方法，找到最重要的事情去做；最后，千万不要相信别人告诉你它的东西有多么多么的好，自己觉得自己的东西重要的话，那就要自己想好退路。

我不奢望自己能一次性改正所有问题，但求能不断反思，不断进步！