[[144535]]

引言

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

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

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

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

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

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

1. DevOps技術(shù)：Fabric與Ansible

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

以下為摘錄:

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

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

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

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

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

因?yàn)樗峁┝烁钊牒透鼜?fù)雜的多層架構(gòu)模型的語(yǔ)義，如 Web 和數(shù)據(jù)庫(kù)主機(jī)陣列。

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

閱讀完整的文章，DevOps 技術(shù)：Fabric 與 Ansible，請(qǐng)?jiān)L問：http://blog.sei.cmu.edu/post.cfm/devops-technologies-fabric-or-ansible

2. DevOps 之 Docker

閱讀完整的文章，DevOps 之 Docker，請(qǐng)?jiān)L問：http://blog.sei.cmu.edu/post.cfm/devops-docker-015

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

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

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

以下為摘錄:

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

實(shí)際上谷歌早在2006就使用了 Cgroups 技術(shù)，因?yàn)楣雀枰恢痹趯ふ遥诠蚕碛布线M(jìn)行資源隔離和運(yùn)行的方式。

事實(shí)上，谷歌承認(rèn)每周會(huì)啟動(dòng)200萬(wàn)個(gè)容器，使用自己發(fā)布的 LXC 容器imctfy ⑨。

不幸的是，這種技術(shù)并不容易被采用，直到 Docker 來簡(jiǎn)化容器技術(shù)，使它更易于使用。

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

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

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

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

4.DevOps 示例：Amazon AWS

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

DevOps 本質(zhì)上是通過精心的構(gòu)建組織過程、加強(qiáng)溝通和工作流程來提升質(zhì)量。

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

閱讀完整的文章， DevOps 示例：Amazon AWS， 請(qǐng)?jiān)L問：http://blog.sei.cmu.edu/post.cfm/devops-casestudy-amazon-aws-036

5.DevOps示例：Netfix的Chaos Monkey

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

以下為摘錄:

Netflix 是一個(gè)奇妙的案例研究，因?yàn)樗麄兊?DevOps 軟件工程過程，展示了一個(gè)對(duì) DevOps 本質(zhì)的了解，專注通過 DevOps 自動(dòng)化輔助過程來達(dá)到質(zhì)量要求。

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

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

總之，他們得出結(jié)論認(rèn)為，處理失敗的唯一方法是不斷實(shí)踐失敗。

為了實(shí)現(xiàn)如此可信賴的，質(zhì)量達(dá)標(biāo)的水平，使用 DevOps 的風(fēng)格，Netflix 公司的工程師開始使用自動(dòng)化故障方案。

閱讀完整的文章，DevOps 示例：Netfix 的 Chaos Monkey，請(qǐng)?jiān)L問：http://blog.sei.cmu.edu/post.cfm/devops-case-study-netflix-and-the-chaos-monkey

#p#

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

康威定律⑮說：設(shè)計(jì)系統(tǒng)的組織，最終產(chǎn)生的設(shè)計(jì)等同于組織之內(nèi)、之間的溝通結(jié)構(gòu)。

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

在本文中，作者學(xué)習(xí)康威定律并應(yīng)用到自己的組織。

以下為摘錄:

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

開發(fā)開發(fā)人員讓（QA）團(tuán)隊(duì)測(cè)試并質(zhì)量保證，QA 讓運(yùn)維（OPS）團(tuán)隊(duì)去部署。

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

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

7. DevOps 團(tuán)隊(duì)需要 ChatOps

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

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

也就是說，一個(gè)團(tuán)隊(duì)如何組織基礎(chǔ)設(shè)施結(jié)構(gòu)，如何溝通，將直接影響團(tuán)隊(duì)的效率。

在文章 DevOps 團(tuán)隊(duì)需要 ChatOps 中，作者介紹了 ChatOps，DevOps 的一個(gè)分支，關(guān)注 DevOps 團(tuán)隊(duì)的溝通。

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

以下為摘錄:

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

“把你的工具帶到您的溝通過程中，并使用一個(gè)聊天機(jī)器人修改關(guān)鍵的插件和腳本工作，團(tuán)隊(duì)可以自動(dòng)執(zhí)行任務(wù)和協(xié)作工作，使工作更好、更便捷、更快”。Sigler寫道。

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

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

和其他簡(jiǎn)單的溝通介質(zhì)不一樣，聊天服務(wù)器可以智能化，開發(fā)的基礎(chǔ)設(shè)施，向團(tuán)隊(duì)傳遞通知，團(tuán)隊(duì)執(zhí)行命令并反饋回基礎(chǔ)設(shè)施。

我們的聊天服務(wù)器是通知的樞紐，與我們的基礎(chǔ)設(shè)施快速互動(dòng)：

項(xiàng)目團(tuán)隊(duì)通過聊天服務(wù)器接到通知（還有其他方法），關(guān)注基礎(chǔ)設(shè)施任何生成狀態(tài)，他們關(guān)注：構(gòu)建失敗、構(gòu)建成功、超時(shí)等。

