更好的沟通和少量的会议并不是白日梦。这里告诉您异步决策是如何实现这一切的。

异步决策能够让地理和文化上分散的软件团队更有效率地做出决策。本文就将讨论一下实现异步决策所需要的一些原则和工具。

同步决策，要求参与者实时地进行互动，而这对那些需要 大块完整时间工作 Maker's Schedule 的人来说代价非常大，而且对于远程团队来说这也不现实。我们会发现这种会议最后浪费的时间让人难以置信。

相比之下，异步决策常应用于大型开源项目中（比如我常参与的 Apache 软件基金会 ASF）。它为团队提供了一种尽可能少开会的有效方法。很多开源项目每年只开很少的几次会议（有的甚至完全没开过会），然而开发团队却始终如一地在生产高质量的软件。

怎样才能异步决策呢？

所需工具

中心化的异步沟通渠道

异步决策的第一步就是构建一个中心化的异步沟通渠道。你所使用的技术必须能让所有的团队成员都获得同样的信息，并能进行 线索讨论 threaded discussions ，也就是说你要既能对一个主题进行发散也要能封禁其他主题的讨论。想一想航海专用无线电台，其中广播渠道的作用只是为了引起特定人员的注意，这些人然后再创建一个子渠道来进行详细的讨论。

很多开源项目依旧使用邮件列表作为中心渠道，不过很多新一代的软件开发者可能会觉得这个方法又古老又笨拙。邮件列表需要遵循大量的准则才能有效的管理热门项目，比如你需要进行有意义的引用，每个线索只讨论一个主题，保证 标题与内容相吻合。虽然这么麻烦，但使用得当的话，再加上一个经过索引的归档系统，邮件列表依然在创建中心渠道的工具中占据绝对主导的地位。

公司团队可以从一个更加现代化的协作工具中收益，这类工具更易使用并提供了更加强大的多媒体功能。不管你用的是哪个工具，关键在于要创建一个能让大量的人员有效沟通并异步地讨论各种主题的渠道。要创建一个一致而活跃的社区，使用一个 繁忙的渠道要好过建立多个渠道。

构建共识的机制

第二个工具是一套构建共识的机制，这样你才不会陷入死循环从而确保能做出决策。做决策最理想的情况就是一致同意，而次佳的就是达成共识，也就是 “有决策权的人之间广泛形成了一致的看法”。强求完全一致的赞同或者允许一票否决都会阻碍决策的制定，因此 ASF 中只在非常有限的决策类型中允许否决权。ASF 投票制度 为类似 ASF 这样没有大老板的松散组织构建了一个久经考验的，用于达成共识的好方法。当共识无法自然产生时也可以使用该套制度。

案例管理系统

如上所述，我们通常在项目的中心渠道中构建共识。但是在讨论一些复杂的话题时，使用案例管理系统这一第三方的工具很有意义。小组可以使用中心渠道专注于非正式的讨论和头脑风暴上，当讨论要转变成一个决策时将其转到一个更加结构化的案例管理系统中去。

案例管理系统能够更精确地组织决策。小型团队不用做太多决策可以不需要它，但很多团队会发现能有一个相对独立的地方讨论决策的细节并保存相关信息会方便很多。

案例管理系统不一定就是个很复杂的软件; 在 ASF 中我们所使用的只是简单的问题跟踪软件而已，这些基于网页的系统原本是创建来进行软件支持和 bug 管理的。每个案例列在一个单独的网页上，还有一些历史的注释和动作信息。该途径可以很好的追踪决策是怎么制定出来的。比如，某些非紧急的决策或者复杂的决策可能会花很长时间才会制定出来，这时有一个地方能够了解这些决策的历史就很有用了。新来的团队成员也能很快地了解到最近做出了哪些决策，哪些决策还在讨论，每个决策都有那些人参与其中，每个决策的背景是什么。

成功的案例

ASF 董事会中的九名董事在每个月的电话会议上只做很少的一些决策，耗时不超过 2 个小时。在准备这些会议之前，大多数的决策都预先通过异步的方式决定好了。这使得我们可以在会议上集中讨论复杂和难以确定的问题，而不是讨论那些已经达成普遍或部分共识的问题上。

软件世界外的一个有趣的案例是 瑞士联邦委员会的周会，它的运作方式跟 ASF 很类似。团队以异步决策构建共识的方式来准备会议。会议议程由一组不同颜色编码的列表组成，这些颜色标识了那些事项可以很快通过批准，那些事项需要进一步的讨论，哪些事项特别的复杂。这使得只要 7 个人就能每年忙完超过 2500 项决策，共 50 个周会，每个周会只需要几个小时时间。我觉得这个效率已经很高了。

就我的经验来看，异步决策带来的好处完全值得上为此投入的时间和工具。而且它也能让团队成员更快乐，这也是成功的关键因素之一。

via: https://opensource.com/article/17/12/asynchronous-decision-making

作者：Bertrand Delacretaz 译者：lujun9972 校对：wxy

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

容器支持者认为未来属于容器化操作系统，而其他人或许有不同看法。

