[[144535]]

引言

近日，國外有技術專家在SEI攥文盤點了當下流行的 DevOps 思想和工具，其中包括Fabric、Ansible、Docker、Chaos Monkey等。本文系OneAPM與高效運維聯(lián)合編譯整理：

在2014年年底，SEI 博客發(fā)表了一系列有關 DevOps① 的博客文章，提供指南，實用的建議和教程。這些帖子針對越來越多的采用 DevOps 的企業(yè)（2011年以來，高達26％）。

根據(jù)最近的研究②，這些組織部署變更代碼比傳統(tǒng)的方式快30倍。

盡管 DevOps 的好處顯而易見，但是許多企業(yè)仍不敢采用 DevOps，因為這需要轉變心態(tài)、文化和技術要求，對于傳統(tǒng)企業(yè)是非常大的挑戰(zhàn)。

鑒于這些障礙，CERT 研究人員的文章主要集中在介紹 Amazon③ 和 Netflix④ DevOps 的成功案例，以及一些 DevOps 流行技術的教程，如 Fabric⑤、Ansible⑤ 和 Docker⑥。

我們將介紹2015年過去的六個月，10個最流行的 DevOps 相關文章（根據(jù)訪問次數(shù)排序）。

1. DevOps技術：Fabric與Ansible

這篇博客文章中，作者重點描述了使用 DevOps 部署過程相關的情況，包括評估資源需求、設計生產(chǎn)系統(tǒng)、配置和生產(chǎn)服務器的配置、同步代碼等等。

以下為摘錄:

部署代碼的工作流程幾乎和代碼本身一樣古老。有許多與部署過程相關聯(lián)的用例，包括評估資源需求、設計一個生產(chǎn)系統(tǒng)、配置和配置生產(chǎn)服務器、同步代碼等等。

在這篇博客文章中，我將會專注于配置一個遠程服務器上的軟件包和必要的軟件來執(zhí)行您的代碼。這個用例可以使用許多不同的，相互競爭的技術完成：

如：Chef、Puppet、Fabric、Ansible、Salt、Foreman，這些只是少數(shù)你可能已經(jīng)聽到過的有關 DevOps 自動化運維之路的技術。

所有這些技術都有提供倉庫，可以提交腳本到倉庫，并完成任務。這篇文章更深入的探討了Fabric 和 Ansible。要了解更多關于其他基礎設施即代碼的解決方案，看看關于 Docker 的文章⑥或關于 Vagrant 的文章⑦。

Fabric 和 Ansible 之間的一個區(qū)別是，F(xiàn)abric 會讓你在幾分鐘內看到結果，而 Ansible 需要付出更多的努力去理解。通常來說，Ansible 是更強大的：

因為它提供了更深入和更復雜的多層架構模型的語義，如 Web 和數(shù)據(jù)庫主機陣列。

從運維的角度看，F(xiàn)abric 具有更直接和基本 API，可以使用 Python 編寫，而 Ansible 使用 YAML，提供了豐富的操作（我以后再討論這篇文章）。我們將通過這篇文章中的例子來說明。

閱讀完整的文章，DevOps 技術：Fabric 與 Ansible，請訪問：http://blog.sei.cmu.edu/post.cfm/devops-technologies-fabric-or-ansible

2. DevOps 之 Docker

閱讀完整的文章，DevOps 之 Docker，請訪問：http://blog.sei.cmu.edu/post.cfm/devops-docker-015

3.使用Docker做開發(fā)

Docker 這些日子在 DevOps 社區(qū)是相當火爆，這有很好的理由。Docker 容器使開發(fā)和部署應用軟件達到可控制的、隔離的、靈活的和高度可移植的基礎設施。

在這篇文章中，作者⑧介紹了使用 Docker 開發(fā)和部署軟件應用程序的可擴展性，資源效率，以及彈性。

以下為摘錄:

Linux 容器技術（LXC），為 Docker 的建立提供了基礎，然而這并不是一個新想法。LXC 早已出現(xiàn)在 Linux 內核2.6.24版本中，當控制族群（或 cgroups）正式被集成時。

實際上谷歌早在2006就使用了 Cgroups 技術，因為谷歌一直在尋找，在共享硬件上進行資源隔離和運行的方式。

