2015年12月，知名調研機構Gartner預測，“到2017年年底，市場對移動應用程序開發服務的需求會以至少比內部IT部門的交付能力快五倍的速度增長。”
由於需求和能力之間的這種不匹配，企業組織在想方設法加快開發速度。而他們日益采用的其中一種方法就是開發運維。據Gartner聲稱，2015年，企業組織在開發運維工具上花費23億美元，預計“到2016年，開發運維會從大型雲服務提供商采用的一種小眾戰略，逐漸變成25%的全球2000強企業采用的一種主流戰略。”
對於開發運維市場的規模，廠商的估計顯得尤為樂觀。2016年RightScale報告聲稱，80%的大企業和70%的中小企業(SMB)在采用開發運維。
遺憾的是，雖然許多公司在競相采用開發運維，但它們並非總是確信開發運維需要什麼。幾家不同的企業提出了彼此競爭的概念，IT行業還沒有就一種權威的定義達成共識。Gene Kim是最知名的開發運維支持者之一，與人合著有暢銷的財經小說《The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win》。他承認：“開發運維飽受诟病的方面之一是，很難描述開發運維是什麼。”
盡管缺乏標准定義，但專家們就開發運維的根本原則達成了共識。通常來說，開發運維旨在打造這樣一種文化：IT開發團隊和運維團隊非常緊密地協同工作。開發運維脫胎於敏捷開發和精益開發原則，它需要盡可能地實現流程自動化，以便加快企業組織部署新應用程序的速度。而最終目標不僅僅是提高IT效率，還在於有助於讓企業組織更成功。
來自專家的幾大高招那些核心原則大有變化和試驗的余地，許多企業組織在想：如果自己想要開始使用開發運維實踐，到底應該做些什麼。為了解答這個問題，我們請教了幾位開發運維專家，聽聽他們在開發運維的最佳實踐方面有什麼高招和建議。
1.從小處著手專家提醒，就開發運維而言，試圖一下子做太多的事情勢必會招致失敗。任何大型IT部門都會有現有的流程和根深蒂固的文化，它們根本不可能一夜之間變化。
他們建議，應該先搞一個得益於開發運維實踐的項目或團隊，從小處著手。關鍵在於選擇這樣一個項目：開發運維的成功幾率很大，它能夠為未來的開發運維工作充當基礎。
Xebia Labs的產品副總裁Tim Buntel說：“可以根據你在哪裡獲得最大的好處，進行相應的變化。評估什麼給如今你的開發和部署流程帶來了最大的麻煩，然後優先處理這一步。”
BMC的雲管理和數據中心自動化業務部的產品管理副總裁David Cramer贊同這一觀點。他說：“一開始成功很重要，那樣團隊才能樹立信心，並且為其他人樹立一個榜樣。初始團隊的成功直接影響著大規模實施變化的難易程度。項目本身也很重要，所以務必要選擇對業務來說有意義的方面。如果初始項目不是戰略性項目，人們就會輕視結果。”
2.專注於文化，而不是專注於工具最重要的一點是，采用開發運維就是改變變化。致力於自動化或購買新工具不足以帶來大多數企業組織希望實現的那種變化。
New Relic戰略營銷團隊的開發運維宣傳官Stevan Arychuk說：“一個常見的陷阱是一味關注技術，而不是文化要素。開發運維注重各個技術和運營團隊之間的信任和合作；工具和技術其實是為實現這個目標而服務的。”
Buntuel說：“大多數技術團隊認為，工具可以解決所有問題。雖然工具對開發運維轉型來說絕對很重要，但是除非輔以實際而重大的文化變化，否則它們毫無幫助。認真考慮你的業務目標，考慮信任和溝通，考慮原因。只有搞清楚了如何開始文化轉型，你才可以往技術解決方案投入時間和精力。”
3.購置實時深入了解項目的工具雖然光有技術還不夠，但是說到如何采用開發運維這個問題，工具絕對是答案的一部分。專家們表示，為了鼓勵溝通和合作，擁有讓每個人都能實時了解IT項目方面的工作進展如何的工具，至關重要。
此外，企業組織需要確保，它們使用的所有不同的團隊工具可以整合起來。企業組織購買多款旨在支持開發運維的工具，這很常見。比如說，它們可能有版本控制管理系統、錯誤跟蹤系統、溝通平台、求助平台、運維監控工具等。Buchanen表示，他“見過交付工具鏈不是很配套，導致許多團隊發生碰撞的情況。”因而，他建議“工具整合是支持開發運維方面最有幫助的技術。”
4.部署自動化技術開發運維技術另一個非常重要的部分是自動化。Buntel說：“可幫助你以一種受控制、可擴展的方式，實現流程自動化的任何技術都大有幫助。”
眾多廠商目前提供自動化工具，可以簡化配置、監控和維護網絡基礎設施這個過程。這些工具可以幫助企業組織更迅速地部署應用程序，並有助於提高IT的效率。
同樣，Docker之類的容器化技術也大有幫助。容器簡化了從開發服務器到生產服務器的轉變，消除了部署過程中的許多棘手問題。
5.加快部署速度據Puppet Lab的《2015年開發運維行情報告》聲稱，“相比表現較為遜色的IT部門，表現出色的IT部門遇到的故障要少60倍，從故障中恢復的速度卻要快168倍。它們部署的頻次也要高30倍，籌備時間縮短了200倍。”
同樣，弗雷斯特研究公司一份題為《新的軟件要務：確保質量的同時快速交付》的報告發現，“一向以最快周期交付的開發團隊能夠在業務用戶當中獲得最高的滿意度。”重要的是，能夠以最快的速度交付新應用程序的新團隊也在構建質量最高的軟件。
對大多數企業來說，加快部署速度是其開發運維項目的一個關鍵目標。為了實現這個目標，它們常常部署有望加快開發的技術，它們常常實施敏捷開發方法，比如測試驅動的開發、持續開發、持續集成、結對編程和Scrum方法。專家們表示，企業組織牢記這一點很重要：方法和技術本身並不是目標;相反，它們只是實現諸多目標的一種手段，比如加快部署、改善代碼質量以及最終為業務部門提供更好的支持。
6.加大運維團隊的反饋雖然開發運維的開發方面常常備受關注，但專家們提醒，不忘記運維很重要。如果改善運營部門內部以及運維部門和IT組織其他部門之間的溝通和合作，企業組織常常能夠獲得顯著的效率。
Atlassian的開發宣傳官Ian Buchanan說：“在許多情況下，敏捷開發已經促使開發團隊優化其交付管道。如果一開始致力於這個概念：簡化來自運維團隊的反饋，而不是借助更多的交付自動化實現局部最優化，那些團隊就能獲得更大的成效。”
7.制定衡量成效的一些KPI為什麼你在向開發運維轉變?你怎麼才能知道轉型是否成功?專家們表示，在實施開發運維之前問答這些問題是個好主意。理想情況下，開發運維應該對你為公司跟蹤的一些關鍵績效指標(KPI)有積極的影響。
New Relic戰略營銷團隊的開發運維宣傳官Stevan Arychuk認為：“一定要搞清楚你為什麼實施開發運維方法，並制定一套清晰的框架來衡量成效。開發運維的真正價值最終意味著，技術能夠更好地利用起來，具有更大的靈活性，從而支持業務，所以行之有效的開發運維戰略應該是能夠使用KPI量化給業務帶來的積極影響。”
8.改變業務流程，與你的開發節奏相一致你改變IT流程後，它同樣會影響業務的其他方面。Cramer建議要有“全局觀”。他解釋：“改變業務流程以便與來自開發運維的新版本發布節奏相一致，這很重要。比如說，營銷團隊可能落實了流程，專注於傳統的年度或半年度產品發布周期，如果發布的版本規模要小得多、頻次高得多，它們不知道如何改變流程。另一個例子就是內部治理流程，需要深入了解12個月的發布計劃。”
IT領導人需要確保，除了開發團隊和運維團隊外，他們還在與另外這些部門溝通和合作。實際上，實施了開發運維的許多企業組織表示，這個理念背後的原則有助於另外許多內部團隊，而不是僅僅有助於IT部門。
9.參與開發運維社區由於那麼多的企業在采用開發運維，企業組織不需要“重新發明輪子。”專家們表示，如果公司參與開發運維會議或在線社區，並且與實施類似項目的其他企業組織積極交流，就會大有收獲。
Buchanen特別指出：“確保開發運維切實可行的理念、實踐和工具在不斷改進。你的人員需要利用社區來驗證理念、衡量進度，並且找到進一步改進的靈感來源。別害怕講述自己的故事，不管你在開發運維這條道路上處於什麼階段。總是會有另一家公司會覺得你的故事對它大有助益。”
開發運維的最佳實踐：是旅程，不是終點隨著企業組織積極實施這些開發運維的最佳實踐，它們應該牢記：采用開發運維是個長期過程。不像ITIL、敏捷開發或精益制造等其他IT管理實踐，開發運維與其說是一種具體的框架或一套具體的實踐，更不如說是一股潮流和一種理念。
在大多數情況下，企業不會達到可以說自己“實現了開發運維”的狀態。相反，它們在不斷嘗試新工具和新流程，試圖找到幫助自己將開發和運維更緊密地整合起來的工具和流程，最終為業務部門改善成效。
原文來自：http://os.51cto.com/art/201606/513406.htm
本文地址：http://www.linuxprobe.com/nine-practices-devops.html
http://xxxxxx/Linuxjc/1155784.html TechArticle