自从 Linus Torvalds 在 1991 年发布 Linux 以来，Linux 已历经漫长的岁月。它已经成为企业级领域的主流操作系统。同时，我们看到桌面级领域出现了很多改进和调整，但在过去的 25 年来，主流 Linux 发行版的模式很大程度上没有变化。基于软件包管理的传统模式依然统治着桌面级和服务器级市场。

但随着 Google 发布了基于 Linux 的 Chrome OS，情况出现了微妙的转变，Chrome OS 采用镜像模式。Core OS (目前归属于 Red Hat) 受 Google 启发推出了一款操作系统 Container Linux，主要面向企业级用户。

Container Linux 改变了操作系统更新的方式，也改变了应用分发和更新的方式。这会是 Linux 发行版的未来吗？这是否会取代基于软件包的传统发行版模式呢？

三种模式

SLE (SUSE Linux Enterprise) 的产品管理总监 Matthias Eckermann 认为目前存在 3 种模式，而不是 2 种。Eckermann 提到：“除了传统模式（RHEL/SLE）和镜像模式（RedHat 的 Atomic Host），还存在第三种模型：事务模式。SUSE CaaS 平台 及 SUSE MicroOS 就采用这种模式。”

差异有哪些

Linux 用户对传统模式非常熟悉，它由独立的软件包和共享库组成。这种模式有独特的优势，让应用开发者无需将共享库捆绑在应用中。由于库不会多次引入，使得系统简洁和轻便。这也让用户无需下载很多软件包，节省了带宽。发行版对软件包全权负责，通过推送系统级别的更新，可以轻松地解决安全隐患。

RHEL （Red Hat Enterprise Linux）的产品管理总监 Ron Pacheco 表示，“传统的打包方式继续为我们提供精心构建和优化操作系统的机会，以便支持需要经过时间考验的任务关键型工作负载。”

但传统模式也有一些弊端。应用开发者受限使用发行版包含的库，使其无法从发行版不支持的新软件中获益。这也可能导致不同版本之间相互冲突。最终，传统模式给管理员增加了挑战，使其难以让软件包一直处于最新版本状态。

镜像模式

镜像模式应运而生。Eckermann 表示，“镜像模式解决了传统模式遇到的问题，它在每次迭代更新时替换整个操作系统，而不是单个的软件包”。

Pacheco 表示，“当我们用镜像作为操作系统的代名词进行讨论时，我们真正关心的是可编程式的开发和部署以及更好的集成式生命周期管理”，基于 RHEL 搭建的 OpenShift 被他用作示例。

Pacheco 认为基于镜像的操作系统是一种延续，从手工打造并部署镜像，到可大规模管理的高度自动化基础设施；无论客户使用哪种类型，都需要运行同样的应用。他说，“你肯定不希望使用一个完全不同的部署模式，这需要重做很多工作”。

镜像模式用新的库和软件包替代来整个操作系统，但也面临一系列问题。在镜像模式中，需要重建镜像才能适应特殊环境的需求。例如，用户有特殊需求，需要安装特定硬件的驱动或安装底层监控功能，镜像模式无法满足，需要重新设计功能以实现细粒度操作。

事务模式

第三种模式采用事务更新，基于传统的软件包更新，但将全部的软件包视为一个镜像，就像镜像那样在一次操作中更新全部软件包。

Eckermann 表示，“由于安装或回滚时操作对象是打包在一起的单一软件包，用户在需要时能够做相应的调整，这就是差别所在。结合传统模式和镜像模式的优点，避免两种模式的缺点，事务模式给用户提供了额外的灵活性。”

Pacheco 表示，将精心构造的工作负载部署成镜像的做法越来越成为主流，因为这种部署方式具有一致性和可靠性，而且可以弹性部署。“这正是我们用户目前的做法，部署环境包括在预置设备或公有/私有云上创建并部署的虚拟机，或在传统的裸机上。”

Pacheco 建议我们将这几种模式视为操作系统角色的进化和扩展，而不是仅仅“使用场景的比较和对比”。

原子化更新的问世

Google 的 Chrome OS 和 Core OS 为我们普及了事务更新的概念，该模型也被 Red Hat 和 SUSE 采用。

Eckermann 表示，“我们必须认识到，用于容器主机的操作系统已经不再是关注点 —— 至少不是管理员的关注点。RedHat Atomic 主机和 SUSE CaaS 平台都解决了该问题，实现方式在用户看来很相似。”

SUSE CaaS 平台、Red Hat Atomic Host和 Container Linux （前身是 Core OS）提供的 不可变基础设施 Immutable infrastructure 推广了事务更新的使用。Red Hat 高级技术产品经理 Ben Breard 表示，“在事务模式中，主机总是会变更到已确认正确的新状态，这让我们更有信心执行更新，进而实现更快速的功能流、安全优势以及易于采用的操作模式。”

这些新型操作系统使用 Linux 容器将应用与底层系统隔离，解除了传统模式中基础设施更新的诸多限制。

Breard 补充道，“当编排层可以智能处理更新、部署，甚至最终实现无缝操作时，我们才会真正意识到该模式的威力和好处”。

展望未来

Linux 的未来会是什么样子？不同的人会给出不同的回答。容器支持者认为未来属于容器化的操作系统，但依然拥有庞大市场的 Linux 供应商显然不这么认为。

