掌握狀態，需重新調整監控層面

最近接連有多個意外事故在臺灣發生，在變故頻傳的狀況下，主事單位除了設法補救，更重要的是，須善用各種技術來及早得知問題。像是：臺北捷運板南線新埔站11日出現電扶梯失速，異常原因據稱是煞車迴路異常，以及扶梯齒輪箱的外齒盤軸向位移，馬達動力無法傳遞，造成向下滑動；桃園近期發生多次工廠、倉儲火警，如10日永光化工公司廠房建物燃燒，美福倉儲也延燒多日，直到16日仍有殘火，家樂福物流中心14日發生火警。

高雄大社區、燕巢區15日發生2千戶停電，原因是有鳥碰觸到帶電設備，有網友譏諷鳥變笨了，台電解釋若是鳥站在同一條電線因為無電位差，所以不會觸電，但如果鳥的位置是在電桿上方，因為有其他相關設備而產生電位差，就會觸電，線路也會啟動保護動作而跳脫，因此影響周遭部分用戶停電。

除此之外，臺鐵這幾年事故頻傳。2021年4月太魯閣號在行駛過程中，撞上一臺邊坡滑落的工程車，造成49人死亡，兩百多人受傷。2020年11月底因連續豪雨造成邊坡滑動，瑞芳猴硐路段發生坍方，導致宜蘭線東西正線完全中斷，兩週後，恢復東正線單線通車，2021年2月3日完成雙線搶通。

實體環境如此，在數位環境、IT系統的日常維運過程當中，當然也有許多大大小小事故，於是，促使大家必須設法做好持續監控狀態的功夫。於是，我們看待這些工作的方式，可能也就分成幾種不同的觀點。一般而言，可以從服務等級（Service Level）來判斷，這樣的呈現形式也有賴於多種狀態的量測（Metrics），以及記錄（Log）。

然而，由於身處執行環境的差異與變化，如今對於需要監測的狀態項目，也需要注意這當中存在著已知（常見）、未知（罕見）的分別，因此，當我們關注如何提升整體的資訊透明度（Transparency），以及能見度（Visibility）的同時，近期，關於可觀測性（Observability）的討論，也越來越熱烈。

根據《Observability Engineering》一書所言，現今面臨多種IT創新典範轉移，像是敏捷開發、DevOps、SRE（網站可靠性工程）、雲端原生等熱門概念的導入，使得更多人需要去了解「可觀測性」這個議題。

書中提到採用新式概念開發的系統，可持續交付應用程式，固然帶來更高生產力與獲利，代價卻是管理成本的提升，因為抽象化的軟體系統搭配了動態控制手段之後，衍生新挑戰，像是面臨突發的複雜性處理（emergent complexity），以及非階層化的溝通模式──當前的雲端原生系統，雖然可以隨著需求暴增而進行快速的橫向擴展執行規模，但在運作上需搭配更進階的社會技術（sociotechnical）實務處理，可觀測性就是其中一種指標。相較之下，舊有的單體系統較少出現突發的複雜性處理狀況，因此，只需要簡單的監控方法，即可推論目前系統發生什麼事，以及出現未知問題的所在位置。

關於可觀測性的討論，在iT邦幫忙有篇《淺談DevOps & Observability》也有一些介紹，當中引用Real Kinetic公司的管理夥伴Tyler Treat的看法，也相當值得大家參考。他以取得資料、理解程度等兩個面向，來對應我們對於現況的4種認知狀況，包含：知道已知的狀態（Known Known），稱為事實；知道未知的狀態（Known Unknown），稱為假定（Hypothesis）；自己處於未知卻面對已知（Unknown Known），稱為假設（Assumption）；自己處於未知卻又面對未知（Unknown Unknown），稱為發現（Discovery）。

其中的Known Unknown，就是我們所熟悉的「監控」，後續對應的手段是測試，至於Unknown Unknown，則是我們現在關注的「可觀測性」，後續對應的手段是探索。

世事如棋，面對局面的變與不變，除了設法臨機因應，更重要的還是持續拓展「知」的領域，才能做出更好的對策，而這不僅是IT能發揮作用的關鍵，或許也是我們在各個領域都能安身立命的重大基礎。