围绕云计算的概念和术语仍然很新，但是也在不断的改进。

不管怎么看，云计算也只有十多年的发展时间。一些我们习以为常的云计算的概念和术语仍然很新。美国国家标准与技术研究所（NIST）文档显示，一些已经被熟悉的术语定义在 2011 年才被发布，例如基础设施即服务（IaaS），而在此之前它就以草案的形式广泛流传。

在该文档中其它定义中，有一个叫做 混合云 hybrid cloud 。让我们回溯一下该术语在这段期间的变化是很有启发性的。云基础设施已经超越了相对简单的分类。此外，它还强调了开源软件的使用者所熟悉的优先级，例如灵活性、可移植性、选择性，已经被运用到了混合云上。

NIST 对混合云最初的定义主要集中于 云爆发 cloud bursting ，你能使用内部的基础设施去处理一个基本的计算负荷，但是如果你的负荷量暴涨，可以将多出来的转为使用公有云。与之密切联系的是加强私有云与公有云之间 API 的兼容性，甚至是创造一个现货市场来提供最便宜的容量。

Nick Carr 在 The Big Switch 一书中提出一个概念，云是一种计算单元，其与输电网类似。这个故事不错，但是即使在早期，这种类比的局限性也变得很明显。计算不是以电流方式呈现的一种物品。需要关注的是，公有云提供商以及 OpenStack 一类的开源云软件激增的新功能，可见许多用户并不仅仅是寻找最便宜的通用计算能力。

云爆发的概念基本上忽略了计算是与数据相联系的现实，你不可能只移动洪水般突如其来的数据而不承担巨大的带宽费用，以及不用为转移需要花费的时间而操作。Dave McCrory 发明了 “ 数据引力 data gravity ”一词去描述这个限制。

那么既然混合云有如此负面的情况，为什么我们现在还要再讨论混合云？

正如我说的，混合云的最初的构想是在云爆发的背景下诞生的。云爆发强调的是快速甚至是即时的将工作环境从一个云转移到另一个云上；然而，混合云也意味着应用和数据的移植性。确实，如之前 2011 年我在 CNET 的文章中写到：“我认为过度关注于全自动的工作转换给我们自己造成了困扰，我们真正应该关心的是，如果供应商不能满意我们的需求或者尝试将我们锁定在其平台上时，我们是否有将数据从一个地方到另一个地方的迁移能力。”

从那以后，探索云之间的移植性有了进一步的进展。

Linux 是云移植性的关键，因为它能运行在各种地方，无论是从裸机到内部虚拟基础设施，还是从私有云到公有云。Linux 提供了一个完整、可靠的平台，其具有稳定的 API 接口，且可以依靠这些接口编写程序。

被广泛采纳的容器进一步加强了 Linux 提供应用在云之间移植的能力。通过提供一个包含了应用的基础配置环境的镜像，应用在开发、测试和最终运行环境之间移动时容器提供了可移植性和兼容性。

Linux 容器被应用到要求可移植性、可配置性以及独立性的许多方面上。不管是预置的云，还是公有云，以及混合云都是如此。

容器使用的是基于镜像的部署模式，这让在不同环境中分享一个应用或者具有全部基础环境的服务集变得容易了。

在 OCI 支持下开发的规范定义了容器镜像的内容及其所依赖、环境、参数和一些镜像正确运行所必须的要求。在标准化的作用下，OCI 为许多其它工具提供了一个机会，它们现在可以依靠稳定的运行环境和镜像规范了。

同时，通过 Gluster 和 Ceph 这类的开源技术，分布式存储能提供数据在云上的可移植性。 物理约束限制了如何快速简单地把数据从一个地方移动到另一个地方；然而，随着组织部署和使用不同类型的基础架构，他们越来越渴望一个不受物理、虚拟和云资源限制的开放的软件定义储存平台。

尤其是在数据存储需求飞速增长的情况下，由于预测分析，物联网和实时监控的趋势。2016 年的一项研究表明，98% 的 IT 决策者认为一个更敏捷的存储解决方案对他们的组织是有利的。在同一个研究中，他们列举出不恰当的存储基础设施是最令他们组织受挫的事情之一。

混合云表现出的是提供在不同计算能力和资源之间合适的移植性和兼容性。其不仅仅是将私有云和公有云同时运用在一个应用中。它是一套多种类型的服务，其中的一部分可能是你们 IT 部门建立和操作的，而另一部分可能来源于外部。

它们可能是软件即服务（SaaS）应用的混合，例如邮件和客户关系管理（CRM）。被 Kubernetes 这类开源软件协调在一起的容器平台越来越受新开发应用的欢迎。你的组织可能正在运用某一家大型云服务提供商来做一些事情。同时你也能在私有云或更加传统的内部基础设施上操作一些你自己的基础设施。

这就是现在混合云的现状，它能被归纳为两个选择，选择最合适的基础设施和服务，以及选择把应用和数据从一个地方移动到另一个你想的地方。

相关阅读: 多重云和混合云有什么不同？

作者简介：

Gordon Haff 是红帽云的布道者，常受到业内和客户的高度赞赏，帮助红帽云组合方案的发展。他是《Computing Next: How the Cloud Opens the Future》的作者，除此之外他还有许多出版物。在红帽之前，Gordon 写了大量的研究简报，经常被纽约时报等出版物在 IT 类话题上引用，在产品和市场策略上给予客户建议。他职业生涯的早期，在 Data General 他负责将各种不同的计算机系统，从微型计算机到大型的 UNIX 服务器，引入市场。他有麻省理工学院和达特茅斯学院的工程学位，还是康奈尔大学约翰逊商学院的工商管理学硕士。