当被问到原子化发行版是否会在很久以后将替换传统发行版时，Eckermann 表示，“如果我回答肯定的，那么表示我顺应潮流；如果回答是否定的，意味着我还是站在传统阵营。然而，我的回答是否定的，即 atomic 发行版在很久以后也不会替换传统发行版，传统负载和容器化负载将在数据中心、私有云以及公有云环境中共存。”

Pacheco 认为，从 Linux 的部署增长情况来看，一般情况下很难想象一种模式替换另一种模式。与其将多种模式视为相互竞争的关系，不如将原子化发行版视为操作系统进化和部署的一部分。

此外，在一些使用案例中，我们需要同时使用多种 Linux 发行版。Eckermann 表示，“想一想银行和保险公司中大量的 PL/1 和 Cobol 系统。再想一想内存数据库和核心数据总线系统。”

这些应用大多数无法进行容器化。就我们目前来看，容器化不是解决所有问题的万金油。总是会同时存在多种不同的技术。

Eckermann 相信，随着时间的推移，大量新的开发和部署将采用容器化，但仍然有不错的理由，促使我们在企业级环境中保留传统的部署方式和应用。

Pacheco 认为，“用户需要经历业务、设计和文化的转型，才能最大化基于容器的部署带来的优势。好消息是业界已经认识到并开始大规模转变，就像历史上大型机转变成 UNIX，UNIX 转变成 x86，x86 转变成虚拟化那样”。

结论

很明显，未来容器化负载的使用量会持续增长，也就意味着原子化发行版的需求量持续增长。与此同时，仍会有不少工作负载运行在传统发行版中。重要的是，这两类用户都在新模式上大规模投入，以便市场改变时可以做相应的策略改变。从外部观察者的视角来看，未来属于事务/原子化模式。我们已经见证了数据中心的发展，我们花了很长时间完成了从每个服务器一个应用到“函数即服务”模型的转变。Linux 发行版进入原子化时代的日子也不会太远了。

via: https://www.linux.com/blog/2018/4/containerization-atomic-distributions-and-future-linux

作者：SWAPNIL BHARTIYA 选题：lujun9972 译者：pinewall 校对：wxy

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

任何一种架构都是有利有弊的，而能满足你组织的独特需要的决策才是正确的选择。

对于许多初创公司来说，传统的知识认为，从单一整体架构开始，而不是使用微服务。但是，我们还有别的选择吗？

这本新书 —— 《初创公司的微服务》，从许多 CIO 们理解的微服务的角度，解释了微服务的优点与缺点。

对于初创公司，虽然不同的 CTO 对此给出的建议是不同的，但是他们都一致认为环境和性能很重要。如果你正考虑你的业务到底是采用微服务还是单一整体架构更好，下面讨论的这些因素正好可以为你提供一些参考。

理解范围

首先，我们先来准确定义我们所谓的 “整体服务” 和 “微服务” 是什么。

微服务是一种方法，它开发一个单一的应用程序来作为构成整体服务的小服务，每个小服务都运行在它自己的进程中，并且使用一个轻量级的机制进行通讯，通常是一个 HTTP 资源的 API。这些服务都围绕业务能力来构建，并且可依赖全自动部署机制来独立部署。

一个整体应用程序是按单个的、统一的单元来构建，并且，通常情况下它是基于一个大量的代码来实现的。一般来说，一个整体服务是由三部分组成的：数据库、客户端用户界面（由 HTML 页面和/或运行在浏览器中的 JavaScript 组成）、以及服务器端应用程序。

“系统架构处于一个范围之中”，Zachary Crockett，Particle 的 CTO，在一次访谈中，他说，“在讨论微服务时，人们倾向于关注这个范围的一端：许多极小的应用程序给其它应用程序传递了过多的信息。在另一端，有一个巨大的整体服务做了太多的事情。在任何现实中的系统上，在这两个极端之间有很多合适的面向服务的架构”。

根据你的情况不同，不论是使用整体服务还是微服务都有很多很好的理由。

“我们希望为每个服务使用最好的工具”，Julien Lemoine 说，他是 Algolia 的 CTO。

与很多人的想法正好相反，整体服务并不是过去遗留下来的过时的架构。在某些情况下，整体服务是非常理想的。我采访了 Steven Czerwinski 之后，更好地理解了这一点，他是 Scaylr 的工程主管，前谷歌员工。

“尽管我们在谷歌时有使用微服务的一些好的经验，我们现在 [在 Scalyr] 却使用的是整体服务的架构，因为一个整体服务架构意味着我们的工作量更少，我们只有两位工程师。“ 他解释说。（采访他时，Scaylr 正处于早期阶段）

但是，如果你的团队使用微服务的经验很丰富，并且你对你们的发展方向有明确的想法，微服务可能是一个很好的替代者。

Julien Lemoine，Algolia 的 CTO，在这个问题上，他认为：“我们通常从使用微服务开始，主要目的是我们可以使用不同的技术来构建我们的服务，因为如下的两个主要原因：

