年度十佳 DevOps 博客文章(前篇)

若是說 15 年你尚未將 DevOps 真正應用起來，16 年再不實踐也未免太落伍了。國內 ITOM 領軍企業 OneAPM 工程師爲您翻譯整理了，2015 年十佳 DevOps 文章，到底是不是深度好文，你們一塊兒來看看吧！

本文譯自 Hasan Yasar 的文章 the Top 10 Devops Posts of 2015 .

2015 年 8 月，DevOps 博客 推出了本身的平臺。DevOps 博客針對愈來愈多采用 DevOps 的企業（自 2011 年來佔比高達 26%），提供各類指南、實用建議和教程。根據近期研究，這些企業變動代碼的速度比傳統企業快 30 倍。儘管 DevOps 的優點顯而易見，不少企業仍然不敢欣然採用，由於這不只須要轉變觀念，還要改變文化和技術要求，後者對孤立的豎井式企業而言，是極大的挑戰。考慮到這些障礙，CERT 研究人員的文章主要集中介紹 Amazon 和 Netflix 的 DevOps 成功案例，以及 Fabric、Ansible 和 Docker 等流行 DevOps 技術的教程。本文則介紹了 2015 年 10 篇最受歡迎的 DevOps 文章（倒序）。

10.迷失的 DevOps 指標

有人說 DevOps 是一種方法；也有人說 DevOps 是一種運動，一種哲學甚至一種策略。定義 DevOps 的方式有不少種，但對於其基本目標你們都已經達成共識：將開發和運維相結合，努力下降風險，減輕負擔，縮短上市時間，同時提升運維意識。但早在 DevOps 這個術語流行起來以前，其發展就能夠追溯到二十世紀七十年代早期興起的工具自動化、文化轉移和迭代開發模型領域（例如敏捷開發）。

社羣推進了 DevOps 的發展，並將軟件開發領域方方面面的理念注入了 DevOps，所以賦予了其強大的能量。但因爲社羣中未能造成集中的操做指南，所以也對 DevOps 的進步形成了阻礙。

一般，意圖採用 DevOps 的企業會依照繁瑣的運維手續和豎井式文化使用 DevOps。對於以「無 DevOps」爲基礎創建的企業（以及設立的員工預期），這一轉型並不容易。此外，一旦某個團體決定嘗試實施 DevOps（這一般是團體自身的挑戰），就會面臨「如何合理實施」這一問題。在 2015 年發佈的十篇最受歡迎的文章中，Tim Palko在《迷失的 DevOps 指標》中探討了這一問題。

下面是這篇文章的摘錄：

對 DevOps 採用率的研究使用了「已採用」或「將採用」這些措辭，彷彿它們是企業季度目標的行項目。這是否表示他們已與 Flickr 的每日十大部署看齊，仍是說他們只是使用了「採用」這一措辭的淺層含義，只是接受了本身的宿命，不會聽從 DevOps 哲學？考慮到 DevOps 具有的多種定義，「採用」一詞的意義可能擁有一樣數量甚至更多的變化形式。不管如何，DevOps 都羽翼未豐，它只是各類正負屬性的連續統一體，甚至遠未達到線性。

我並不打算立什麼里程碑。在一些團隊裏，取得任何程度的 DevOps 成就都值得大餐一頓，以示慶祝。然而，要制定目標，只知道 DevOps 是一種文化和技術遠遠不夠。另外一種觀點是，你採用 DevOps 的目標就是你須要 DevOps 達到的效果。換言之，家家有本難唸的經，而 DevOps 給出的海量解決方案必然可以開啓良好開端，幫助你們解決問題，即便只須要一兩個解決方案。

DevOps 的發展彷佛一切順利，不依靠任何枯燥精簡的標準和指標。儘管如此，若是咱們一心改變卻不對變化加以測量，就可能走上給流程鍍金的無盡之路。結果多是好的，但客戶也在這樣的文化變革中投入了真金白銀，不管他們是否知情、是否但願知情甚至絕不知情。所以，必須對變化進行規劃，並設立明確的目標和完成日期。

閱讀原文 & 系統監控解決方案推薦。

9.DevOps 技術：Vagrant

