我告诉你一个秘密：DevOps 云计算之类的东西可以把我的程序运行在世界上任何一个地方，这对我来说仍然有一点神秘。但随着时间流逝，我意识到理解大规模的机器增减和应用程序部署的来龙去脉对一个开发者来说是非常重要的知识。这类似于成为一个专业的音乐家，当然你肯定需要知道如何使用你的乐器，但是，如果你不知道一个录音棚是如何工作的，或者如何适应一个交响乐团，那么你在这样的环境中工作会变得非常困难。 在软件开

那些熟悉 DevOps 的人通常认为与其说 DevOps 是一种技术不如说是一种文化。在 DevOps 的有效实践上需要一些特定的工具和经验，但是 DevOps 成功的基础在于企业内如何做好团队和个体协作，从而可以让事情更快、更高效而有效的完成。 大多数的 DevOps 平台和工具都是以可扩展性为设计理念的。DevOps 环境通常运行在云端，并且容易发生变化。对于DevOps 软件来说，支持实时伸

这些 DevOps 日志记录和监控工具是重塑云计算趋势的一部分 – 在《开放云指南》中了解更多。 在云中，开源工具和应用程序使 DevOps 提高了很多效率，对于日志记录和监视解决方案尤其如此。监控云平台、应用程序和组件以及处理和分析日志，对于确保高可用性、高性能、低延迟等至关重要。事实上，RightScale 最近的云状态调查报告中说，最常见的云优化的行为中，45％ 的大公司和中小型企业关注的是

安全难以推行。在企业管理者迫使开发团队尽快发布程序的大环境下，很难说服他们花费有限的时间来修补安全漏洞。但是鉴于所有网络攻击中有 84％ 发生在应用层，作为一个组织是无法承担其开发团队不包括安全性带来的后果。 DevOps 的崛起为许多安全负责人带来了困境。Sonatype 的前 CTO Josh Corman 说：“这是对安全的威胁，但这也是让安全变得更好的机会。” Corman 是一个坚定的将

真正的组织文化变革有助于弥合你原以为无法跨过的鸿沟 回想一下你最近一次尝试改掉一个个人习惯的事情，你可能遇到过这样的情形，你需要改变你思考的方式并且改掉之前的习惯。这很艰难，你只能试着改变你自己的思维方式。 所以你可能会试着让自己置身于新的环境。新的环境实际上可帮助我们养成新的习惯，它反过来又会促成新的思维方式。 那就是能否成功改变的所在：思考的越多，得到的越多。你需要知道你在改变的原因以及你的目

R 语言，一种自由软件编程语言与操作环境，主要用于统计分析、绘图、数据挖掘。R 内置多种统计学及数字分析功能。R 的另一强项是绘图功能，制图具有印刷的素质，也可加入数学符号。——引自维基百科。 已经有几篇关于为什么要在 Docker 中使用 R 的文章。在这篇文章中，我将尝试加入一个 DevOps 的观点，并解释在 OpenCPU 系统的环境中如何使用容器化 R 来构建和部署 R 服务器。 有在

题图抽象的形容了容器和虚拟机是那么的相似，又是那么的不同！ 在近期的一些会议和学术交流会上，我一直在讲述有关 DevOps 的安全问题（亦称为 DevSecOps） 注1 。通常，我首先都会问一个问题：“在座的各位有谁知道什么是容器吗？” 通常并没有很多人举手 注2 ，所以我都会先简单介绍一下什么是容器 注3 ，然后再进行深层次的讨论交流。 更准确的说，在运用 DevOps 或者 DevSecOp

DevOps 团队需要 IT 领导者关注三件事：沟通、技术债务和信任。 IT 领导者可以从大量的 DevOps 材料和 向 DevOps 转变 所要求的文化挑战中学习。但是，你在一个 DevOps 团队面对长期或短期的团结挑战的调整中 —— 一个 CIO 真正需要他们做的是什么呢？ 在我与 DevOps 团队成员的谈话中，我听到的其中一些内容让你感到非常的意外。DevOps 专家（无论是内部团队的

想要实现 DevOps 但是不知道如何开始吗？试试这 5 个最佳实践吧。 想要采用 DevOps 的人通常会过早的被它的歧义性给吓跑，更不要说更加深入的使用了。当一些人开始使用 DevOps 的时候都会问：“如何开始使用呢？”，”怎么才算使用了呢？“。这 5 个最佳实践是指导你的 DevOps 之旅的很好的路线图。 1、 衡量所有的事情 除非你能够量化输出结果，否则你并不能确认你的努力能否使事情变

你是否担心工作中自动化将代替人？可能是对的，但是这并不是件坏事。 这是一个很正常的担心：DevOps 最终会让你失业？毕竟，DevOps 意味着开发人员做运营，对吗？DevOps 是自动化的。如果我的工作都自动化了，我去做什么？实行持续分发和容器化意味着运营已经过时了吗？对于 DevOps 来说，所有的东西都是代码：基础设施是代码、测试是代码、这个和那个都是代码。如果我没有这些技能怎么办？ Dev

