此刻，您可能已經(jīng)充分地接納DevOps了，但您的同事可能還沒有。也許以下這些內容會對您有幫助：

根據(jù)Google DORA（ DevOps、Research與Assessment）團隊最新的《DevOps現(xiàn)狀》報告，在DevOps方面成效不佳的團隊很少能夠在6個月內將軟件投入生產(chǎn)運營。即便他們做到了，也會有16%-30%的失敗率，而且他們很可能需要長達六個月的前導時間來讓代碼投入生產(chǎn)運營。就算變更不那么頻繁，但某些事情發(fā)生變更帶來的風險相對較高，而下一次更新可能又需要6個月的時間。

與此相比，精英團隊的部署頻率要高出973倍（基本上可以每天都可以根據(jù)需要進行多次更新），從提交到部署的交付周期要快6570倍，從故障中恢復的時間更快，其變更失敗的可能性要低30%。

雖然上面的數(shù)據(jù)令人印象深刻，但可能仍然讓您感覺有點抽象。當您把失敗與美元價值關聯(lián)起來，那將會是什么感覺？

根據(jù)IT軟件質量聯(lián)盟（CISQ，Consortium for IT Software Quality ）2018年發(fā)布的報告，美國劣質軟件的總成本為2.84萬億美元。平均而言，每個失敗項目的成本大約是5000萬美元。即使是打折為十分之一，想想您是否真的能承受那么多錢的損失。

為什么推出高質量的軟件如此困難？人們普遍認為，是因為企業(yè)很難及時獲得并響應客戶的意見。敏捷開發(fā)流程和其它現(xiàn)代化開發(fā)方法旨在降低風險，但您企業(yè)的其他成員如何才能步調一致并以最快的速度交付價值呢？

答案就是——采用DevOps非常有益，而且應用越好收益越多！

您需要做什么？具體應該怎么做？

如果您具備DevOps的基本知識，您的團隊就有可能變得更加敏捷，更加協(xié)調一致。他們就能夠比以前更快地將更高質量的代碼推向生產(chǎn)第一線。這太好了！尤其是如果您在其中扮演了重要角色那就更值得慶賀！

但也有時候，這些改善帶來的實際收益不夠顯著，也有可能就是您的管理層需要調整期望值。這時候您就需要認真考慮下一步如何行動。

問題的關鍵在于您需要ROI方面的真憑實據(jù)。您可能會擔心，您的下一個步驟可能不會像在早期階段看到的那樣效果顯著。也就是說，您如何證明繼續(xù)改變可以加快DevOps的有效性呢？您可能會遇到以下一種或兩種情況：

需要克服慣性：這就是我所說的問題——“我們不就是按部就班做的嗎？”您對您的團隊說您想引入新的DevOps實踐，但他們已經(jīng)根據(jù)當前的實踐設計了工作流程。改變常常很難，尤其是當人們剛剛適應上次的改變之后。

管理層期望過高：誰沒有經(jīng)歷過這種情況呢？通常，高管層的期望都很高，有時他們似乎沒有真正意識到這項工作到底有多么復雜。創(chuàng)新的壓力接踵而至，而且一波比一波更緊迫。您能跟上節(jié)奏嗎？

解決上述這兩個問題——阻力和壓力——可以通過這種方式完成：確定“關注點”，同時找出您希望改變的一組指標。沒有人會說：“改變流程把軟件做得更糟糕些?！钡唵蔚卣f“讓它運行的更好、更快”并沒什么意義！

當考慮如何確定ROI的時候，或者為DevOps的投資尋找理由時，需要首先搞清楚哪些指標可以衡量，哪些指標不可以衡量。

大多數(shù)企業(yè)都可以確定解決客戶報告的一個缺陷需要多少錢。隨著自動化測試的增加，可以更快地發(fā)現(xiàn)缺陷，并以更低的成本修復缺陷。如果您可以將缺陷的數(shù)量減少5%-10%，這就是一個可衡量的價值。請注意，您的團隊中仍有人需要完成修復缺陷的工作，因此我們不會重復計算節(jié)省的費用。

有些好處卻很難衡量，但可能會隨著時間的推移而改變，值得追蹤。企業(yè)商譽就是一個很好的例子。衡量企業(yè)商譽有不同的方法。在風河公司，我們使用凈推薦評分（Net Promoter Score），也就是客戶向他人推薦我們的可能性有多大。您的企業(yè)可能會使用不同的測量指標。關鍵是，您可以使用這個指標跟蹤您在市場上的商譽。因果關系很難確定——您的商譽是否因為質量提高或其他市場因素而提高？但如果您追蹤指標的變化，就可以分辨出正面或負面的趨勢。

商譽對銷售有影響，如果您可以獲得這些數(shù)據(jù)，它就可以讓趨勢顯現(xiàn)出來。大多數(shù)銷售或營銷團隊都可以追蹤到續(xù)約率與客戶滿意度、現(xiàn)有客戶滲透、甚至是媒體正面報道都是正相關的指標。再次強調，因果關系很難確定，但值得追蹤。

因此，改善底線成本節(jié)約就成為一種明顯的結論。另外有些指標不易測量但的確能給企業(yè)增加利潤。