via: https://opensource.com/article/17/7/hybrid-cloud

作者：Gordon Haff (Red Hat) 译者：ZH1122 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

2017云栖大会，阿里巴巴集团 CTO 兼阿里云 CTO 行癫就开源谈了一番他的看法。

行癫在阿里历经了从技术到商业，又从商业到技术的过程，十多年的阿里生涯，让他对开源、技术和商业有了深刻了解。

开源的核心是连接，社区的根本是连接

行癫说，阿里巴巴的平台将“消费者和商家连接在了一起，这个平台不仅是个渠道，也从消费者获得了非常多一些反馈，能够快速的根据消费者的需求，来做出满足消费者要求的一些产品。我们回过头来想一下，开源社区，非常像这个模式。”

这个商业模式，其实就是将相关的人、物、关系连接到了一起，与开源的道理是一致的。

行癫认为“开源要做好，它最重要、最核心的一点，是把相关的一些开发者、用户，通过软件、工具和平台连接在一起了。”

纵观那些发展的比较好的开源软件，都是通过开源软件、通过开源的模式和开源的平台，将最优秀的开发者联系起来，将最有价值的软件用户连接起来。

互联网的本质是连接。没有互联网之前，所有的行为、所有的商业都是单向的；有互联网之后，非常非常多的连接就产生了。所以对于开源，行癫认为它“是根植于互联网的，有了互联网技术平台之后，开源能够做得更好。”

开源是生长于社区土壤中的，而社区就是一种将参与者连接起来的机制。首先通过将人连接起来，然后才能逐步考虑将来的发展，考虑如何发展和进行商业化发展。

一个开源软件在诞生之初，有可能只是表达一下对技术的理解和看法，也有可能只是解决某个痛点——大多数情况下是自己的痛点，还有可能只是好玩。至于将来能走多远，能否得到社区的迎合，能否发展出一个生态，甚至成为商业新动力，在最初往往并没有很远的计划和远景。

但是，在建立连接后，有了一个社区的土壤之后，就有了成长为一棵大树、一片森林的可能。“把人连接在一起，然后后面才是讨论核心问题，和怎么样进行商业化”。

而现在的云栖大会“也是一个连接”，通过网上直播，中国大概会有一千万左右的开发者会来参加这个云栖大会，所以“云栖大会把中国最具有活力的一群开发者，全部连接在一起了。今天这种形式的大会，本身就是一个对开发者来说，一个最重要的纽带。”

阿里为何拥抱开源

阿里巴巴最初是采用商用软件做解决方案，基于小型机、企业级的基础设施。阿里巴巴的平台三个比较大的特点，“互联网级的规模、金融级的稳定性、企业级的复杂程度。”在这种情况下，一方面，如果继续用 IOE 基础设施，随着业务规模的扩大，将来根本无法覆盖剧增的成本。另外一方面，商用软件的支持情况也难以满足业务的增长带来的各种需求。

因此，阿里巴巴发起了去 IOE 行动，全面投向开源解决方案，用开源软件构建了满足其体量和需求的基础设施。在这个过程中，阿里巴巴一方面大量采用开源软件替代传统的 IOE 基础设施，另外一方面也要面临一些前所未有的需求。

“阿里巴巴应该是最早把这么复杂的一个应用系统，全部放到开源社区的应用上的。”因此，在规模扩大了到开源软件原来很少涉及的数量级时，就会发现很多之前隐藏的场景问题。在这其中解决了无数的问题，因为面临的环境跟别人不一样，面临的要求也跟别人不一样。阿里做了非常多的工作，把他们的互联网的架构中现在社区不具备的一些功能，都纷纷补上去。自己开发了很多的中间件去满足这些功能需求。

积极回馈开源

在全面投入开源的怀抱后，阿里也积极回馈开源社区，真正使自己成为开源社区的一份子。这可以从近年来阿里加大对开源社区的赞助、代码的贡献、开源社区的扶持，以及鼓励技术人员走出去等举措上可以看出来。

在本次云栖大会上，阿里巴巴宣布了正式发布了 OpenMessaging 和 ApsaraCache 两个开源项目。此前，阿里巴巴捐赠的开源的 RocketMQ 已被 Apache 基金会接纳为全球顶级项目。

“开源和阿里巴巴都根植于互联网，有了互联网技术平台之后，开源和商业将在未来相当长的时间内保持平衡的发展。”行癫表示。

据悉， OpenMessaging 项目是由阿里巴巴发起，与雅虎、滴滴出行、 Streamlio 公司共同参与创立的分布式消息中间件、流处理领域的应用开发标准，目前已正式入驻 Linux 基金会，这也是国内首个在全球范围内发起的分布式消息领域的国际标准。

该标准可以不受编程语言限制，能满足企业对扩展性、伸缩性、隔离和安全的要求，可提供大规模的工业级支持，支持标准参照点的添加与标准化测试，开放接口便于对其他不同标准的接入，适用于金融、电商、物联网、工业互联网等行业。

“OpenMessaging 希望成为全球化、无国界、无公司边界、面向云和大数据、多行业领域的一站式方案标准，这也是阿里巴巴第一次在国际社区进行的主导和探索。” 项目负责人蒋江伟表示。

同时，在云栖大会现场，阿里云数据库负责人余锋与 Redis 创始人 Salvatore 共同宣布 ApsaraCache 在 Github 上正式开放下载。ApsaraCache 是阿里云数据库 Redis 版的分支，适用于更大的数据规模和更多的应用场景。

