簡介
DevOps: Development和Operations的組合
可以把DevOps看作開發（軟體工程）、技術運營和質量保障（QA）三者的交集
傳統的軟體組織將開發、IT運營和質量保障設為各自分離的部門。在這種環境下如何採用新的開發方法（例如敏捷軟體開發），這是一個重要的課題：按照從前的工作方式，開發和部署不需要IT支持或者QA深入的、跨部門的支持，而卻需要極其緊密的多部門協作。然而DevOps考慮的還不止是軟體部署。它是一套針對這幾個部門間溝通與協作問題的流程和方法。
需要頻繁交付的企業可能更需要對DevOps有一個大致的了解。Flickr發展了自己的DevOps能力，使之能夠支撐業務部門“每天部署10次”的要求──如果一個組織要生產面向多種用戶、具備多樣功能的應用程式，其部署周期必然會很短。這種能力也被稱為持續部署，並且經常與精益創業方法聯繫起來。 從2009年起，相關的工作組、專業組織和部落格快速湧現。
DevOps的引入能對產品交付、測試、功能開發和維護（包括──曾經罕見但如今已屢見不鮮的──“熱補丁”）起到意義深遠的影響。在缺乏DevOps能力的組織中，開發與運營之間存在著信息“鴻溝”──例如運營人員要求更好的可靠性和安全性，開發人員則希望基礎設施回響更快，而業務用戶的需求則是更快地將更多的特性發布給最終用戶使用。這種信息鴻溝就是最常出問題的地方。
以下幾方面因素可能促使一個組織引入DevOps：
使用敏捷或其他軟體開發過程與方法
業務負責人要求加快產品交付的速率
虛擬化和雲計算基礎設施（可能來自內部或外部供應商）日益普遍
數據中心自動化技術和配置管理工具的普及
有一種觀點認為，占主導地位的“傳統”美國式管理風格（“斯隆模型 vs 豐田模型”）會導致“煙囪式自動化”，從而造成開發與運營之間的鴻溝，因此需要DevOps能力來克服由此引發的問題。
DevOps經常被描述為“開發團隊與運營團隊之間更具協作性、更高效的關係”。由於團隊間協作關係的改善，整個組織的效率因此得到提升，伴隨頻繁變化而來的生產環境的風險也能得到降低。
DevOps對應用程式發布的影響
在很多企業中，應用程式發布是一項涉及多個團隊、壓力很大、風險很高的活動。然而在具備DevOps能力的組織中，應用程式發布的風險很低，原因如下：
devops與傳統開發方法那種大規模的、不頻繁的發布（通常以“季度”或“年”為單位）相比，敏捷方法大大提升了發布頻率（通常以“天”或“周”為單位）
減少變更範圍與傳統的瀑布式開發模型相比，採用敏捷或疊代式開發意味著更頻繁的發布、每次發布包含的變化更少。由於部署經常進行，因此每次部署不會對生產系統造成巨大影響，應用程式會以平滑的速率逐漸生長。加強發布協調靠強有力的發布協調人來彌合開發與運營之間的技能鴻溝和溝通鴻溝；採用電子數據表、電話會議、即時訊息、企業門戶（wiki、sharepoint）等協作工具來確保所有相關人員理解變更的內容並全力合作。自動化強大的部署自動化手段確保部署任務的可重複性、減少部署出錯的可能性。
現狀
很多組織將開發和和系統管理劃分成不同的部門。開發部門的驅動力通常是“頻繁交付新特性”，而運營部門則更關注IT服務的可靠性和IT成本投入的效率。兩者目標的不匹配，就在開發與運營部門之間造成了鴻溝，從而減慢了IT交付業務價值的速度。
開發人員經常不考慮自己寫的代碼會對運營造成什麼影響。他們在交付代碼之前，並不邀請運營人員參與架構決策或代碼評審。
開發人員對配置或環境進行修改之後，經常沒有及時與運營人員溝通，導致新的代碼不能運行。
開發人員在自己的機器上手工修改配置，而沒有記錄所有需要的步驟。想找到必要的配置參數，通常需要嘗試很多不同的參數；在得到一個可工作的狀態後，往往很難識別出通過哪些最小步驟就能到達該狀態。
開發人員傾向於使用有利於快速開發的工具：對代碼修改更快的反饋，更低的記憶體消耗，等等。這樣的工具集與運營人員面對的目標運行時環境非常不同：後者對穩定性和性能的要求遠勝於靈活性。
由於開發人員平時使用桌面電腦，他們傾向於使用為桌面用戶最佳化的作業系統。生產環境的運行時系統通常都運行伺服器作業系統上。
在開發過程中，系統在開發者的本地機器上運行。在運營過程中，系統經常分布在多台伺服器上，例如web伺服器、套用伺服器、資料庫伺服器等等。
開發是由功能性需求（通常與業務需求直接相關）驅動的。
運營是由非功能性需求（例如可獲得性、可靠性、性能等）驅動的。
運營人員希望儘量避免修改功能，從而降低滿足非功能性需求的風險
如果拒絕了小的修改，但給定時間段內需要修改的總量不變，那么每次變更的規模就會變大
變更規模越大，風險也越大，因為其中涉及的區域越多
由於運營人員嘗試避免變更，新功能流入生產環境的速度因此被延緩，從而延緩了開發人員將特性交付給用戶使用的速度。
運營人員可能對應用程式內部缺乏了解，從而難以正確地選擇運行時環境和發布流程。
開發人員可能對運行時環境缺乏了解，從而難以正確地對代碼進行調整。
訴求
1、更小、更頻繁的變更──意味著更少的風險
2、讓開發人員更多地控制生產環境
3、更多地以應用程式為中心來理解基礎設施
4、定義簡潔明了的流程
5、儘可能地自動化
6、促成開發與運營的協作
一般而言，當企業希望將原本笨重的開發與運營之間的工作移交過程變得流暢無礙，他們通常會遇到以下三類問題：
發布管理問題：
很多企業有發布管理問題。他們需要更好的發布計畫方法，而不止是一份共享的電子數據表。他們需要清晰了解發布的風險、依賴、各階段的入口條件，並確保各個角色遵守既定流程行事。
發布/部署協調問題：
有發布/部署協調問題的團隊需要關注發布/部署過程中的執行。他們需要更好地跟蹤發布狀態、更快地將問題上升、嚴格執行流程控制和細粒度的報表。
發布/部署自動化問題：
這些企業通常有一些自動化工具，但他們還需要以更靈活的方式來管理和驅動自動化工作──不必要將所有手工操作都在命令行中加以自動化。理想情況下，自動化工具應該能夠在非生產環境下由非運營人員使用。
要開始最佳化發布流程，可以從問題識別開始：看看上面提到的哪種問題在你的團隊中具有最高的優先權。
協調人
這是企業級IT組織中一個新出現的角色，其主要任務就是協調安排將企業級 軟體 部署到預生產環境。對發布協調人的需求來自於以下幾方面原因：
需要彌合 開發與 運營的鴻溝
基礎設施日益變得複雜：為了 運營web套用，需要多層 基礎設施和多種平台
發布頻率上升（由於敏捷和 疊代式開發的引入）
分散式團隊：位於全球多個地點的、包含外包人員的、混合 開發/ 測試/基礎設施的團隊
發布協調人的角色（也被稱為 部署協調人或集成協調人）源自發布管理或發布工程團隊。這個角色與航空交通管制有些類似──實時協調不同團隊的行動，有效使用共享的資源（空域、航道、跑道、航站門），達到組織的總體目標（安全起降）。
傳統意義上的發布管理往往只關注 軟體變更的計畫與管理，發布協調則需要控制“將特定軟體變更發布至生產環境”的整個過程。這項工作需要系統地管理所有與“將代碼構建並 部署到生產環境”相關的技術任務，也被稱為“發布工程”。
變更管理是跟蹤企業IT環境中各種變化──不管是應用程式還是 基礎設施的變化──的基本原則。 變更管理是 ITIL v3的核心之一。
促進戰略
想要為DevOps和套用靈活性而重塑團隊，需要領導層的勇氣和無私奉獻。當然，它也需要花費時間和金錢，並且需要在團隊成員篩選上做出艱難的決定。
為了促進DevOps戰略，調整考核和激勵機制是必要的。如果依然只根據敲出代碼的生產力來獎勵開發人員，或者根據基礎設施的可靠性來獎勵運維人員，那么，什麼都不會改變。相反，應該獎勵系統創建和運維的整體團隊，並且根據團隊工作的全部要素來確定獎勵。
圍繞業務系統而不是職責來組織工作，這就是DevOps打破IT分組壁壘的寓意。一個團隊應該有開發人員創建代碼，從用戶界面到業務邏輯和數據結構，也應該有運維人員負責操作自動化和部署。
人們需要知道他們需要對什麼樣的系統負責，而並不僅僅是毫無責任地從一個系統換到另一個系統。唯一的例外是專家。
團隊待在一起，共同為他們的套用和系統負責。
不要製造一個團隊支持太多套用的局面。在這個預算縮減的年代很難考慮周全，但是經歷這種融合轉變之後，團隊將更加富有成效，並且不需要額外人員就能應對需求的增長。
需要充足的專家參與項目和為團隊提供支持 ——這些人都是不同學科的大師和專家。他們為系統提供支持，但是不會長期指派給某一個系統。他們不需要對這些系統負責。
全面自動化 —— 部署、 升級、 擴展、 維護、 數據衛生、 測試、 監測、 安全和策略管理。在自動化方面投入巨資，目標是100%的自動化，不考慮低於90%的可能性。但是，全面自動化也可能會引起自動化泛濫。集中審查和調整可以控制Chef或Puppet腳本庫的無序增長。
針對整個團隊進行獎勵和表彰。成功離不開大家共同的努力，同樣，問題需要整個團隊自我反省。系統團隊應該承認專家們的貢獻 ，對表現傑出的專家給予獎勵。
圍繞建設運營融合的原則制定新的企業體系結構標準。這將確保系統符合運維的需求。
DevOps戰略必須獲取本組織自頂向下的全面支持。整個行政領導團隊 ——不只是首席信息官 ——應知道它為什麼重要和怎樣使它取得成功。
請記住，這是重大的文化和組織變革，多分配些時間開展培訓和組織開發活動。如果變革得太快而忘了和您的所有團隊步調一致，將整天陷入失誤和衝突——最後滿盤皆輸。
批評
有IT 部落格對“DevOps”這個標籤進行了批評，認為它不過是系統管理員的精英至上論俱樂部在老調重談一些現有的問題（參見“對此運動的批評”）。
成功的關鍵
文化衝擊
平穩的文化過渡是讓DevOps獲得長期成功套用和增強發布軟體產品的綜合能力的關鍵。第一步是，明確DevOps的定義，調動開發和運營部門之間的協作，鼓勵運營人員採納軟體開發方法，並利用雲計算基礎設施來完成真實的測試和代碼部署。
在軟體開發、測試、質量保證（QA）、集成、預生產和生產部署等方面的任何舊小團隊必須打散，因為每個小團隊都可能拖延開發周期並且帶來不可預料的問題。
以上策略能更好地整合開發和運營人員，通過整合團隊成員來產生效益。例如，在討論運營解決方案或擾亂事後評估報告時應該邀請開發人員加入。相反地，應該邀請運營人員列席開發人員規劃會議。讓交叉組合的工作模式成為制度，可以讓團隊之間合作融洽，消除溝通不暢導致的延誤或疏忽，使DevOps的推進更加有效。
這種文化上的改革並不容易。它需要公司提供統一的考核標準，以相同的形式衡量開發人員和運維人員的業績。培養一種團隊精神，讓大家一起向一個共同的目標努力，而不再只是為了從前各自的狹隘的小團體目標。在這裡有時可以運用崗位輪換或者知識共享的方法
齊全的工具箱
想要超越文化的影響，組織還必須依靠各種 DevOps 工具。例如，開發人員編寫代碼需要工具、QA測試人員需要用工具完成新版軟體的部署，環境準備、將新代碼在測試系統和生產系統之間遷移也必須用到雲資源調度工具。Fletcher表示，工具本身都不是問題，重要的是能夠讓各種工具互相配合，在軟體的生命周期內提供支持。
當前在應用程式發布自動化工具市場已經存在眾多的供應商。運營工具方面的供應商有BMC Software, CA Technologies Inc. 和 XebiaLabs Inc.等公司。軟體開發工具方面的供應商包括IBM，Electric Cloud Inc.和Serena Software Inc。
關於開發人員工作流程、架構設計和軟體發布工具方面的專業供應商也在不斷湧現，這些供應商包括Atlassian, CollabNet Inc., Rally Software, ThoughtWorks Inc. ，OpenMake Software Inc.等公司。在評估這些新供應商時，應明智地預計到這些公司隨時可能會被併購，其產品可用性和未來發展也會因此受影響——請記得在選擇新的軟體發布自動化產品時多留個心眼。
五大重點
1、警惕總體安全風險。虛擬化、雲、BYOD以及軟體定義網路（SDN）等新興技術不斷得到採用意味著網路變得越來越複雜，愈發的異構化，安全風險也是如此。這其中的巨大挑戰是迄今為止，安全被視為是事後想法，而安全組織又被認為是企業的抑制因子，只會告訴企業什麼做不了而不是如何安全地做事情。這是一個文化問題，需要安全、開發者以及運營團隊培育出此前未有過的一定水平的信任和協作。做到這一點的唯一辦法是逐步地、帶著警惕地去做。
2、觀察安全風險變化，把DevOps看作一種可將開發者和IT運營引向更快更高效的部署、運營及升級套用的協作理念和流程很重要。
3、注意可伸縮性。企業和技術的人必須在功能、推向市場的時間、成本以及風險承受能力等方面做出權衡。你需要有合適的衡量目標，包括特定模式下的那些端點上有多少用戶，有多少並發請求。
4、爭取實現易用—DevOps就是自動化和可重複性。
5、管理網關。儘管新的目標是在開發和運營團隊之間建設最好的文化，但為了確保產品環境保持穩定，在這兩個職能之間保留一些網關仍然是好的。
三種便利
將人置於技術之前
投資在那些關注技術的使用，以及如何採用持續開發、測試、集成、部署和操作的培訓計畫上。
安全和管理
對雲套用開發的管理必須是系統性的，構建在DevOps流程中的每一步，包括對使用的服務或API，以及服務發現和服務的依賴上所做的限制的政策。
作出改變
DevOps需要改變和發展以跟上新興的理念和技術。在設計你的DevOps流程時始終要將變化考慮在內。
度量標準
開發套用所花費的最高時間：幫助理解可以多快得開發套用
失敗部署的百分比：看出是否部署成功
客戶ticket數：顯示產生了多少問題
故障恢復的平均時間：顯示從應用程式bug或者故障恢復需要多長時間
用戶數：顯示應用程式對於用戶而言的有用程度
使用技巧
Web伺服器負載飆升的分析與處理
前提：日誌已經通過logrotate按天切分，其內容類似下面的樣子：
1.2.3.4--[01/Jan/2013:00:01:01+0800]"GET/pathHTTP/1.1"...
利用AWK，我們可以很方便的計算一天中每分鐘的訪問量是多少：
shell>awk-F:'{count[$2":"$3]++}
END{for(minuteincount)printminute,count[minute]}'/path/to/log|sort>count.log
下面列出生成的count.log檔案中的部分數據，結果一目了然，不多說了：
18:5514450
18:5614926
18:5715645
18:5816678
18:5919032
19:0029134
19:0134665
19:0235558
19:0335545
19:0435829
19:0535608
如果想要以秒為單位來統計，也是類似的方法。
與雲混合方法
步驟一：使用雲友好工具
DevOps的是客戶託管的命令中心，在這之中每一個管理伺服器都直接連線。對於一個可訪問命令中心的新實例，它所需要的只是在本地伺服器上的代理運行。這很容易就陷入到雲實例中。有了與套用、資料庫和配置信息命令綁定的解決方案，那么跨雲進行無論是小的，還重大的更改都很容易。
步驟二：不要忘本
雖然自動化將會變得越來越重要，但了解發生的什麼還是很重要的。這意味著要掌握部署流程的所有步驟。否則，在解決故障或定製化你的自動化工具時，你就是在抓瞎。
步驟三：對團隊進行培訓
隨著雲和新的工具承擔了大量的工作負載，運維工作似乎變得越來越不重要。但同時隨著雲複雜性的增加，實際上很難找到合格的運維人員。在真實世界中的持續套用管理備受關注，而且找到適合大局的人很關鍵。儘可能地讓你的開發人員學到更多關於運維的知識可以消除一些痛點，因為在他們的編程中他們可以做出更明智的選擇，從而避免常見錯誤。
作用
DevOps是Develop與Operations的縮寫，它是企業內開發、技術運營和質量保障這三方面工作的融合，用於促進開發、技術運營和質保部門之間的溝通、協作與整合。有研究顯示，在那些引入了DevOps概念的企業中，開發與運營人員在設計、構建、測試工作中共同在內部套用上進行協作之後，可以將產品開發的效率提升20%。
然而最為重要的如何成為一名真正的消費者用戶並像消費者用戶那樣來考慮這整件事情的意義所在，無論是成為企業內部用戶的還是外部用戶。事實上，如何提升最終用戶體驗一直是DevOps戰略發展的第一驅動力，有68%的企業是這樣認為的，第二個需求是為了提升開發與運營團隊之間的協作水平與效率，有61%的受訪者選擇了這一項。企業的移動與雲計算轉型趨勢的興起，同樣也是企業引入DevOps的重要原因，有52%與43%的人分別選擇了這兩項。
工具
即便是具有最高度功能化的DevOps團隊也是需要第三方工具來管理諸如雲計算這類的分散式環境。對於這樣的環境來說，某些工具是特別有用的。
諸如FlowDock或HipChat這樣的DevOps實用工具能夠幫助開發團隊的成員互相以及與DevOps人員保持聯繫。諸如Asana或Basecamp這類服務能夠有助於跟蹤開發任務以及在套用發布中的注意事項。
諸如以客戶為中心的支持入口網站可讓用戶直接與管理層或開發團隊進行需求溝通。這將有助於觸發新的或改進的功能，並確保客戶的需求能夠得到滿足。一個DevOps團隊能夠幫助建立這些服務，並讓團隊成員了解相關技術。
無論是縱向集成還是橫向集成，DevOps都需要通過工具鏈與持續集成、交付、反饋與最佳化進行端到端整合。華為基於二十幾年的研發實踐，並融合DevOps等理念方法，打造了軟體開發雲服務，希望為企業提供一站式的雲上開發工具平台。據了解，華為軟體開發雲提供了項目管理、配置管理、代碼檢查、編譯構建、測試、部署、發布等端到端地覆蓋軟體生命周期的相關服務。
發展現狀
在雲計算、大數據等技術顛覆性趨勢繼續在套用經濟下發揮作用的同時，DevOps也已經穩健地在業務思維方式中占有一席之地，並將在2015年扮演主要角色。在套用驅動、雲連線、移動化的大環境下，DevOps戰略將助力業務增值。2015年對於很多公司來說是DevOps之路的第一步。
緊跟行業趨勢、進行新的技術變革往往會帶來發展的陣痛，DevOps也同樣要經歷這一過程。中國及全球各地的企業正在認識到DevOps可以助力軟體開發速度加快，軟體套用質量提升，更重要的是與業務目標更完美地結合。如果說，2014年DevOps還在謀求廣泛的認可，那么2018年DevOps將走到舞台中心，被整合成為企業戰略的重要組成部分。
改變流程促進軟體質量的改進
與DevOps相伴的一個變化是向持續集成的演進。軟體開發和部署的速度是其中一個驅動因素，使得開發和運維的合併不是空談而成為必需。
大型機上使用
devops加快交付速度
devops填補了之前的空白部分，devops通過建立一個完整的生命活動周期，devops關注如何更好地獲取IT運維團隊的反饋。devops將敏捷原則套用於管理領域，devops使得開發人員和管理員可以進行毫無障礙的溝通。
devops還有很多不足，devops導致代碼交接容易出現延遲。devops同樣的情況也會出重大bug的修復過程中。
devops運行時軟體最佳化
devops可以在兩個方面提升知識水平和程式質量。首先，devops對於許多較新的、面向對象的作業系統，比如Linux，devops很有可能不關機而一直保持運行狀態。因此，devops容易出現問題，比如錯誤的垃圾回收機制以及不能正確重新組織關係型數據存儲。
devops借鑑了大型機管理員積累的經驗來重新認識軟體平台類型，以及可能引起這些類型問題的開發和/或測試流程。devops開發團隊可以使用嵌入式模式保護代碼來部署代碼庫和測試環境。
devops的目標是在測試環境中，或者devops以代碼的形式嵌入到應用程式自身當中以獲取大型機複雜性的現有知識，devops不希望大型機管理員發現問題所在。devops並不僅可以使得開發人員和測試人員的工作更加輕鬆，同樣可以簡化管理員的工作。
devops提高大型機管理員工作效率
devops可以改善這種大型機管理模式，devops提高大型機管理員的工作效率。首先，devops通過實現標準配置和Linux相關任務的自動化，devops可以保證管理員擁有更多時間來“救火”。devops通過確保解決方案是長期有效和高質量的來減少對於處理緊急情況的處理需求。此外，devops讓管理員也參與敏捷開發流程，和開發團隊進行溝通，當開發團隊擁有了一個能夠快速定位問題並且修復運行時問題的測試工具或者代碼庫之後，devops就可以減少管理員修復bug以及與開發部門協調所花費的時間。
雲套用安全
1.自動化手動安全測試
自動化在DevOps中很重要因為它提供了準確性和速度。套用交付需要高效，而手動安全測試就是不夠快。更重要的是，第三方在外部手動測試中往往會漏掉測試錯誤。
儘管組織不需要完全拋棄手動測試，他們應該將自動化過程提上日程。安全團隊應該確定如何自動實施他們的手動過程。當嵌入堅固DevOps到你現有的雲環境中時，對安全測試工具進行審核以確保可以將其加入到持續集成和套用交付過程中。然後，刪除或替換不適合DevOps的工具或者不能與你的雲業務集成的工具。
2．儘早優先處理安全性
儘管IT行業採用敏捷和DevOps過程的比例很大，安全測試周期仍然還是基於傳統繁瑣的瀑布模型。這意味著許多組織忘記做安全資格測試，如PCI檢查和風險評估，直到幾乎為時已晚。為了更有效地同步安全和DevOps周期，從開發過程一開始就進行安全測試。
3．建立跨職能團隊參與
實施堅固DevOps，安全團隊需要開發和運營團隊緊密合作。當這么做時，安全專家應該保持開放的心態去了解他們同事的文化和語言。這樣，這種關係就成了一種真正的夥伴關係而不是一種機械的形式。
4.在運營中嵌入安全工具
在一個堅固DevOps模型中，安全團隊應該讓組織的其他部門也了解安全工具。通過分享技術知識，企業將有更廣闊的勞動力，可以解決在第一線的安全問題。為了幫助小的安全團隊在更大的DevOps組織內擴展其業務影響力，可以把安全工具包括在通用的操作工具包里。
5．監控和審計集成過程
緊密監控和記錄集成和交付流程，以確保高質量的軟體。這也有助於識別安全問題。使用粒度變化日誌為審計人員準備信息，以及可擴展的雲安全監測工具。這些工具應能夠自動跟蹤和測量新添加的資源。此外，它們應匯總監測數據和快速檢測實際的問題，同時消除誤報。
