一、系統不可能100%可靠
系統不可能100%可靠，人都不可能100%健康，更何況我們人類創造的系統？所以，任何軟體系統都不應該一味地追求 100%可靠，事實證明，可靠性超過一定值后，再提高可靠性對于一項服務來說，結果可能會更差而不是更好！極端的可靠性會帶來成本的大幅提升：比如過分追求穩定性限制了新功能的開發速度和產品交付速度，并且很大程度地增加了投資成本和運維成本，
二、管理風險
不可靠的系統會影響產品的信譽，雖然系統不可能100%可靠，但我們也要減少系統出故障的幾率，然而，經驗表明，可靠性進一步提升的成本并不是線性增加的：可靠性的下一個改進可能比之前的改進成本增加100倍，基于以上矛盾點，SRE的做法是管理風險，目標是：我們會努力提高一項服務的可靠性，但不會超過該服務需要的可靠性，管理風險旨在尋求快速創新和系統可靠性的平衡，而不是簡單地將可靠性最大化，
三、度量風險
SRE的做法是通過一個客觀的指標來體現一個系統的可靠性（或者是風險），對于大多數服務而言，最直接的能夠代表風險承受能力的指標就是對于計劃外停機時間的可接受水平，對于系統而言，這個指標通常是基于系統正常運行時間比例的計算得出的，
可用性=系統正常運行時間/（系統正常運行時間+停機時間）
使用這個公式，我們可以計算出一年內可接受的停機時間，從而可以使可用性達到預期目標，舉例來說，一個可用性目標為99.99%的系統最多在一年中停機52.56分鐘，就可以達到預計的可用性目標，當然，并不是所有的系統或者組件適用于這個公式，比如也可以通過請求成功率來定義服務可用性，具體如何度量還要結合實際情況靈活應對，
四、確定服務可靠性目標
如果 100% 不是一個正確的可靠性目標，那么多少才是呢?這其實并不是一個技術問題而是一個產品問題，要回答這個問題，必須考慮以下幾個方面:
- 基于用戶的使用習慣，服務可靠性要達到什么程度用戶才會滿意?
- 如果這項服務的可靠程度不夠，用戶是否有其他的替代選擇?
- 服務的可靠程度是否會影響用戶對這項服務的使用模式?
為了建立起一個合理的可靠性目標，SRE必須與產品負責人一起努力，將一組商業目標轉化為明確的可以實作的工程目標，在實踐中，這種轉化說起來容易做起來難，SAAS層軟體和IAAS層基礎設施轉化的方式又各不相同，
五、錯誤預算
SRE和產品負責人必須對每個系統建立起一個合理的可靠性目標，一旦建立，“錯誤預算”就是“1-可靠性目標”，如果一個服務的可靠性目標是99.99%,那么錯誤預算就是0.01%，這意味著產品研發部門和SRE部門可以在這個范圍內將這個預算用于新功能上線或者產品的創新等任何事情，
錯誤預算可以用于什么范疇呢?研發團隊需要用這個預算上線新功能，吸引新用戶，理想情況下，我們應該使用錯誤預算來最大化新功能上線的速度，同時保障服務質量，這個基本模型建立起來之后，許多常見的戰術策略，例如灰度發布、AB測驗等手段就全說得通了，這些戰術性手段都是為了更合理地使用整個服務的錯誤預算，
SRE通過引進“錯誤預算”的概念，解決了研發團隊和 SRE 團隊之間的組織架構沖突，SRE 團隊的目標不再是“零事故運行”，SRE團隊和產品研發團隊目標一致，都是在保障業務服務可靠性需求的同時盡可能地加快功能上線速度，這個改動雖小，意義卻很大，一次“生產事故”不再是一件壞事，而僅僅是創新流程中一個不可避免的環節，兩個團隊通過協作共同管理它，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/552837.html
標籤：其他
上一篇：更專業省心的來了，你沒必要研究UE4和Unity官方推流了！
下一篇：返回列表