可觀測度、問題、解決策

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

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

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

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

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

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

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

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

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

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

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

（完）