【大运维之六】DevOps年中盘点：国外最受欢迎的10篇技术文章（下）

编辑 王鹏（翻译） 高浩淼（整理&发布）

在2014年年底，SEI 博客发表了一系列有关 DevOps① 的博客文章，提供指南，实用的建议和教程。这些帖子针对越来越多的采用 DevOps 的企业（2011年以来，高达26％）。

根据最近的研究②，这些组织部署变更代码比传统的方式快30倍。

尽管 DevOps 的好处显而易见，但是许多企业仍不敢采用 DevOps，因为这需要转变心态、文化和技术要求，对于传统企业是非常大的挑战。

鉴于这些障碍，CERT 研究人员的文章主要集中在介绍 Amazon③ 和 Netflix④ DevOps 的成功案例，以及一些 DevOps 流行技术的教程，如 Fabric⑤、Ansible⑤ 和 Docker⑥。

我们将介绍2015年过去的六个月，10个最流行的 DevOps 相关文章（根据访问次数排序）。本文介绍后5篇文章，同样非常精彩。

6.DevOps 和敏捷开发

康威定律⑮说：设计系统的组织，最终产生的设计等同于组织之内、之间的沟通结构。

因此，一个公司的前端、后端和数据库团队可能会倾向于使用三层架构。在很大程度上，应用程序的结构，是由组织沟通后产生。简而言之，形式是交流的产物。

在本文中，作者学习康威定律并应用到自己的组织。

以下为摘录:

传统的瀑布式开发模式已经为我们的应用程序定义一个特定的沟通结构：

开发开发人员让（QA）团队测试并质量保证，QA 让运维（OPS）团队去部署。

这种方式的沟通，是非敏捷的，加重了我们有缺陷的组织结构，这又是一个印证了康威定律的例子：组织结构决定产品。

阅读完整的文章， DevOps 和敏捷开发，请访问 
https://blog.sei.cmu.edu/post.cfm/devops-agile-317

7. DevOps 团队需要 ChatOps

项目团队关键利益相关者之间的对话（例如，开发人员、业务分析员、项目经理、安全团队），平台之间的沟通，可以对协作产生深远的影响。

较差的或甚至没有使用通讯工具，导致沟通不畅，重复的工作，或错误的实现。另一方面，开发和业务基础设施相结合的通信工具，可以加快向组织交付业务价值。

也就是说，一个团队如何组织基础设施结构，如何沟通，将直接影响团队的效率。

在文章 DevOps 团队需要 ChatOps 中，作者介绍了 ChatOps，DevOps 的一个分支，关注 DevOps 团队的沟通。

ChatOps 包括了团队的沟通和协作工具：通知、聊天服务器、机器人、问题跟踪系统等等。

以下为摘录:

在最近的一篇博客⑱中，作者写道，ChatOps，一词起源于GitHub上，都是关于基于对话的驱动开发方式：

“把你的工具带到您的沟通过程中，并使用一个聊天机器人修改关键的插件和脚本工作，团队可以自动执行任务和协作工作，使工作更好、更便捷、更快”。Sigler写道。

大多数团队在聊天服务器上都有一定程度的合作。聊天服务器可以作为一个城市广场一样容纳开发团队、促进团队之间的凝聚力、讨论实际问题以及潜在解决方案等。

我们希望所有的团队成员使用聊天服务器。在我们的团队中，为了避免一般聊天室的灌水聊天，我们也创建专用聊天室，每个项目，项目团队成员可以谈论项目的细节，不涉及其他的团队：

和其他简单的沟通介质不一样，聊天服务器可以智能化，开发的基础设施，向团队传递通知，团队执行命令并反馈回基础设施。

我们的聊天服务器是通知的枢纽，与我们的基础设施快速互动：

项目团队通过聊天服务器接到通知（还有其他方法），关注基础设施任何生成状态，他们关注：构建失败、构建成功、超时等。

阅读完整的文章，DevOps团队需要ChatOps，请访问
https://blog.sei.cmu.edu/post.cfm/chatops-in-devops-team-029

