「如果你改善了開發吞吐量的一個要素，但在過程中卻降低了服務的穩定性，那麼你的改善是處於不平衡的方式」——《軟體架構指標：改善架構品質的案例研究》

部署的速度提升了三倍！

交付的頻率加快了兩倍！

那麼變更失敗率是跟著上升還是下降呢？

在實踐 DevOps 之後，我們都希望看到速度提升再提升。

不過只看其中一項指標其實是滿危險的一件事。

因為很可能你乍看起來開發得很快，快速交付一堆垃圾，實質上只是把風險與成本轉移到維運階段。

所以在知名的 DORA Metrics 可以發現，它不會只有單一面向的指標，必須同時從「快」（velocity）與「穩」（stability）不同的角度來評估實踐 DevOps 的成效。

而這同時也正是實踐 DevOps 困難之處，因為我們對於真正高效團隊的要求，是魚（快）與熊掌（穩）兩者皆得。

你們團隊的 DevOps 有同時帶來「快」與「穩」兩個面向的改善嗎？

你們是選擇先「穩」再「快」，還是先「快」再「穩」呢？