jim yeh on 十月 26th, 2009

這篇文章是投稿 ZDNet Taiwan 的文章原稿,由 ZDNet Taiwan 以〈如何在系統異常前發現錯誤?〉、〈如何在系統異常前發現錯誤?(下)〉兩篇文章刊登。文章原稿未經 ZDNet Taiwan 編輯,內容可能與 ZDNet Taiwan 約略有所不同。

前一陣子有兩個與資訊系統失常有關,而且眾所矚目的新聞事件,也就是戴爾電腦網路購物系統與台北捷運內湖線的系統異常。相信很多人都認為這兩個系統會發生系統異常相當離譜,在系統上線之後才發現系統無法正常運作,造成系統使用者的困擾,同時也會讓人對系統可靠度與穩定度失去信心,而增加系統的失敗成本。

雖然平心而論,想要事前預料系統可能發生的問題,並加以預防或因應其實並不容易,因為開發系統,尤其是軟體開發常會碰到事先難以預料的問題。但如果能在錯誤造成危害之前,就能夠發現問題並採取適當的行動來解決它,應該就能減少系統的失敗成本。因此,看到戴爾與台北捷運內湖線的重大系統異常,讓筆者想探討如何在系統失敗前發現錯誤,以避免系統失敗的巨大損失。

設計不夠好?

戴爾是世界知名的電腦直銷公司,擁有 13 年的網路直銷經驗。對於這種有豐富網路直銷經驗的公司來說,系統連續發生產品標價錯誤的問題,實在是一件令人感到不可思議的事情。在戴爾發生第二次標價錯誤事件之後,筆者聽到有一位工程師出身的朋友指出,戴爾筆記型電腦的標價錯誤,是因為他們的系統設計不良。他依據新聞的報導,對比自己的網站開發經驗,認為可以確定這絕對是設計的問題。研判是促銷資料沒有正確關連產品資料,才會發生這種錯誤。

從戴爾回應外界連續標價錯誤事件的說法,第一次錯誤定位為人為作業疏失,第二次錯誤是因為系統異常。這麼看來朋友的說法似乎有些道理,但從系統開發流程的角度來看,卻讓筆者產生一個疑問。如果是因為設計有問題,應該是可以在系統正式運行前被測試出來,但為什麼要直到錯誤釀成災禍才被使用者發現?朋友表示要做到完整測試系統是很困難的,還不如把系統設計做好,這樣系統自然不會出錯。

在觀念上,我同意朋友的說法,因為好的設計的確可以減少系統發生錯誤的機會。但問題是朋友的想法在實務上卻有操作上的困難。因為設計夠好是很難被清楚定義,尤其是在專案時程及資源有限的情況下,想要設計出可以在各種情況下適用的系統是非常困難的。面對系統運作環境與需求變化無常的情況下,設計通常只是一種權衡與取捨之道;沒有可以解決所有問題的最佳設計,只有針對解決重要問題的最適當設計。

如果我們不能定義出具體明確的系統問題,所謂的較好的設計也只不過對未來可能變化的假設所做的設計,但實際上未來的變化可能會出乎我們的意料之外。當我們對系統的假設不再成立時,就會產生系統可能發生異常的風險。因此,戴爾出現系統異常的原因,問題的關鍵可能並不在設計的好壞,而是沒有掌握好問題的複雜度;今天系統碰上比過去更複雜的問題,是當初設計系統之時所沒有想到的情境。

造成錯誤的原因

從筆者過去系統開發的經驗顯示,過去長期運作正常的系統,經常會因為運作環境發生變化,而使系統在現今發生功能失常。我想戴爾的情況應該也是類似的狀況,否則如果是設計有問題,就很難解釋為什麼過去運作正常的系統,會在今天出問題。如同商業周刊的評論「戴爾烏龍 在於沒換腦袋」所提到的:

戴爾系統無法偵錯的關鍵——戴爾仍以經營企業顧客的思維在做消費者生意,否則怎會沒把消費者異常下單行為納入管理流程?