8.DevOps之Vagrant

环境等同⑲是一个理想的、令人充满期待的状态。缺乏环境等同会使软件开发陷入令人沮丧的困境。部署和开发都经常会陷入这样的陷阱，降低了稳定性、可预测性和生产力。

当环境不等同时，这使得故障难以排除，而且难以协作。这种缺乏环境等同使开发人员和运维人员负担太多。

在这篇博客中 DevOps 之 Vagrant ，作者描述了 Vagrant： 

这是一个开发者使用的工具，提供了一个虚拟化和环境配置，Vagrant 为开发者提供了一个单一的，声明式脚本，以及一个简单的命令行界面。

通过使用相同的预先配置的 Vagrant 脚本，Vagrant 为所有开发者统一了线上的环境。在应用开发生命周期过程中，Vagrant 消除了“环境不同”的借口。 

以下为摘录:

运维团队的作业通常包括在所有部署环境中实施全面的校验，例如用于测试、分段和上线。

相反，开发团队几乎完全自己负责配置开发机器。为了达到百分之100的环境等同，两个团队必须使用相同的语言，使用相同的资源。

Chef和Puppet，这两个都是为运维而生，对一个繁忙的开发人员来说可能不太友好。

Chef和Puppet都有一个比较陡的学习曲线，并没有真正解决环境等同的问题： 

开发者仍然需要和线上环境同步。

所有这些额外的工作会带来一个相当大的开销，而开发者只想好好的写业务代码！

这就是Vagrant出现的意义。Vagrant是一个面向开发者的工具，基本上Vagrant提供了一个虚拟化环境，提供了一个单一的，声明式的脚本和一个简单的命令行界面。

Vagrant通过启动一个虚拟机（VM），去除繁重的工作，消除了人工配置或运行，例如，chef-server和chef-client。Vagrant的隐藏这一切，提供一个简单的脚本给开发人员，一个名叫Vagrantfile无扩展项文件，可随着代码签入到源代码控制。

阅读完整的文章，DevOps之Vagrant，请访问 
https://blog.sei.cmu.edu/post.cfm/devops-technologies-vagrant-345

9.使用DevOps解决上下文切换的不利影响

在计算系统中，上下文切换发生在：

操作系统保存一个应用程序线程的状态，停止线程并恢复其他线程的状态（之前停止线程），使其他线程恢复执行。

上下文切换管理的开销，发生在处理状态的保存和恢复，这个过程会对操作系统产生负荷，并影响应用程序的性能。

在博客使用DevOps解决上下文切换的不利影响中，CERT研究员Todd Waits描述了如何使用DevOps改善负面影响， 减少项目之间的“上下文切换”对软件工程团队效率的影响。

以下为摘录:

Quality Software Management: Systems Thinking⑳, 作者在这本书中讨论了，上下文切换的概念是如何适用于一个工程团队。

从人力劳动力的角度来看，上下文切换是一个项目停止工作的过程，并在不同的项目上完成不同的任务后，将其重新捡起来。就像计算机系统一样，在多个项目之间进行上下文切换时，团队成员通常会产生开销。

当团队成员被分配到多个项目时，上下文切换通常会发生。上下文切换的合理理由是： 

逻辑上来讲，为团队成员分配项目任务，比为每个项目分配专用资源更省时省力。

这似乎是合理的假设，将一个人的精力平分，对每个项目，两者之间的项目收益率百分之50。

此外，如果一个团队成员只在一个单独的项目中，如果这个项目正在等待处理某些事情，比如等待书面工作审批、审查等，该小组成员将是空闲的，没有充分利用。

使用我们计算系统的隐喻，任务之间的切换类似多线程概念，如果一个线程因为某些事情阻塞，其他线程可以执行其他工作，而不是等待第一个线程直到恢复。

如果所有的工作只分配给第一个线程，进展很慢。虽然多线程在计算系统中很合理，问题是，人类并不总是能很好分配精力。因此效率会在上下文切时损失，生产力可能会在精力分散在更多的项目的时候下降。

