经常有朋友问我，为什么你面对一些复杂的数据库故障，总是能游刃有余，抽丝剥茧地找到问题的关键，然后解决问题。而我也干了十多年DBA了，遇到没见过或者不熟悉的故障还是满头雾水呢?

确实我这些年遇到的疑难杂症之多，是一般DBA所无法比拟的。做DBA就像当医生，经验十分重要。就像前阵子有个搞医的朋友说，如果论起门诊的水平来，中国的医生要完爆欧美的医生，因为他们经历过的病历是他们的数十倍甚至上百倍。想要提高水平，丰富的临床经验肯定是十分关键的。

虽说如此，只是见过更多的案例是不够的，很多DBA对于 同类型的案例遇到过很多次，但是下回遇到了某个稍有不同的案例，也不一定能搞得定。除了接触各种各样的案例，还要善于总结才行。你可以通过读书、看文章去学习别人的分析思路，但是无法真正学习到别人的知识体系和思维体系。最终帮助你解决问题的是在自己的脑子里形成的自主化的知识体系和工作思路体系，因此要想提高分析问题的能力，加快分析问题的速度，必须不断完善自己的知识体系。

如何高质量、高效率地构建自己的知识体系呢?一般情况下我们通过读书、参加培训以及从别人那里学习这三种方式来学习。但是大家可能有一种感觉，那就是我在看书上的方法或者看 别人的案例的时候，好像都学会了，但是一旦自己独立来做，还是不得要领。

这是因为你学习了，但是没有融入自己的知识体系。融会贯通是其中的关键。要想融会贯通，除了多看书，多学习，多实践之外，还有一个很重要的事情就是多总结。总结是把非自我形成的知识，或者未体系化的知识有效融入自己的知识体系的最好的方法。很多朋友遇到过不少故障案例，但是因为不能及时总结，从而无法通过实践提升自己的能力。

总结自己经历过的案例是最好的总结，因为自己亲身参与，了解其中的细节，因此能够做最为完善的总结。不过总结案例不是一件简单的事情，如果你对某些技术和原理的问题不了解，那么总结案例也总结不好。

当我们在处理一些故障之后，需要认真思考一下这些故障可能产生的原因，并且不断地把我们总结出来的东西系统地记录下来。这种积累能力的不同也会导致相同工作年限的不同DBA之间出现很大的能力差异。

上面的这张图是前些年我总结的log File sync等待事件的分析路线。这张图不是一次性完成的，是在多年的工作实践中，不断遇到问题，不断进行修改后形成的，如果你不是经过一段时间的总结，哪怕一个经历过很多场景的专家，也不见得能一次性把它画出来。有些朋友很懒，做完一件事，自己脑子里过一下，觉得自己明白了就算了事了。实际上这样就错过了进一步提升自己能力的机会。

如果每次遇到类似问题后，都打开这个图看看，是不是能用图上的某个诊断路径来完全复盘这个案例，如果不能，那么就通过修改这张图，修正这张图上的错误只是，进一步完善这方面的知识。久而久之，你的技术能力提升，运维经验的积累就会超过身边的同事了。

如果每次遇到案例之后，都能动手把它记下来，那就更好了。写作是十分好的知识总结手段，在写的过程中，你会发现哪怕这个问题被很完美地解决了，但是你的分析过程中还是有很多无法连贯起来的细节。这些细节应该如何推理出来呢?如果你无法把这些问题想清楚，那么下回哪怕遇到同样的案例，可能缺少了某个灵光乍现而导致你无法完成同样的推理。而如果你把整个推理路径都想清楚了，并总结出来了，那么今后此类问题无论如何变化，都尽在你的掌握之中了。

我是当年在联想时学会这种方法的，那时候联想企业文化里有三句话：“把要做的事情想清楚，把想好的事情做出来，把做好的事情记下来”，这三句话让我受益终生。很多人都会做好前两句话，但是很少人会去做第三句话，现在想来，这是我能面对复杂问题的时候游刃有余的主要原因。