我們要給犯錯以空間，充分考慮錯誤預算。否則，開發團隊可能會在嘗試新功能時過于謹慎，抑制產品的增長。不過作為一般經驗法則， SLO 應該比你在 SLA 中詳細說明的內容更嚴格。

在一開始啟動 SLO 的時候，你可能沒有辦法確定當前系統整體的情況，所以我會建議從一個較低的 SLO 目標開始，根據團隊整體的成熟度逐漸提升 SLO 的目標。設定這個目標需要考慮產品的性質、團隊的優先級以及最終用戶的期望，然后不斷進行動態調整。例如，你的團隊持續大幅超越目標，你可能希望收緊這些值，或者加大開發力度來利用未使用的錯誤預算；但是如果團隊一直未能實現目標，那么把它們降到更容易實現的水平，或投入更多時間來穩定產品可能就是明智之舉。

保持耐心，你的團隊可能需要一段時間才能找到跟蹤和維持 SLO 目標的訣竅。如果改變沒有在一夜之間發生，不要氣餒。請繼續和你的團隊討論這些工具和概念，嘗試各種想法，朝著更好的監控和可靠性目標進發。這里具體包括：與利益相關者開會，努力就可靠性標準達成一致；對 SLO 進行優先級排序，收集一個月的 SLI 數據并進行分析和調整，等等。就像軟件迭代一樣，SLO 的建設也是個逐步完善的過程。

在定義 SLO 目標時，建議不要設置過多的 SLO 或使 SLI 過于復雜。比如說，你可能會為一個用戶使用產品的關鍵旅程中的每個相關集群、主機或組件設置單獨的 SLI，但這樣做不如嘗試以有意義的方式將它們聚合為單個 SLI，然后花更多時間關注那些真正影響最終用戶使用體驗 SLI。這有助于消除很多“噪音”，讓你專注于真正重要的事情。

面向最終用戶體驗和性能的指標才是合格的 SLI。比如說你的應用軟件后端是一個高可用集群，如果集群有一個節點出現問題，但卻并不會影響用戶正常的使用，這時候這個節點的故障就不適合作為 SLI。當然，并不是說這個故障節點就完全不用理會了，我們也應該設置相關的監控和告警，在出現問題的時候及時修復。否則如果再有節點出現問題，就可能讓用戶無法使用產品服務了，這就影響到 SLO 了。

總體而言，系統的可靠性并不是我們的監控和日志來決定的，而是由我們產品的最終用戶說了算。你編寫的代碼和設計的系統都是為你的用戶服務的。畢竟，如果我們構建了一個沒人使用的東西，那么我們最好把時間和精力花在其他事情上。

可靠性是所有系統最重要的要求，因為它是用戶信任的基礎。如果用戶不信任系統，他們就不會使用它，很快我們的系統就會沒有用戶了。換句話說，即使產品和服務提供了更多的新功能，如果它們不可靠，也就不會被信任，就會無人關注。

此文章為3月Day12?學習筆記，內容來源于極客時間《深入淺出可觀測性》，推薦該課程。

總結

以上是生活随笔為你收集整理的SLO 和 SLI的最佳实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。