全球藍畫面災難帶來的五大教訓

作為產品管理專業人員,我受過訓練以了解客戶的痛點,尤其是那些因軟體品質不佳而面臨系統停機挑戰的客戶。不過,上週五我親身體驗到這個問題,當時我抵達希斯路機場時,發現微軟的系統中斷導致全球航班被迫停飛。我從倫敦出發的航班僅延誤了幾個小時,但轉機航班則完全取消。由於那是當天前往我家鄉的最後一班航班,我不得不找間旅館住宿,但機場30英里範圍內的所有房間都已經訂滿。所有這一切的根源,竟是一個不比本文大多少的小檔案中的錯誤,影響了全球數百萬人。

大多數軟體發佈版本都包含缺陷。我從未見過生產環境的程式碼沒有任何問題,尤其是企業級應用程式。釋出到生產環境的發現通常是美化或影響較少使用功能的小錯誤。然而,像導致航空公司停飛的那類缺陷,卻是另一回事。現在,我們有必要思考這起事件能學到什麼教訓。

第一課:右移測試(Shift Right)已經不再是選項。右移測試的概念是,你應該在發佈後於生產環境進行測試。我們不禁懷疑,上週的系統中斷事件是否進行了這種測試。即使在預先發佈環境執行了測試,你也無法確定預先發佈環境與生產環境完全相同。你至少必須在生產環境進行簡易測試。更好的做法是定期執行回歸測試。即使在生產環境測試,僅測試單一流程或元件也可能不夠。這帶出了下一個教訓。

第二課:整合測試和端到端系統測試是必須的。如今,大多數企業級應用程式都是由複雜的互連服務和系統所組成。每個服務單獨運作時都可能正常無誤,但當你將它們全部整合測試時,你可能會發現這裡稍微延遲一點、那裡稍微延遲一點,就足以破壞整個端到端流程。這些與時間相關的問題會在異常高的使用量下加劇,這就是下一個教訓。

第三課:效能和負載測試也很重要。在正常情況下,效能和負載測試可能看起來不太重要,但在從系統中斷中恢復時,通常會有大量使用者試圖趕上被延遲的工作。這可能被視為級聯效應,但有些企業在每月和每季結束時,往往也會遇到類似情況。

在上週的事件中,大量取消的航班導致航空公司預訂系統的使用量激增。一個可能未受實際錯誤影響的系統,卻因異常的活動量而受到影響。負載測試並非易事,而且可能無需定期執行,但你不應等到災難來臨時才發現,使用量超過平均水準20%就會讓系統無法使用。

第四課:你不需要一次對所有人發佈。有兩個概念可以幫助防止全球性的系統癱瘓。第一個是「自食其果」(Dogfooding),即在對外發佈前先自己使用自家軟體。這樣一來,如果有重大問題,你就能快速發現並將災情限制在自家公司內部。

第二個概念叫做「金絲雀發佈」(Canary Releases)。就像礦工過去會帶著金絲雀進入煤礦以警示有毒氣體一樣,你也可以先將程式碼發佈給少數外部使用者一段時間,確保發佈版本在組織外也能正常運作。再次強調,你可以將負面影響限制在最小範圍內。

第五課:系統停機的成本會產生級聯效應。不僅生產力在停機期間遭受損失,還會引發多米諾骨牌效應。例如,訂單系統停機可能會影響到庫存管理系統,進而延遲出貨並影響營收和獲利。收入和利潤的損失可能會導致股東和客戶背離。

生產力損失會被加班趕工的需求所加劇。對於按小時計酬的工人來說,這是公司的直接成本。對於薪資員工,如開發人員和測試人員,這意味著工作滿意度下降,以及與家人相處時間減少。IT人員流失率升高也是一項成本。

客戶滿意度下降是另一項與系統停機無直接關聯的間接成本。即使你的競爭對手也受到同一事件的影響,但你的客戶可能不知情。他們只知道當天搭乘的是你們的航班。

下次你在協商測試工具和資源的預算時,請記住不僅有顯著的停機成本,還有許多間接成本。有時我認為,測試工具和人員的成本應該被歸類為保險成本,因為它們確實是一種保險。雖然錯誤極少會導致系統停機,但我們一直在忍受它們。我們的客戶也一直在忍受。直到有一天,它讓你應接不暇。

別等到痛苦難以承受時才採取行動。投資於人力、流程和工具,以確保你永遠不會陷入必須解釋為什麼一個小小的檔案錯誤竟影響全球的處境。