可觀測度、問題、解決策

發佈於:

面對一個複雜系統,有能夠一覽全貌的觀測系統實為重要。於是有了許多關於「可觀測度」(Observability)的討論。(這個字是否能榮登年度最難發音之王座?)

開發團隊覺得這系統「似乎有些問題,總是有些不順的地方」,但又無法將問題清楚的定義出來。一方面,缺乏了能佐證問題存在之資料,另一方面,也缺乏了能佐證問題不存在之資料。缺乏資料,就無法將問題定義清楚,缺乏問題之定義,就無法討論解決方案。

所謂缺乏資料,換言之就是缺乏記錄與蒐集。備妥了記錄系統之後,要留什麼樣的紀錄比較好?

這就直接回到系統之設計目的了。如果這系統設計出來,是為了讓使用者下訂單,那麼訂單之建立便是該被記錄下來的事件。如果這系統是為了發送通知,那發送之成功與失敗,都是該被紀錄下來的事件。也就是說,在達到「最終目的」之時,留個紀錄就好。

如此一來,只要注意終端數字的變化,就可以判斷出系統整體是否「健康」。如果最終端不健康,亦能向前回溯,根據上游數字變化找出病灶。

至少,開始蒐集這種紀錄之後,記錄之「缺乏」本身就可被視為是一種問題。也是個很明確能開始著手解決的事項。

然而,在找出病灶之處之後,為了要能準確找出病因,提供修正,亦需要不同層級的紀錄資料。

像是,處理單一事項是否花去太多時間?是否在某處發生錯誤?是內部問題還是外部問題?是否最近的變更有關?與最近何時何處的變更有關?

這種種的「經常性嫌犯」列舉不完,為了能讓偵錯更容、更順利,開發團隊總之在各資料處理的終端之處,再度加入許多紀錄點。紀錄量大幅增加了,但也將使系統整體更容易被觀測。

將系統觀測度弄高了、各處數字上了儀表板後,團隊總算能知其所知,知其所不知。

這時產品負責人丟出一句:「好了,現在我們把工具做好了,總算可以來開始解決問題了!」

(完)