戴爾成立以來都是以企業市場為重,占營收比重超過八成。直到二○○七年才進入消費市場,這是很大的突破,因為經營企業市場,客戶數量少,強調服務與產品穩定度,但經營消費市場,客戶數倍增,就必須靈活彈性。

但此次事件讓我們看到,即使經歷兩年,戴爾網路系統的「腦袋」還沒轉過來,管理階層也是一般。

從戴爾大中華區中小企業處許肇元的說法,我們也可以了解戴爾系統異常的問題。網路上有一篇 jeremy 寫的專訪中提到許肇元對短短 10 多天連續出了兩次錯誤的解釋:

「因為我們成長的速度太快,而系統並沒有配合我們的成長。像是我們的訂購流程,每個零組件都可以客製化,訂一台筆電的流程換算下來就幾十個關卡,每個關卡都跟價錢有關,牽一髮而動全身。這次事件中,我們真的學到很多,也重新檢視了我們的系統。」

這更讓人相信,問題的關鍵並非單純的系統單一功能失常,而是戴爾忽略了商業模式改變會對系統產生影響,而沒有做好事先預防與事後可以及時因應的準備。

由此可知,造成戴爾系統發生錯誤看起來並非出在各部分功能的問題,而是系統整體整合出現問題而造成系統異常。那麼台北捷運內湖線的系統異常是不是也是相同的問題?從相關新聞報導我們發現,系統發生錯誤的原因也是因為系統沒有整合好,內湖線無法順利整合木柵線舊有系統。這大概從決策當局決定採用規格無法統一的中運量的系統,以及冒險採用無線通訊新技術時就已經註定了這樣的結果。再加上測試時間不足,自然會使品質問題更加雪上加霜而惡化。

造成系統失敗的條件

如果戴爾電腦和台北捷運內湖線的系統異常,種種跡象都顯示是整合出現問題,那麼我們不禁要問:為什麼它們的整合都會出現問題呢?從筆者系統開發的經驗來看,我相信是因為系統整合牽涉的問題太多或是太複雜,使得開發者難以掌握。再加上人們在尚未意識到系統的複雜度之前,常會認為自己有能力解決所有的問題,但實際上他們想要這樣做卻做不到。一言以敝之,系統失敗的根源其實是來自於人性的弱點,雖然這個真相往往被硬體、作業系統或平台的功能失常所掩蔽。

More about 溫伯格的軟體管理學如同著名的軟體工程顧問溫伯格在《第一級評量》提到,造成軟體系統失敗的條件有八個 F,它是分別是弱點(Frailty)、愚蠢(Folly)、執迷不悟(Fatuousness)、好玩(Fun)、欺騙(Fraud)、狂熱(Fanaticism)、硬體功能失常(Failure)與運氣(Fate)。筆者發現這些造成失敗的條件,其實正是表現人性弱點的不同面向。

弱點

弱點是做想做的事卻做不到,它是軟體失敗的終極源頭。因為人不是完美的,他們做不到設計所要求的,不論那是一個程式設計,或是一個過程設計。溫伯格認為管理階層的責任是設計出一個程序以規範程式如何修改,承認自然界的事實,與確保程序本身被執行。而且他認為人們傾向在發生錯誤後懲罰嫌疑犯其實很不好,因為他會讓人隱藏錯誤、浪費時間在找嫌疑犯、以及分散注意力忽略管理階層的責任;建立並執行能及早找出失敗,並預防悲慘後果的程序。

愚蠢

愚蠢是做到想要做的事,但它卻是錯的事。愚蠢的基礎是無知,雖然它在當下沒有發生錯誤,卻會在以後造成錯誤。不過透過學習可以改善無知,進而將愚蠢矯正過來。溫伯格認為建立完整訓練師徒制、技術審查計劃、提供落實計劃的支援,是管理階層可以用來矯正愚蠢的職責。

執迷不悟

執迷不悟是指不肯學習,一直做出蠢事,一次又一次的做。此外,想要管理好一個愚蠢的人,卻不提供他根除愚蠢所需的訓練和經驗,這也算是一種執迷不悟的行為。溫伯格認為在軟體工程機構中,除了把執迷不悟的人送到其它行業去,否則沒有什麼防護措施可以抵擋執迷不悟的人。

