年度十佳 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&utm_campaign=CiArti&from=jscwxyry) 集监控、管理、计算、协做、可视化于一身，帮助全部 IT 公司，减小在系统监控上的人力和时间成本投入，让运维工做更加高效、简单，已在阿里云云市场上线，云市场详情请戳&utm_campaign=CiArti&from=jscwxyry)。

本文转自 OneAPM 官方博客