知道在哪裡畫x的價值(一)

幾年前曾經有這麼一個故事被到處轉寄:

====================================

有一個工程師在一家公司工作30年後退休了,
他對該公司的機器及產品瞭如指掌。
幾年後,該公司的一套機器故障,
全公司的人都沒法找出問題來。
絕望中,他們只好找這位退休工程師。

這位工程師看了一個小時之後,
工程師從上衣口袋拿出一枝粉筆,
用粉筆在一個零件上畫了一個大叉叉。
公司把零件換了,機器操作正常。
但是不久公司收到一張十萬元的帳單,
是這位退休工程師的收費。
公司老闆火大了,
認為一個小時不值這麼多錢,就要求送一張明細表。

這位退休工程師的回函是:

粉筆        $ 1
知道在哪裡畫粉筆  $ 99,999

======================================

這個故事我大概前後收到有十幾次,  只是不知道轉寄的人有沒有認真想過其中涵義?

聖帕來襲那天傍晚, 我接到公司值班人員的電話通知, 收到某台db主機的警告訊息, 但是從監控系統看來主機還是活著的. 這台db是網站的後台, 當時我也沒想太多, 只當是颱風天上網的人多所以發出些抱怨訊息, 這種事情常見. 如果是一般人頂多回一句[知道了]就把這事丟到腦後吧, 不過我個人是一定會去花點時間去檢查相關log, 這是工作習慣.

檢查的結果, 我發現這台主機的cpu是吃滿的, 上面跑了許多的oracle process, 這代表這台db處在high loading狀態, 大部分資源都消耗在oracle上, 也表示沒有其他東西有問題, 簡單說系統是正常的. 我打電話根負責這db的dba討論一下, 說出我的看法是db connection數到達上限, dba給我的訊息也證實這個想法. 於是我把這台主機所有人從睡夢中挖醒, 跟他說明情形, 並請他注意, 因為一般來說晚上的loading還會更高(不同公司的人). 本來以為事情到此結束, 沒想到15分鐘後這位仁兄call我說, server的connection並沒有滿, 我的猜測不對. 這麼一來倒是激起我的好奇心, 如果不是connection滿, 那cpu吃滿就不是結果, 而是原因, 可是在有限的connection數就能把一台有4顆cpu的sparc主機吃滿, 這絕對不是正常現象. 沒想到說出我的看法之後, 對方開始說出一大串話, 大意就是這問題存在兩個多月, 但是寫程式的人(這是第三家公司)完全不認為他們的東西有問題, 一口咬定是機器有問題, 網路有問題, db有問題. 反正千錯萬錯絶不會是他們的錯. 坦白說, 這種事情我聽得多了, 也沒啥感覺.

不過掛了電話之後想了一下又打了通電話給剛通話過的dba, 說服他把db的query  log打開好抓出是哪幾句sql語法吃掉大量cpu, 並把結果交給coder讓他們去做修改. 當然這中間又聽到抱怨coder寫的不好等等的話語. 事情安排好, 我就不再浪費精神去想這問題, 一切等颱風走後上班日再說.

廣告

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com 標誌

您的留言將使用 WordPress.com 帳號。 登出 /  變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 /  變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 /  變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 /  變更 )

w

連結到 %s