「『You build it, you run it.』這個緊密的回饋迴路能保證一個人的決策後果會回到本人身上」——《Vibe Coding 聖經》

你有沒有被別人寫的程式碼給激怒過？

明明是別人寫的糞Code，造成 Production 環境異常，但卻是你在半夜三點被告警吵醒去收拾善後。

更令人生氣的是，抓出當事人後，還得到一句「可是在我的電腦上是好的啊？」

同樣的，你是否曾經被自己寫的程式碼給氣到？

同樣是 Production 出現異常，正想大罵是誰寫的程式碼，然後打開 git blame 一看，就默默把 git blame 的視窗關掉。

上面兩種情境，剛好是最佳的對照組，讓我們知道「回饋迴路」的重要性。

當人們不需要為自己的決策後果承擔責任時，那麼他多半會一再犯下同樣的錯誤。

於是就發生了 Dev 與 Ops 對立的狀況；

Dev 只負責把程式碼丟過去，剩下都是 Ops 的責任，這種不負責任的互動，當然只會讓兩邊的隔閡越來越深。

同時，欠缺「回饋迴路」也意味著知識的斷裂。

Dev 永遠不知道自己的程式在真實環境中長什麼樣子。

Ops 永遠無法理解為什麼程式要這樣設計。

於是兩邊都像是瞎子，在黑暗中協作。

實踐 DevOps 的其中一種方式即是「You build it, you run it.」，打破 Dev 與 Ops 中間那道牆，建立回饋迴路讓團隊可以共同知曉決策的後果，並進行改善。

你的軟體開發交付流程中有足夠的回饋迴路嗎？

當 Production 出狀況時，是 Dev 或 Ops 的責任？還是 Dev + Ops 整個團隊的責任？