iT邦幫忙

2021 iThome 鐵人賽

DAY 15
0
IT管理

邁向Tech Leader的成長之路系列 第 15

14. 為何歸咎於human error不是個好作法?

前言

這篇是個非常general的議題,關於從錯誤中學習,適合所有的工程師看。如果你常遇到工作上把意外怪罪為人為失誤的話,特別可以看看,對於這些人為失誤的意外,我們如何從中學習。

P.S. 這篇所有的演講資料都可以從講者的github上找到:learning from incidents

演講總結

演講想探討的問題是:我們如何從意外事故(incident)中學習?與從意外中學習的正確姿勢。

為何要從意外中學習?

簡單的回答是:「因為我們想避免意外發生。」但我們真的有辦法100%避免意外嗎?

講者表示「對於我們使用的複雜系統們,沒有100%不會出錯的」。原因是因為系統的運作永遠都與人為操作有關,沒有系統是不需要人為介入的。與其說人在操作系統(on system),不如說人其實是系統的一部分(in system)。

所以重點其實不在於避免所有意外發生,更多是我們要衡量災難本身帶來的影響,與我們是否能夠承擔災難帶來的後果。在公司裡常常會有的狀況是,我們花了很大的心力去避免意外產生,但是卻導致我們操作越來越複雜或越來越難管理。

常見謬誤

上面說了因為人是系統的一部分,所以人所用的語言去描述意外本身,也會大幅影響我們對意外的看法,進而影響我們能從意外中學到的事情。

所以下面列出四個常見的意外檢討的謬誤:

  1. 歸因於人為操作失誤(Attribution to "human error")

    「人為操作失誤」往往是個標籤,讓我們停止研究意外,因為大家會想說既然是人為操作失誤那就無法避免了。

    但事實是,人當然會犯錯,但系統設計、組織、個人因素與天時地利都有可能影響到人犯錯。所以往往在意外發生當下,人不會覺得自己是犯錯的。

    所以當我們聽到「人為操作失誤」,我們更應該深入探討問題而非就此打住。

  2. 反事實的討論(Counterfactual reasoning)

    人們往往會在討論中出現類似這樣的言論:「如果當初...那應該就可以避免問題」「...沒有做...所以...」。但討論「沒發生的事情」無法真正解決問題,我們應該聚焦在「發生的事實」上。

    所以你不該說「這bug沒在testing中偵測到」,而應該說「這個bug要怎麼樣才能在testing中被偵測到?」

  3. 標準的語言(Normative language)

    事後諸葛總是最容易的,我們往往會從結果來看當初應該做的最佳決定為何,但是當你是做決定的人時,你哪知道哪個是最佳決定= =。

    所以我們其實應該多問決策者,事發當下有哪些現象與環境來幫助他做出這個決定。

  4. 機械問題的討論(Mechanistic reasoning)

    我們在尋找系統問題時,往往會去找到底是哪個元件(component)有問題。一旦發現沒有component有問題我們就停止尋找問題了。但了解元件的問題不足以了解意外的全貌。

面對意外該如何學習?

接下來要講講如何從意外中學習,此處的細節可以從作者的github repo看到。

這裡是站在一個協調者(facilitator)的角度來看這件事,而不是管理者的角度。而這個協調者不能是利益關係人,才能保持中立。(這裡有個Debriefing Facilitation Guide,可以參考如何當個好的協調者。)

  1. 事後檢討(post-incident review)

    我們常常叫意外處理者或負責人自己寫incident report,但這其實這是不足的。

    最好是舉辦一個一個小時左右的post-incident review,大家一起來還原事件發生當下的狀況。記住,重點不是要找出「正確的作法」而是還原當下情境。

  2. 問正確的問題

    不要問why而是問how,因為問Why會讓別人覺得被究責。而每個事件參與者對事件都有不同的體驗,專注於理解這些體驗與分享經驗,而非決定哪些是「正確的」。

  3. 詢問事情要如何才不會出錯

    當蒐集完與理解既有的事實之後,嘗試去想需要哪些跡象、工具、技巧是可以幫助人做好決定的。因為做出不恰當的決策通常是因為資訊量不足,所以協調者的工作就是要找出中間資訊量的差異,並看用哪些方式可以彌補中間的隔閡。

  4. 分開Review與Planning會議

    Review指的是事件回顧,而Planning指的是討論下一步與修正錯誤的討論。

    一方面是兩者的目標不同,所以可以讓兩個會議分別專注在How與Next step上。也有更多時間可以沈澱找出更好的改進方向。

    而Planning的會議就就不需要牽扯太多人,可以盡量的短跟快速就好。

    另外Review會議最好是不要manager來參加,因為可能會害意外負責人噤聲。而Planning會議就是manager可以參加的。

