"问题根源"分析

Translate root cause "问题根源"分析

昨天读了老刘(Jonathan Lewis)的一篇时评文章,非常有趣,在征得老刘的同意后,在此翻译成中文.

http://jonathanlewis.wordpress.com/2008/09/26/root-cause/

标签: 架构, 解难, 幽默

现今有一些(计算机)行业的表达方式惹恼了我 - 不必有一个好的理由,仅仅因为听起来极端的自命不凡,并且被做市场的放到一起. (狂妄自大, moi !)

比如: "问题根源分析","整体全面方法" 等等 - 不过是重复在讲 "我们和别人解决问题的方法是一样的, 但要起一个好听的名字,使人们相信我们做的会更好,更有意义".

每当他们提供这些无价值东西的时候, 我总是喜欢用相反的观点来比较,看看会得到什么印象:

"我们采用全面整体方法" = "别人只看局部"

"我们重点放在问题根源分析上" = "别人不会发现真正的问题在哪里"

像这样, 只是换个说法, 没有任何额外价值. 你渐渐识破他的诡计和谎言.

不过, 我近期看了一篇有才气的问题根源分析. 他是这样开始的:

问题: "为什么我们开始 长时间等待 log file sync(同步写日志文件)?"
答案: "因为经济衰退, 笨蛋."

的确 - 这就是问题根源 (尽管我想引用 克林顿 1992年竞选宣言)

说说他的来龙去脉.

房价下滑(因为经济), 银行紧缩贷款(贷款多数是用来购买房地产)**.就是说他们放慢了贷款申请的处理速度.

贷款申请有四种状态: 新申请,在线处理,批准,拒绝. 突然间很多申请被滞留在"正在处理"状态.

办公室职员上班时间的多数工作集中在"正在处理"状态的申请, SQL 访问请求急剧增加, 使用更多的CPU. CPU负荷增长, 尽管(写)事务量没有变,写日志个数没有变, 日志文件同步的往返信号传输时间就会延长.

因此 - 当房价下滑, log file sync(日志同步)等待时间延长. 这就是所谓的根源分析.

脚注 - 这不是一个有关信息系统的准确描述, 但是经济变化可以影响数据库性能.

** 近期一份时代杂志指出, 银行相互竞争, 看谁能给出最低的交易.
大概因为他们不得不继续发放贷款, 在市场上继续生存, 而不愿被别人摘牌(收购).