事實上，谷歌承認每周會啟動200萬個容器，使用自己發(fā)布的 LXC 容器imctfy ⑨。

不幸的是，這種技術并不容易被采用，直到 Docker 來簡化容器技術，使它更易于使用。

在沒有 Docker 的時代，開發(fā)者很難訪問，實現(xiàn)，更不用說要理解 LXC 的優(yōu)點。DotCloud⑩創(chuàng)始人、現(xiàn)任首席技術官 Solomon Hykes 發(fā)現(xiàn) Docker 的潛力，在2013年三月份Docker作為開源項目被發(fā)布。

Docker的易用性是由于其高層次抽象的API以及文檔。這使得 DevOps 社區(qū)充滿力量，并創(chuàng)建 Docker 教程、官方化應用程序和許多其他的技術。通過降低進入容器技術的門檻，Docker 已經(jīng)改變了開發(fā)人員共享、測試和部署應用程序的方式。

在這篇文章使用 Docker 開發(fā)⑪中，Yankel 描述了如何開始使用 Docker 在一個普通的軟件開發(fā)環(huán)境開發(fā)相應的軟件，通過啟動一個數(shù)據(jù)庫容器（MongoDB），一個 Web 服務容器（Python Bottle APP），并配置它們可以互相訪問。這是一個多容器應用程序。

閱讀完整的文章，使用 Docker 開發(fā)，請訪問：http://blog.sei.cmu.edu/post.cfm/development-with-docker

4.DevOps 示例：Amazon AWS

經(jīng)常閱讀 DevOps 博客的讀者會發(fā)現(xiàn)這個系列中會反復出現(xiàn)的主題：

DevOps 本質上是通過精心的構建組織過程、加強溝通和工作流程來提升質量。

在本文⑫中，主要分享了 Amazon DevOps 的經(jīng)驗。

閱讀完整的文章， DevOps 示例：Amazon AWS， 請訪問：http://blog.sei.cmu.edu/post.cfm/devops-casestudy-amazon-aws-036

5.DevOps示例：Netfix的Chaos Monkey

DevOps 經(jīng)常被運用在如敏捷開發(fā)、自動化和持續(xù)交付，DevOps 的精神可以應用在很多方面。在這篇博客中，作者分享了另外一個具有開創(chuàng)性的 DevOps 案例研究，Netflix⑭的一些開箱即用的方式。

以下為摘錄:

Netflix 是一個奇妙的案例研究，因為他們的 DevOps 軟件工程過程，展示了一個對 DevOps 本質的了解，專注通過 DevOps 自動化輔助過程來達到質量要求。

DevOps 從業(yè)者信奉一種注重質量屬性的驅動來滿足業(yè)務需求，利用自動化過程實現(xiàn)一致性和效率。

Netflix 的流媒體服務是一個托管在AWS的大型分布式系統(tǒng)。由于這么多組件一起工作，為各個地區(qū)的客戶提供可靠的視頻流，Netflix 工程師需要側重于服務端-客戶端組件質量屬性的可靠性和魯棒性的。

總之，他們得出結論認為，處理失敗的唯一方法是不斷實踐失敗。

為了實現(xiàn)如此可信賴的，質量達標的水平，使用 DevOps 的風格，Netflix 公司的工程師開始使用自動化故障方案。

閱讀完整的文章，DevOps 示例：Netfix 的 Chaos Monkey，請訪問：http://blog.sei.cmu.edu/post.cfm/devops-case-study-netflix-and-the-chaos-monkey

#p#

6.DevOps 和敏捷開發(fā)

康威定律⑮說：設計系統(tǒng)的組織，最終產(chǎn)生的設計等同于組織之內、之間的溝通結構。

因此，一個公司的前端、后端和數(shù)據(jù)庫團隊可能會傾向于使用三層架構。在很大程度上，應用程序的結構，是由組織溝通后產(chǎn)生。簡而言之，形式是交流的產(chǎn)物。

在本文中，作者學習康威定律并應用到自己的組織。

以下為摘錄:

傳統(tǒng)的瀑布式開發(fā)模式已經(jīng)為我們的應用程序定義一個特定的溝通結構：

開發(fā)開發(fā)人員讓（QA）團隊測試并質量保證，QA 讓運維（OPS）團隊去部署。

