DevOps簡介

DevOps 是一個完整的面向IT運維的工做流，以 IT 自動化以及持續集成（CI）、持續部署（CD）爲基礎，來優化程式開發、測試、系統運維等全部環節。

 

 

DevOps的概念

DevOps一詞的來自於Development和Operations的組合，突出重視軟件開發人員和運維人員的溝通合做，經過自動化流程來使得軟件構建、測試、發佈更加快捷、頻繁和可靠。

DevOps是爲了填補開發端和運維端之間的信息鴻溝，改善團隊之間的協做關係。不過須要澄清的一點是，從開發到運維，中間還有測試環節。DevOps其實包含了三個部分：開發、測試和運維。

 

 換句話說，DevOps但願作到的是軟件產品交付過程當中IT工具鏈的打通，使得各個團隊減小時間損耗，更加高效地協同工做。專家們總結出了下面這個DevOps能力圖，良好的閉環能夠大大增長總體的產出。

歷史變革

由上所述，相信你們對DevOps有了必定的瞭解。可是除了觸及工具鏈以外，做爲文化和技術的方法論，DevOps還須要公司在組織文化上的變革。回顧軟件行業的研發模式，能夠發現大體有三個階段：瀑布式開發、敏捷開發、DevOps。

DevOps早在九年前就有人提出來，可是，爲何這兩年纔開始受到愈來愈多的企業重視和實踐呢？由於DevOps的發展是獨木不成林的，如今有愈來愈多的技術支撐。微服務架構理念、容器技術使得DevOps的實施變得更加容易，計算能力提高和雲環境的發展使得快速開發的產品能夠馬上得到更普遍的使用。

好處是什麼？

DevOps的一個巨大好處就是能夠高效交付，這也正好是它的初衷。Puppet和DevOps Research and Assessment (DORA) 主辦了2016年DevOps調查報告，根據全球4600位各IT公司的技術工做者的提交數據統計，得出高效公司平均每一年能夠完成1460次部署。

與低效組織相比，高效組織的部署頻繁200倍，產品投入使用速度快2555倍，服務恢復速度快24倍。在工做內容的時間分配上，低效者要多花22%的時間用在爲規劃好或者重複工做上，而高效者卻能夠多花29%的時間用在新的工做上。因此這裏的高效不只僅指公司產出的效率提升，還指員工的工做質量獲得提高。

DevOps另一個好處就是會改善公司組織文化、提升員工的參與感。員工們變得更高效，也更有知足和成就感；調查顯示高效員工的僱員淨推薦值（eNPS:employee Net Promoter Score）更高，即對公司更加認同。

快速部署同時提升IT穩定性。這難道不矛盾嗎？

快速的部署其實能夠幫助更快地發現問題，產品被更快地交付到用戶手中，團隊能夠更快地獲得用戶的反饋，從而進行更快地響應。並且，DevOps小步快跑的形式帶來的變化是比較小的，出現問題的誤差每次都不會太大，修復起來也會相對容易一些。

所以，認爲速度就意味着危險是一種偏見。此外，滯後軟件服務的發佈也並不必定會徹底地避免問題，在競爭日益激烈的IT行業，這反而可能錯失了軟件的發佈時機

爲何DevOps會興起？

爲何會繼續火下去？

條件成熟：技術配套發展

技術的發展使得DevOps有了更多的配合。早期時，你們雖然意識到了這個問題的，可是苦於當時沒有完善豐富的技術工具，是一種「理想很豐滿，可是現實很骨感」的狀況。DevOps的實現能夠基於新興的容器技術；也能夠在自動化運維工具Puppet、SaltStack、Ansible以後的延伸；還能夠構建在傳統的Cloud Foundry、OpenShift等PaaS廠商之上。

來自市場的外部需求：這世界變化太快

IT行業已經愈來愈與市場的經濟發展緊密掛鉤，專家們認爲IT將會有支持中心變成利潤驅動中心。事實上，這個變化已經開始了，這不只體如今Google、蘋果這些大企業中，並且也發生在傳統行業中，好比出租車業務中的Uber、酒店連鎖行業中的Airbnb、圖書經銷商Amazon等等。可否讓公司的IT配套方案及時跟上市場需求的步伐，在今天顯得相當重要。

DevOps 2016年度報告給出了一個運維成本的計算公式： 
停機費用成本 = 部署頻率 * 版本迭代失敗機率 * 平均修復時間 * 斷電的金錢損失

來自團隊的內在動力：工程師也須要

對於工程師而言，他們也是DevOps的受益者。微軟資深工程師Scott Hanselman說過「對於開發者而言，最有力的工具就是自動化工具」（The most powerful tool we have as developers is automation）。

工具鏈的打通使得開發者們在交付軟件時能夠完成生產環境的構建、測試和運行；正如Amazon的VP兼CTO Werner Vogels那句讓人印象深入的話：「誰開發誰運行」。（You build it, you run it）

實現DevOps須要什麼？

硬性要求：工具上的準備

上文提到了工具鏈的打通，那麼工具天然就須要作好準備。現將工具類型及對應的不徹底列舉整理以下：

• 代碼管理（SCM）：GitHub、GitLab、BitBucket、SubVersion

• 構建工具：Ant、Gradle、maven

• 自動部署：Capistrano、CodeDeploy

• 持續集成（CI）：Bamboo、Hudson、Jenkins

