講風險評估前，我們先來聊聊一個軟體服務維運(Ops)常會聽到的詞：

叫做服務級別協定，簡稱SLA(Service-Level Agreement)。

SLA通常被用在產品是SaaS(Software-as-a-Service)軟體服務類型的公司

文言文的意思是：「軟體產品上線後的服務可用性的等級是多少？」

白話文來說是：「一年之中，客戶有多少時間比例是可以正常使用我們的產品？」

如果提到SLA，老闆通常會從3個9開始講起，而3個9的意思就是99.9%

所以一年之中，客戶有99.9%的時間都要能正常使用產品，才算是達到3個9的SLA

SLA的計算方法

所以只要知道目標是99.9%的產品正常時間(uptime)，就可以知道我們容許多少錯誤

也就是產品可以有多少的下線時間(downtime)，比如說停機維護或是緊急維修等等。

簡單的算法如下

一年 = 365天 = 8760小時

99.9% SLA 的停機時間 => (100-99.9)% * 8760小時 = 8.76小時

也就是說一年之中只要停機時間小於8.76小時，那產品就算達到3個9的SLA。

經過計算，4個9就是一年之中，產品只能有52分35秒無法使用的時間。

當然也有5個9，甚至是6個9，有興趣可以到這裡看每個SLA等級所需uptime

SLA的實際情況

但實際上，這些SLA標準都不容易達到，即使是3個9，一年只能下線8.76小時

除非開發團隊在產品設計之初就做好no-downtime的架構規劃

以及負責產品運維的團隊，能夠熟練運用產品部署的配套機制(ex: data migration)

否則比較常見或是說早期開發的後端架構，都會停機維護以確保升級沒有問題

小一點的服務一次可能也要1~2小時，大一點的產品需要花到4~8個小時都很正常

所以可能一年只能預定維護個幾次，3個9的SLA品質保證就沒辦法達標

更不用說是緊急維護或臨時需要修一個嚴重的bug所做的維護。

所以999等級以上的SLA，一般來說都會以商業軟體服務為主，消費者軟體服務較少

原因是商業使用的軟體如果是跟業務直接相關，一定會要求較穩定的運行狀態，

對於軟體品質的需求也會比較高，不希望常常當機或是軟體升級出問題。

而SLA我自己覺得是一個很吃運氣的標準，更具體來說是個遠大的夢想（？）

但一個正面的影響是，團隊大家都會想朝著這樣的產品可用性標準去努力

RD持續想辦法去改善產品部署的方法，QA持續減少可能需要停機維護的巨大Bug

在這個過程中，SLA成為了一個可以量化產品品質的數字

不論這個數字是從70到85，或是從95成長到99，都是一個明確且可見的進步。

這篇的開頭有提到一個字叫做Ops

下一篇來粗淺的提一下DevOps這個buzzword(?)

以及開發人員(Dev)與維運人員(Ops)的差別與各自的目標