一篇文章了解DevOps究竟是什麼鬼？

目前在國外，互聯網巨頭如Google、Facebook、Amazon、LinkedIn、Netflix、Airbnb，傳統軟體公司如Adobe、IBM、Microsoft、SAP等，亦或是網路業務非核心企業如蘋果、沃爾瑪、索尼影視娛樂、星巴克等都在採用DevOps或提供相關支持產品。那麼DevOps究竟是怎樣一回事？

本文主要結構如下，讀完大概需要10分鐘

1. DevOps是什麼？從哪裡來？

2. DevOps的幾個關鍵問題

3. 為什麼DevOps會興起？為什麼會繼續火下去？

4. 實現DevOps需要什麼？

5. DevOps的採用現狀

DevOps是什麼？從哪裡來？

DevOps的概念

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

DevOps概念早先升溫於2009年的歐洲，因傳統模式的運維之痛而生。

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

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

歷史變革

由上所述，相信大家對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

在工具的選擇上，需要結合公司業務需求和技術團隊情況而定。

軟性需求：文化和人

GIF/371K

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

2016年倫敦企業級DevOps峰會的ITV公司在2012年就開始落地DevOps，其通用平台主管Clark在接受了InfoQ的採訪，在談及成功時表示，業務人員非常清楚他們希望在最小化可行產品中實現什麼，工程師們就按需交付，不做多餘工作。這樣，工程師們使用通用的平台（即打通的工具鏈）得到更好的一致性和更高的質量。

總結

DevOps是一種思維方式。我們所有人都是該系統流程的一部分，我們一起分享共同的時光和交付價值。每個參加到這個軟體交付流程上來的成員都能夠加速或減緩整個系統的運作速度。系統出現的一個缺陷，以及錯誤配置的團隊之間的 「防火牆」，都可能會使得整個系統癱瘓。所有的人都是DevOps的一部分，一旦你的組織明白了這一點，能夠幫你管理好這些工具和技術棧就自然而然的會出現在你眼前了。

本文章由春曉公司郄朋龍推薦發布！

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！