“ApsaraCache 项目开源是一件非常好的事情，将能够吸引全世界更多 Redis 核心专家参与，进一步提升产品的稳定性和可用性。” Salvatore 表示。

Mysql 之父、 MariaDB 创始人 Michael Widenius 已经连续三年参加云栖大会，年过 50 的他依然奋斗在代码第一线，Widenius 表示：“很多 MariaDB 的运用源自我们的开发者，维基百科用的就是 MariaDB，我们也从阿里巴巴中获得了很多开源的支持和贡献，确保能给大家提供功能丰富的数据库产品。”

图为 Mysql 之父、 MariaDB 创始人 Michael Widenius

近年来，阿里巴巴在技术领域投入不断加强，拥抱开源也由来已久，积极加入了包括自由软件基金会、Apache 软件基金会和 Linux 基金会在内的多家国际知名开源组织。目前，阿里巴巴开源和维护的开源项目超过 150 个，涵盖中间件、开发框架、数据库和各种工具类软件。在开源中国公布的“2016 年度最受欢迎中国开源软件评选 TOP20”榜单中，阿里巴巴独占 4 席。其中 Weex、Ant Design、Dubbo、Fastjson 在 GitHub 上的星标数已经破万，“Alibaba”组织在 GitHub 上星标数超过 170,000，组织排名进入前十。

开源之路

行癫认为，“开源我觉得有几个层次”，刚开始可能只是做了一个工具，这个工具做得非常好，可以解决一个非常确定性的问题。逐渐地，这个工具可能会变成一个产品、变成一个系统，慢慢延伸出一堆工具。“开源要成功，第一步要做好一个工具，第二步会变成全链的产品，我觉得最成功的就是变成新的一个生态。” 开源软件组成了一个生态，无数人为这个生态贡献了新的智慧、新的工具。融入这个生态的人，或许只用非常少的代价，就能够找到跟他的工作场景、业务场景相匹配的模式。到这个程度，“这个社区就发展得比较成熟了。这个可能是大多数开源软件必须要去走的一些路径。”

“今天要开源的其实不仅是软件，还有很多硬件”，行癫说。“今天的开源比以前的更复杂，有可能是端跟云端的结合。……互联网第一阶段的开源，是基于互联网的端建成的；互联网的第二个阶段是 IoT，我们希望所有的设备能够串起来。所以我认为接下去开源软件会与硬件结合，这就是从单纯的互联网向 IoT 时代发展非常重要的一个过程。”

结语

在近来几届云栖大会上，开源已经成为了永恒的主题，除了开源专场之外，在各个会场和论坛，充斥着各种热烈的开源气息，无数建筑于开源之上的产品、服务源源不断的开发出来，无数的技术人员和开源爱好者投身于开源世界。让我们期待云栖大会成为开源的大会，成为中国开源界和世界开源接轨的枢纽。

对于家用 WiFi 路由器和接入点来说，OpenWrt 项目可能是最广为人知的 Linux 发行版；在 12 年以前，它产自现在有名的 Linksys WRT54G 路由器的源代码。（2016 年）五月初，当一群 OpenWrt 核心开发者 宣布 他们将开始着手 OpenWrt 的一个副产品 （或者，可能算一个分支）叫 Linux 嵌入开发环境 （LEDE）时，OpenWrt 用户社区陷入一片巨大的混乱中。为什么产生分裂对公众来说并不明朗，而且 LEDE 宣言惊到了一些其他 OpenWrt 开发者也暗示这团队的内部矛盾。

LEDE 宣言被 Jo-Philipp Wich 于五月三日发往所有 OpenWrt 开发者列表和新 LEDE 开发者列表。它将 LEDE 描述为“OpenWrt 社区的一次重启” 和 “OpenWrt 项目的一个副产品” ，希望产生一个 “注重透明性、合作和权利分散”的 Linux 嵌入式开发社区。

给出的重启的原因是 OpenWrt 遭受着长期以来存在且不能从内部解决的问题 —— 换句话说，关于内部处理方式和政策。例如，宣言称，开发者的数目在不断减少，却没有接纳新开发者的方式（而且貌似没有授权委托访问给新开发者的方法）。宣言说到，项目的基础设施不可靠（例如，去年服务器挂掉在这个项目中也引发了相当多的矛盾），但是内部不合和单点错误阻止了修复它。内部和从这个项目到外面世界也存在着“交流、透明度和合作”的普遍缺失。最后，一些技术缺陷被引述：不充分的测试、缺乏常规维护，以及窘迫的稳固性与文档。

该宣言继续描述 LEDE 重启将怎样解决这些问题。所有交流频道都会打开供公众使用，决策将在项目范围内的投票决出，合并政策将放宽等等。更详细的说明可以在 LEDE 站点的规则页找到。其他细节中，它说贡献者将只有一个阶级（也就是，没有“核心开发者”这样拥有额外权利的群体），简单的少数服从多数投票作出决定，并且任何被这个项目管理的基础设施必须有三个以上管理员账户。在 LEDE 邮件列表， Hauke Mehrtens 补充到，该项目将会努力把补丁投递到上游项目 —— 这是过去 OpenWrt 被批判的一点，尤其是对 Linux 内核。

除了 Wich，这个宣言被 OpenWrt 贡献者 John Crispin、 Daniel Golle、 Felix Fietkau、 Mehrtens、 Matthias Schiffer 和 Steven Barth 共同签署，并以给其他有兴趣参与的人访问 LEDE 站点的邀请作为了宣言结尾。

