最近出了2次故障，回过头来还是有多地方值得思考的，简单总结下避免以后再出类似的问题。
除了这2次产生资损的故障，之前还出过几次线上问题。
出现的几个问题中，蛋疼的是有2个都是重复出现过的问题。
有一个规律是欠的债迟早要还的，尤其是技术债。。。
之前出的某一个问题，如果没有彻底解决，势必会在未来的某个时间点再次爆发，不是不抱，时候未到。有时候可能想懒那么一下，想节省一点时间，或者去忙其他事情，后面可能会花更多的时间来处理线上问题。所以技术债还是越早处理越好，或者说压根就不要留技术债。
业务迭代关乎一个团队的产出和吞吐量，当然不可否认系统设计的合理性和健壮性也非常重要，系统的稳定性也至关重要，技术债欠的越多就会在未来的某个时间点爆发。因此在设计开发维护阶段都尽量避免不合理的设计，避免留下技术债，需要投入更多的精力做好系统的稳定性，监控报警是否完善，核心链路是否有兜底降级。
比如说我们要面向失败做设计，充分考虑各种失败的场景，链路中有哪些薄弱的地方，可能会容易出问题的地方。稳定性的理念有很多，避免单点故障、多活、限流熔断、兜底降级、备好预案等等。
千万不要依赖任何的口头约定，千万不要信任上下游，假设没有这些约定，就假设上下游就是会疯狂搞你，看看你的系统还会不会正常run。
还有就是要明确一个事实，程序员不可能写出没有bug的代码，线上也永远不可能不出问题，所以出问题不可怕，可怕的是出了问题发现不了，想想如果一个隐藏的bug每分钟导致损失1快币，时间久了也很恐怖，短时间可能不痛不痒，长时间的话细思恐极。。。这里也充分体现出监控报警的重要性了。
只有系统的稳定性够好，没有欠下技术债，才能支持系统更稳定、更快速、更持久的迭代。
往往当我们说等下次再优化，等后面有空再搞，其实就已经很危险了～
说点什么
您将是第一位评论人！