這種方式的溝通，是非敏捷的，加重了我們有缺陷的組織結構，這又是一個印證了康威定律的例子：組織結構決定產(chǎn)品。

閱讀完整的文章， DevOps 和敏捷開發(fā)，請訪問：https://blog.sei.cmu.edu/post.cfm/devops-agile-317

7. DevOps 團隊需要 ChatOps

項目團隊關鍵利益相關者之間的對話（例如，開發(fā)人員、業(yè)務分析員、項目經(jīng)理、安全團隊），平臺之間的溝通，可以對協(xié)作產(chǎn)生深遠的影響。

較差的或甚至沒有使用通訊工具，導致溝通不暢，重復的工作，或錯誤的實現(xiàn)。另一方面，開發(fā)和業(yè)務基礎設施相結合的通信工具，可以加快向組織交付業(yè)務價值。

也就是說，一個團隊如何組織基礎設施結構，如何溝通，將直接影響團隊的效率。

在文章 DevOps 團隊需要 ChatOps 中，作者介紹了 ChatOps，DevOps 的一個分支，關注 DevOps 團隊的溝通。

ChatOps 包括了團隊的溝通和協(xié)作工具：通知、聊天服務器、機器人、問題跟蹤系統(tǒng)等等。

以下為摘錄:

在最近的一篇博客⑱中，作者寫道，ChatOps，一詞起源于GitHub上，都是關于基于對話的驅動開發(fā)方式：

“把你的工具帶到您的溝通過程中，并使用一個聊天機器人修改關鍵的插件和腳本工作，團隊可以自動執(zhí)行任務和協(xié)作工作，使工作更好、更便捷、更快”。Sigler寫道。

大多數(shù)團隊在聊天服務器上都有一定程度的合作。聊天服務器可以作為一個城市廣場一樣容納開發(fā)團隊、促進團隊之間的凝聚力、討論實際問題以及潛在解決方案等。

我們希望所有的團隊成員使用聊天服務器。在我們的團隊中，為了避免一般聊天室的灌水聊天，我們也創(chuàng)建專用聊天室，每個項目，項目團隊成員可以談論項目的細節(jié)，不涉及其他的團隊：

和其他簡單的溝通介質不一樣，聊天服務器可以智能化，開發(fā)的基礎設施，向團隊傳遞通知，團隊執(zhí)行命令并反饋回基礎設施。

我們的聊天服務器是通知的樞紐，與我們的基礎設施快速互動：

項目團隊通過聊天服務器接到通知（還有其他方法），關注基礎設施任何生成狀態(tài)，他們關注：構建失敗、構建成功、超時等。

閱讀完整的文章，DevOps團隊需要ChatOps，請訪問：http://blog.sei.cmu.edu/post.cfm/chatops-in-devops-team-029

8.DevOps之Vagrant

環(huán)境等同⑲是一個理想的、令人充滿期待的狀態(tài)。缺乏環(huán)境等同會使軟件開發(fā)陷入令人沮喪的困境。部署和開發(fā)都經(jīng)常會陷入這樣的陷阱，降低了穩(wěn)定性、可預測性和生產(chǎn)力。

當環(huán)境不等同時，這使得故障難以排除，而且難以協(xié)作。這種缺乏環(huán)境等同使開發(fā)人員和運維人員負擔太多。

在這篇博客中 DevOps 之 Vagrant ，作者描述了 Vagrant：

這是一個開發(fā)者使用的工具，提供了一個虛擬化和環(huán)境配置，Vagrant 為開發(fā)者提供了一個單一的，聲明式腳本，以及一個簡單的命令行界面。

通過使用相同的預先配置的 Vagrant 腳本，Vagrant 為所有開發(fā)者統(tǒng)一了線上的環(huán)境。在應用開發(fā)生命周期過程中，Vagrant 消除了“環(huán)境不同”的借口。

以下為摘錄:

運維團隊的作業(yè)通常包括在所有部署環(huán)境中實施全面的校驗，例如用于測試、分段和上線。

相反，開發(fā)團隊幾乎完全自己負責配置開發(fā)機器。為了達到百分之100的環(huán)境等同，兩個團隊必須使用相同的語言，使用相同的資源。