• 我们想为每个服务使用最好的工具。我们的搜索 API 是在底层做过高度优化的，而 C++ 是非常适合这项工作的。他说，在任何其它地方都使用 C++ 是一种生产力的浪费，尤其是在构建仪表板方面。
• 我们希望使用最好的人才，而只使用一种技术将极大地限制我们的选择。这就是为什么在公司中有不同语言的原因。

”

如果你的团队已经准备好从一开始就使用微服务，这样你的组织从一开始就可以适应微服务环境的开发节奏。

权衡利弊

在你决定那种方法更适合你的组织之前，考虑清楚每种方法的优缺点是非常重要的。

整体服务

优点：

• 很少担心横向联系： 大多数应用程序开发者都担心横向联系，比如，日志、速度限制、以及像审计跟踪和 DoS 防护这样的安全特性。当所有的东西都运行在同一个应用程序中时，通过组件钩子来处理这些关注点就非常容易了。
• 运营开销很少： 只需要为一个应用程序设置日志、监视、以及测试。一般情况下，部署也相对要简单。
• 性能： 一个整体的架构可能会有更好的性能，因为共享内存的访问速度要比进程间通讯（IPC）更快。

缺点：

• 紧耦合： 整体服务的应用程序倾向于紧耦合，并且应用程序是整体进化的，分离特定用途的服务是非常困难的，比如，独立扩展或者代码维护。
• 理解起来很困难： 当你想查看一个特定的服务或者控制器时，因为依赖、副作用、和其它的不可预见因素，整体架构理解起来更困难。

微服务

优点：

• 非常好组织： 微服务架构一般很好组织它们，因为每个微服务都有一个特定的工作，并且还不用考虑其它组件的工作。
• 解耦合： 解耦合的服务是能够非常容易地进行重组织和重配置，以服务于不同的应用程序（比如，同时向 Web 客户端和公共 API 提供服务）。它们在一个大的集成系统中，也允许快速、独立分发单个部分。
• 性能： 根据组织的情况，微服务可以提供更好的性能，因为你可以分离热点服务，并根据其余应用程序的情况来扩展它们。
• 更少的错误： 微服务允许系统中的不同部分，在维护良好边界的前提下进行并行开发。这样将使连接不该被连接的部分变得更困难，比如，需要连接的那些紧耦合部分。

缺点：

• 跨每个服务的横向联系点： 由于你构建了一个新的微服务架构，你可能会发现在设计时没有预料到的很多横向联系的问题。这也将导致需要每个横向联系点的独立模块（比如，测试）的开销增加，或者在其它服务层面因封装横向联系点，所导致的所有流量都需要路由。最终，即便是整体服务架构也倾向于通过横向联系点的外部服务层来路由流量，但是，如果使用整体架构，在项目更加成熟之前，也不过只是推迟了工作成本。
• 更高的运营开销： 微服务在它所属的虚拟机或容器上部署非常频繁，导致虚拟机争用激增。这些任务都是使用容器管理工具进行频繁的自动化部署的。

决策时刻

当你了解了每种方法的利弊之后，如何在你的初创公司使用这些信息？通过与这些 CTO 们的访谈，这里有三个问题可以指导你的决策过程：

你是在熟悉的领域吗？

如果你的团队有以前的一些领域的经验（比如，电子商务）和了解你的客户需求，那么分割成微服务是低风险的。如果你从未做过这些，从另一个角度说，整体服务或许是一个更安全的选择。

你的团队做好准备了吗？

你的团队有使用微服务的经验吗？如果明年，你的团队扩充到现在的四倍，将为微服务提供更好的环境？评估团队大小对项目的成功是非常重要的。

你的基础设施怎么样？

实施微服务，你需要基于云的基础设施。

David Strauss，Pantheon 的 CTO，他解释说："[以前]，你使用整体服务是因为，你希望部署在一个数据库上。每个单个的微服务都需要配置数据库服务器，然后，扩展它将是一个很重大的任务。只有大的、技术力量雄厚的组织才能做到。现在，使用像谷歌云和亚马逊 AWS 这样的云服务，为部署一个小的东西而不需要为它们中的每个都提供持久存储，对于这种需求你有很多的选择。“

评估业务风险

技术力量雄厚的初创公司为追求较高的目标，可以考虑使用微服务。但是微服务可能会带来业务风险。Strauss 解释说，“许多团队一开始就过度构建他们的项目。每个人都认为，他们的公司会成为下一个 ‘独角兽’，因此，他们使用微服务构建任何一个东西，或者一些其它的高扩展性的基础设施。但是这通常是一种错误的做法”。Strauss 说，在那种情况下，他们认为需要扩大规模的领域往往并不是一开始真正需要扩展的领域，最后的结果是浪费了时间和努力。

态势感知

最终，环境是关键。以下是一些来自 CTO 们的提示：

什么时候使用整体服务

• 你的团队还在创建阶段： 你的团队很小 —— 也就是说，有 2 到 5 位成员 —— 还无法应对大范围、高成本的微服务架构。
• 你正在构建的是一个未经证实的产品或者概念验证： 如果你将一个全新的产品推向市场，随着时间的推移，它有可能会成功，而对于一个快速迭代的产品，整体架构是最合适的。这个提示也同样适用于概念验证，你的目标是尽可能快地学习，即便最终你可能会放弃它。
• 你没有使用微服务的经验： 除非你有合理的理由证明早期学习阶段的风险可控，否则，一个整体的架构更适用于一个没有经验的团队。

