最近接連有多個意外事故在臺灣發生,在變故頻傳的狀況下,主事單位除了設法補救,更重要的是,須善用各種技術來及早得知問題。像是:臺北捷運板南線新埔站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能發揮作用的關鍵,或許也是我們在各個領域都能安身立命的重大基礎。

專欄作者


熱門新聞

Advertisement