阅读完整的文章，使用 DevOps 解决上下文切换的不利影响，请访问 
https://blog.sei.cmu.edu/post.cfm/addressing-detrimental-effects-context-switching-devops-064

通常，当我们设想一个实现了 DevOps 的组织，我们可以想象一个自动化运转良好的机器：

最终，这些做法的结果是运用DevOps的方法和工具。DevOps适合所有规模的团队，从一个一个人的团队到一个企业组织。在这篇博文中，什么是DevOps，CERT研究员Todd Waits介绍了DevOps的基础。

DevOps可以看作是敏捷方法的推广。它要求掌握相当多的知识和技能，包括一个项目从开始到持续，到被一个专门的项目小组负责。组织壁垒必须打破。只有这样才能有效地缓解项目风险

10.什么是 DevOps？

基础设施配置
代码测试
应用部署

最终，这些做法的结果是运用DevOps的方法和工具。DevOps适合所有规模的团队，从一个一个人的团队到一个企业组织。在这篇博文中，什么是DevOps，CERT研究员Todd Waits介绍了DevOps的基础。

DevOps可以看作是敏捷方法的推广。它要求掌握相当多的知识和技能，包括一个项目从开始到持续，到被一个专门的项目小组负责。组织壁垒必须打破。只有这样才能有效地缓解项目风险。

以下为摘录:

然而严格来说，DevOps 并不是持续集成，交付或部署。

DevOps 的做法能使团队达到协调，理解必要的自动化基础设施、测试和部署。特别是，DevOps 提供了组织如何保证：

不同项目团队人员之间的合作；基础设施即为代码； 自动化任务、过程和工作流程；监控应用和基础设施。

商业价值驱动 DevOps 的发展。如果没有 DevOps 的心态，组织经常发现他们的运维、开发和测试团队，目光短浅，只致力于创建方便自己的基础设施、测试套件或产品增量。

一旦一个组织打破了这些孤岛，把这些领域的专业知识整合起来，就可以把重点放在共同致力于提供商业价值的基本目标上：

组织良好的团队会发现（或创建）工具和技术，使他们的组织实践 DevOps。每个组织都是不同的，有不同的需求，不同的但是必须满足的需求。

DevOps 的关键，并不是一个杀手级的工具或脚本，而是合作文化和传递价值的终极承诺。

阅读完整的，什么是DevOps，请访问 
https://blog.sei.cmu.edu/post.cfm/what-is-devops-324

说明

每两周，SEI 会发布一篇新的博客，为那些尝试采用 DevOps 的组织提供指南，实用的建议和教程。我们欢迎您对本系列文章提供反馈，以及对未来内容的建议。请在下面的评论部分反馈意见。

⑮ https://en.wikipedia.org/wiki/Melvin_Conway
⑯ https://en.wikipedia.org/wiki/Conway%27s_law
⑰ https://blog.sei.cmu.edu/post.cfm/devops-agile-317
⑱ https://www.pagerduty.com/blog/what-is-chatops/
⑲ https://www.newmediacampaigns.com/blog/matching-development-production-environments
⑳ https://www.amazon.com/Quality-Software-Management-Systems-Thinking/dp/0932633722

更多好文章请点击如下链接

【大运维之一】自动化实践探索的最优路  https://www.csdn.net/article/2015-08-05/2825387

【大运维之二】DevOps年中盘点：国外最受欢迎的10篇技术文章（上） https://www.csdn.net/article/2015-08-07/2825400

【大运维之三】IT架构的渊源及方法论  https://www.csdn.net/article/2015-08-12/2825442

【大运维之四】运维标准化文档的四项基本原则   https://www.csdn.net/article/2015-08-12/2825444

【大运维之五】OKR: Google和Facebook高效管理的秘密  https://www.csdn.net/article/2015-08-13/2825451

重要提示：运维在“云江湖”的地位毋庸置疑。为给ImapBox的读者提供更多高质量内容，ImapBox云计算频道已与“高效运维”微信公众号（如下二维码）达成合作，众多深度分享文章均将网页端首发在ImapBox。欢迎关注。