講者也說到,當然做這件事情的成本蠻高,大家不見得會願意花時間在這件事上面。因此可以先從找那些有趣,且不那麼重大的意外中開始練習做起,等大家對這個方式建立自信之後再慢慢的rollout出去。

個人心得

在聽這篇演講的時候,我完全就想到電影《薩利機長:哈德遜奇蹟》的情節。故事中主角機師Sully駕駛的飛機因為引擎故障,而導致他必須迫降飛機在河上,雖然被喻為英雄的拯救了所有乘客,但也被調查人員指責說做了不恰當的決定。調查委員會認為整件事是機師的疏失,因為他當下有更好的選擇可以迫降在另一個機場,並且就模擬結果來說也是辦得到的。但Sully表示那是不切實際的,因為模擬人員是在已知要如何反應的狀況下操作,但對他來說卻是要花時間來回檢查與做出決定才能得出當下的結論。

整個故事儼然就是這篇演講的精隨:我們不該用結果去反推當下要做什麼決定才是正確的,因為往往當事者在做決定的時候是沒有足夠的訊息的。與其事後諸葛給出「最佳解答」,不如去還原現場與思考從資訊不足的情況如何找到解答,才會真正的獲得進步。

預防問題的成本效益

另外演講裡有提到:我們往往會為了阻止某個問題的發生,而複雜化我們的流程。並不是說不該阻止問題發生,更重要的是我們要去評估「我們在阻止問題發生上所需要花費的精力」與「事情真的發生要修正他花費的精力」是不是成比例的。

之前就有過Ops(operators)因為不太信任我們的系統,所以提出需求希望我們多產一兩個report來讓他們做交叉比對資料正確性。可以理解他們的初衷,但是產report的effort其實很大,加上又會多一件事要來maintain,對他們來說也需要多出人力來檢查,更重要的是,產生report的部份基本上一年來也沒有壞過...,如果真的要做那就是為了做而做的而已。這就是「花費力氣避免問題產生」的效益與「出問題的影響」不成比例。

追根究柢真的好嗎?

雖然這篇演講是在講述追根究柢的必要性,但我並不認同所有事情都必須要找到root cause。原因是因為資源是有限,無論是人或時間或精力都是。

相信各位工程師們都有慘痛debug經驗,大部分時候寫feature其實不難,難的是debug或找出問題所在。很多時候我們尋找問題的root cause所花費的時間已經遠遠大於問題產生的可能性了,那我們還應該繼續查下去嗎?例如說每個月會有十幾個訂單會有奇怪的行為發生,而我已經花了兩天的時間尋找了各式各樣的log跟看了code但是都找不到問題,是否還有必要繼續花時間下去?

我自己覺得這一切都跟資源分配與成本效益有關,你花月多的時間在這個bug上你的邊際效益就越低。當然如果是個嚴重的問題絕對是必須要查出來的,但是大部分狀況下問題其實並不是那麼的嚴重,所以要謹慎考慮是否要繼續投資時間下去查出問題根源。

批判性思考與意外的全局性

演講也提到:知道出問題的元件在哪並不代表你知道意外的全貌。

在公司裡之前就會出現一些奇葩的狀況是,線上有個bug,而我們為了快速修正所以生了一個report來去讓OPs(operators)去手動修正這些數字。相安無事過了一陣子後,某天你接到一個request說這個report沒考慮到某個狀況要把特殊狀況考慮進來。來來回回幾次之後發現原本只是workaround(=暫時解決某個問題的應變方法)的report,卻變成正式的report了,OPs還甚至多花了個人力去做這件事。但實際上應該要做的是:修正原本的bug阿RRRR,如果沒有這個bug的話根本就不用這些report了。

我們花了一堆心力去東補西補某個系統會產生的毛病,但是卻沒想過本身這個系統的設計就是造成這些問題的根本。所以竊記不要看到一點病徵就嘗試解決他,確認已經了解事情的全貌再去討論下一步。


上一篇
13. 克服團隊的摩擦力
下一篇
15. 做對事是不夠的,你還必須要有影響力。
系列文
邁向Tech Leader的成長之路30

尚未有邦友留言

立即登入留言