口水记

今天和朋友聊天，他说，今天出了一个事故，由于以前的一个设计问题，今天在线上操作了某个需要消耗服务器和数据库大量资源的动作（称为a操作吧），暴露出了设计和性能的问题，导致接口的后续响应超时，从而出现了线上问题。

听了朋友的全程描述，我精简一下导致出现问题的原因：

• 当初数据库未考虑到后续功能的一个迭代，导致业务实现复杂，每一次操作a都需要大量的资源
• 在几个月前，有想过优化，但是由于业务等原因，搁置了
• 当初和操作人约定过不在白天高峰期操作，但是随着人员的流动，口头约定并没有交接

事故已经发生，无法避免，那么我先让我朋友先将事故产生的脏数据进行处理

然后再总结一下事故

事故总结至少应该包含以下几点

• 事故导致的现象
• 责任人
• 产生的原因
• 优化方案
• 后续如何避免

关于前面所说的三个原因，在这里，我分别讲一下方案，当然，我也是给我朋友的建议，不一定是最好的，所以欢迎大家来提出更好的建议

关于设计的一个缺陷，导致a操作需要大量的资源，那么这种情况首先应该考虑的是去重构，改进设计，而不是其他边边角角的优化，很简单，这个设计缺陷不改动，一旦随着后续业务迭代，人员流动，出现致命的宕机才想改动时，这个代价，实在是太大了。

其次，在当时如果真的是业务很忙，来不及，那么很简单，给a操作限流&

文章来源: chenhx.blog.csdn.net，作者：谙忆，版权归原作者所有，如需转载，请联系作者。

原文链接：chenhx.blog.csdn.net/article/details/107025830