一、系統不可能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團隊和產品研發團隊目標一致，都是在保障業務服務可靠性需求的同時儘可能地加快功能上線速度。這個改動雖小，意義卻很大。一次“生產事故”不再是一件壞事，而僅僅是創新流程中一個不可避免的環節，兩個團隊透過協作共同管理它。