什么时候开始使用微服务

• 你需要快速、独立的分发服务： 微服务允许在一个大的集成系统中快速、独立分发单个部分。请注意，根据你的团队规模，获取与整体服务的比较优势，可能需要一些时间。
• 你的平台中的某些部分需要更高效： 如果你的业务要求集中处理 PB 级别的日志卷，你可能需要使用一个像 C++ 这样的更高效的语言来构建这个服务，尽管你的用户仪表板或许还是用 Ruby on Rails 构建的。
• 计划扩展你的团队： 使用微服务，将让你的团队从一开始就开发独立的小服务，而服务边界独立的团队更易于按需扩展。

要决定整体服务还是微服务更适合你的组织，要坦诚并正确认识自己的环境和能力。这将有助于你找到业务成长的最佳路径。

关于作者

jakelumetta - Jake 是 ButterCMS 的 CEO，它是一个 API-first CMS。他喜欢搅动出黄油双峰，以及构建让开发者工作更舒适的工具，喜欢他的更多内容，请在 Twitter 上关注 @ButterCMS，订阅 他的博客。关于他的更多信息……

via: https://opensource.com/article/18/1/how-choose-between-monolith-microservices

作者：jakelumetta 译者：qhwdw 校对：wxy

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

专家们权衡了 DevOps 团队最近会有何期望。

“DevOps” 一词通常认为是来源于 这篇 2008 年关于敏捷基础设施和运营的讲演中。现在的 IT 词汇中，它无处不在，这个“混搭”的词汇出现还不到 10 年：我们还在研究它在 IT 中更现代化的工作方法。

诚然，多年来一直在 “从事 DevOps” 的人积累了丰富的知识。但是大多数的 DevOps 环境 —— 人与 文化 、流程与方法、工具与技术的融合 —— 还远远没有成熟。

更多的变化即将到来。Robert Reeves 说 “DevOps 是一个过程，一种算法”，他是 Datical 的 CTO， “它的绝对目标就是随着时间进行改变和演进”，这就是重点。

那我们预计接下来会发生什么呢？这里有一些专家们观察到的重要趋势。

1、 预计 DevOps、容器、以及微服务之间的相互依赖会增强

驱动 DevOps 发展的文化本身可能会演进。当然，DevOps 仍然将在根本上摧毁传统的 IT 孤岛和瓶颈，但这样做的理由可能会变得更加急迫。证据 A & B： 对容器和微服务的兴趣 与日俱增。这个技术组合很强大、可连续扩展、与规划和 持续进行的管理配合最佳。

Arvind Soni 说 “影响 DevOps 的其中一个主要因素是向微服务转变”，他是 Netsil 的产品副总裁，补充道，容器和业务流程，使开发者打包和交付的速度越来越快。DevOps 团队的任务可能是帮助去加速打包并管理越来越复杂的微服务弹性架构。

2、 预计 ”安全网“ 更少

DevOps 使团队可以更快更敏捷地去构建软件，部署速度也更快更频繁、同时还能提升软件质量和稳定性。但是好的 IT 领导通常都不会忽视管理风险，因此，早期大量的 DevOps 迭代都是使用了安全防护 —— 从后备的不重要业务开始的。为了实现更快的速度和敏捷性，越来越多的团队将抛弃他们的 ”辅助轮“（LCTT 译注：意思说减少了安全防护措施）。

Nic Grange 说 “随着团队的成熟，他们决定不再需要一些早期增加的安全 ‘防护栏’ 了”，他是 Retriever Communications 的 CTO。Grange 给出了一个阶段展示的服务器的示例：随着 DevOps 团队的成熟，他们决定不再需要阶段展示的服务器了，尤其是他们很少在试生产环境中发现问题。（Grange 指出，这一举措对于缺乏 DevOps 经验的团队来说，不可轻易效仿）

Grange 说 “这个团队可能在监视和发现并解决生产系统中出现的问题的能力上有足够的信心”，“部署过程和测试阶段，如果没有任何证据证明它的价值，那么它可能会把整个进度拖慢”。

3、 预计 DevOps 将在其它领域大面积展开

DevOps 将两个传统的 IT 部门（开发和运营）结合的更紧密。越来越多的公司看到了这种结合的好处，这种文化可能会传播开来。这种情况在一些组织中已经出现，在 “DevSecOps” 一词越来越多出现的情况下，它反映出了在软件开发周期中有意地、越来越早地包含了安全性。

Derek Weeks 说 “DevSecOps 不仅是一个工具，它是将安全思维更早地集成到开发实践中”，它是 Sonatype 的副总裁和 DevOps 拥挤者。

Red Hat 的安全策略师 Kirsten Newcomer 说，这种做法并不是一个技术挑战，而是一个文化挑战。