回应和问题

有人可能会猜想 LEDE 组织者预期他们的宣言会有或积极或消极的反响。毕竟，细读宣言中批判 OpenWrt 项目暗示了 LEDE 阵营发现有一些 OpenWrt 项目成员难以共事（例如，“单点错误” 或 “内部不和”阻止了基础设施的修复）。

并且，确实，有很多消极回应。OpenWrt 创立者之一 Mike Baker 回应 了一些警告，反驳所有 LEDE 宣言中的结论并称“像‘重启’这样的词语都是含糊不清的，且具有误导性的，而且 LEDE 项目未能揭晓其真实本质。”与此同时，有人关闭了那些在 LEDE 宣言上署名的开发者的 @openwrt.org 邮件入口；当 Fietkau 提出反对， Baker 回复账户“暂时停用”是因为“还不确定 LEDE 能不能代表 OpenWrt。” 另一个 OpenWrt 核心成员 Imre Kaloz 写到，他们现在所抱怨的 OpenWrt 的“大多数[破]事就是 LEDE 团队弄出来的”。

但是大多数 OpenWrt 列表的回应对该宣言表示困惑。邮件列表成员不明确 LEDE 团队是否将对 OpenWrt 继续贡献，或导致了这次分裂的架构和内部问题的确切本质是什么。 Baker 的第一反应是对宣言中引述的那些问题缺乏公开讨论表示难过：“我们意识到当前的 OpenWrt 项目遭受着许多的问题，”但“我们希望有机会去讨论并尝试着解决”它们。 Baker 作出结论：

我们想强调，我们确实希望能够公开的讨论，并解决掉手头事情。我们的目标是与所有能够且希望对 OpenWrt 作出贡献的参与者共事，包括 LEDE 团队。

除了有关新项目的初心的问题之外，一些邮件列表订阅者提出了 LEDE 是否与 OpenWrt 有相同的使用场景定位，给新项目取一个听起来更一般的名字的疑惑。此外，许多人，像 Roman Yeryomin，对为什么这些问题需要 LEDE 团队的离开（来解决）表示了疑惑，特别是，与此同时，LEDE 团队由大部分活跃核心 OpenWrt 开发者构成。一些列表订阅者，像 Michael Richardson，甚至不清楚谁还会继续开发 OpenWrt。

澄清

LEDE 团队尝试着深入阐释他们的境况。在 Fietkau 给 Baker 的回复中，他说在 OpenWrt 内部关于有目的地改变的讨论会很快变得“有毒，”因此导致没有进展。而且：

这些讨论的要点在于那些掌握着基础设施关键部分的人精力有限却拒绝他人的加入和帮助，甚至是面对无法及时解决的重要问题时也是这样。

这种像单点错误一样的事已经持续了很多年了，没有任何有意义的进展来解决它。

Wich 和 Fietkau 都没有明显指出具体的人，虽然在列表的其他人可能会想到这个基础设施和 OpenWrt 的内部决策问题要归咎于某些人。 Daniel Dickinson 陈述到：

我的印象是 Kaloz (至少) 以基础设施为胁来保持控制，并且根本性的问题是 OpenWrt 是不民主的，而且忽视那些真正在 OpenWrt 工作的人想要的是什么，无视他们的愿望，因为他/他们把控着要害。

另一方面， Luka Perkov 指出 很多 OpemWrt 开发者想从 Subversion 转移到 Git，但 Fietkau 却阻止这种变化。

看起来是 OpenWrt 的管理结构并非如预期般发挥作用，其结果导致个人冲突爆发，而且由于没有完好定义的流程，某些人能够简单的忽视或阻止提议的变化。明显，这不是一个能长期持续的模式。

五月六日，Crispin 在一个新的帖子中写给 OpenWrt 列表，尝试着重构 LEDE 项目宣言。他说，这并不是意味着“敌对或分裂”行为，只是与结构失衡的 OpenWrt 做个清晰的划分并以新的方式开始。问题在于“不要归咎于一次单独的事件、一个人或者一次口水战”，他说，“我们想与过去自己造成的错误和多次作出的错误管理决定分开”。 Crispin 也承认宣言没有把握好，说 LEDE 团队 “弄糟了发起纲领。”

Crispin 的邮件似乎没能使 Kaloz 满意，她坚持认为 Crispin（作为发行经理）和 Fietkau（作为领头开发者）可以轻易地在 OpenWrt 内部作出想要的改变。但是讨论的下文后来变得沉寂；之后 LEDE 或者 OpenWrt 哪边会发生什么还有待观察。

目的

对于那些想要探究 LEDE 所认为有问题的事情的更多细节的 OpenWrt 成员来说，有更多的信息来源可以为这个问题提供线索。在公众宣言之前，LEDE 组织花了几周谈论他们的计划，会议的 IRC 日志现已发布。特别有趣的是，三月三十日的会议包含了这个项目目标的细节讨论。

其中包括一些针对 OpenWrt 的基础设施的抱怨，像项目的 Trac 工单追踪器的缺点。它充斥着不完整的漏洞报告和“我也是”的评论，Wich 说，结果几乎没有贡献者使用它。此外，他们也在 Github 上追踪 bug，人们对这件事感到困惑，这使得工单应该在哪里讨论不明了。

