基于失败设计

面对系统发生错误时会将经验作为催化剂来识别具体的故障（故障状态），进行因果推理、评估；系统出了问题不可怕，可怕的是以后还会出现类似的问题，这就比较尴尬了，不能将问题“釜底抽薪”，刨根问底，研究透，并有相应措施应对，那么这个系统也就废了。基于我们平台，从发现问题，解决问题，预防问题来侧面理解下“失败设计”。

从技术层面

从平台平常出现的bug，无论大小，我们大多数都是看着问题先解决，有的解决起来快，有的可能需要花费些时间，但最终我们都解决了，心里长舒一口气，有时候内心也许还会冒出“爷真机智，这问题都解决了”。可是然后呢？接着解决下一个问题，可是如果我们每天或者每周都记录下我们遇到的问题，然后在固定的时候，自己总结下，或许收获真的不少。

就拿这次上线的问题来说，一个发送邮件的服务突然爆了，每分钟不停的发邮件（在此之前，还出现过一晚上十几万封邮件的发出，结果直接导致公司邮件服务崩溃，整个公司邮箱不能用了，此刻本人很崩溃，那时候也认真思考过）。这次又发生这样的问题，就不得重新认真思考后续发布上线，怎么预防类似问题重复发生了。

小小记录下。。。。。。

转载于:https://www.cnblogs.com/levcon/p/10588278.html