那麼，我們今天就來談談到底 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 表示每次發生錯誤時造成的影響會更小。
所以朝著這兩個方向努力便是提高可靠性的思考方向，然而造成故障的原因有很多，具體有哪些是可以嘗試改善的呢？我想這對於每個專案來說可能會有些許的差異，以 NOJ 在這些時間運作的情況來看，主要的故障成因包括：
關於以上兩點，學校停電這部分就我們現有的資源來說無法完美的避免，也就是說就 MTBF 來看，他不是們可以掌控的因素，學校停電就得關機（當然如果可以轉移到 Azure 等雲端服務可以避免這類型的問題，可是我們沒錢 
）。然而若是在 MTTR 這方面，卻是有可以著手改善的空間，因為目前還是需要我們自己在電力回來的時候手動把 server 打開並開啟服務，若是可以在復電後自動開機或是重啟服務，都會比起手動操作來得有效率，有效提高可靠性。
然而天有不測風雲，有時候可能會發生像是乖乖過期之類的一些意料之外的狀況，就算原本有準備一些自動復原的手法也沒辦法正確的執行，這時候還需要架設監控的系統，替我們定期檢查服務的發育有沒有正常，啊不對，是有沒有在正常運作，並且在發生無法自動化處理的狀況時發出警報通知相關人員。
而關於程式本身的 bug 導致服務沒有辦法正常運作的情形，只要不更新程式碼，就不會有 bug 了。
(source: meme generator)
沒啦，開玩笑的。比較合理的策略可以分成兩個方面來看，第一個是要預防 bug 在部屬到生產環境之後才被發現，所以在對專案做出任何變更的時候，我們應當要確保這些變更都有做過足夠的測試，才將他合進 main branch。
而有關於測試的設計，我想網路上應該已經有不少相關的討論了，這邊就只提一點，那就是測試要盡量可以自動化執行，因為人在長期執行重複的動作時難免會出錯，可能會導致測試的結果不正確，意外將 bug 引進 main branch，所以有自動化的測試很重要。完整的測試可以有效地降低錯誤發生的機率，也就是說可以提升 MTBF。
另外一個部份是事後的補救機制，當 bug 已經發生，我們需要花多少時間讓服務恢復到可用的狀態？把 bug 修掉當然是個方式，然而我們很難評估一個 bug 需要花多少時間去修復，更好的選擇是先將版本倒退回上個可以正常運作的版本，這個操作通常來說相對比較容易。
以 NOJ 來說，我們部署的流程應該足夠簡單（一個 shell script），然而在發現錯誤的部分卻做得不夠好，這邊我想可以改善的流程有兩點：
今天簡單的介紹了 SRE 是什麼，並且提及了兩個重要的概念。
自動化可以有效地節省人力，並且降低因人為的失誤而造成的錯誤，讓我們有精力將時間花在改善流程上面。
監控可以在服務上線之後，幫助我們確認服務是否正常，並且在需要的時候主動通知相關人員，避免我們是在錯誤發生一段時間之後才發現，爭取更多修復的時間。
iThome鐵人賽
看影片追技術