Newcomer 说 “从历史来看，安全团队都是从开发团队中分离出来的 —— 每个团队在它们不同的 IT 领域中形成了各自的专长” ，“它并不需要这种方法。每个关心安全性的企业也关心他们通过软件快速交付业务价值的能力，这些企业正在寻找方法，将安全放进应用程序的开发周期中。它们采用 DevSecOps 通过 CI/CD 流水线去集成安全实践、工具和自动化。为了做的更好，他们整合他们的团队 —— 将安全专家整合到应用程序开发团队中，参与到从设计到产品部署的全过程中。这种做法使双方都看到了价值 —— 每个团队都扩充了它们的技能和知识，使他们成为更有价值的技术专家。DevOps 做对了 —— 或者说是 DevSecOps —— 提升了 IT 安全性。”

除了安全以外，还可以让 DevOps 扩展到其它领域，比如数据库团队、QA，甚至是 IT 以外的潜在领域。

Datical 的 Reeves 说 “这是一件非常 DevOps 化的事情：发现相互掣肘的地方并解决它们”，“对于以前采用 DevOps 的企业来说，安全和数据库是他们面临的最大瓶颈。”

4、 预计 ROI 将会增加

Eric Schabell 说，“由于公司深入推进他们的 DevOps 工作，IT 团队在方法、流程、容器和微服务方面的投资将得到更多的回报。” 他是 Red Hat 的全球技术传播总监，Schabell 说 “‘圣杯’将移动的更快、完成的更多、并且变得更灵活。由于这些组件找到了更宽阔的天地，组织在应用程序中更有归属感时，结果就会出现。”

“每当新兴技术获得我们的关注时，任何事都有一个令人兴奋的学习曲线，但当认识到它应用很困难的时候，同时也会经历一个从兴奋到幻灭的低谷。最终，我们将开始看到从低谷中爬出来，并收获到应用 DevOps、容器、和微服务的好处。”

5、 预计成功的指标将持续演进

Mike Kail 说 “我相信 DevOps 文化的两个核心原则 —— 自动化和可衡量是从来不会变的”，它是 CYBRIC 的 CTO，也是 Yahoo 前 CIO。“总是有办法去自动化一个任务，或者提升一个已经自动化的解决方案，而随着时间的推移，重要的事情是测量可能的变化和扩展。这个成熟的过程是一个永不停步的旅行，而不是一个目的地或者已完成的任务。”

在 DevOps 的精神中，成熟和学习也与协作者和分享精神有关。Kail 认为，对于敏捷方法和 DevOps 文化来说，它仍然为时尚早，这意味着它们还有足够的增长空间。

Kail 说 “随着越来越多的成熟组织持续去测量可控指标，我相信（希望） —— 这些经验应该被广泛的分享，以便我们去学习并改善它们。”

作为 Red Hat 技术传播专家，Gordon Haff 最近注意到，组织使用业务成果相关的因素去改善他们的 DevOps 指标的工作越来越困难。 Haff 写道 “你或许并不真正关心你的开发者写了多少行代码、服务器是否在一夜之间出现了硬件故障、或者你的测试覆盖面是否全面”。事实上，你可能并不直接关心你的网站的响应速度和更新快慢。但是你要注意的是，这些指标可能与消费者放弃购物车或者转到你的竞争对手那里有关。”

与业务成果相关的一些 DevOps 指标的例子包括，消费者交易金额（作为消费者花销统计的指标）和净推荐值（消费者推荐公司产品和服务的意愿）。关于这个主题更多的内容，请查看这篇完整的文章—— DevOps 指标：你是否测量了重要的东西。

唯一不变的就是改变

顺利说一句，如果你希望这件事一蹴而就，那你就要倒霉了。

Reeves 说 “如果你认为今天发布非常快，那你就什么也没有看到”，“这就是为什么要让相关者包括数据库团队进入到 DevOps 中的重要原因。因为今天这两组人员的冲突会随着发布速度的提升而呈指数级增长。”

via: https://enterprisersproject.com/article/2017/10/what-s-next-devops-5-trends-watch

作者：Kevin Casey 译者：qhwdw 校对：wxy

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

最近，有发现称一些 Ubuntu Snap 应用商店上的应用包含加密货币挖矿程序。Canonical 公司迅速下架了这些违规的应用，但是留下了几个有待回答的问题。

在 Snap 应用商店上发现了加密矿工

5 月 11 号，一位名叫 tarwirdur 的用户在 snapcraft.io repository 开了一个新的工单 ，他提到一个由 Nicolas Tomb 开发，叫做 2048buntu 的 snap 应用包含加密货币矿工。tarwirdur 询问，他怎样才能出于安全的原因而“投诉该应用” 。tarwirdur 后来发表说其它由 Nicolas Tomb 开发的 snap 应用也都包含加密货币矿工。

看起来该 snap 应用使用了 systemd 在系统启动时自动地运行代码，并在用户不知情的情况下在后台运行。

对那些不熟悉相关术语的人来说， 加密货币 cryptocurrency 矿工 miner 是一段使用计算机的主处理器或者图形处理器来“挖掘”数字货币的程序。“挖矿”通常涉及到解决一个数学等式。在这种情况下，如果你在运行 2048buntu 游戏，这个游戏将会额外使用处理器的计算能力去进行加密货币的挖掘。