環境對等 (Environment parity) 是一種理想狀態，執行代碼時所在的各類環境等效運行。軟件開發問題日益使人沮喪，不少難題懸而未決，缺乏環境對等性就是其中一個問題。部署和開發常常是這個問題的受害者，穩定性、可預測性和工做效率都所以下降。若是達不到對等性，各環境就會以不一樣方式運行，這樣，解決疑難問題就會變得棘手，協同也無從談起。對於太多開發人員和運維人員來講，缺乏對等性都是個負擔。

在 DevOps 技術：Vagrant 這篇文章中，CERT 研究人員 Tim Palko 介紹了 Vagrant ，一種藉助一個聲明腳本和一個簡單的命令行界面就能夠爲開發人員提供虛擬化配置環境的開發工具。Vagrant 對全部開發人員和工做使用相同的預配置（腳本型）環境，從而提升了開發和環境對等性。Vagrant 讓應用程序開發週期過程當中「機器工做不受人控制」這樣的理由再也不是理由。

下面是這篇文章的摘錄：

運維團隊的工做一般包括在各個部署環境（例如測試環境、模擬環境和運做環境）中實施全面的對等性。反之，開發團隊則幾乎全權負責配置開發機器。爲了實現兩組環境之間的徹底對等，兩個團隊必須使用相同的語言和資源。  Chef 和 Puppet 工具都是專爲運維人員而生，對忙碌的開發人員來講有些難以觸及。每一種工具都有可觀的學習曲線，但沒有哪一種工具確實徹底地解決了對等問題：開發人員仍然須要將適當的生產目標平臺虛擬化。這些額外工做都會致使可觀的開銷，而此時你只是想編寫代碼！

這時候，Vagrant 就派上用場了。Vagrant 是一款開發者工具，僅藉助一個聲明腳本和一個簡單的命令行界面就可爲使用運維工具的開發人員提供虛擬化的配置環境。Vagrant 剔除了支撐虛擬主機 (VM) 所需的繁重工做，還避免了配置或運行 Chef 服務器和 Chef 客戶端。Vagrant 隱藏了全部這些工做，只給開發人員留下一個簡單的腳本和一個名爲 Vagrantfile 的無擴展名頭文件，可在源碼控制和代碼中檢查該文件。

閱讀原文：https://blog.sei.cmu.edu/post.cfm/devops-technologies-vagrant-345

8.DevOps 團隊使用 ChatOps

一個項目團隊中關鍵利益相關者（例如開發人員、業務分析師、項目經理和安全團隊）之間的對話，以及他們的溝通平臺都會對協做產生深入影響。溝通工具不理想或不熟悉，會形成溝通不順暢、徒勞無功甚至執行有誤。另外一方面，若是溝通工具集成了開發和運維基礎架構，就可以縮短將商業價值交付給公司的時間。團隊的溝通基礎架構組織方式直接影響團隊效率。

在 DevOps 團隊使用 ChatOps 這篇文章中，CERT 研究人員 Todd Waits 首次引入了 ChatOps 這個概念， ChatOps 做爲 DevOps 的分支，側重於 DevOps 團隊內部的溝通。ChatOps 空間主要包括團隊內的溝通和協做工具：通知、聊天服務器、機器人、問題追蹤系統等。

下面是這篇文章的摘錄：

在近期的一篇博客文章 中，Eric Sigler 寫到，ChatOps 這一術語源於 GitHub，主要是指對話驅動式開發。「將工具代入對話，使用經改良的聊天機器人來配合使用關鍵插件和腳本，團隊就能自動運行任務並展開協做，工做表現更出色，費用更低，速度也更快，」Sigler 寫道。

大多數團隊都會在聊天服務器上開展必定程度的協做。聊天服務器能夠做爲大型開發團隊的「城市廣場」，有利於促進團隊之間的凝聚力，爲團隊成員的全部活動提供一個空間，好比用大量 gif 圖像 抒發情感，討論實際問題的潛在解決方案等。咱們但願全部團隊成員都使用聊天服務器。在咱們的團隊中，爲了不通常聊天室的灌水聊天，咱們也爲每一個項目建立專用聊天室，項目團隊成員能夠談論項目的細節，不涉及其餘團隊。

聊天服務器不只僅是簡單的溝通媒介，它還能夠智能化，先從開發基礎架構向團隊傳遞通知，而後執行命令並從團隊返回基礎架構。聊天服務器是通知中心，能夠和開發基礎架構快速互動。項目團隊經過聊天服務器（以及其餘渠道）接收關於其但願關注的全部構建狀態的通知：構建失敗、構建成功、超時等。