Chef和Puppet，這兩個都是為運維而生，對一個繁忙的開發(fā)人員來說可能不太友好。

Chef和Puppet都有一個比較陡的學習曲線，并沒有真正解決環(huán)境等同的問題：

開發(fā)者仍然需要和線上環(huán)境同步。

所有這些額外的工作會帶來一個相當大的開銷，而開發(fā)者只想好好的寫業(yè)務代碼！

這就是Vagrant出現(xiàn)的意義。Vagrant是一個面向開發(fā)者的工具，基本上Vagrant提供了一個虛擬化環(huán)境，提供了一個單一的，聲明式的腳本和一個簡單的命令行界面。

Vagrant通過啟動一個虛擬機（VM），去除繁重的工作，消除了人工配置或運行，例如，chef-server和chef-client。Vagrant的隱藏這一切，提供一個簡單的腳本給開發(fā)人員，一個名叫Vagrantfile無擴展項文件，可隨著代碼簽入到源代碼控制。

閱讀完整的文章，DevOps之Vagrant，請訪問：https://blog.sei.cmu.edu/post.cfm/devops-technologies-vagrant-345

9.使用DevOps解決上下文切換的不利影響

在計算系統(tǒng)中，上下文切換發(fā)生在：

操作系統(tǒng)保存一個應用程序線程的狀態(tài)，停止線程并恢復其他線程的狀態(tài)（之前停止線程），使其他線程恢復執(zhí)行。

上下文切換管理的開銷，發(fā)生在處理狀態(tài)的保存和恢復，這個過程會對操作系統(tǒng)產(chǎn)生負荷，并影響應用程序的性能。

在博客使用DevOps解決上下文切換的不利影響中，CERT研究員Todd Waits描述了如何使用DevOps改善負面影響，減少項目之間的“上下文切換”對軟件工程團隊效率的影響。

以下為摘錄:

Quality Software Management: Systems Thinking⑳, 作者在這本書中討論了，上下文切換的概念是如何適用于一個工程團隊。

從人力勞動力的角度來看，上下文切換是一個項目停止工作的過程，并在不同的項目上完成不同的任務后，將其重新?lián)炱饋怼＞拖裼嬎銠C系統(tǒng)一樣，在多個項目之間進行上下文切換時，團隊成員通常會產(chǎn)生開銷。

當團隊成員被分配到多個項目時，上下文切換通常會發(fā)生。上下文切換的合理理由是：

邏輯上來講，為團隊成員分配項目任務，比為每個項目分配專用資源更省時省力。

這似乎是合理的假設，將一個人的精力平分，對每個項目，兩者之間的項目收益率百分之50。

此外，如果一個團隊成員只在一個單獨的項目中，如果這個項目正在等待處理某些事情，比如等待書面工作審批、審查等，該小組成員將是空閑的，沒有充分利用。

使用我們計算系統(tǒng)的隱喻，任務之間的切換類似多線程概念，如果一個線程因為某些事情阻塞，其他線程可以執(zhí)行其他工作，而不是等待第一個線程直到恢復。

如果所有的工作只分配給第一個線程，進展很慢。雖然多線程在計算系統(tǒng)中很合理，問題是，人類并不總是能很好分配精力。因此效率會在上下文切時損失，生產(chǎn)力可能會在精力分散在更多的項目的時候下降。

閱讀完整的文章，使用 DevOps 解決上下文切換的不利影響，請訪問：http://blog.sei.cmu.edu/post.cfm/addressing-detrimental-effects-context-switching-devops-064

10.什么是 DevOps？

通常，當我們設想一個實現(xiàn)了 DevOps 的組織，我們可以想象一個自動化運轉良好的機器：

• 基礎設施配置

• 代碼測試

• 應用部署

最終，這些做法的結果是運用DevOps的方法和工具。DevOps適合所有規(guī)模的團隊，從一個一個人的團隊到一個企業(yè)組織。在這篇博文中，什么是DevOps，CERT研究員Todd Waits介紹了DevOps的基礎。

DevOps可以看作是敏捷方法的推廣。它要求掌握相當多的知識和技能，包括一個項目從開始到持續(xù)，到被一個專門的項目小組負責。組織壁壘必須打破。只有這樣才能有效地緩解項目風險。

