在2014年年底，SEI 博客發表了一系列有關 DevOps① 的博客文章，提供指南，實用的建議和教程。這些帖子針對越來越多的采用 DevOps 的企業（2011年以來，高達26％）。
根據最近的研究②，這些組織部署變更代碼比傳統的方式快30倍。
盡管 DevOps 的好處顯而易見，但是許多企業仍不敢采用 DevOps，因為這需要轉變心態、文化和技術要求，對于傳統企業是非常大的挑戰。
鑒于這些障礙，CERT 研究人員的文章主要集中在介紹 Amazon③ 和 Netflix④ DevOps 的成功案例，以及一些 DevOps 流行技術的教程，如 Fabric⑤、Ansible⑤ 和 Docker⑥。
我們將介紹2015年過去的六個月，10個最流行的 DevOps 相關文章（根據訪問次數排序）。
1. DevOps技術：Fabric與Ansible
這篇博客文章中，作者重點描述了使用 DevOps 部署過程相關的情況，包括評估資源需求、設計生產系統、配置和生產服務器的配置、同步代碼等等。
以下為摘錄:
部署代碼的工作流程幾乎和代碼本身一樣古老。有許多與部署過程相關聯的用例，包括評估資源需求、設計一個生產系統、配置和配置生產服務器、同步代碼等等。
在這篇博客文章中，我將會專注于配置一個遠程服務器上的軟件包和必要的軟件來執行您的代碼。這個用例可以使用許多不同的，相互競爭的技術完成：
如：Chef、Puppet、Fabric、Ansible、Salt、Foreman，這些只是少數你可能已經聽到過的有關 DevOps 自動化運維之路的技術。
所有這些技術都有提供倉庫，可以提交腳本到倉庫，并完成任務。這篇文章更深入的探討了Fabric 和 Ansible。要了解更多關于其他基礎設施即代碼的解決方案，看看關于 Docker 的文章⑥或關于 Vagrant 的文章⑦。
Fabric 和 Ansible 之間的一個區別是，Fabric 會讓你在幾分鐘內看到結果，而 Ansible 需要付出更多的努力去理解。通常來說，Ansible 是更強大的：
因為它提供了更深入和更復雜的多層架構模型的語義，如 Web 和數據庫主機陣列。
從運維的角度看，Fabric 具有更直接和基本 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做開發
Docker 這些日子在 DevOps 社區是相當火爆，這有很好的理由。Docker 容器使開發和部署應用軟件達到可控制的、隔離的、靈活的和高度可移植的基礎設施。
在這篇文章中，作者⑧介紹了使用 Docker 開發和部署軟件應用程序的可擴展性，資源效率，以及彈性。
以下為摘錄:
Linux 容器技術（LXC），為 Docker 的建立提供了基礎，然而這并不是一個新想法。LXC 早已出現在 Linux 內核2.6.24版本中，當控制族群（或 cgroups）正式被集成時。
實際上谷歌早在2006就使用了 Cgroups 技術，因為谷歌一直在尋找，在共享硬件上進行資源隔離和運行的方式。
事實上，谷歌承認每周會啟動200萬個容器，使用自己發布的 LXC 容器imctfy ⑨。
不幸的是，這種技術并不容易被采用，直到 Docker 來簡化容器技術，使它更易于使用。
在沒有 Docker 的時代，開發者很難訪問，實現，更不用說要理解 LXC 的優點。DotCloud⑩創始人、現任首席技術官 Solomon Hykes 發現 Docker 的潛力，在2013年三月份Docker作為開源項目被發布。
Docker的易用性是由于其高層次抽象的API以及文檔。這使得 DevOps 社區充滿力量，并創建 Docker 教程、官方化應用程序和許多其他的技術。通過降低進入容器技術的門檻，Docker 已經改變了開發人員共享、測試和部署應用程序的方式。
在這篇文章使用 Docker 開發 中，Yankel 描述了如何開始使用 Docker 在一個普通的軟件開發環境開發相應的軟件，通過啟動一個數據庫容器（MongoDB），一個 Web 服務容器（Python Bottle APP），并配置它們可以互相訪問。這是一個多容器應用程序。
閱讀完整的文章，使用 Docker 開發，請訪問
http://blog.sei.cmu.edu/post.cfm/development-with-docker
4.DevOps 示例：Amazon AWS
經常閱讀 DevOps 博客的讀者會發現這個系列中會反復出現的主題：
DevOps 本質上是通過精心的構建組織過程、加強溝通和工作流程來提升質量。
在本文 中，主要分享了 Amazon DevOps 的經驗。
閱讀完整的文章， DevOps 示例：Amazon AWS， 請訪問
http://blog.sei.cmu.edu/post.cfm/devops-casestudy-amazon-aws-036
5.DevOps示例：Netfix的Chaos Monkey
DevOps 經常被運用在如敏捷開發、自動化和持續交付，DevOps 的精神可以應用在很多方面。在這篇博客中，作者分享了另外一個具有開創性的 DevOps 案例研究，Netflix 的一些開箱即用的方式。
以下為摘錄:
Netflix 是一個奇妙的案例研究，因為他們的 DevOps 軟件工程過程，展示了一個對 DevOps 本質的了解，專注通過 DevOps 自動化輔助過程來達到質量要求。
DevOps 從業者信奉一種注重質量屬性的驅動來滿足業務需求，利用自動化過程實現一致性和效率。
Netflix 的流媒體服務是一個托管在AWS的大型分布式系統。由于這么多組件一起工作，為各個地區的客戶提供可靠的視頻流，Netflix 工程師需要側重于服務端-客戶端組件質量屬性的可靠性和魯棒性的。
總之，他們得出結論認為，處理失敗的唯一方法是不斷實踐失敗。
為了實現如此可信賴的，質量達標的水平，使用 DevOps 的風格，Netflix 公司的工程師開始使用自動化故障方案。
閱讀完整的文章，DevOps 示例：Netfix 的 Chaos Monkey，請訪問
http://blog.sei.cmu.edu/post.cfm/devops-case-study-netflix-and-the-chaos-monkey
6.DevOps 和敏捷開發
康威定律 說：設計系統的組織，最終產生的設計等同于組織之內、之間的溝通結構。
因此，一個公司的前端、后端和數據庫團隊可能會傾向于使用三層架構。在很大程度上，應用程序的結構，是由組織溝通后產生。簡而言之，形式是交流的產物。
在本文中，作者學習康威定律并應用到自己的組織。
以下為摘錄:
傳統的瀑布式開發模式已經為我們的應用程序定義一個特定的溝通結構：
開發開發人員讓（QA）團隊測試并質量保證，QA 讓運維（OPS）團隊去部署。
這種方式的溝通，是非敏捷的，加重了我們有缺陷的組織結構，這又是一個印證了康威定律的例子：組織結構決定產品。
閱讀完整的文章， DevOps 和敏捷開發，請訪問
https://blog.sei.cmu.edu/post.cfm/devops-agile-317
7. DevOps 團隊需要 ChatOps
項目團隊關鍵利益相關者之間的對話（例如，開發人員、業務分析員、項目經理、安全團隊），平臺之間的溝通，可以對協作產生深遠的影響。
較差的或甚至沒有使用通訊工具，導致溝通不暢，重復的工作，或錯誤的實現。另一方面，開發和業務基礎設施相結合的通信工具，可以加快向組織交付業務價值。
也就是說，一個團隊如何組織基礎設施結構，如何溝通，將直接影響團隊的效率。
在文章 DevOps 團隊需要 ChatOps 中，作者介紹了 ChatOps，DevOps 的一個分支，關注 DevOps 團隊的溝通。
ChatOps 包括了團隊的溝通和協作工具：通知、聊天服務器、機器人、問題跟蹤系統等等。
以下為摘錄:
在最近的一篇博客 中，作者寫道，ChatOps，一詞起源于GitHub上，都是關于基于對話的驅動開發方式：
“把你的工具帶到您的溝通過程中，并使用一個聊天機器人修改關鍵的插件和腳本工作，團隊可以自動執行任務和協作工作，使工作更好、更便捷、更快”。Sigler寫道。
大多數團隊在聊天服務器上都有一定程度的合作。聊天服務器可以作為一個城市廣場一樣容納開發團隊、促進團隊之間的凝聚力、討論實際問題以及潛在解決方案等。
我們希望所有的團隊成員使用聊天服務器。在我們的團隊中，為了避免一般聊天室的灌水聊天，我們也創建專用聊天室，每個項目，項目團隊成員可以談論項目的細節，不涉及其他的團隊：
和其他簡單的溝通介質不一樣，聊天服務器可以智能化，開發的基礎設施，向團隊傳遞通知，團隊執行命令并反饋回基礎設施。
我們的聊天服務器是通知的樞紐，與我們的基礎設施快速互動：
項目團隊通過聊天服務器接到通知（還有其他方法），關注基礎設施任何生成狀態，他們關注：構建失敗、構建成功、超時等。
閱讀完整的文章，DevOps團隊需要ChatOps，請訪問
http://blog.sei.cmu.edu/post.cfm/chatops-in-devops-team-029
8.DevOps之Vagrant
環境等同 是一個理想的、令人充滿期待的狀態。缺乏環境等同會使軟件開發陷入令人沮喪的困境。部署和開發都經常會陷入這樣的陷阱，降低了穩定性、可預測性和生產力。
當環境不等同時，這使得故障難以排除，而且難以協作。這種缺乏環境等同使開發人員和運維人員負擔太多。
在這篇博客中 DevOps 之 Vagrant ，作者描述了 Vagrant：
這是一個開發者使用的工具，提供了一個虛擬化和環境配置，Vagrant 為開發者提供了一個單一的，聲明式腳本，以及一個簡單的命令行界面。
通過使用相同的預先配置的 Vagrant 腳本，Vagrant 為所有開發者統一了線上的環境。在應用開發生命周期過程中，Vagrant 消除了“環境不同”的借口。
以下為摘錄:
運維團隊的作業通常包括在所有部署環境中實施全面的校驗，例如用于測試、分段和上線。
相反，開發團隊幾乎完全自己負責配置開發機器。為了達到百分之100的環境等同，兩個團隊必須使用相同的語言，使用相同的資源。
Chef和Puppet，這兩個都是為運維而生，對一個繁忙的開發人員來說可能不太友好。
Chef和Puppet都有一個比較陡的學習曲線，并沒有真正解決環境等同的問題：
開發者仍然需要和線上環境同步。
所有這些額外的工作會帶來一個相當大的開銷，而開發者只想好好的寫業務代碼！
這就是Vagrant出現的意義。Vagrant是一個面向開發者的工具，基本上Vagrant提供了一個虛擬化環境，提供了一個單一的，聲明式的腳本和一個簡單的命令行界面。
Vagrant通過啟動一個虛擬機（VM），去除繁重的工作，消除了人工配置或運行，例如，chef-server和chef-client。Vagrant的隱藏這一切，提供一個簡單的腳本給開發人員，一個名叫Vagrantfile無擴展項文件，可隨著代碼簽入到源代碼控制。
閱讀完整的文章，DevOps之Vagrant，請訪問
https://blog.sei.cmu.edu/post.cfm/devops-technologies-vagrant-345
9.使用DevOps解決上下文切換的不利影響
在計算系統中，上下文切換發生在：
操作系統保存一個應用程序線程的狀態，停止線程并恢復其他線程的狀態（之前停止線程），使其他線程恢復執行。
上下文切換管理的開銷，發生在處理狀態的保存和恢復，這個過程會對操作系統產生負荷，并影響應用程序的性能。
在博客使用DevOps解決上下文切換的不利影響中，CERT研究員Todd Waits描述了如何使用DevOps改善負面影響，減少項目之間的“上下文切換”對軟件工程團隊效率的影響。
以下為摘錄:
Quality Software Management: Systems Thinking , 作者在這本書中討論了，上下文切換的概念是如何適用于一個工程團隊。
從人力勞動力的角度來看，上下文切換是一個項目停止工作的過程，并在不同的項目上完成不同的任務后，將其重新撿起來。就像計算機系統一樣，在多個項目之間進行上下文切換時，團隊成員通常會產生開銷。
當團隊成員被分配到多個項目時，上下文切換通常會發生。上下文切換的合理理由是：
邏輯上來講，為團隊成員分配項目任務，比為每個項目分配專用資源更省時省力。
這似乎是合理的假設，將一個人的精力平分，對每個項目，兩者之間的項目收益率百分之50。
此外，如果一個團隊成員只在一個單獨的項目中，如果這個項目正在等待處理某些事情，比如等待書面工作審批、審查等，該小組成員將是空閑的，沒有充分利用。
使用我們計算系統的隱喻，任務之間的切換類似多線程概念，如果一個線程因為某些事情阻塞，其他線程可以執行其他工作，而不是等待第一個線程直到恢復。
如果所有的工作只分配給第一個線程，進展很慢。雖然多線程在計算系統中很合理，問題是，人類并不總是能很好分配精力。因此效率會在上下文切時損失，生產力可能會在精力分散在更多的項目的時候下降。
閱讀完整的文章，使用 DevOps 解決上下文切換的不利影響，請訪問
http://blog.sei.cmu.edu/post.cfm/addressing-detrimental-effects-context-switching-devops-064
10.什么是 DevOps？
通常，當我們設想一個實現了 DevOps 的組織，我們可以想象一個自動化運轉良好的機器：
基礎設施配置
代碼測試
應用部署
最終，這些做法的結果是運用DevOps的方法和工具。DevOps適合所有規模的團隊，從一個一個人的團隊到一個企業組織。在這篇博文中，什么是DevOps，CERT研究員Todd Waits介紹了DevOps的基礎。
DevOps可以看作是敏捷方法的推廣。它要求掌握相當多的知識和技能，包括一個項目從開始到持續，到被一個專門的項目小組負責。組織壁壘必須打破。只有這樣才能有效地緩解項目風險。
以下為摘錄:
然而嚴格來說，DevOps 并不是持續集成，交付或部署。
DevOps 的做法能使團隊達到協調，理解必要的自動化基礎設施、測試和部署。特別是，DevOps 提供了組織如何保證：
不同項目團隊人員之間的合作；
基礎設施即為代碼；
自動化任務、過程和工作流程；
監控應用和基礎設施。
商業價值驅動 DevOps 的發展。如果沒有 DevOps 的心態，組織經常發現他們的運維、開發和測試團隊，目光短淺，只致力于創建方便自己的基礎設施、測試套件或產品增量。
一旦一個組織打破了這些孤島，把這些領域的專業知識整合起來，就可以把重點放在共同致力于提供商業價值的基本目標上：
組織良好的團隊會發現（或創建）工具和技術，使他們的組織實踐 DevOps。每個組織都是不同的，有不同的需求，不同的但是必須滿足的需求。
DevOps 的關鍵，并不是一個殺手級的工具或腳本，而是合作文化和傳遞價值的終極承諾。
閱讀完整的，什么是DevOps，請訪問
https://blog.sei.cmu.edu/post.cfm/what-is-devops-324
京公網安備 11010502049343號