这些 IRC 讨论也定下了开发流程本身。LEDE 团队想作出些改变，以使用会合并到主干的阶段开发分支为开端，与 OpenWrt 所使用的“直接提交到主干”方式不同。该项目也将提供基于时间的发行版，并通过只发行已被成功测试的二进制模块来鼓励用户测试，由社区而不是核心开发者在实际的硬件上进行测试。

最后，这些 IRC 讨论也确定了 LEDE 团队的目的不是用它的宣言吓唬 OpenWrt。Crispin 提到 LEDE 首先是“半公开的”并渐渐做得更公开。 Wich 解释说他希望 LEDE 是“中立的、专业的，并打开大门欢迎 OpenWrt 以便将来的合并”。不幸的是，前期发起工作并不是做得很好。

在一封邮件中， Fietkau 补充到 OpenWrt 核心开发者确实在任务中遇到瓶颈，像补丁复审和基础设施维护这些事情让他们完成不了其他工作，比如配置下载镜像和改良构建系统。在 LEDE 宣言之后短短几天内，他说，团队成功解决了镜像和构建系统任务，而这些已被搁置多年。

我们在 LEDE 所做的事情很多是基于转移到 Github 的去中心化软件包开发经验，并放弃了软件包应如何被维护的许多控制。这样最终有效减少了我们的工作量，而且我们有了很多更活跃的开发者。

我们真的希望为核心开发做一些类似的事，但是基于我们想作出更大改变的经验，我们觉得在 OpenWrt 项目内做不到。

修复基础设施也将收获其他好处，他说，就比如改进了用于管理签署发布版本的密码的系统。团队正在考虑在某些情况下非上游补丁的规则，像需要补丁的描述和为什么没有发送到上游的解释。他也提到很多留下的 OpenWrt 开发者表示有兴趣加入 LEDE，相关当事人正试图弄清楚他们是否会重新合并该项目。

有人希望 LEDE 更为扁平的管理模式和更为透明的分工会在困扰 OpenWrt 的方面取得成功。解决最初的宣言中被诟病的沟通方面的问题会是最大的障碍。如果那个过程处理得好，那么，未来 LEDE 和 OpenWrt 可能能够求同存异并协作。否则，之后两个团队可能一起被迫发展到比以前拥有更少资源的方向，这也许不是开发者或用户想看到的。

via: https://lwn.net/Articles/686767/

作者：Nathan Willis 译者：XYenChi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

目的是任何团队组建的首要之事。如果一个人足以实现那个目的，那么就没有必要组成团队。而且如果没有重要目标，你根本不需要一个团队。但只要任务需要的专业知识比一个人所拥有的更多，我们就会遇到集体参与的问题——如果处理不当，会使你脱离正轨。

想象一群人困在洞穴中。没有一个人具备如何出去的全部知识，所以每个人要协作，心路常开，在想要做的事情上尽力配合。当（且仅当）组建了适当的工作团队之后，才能为实现团队的共同目标创造出合适的环境。

但确实有人觉得待在洞穴中很舒适而且只想待在那里。在组织里，领导者们如何掌控那些实际上抵触改善、待在洞穴中觉得舒适的人？同时该如何找到拥有共同目标但是不在自己组织的人？

我从事指导国际销售培训，刚开始甚至很少有人认为我的工作有价值。所以，我想出一套使他们信服的战术。那个战术非常成功以至于我决定深入研究它并与各位分享。

获得支持

为了建立公司强大的企业文化，有人会反对改变，并且从幕后打压任何改变的提议。他们希望每个人都待在那个舒适的洞穴里。例如，当我第一次接触到海外销售培训，我受到了一些关键人物的严厉阻挠。他们迫使其他人相信某个东京人做不了销售培训——只要基本的产品培训就行了。

尽管我最终解决了这个问题，但我那时候真的不知道该怎么办。所以，我开始研究顾问们在改变公司里抗拒改变的人的想法这个问题上该如何给出建议。从学者 Laurence Haughton 的研究中，我发现一般对于改变的提议，组织中 83% 的人最开始不会支持你。大约 17% 会从一开始就支持你，但是只要看到一个实验案例成功之后，他们觉得这个主意安全可行了，60% 的人会支持你。最后，有部分人会反对任何改变，无论它有多棒。

我研究的步骤：

• 从试验项目开始
• 开导洞穴人
• 快速跟进
• 开导洞穴首领
• 全局展开

1、 从试验项目开始

找到高价值且成功率较高的项目——而不是大的、成本高的、周期长的、全局的行动。然后，找到能看到项目价值、理解它的价值并能为之奋斗的关键人物。这些人不应该只是“老好人”或者“朋友”；他们必须相信项目的目标而且拥有推进项目的能力或经验。不要急于求成。只要足够支持你研究并保持进度即可。

个人而言，我在新加坡的一个小型车辆代理商那里举办了自己的第一场销售研讨会。虽然并不是特别成功，但足以让人们开始讨论销售训练会达到怎样的效果。那时候的我困在洞穴里（那是一份我不想做的工作）。这个试验销售训练是我走出困境的蓝图。

2、 开导洞穴人

洞穴（CAVE）实际上是我从 Laurence Haughton 那里听来的缩略词。它代表着 Citizens Against Virtually Everything。（LCTT 译注，此处一语双关前文提及的洞穴。）

你得辨别这些人，因为他们会暗地里阻挠项目的进展，特别是早期脆弱的时候。他们容易黑化：总是消极。他们频繁使用“但是”、“如果”和“为什么”，只是想推脱你。他们询问轻易不可得的细节信息。他们花费过多的时间在问题上，而不是寻找解决方案。他们认为每个失败都是一个趋势。他们总是对人而不是对事。他们作出反对建议的陈述却又不能简单确认。