• 配置管理：Ansible、Chef、Puppet、SaltStack、ScriptRock GuardRail

• 容器：Docker、LXC、第三方廠商如AWS

• 編排：Kubernetes、Core、Apache Mesos、DC/OS

• 服務註冊與發現：Zookeeper、etcd、Consul

• 腳本語言：python、ruby、shell

• 日誌管理：ELK、Logentries

• 系統監控：Datadog、Graphite、Icinga、Nagios

• 性能監控：AppDynamics、New Relic、Splunk

• 壓力測試：JMeter、Blaze Meter、loader.io

• 預警：PagerDuty、pingdom、廠商自帶如AWS SNS

• HTTP加速器：Varnish

• 消息總線：ActiveMQ、SQS

• 應用服務器：Tomcat、JBoss

• Web服務器：Apache、Nginx、IIS

• 數據庫：MySQL、Oracle、PostgreSQL等關係型數據庫；cassandra、mongoDB、redis等NoSQL數據庫

• 項目管理（PM）：Jira、Asana、Taiga、Trello、Basecamp、Pivotal Tracker

在工具的選擇上，須要結合公司業務需求和技術團隊狀況而定。（注：更多關於工具的詳細介紹能夠參見此文：51 Best DevOps Tools for #DevOps Engineers）

軟性需求：文化和人

DevOps成功與否，公司組織是否利於協做是關鍵。開發人員和運維人員能夠良好溝通互相學習，從而擁有高生產力。而且協做也存在於業務人員與開發人員之間。

出席了2016年倫敦企業級DevOps峯會的ITV公司在2012年就開始落地DevOps，其通用平臺主管Clark在接受了InfoQ的採訪，在談及成功時表示，業務人員很是清楚他們但願在最小化可行產品中實現什麼，工程師們就按需交付，不作多餘工做。

這樣，工程師們使用通用的平臺（即打通的工具鏈）獲得更好的一致性和更高的質量。此外，DevOps對工程師我的的要求也提升了，不少專家也認爲招募到優秀的人才也是一個挑戰。

DevOps的採用現狀

哪些公司在用？

DevOps正在增加，尤爲是在大企業中：調查發現，DevOps的接受度有了顯著提升。74%的受訪者已經接受了DevOps，而去年這一比例爲66%。目前，在81%的大企業開始接受DevOps，中小企業的接受度僅爲70%。

那麼具體而言都有些公司在採用DevOps呢？Adobe、Amazon、Apple、Airbnb、Ebay、Etsy、Facebook、LinkedIn、Netflix、NASA、Starbucks、Target（泛歐實時全額自動清算系統）、Walmart、Sony等等。

他們怎麼實施的？

首先，大企業正在自下而上接受DevOps，其中業務單位或部門（31%）以及項目和團隊（29%）已經實施DevOps。不過，只有21%的大企業在整個公司範圍內採用了DevOps。 

其次，在工具層面上，DevOps工具的用量大幅激增。Chef和Puppet依然是最經常使用的DevOps工具，使用率均爲32%。Docker是年增加率最快的工具，用量增加一倍以上。Ansible的用量也有顯著增長，使用率從10%翻倍至20%。

 

 

現狀

編輯

不少組織將開發和系統管理劃分紅不一樣的部門。開發部門的驅動力一般是「頻繁交付新特性」，而運營部門則更關注IT服務的可靠性和IT成本投入的效率。二者目標的不匹配，就在開發與運營部門之間形成了鴻溝，從而減慢了IT交付業務價值的速度  [3] 。

開發人員常常不考慮本身寫的代碼會對運營形成什麼影響。他們在交付代碼以前，並不邀請運營人員參與架構決策或 代碼評審。

開發人員對配置或環境進行修改以後，常常沒有及時與運營人員 溝通，致使新的代碼不能運行。

開發人員在本身的機器上手工修改配置，而沒有記錄全部須要的步驟。想找到必要的配置參數，一般須要嘗試不少不一樣的參數；在獲得一個可工做的狀態後，每每很難識別出經過哪些最小步驟就能到達該狀態。

開發人員傾向於使用有利於快速開發的工具：對代碼修改更快的反饋，更低的內存消耗，等等。這樣的工具集與運營人員面對的目標運行時環境很是不一樣：後者對穩定性和性能的要求遠勝於靈活性。

因爲開發人員平時使用桌面電腦，他們傾向於使用爲桌面用戶優化的操做系統。生產環境的運行時系統一般都運行 服務器操做系統上。

在開發過程當中，系統在開發者的 本地機器上運行。在運營過程當中，系統常常分佈在多臺服務器上，例如web服務器、 應用服務器、 數據庫服務器等等。

開發是由功能性需求（一般與業務需求直接相關）驅動的。

運營是由非功能性需求（例如可得到性、可靠性、性能等）驅動的。

運營人員但願儘可能避免修改功能，從而下降知足非功能性需求的風險

若是拒絕了小的修改，但給定時間段內須要修改的總量不變，那麼每次變動的規模就會變大

變動規模越大，風險也越大，由於其中涉及的區域越多

因爲運營人員嘗試避免變動，新功能流入生產環境的速度所以被延緩，從而延緩了開發人員將特性交付給用戶使用的速度。

運營人員可能對應用程序內部缺少了解，從而難以正確地選擇運行時環境和發佈流程。

開發人員可能對運行時環境缺少了解，從而難以正確地對代碼進行調整。