如果說 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 官方博客