Snapcraft 团队迅速地下架了所有由该违规者开发的应用来做出回应。他们同时也开展了调查。

隐匿者发声

5 月 13 号，一位同名为 Nicolas Tomb 的 Disqus 用户在 OMGUbuntu 的新闻报道上发表了评论，他在评论中称自己向 snap 应用中添加了加密货币矿工，从而获取收益。他为他的行为道歉，同时承诺将所有挖矿所得的收益送给 Ubuntu 基金会。

我们不能确认这个评论就是由 Nicolas Tomb 发表的，因为这个 Disqus 账户最近才被创建，也只有一条评论与之相关联。现在，我们假设他是。

Canonical 公司发表了声明

5 月 15 号，Canonical 公司在这种情况下发表了一份声明。标题为 “在 Snap 应用商店中的信任与安全”，声明开头重申了当下的情况。他们也补充道重新发布的 snap 应用中已经被删除了加密货币挖矿程序。

Canonical 公司随后尝试调查 Nicolas Tomb 的动机。他们指出，他告诉他们说自己这样做是为了通过应用赚钱（如上所诉），而当面对质疑时就停止了。他们也指出“挖掘加密货币本身并非不合法和不道德的”。然而，他们仍对他没有在 snap 应用描述中披露加密矿工这件事表示了不满意。

随后 Canonical 公司将话题转移到审核软件上。根据这份申明，Snap 应用商店将会采用一种类似 iOS、Android、Windows 的质量控制系统，这个系统将有“自动化的检查点，安装包必须在被接受前通过检查，同时在特殊问题被标记时会进行人工审核”。

然后，Canonical 公司声称“对大规模的软件仓库来说，只接受每个单独文件都被仔细审核过的软件是不可能的”。因此，他们需要信任软件源而不是内容。毕竟，软件源是现在 Ubuntu 软件仓库系统的基础。

Canonical 公司紧接着谈到了 Snap 应用的未来。他们承认现在的系统是不完美的。他们也在不断地进行改善。他们“在开发非常有趣的安全功能，这些功能将会在改善系统安全性同时提升人们在服务器或桌面上进行软件开发的体验”。

其中一个他们正在开发的功能是查看一个软件发布者是否已通过验证。其他的改进包括：“将所有 AppArmor 内核补丁递交到上游”和其它底层修复。

一些关于“Snap 应用商店中的恶意软件”的想法

基于我所了解的所有内容，我产生了一些想法和问题。

这种挖矿软件运行多久了？

首先，这些挖矿软件存在于 Snap 应用商店多久了？因为它们已经被下架了，我们没有这样的数据。我可以通过 Google 快照抓取一些 2048buntu 页面的图片，但这没有提供任何可用的信息。根据该软件运行时间，多少系统安装过，挖掘出了什么加密货币，我们能否知道违规者获取的是一点钱还是一笔钱。一个更长远的问题是：Canonical 公司将来有能力捕捉到这样的违规情况吗？

这真的是一个恶意软件吗？

许多新闻网站将之报道为恶意软件感染。我想我甚至可以看到这个事件被称为 Linux 的第一个恶意软件。我不确定这个术语是否精确。Dictionary.com 这样定义 恶意软件：“意图损害计算机、移动设备、计算机系统或者计算机网络，或者对其运作进行部分控制的软件”。

这个有问题的 snap 应用并没有损害或者控制涉及到的计算机。它同样没有感染其他计算机。它也不能这样做，因为所有的 snap 应用位于沙盒之中。它们最多利用了处理器的计算能力，就是这样。所以，我不会称之为恶意软件。

无孔不入

Nicolas Tomb 使用的一个辩解是在他上传应用的时候 Snap 应用商店没有任何反对加密货币挖矿的规则。（我敢向你打赌他们正在纠正这个错误。）他们之所以没有这样的规则，原因很简单，之前没有人做过这种事。如果 Tomb 想正确地做事，他应该提前询问是否允许这种行为。而事实是他似乎没有指出他知道 Canonical 公司可能会拒绝的事实。至少，Canonical 公司会告诉他将这些写在软件的描述中。

一看就不对劲

如我之前说的，我从 Google 快照获取了一个 2048buntu 的页面截图。仅仅看它就会感觉到一些危险的信号。首先，截图中几乎没有真实的描述。它是这样描述的“类似 2048 的游戏。这个游戏用 ubuntu 主题克隆了流行的游戏 2048。”哇，这将会引来容易上当受骗的人。当我读到类似空洞的描述时，我会多考虑下。

我注意到的另一件事是软件的大小。2048buntu 的 1.0 版本大小将近 140 MB。一个简单的游戏怎么需要这么多的空间？有用 Javascript 写的浏览器版本大概只用了不到它的四分之一。其他 snap 应用商店的 2048 游戏的大小没有一个达到了这个软件的一半。

然后，它有个许可证。这是一个使用了 Ubuntu 主题的流行游戏的克隆。它怎么能被认为是专有软件？我确信，其他合法的开发者会因为该内容而使用了 FOSS （自由开源软件）许可证来上传它。

单是这些因素就使得这个 snap 应用很特殊，应该进行审核。

