3.4 常見的理解誤區

本節將介紹常見的理解誤區，分別如下。

1.DevOps強調交付時間，天下武功，唯快不破

在軟件開發等科技領域，價值流同樣存在，而且制造業的原則和經驗在這些領域同樣適用：同樣是由業務部門提供明確的需求定義，將開發、測試、部署交付給運維團隊，最終價值流向客戶。區別于傳統制造業的產品，科技領域的價值流更多是以服務的形式進行交付的。

只有將我們開發、測試完成的軟件運行在面向最終客戶的生產環境之上時，I T領域的價值流動才算完成，在那之前都只是“工作制品”（WIP）而已。

在DevOps中，交付時間也不是全部。“快”很重要，可靠性、穩定性、擴展性、安全性同樣重要。DevOps追逐的快速價值流動，是建立在不會因此而帶來服務中斷、安全事件等混亂事件的基礎之上的，所以也需要“穩”。

2.DevOps適合小型團隊，大型團隊難以開展

當開發人員的數目增加的時候，由規模效應帶來的溝通、協作等額外作業不可避免地會對個體開發者產生比較明顯的影響。就像《人月神話》一書中所解釋的那樣，當項目延遲時，增加開發者不但會降低個體開發者的效率，也會降低整體的效率。

而 DevOps 則從另外一個角度告訴我們，當我們有合適的架構、合適的技術實踐、合適的文化氛圍之時，小的團隊也能高效地完成作業。同時，大規模的團隊也同樣適合DevOps。Google等公司已經證明即使對于數千人的團隊，架構和實踐依然能使得團隊像初創公司那樣產生很好的效率。

同時，DORA調查結果也表明，當人數增加時，由踐行DevOps的高效能人員所組成的團隊依然能夠保證與小團隊同樣的線性增長效率。

3.給予開發團隊較多權責，容易產生更多問題

在20世紀制造業變革的浪潮中，很多高績效的制造企業的做法讓人眼前一亮。這些制造企業不再將工人視作工具，而是給予工人一定的權責，使得工人能夠在他們的日常工作中進行試驗和改進。區別于傳統企業的做法（限定的流程，出現錯誤進行懲罰），這種企業認為不斷地改進才應該是常態，甚至已經將其變成了例行的工作內容。

同樣的情況，在企業的 DevOps 實踐中也得到了驗證，給予開發團隊一定權責會給企業帶來更好的活力。很多號稱敏捷開發的團隊在實際作業時遵從其他團隊所做的需求，而沒有提出自己意見的權利，這個限制可能會帶來很多實際的問題，而最終的結果則可能是產品不會取悅客戶，也無法交付所期待的業務結果。敏捷開發的一個重要目標是在整個開發過程中都去尋求客戶的真正需求，這使得開發團隊能夠得到重要的信息，但是如果不管開發團隊發現了什么，他們都沒有任何權利對需求進行改變，創新能力將會被極大地閹割掉。

4.反饋的信息過于繁雜，只重視主要信息即可

復雜系統反饋的信息的確非常多，但這并不意味著只重視主要信息即可。前提是我們能分辨出主要信息和次要信息，但是在現實的世界中，這個往往很難。而微弱的征兆如果得不到足夠的重視，災難性的后果遲早會發生。

2003 年，在完成了 16 天的研究任務后，美國的哥倫比亞航天飛機在返回大氣層的時候發生爆炸，原因是起飛時燃料罐隔熱泡沫發生脫落。而這個問題在航天飛機返回大氣層之前，已被工程師發現并上報，但是沒有得到重視，他們被告知泡沫問題不是什么新問題，以前也出現過，從來沒有出過事。這個問題一直沒有得到重視直到災難發生。2006年，有關人員對美國國家航空航天局（NASA）的文化進行了剖析，他們將組織模型分為標準模型和試驗模型兩種，組織模型分類及說明如表3-4所示。

NASA的模型則為標準模型，對模型的錯誤選擇導致本來應該得到重視的新的信息被忽視。這一慘痛的教訓告訴我們，應當對每次試驗的結果進行認真的審視，通過放大反饋予以重視，以保證微弱的征兆也不會被忽視。