避开洞穴人；不要让他们太早加入项目的讨论。他们固守成见，因为他们看不到改变所具有的价值。他们安居于洞穴，所以试着让他们去做些其他事。你应该找出我上面提到那 17% 的人群中的关键人物，那些想要改变的人，并且跟他们开一个非常隐秘的准备会。

我在五十铃汽车（股东之一是通用汽车公司）的时候，销售训练项目开始于一个销往世界上其他小国家的合资分销商，主要是非洲、南亚、拉丁美洲和中东。我的个人团队由通用汽车公司雪佛兰的人、五十铃产品经理和分公司的销售计划员工组成。隔绝其他任何人于这个圈子之外。

3、 快速跟进

洞穴人总是慢吞吞的，那么你就迅速行动起来。如果你在他们参与之前就有了小成就的经历，他们对你团队产生消极影响的能力将大大减弱——你要在他们提出之前就解决他们必然反对的问题。再一次，选择一个成功率高的试验项目，很快能出结果的。然后宣传成功，就像广告上的加粗标题。

当我在新加坡研讨会上所言开始流传时，其他地区开始意识到销售训练的好处。仅在新加坡研讨会之后，我就被派到马来西亚开展了四次以上。

4、 开导洞穴首领

只要你取得了第一个小项目的成功，就针对能影响洞穴首领的关键人物推荐项目。让团队继续该项目以告诉关键人物成功的经历。一线人员甚至顾客也能提供有力的证明。 洞穴管理者往往只着眼于销量和收益，那么就宣扬项目在降低开支、减少浪费和增加销量方面的价值。

自新加坡的第一次研讨会及之后，我向直接掌握了五十铃销售渠道的前线销售部门员工和通用汽车真正想看到进展的人极力宣传他们的成功。当他们接受了之后，他们会向上级提出培训请求并让其看到分公司销量的提升。

5、 全局展开

一旦一把手站在了自己这边，立马向整个组织宣告成功的试验项目。讨论项目的扩展。

用上面的方法，在 21 年的职业生涯中，我在世界各地超过 60 个国家举办了研讨会。我确实走出了洞穴——并且真的看到了广阔的世界。

作者简介：

Ron McFarland - Ron McFarland 已在日本工作 40 年，从事国际销售、销售管理和在世界范围内扩展销售业务 30 载有余。他曾去过或就职于 80 多个国家。在过去的 14 年里， Ron 为总部位于东京的日本硬件切割厂在美国和欧洲各地建立分销商。

via: https://opensource.com/open-organization/17/1/escape-the-cave

作者：Ron McFarland 译者：XYenChi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

学习使用开放式决策框架来写一本书

GSD（get stuff done 的缩写，即搞定）指导着我的工作方式。数年来，我将各种方法论融入我日常工作的习惯中，包括精益方法的反馈循环，和敏捷开发的迭代优化，以此来更好地 GSD（如果把 GSD 当作动词的话）。这意味着我必须非常有效地利用我的时间：列出清晰、各自独立的目标；标记已完成的项目；用迭代的方式地持续推进项目进度。但是当我们以开放为基础时仍然能够 GSD 吗？又或者 GSD 的方法完全行不通呢？大多数人都认为这会导致糟糕的状况，但我发现事实并不一定这样。

在开放的环境中工作，遵循 开放式决策框架 Open Decision Framework 中的指导，会让项目起步变慢。但是在最近的一个项目中，我们作出了一个决定，一个从开始就正确的决定：以开放的方式工作，并与我们的社群一起合作。

这是我们能做的最好的决定。

我们来看看这次经历带来的意想不到的结果，再看看我们如何将 GSD 思想融入开放式组织框架。

建立社区

2014 年 10 月，我接手了一个新的项目：当时红帽的 CEO Jim Whitehurst 即将推出一本新书 《开放式组织》 The Open Organization ，我要根据书中提出的概念，建立一个社区。“太棒了，这听起来是一个挑战，我加入了！”我这样想。但不久，冒牌者综合征便出现了，我又开始想：“我们究竟要做什么呢？怎样才算成功呢？”

让我剧透一下，在这本书的结尾处，Jim 鼓励读者访问 Opensource.com，继续探讨 21 世纪的开放和管理。所以，在 2015 年 5 月，我们的团队在网站上建立了一个新的板块来讨论这些想法。我们计划讲一些故事，就像我们在 Opensource.com 上常做的那样，只不过这次围绕着书中的观点与概念。之后，我们每周都发布新的文章，在 Twitter 上举办了一个在线的读书俱乐部，还将《开放式组织》打造成了系列书籍。

我们内部独自完成了该系列书籍的前三期，每隔六个月发布一期。每完成一期，我们就向社区发布。然后我们继续完成下一期的工作，如此循环下去。

这种工作方式，让我们看到了很大的成功。近 3000 人订阅了该系列的新书：《开放式组织领袖手册》。我们用 6 个月的周期来完成这个项目，这样新书的发行日正好是前书的两周年纪念日。

在这样的背景下，我们完成这本书的方式是简单直接的：针对开放工作这个主题，我们收集了最好的故事，并将它们组织起来形成文章，招募作者填补一些内容上的空白，使用开源工具调整字体样式，与设计师一起完成封面，最终发布这本书。这样的工作方式使得我们能按照自己的时间线（GSD）全速前进。到第三本书时，我们的工作流已经基本完善了。

