1.2 DevOps能帶來什么

Dev 需要對開發負責，并且需要應對市場快速的變化、實現業務的需求。Ops 的重心則放在提供安全、可靠、穩定的服務上。為了使Dev和Ops更好地協作，已經有了很多方法和流程被提出，但是幾乎在每一個IT組織中，Dev和Ops之間都會產生一些不好的因素，使得產品或功能交付的時間增加，質量下降，更糟糕的是出現了與日俱增的技術債務。技術債務描述了所做的決策會引起的問題。隨著技術債務的不斷增加，解決它所帶來的問題也會花費越來越多時間并使得成本不斷增加。

Dev和Ops之間到底因為什么產生問題？Dev和Ops，本來就像左手和右手，但在實際的項目之中并非如此，它們之間仿佛有著一堵無形的墻，正是這堵墻使得Dev和Ops產生了隔閡。產生隔閡的原因在于Dev和Ops的分工和目標不同。細化組織目標的過程中產生了在實際推行的時候相互制約的因素，具體來說，企業需要實現快速發展，同時也需要提供穩定服務。Dev為快速將產品推向市場做出了努力，當然穩定和安全也是必要的，在現實中，非功能性要素不會出現在大多數開發人員的視線范圍內，而且在大部分情況下這些也不是交付的要素，Ops 則需要負責穩定這些要素。兩個團隊、兩個目標、兩套KPI（Key Performance Indicator，關鍵績效指標），相互沖突，無論在哪個國家，類似的隔閡和問題一直都存在。

這不再是一個簡單的技術問題，Dev的目標和Ops的目標，以及兩者在組織層面上的KPI是不同的。在現實工作中問題到底是如何產生的呢？我們可以還原一下場景。

讓我們從欠下的“賬”（技術債務）說起，每個項目都難免有自己的“賬”，Ops 的目標是為最終客戶提供穩定服務。但是由于應用程序和基礎框架極其復雜，以及復雜系統具有脆弱性，加之缺少文檔，運維人員每天都需要面對一些計劃外的“救火”任務。而“救火”的時候一般都會留下一些小的問題，“救火”人員總是想之后抽空修復這些問題，但現實是，他們往往因為沒有時間或者忘記而導致這些“賬”被束之高閣，如果是，他們欠下的“賬”不斷地增加。

而當這些日漸脆弱的系統所支持的是創造利潤的關鍵業務時，問題就會變得更加復雜，本來能夠應對的問題也會因為人們的擔心和憂慮，以及沒有非功能性要素的保障而使相關人員信心不足。問題越積越多，每一個小小的改動，最終都可能引起多米諾骨牌效應。所以每次只能進行最少量的修改。至于事后分析，結果很有可能是，在進行根本原因分析后發現修改的成本過高，無法實現。

“救火”已經讓大家手忙腳亂，但是不收口的需求往往會點起第二把“火”。在IT行業中有一個被講了很多年的冷笑話：需求的變化只有兩種類型，第一種是從項目開始到結束一直在變；第二種是只變一次，項目開始的時候把需求打開，項目結束的時候把需求關閉，因為需求一直沒有定，之間的變更都算作一次。

理想的項目是，缺錢給錢，缺人給人，項目范圍穩定，變更管理有序，在 QCT（Quality、Cost、Time）三角進行管理的經驗豐富的人員也游刃有余。而實際的項目是，錢和其他資源往往比預想的要緊缺，變更也很難管控，項目會存在很多壓力，在這些壓力之下，很多難以兌現的承諾可能就被許下了。

然而最終伴隨著這些許諾的任務都會壓到Dev那里，使得項目進度更加緩慢。這些任務往往兼具難度大、工期緊、經費少、人手不足等諸多不利因素，完成任務已經令人精疲力竭，至于技術債務，自然會進一步地累積。

這樣只要每件事情都復雜一點點，每個人都再忙一點點，問題就會發生。一點一點，每個人都變得越來越忙，工作時間越來越長，交流時間越來越少，任務列表越堆越高。每個人的工作都和別人的工作緊密相關，一個小的動作都可能帶來很大的失敗，自然而然，他們便會對變更更加畏懼和排斥。工作中需要更多的溝通、協調、批準，每個團隊必須等待更長的時間以確保所依賴的部分已經完成。

在這種情況下，項目部署的時間也越來越長，更糟糕的是，項目開發將開始出現問題，而對這些問題的“救火”行為耗費了大量的時間和成本，使得原本可以著手對付那高壘的技術債務的最后一絲機會也喪失殆盡。到了這時，能力出眾的個人或者小團體的非常規的努力，在保證了系統能夠運行的同時繼續推高了系統的技術債務，為下一次問題的爆發埋下了隱患。

很多傳統的IT組織將穩定和快速兩個目標（就像油門和剎車）分別給予了Dev和Ops，并為其定下了 KPI。組織所做的事情只是等待沖突的出現，而組織真正的目標和最終客戶的需求只好被選擇性地無視。那么DevOps能解決這個問題嗎？我們先對DevOps的現狀進行簡單了解。