以下為摘錄:

然而嚴格來說，DevOps 并不是持續(xù)集成，交付或部署。

DevOps 的做法能使團隊達到協(xié)調，理解必要的自動化基礎設施、測試和部署。特別是，DevOps 提供了組織如何保證：

• 不同項目團隊人員之間的合作；

• 基礎設施即為代碼；

• 自動化任務、過程和工作流程；

• 監(jiān)控應用和基礎設施。

商業(yè)價值驅動 DevOps 的發(fā)展。如果沒有 DevOps 的心態(tài)，組織經(jīng)常發(fā)現(xiàn)他們的運維、開發(fā)和測試團隊，目光短淺，只致力于創(chuàng)建方便自己的基礎設施、測試套件或產(chǎn)品增量。

一旦一個組織打破了這些孤島，把這些領域的專業(yè)知識整合起來，就可以把重點放在共同致力于提供商業(yè)價值的基本目標上：

組織良好的團隊會發(fā)現(xiàn)（或創(chuàng)建）工具和技術，使他們的組織實踐 DevOps。每個組織都是不同的，有不同的需求，不同的但是必須滿足的需求。

DevOps 的關鍵，并不是一個殺手級的工具或腳本，而是合作文化和傳遞價值的終極承諾。

閱讀完整的，什么是DevOps，請訪問：https://blog.sei.cmu.edu/post.cfm/what-is-devops-324

說明

每兩周，SEI 會發(fā)布一篇新的博客，為那些嘗試采用 DevOps 的組織提供指南，實用的建議和教程。我們歡迎您對本系列文章提供反饋，以及對未來內容的建議。請在下面的評論部分反饋意見。

① http://blog.sei.cmu.edu/post.cfm/what-is-devops-324
② http://readwrite.com/2014/02/11/devops-future-diy-it-gartner-nosql
③ http://blog.sei.cmu.edu/post.cfm/devops-casestudy-amazon-aws-036
④ http://blog.sei.cmu.edu/post.cfm/devops-case-study-netflix-and-the-chaos-monkey
⑤ http://blog.sei.cmu.edu/post.cfm/devops-technologies-fabric-or-ansible
⑥ http://blog.sei.cmu.edu/post.cfm/devops-docker-015
⑦ http://blog.sei.cmu.edu/post.cfm/devops-technologies-vagrant-345
⑧ http://www.sei.cmu.edu/about/people/profile.cfm?id=yankel_15790
⑨ https://github.com/google/lmctfy
⑩ https://www.dotcloud.com/
⑪ http://blog.sei.cmu.edu/post.cfm/development-with-docker
⑫ http://blog.sei.cmu.edu/post.cfm/devops-casestudy-amazon-aws-036
⑬ http://aws.amazon.com/
⑭ http://www.netflix.com/

⑮ http://en.wikipedia.org/wiki/Melvin_Conway
⑯ http://en.wikipedia.org/wiki/Conway%27s_law
⑰ http://blog.sei.cmu.edu/post.cfm/devops-agile-317
⑱ https://www.pagerduty.com/blog/what-is-chatops/
⑲ http://www.newmediacampaigns.com/blog/matching-development-production-environments
⑳ http://www.amazon.com/Quality-Software-Management-Systems-Thinking/dp/0932633722

如何一起愉快地發(fā)展

“高效運維”公眾號（如下二維碼）值得您的關注，作為高效運維系列微信群（國內領先的運維垂直社區(qū)）的唯一官方公眾號，每周發(fā)表多篇干貨滿滿的原創(chuàng)好文：來自于系列群的討論精華、運維講壇精彩分享及群友原創(chuàng)等。“高效運維”也是互聯(lián)網(wǎng)專欄《高效運維最佳實踐》及運維2.0官方公眾號。

提示：目前高效運維兩個微信主群僅有少量珍貴席位，如您愿意，可添加蕭田國個人微信號 xiaotianguo 為好友，進行申請；或申請加入我們技術交流群（技術討論為主，沒有主群那么多規(guī)矩，更熱鬧）。

重要提示：除非事先獲得授權，請在本公眾號發(fā)布2天后，才能轉載本文。尊重知識，請必須全文轉載，并包括本行及如下二維碼。