好玩

好玩是程式設計師會寫一些奇怪的程式來為自己找樂子,溫伯格認為沒有人能夠預測別人認為好玩的事是什麼,因此好玩的心理是所有失敗的源頭中最危險的一個,因為它防不勝防。但管理者應該提供預防之道:一是開放透明的系統,另一個則是讓單單工作本身具有足夠的趣味。

欺騙

欺騙是用非法的方式從一個系統中獲取個人利益。溫伯格認為好玩是在失敗的源頭中,帶來的最小的損失。因為一個系統找樂子的方法有千百種,但值得一偷的東西卻沒多少。他認為軟體工程經理要好好閱讀以資訊系統詐騙為主題的文章,並採取一切可能的預防措施來防堵它。

狂熱

狂熱是試圖摧毀或瓦解一個系統,而原因不是為了個人利益,而是為了報復。溫伯格認為防範弱點而採取的行動中,多數也可以減少恐怖份子所造成的威脅與影響。

硬體功能失常

溫伯格提到硬體若不能造著當初設計的目的而執行工作,就會造成功能失常的現象,這類問題多半可以用軟體來克服。他認為當人們抱怨硬體造成他所寫的軟體出問題時,我們應該找出它表達的意思,以免遺漏這句話所帶來的重要資訊:

  1. 硬體沒什麼大不了的功能失常,但程式設計師需要找藉口來隱瞞一些事實。
  2. 硬體功能失常問題都在一般的預期範圍內,可能程式設計師沒有採取正確的防護措施。例如將程式碼或測試腳本做備份。
  3. 硬體功能失常,但沒做好硬體供應商關係的管理工作。
  4. 硬體功能失常是由人為錯誤所造成的,如使用者做出出乎意料的動作。

運氣

溫伯格指出運氣不好是多數表現不佳的經理愛用藉口,這不是事實。他建議當我們聽到一個經理老愛說運氣不好時,我們應該把運氣兩字換成經理,因為沒有不好的士兵,只有不好的軍官。

系統異常與人性弱點

從以上造成系統失敗的條件我們可以知道,系統發生異常的原因可能是系統的設計不夠好、硬體設備或作業系統出錯或是系統運作的環境太複雜了,但發生問題的真相卻都大部份是因為人性的弱點。因此,要在失敗前發現錯誤,進而採取行動防止系統失敗,重點管理好人性弱點,而非不承認它的存在,卻只在事後責備人們沒有盡到責任,但事實上最大的責任是管理階層沒有盡到管理的責任。

例如在台北捷運內湖線在 7/10 發生系統大當機的事件後,當外界質疑為什麼發生這麼嚴重的當機事件時,筆者注意到有一篇新聞報導提到市府官員有人表示「這個問題,80 % 是因為電腦中毒」言下之意系統異常多半是因為硬體的功能失常所致,而比較不可能是軟體的瑕疵或人為的錯誤。

溫伯格說過「對錯誤的直接觀察,本身並無意義,但是對『人們作何準備來面對錯誤的發生』的統合觀察就很有意義」那位市府官員的說辭,筆者相信只是為了隱瞞了一些事實,以免公布實情而讓損失更加擴大,然而這卻表現反應他們對面對系統錯誤發生的準備並不夠充分。

筆者再舉一位朋友的經驗為例,以前他們公司採用 .Net 開發平台開發新產品。由於他偏好 Java 的程式寫作慣例,加上當時微軟聲稱與 C# 整合不成問題,讓他很想用 J# 程式語言來開發系統。雖然他的同事擔心系統的整合會出現變數而反對,但由於他的堅持,管理階層還是照他的意思,讓他用 J# 開發他的程式,與其他同事以 C# 的程式來進行整合。