然而这一切在我们计划开始《开放式组织》的最后一本书时改变了，这本书将重点放在开放式组织和 IT 文化的交融上。我提议使用开放式决策框架来完成这本书，因为我想通过这本书证明开放式的工作方法能得到更好的结果，尽管我知道这可能会完全改变我们的工作方式。时间非常紧张（只有两个半月），但我们还是决定试一试。

用开放式决策框架来完成一本书

开放式决策框架列出了组成开放决策制定过程的 4 个阶段。下面是我们在每个阶段中的工作情况（以及开放是如何帮助完成工作的）。

1、 构思

我们首先写了一份草稿，罗列了对项目设想的愿景。我们需要拿出东西来和潜在的“顾客”分享（在这个例子中，“顾客”指潜在的利益相关者和作者）。然后我们约了一些领域专家面谈，这些专家能够给我们直接的诚实的意见。这些专家表现出的热情与他们提供的指导验证了我们的想法，同时提出了反馈意见使我们能继续向前。如果我们没有得到这些验证，我们会退回到我们最初的想法，再决定从哪里重新开始。

2、 计划与研究

经过几次面谈，我们准备在 Opensource.com 上公布这个项目。同时，我们在 Github 上也启动了这个项目，提供了项目描述、预计的时间线，并阐明了我们所受的约束。这次公布得到了很好的效果，我们最初计划的目录中欠缺了一些内容，在项目公布之后的 72 小时内就被补充完整了。另外（也是更重要的），读者针对一些章节，提出了本不在我们计划中的想法，但是读者觉得这些想法能够补充我们最初设想的版本。

回顾过去，我觉得在项目的第一和第二个阶段，开放项目并不会影响我们搞定项目的能力。事实上，这样工作有一个很大的好处：发现并填补内容的空缺。我们不只是填补了空缺，我们是迅速地填补了空缺，并且还是用我们自己从未考虑过的点子。这并不一定要求我们做更多的工作，只是改变了我们的工作方式。我们动用有限的人脉，邀请别人来写作，再组织收到的内容，设置上下文，将人们导向正确的方向。

3、 设计，开发和测试

项目的这个阶段完全围绕项目管理，管理一些像猫一样特立独行的人，并处理项目的预期。我们有明确的截止时间，我们提前沟通，频繁沟通。我们还使用了一个战略：列出了贡献者和利益相关者，在项目的整个过程中向他们告知项目的进度，尤其是我们在 Github 上标出的里程碑。

最后，我们的书需要一个名字。我们收集了许多反馈，指出书名应该是什么，更重要的是反馈指出了书名不应该是什么。我们通过 Github 上的工单收集反馈意见，并公开表示我们的团队将作最后的决定。当我们准备宣布最后的书名时，我的同事 Bryan Behrenshausen 做了很好的工作，分享了我们作出决定的过程。人们似乎对此感到高兴——即使他们不同意我们最后的书名。

书的“测试”阶段需要大量的校对。社区成员真的参与到回答这个“求助”贴中来。我们在 GitHub 工单上收到了大约 80 条意见，汇报校对工作的进度（更不用说通过电子邮件和其他反馈渠道获得的许多额外的反馈）。

关于搞定任务：在这个阶段，我们亲身体会了 Linus 法则：“ 众目之下， 笔误 无所遁形。 With more eyes, all typos are shallow. ” 如果我们像前三本书一样自己独立完成，那么整个校对的负担就会落在我们的肩上（就像这些书一样）！相反，社区成员慷慨地帮我们承担了校对的重担，我们的工作从自己校对（尽管我们仍然做了很多工作）转向管理所有的 change requests。对我们团队来说，这是一个受大家欢迎的改变；对社区来说，这是一个参与的机会。如果我们自己做的话，我们肯定能更快地完成校对，但是在开放的情况下，我们在截止日期之前发现了更多的错误，这一点毋庸置疑。

4、 发布

好了，我们现在推出了这本书的最终版本。（或者只是第一版？）

我们把发布分为两个阶段。首先，根据我们的公开的项目时间表，在最终日期之前的几天，我们安静地推出了这本书，以便让我们的社区贡献者帮助我们测试下载表格。第二阶段也就是现在，这本书的通用版的正式公布。当然，我们在发布后的仍然接受反馈，开源方式也正是如此。

成就解锁

遵循开放式决策框架是 《IT 文化变革指南》 Guide to IT Culture Change 成功的关键。通过与客户和利益相关者的合作，分享我们的制约因素，工作透明化，我们甚至超出了自己对图书项目的期望。

我对整个项目中的合作，反馈和活动感到非常满意。虽然有一段时间内没有像我想要的那样快速完成任务，这让我有一种焦虑感，但我很快就意识到，开放这个过程实际上让我们能完成更多的事情。基于上面我的概述这一点显而易见。

所以也许我应该重新考虑我的 GSD 心态，并将其扩展到 GMD：Get More Done，搞定更多工作，并且就这个例子说，取得更好的结果。

（题图：opensource.com）

作者简介：

Jason Hibbets - Jason Hibbets 是 Red Hat 企业营销中的高级社区传播者，也是 Opensource.com 的社区经理。 他自2003 年以来一直在 Red Hat，并且是开源城市基金会的创立者。之前的职位包括高级营销专员、项目经理、Red Hat 知识库维护人员和支持工程师。

via: https://opensource.com/open-organization/17/6/working-open-and-gsd

作者：Jason Hibbets 译者：explosic4 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