谁是 Nicolas Tomb？

当第一次了解到这些之后，我决定看看我能否找出造成这些混乱的人。当我搜索 Nicolas Tomb 的时候，我什么都没找到。所有我找到的只是一大堆关于加密货币挖矿 snap 应用的新闻和文章，以及去 tomb of St. Nicolas 旅游的信息。在 Twiter 和 Github 上都没有 Nicolas Tomb 的标志。看起来似乎是为了上传这些 snap 应用才创建的名称。

这同样引出了 Canonical 公司发表的申明中的一点，关于验证发布者。上一次我查看的时候，相当多的 snap 应用不是由应用的维护者发布的。这让我感到担忧。我更乐意相信由 Mozilla 基金会发布的 firefox 的 snap 应用，而不是 Leonard Borsch。如果对应用维护者来说关注应用的 snap 版本太耗费精力，应该有办法让维护者在他们软件的 snap 版本上贴上批准的标签。就像是 Firefox 的 snap 版本由 Fredrick 发布，经 Mozilla 基金会批准。这样才能让用户对下载的内容更放心。

无疑 Snap 应用商店还有改善的空间

在我看来，Snap 应用商店团队应该实现的第一个特性是报告可疑应用的方式。tarwirdur 必须找到该网站的 Github 页面才行。而大多数用户不会想到这一点。如果 Snap 应用商店不能审核每一行代码，那么使用户能够报告问题是退而求其次的办法。即使评分系统也是一个不差的补充。我确信一定有部分人因为 2048buntu 使用了太多系统资源而给它很低的评分。

结论

从我所知道的情况来说，我认为这是某个人创建了一些简单的应用，在每个应用中嵌入了加密货币矿工，之后将这些应用上传到 Snap 应用商店，想着捞一笔钱。一旦他们被抓了，他们就声称这仅仅为了通过应用程序获利。如果真的是这样，他们应该在 snap 应用的描述中提到才对。隐藏加密矿工并不是什么新鲜事。他们通常是一种盗取计算能力的方法。

我希望 Canonical 公司已经具备了解决这个问题的功能，盼望这些功能能很快出来。

你对 Snap 应用商店的“恶意软件风波”有什么看法？你将如何改善这种情况？请在下面的评论中告诉我们。

如果你觉得这篇文章有趣，请花费一点时间将它分享到社交媒体上。

via: https://itsfoss.com/snapstore-cryptocurrency-saga/

作者：John Paul 选题：lujun9972 译者：paperzhang 校对：wxy

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

提要：对于面临滥用专利制度的实体发起诉讼威胁的技术公司和创新者来说，此案是一个重大胜利。

对于面临滥用专利制度的实体发起诉讼威胁的技术公司和创新者来说，日前美国最高法院对 Oil States 诉 Greene’s Energy 案做出的裁决是一个重大胜利。此类滥用专利制度的实体试图从创新者和创造就业机会的企业身上攫取价值。

在 Oil States 案中，美国最高法院对美国专利商标局（USPTO）一项旨在质疑此前授权但存在问题的专利是否有效的行政程序是否违宪做出了裁决。 专利流氓 （ patent trolls ） 最喜欢利用此类专利发起诉讼。这一称为 “双方复审” （ inter partes review ） 的程序已经成为一种应对基于可能无效专利而轻率发起的侵权主张的重要工具，其成本远低于在联邦法院检验此类专利有效性的成本。

美国国会根据 《2011年美国发明法案》 （ America Invents Act of 2011 ） 创建了这种双方复审程序，以清理美国国会所认为的大量被不当授权的专利。此类专利被专利流氓用于向创新者谋取费用。自 2012 年实施该程序以来，已经有 7000 多份申请被提交，主要是为了审查计算机和高科技领域的可疑专利，并且有超过 1300 项权利主张被裁定无效。

在 7 比 2 的多数意见中，托马斯法官表示：“授予专利的决定是涉及公共权利的事项。双方复审只是对该授权过程的再审，美国国会已经授权美国专利商标局实施此种再审。”法官认为双方复审程序并没有侵犯专利权人所拥有的案件需由联邦法院裁决（在联邦法院无效专利的成本更高，诉讼费用明显更为昂贵）的宪法权利。

与开发、销售或实施复杂技术的任何实体一样，开发或实施开源软件的成功企业是专利流氓诉讼威胁的颇有吸引力的目标。因此，确认双方复审程序的合宪性不仅提高了专利系统的质量，而且也保留了一种工具来保护开源技术免受那些滥用专利系统的实体的攻击。

美国专利商标局打算评估双方复审程序的实施情况，这可能会影响其作为防御工具的有效性。但科技行业人士应继续让政策制定者保留《2011 年美国发明法案》所带来的有益变革，以保护创新并阻止滥用专利的行为。

作者简介：Matt Krupnick 是 红帽公司 （ Red Hat ） 公共政策总监，于 2017 年加入红帽公司，负责政策制定以及为一系列对红帽公司及开源技术有潜在影响的各种政策问题提供建议。

译者简介：薛亮，集慧智佳知识产权咨询公司高级咨询师，擅长专利检索、专利分析、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。