後來在整合時,他們發現碰到很多平台上及程式語言本身的問題。為了解決這些問題,他只好修改他的程式以處理這些問題,但也讓系統愈變愈複雜,結果使軟體問題層出不窮。但朋友仍然還是堅持要用他喜歡的方式開發系統,最後在管理階層無法忍受他的執迷不悟,並且在彼此無法達成共識的情況下,要求他離開了那家公司。

從這位朋友的故事中,我們看到他的弱點、愚蠢以及他和管理階層的執迷不悟。他的弱點是想實現他的設計理念並完成不同語言的整合,但後來卻發現這是個艱鉅的任務。在發現了專案時程及市場上的壓力並不允許他實現他的設計理想時,卻一再地堅持做自己想做的事而非應該做的事,這是愚蠢。而與管理階層之間一次又一次想要對方同意自己的觀點,卻又不去理性客觀地評估現實,而只是一廂情願地以為讓對方發現此路不通就會懸崖勒馬,這是他與管理階層的執迷不悟。

朋友的經歷並不是特例,在實際的系統開發專案中,筆者總是看到相同的故事正在持續上演。就像戴爾電腦、台北捷運內湖線發生系統異常的事件一樣,應該發揮效果的程序、流程與方法,在關鍵時刻竟然沒有發揮作用。筆者認為問題的關鍵是在於人性的弱點,我想只有在適當地管理好人性弱點之後,程序、流程與方法才能真正地落實,並且發揮出應有的效果吧。

管理的重要性

如果導致系統異常的關鍵是在於人性的弱點。那麼管理階層就應該負起管理人性弱點的責任,以避免專案因為人性弱點而造成系統異常的意外事件而慘遭失敗。從去年跨年夜發生的台灣大哥大行動電話用戶大當機的事件,又再一次地讓我們看到管理對避免系統異常而造成失敗的重要性。

去年跨年夜,台灣大哥大發生行動電話用戶大當機,經檢調查出是台灣諾基亞西門子公司離職工程師,涉嫌以女友名義登入台灣大資料庫並刪除資料造成大當機,檢方昨天將陳依妨害電腦使用罪嫌起訴。

筆者看到新聞提到那位工程師,否認是遭開除而挾怨報復,只說會這麼做是因為「好玩」。讓我想到溫伯格說的,好玩的心理是所有失敗源頭最危險的一個,因為沒有人可以預測到別人認為好玩的事是什麼。

當然,我想事件的真相應該不是因為那位工程師基於好玩的心理,而是被公司開除而心生報復。造成台灣大哥大系統當機的原因,固然是難以預料到的惡意破壞,但這並不代表這種系統失敗是無法防止的。筆者認為問題在管理上,因為管理階層忽視人性弱點,而沒有盡到管理者應盡的責任。

或許有人會認為筆者這樣說對管理者要求太多了,但如果系統開發團隊沒有紀律來把事情做好,這的確是管理者的問題。管理者設計或制定流程,目的是為了幫工程師把事做好,但如果流程不能落實,那是必然代表管理出現了問題,所以管理者必然難辭其咎。

好比說,為什麼離職員工可以用他離職前的帳號密碼來登入系統,然後做出一些危害系統的行為?又或者,為什麼會讓人興起想要破壞系統的動機,而身為負責系統成敗的高階管理者,為什麼會不去防範可能破壞系統的行為?

因此,即使可能是因為好玩,管理者也要思考如何降低人們為了找樂子而影響系統的動機。如前面所提到過的,讓員工的工作更有趣,同時讓流程更透明。此外,避免員工試圖摧毀或瓦解一個系統,不是為個人利益而是為了報復。管理者應加強防範弱點而採取的行動,因為它們多數也可以減少這種攻擊。

以上這些都是管理者的職責,以避免系統因為人為的疏忽而失敗。總而言之,預防系統失敗,管理最重要的工作就是認清「人的不完美」,才能知道如何管理人性,進而避免發生人為錯誤而造成意外,產生系統的重大損失。



     

One Response to “如何在系統失敗前發現錯誤”

  1. weskerjax 說道:

    事實的背後總是有一個愚蠢可笑的錯誤

Leave a Reply

You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="">