安全难以推行。在企业管理者迫使开发团队尽快发布程序的大环境下，很难说服他们花费有限的时间来修补安全漏洞。但是鉴于所有网络攻击中有 84％ 发生在应用层，作为一个组织是无法承担其开发团队不包括安全性带来的后果。

DevOps 的崛起为许多安全负责人带来了困境。Sonatype 的前 CTO Josh Corman 说：“这是对安全的威胁，但这也是让安全变得更好的机会。” Corman 是一个坚定的将安全和 DevOps 实践整合起来创建 “坚固的 DevOps”的倡导者。Business Insights 与 Corman 谈论了安全和 DevOps 共同的价值，以及这些共同价值如何帮助组织更少地受到中断和攻击的影响。

安全和 DevOps 实践如何互惠互利？

Josh Corman： 一个主要的例子是 DevOps 团队对所有可测量的东西进行检测的倾向。安全性一直在寻找更多的情报和遥测。你可以获取许多 DevOps 团队正在测量的信息，并将这些信息输入到你的日志管理或 SIEM （安全信息和事件管理系统）。

一个 OODA 循环（ 观察 observe 、 定向 orient 、 决定 decide 、 行为 act ）的前提是有足够普遍的眼睛和耳朵，以注意到窃窃私语和回声。DevOps 为你提供无处不在的仪器。

他们有分享其他文化观点吗？

JC： “严肃对待你的代码”是一个共同的价值观。例如，由 Netflix 编写的软件工具 Chaos Monkey 是 DevOps 团队的分水岭。它是为了测试亚马逊网络服务的弹性和可恢复性而创建的，Chaos Monkey 使得 Netflix 团队更加强大，更容易为中断做好准备。

所以现在有个想法是我们的系统需要测试，因此，James Wickett 和我及其他人决定做一个邪恶的、带有攻击性的 Chaos Monkey，这就是 GAUNTLT 项目的来由。它基本上是一堆安全测试, 可以在 DevOps 周期和 DevOps 工具链中使用。它也有非常适合 DevOps 的API。

企业安全和 DevOps 价值在哪里相交？

JC： 这两个团队都认为复杂性是一切事情的敌人。例如，安全人员和 Rugged DevOps 人员实际上可以说：“看，我们在我们的项目中使用了 11 个日志框架 - 也许我们不需要那么多，也许攻击面和复杂性可能会让我们受到伤害或者损害产品的质量或可用性。”

复杂性往往是许多事情的敌人。通常情况下，你不会很难说服 DevOps 团队在架构层面使用更好的建筑材料：使用最新的、最不易受攻击的版本，并使用较少的组件。

“更好的建筑材料”是什么意思？

JC： 我是世界上最大的开源仓库的保管人，所以我能看到他们在使用哪些版本，里面有哪些漏洞，何时他们没有修复漏洞，以及等了多久。例如，某些日志记录框架从不会修复任何错误。其中一些会在 90 天内修复了大部分的安全漏洞。人们越来越多地遭到攻击，因为他们使用了一个毫无安全的框架。

除此之外，即使你不知道日志框架的质量，拥有 11 个不同的框架会变得非常笨重、出现 bug，还有额外的工作和复杂性。你暴露在漏洞中的风险是非常大的。你想把时间花在修复大量的缺陷上，还是在制造下一个大的破坏性的事情上？

Rugged DevOps 的关键是软件供应链管理，其中包含三个原则：使用更少和更好的供应商、使用这些供应商的最高质量的部分、并跟踪这些部分，以便在发生错误时，你可以有一个及时和敏捷的响应。

所以变更管理也很重要。

JC： 是的，这是另一个共同的价值。我发现，当一家公司想要执行诸如异常检测或净流量分析等安全测试时，他们需要知道“正常”的样子。让人们失误的许多基本事情与仓库和补丁管理有关。

我在 Verizon 数据泄露调查报告中看到，追踪去年被成功利用的漏洞后，其中 97％ 归结为 10 个 CVE（常见漏洞和风险），而这 10 个已经被修复了十多年。所以，我们羞于谈论高级间谍活动。我们没有做基本的补丁工作。现在，我不是说如果你修复这 10 个CVE，那么你就没有被利用，而是这占据了人们实际失误的最大份额。

DevOps 自动化工具的好处是它们已经成为一个意外的变更管理数据库。其真实反应了谁在哪里什么时候做了变更。这是一个巨大的胜利，因为我们经常对安全性有最大影响的因素无法控制。你承受了 CIO 和 CTO 做出的选择的后果。随着 IT 通过自动化变得更加严格和可重复，你可以减少人为错误的机会，并且哪里发生了变化更加可追溯。

你认为什么是最重要的共同价值？

JC： DevOps 涉及到过程和工具链，但我认为定义这种属性的是文化，特别是同感。 DevOps 有用是因为开发人员和运维团队能够更好地了解彼此，并做出更明智的决策。不是在解决孤岛中的问题，而是为了活动流程和目标解决。如果你向 DevOps 的团队展示安全如何能使他们变得更好，那么作为回馈他们往往会问：“那么，我们是否有任何选择让你的生活更轻松？”因为他们通常不知道他们做的 X、Y 或 Z 的选择使它无法包含安全性。

对于安全团队，驱动价值的方法之一是在寻求帮助之前变得更有所帮助，在我们告诉 DevOps 团队要做什么之前提供定性和定量的价值。你必须获得 DevOps 团队的信任，并获得发挥的权利，然后才能得到回报。它通常比你想象的快很多。

via: https://techbeacon.com/why-devops-end-security-we-know-it

作者：Mike Barton 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出