如果說 15 年你還沒有將 DevOps 真正應(yīng)用起來，16 年再不實踐也未免太落伍了。在上篇文章中我們了解到 15 年十佳 DevOps 博客文章的第 6-10 名，有沒有哪一篇抓住了您的眼球，讓您有所收獲呢？接下來讓我們來看一看排名前五的文章，究竟是不是妙筆生花，鞭辟入里！
本文是「年度十佳 DevOps 博客文章（前篇）」的后半部分，譯自 Hasan Yasar 的文章 the Top 10 Devops Posts of 2015 .
2015 年 8 月，DevOps 博客 推出了自己的平臺。DevOps 博客針對越來越多采用 DevOps 的企業(yè)（自 2011 年來占比高達 26%），提供各種指南、實用建議和教程。根據(jù)近期研究，這些企業(yè)變更代碼的速度比傳統(tǒng)企業(yè)快 30 倍。盡管 DevOps 的優(yōu)勢顯而易見，很多企業(yè)仍然不敢欣然采用，因為這不僅需要轉(zhuǎn)變觀念，還要改變文化和技術(shù)要求，后者對孤立的豎井式企業(yè)而言，是極大的挑戰(zhàn)?？紤]到這些障礙，CERT 研究人員的文章主要集中介紹 Amazon 和 Netflix 的 DevOps 成功案例，以及 Fabric、Ansible 和 Docker 等流行 DevOps 技術(shù)的教程。本文則介紹了 2015 年 10 篇最受歡迎的 DevOps 文章中的第 1-5 名（倒序）。
5.DevOps 案例分析：Netflix 和 Chaos Monkey
DevOps 經(jīng)常被用在 敏捷 開發(fā)、自動化和 持續(xù)交付 等實踐中，但 DevOps 的精神卻可以應(yīng)用在很多方面。在這篇博文中，C. Aaron Cois 剖析了另一個影響深遠的 DevOps 思維案例分析 - Netflix 的開箱即用方式。
下面是這篇文章的摘錄：
對于 DevOps 來說，Netflix 是一個奇妙的案例，因為 Netflix 軟件工程過程顯示了對 DevOps 思維本質(zhì)的深刻理解和通過自動化輔助過程對質(zhì)量屬性的關(guān)注。DevOps 從業(yè)者信奉以一種注重質(zhì)量屬性的驅(qū)動滿足業(yè)務(wù)需求，充分利用自動化過程實現(xiàn)一致性和高效率。
Netflix 的流媒體服務(wù)是一個托管在 AWS 上的大型分布式系統(tǒng)。眾多組件必須一起工作，才能為使用各種設(shè)備的客戶提供可靠的視頻流。過去， Netflix 工程師需要同時重點關(guān)注服務(wù)器和客戶端組件這二者的可靠性和魯棒性等質(zhì)量屬性。簡而言之，他們 得出結(jié)論，正確應(yīng)對失敗的唯一方法是不斷失敗。為了實現(xiàn)確實符合 DevOps 風(fēng)格、預(yù)期的信賴水準和質(zhì)量水平，Netflix 工程師開始采用自動化故障方案。
閱讀原文： DevOps 案例分析：Netflix 和 Chaos Monkey
4.用 Docker 進行開發(fā)
在用 Docker 進行開發(fā) 這篇文章中，Joe Yankel 分享了一份利用 Docker 在軟件開發(fā)通用環(huán)境中進行開發(fā)的入門教程：啟動一種數(shù)據(jù)庫容器 (MongoDB) 和一種網(wǎng)絡(luò)服務(wù)容器（一款 Python Bottle 應(yīng)用），然后對二者進行通信配置，形成實用的多容器應(yīng)用。
下面是這篇文章的摘錄：
如果您還不了解 Docker 的基本知識，請先點擊 此處 學(xué)習(xí) Docker 的官方教材再繼續(xù)閱讀本文。
入門前，您需要有一臺 虛擬主機 或其他兼容 Docker 的主機。根據(jù)下面的操作說明來創(chuàng)建演示程序所需的源文件。
為方便起見，請從 我們的 github 資源庫 下載所有源文件，然后跳轉(zhuǎn)到演示部分。我們的源代碼包含一份 Vagrant 配置文件，可在適用環(huán)境下運行演示。請點擊 此處 查看我們對 Vagrant 的介紹。
閱讀原文：用 Docker 進行開發(fā) & 推薦文章 為什么 Cloud Insight 要支持監(jiān)控 Docker
3.DevOps 的持續(xù)集成
人們首次展望 敏捷 軟件開發(fā)模式時，核心原則是：更快地實現(xiàn)軟件更改迭代、通過探索確定適當?shù)穆窂?，本質(zhì)上來說，就是力求“故障快速修復(fù) (fail fast)”并將正確性作為基本項目目標進行迭代。有人認為，由于對客戶認識不足以及無法預(yù)期客戶不斷變化的需求，在項目開始時開發(fā)人員缺少正確定義長期項目要求的必要信息，因此，敏捷過程應(yīng)運而生。近期的研究 繼續(xù)凸顯出軟件開發(fā)周期中規(guī)劃、設(shè)計和執(zhí)行階段之間的斷層問題，為這一結(jié)論提供了有力證明。在 DevOps 的 持續(xù)集成 這篇文章中，C. Aaron Cois 強調(diào)需要進行持續(xù)集成以避免斷層，從而降低軟件開發(fā)項目的風(fēng)險。
下面是這篇文章的摘錄：
持續(xù)集成 (CI) 是 DevOps 的基石。持續(xù)集成技術(shù)由 Grady Booch 開發(fā)并命名，可持續(xù)合并來自團隊所有開發(fā)人員的最新源代碼并形成共享主線。持續(xù)的合并可以防止其他成員新增代碼時開發(fā)人員的軟件項目本地復(fù)本偏離主題過遠，從而避免災(zāi)難性的合并沖突。實際應(yīng)用中，CI 會有一臺中央服務(wù)器，在開發(fā)人員提交新的源碼或從頭構(gòu)建軟件應(yīng)用時，這臺服務(wù)器會持續(xù)地納入所有源碼的修改情況，并將此過程中的任何故障告知團隊。如果發(fā)現(xiàn)故障，開發(fā)團隊應(yīng)該重新將精力集中在故障修改，直到修復(fù)完成才能提交新的代碼修改。雖然看起來有些混亂，但實際上 CI 使開發(fā)團隊專注于單一的穩(wěn)定性指標：行之有效的軟件自動構(gòu)建。
DevOps 方法的關(guān)鍵要素是消除理解斷層和影響力斷層，企業(yè)必須派遣一位或多位相關(guān)專家與開發(fā)團隊展開全面交流，鞏固域中心觀點。要消除開發(fā)和 維護 之間的斷層，DevOps 從業(yè)人員一開始就將開發(fā)團隊中的 IT 運維專業(yè)人員視為團隊正式成員。同樣地，為了確保軟件質(zhì)量，在整個項目周期內(nèi)質(zhì)量管理人員都必須作為團隊成員。換句話說，DevOps 意識到，確保高質(zhì)量開發(fā)需要與多位技術(shù)專家（包括質(zhì)量管理專家和運維專家）持續(xù)交流并積極聽取專家意見，繼而以敏捷為原則擴展示其應(yīng)用范圍。
2.DevOps 與 Docker
Docker 是 DevOps 社群近來的熱門話題，這自然是有充分理由的。Docker 容器提供的工具可在可控、獨立、靈活同時高度可移植的基礎(chǔ)架構(gòu)中開發(fā)和部署軟件應(yīng)用。在 DevOps 與 Docker 這篇文章中，CERT 研究人員 Joe Yankel 將 Docker 介紹為一個對可擴展性、資源利用率和彈性都有極大好處的軟件應(yīng)用開發(fā)和部署工具。
下面是這篇文章的摘錄：
Linux 容器技術(shù) (LXC) 作為 Docker 的構(gòu)建基礎(chǔ)，已經(jīng)不是什么新理念了。自 2.6.24 版起，LXC 就是 Linux 內(nèi)核的一部分，該版本正式集成了 控制組（Control Groups，簡稱 cgroups）。實際上，早在 2006 年，谷歌就開始使用 Cgroups，這是因為谷歌一直設(shè)法分離在共享硬件上運行的資源。事實上，谷歌承認一周啟動超過 20 億臺容器，同時發(fā)布了谷歌版 LXC 容器并命名為 lmctfy，即“讓我容納你的程序 (Let Me Contain That For You)”。
不幸的是，在 Docker 出現(xiàn)并簡化容器技術(shù)之前，容器技術(shù)一直難以采用。在 Docker 出現(xiàn)之前，開發(fā)人員一度難以使用、實施甚至理解 LXC 技術(shù)，更別提意識到 LXC 的系統(tǒng)管理程序優(yōu)勢了。DotCloud 創(chuàng)始人兼 Docker 現(xiàn)任首席技術(shù)官 Solomon Hykes 啟動 Docker 項目并于 2013 年 3 月將其作為開源軟件公之于世，這無疑是一個偉大的行動。Docker 的易用性源于其高水平 API 和文檔支持，這使得 DevOps 社群全速發(fā)展，進而創(chuàng)建出各種教程和官方集成化應(yīng)用，并衍生了眾多附加技術(shù)。Docker 降低了容器技術(shù)領(lǐng)域的準入門檻，改變了開發(fā)人員共享、測試和部署應(yīng)用程序的方式。
閱讀原文 & 推薦文章 Docker 監(jiān)控實戰(zhàn)
1.DevOps 技術(shù)：Fabric 還是 Ansible
在 DevOps 技術(shù)：Fabric 還是 Ansible 這篇文章中，CERT 研究人員 Tim Palko 特別介紹了 DevOps 部署過程的用例，包括評估資源要求、設(shè)計產(chǎn)品系統(tǒng)、配置產(chǎn)品服務(wù)器和推送代碼等。
下面是這篇文章的摘錄：
部署代碼的工作流程幾乎和代碼本身的歷史一樣久遠。與 DevOps 部署過程相關(guān)的用例很多，舉幾個例子，包括評估資源要求、設(shè)計產(chǎn)品系統(tǒng)、配置生產(chǎn)服務(wù)器和推送代碼等。在這篇文章中，我會重點介紹一個配置遠程服務(wù)器的用例，以及執(zhí)行代碼必需的數(shù)據(jù)包和軟件。這一用例得到了眾多不同競爭技術(shù)的支持，包括 Chef、Puppet、Fabric、Ansible、Salt 和 Foreman 等，而這些只是你在 DevOps 的自動化之路上可能見到的滄海一栗而已。所有這些技術(shù)都提供了免費版，你可以將他們加入自己的資源庫以完成工作。本文更深入地探討了 Fabric 和 Ansible。要了解更多其他基礎(chǔ)架構(gòu)即代碼的解決方案，請查看 Joe Yankel 撰寫的關(guān)于 Docker 文章 或 我對 Vagrant 的介紹。
Fabric 和 Ansible 的一個區(qū)別是，F(xiàn)abric 可以在幾分鐘內(nèi)見效，而 Ansible 則需要多花些時間去理解。一般來說，Ansible 更為強大，這是因為它為多層架構(gòu)建模了提供更深入更復(fù)雜的語義，例如 Web 和數(shù)據(jù)庫主機陣列。從運維人員的角度來說，F(xiàn)abric 的 API 更基本 也更符合字面意義，同時使用 Python 進行創(chuàng)作，而 Ansible 則使用 YAML 并提供更豐富的行為（這一點稍后討論）。我們會在 這篇文章 中仔細分析 Fabric 和 Ansible 的例子。
總結(jié)和展望
DevOps 要求從啟動到維護項目所必需的所有知識和技能都囊括在一個專門的項目團隊中，這可以視為 敏捷 方法的延伸。必須打破企業(yè)的孤立豎井狀態(tài)。只有這樣，才能有效緩和項目風(fēng)險。
題外話
小編發(fā)現(xiàn)，Docker 依然是 DevOps 的一大熱點。怎么樣？看完十佳 DevOps 博客文章的介紹，是否有其中的哪一篇對您的胃口？是否對實踐 DevOps 又有了新的想法呢？
本文由國內(nèi) ITOM 領(lǐng)軍企業(yè) OneAPM 工程師為您翻譯整理，要閱讀 DevOps 系列的所有博客文章，請點擊 閱讀更多。
Cloud Insight 集監(jiān)控、管理、計算、協(xié)作、可視化于一身，幫助所有 IT 公司，減少在系統(tǒng)監(jiān)控上的人力和時間成本投入，讓運維工作更加高效、簡單，已在阿里云云市場上線，云市場詳情請戳。
本文轉(zhuǎn)自 OneAPM 官方博客
