iT邦幫忙

2021 iThome 鐵人賽

DAY 2
1
DevOps

這個 site 就是遜啦 - SRE 30 天登大人之旅系列 第 2

Day 2:什麼是 SRE

那麼,我們今天就來談談到底 SRE 是什麼,以及他如何在軟體的生命週期發揮作用吧。

SRE 的由來

SRE,全稱為 Site Reliability Engineering,臺灣通常譯為「網站可靠性工程」,而相對應的職位,自然就是 Site Reliability Engineer,縮寫亦為 SRE。這個概念最早被 google 的 Ben Treynor 在 2003 年所提出的,基本上是期望可以透過軟體工程的手法解決日益複雜的維運問題,透過開發各種自動化工具輔助,解決那些重複且繁瑣的流程,將人力解放出來投入在開發上,以提供更可靠的軟體以及更快的迭代速度。

可靠性

可靠性的高低,取決於服務不可用的時間長短,當不可存取的時間越短,則服務的可靠性就越高,通常來說,我們會以「可用時間」的比率來量化它,例如 99% 就代表在一年之中,至多有 3.65 天無法存取服務是被允許的。

影響可靠性的因素有很多,其中幾個重要的指標包括 MTBF(平均故障間隔時間,Mean Time Between Failure)和 MTTR(平均修復時間,Mean Time To Repair),這兩項指標非常直接的影響服務的可靠性,越高的 MTBF 表示故障的頻率越低,而越低的 MTTR 表示每次發生錯誤時造成的影響會更小。

以 Normal OJ 為例

所以朝著這兩個方向努力便是提高可靠性的思考方向,然而造成故障的原因有很多,具體有哪些是可以嘗試改善的呢?我想這對於每個專案來說可能會有些許的差異,以 NOJ 在這些時間運作的情況來看,主要的故障成因包括:

  • 學校停電:因為我們的 server 放在學校,所以每當學校停電時,整個網站便無法存取了。
  • 程式邏輯錯誤:就是 bug 啦,因為種種原因而被佈署到 server 上,可能進而導致使用者無法存取服務。

關於以上兩點,學校停電這部分就我們現有的資源來說無法完美的避免,也就是說就 MTBF 來看,他不是們可以掌控的因素,學校停電就得關機(當然如果可以轉移到 Azure 等雲端服務可以避免這類型的問題,可是我們沒錢 /images/emoticon/emoticon02.gif)。然而若是在 MTTR 這方面,卻是有可以著手改善的空間,因為目前還是需要我們自己在電力回來的時候手動把 server 打開並開啟服務,若是可以在復電後自動開機或是重啟服務,都會比起手動操作來得有效率,有效提高可靠性。

然而天有不測風雲,有時候可能會發生像是乖乖過期之類的一些意料之外的狀況,就算原本有準備一些自動復原的手法也沒辦法正確的執行,這時候還需要架設監控的系統,替我們定期檢查服務的發育有沒有正常,啊不對,是有沒有在正常運作,並且在發生無法自動化處理的狀況時發出警報通知相關人員。

而關於程式本身的 bug 導致服務沒有辦法正常運作的情形,只要不更新程式碼,就不會有 bug 了。

(source: meme generator)

沒啦,開玩笑的。比較合理的策略可以分成兩個方面來看,第一個是要預防 bug 在部屬到生產環境之後才被發現,所以在對專案做出任何變更的時候,我們應當要確保這些變更都有做過足夠的測試,才將他合進 main branch。

而有關於測試的設計,我想網路上應該已經有不少相關的討論了,這邊就只提一點,那就是測試要盡量可以自動化執行,因為人在長期執行重複的動作時難免會出錯,可能會導致測試的結果不正確,意外將 bug 引進 main branch,所以有自動化的測試很重要。完整的測試可以有效地降低錯誤發生的機率,也就是說可以提升 MTBF。

另外一個部份是事後的補救機制,當 bug 已經發生,我們需要花多少時間讓服務恢復到可用的狀態?把 bug 修掉當然是個方式,然而我們很難評估一個 bug 需要花多少時間去修復,更好的選擇是先將版本倒退回上個可以正常運作的版本,這個操作通常來說相對比較容易。

以 NOJ 來說,我們部署的流程應該足夠簡單(一個 shell script),然而在發現錯誤的部分卻做得不夠好,這邊我想可以改善的流程有兩點:

  1. 檢測服務是否正常:以往出現問題,往往是修課的同學在使用上遇到一些問題跟我們回報過後,才會開始處理。若是有個自動化的流程可以檢查生產環境是否正常的話,就可以更早的發現問題。
  2. 紀錄可以正常運作的版本:在發生問題之後,我們需要退回到上一個版本,然而目前我們對於「上一個可以正常運作的版本」並沒有紀錄,所以說這部分還需要手動找到可以運作的版本,若是有紀錄下來的話,那們自動退版也就會變得比較容易實現了。

小結

今天簡單的介紹了 SRE 是什麼,並且提及了兩個重要的概念。

自動化

自動化可以有效地節省人力,並且降低因人為的失誤而造成的錯誤,讓我們有精力將時間花在改善流程上面。

監控

監控可以在服務上線之後,幫助我們確認服務是否正常,並且在需要的時候主動通知相關人員,避免我們是在錯誤發生一段時間之後才發現,爭取更多修復的時間。

參考資料


上一篇
Day 1:前言
下一篇
Day 3:讓我看看你狀態正不正常啊 - 架設 status page
系列文
這個 site 就是遜啦 - SRE 30 天登大人之旅30

尚未有邦友留言

立即登入留言