Dan Zentgraf是Ascendant Technology公司的一名領域架構師。他的任務是幫助顧客採用DevOps和敏捷實踐。作爲一位諮詢師和產品經理，他在軟件領域擁有與商業、工程主管一起工作的12年從業經驗。
這片文章講述了將傳統的軟件開發方式轉變爲使用新興的Devops理論、技術所帶來的挑戰以及在新方式中所需要注意的變化。這篇文章的研究範圍包括部署內容的定義以及爲了利用DevOps 所需要的組織和文化的革新。
敏捷開發的一般原則是開發團隊應該一直以可持續的速度不斷地交付軟件。與此同時，基於相關的虛擬化和雲計算，許多新的操作工具和基礎設施已經可以爲我們所用。雖然很多研發團隊已經主動採取了敏捷開發的方法，但是他們開發的軟件常常不能被用戶接受，因爲他們的程序充滿了缺陷、易出錯的手工任務或者和運維相關的延遲。
同時，競爭日益激烈的市場環境給業務主管帶來了巨大的壓力，因此他們要求在更短的週期裏把新軟件和特性交到客戶手裏。敏捷開發、新運維技術和市場需求導向這三個因素正在使人們重新思考應該如何看待軟件開發。
這三種趨勢的共性是變化的速度增加了。那種把用戶所需要的軟件功能擱置幾個月再去開發的做法已經無法被接受了。軟件只有使用的時候才有價值，快速的得到那種價值在今天的市場上顯得尤爲重要。這種轉變使人們質疑團隊開發軟件的種種假設，而質疑的結果就是DevOps的問世。
爲了總體上理解軟件交付，尤其是用DevOps進行軟件部署，理解以下兩點很重要：
首先，對DevOps以及各種利益相關者對它感興趣的原因有一個清晰和正確的理解是十分必要的；
其次，當我們嘗試應用DevOps時，理解軟件部署的假設是如何變化很重要。
當這些理解了這些之後，纔有可能瞭解支持DevOps的可執行部署的框架。
理解DevOps和利益相關者
DevOps這個術語，由英文單詞development和IT operations組合生成，一般指的是一種利用所有各種規則統一軟件系統的相關工作的方法，，從而以業務部門要求的速度將更改交付給系統。它通常與進行快速而小的改變的敏捷開發結合起來，目的是注意力集中於高價值的工作，最小化由大的變化所產生的缺陷風險，減小由於工程完工後軟件特性與商業要求的嚴重背離而帶來的軟件價值偏移。另一方面，運維的觀點是指將變化視作不穩定性的成因。不穩定性必然會導致宕機，這是運維當中最嚴重的負面事件。因此，運維團隊常常抵制變化。
然而，DevOps常常被視爲一種改變，因爲在絕大多數的開發團隊中，開發、運維和市場三者之間有着一系列的的衝突行爲和回報，從而導致無數的不當行爲。市場給進行新特性開發和追求變化的開發團隊以回報，但是卻因爲宕機而處罰運維團隊。因此，開發團隊迫切要求運維人員進行更多的部署；運維團隊則要求開發人員的交付模塊包含更多結構和更高的精確度。這些矛盾在很多開發團隊中已經根深蒂固，並且因爲各自團隊成熟度的固有不同而更加嚴重。DevOps力圖消除這些障礙，爲這些競爭團隊搭建一個共同合作的平臺，從而把他們集中到同一個目標上。爲了實現這個目的，理解每一個團隊的心態非常的重要。
研發
研發通常被認爲更加的接近市場需求。《敏捷宣言》已經問世十多年了。從某種程度上說，該宣言是早期極限編程、結對編程和實踐的結果。公平地說，這個難題的軟件部分被視爲是很容易實現的目標（它很容易改變，但理論上獨立於基礎設施和平臺之上）。基礎設施習慣上被認爲是一種很難被改變的昂貴資本支出，並且有很長的攤銷週期。不幸的是，複雜的軟件需要很多的基礎設施，並且要求基礎設施和軟件本身同步發展。這種聯繫就是爲什麼早期DevOps有時被稱作“敏捷運維”。
無論人們怎麼稱呼它，如果科技與市場需求保持同步的話，堅持軟件和基礎設施分開的想法是不可持續的。這迫使研發團隊接受維持複雜基礎設施生產的現實。
運維
幸運地是，一些新的科學技術已經成爲運維領域的最前沿，從而幫助運維更加的符合市場需求。運維領域最主要的顛覆性技術是便宜的硬件商品虛擬化的廣泛普及。這產生了新的系統管理方法，當然還有云計算。這種科技由於能讓開發團隊快速而容易地整合他們未被充分使用的計算資源從而直接產生價值，因而快速流行起來。美國Gartner諮詢公司估計現在50%的應用在虛擬環境中運行。
然而，簡單的整合只是一種有限地回收價值、縮減開支的的辦法。虛擬化技術也使基礎設施具有了一定的可變性，讓運維團隊在不影響穩定性的前提下以以前不可能達到的速度改進基礎設施。虛擬化利用技術常常在與雲計算有關的項目中出現。這些新興的技術給了運維團隊一條同研發團隊一樣敏捷並且能切合市場需求的途徑。
業務
對業務主管們來說，他們已經明白了理解和利用技術來實現目標相比以往更加的關鍵。根據IBM2012年的CEO調查（這個調查建立在對64個國家1700個首席執行官進行訪談的基礎上），技術因素是影響開發團隊排名第一位的因素。2004年技術因素只在九個因素中排名第六，此後，這個排名穩步地上升。
因此業務主管注意到響應顧客需求的能力是一種競爭優勢。由此可以推斷，糟糕的技術執行力是對業務的一種內在威脅。這種威脅不會一夜之間就成爲現實，但是它已經一觸即發。同樣的調查還討論了調查對象如何權衡理解客戶的需求和用更短的交付時間來滿足他們的需求。最後，這是一種和過程現實相沖突的業務壓力。這種過程現實就是研發和運維的技術規程過去是如何運作以及激發將商業做的更好的討論。
DevOps和部署
高頻率
爲了實現這些目標，最明顯的變化之一是我們假設把新的軟件功能交到用戶手中才能讓軟件更有價值。這個假設意味着越早發佈新的軟件功能越好，因爲這意味着新的軟件功能所帶來的價值實現的更快。但是絕大多數的開發團隊，以前都以用很長的時間開發很大的軟件爲導向。
這種短週期、高頻率的開發假設才正是軟件開發定義轉變的根本所在。DevOps摒棄了原來那種一年當中將開發進程暫停很多次而去做很大的軟件整合和組裝的想法，取而代之的是一個開發系統應該能持續運行，並且擅長連續不斷地開發大量小的增量。關鍵點是替代。傳統的以大的開發爲導向的系統通常都很笨拙，所以很難高速運轉來支持DevOps。“用舊方法做，就是儘量快點”的企圖常常會失敗，因爲創造舊方法的假設從來不是爲了支持高頻率的活動。這不是好與不好，這只是一個需要解決的工程問題。
鑑於這種新的交付過程變成了從軟件投資中獲取價值的固有的一部分，這種過程理所當然也就成爲了整個系統新的擴展。它成爲了評價研發投資最基本的方式。於是，這也形成了管理交付進程的效率和效果對整個系統來說有着直接且可計量的商業價值的假設。這個假設所暗含的意思是忽略維持交付能力所產生成本是不可行的。
系統全景
DevOps研發另外一個特點是它着眼於完整的系統而不是簡單的能實現軟件功能的代碼變化。DevOps嚴謹地認爲應用程序代碼依靠服務器、網絡和數據庫等基礎設施來實現它的價值。因此，DevOps部署方法同等地對待系統組成部分的所有變化，以同樣的方式追蹤記錄這些變化。一些基礎設施的變化，比如一個謹慎的網絡交換機升級或者存儲設備的增加，會被視爲性能的增強（系統的新功能），即便這些變化可能會不太容易察覺。同樣的，網絡服務器的或者SAN固件補丁可能會被認爲是修復補丁或者缺陷。不論一個開發團隊如何將事物分類，關鍵是他們能夠用同樣的嚴謹態度去對待其他部分，來保證整個系統的持續穩定。
在DevOps環境下，將全局系統的視角運用到一個高層次的模型中會產生下面四種將被交付的核心變化：
應用
應用是系統中編寫代碼的真正特性。它是驅動整個核心業務進程的具有高度可見性的功能。它的這種可見性使它獲得了很多的注意，但是這種關注幾乎沒有給支持它的環境帶來任何主動式的價值考慮。
操作系統服務
操作系統服務適用於所有的機器（虛擬的或是真實的）、操作系統服務、程序庫和能讓應用運行的中間軟件。所有環境下配置的協調性，從測試一直到生產，都是應用穩定性和質量的關鍵驅動因素。
網絡服務
網絡服務將所有的網絡設備和配置集中在應用的周圍。這些配置顯然影響運行和可用性，但是也能影響應用行爲和體系結構。例如，應用和負載均衡器必須就在其他事物中就session處理達成一致。
數據庫
應用中的數據庫包含應用使用和產生的關鍵數據。在應用的整個生命週期中，數據庫和應用必須在數據規劃結構方面完美地保持同步。
DevOps部署系統的特性
DevOps部署需要一種很嚴格縝密的方法將各種變化傳遞到這種部署所支持的軟件系統。系統需要承受的異常、變化或者是特殊的事件越多，系統開發尤其是維護就會越昂貴。控制交付過程的複雜程度就要理解並控制將被交付的對象以及它們是怎樣被交付的。這要求開發團隊必須商定一套構成每個交付單元的已定義的程序包和一個能和諧地將程序部署到所需要的環境中的系統。
已定義的程序包
一個有效的交付系統要求被交付的項目符合一定的標準。現實世界中的集裝箱就是一個很好的例子。這種標準的集裝箱能夠被標準的設備通過極其複雜的物流網運輸。這個物流網絡包括很多不同的交通方式，如火車、貨船和貨車。在起重機和追蹤系統的幫助下，我們能將任何東西運送到任何地方，只要它能夠被裝在一個集裝箱中。將這些集裝行標準化是世界商品運輸和貿易史上的一次革命。
好消息是我們沒必要制定一個國際化的標準來將變化交付到一個軟件系統中。許多開發團隊已經通過一些活動拓展實現了這個目標。許多開發團隊正在通過持續集成或者其他的計劃以穩定的速度開發軟件內部版本。這些內部版本擁有或者應該擁有一些獨特的身份標識，能讓使用它們的人，比如測試者，預期軟件的性能和特點等。
這種方法能給開發團隊提供一條理解其他三大組件中變化組羣的基準。如果這四大構成中的每一種都有一種標準方式去識別變化，那麼通過獨有的變化指示器去追蹤這四大構成的組合就會變得相對直接簡便。對應用的內部版本號、配置服務器以及數據庫的模式版本等的組合
就能夠被記錄並且被部署到任何測試或者使用環境中。
交付系統
然而，不像集裝箱，可部署數據包系統不一定和水力學和柴油燃料有關。相反，它涉及一組工具和程序，它們能讓開發團隊以同樣的方式操控他們的開發環境、測試環境以及生產環境並且任何時候都能將數據包部署到任何一個環境中。這些工具和程序涉及環境中的各種函數。這些函數包含不同領域的專業知識，並且根據四大組件中出現的問題以不同的方式運用。考慮到各種函數複雜性，根據它們的作用建立一個框架來將它們形象化並分成不同的種類將會很有幫助。
對DevOps而言，容量分類法包含六大類，每一大類又有很多小類。這個框架不是爲了分類而分類，也不是說所有的部件都必須擁有所有的性能。然而，它卻爲理解優先化在構建一個DevOps交付系統時所存在的障礙提供了一種有用的工具。
下面這些定義總結這六大分類：
變化管理——保證對系統進行的改進被正確地記錄而進行的活動；
編制——同步協調分佈系統中所有活動；
部署——和管理正在基礎設施上運行的各種模塊的生命週期相關的活動；
監控——提供保持環境正常的指示器和爲相關利益人提供系統運行反饋；
系統註冊——將整個系統運行需要的所共享的基礎設施信息進行集中歸檔；
供應——保證基礎設施環境提供足夠數量的正確部件來供系統運行。
分類法應用
分類法的價值是它爲我們理解環境，識別其中的首要目標以及評價合適的解決方案提供了一種方法。它使得一個開發團隊能快速對目標和和現有工具的性能有一個結構性的瞭解。此外，它也能用來評價一個開發團隊或者解決方案在一段時間的運行情況。這種結構性的分類法根據具體的情境，也會一定程度讓評價內容更加詳細。
例如，2012年IBM發佈了一款持續部署框架軟件的測試版，叫做SmartCloud連續交付系統。這個框架的目的是開發交付可以幫助開發組織應用DevOps交付方法的工具和整合程序。
通過只應用分類上層的一些函數，我們就能看到這種分類方法是如何系統而完善地包括着六大分類的：
首先，SmartCloud持續交付測試版利用IBM的Rational Team Concert軟件和Rational® Asset Manager軟件來提供一些變化管理、編制以及部署功能。
其次，也有一些利用IBM的雲系統基礎設施工具（比如IBM Workload Deployer，IBM® SmartCloud™ Provisionin，IBM® PureSystems）來提供系統註冊和供應的功能的整合方法。
第三，也有一些報告反饋程序提供監控功能。
最後，也有一些整合工具，如Rational Automation Framework和Rational Build Forge。它們具有部署和編制功能。
即使用結構化的分類方法隨便看看，也能知道SmartCloud連續交付對這六種功能都有涉及，但是每一種功能涉及的深度又有所不同。每種功能的不同深度正是工具提供者在強調不同方法、整合不同的產品或產品組合及將客戶要求最優化時所期望的。用一種協調一致的的方法來評價解決方案是開發團隊保證客戶能得到他們想要的東西的關鍵所在。
系統操作
不論用什麼結構來理解，DevOps交付系統是一個應用系統中所有變化的中心代理。這種集中性對所有應用運行所在環境都適用，包括生產和再生產環境。這保證應用總是在一種已知的狀態下和一種配置已知的環境中運行。到達那種狀態不僅僅需要對開發新功能的原則和所在框架有一個清晰的瞭解。它更需要對原則的應用和遵守，開發團隊必須尊重一些因素纔會更有效。
環境管理
允許軟件系統運行的多環境總是存在。我們有生產環境，當然同時也要有一些質量保證和測試環境。這些質量保證環境是開發團隊驗證某一給定的變化會產生所預期的效果的地方。這些環境常常被視爲僅次於生產環境，但是事實是測試環境中錯誤的信息會導致生產中斷。這種依賴意味着開發團隊必須嚴肅地對待這些環境。這是成功的DevOps交付所依賴的。
嚴肅對待這些環境的第一步是保證所有的環境都真正的具有代表性。確認某一質量保證環境中某一假定的配置對生產環境來說是一個好的代理，這是一項工程性工作。在這條基線建立之後，保持這種狀態就會變得更加簡單直接。
第二步是保證所有的變化都通過質量保證環境得到提升，而後再進入到生產當中。因爲一項應用應該被視爲一個整體，所以對生產環境任何方面不經過質量保證環境的的配置變化都是不允許的。這要求我們改變自己的觀點，不要再認爲變化很容易或者自己所做的變化和其他的不同。除了明顯的減小風險和提高可靠性的好處外，這種做法也能減少環境維護和同步的花費。這種方法意味着環境總是在一種已知的狀態中運行，同時也意味着減少了管理多環境配置的重複工作。
異常處理
即使用一種統一的環境管理方法，緊急情況也會出現。在環境中異常事件應該非常的罕見。一個嚴重的事件經常是由外部因素導致的。平臺中的供應商Bug或者緊急安全補丁就是很好的例子。這些不應該是由內部因素導致的變化。
處理異常情況時，我們應該把異常當做重要的事件並且應該及時矯正並反思。矯正必須着眼於環境的再同步。例如，如果標準的變化傳遞系統不是用來將變化適用於突發性環境，這個變化必須被加到標準的變化傳遞系統中。不管這個變化是如何被適用的，也必須有一個事後處理過程來解釋異常發生的原因，更要要的是解釋如何減小異常再次發生的機率。
度量和持續改進
用DevOps方法來傳遞軟件變化爲我們提供了充分的機會來度量和改進程序。除了標準系統的一致性外，DevOps方法的高頻率也提供了更多的數據點。各種各樣的度量對象，如週期、數據包缺口和程序故障，都是常見的度量之物。這些度量不是典型的運維度量，如可用性和可用時間。相反，它們以保證可用性和可用時間爲工作方針。其他好的追蹤記錄對象是對程序有效性和效率的度量。維護應用系統所需的工作時間、維護DevOps基礎設施所需要的時間和向給定環境交付所需的等待時間都是很好的度量對象。
一個DevOps交付方法也能讓應用系統擁有強大的檢測儀功能。這些度量只能針對特定應用的，但是它們揭示了運行情況和用戶體驗反饋等等。因此，這些度量告訴我們是否應該主動比較操作環境、識別應用系統中的瓶頸或者管理容量需求。
DevOps交付中的工具必須鬆散地耦合到它們被部署的環境中去。這意味着開發團隊必須能夠在不對整個系統進行重大分裂的條件下替換某個工具。從架構上講，有一些方法來實現這個目的。例如，將注意力集中於那些使用網絡服務APIs作爲基本整合原理的工具就是部署運用DevOps工具時的流行做法。不管用什麼技術方法，開發團隊必須意識到改變某一工具對團隊整體部署變化的能力有一定程度的影響。當開發團隊想替換某一工具時，他們必須謹慎地分析所帶來的影響並將它和替換所帶來的好處進行權衡。
總結
DevOps倡導一種軟件交付的根本性變化。這麼做的好處卻是更加快速頻繁地交付更高質量的軟件。用一種結構性的方法去將應用系統視爲一個統一的整體能幫助開發團隊進行協調合作。那種協調合作能夠通過一種系統的方法來支持，從而更加高效地交付和提高用來交付整個系統的功能。DevOps方法支持以穩定、多週期漸進式改進爲特點的敏捷開發，並且提供給開發團隊持續地按用戶要求交付有價值的軟件所需的結構和洞察力。這纔是開發部署軟件的要義所在。
查看英文原文，請點擊這裏。