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