閱讀完整的文章，DevOps團(tuán)隊(duì)需要ChatOps，請(qǐng)?jiān)L問：http://blog.sei.cmu.edu/post.cfm/chatops-in-devops-team-029

8.DevOps之Vagrant

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

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

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

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

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

以下為摘錄:

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

相反，開發(fā)團(tuán)隊(duì)幾乎完全自己負(fù)責(zé)配置開發(fā)機(jī)器。為了達(dá)到百分之100的環(huán)境等同，兩個(gè)團(tuán)隊(duì)必須使用相同的語(yǔ)言，使用相同的資源。

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

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

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

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

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

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

閱讀完整的文章，DevOps之Vagrant，請(qǐng)?jiān)L問：https://blog.sei.cmu.edu/post.cfm/devops-technologies-vagrant-345

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

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

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

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

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

以下為摘錄:

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

從人力勞動(dòng)力的角度來看，上下文切換是一個(gè)項(xiàng)目停止工作的過程，并在不同的項(xiàng)目上完成不同的任務(wù)后，將其重新?lián)炱饋怼＞拖裼?jì)算機(jī)系統(tǒng)一樣，在多個(gè)項(xiàng)目之間進(jìn)行上下文切換時(shí)，團(tuán)隊(duì)成員通常會(huì)產(chǎn)生開銷。

當(dāng)團(tuán)隊(duì)成員被分配到多個(gè)項(xiàng)目時(shí)，上下文切換通常會(huì)發(fā)生。上下文切換的合理理由是：

邏輯上來講，為團(tuán)隊(duì)成員分配項(xiàng)目任務(wù)，比為每個(gè)項(xiàng)目分配專用資源更省時(shí)省力。

這似乎是合理的假設(shè)，將一個(gè)人的精力平分，對(duì)每個(gè)項(xiàng)目，兩者之間的項(xiàng)目收益率百分之50。

此外，如果一個(gè)團(tuán)隊(duì)成員只在一個(gè)單獨(dú)的項(xiàng)目中，如果這個(gè)項(xiàng)目正在等待處理某些事情，比如等待書面工作審批、審查等，該小組成員將是空閑的，沒有充分利用。

使用我們計(jì)算系統(tǒng)的隱喻，任務(wù)之間的切換類似多線程概念，如果一個(gè)線程因?yàn)槟承┦虑樽枞?，其他線程可以執(zhí)行其他工作，而不是等待第一個(gè)線程直到恢復(fù)。

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

閱讀完整的文章，使用 DevOps 解決上下文切換的不利影響，請(qǐng)?jiān)L問：http://blog.sei.cmu.edu/post.cfm/addressing-detrimental-effects-context-switching-devops-064

10.什么是 DevOps？

通常，當(dāng)我們?cè)O(shè)想一個(gè)實(shí)現(xiàn)了 DevOps 的組織，我們可以想象一個(gè)自動(dòng)化運(yùn)轉(zhuǎn)良好的機(jī)器：

• 基礎(chǔ)設(shè)施配置

• 代碼測(cè)試

• 應(yīng)用部署

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

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

以下為摘錄:

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

DevOps 的做法能使團(tuán)隊(duì)達(dá)到協(xié)調(diào)，理解必要的自動(dòng)化基礎(chǔ)設(shè)施、測(cè)試和部署。特別是，DevOps 提供了組織如何保證：

• 不同項(xiàng)目團(tuán)隊(duì)人員之間的合作；

• 基礎(chǔ)設(shè)施即為代碼；

• 自動(dòng)化任務(wù)、過程和工作流程；

• 監(jiān)控應(yīng)用和基礎(chǔ)設(shè)施。

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

一旦一個(gè)組織打破了這些孤島，把這些領(lǐng)域的專業(yè)知識(shí)整合起來，就可以把重點(diǎn)放在共同致力于提供商業(yè)價(jià)值的基本目標(biāo)上：

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

DevOps 的關(guān)鍵，并不是一個(gè)殺手級(jí)的工具或腳本，而是合作文化和傳遞價(jià)值的終極承諾。

閱讀完整的，什么是DevOps，請(qǐng)?jiān)L問：https://blog.sei.cmu.edu/post.cfm/what-is-devops-324

說明

每?jī)芍?，SEI 會(huì)發(fā)布一篇新的博客，為那些嘗試采用 DevOps 的組織提供指南，實(shí)用的建議和教程。我們歡迎您對(duì)本系列文章提供反饋，以及對(duì)未來內(nèi)容的建議。請(qǐng)?jiān)谙旅娴脑u(píng)論部分反饋意見。

① 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ā)展

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

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

重要提示：除非事先獲得授權(quán)，請(qǐng)?jiān)诒竟娞?hào)發(fā)布2天后，才能轉(zhuǎn)載本文。尊重知識(shí)，請(qǐng)必須全文轉(zhuǎn)載，并包括本行及如下二維碼。