专家们权衡了 DevOps 团队最近会有何期望。 “DevOps” 一词通常认为是来源于 这篇 2008 年关于敏捷基础设施和运营的讲演中。现在的 IT 词汇中，它无处不在，这个“混搭”的词汇出现还不到 10 年：我们还在研究它在 IT 中更现代化的工作方法。 诚然，多年来一直在 “从事 DevOps” 的人积累了丰富的知识。但是大多数的 DevOps 环境 —— 人与 文化 、流程与方法、工具与

想要在今天的快节奏的商业环境中获得成功？要么选择 DevOps，要么死亡。 在很久之前，遥远的银河系中，在 DevOps 成为主流实践之前，软件开发的过程是极其缓慢、单调和按部就班的。当一个应用准备要部署的时候，就已经为下一个主要版本迭代积累了一长串的变更和修复。每次为新版本迭代所花费的准备时间都需要花费数个月的时间去回顾和贯穿整个开发周期。请记住这个过程将会在交付更新给用户的过程中不断的 重复。

DevOps 是一种持续性的改变和提高：那么也准备改变你所珍视的领导力准则吧。 如果 [DevOps] 最终更多的是一种文化而非某种技术或者平台，那么请记住：它没有终点线。而是一种持续性的改变和提高——而且最高管理层并不及格。 然而，如果期望 DevOps 能够帮助获得更多的成果，领导者需要修订他们的一些传统的方法。让我们考虑 7 个在 DevOps 时代更有效的 IT 领导的想法。 1、 向失败

DevSecOps 也许不是一个优雅的词汇，但是其结果很吸引人：更强的安全、提前出现在开发周期中。来看看一个 IT 领导与 Meltdown 的拼搏。 如果 DevOps 最终是关于创造更好的软件，那也就意味着是更安全的软件。 而到了术语 “DevSecOps”，就像任何其他 IT 术语一样，DevSecOps —— 一个更成熟的 DevOps 的后代 ——可能容易受到炒作和盗用。但这个术语对那些

这些技巧或许对那些想要践行 DevOps 的系统运维和开发者能有所帮助。 在去年大概一年的时间里，我注意到对“Devops 实践”感兴趣的开发人员和系统管理员突然有了明显的增加。这样的变化也合理：现在开发者只要花很少的钱，调用一些 API，就能单枪匹马地在一整套分布式基础设施上运行自己的应用，在这个时代，开发和运维的紧密程度前所未有。我看过许多博客和文章介绍很酷的 DevOps 工具和相关思想，但

推动大规模的组织变革是一个痛苦的过程。对于 DevOps 来说，尽管也有阵痛，但变革带来的价值则相当可观。 避免痛苦是一种强大的动力。一些研究表明，植物也会通过遭受疼痛的过程以采取措施来保护自己。我们人类有时也会刻意让自己受苦——在剧烈运动之后，身体可能会发生酸痛，但我们仍然坚持运动。那是因为当人认为整个过程利大于弊时，几乎可以忍受任何事情。 推动大规模的组织变革的过程确实是痛苦的。有人可能会因难

容器技术的使用支撑了目前 DevOps 三大主要实践：工作流、及时反馈、持续学习。 有人说容器技术与 DevOps 二者在发展的过程中是互相促进的关系。得益于 DevOps 设计理念的流行，容器生态系统在设计上与组件选择上也有相应发展。同时，由于容器技术在生产环境中的使用，反过来也促进了 DevOps 三大主要实践：支撑 DevOps 的三个实践。 工作流 容器中的工作流 每个容器都可以看成一个独

开发人员不需要成为安全专家, 但他们确实需要摆脱将安全视为一些不幸障碍的心态。 DevOps 并不意味着每个人都需要成为开发和运维方面的专家。尤其在大型组织中，其中角色往往更加专业化。相反，DevOps 思想在某种程度上更多地是关注问题的分离。在某种程度上，运维团队可以为开发人员（无论是在本地云还是在公共云中）部署平台，并且不受影响，这对两个团队来说都是好消息。开发人员可以获得高效的开发环境和自助

通过不断分析代码以了解潜在的质量问题，开源的 SonarQube 项目支持了 DevOps 的“尽早发布和经常发布” 的思维模式。 越来越多的组织正在实施 DevOps 以便在通过中间开发和测试环境以后更快更好的将新代码引入到生产环境。虽然版本控制、持续集成和部署以及自动化测试都属于 DevOps 的范畴，但仍然存在一个关键问题：组织如何量化代码质量，而不仅仅是部署的速度？ SonarQube 是

让一名非工程师来解释为什么你不必成为一位开发者或运维就能爱上 DevOps。 我从未做过开发或运维的工作 —— 那怎么我在写一篇关于 DevOps 的文章？我一直都对计算机和技术有兴趣。我还对社群、心理学以及帮助他人充满热情。当我第一次听到 DevOps 时，这个概念激起了我的兴趣，因为它看起来融合了很多我感兴趣的东西，即便我是不写代码的。 我的第一台电脑是 TRS-80，我喜欢在上面编写 BAS