logo头像

Edward.K Thinking

(學習DevOps系列 9) DevOps的監控與反饋一環

監控,這個環節其實在DevOps似乎很少被討論,但是,這一塊其實是非常需要被注重的一環。談到監控,不外乎就是確保系統穩定性或是確認系統是否有出問題,不過,要能在DevOps的監控一環中得到效益,就是必須要持續學習。透過Fail First做到快速學習錯誤,進而改善,如果,只知道問題發生,但卻無法從問題中持續學習,就無法讓團隊持續前進。


從現有的敏捷開發法當中,所有的方法改進模式都是必須透過觀察或是監控和學習來進行調整與實踐。Scrum中提到inspect and adapt principle,精實開發中提到build-measure-learn feedback loop,在看板中提到feedback loops。不管哪一種方式,所有共通點都在於反饋。任何開發方式中,不可能達到可以做出一套完美的系統,會有錯誤是必然的,且在組織推進的過程中,也一定會犯錯。而反饋則是確保找到錯誤以及修正錯誤的最有效方式。況且除了所謂大家強調軟體開發外,更因該關注開發後整串的局面。從DevOps週期的監控和反饋,讓我們在可以在這循環裡快速且持續的到反饋並修正團隊。


現在開發的系統是越來越複雜,而在企業中,開發的系統只會持續增加並不會減少。再加上雲端運算的發展,很多系統已經不是單純只在雲端或是地端,已經是分散在雲和地的兩端,這樣開始讓系統變得相對複雜化,因此,無論系統架構變得多複雜,越早機會去發現錯誤和修改錯誤,是非常重要的,所以,就必須透過監控來取得相對應數據或是蒐集現象,確保可以快速反應。在學習和反饋的循環中,可以實踐幾個目標

  • 品質
  • 可靠性
  • 安全
  • 為使用者提供價值

價值流


軟體開發過程並非只是單一透過一個開發者完成,在整個開發過程中,其實包含許多步驟和許多不同角色的人參與。所以,價值流是一個不同階段的生態鏈。其中,在這鏈中,唯一不變的就是反饋,這過程中,不同角色的都會獲得反饋,只是反饋的類型有所不同而已。在需求建立期間,有使用者或是商業價值的聲音,甚至有市場調查的意見等等。開發過程中,會有佈署、測試、效能等等的反饋資訊,其目的都是為了持續交付價值給使用者。上線之後,快速得到應用程式執行的狀況,使用者遇到錯誤,維運者是否可以提供反饋,讓系統操作順利等等。

監控與反饋


越來越多組織開始採用敏捷開發或是實施DevOps,並且開始縮短系統發布週期,進而快速交付給使用者。而這種頻繁變更應用程序以及交付功能並不是為了滿足開發人員的利益。而是為了滿足商業和使用者的需求,避免失去使用者或是讓使用者使用競爭對手產品。因此,大家就開始想要頻繁的發布,雖然,頻繁的發布可以降低商業風險或是IT風險。但是,也可能因為會造成一些錯誤或是傷害,導致不穩定的問題發生。下面有幾種機制可以降地開發過程中發生這類問題產生,或是在佈署上線後能夠快速檢測出來


DevOps四個週期循環

  • Plan:需求確認、工作計畫,並決定如何執行計畫
  • 開發與測試:團隊通常在不斷的迭代中,將想法變成功能,在開發過程中,透過持續整合和自動化測試,或是團隊的其他方式進行相關驗證
  • 發布:所有測試通過且佈署到每個測試環境中,直到確認可以發布到正式環境才結束
  • 監控與學習:了解使用者如何使用系統,系統如何反應、解決問題或是發生Bug,透過數據分析來進行下一次迭代的改進

一旦系統被發佈到正式環境中,我們就必須要去監控它品質,無論開發人員對於自己的程式碼有多大的信心不出錯。一般來說正式環境的資料量與複雜度一定都比測試環境大好幾個級別。伴隨者數據大小不同,數據的多樣性也會是一個影響因子。而系統負載不同,使用者的操作環境和素質不同,和網路狀態的差異性,都會讓代碼無預警的崩潰。因此,在監控一環中,我們因該針對問題、效能變化、系統容量和系統被使用方式,去進行設置監控點。透過這種多面向,取得強大的反饋循環,提拱給使用者更好的價值。

遙測


在DevOps作監控,一定會聽過遙測這個名詞。做這件事主要目標在於是要了解應用程式是否有發揮效用,不僅要從系統角度來看,還要從最終用戶的角度來看,這期間不僅要注重系統運行狀況,是否有系統有正確執行它該執行的事情,是否有出現錯誤或是意外,對於用戶有甚麼影響。也要從用戶使用系統方式去知道UI的問題,是否有功能沒被使用以及需要額外那些新功能。這些都必須透過數據去佐證。透過蒐集資料,不僅可以分析系統運行狀況,或是當前運行的健康狀況。還能分析歷史趨勢圖。例如:分析發布前一版和這一版的效能差異,是否有改進或是更遭。通常一個系統設定一些指標,並從指標找出一些錯誤,其實是會有效益的。透過遙測方式,也可以隨時提醒開發者問題是否發生了。另外,在需求中,我們都會提到Stakeholders,那麼在這監控一環中,誰會是扮演Stakeholders,一般人或許會認為是開發者,其實不然,只要在這開發過程中有參與的人員都是Stakeholders,每個角色都可以從遙測資訊中獲益。

Hypothesis-Driven


軟體開發往往是包含許多未知數和不確定因子,這絕對是正常的。在製造產業中,這些因子數又可以說特別多。通常使用者的需求,往往都不是它們真正想要的功能(雖然,有很多理論或是方式去找出真正的用戶需求,但依舊不能很精準找到),這也是敏捷式開發盛行的原因,因為透過這樣方式,可以降低開發出錯誤東西的風險。當反饋週期變短,就可以快速反應用戶下一階段想要做甚麼,而錯誤的發生被修復的成本也越低。在於假設驅動一環中,其定義如下:

  • 定義一個可以被測試的功能
  • 可以被更改
  • 可以進行測量

而進行Hypothesis-Driven的重要的是做到下列幾點

  • 建立指標
  • 定義成功與失敗標準
  • 運行多種實驗

此外,這種方式不僅僅是為了商業假設,探索需求,它可以也運用在一些非商業需求的。像是效能假設。Hypothesis-driven development是一種很廣泛的名詞,其中,精實創業的方法論就是它的縮影。

上一篇