閱讀原文 & 推薦「探討如何將 DevOps 與 ChatOps 結合」的文章 當咱們在談論 DevOps，咱們在談論什麼？

7.DevOps 容器安全性

基於容器的虛擬化平臺給出了一種方法，能夠在單獨的實例上運行多個應用。容器技術能夠爲 DevOps 提供極大效益，包括可擴展性提高，資源利用率提升，彈性加強。儘管如此，除非從主機系統分離容器，不然可能存在安全問題。Chris Taschner 在 DevOps 的容器安全問題 這篇博客文章中說明了在分離前,管理員爲什麼應當密切關注容器內所運行的應用程序的特權級別和訪問主機系統的用戶的特權級別。

容器現已成爲 DevOps 的大熱新技術。Docker 這家公司尤爲已經成爲容器技術的架構首選提供商。利用 Docker 平臺，能夠將應用程序連同其全部依賴項打包放進一個被稱爲圖像的單元中。而後 Docker 就能夠運行該圖像的實例。每個實例都留在一個容器中。

Docker 正在成爲 DevOps 的代名詞。若是您還不瞭解容器的優點，請聽我慢慢道來。一個極小的容器中能夠包含現成的圖像、易於使用的公共資源庫、圖像版本控制以及 Docker 的應用程序本質。（更多信息請參見 devops.com 上的文章——使用 Docker 的三大緣由）

就大小而言，容器也具有大量優點。和虛擬主機不一樣的是，容器不須要運行全面的操做系統，也不須要系統全部硬件的虛擬複本。只要操做系統和硬件信息足夠使用，容器就能將其負責的應用運轉起來。最終，容器能夠比虛擬主機還小得多，這樣主機系統運行的容器數量就會遠多於其運行的虛擬主機數量。

閱讀原文 & Docker 監控實戰。

6.DevOps 案例分析：Amazon AWS

常常閱讀 DevOps 博客 的讀者會發現，這個系列常常出現的主題 是：* DevOps 的本質是經過精心構建組織流程、溝通和工做流來鞏固所需質量屬性 。經過研究知名科技公司的軟件工程/維護管理技術，DevOps 博客做者能夠呈現真實的寶貴案例，得出大量軟件工程方法及相關成果。這些案例也很是值得 DevOps 從業人員借鑑。在「DevOps 案例分析：Amazon AWS 」這篇文章中，C. Aaron Cois 分享了 Amazon 的 DevOps 使用經驗。

下面是這篇文章的摘錄：

Amazon 是當今最多產的科技公司之一。2006 年，Amazon 從一家在線零售商成功轉型爲科技巨頭，並推出 Amazon Web Services (AWS)，成爲雲服務領導者。AWS 是一項擁有普遍用戶的按需定製型 IaaS （基礎架構即服務）服務。對於 AWS，Amazon 承受了大量風險。經過開發首批大規模的公共雲服務，Amazon 認識到，不少挑戰都是未知的，許多解決方案也未經證明。要學習 Amazon 的成功經驗，咱們須要問出正確的問題。這項商業冒險活動存在固有風險，爲了將風險降到最低，Amazon 採起了哪些措施？Amazon 工程師如何設計其流程以保證質量？

幸運的是，谷歌工程師 Steve Yegge（前 Amazon 工程師）意外公佈了一分內部備忘錄，其中概述了他對谷歌平臺開發失敗（以及 Amazon 取得成功）的感想，從而讓世人對這些問題有了大體瞭解。這份備忘錄（Yegge 特別容許可在網絡上傳播）歸納地介紹了一項具體決策，該決策描述了首席執行官 Jeff Bezos 對咱們如今稱之爲 DevOps 的基本原則的理解，以及他對互操做性、可用性、可靠性和安全性（筆者認爲這些是 AWS 平臺的主要質量屬性）的奉獻。

閱讀原文

以上是 15 年年度十佳 DevOps 博客文章的第 6-10 名，有沒有哪一篇抓住了您的眼球，讓您有所收穫呢？預知 1-5 名的文章，請期待「年度十佳 DevOps 博客文章(後篇)」。

Cloud Insight 集監控、管理、計算、協做、可視化於一身，幫助全部 IT 公司，減小在系統監控上的人力和時間成本投入，讓運維工做更加高效、簡單，已在阿里云云市場上線，雲市場詳情請戳。

本文轉自 OneAPM 官方博客