安安週五大家好！時光飛逝，一轉眼就快放假了（誒？），這裡是今天讀的原文出處：Embracing Risk，那我們就開始吧！

本書其他章節探討的緊張關係源於產品研發小組和SRE小組不同的績效評估指標：

• 產品研發小組以研發速度評估績效，促使其快速編寫新代碼。
• SRE 小組以服務可靠性作為衡量標準，對頻繁的改動保持警惕。

這樣的訊息不對稱進一步加大了內部緊張關係。

這些緊張關係反映了不同團隊對工程實踐投入的看法。一些常見緊張狀況包括：

• 軟體對故障的容忍度：故障容忍度過低可能導致產品脆弱無用 vs 故障容忍度過高可能使產品失去用戶。
• 測試：缺乏測試可能出現嚴重故障 vs 過度測試可能錯失市場機會。
• 發佈頻率：發布頻率過高會提升故障風險 vs 發布頻率過低會使產品功能遲遲難以更新
• 金絲雀測試的持續時間和大小

在這些情況下，團隊通常會找到一個非正式的風險成本平衡。然而，這種平衡往往由工程師的談判能力決定，而不一定是最佳的。作為解決方案，我們應該定義一個雙方都認可的客觀指標，引導談判方向。據此，數據為基礎的決策通常更佳，這也就是「錯誤預算」誕生的主要原因！

後記

今天聊到了為什麼會需要「錯誤預算」，在不同部門之間的溝通中，難免帶有主觀的偏見，在意見無法達成共識時，可以數據為基礎來進行討論與決策！明天會接著聊錯誤預算要如何建立，以及有什麼好處，那就明天見啦！掰噗！