人和流程比在解决的业务问题的任何技术“银弹”更重要，且需要花更多的时间。

今天的许多 IT 专业人士都在努力适应变化和扰动。这么说吧，你是否正在努力适应变化？你觉得不堪重负吗？这并不罕见。今天，IT 的现状还不够好，所以需要不断尝试重新自我演进。

凭借 30 多年的IT综合经验，我们见证了人员与关系对于 IT 企业提高效率和帮助企业蓬勃发展的重要性。但是，在大多数情况下，我们关于 IT 解决方案的对话始于技术，而不是从人员和流程开始。寻找“银弹”来解决业务和 IT 挑战的倾向过于普遍。但你不能想着可以买到创新、DevOps 或有效的团队和工作方式；他们需要得到培养，支持和引导。

由于扰动如此普遍，并且对变革速度存在如此迫切的需求，我们需要纪律和围栏。下面描述的 DevOps 思维模式的五个基本价值观将支持将我们的实践。这些价值观不是新观念；正如我们从经验中学到的那样，它们被重构了。一些价值观可以互换的，它们是灵活的，并且它们如支柱一样导向了支持这五个价值观的整体原则。

1、利益相关方的反馈至关重要

我们如何知道我们是否为我们创造了比利益相关方更多的价值？我们需要持久的质量数据来分析、通知并推动更好的决策。来自可靠来源的相关信息对于任何业务的蓬勃发展至关重要。我们需要倾听并理解我们的利益相关方所说的，而不是说我们需要以一种方式实施变革，使我们能够调整我们的思维、流程和技术，并根据需要对其进行调整以使我们的利益相关者满意。由于信息（数据）不正确，我们常常看到的变化过少，或者由于错误的原因而发生了很多变化。因此，将变更与利益相关方的反馈结合起来是一项基本价值观，并有助我们专注于使公司成功最重要的事情。

关注我们的利益相关方及其反馈，而不仅仅是为了改变而改变。

2、超越当今流程的极限进行改进

我们希望我们的产品和服务能够不断让客户满意，他们是我们最重要的利益相关方。因此，我们需要不断改进。这不仅仅是关系到质量；它还可能意味着成本、可用性、相关性以及许多其他目标和因素。创建可重复的流程或使用通用框架是非常棒的，它们可以改善治理和许多其他问题。但是，这不应该是我们的最终目标。在寻找改进方法时，我们必须调整我们的流程，并辅以正确的技术和工具。可能有理由抛出一个“所谓的”框架，因为不这样做可能会增加浪费，更糟糕的是只是“货物结果”（做一些没有价值或目的的东西）。

力争始终创新并改进可重复的流程和框架。

3、不要用新的孤岛来打破旧的孤岛

孤岛和 DevOps 是不兼容的。我们经常能看到：IT 主管带来了所谓的“专家”来实施敏捷和 DevOps，他们做了什么？这些“专家”在现有问题的基础上创建了一个新问题，这是 IT 部门和业务中又增加了一个孤岛。创造“DevOps”职位违背了敏捷和 DevOps 基于打破孤岛的原则。在敏捷和 DevOps 中，团队合作是必不可少的，如果你不在自组织团队中工作，那么你就不会做任何事情。

相互激励和共享，而不是成为英雄或创建一个孤岛。

4、了解你的客户意味着跨组织协作

企业的任何一个部分都不是一个独立的实体，因为它们都有利益相关方，主要利益相关方始终是客户。“客户永远是对的”（或国王，我喜欢这样说）。关键是，没有客户就真的没有业务，而且为了保持业务，如今我们需要与竞争对手“区别对待”。我们还需要了解客户对我们的看法以及他们对我们的期望。了解客户的需求势在必行，需要及时反馈，以确保业务能够快速、负责地满足这些主要利益相关者的需求和关注。

无论是想法、概念、假设还是直接利益相关方的反馈，我们都需要通过使用探索、构建、测试和交付生命周期来识别和衡量我们的产品提供的功能或服务。从根本上说，这意味着我们需要在整个组织中“插入”我们的组织。在持续创新、学习和 DevOps 方面没有任何边界。因此，当我们在整个企业中进行衡量时，我们可以理解整体并采取可行的、有意义的步骤来改进。

衡量整个组织的绩效，而不仅仅是在业务范围内。

5、通过热情鼓励采纳

不是每个人都要被驱使去学习、适应和改变；然而，就像微笑可能具有传染性一样，学习和意愿成为变革文化的一部分也是如此。在学习文化中适应和演化为一群人提供了学习和传递信息（即文化传播）的自然机制。学习风格、态度、方法和过程不断演化，因此我们可以改进它们。下一步是应用所学和改进的内容并与同事分享信息。学习不会自动发生；它需要努力、评估、纪律、意识，特别是沟通；遗憾的是，这些都是工具和自动化无法提供的。检查你的流程、自动化、工具策略和实施工作，使其透明化，并与你的同事协作重复使用和改进。

通过精益交付促进学习文化，而不仅仅是工具和自动化。

总结

随着我们的公司采用 DevOps，我们继续在各种书籍、网站或自动化软件上倡导这五个价值观。采用这种思维方式需要时间，这与我们以前作为系统管理员所做的完全不同。这是一种全新的工作方式，需要很多年才能成熟。这些原则是否与你自己的原则一致？在评论或我们的网站 Agents of chaos 上分享。

via: https://opensource.com/article/19/5/values-devops-mindset

作者：Brent Aaron Reed 选题：lujun9972 译者：arrowfeng 校对：wxy

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

“区块链 2.0” 系列文章讨论了自 2008 年比特币等加密货币问世以来区块链技术的发展。本文将探讨区块链的未来发展。区块链 3.0 这一新的 DLT（ 分布式分类帐本技术 Distributed Ledger Technology ）演进浪潮将回答当前区块链所面临的问题（每一个问题都会在这里总结）。下一版本的技术标准也将带来全新的应用和使用案例。在本文的最后，我们也会看一些当前使用这些原则的案例。

以下是现有区块链平台的几个缺点，并针对这些缺点给出了建议的解决方案。

问题 1：可扩展性

这个问题 ¹ 被视为普遍采用该技术的第一个主要障碍。正如之前所讨论的，很多因素限制了区块链同时处理大量交易的能力。诸如 以太坊 之类的现有网络每秒能够进行 10-15 次交易（TPS），而像 Visa 所使用的主流网络每秒能够进行超过 2000 次交易。可扩展性是困扰所有现代数据库系统的问题。正如我们在这里看到的那样，改进的共识算法和更好的区块链架构设计正在改进它。

解决可扩展性

已经提出了更精简、更有效的一致性算法来解决可扩展性问题，并且不会影响区块链的主要结构。虽然大多数加密货币和区块链平台使用资源密集型的 PoW 算法（例如，比特币和以太坊）来生成区块，但是存在更新的 DPoS 和 PoET 算法来解决这个问题。DPoS 和 PoET 算法（还有一些正在开发中）需要更少的资源来维持区块链，并且已显示具有高达 1000 TPS 的吞吐量，可与流行的非区块链系统相媲美。

可扩展性问题的第二个解决方案是完全改变区块链结构和功能。我们不会详细介绍这一点，但已经提出了诸如 有向无环图 Directed Acyclic Graph （DAG）之类的替代架构来处理这个问题。从本质上讲，这项工作假设并非所有网络节点都需要整个区块链的副本才能使区块链正常工作，或者并非所有的参与者需要从 DLT 系统获得好处。系统不要求所有参与者验证交易，只需要交易发生在共同的参考框架中并相互链接。

在比特币系统中使用 闪电网络 Lightning network 来实现 DAG，而以太坊使用他们的 切片 Sharding 协议来实现 DAG。本质上，从技术上来看 DAG 实现并不是区块链。它更像是一个错综复杂的迷宫，只是仍然保留了区块链的点对点和分布式数据库属性。稍后我们将在另一篇文章中探讨 DAG 和 Tangle 网络。

问题 2：互通性

互通性 ^{2 3} 被称为跨链访问，基本上就是指不同区块链之间彼此相互通信以交换指标和信息。由于目前有数不清的众多平台，不同公司为各种应用提供了各种专有系统，平台之间的互操作性就至关重要。例如，目前在一个平台上拥有数字身份的人无法利用其他平台提供的功能，因为各个区块链彼此之间互不了解、不能沟通。这是由于缺乏可靠的验证、令牌交换等有关的问题仍然存在。如果平台之间不能够相互通信，面向全球推出智能合约也是不可行的。

解决互通性

有一些协议和平台专为实现互操作性而设计。这些平台实现了原子交换协议，并向不同的区块链系统提供开放场景，以便在它们之间进行通信和交换信息。“0x (ZRX)” 就是其中的一个例子，稍后将对进行描述。

问题 3：治理

公有链中的治理 ⁴ 本身不是限制，而是需要像社区道德指南针一样，在区块链的运作中考虑每个人的意见。结合起来并规模性地看，能预见这样一个问题，即要么协议更改太频繁，要么协议被拥有最多令牌的“中央”权威一时冲动下修改。不过这不是大多数公共区块链目前正在努力避免的问题，因为其运营规模和运营性质不需要更严格的监管。

解决治理问题

上面提到的复杂的框架或 DAG 几乎可以消除对全球（平台范围）治理法规的需要和使用。相反，程序可以自动监督事务和用户类型，并决定需要执行的法律。

问题 4：可持续性

可持续性再次建立在可扩展性问题的基础上。当前的区块链和加密货币因不可长期持续而倍遭批评，这是由于仍然需要大量的监督，并且需要大量资源保持系统运行。如果你读过最近“挖掘加密货币”已经没有这么大利润的相关报道，你就知道“挖矿”图利就是它的本来面目。保持现有平台运行所需的资源量在全球范围和主流使用方面根本不实用。

解决不可持续性问题

从资源或经济角度来看，可持续性的答案与可扩展性的答案类似。但是，要在全球范围内实施这一制度，法律和法规必须予以认可。然而，这取决于世界各国政府。来自美国和欧洲政府的有利举措重新燃起了对这方面的希望。

问题 5：用户采用

目前，阻止消费者广泛采用 ⁵ 基于区块链的应用程序的一个障碍是消费者对平台及其底层的技术不熟悉。事实上，大多数应用程序都需要某种技术和计算背景来弄清楚它们是如何工作的，这在这方面也没有帮助。区块链开发的第三次浪潮旨在缩小消费者知识与平台可用性之间的差距。

解决用户采用问题

互联网花了很长的时间才发展成现在的样子。多年来，人们在开发标准化互联网技术栈方面做了大量的工作，使 Web 能够像现在这样运作。开发人员正在开发面向用户的前端分布式应用程序，这些应用程序应作为现有 Web 3.0 技术之上的一层，同时由下面的区块链和开放协议的支持。这样的分布式应用将使用户更熟悉底层技术，从而增加主流采用。

在当前场景中的应用

我们已经从理论上讨论了上述问题的解决方法，现在我们将继续展示这些方法在当前场景中的应用。

• 0x – 是一种去中心化的令牌交换，不同平台的用户可以在不需要中央权威机构审查的情况下交换令牌。他们的突破在于，他们如何设计系统使得仅在交易结算后才记录和审查数据块，而不是通常的在交易之间进行（为了验证上下文，通常也会验证交易之前的数据块）。这使在线数字资产交换更快速。
• Cardano – 由以太坊的联合创始人之一创建，Cardano 自诩为一个真正“科学”的平台，和采用了严格的协议，对开发的代码和算法进行了多次审查。Cardano 的所有内容都在数学上尽可能的进行了优化。他们的共识算法叫做 Ouroboros，是一种改进的 权益证明 Proof of Stake （PoS）算法。Cardano 是用 haskell 开发的，智能合约引擎使用 haskell 的衍生工具 plutus 进行操作。这两者都是函数式编程语言，可以保证安全交易而不会影响效率。
• EOS – 我们已经在 这篇文章 中描述了 EOS。
• COTI – 一个鲜为人知的架构，COTI 不需要挖矿，而且在运行过程中趋近于零功耗。它还将资产存储在本地用户设备上的离线钱包中，而不是存储在纯粹的对等网络上。它们也遵循基于 DAG 的架构，并声称处理吞吐量高达 10000 TPS。他们的平台允许企业在不利用区块链的情况下建立自己的加密货币和数字化货币钱包。

1. A. P. Paper, K. Croman, C. Decker, I. Eyal, A. E. Gencer, and A. Juels, “On Scaling Decentralized Blockchains | SpringerLink,” 2018. ↩
2. Why is blockchain interoperability important ↩
3. The Importance of Blockchain Interoperability ↩
4. R. Beck, C. Müller-Bloch, and J. L. King, “Governance in the Blockchain Economy: A Framework and Research Agenda,” J. Assoc. Inf. Syst., pp. 1020–1034, 2018. ↩
5. J. M. Woodside, F. K. A. Jr, W. Giberson, F. K. J. Augustine, and W. Giberson, “Blockchain Technology Adoption Status and Strategies,” J. Int. Technol. Inf. Manag., vol. 26, no. 2, pp. 65–93, 2017. ↩

via: https://www.ostechnix.com/welcoming-blockchain-3-0/

作者：sk 选题：lujun9972 译者：murphyzhao 校对：wxy

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

6 月 15 日，你可以在当地的游戏商家庆祝桌面角色扮演游戏并获得免费的 RPG 资料。

（LCTT 译注：“ 免费 RPG 日 Free RPG Day ”是受“ 免费漫画书日 Free Comic Book Day ”启发而发起的庆祝活动，从 2007 年开始已经举办多次。这里的 RPG 游戏并非我们通常所指的电脑 RPG 游戏，而是指使用纸和笔的桌面游戏，是一种西方传统游戏形式。）

你有没有想过尝试一下《 龙与地下城 Dungeons & Dragons 》，但不知道如何开始？你是否在年轻时玩过《 开拓者 Pathfinder 》并一直在考虑重返快乐时光？你是否对角色扮演游戏（RPG）感到好奇，但不确定你是否想玩一个？你是否对桌面游戏的概念完全陌生，直到现在才听说过这种 RPG 游戏？无论是哪一个并不重要，因为免费 RPG 日适合所有人！

第一个免费 RPG 日活动发生在 2007 年，是由世界各地的桌面游戏商家举办的。这个想法是以 0 美元的价格为新手和有经验的游戏玩家带来新的、独家的 RPG 快速入门规则和冒险体验。在这样的一天里，你可以走进当地的桌面游戏商家，得到一本小册子，其中包含桌面 RPG 的简单的初学者规则，你可以在商家里与那里的人或者回家与朋友一起玩。这本小册子是给你的，应该一直留着的。

这一活动如此的受欢迎，此后该传统一直延续至今。今年，免费 RPG 日定于 6 月 15 日星期六举行。

有什么收获？

显然，免费 RPG 日背后的想法是让你沉迷于桌面 RPG 游戏。但在你本能的犬儒主义开始之前，考虑到它会慢慢上瘾，爱上一个鼓励你阅读规则和知识的游戏并不太糟，这样你和你的家人、朋友就有了共度时光的借口了。桌面 RPG 是一个功能强大、富有想象力和有趣的媒介，而免费 RPG 日则是对这种游戏很好的介绍。

开源游戏

像许多其他行业一样，开源现象影响了桌面游戏。回到世纪之交，《Magic：The Gathering and Dungeons＆Dragons》 的提供者 威世智公司 Wizards of the Coast 决定通过开发 开源游戏许可证 Open Game License （OGL）来采用开源方法。他们将此许可证用于世界上第一个 RPG（《 龙与地下城 Dungeons & Dragons 》，D&D）的版本 3 和 3.5。几年后，当他们在第四版上（对开源）产生了动摇时，《 龙 Dragon 》杂志的出版商复刻了 D＆D 3.5 的“代码”，将其混制版本发布为《 开拓者 Pathfinder 》 RPG，从而保持了创新和整个第三方游戏开发者产业的健康发展。最近，威世智公司在 D&D 5e 版本中才又重回了 OGL。

OGL 允许开发人员至少可以在他们自己产品中使用该游戏的机制。不管你可以不可以使用自定义怪物、武器、王国或流行角色的名称，但你可以随时使用 OGL 游戏的规则和数学计算。事实上，OGL 游戏的规则通常作为系统参考文档（SRD）免费发布的，因此，无论你是否购买了规则书的副本，你都可以了解游戏的玩法。

如果你之前从未玩过桌面 RPG，那么使用笔和纸玩的游戏也可以拥有游戏引擎似乎很奇怪，但计算就是计算，不管是数字的还是模拟的。作为一个简单的例子：假设游戏引擎规定玩家角色有一个代表其力量的数字。当那个玩家角色与一个有其两倍力量的巨人战斗时，在玩家掷骰子以增加她的角色的力量攻击时，真的会感到紧张。如果没有掷出一个很好的点数的话，她的力量将无法与巨人相匹敌。知道了这一点，第三方或独立开发者就可以为这个游戏引擎设计一个怪物，同时了解骰子滚动可能对玩家的能力得分产生的影响。这意味着他们可以根据游戏引擎的优先级进行数学计算。他们可以设计一系列用来杀死的怪物，在游戏引擎的环境中它们具有有意义的能力和技能，并且他们可以宣称与该引擎的兼容性。

此外，OGL 允许出版商为其材料定义产品标识。产品标识可以是出版物的商业外观（图形元素和布局）、徽标、术语、传说、专有名称等。未经出版商同意，任何定义为产品标识的内容都可能无法重复使用。例如，假设一个出版商发行了一本武器手册，其中包括一个名为 Sigint 的魔法砍刀，它对所有针对僵尸的攻击都给予 +2 魔法附加攻击值。这个特性来自一个故事，该砍刀是一个具有潜伏的僵尸基因的科学家锻造的。但是，该出版物在 OGL 第 1e 节中列出的所有武器的正确名称都被保留为产品标识。这意味着你可以在自己的出版物中使用该数字（武器的持久性、它所造成的伤害，+2 魔法奖励等等）以及与该武器相关的传说（它由一个潜伏的僵尸锻造），但是你不能使用该武器的名称（Sigint）。

OGL 是一个非常灵活的许可证，因此开发人员必须仔细阅读其第 1e 节。 一些出版商只保留出版物本身的布局，而其他出版商保留除数字和最通用术语之外的所有内容。

当卓越的 RPG 特许经营权拥抱开源时，至今仍能感受到的它给整个行业掀起的波澜。第三方开发人员可以为 5e 和《开拓者》系统创建内容。由威世智公司创建的整个 DungeonMastersGuild.com 网站为 D＆D 5e 制作了独立内容，旨在促进独立出版。Starfinder、OpenD6、战士，盗贼和法师、剑与巫师 等及很多其它游戏都采用了 OGL。其他系统，如 Brent Newhall 的 《Dungeon Delvers》、《Fate》、《Dungeon World》 等等，都是根据知识共享许可授权的的。

获取你的 RPG

在免费 RPG 日，你可以前往当地游戏商铺，玩 RPG 以及获取与朋友将来一起玩的 RPG 游戏材料。就像 Linux 安装节 Linux installfest 或 软件自由日 Software Freedom Day 一样，该活动的定义很松散。每个商家举办的自由 RPG 日都有所不同，每个商家都可以玩他们选择的任何游戏。但是，游戏发行商捐赠的免费内容每年都是相同的。显然，免费的东西视情况而定，但是当你参加免费 RPG 日活动时，请注意有多少游戏采用了开源许可证（如果是 OGL 游戏，OGL 会打印在书背面）。《开拓者》、《Starfinder》 和 D＆D 的任何内容肯定都会带有 OGL 的一些优势。许多其他系统的内容使用知识共享许可。有些则像 90 年代复活的 Dead Earth RPG 一样，使用 GNU 自由文档许可证。

有大量的游戏资源是通过开源许可证开发的。你可能需要也可能不需要关心游戏的许可证；毕竟，许可证与你是否可以与朋友一起玩无关。但是如果你喜欢支持自由文化而不仅仅是你运行的软件，那么试试一些 OGL 或知识共享游戏吧。如果你不熟悉游戏，请在免费 RPG 日在当地游戏商家试玩桌面 RPG 游戏！

via: https://opensource.com/article/19/5/free-rpg-day

作者：Seth Kenlon 选题：lujun9972 译者：wxy 校对：wxy

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

Kubernetes 解决了一些开发和运维团队每天关注的的常见问题。

Kubernetes（K8S）是面向企业的开源容器编排工具的事实标准。它提供了应用部署、扩展、容器管理和其他功能，使企业能够通过容错能力快速优化硬件资源利用率并延长生产环境运行时间。该项目最初由谷歌开发，并将该项目捐赠给云原生计算基金会（CNCF）。2018 年，它成为第一个从 CNCF 毕业的项目。

这一切都很好，但它并不能解释为什么开发者和运维人员应该在 Kubernetes 上投入宝贵的时间和精力。Kubernetes 之所以如此有用，是因为它有助于开发者和运维人员迅速解决他们每天都在努力解决的问题。

以下是 Kubernetes 帮助开发者和运维人员解决他们最常见问题的五种能力。

1、厂商无关

许多公有云提供商不仅提供托管 Kubernetes 服务，还提供许多基于这些服务构建的云产品，来用于本地应用容器编排。由于与供应商无关，使运营商能够轻松、安全地设计、构建和管理多云和混合云平台，而不会有供应商锁定的风险。Kubernetes 还消除了运维团队对复杂的多云/混合云战略的担忧。

2、服务发现

为了开发微服务应用，Java 开发人员必须控制服务可用性（就应用是否可以提供服务而言），并确保服务持续存在，以响应客户端的请求，而没有任何例外。Kubernetes 的服务发现功能意味着开发人员不再需要自己管理这些东西。

3、触发

你的 DevOps 会如何在上千台虚拟机上部署多语言、云原生应用？理想情况下，开发和运维会在 bug 修复、功能增强、新功能、安全更新时触发部署。Kubernetes 的部署功能会自动化这个日常工作。更重要的时，它支持高级部署策略，例如蓝绿部署和金丝雀部署。

4、可伸缩性

自动扩展是处理云环境中大量工作负载所需的关键功能。通过构建容器平台，你可以为终端用户提高系统可靠性。Kubernetes Horizo​​ntal Pod Autoscaler（HPA）允许一个集群增加或减少应用程序（或 Pod）的数量，以应对峰值流量或性能峰值，从而减少对意外系统中断的担忧。

5、容错性

在现代应用体系结构中，应考虑故障处理代码来控制意外错误并快速从中恢复。但是开发人员需要花费大量的时间和精力来模拟偶然的错误。Kubernetes 的 ReplicaSet 通过确保指定数量的 Pod 持续保持活动来帮助开发人员解决此问题。

结论

Kubernetes 使企业能够轻松、快速、安全地解决常见的开发和运维问题。它还提供其他好处，例如构建无缝的多云/混合云战略，节省基础架构成本以及加快产品上市时间。

via: https://opensource.com/article/19/6/reasons-kubernetes

作者：Daniel Oh 选题：lujun9972 译者：geekpi 校对：wxy

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

前段时间，笔者参加了 UCloud 在京举办的 TIC 2019 大会，适逢 UCloud 实验室负责人叶理灯的演讲结束，就容器计算方面和他进行了短暂沟通。叶理灯是国内在云计算方面有深入研究和实践的资深专家，我觉得他的一些观点和看法值得分享给大家了解。

叶理灯，UCloud实验室负责人

叶理灯，UCloud 实验室负责人。现负责 UCloud 创新产品研发，专注面向企业的云计算产品的研发及运营。叶理灯拥有 10 年以上丰富的互联网研发经验，先后任职于腾讯、盛大云等互联网公司，从事海量分布式后台系统研发及运营工作。

定制违背了 K8S 初衷，提供原生 K8S 产品

记者：在官方的 K8S 发行版之上，各方云厂商提供 K8S 服务时都有一些自己的定制和调整，今天大会上提及的 UCloud 的 K8S 发行版 UK8S 主要做了哪些定制，有什么特色呢？

叶理灯：如果说定制 K8S 的话，其实是违背了 K8S 的初衷。我们并没有定制 K8S，我们是基于公有云给用户提供了原生的 K8S 产品。在公有云上提供原生的 K8S，其实要做很多的工作，例如与公有云的计算、网络和存储的整合，给用户提供一个开箱即用的原生K8S集群等等。

我为什么说不应该定制呢？因为大家知道 PaaS 发展到今天，一直存在的一个问题就是供应商绑定的问题。而 K8S 之所以那么有生命力，之所以迅速流行，是因为它提供了一个开源的标准，让用户使用 K8S PaaS 平台，可以避免厂商绑定。也就是说你的服务在某个服务商的 K8S 上运行，可以无缝的迁移到另外一个服务商。

作为云厂商其实最重要的工作是，基于我们自身云平台的体系，提供原生的 K8S 给用户使用，帮助他们减少在集群管理和资源整合方面的工作和投入。例如，我们网络能力、存储能力和计算能力的整合，就是让用户享受到原生K8S的好处，同时避免了很多运维的负担。

公有云的 K8S 处在底层 IaaS 和上层应用之间，一方面向下整合IaaS能力，一方面向上托管客户的应用。在整合 IaaS 方面，不改变 K8S原生特性，因为 K8S 本身架构足够开放，例如在我们实现的网络插件，是基于我们 IaaS 的 VPC 网络，让 pod 可以和我们托管区和物理云区域打通，这是我们 IaaS 能力在 K8S 产品上的体现，算是我们的特色之一，但这是在 K8S 体系支持下的插件方式实现的，不影响我们提供原生 K8S；在应用层面，厂商也可以基于 K8S 提供一些周边的功能以帮助用户提高效率，但它和提供一个一致的 K8S 环境不矛盾。

另外一方面，如果说定制的概念是指基于 K8S 本身开发体系所提供的插件机制去做二次开发，那每家厂商都要定制，因为 K8S 本身不是一个产品级就绪的环境，需要使用者去适配网络和存储还有计算，因为每个公有云厂商基于自己的 IaaS 去提供 K8S 产品，必然要去开发插件。

综上，向用户应该提供原生的、标准的 K8S 产品，但底层应该基于自身 IaaS 平台去定制，本质还是为了提高用户使用 K8S 的效率，让用户开箱即用。

K8S 落地挑战：改造成本和人才问题

记者：你觉得目前国内云厂商提供的 K8S 集群编排服务在推广方面目前欠缺的是什么？是什么阻碍了客户进一步去使用这些容器集群服务？

叶理灯：K8S 以容器技术为核心、以容器镜像为打包标准的特点，意味着如果要迁移到这个体系下，客户需要将软件做容器化打包和微服务改造，这个是有成本的。K8S 的特点决定它是运维和研发之间的桥梁，这样就要求公司的研发过程需要跟着改造。我们看到很多公司的运维人员有动力去推动，而研发人员则没有动力，因为它改变了研发的习惯和流程，增加了负担；当然也有的公司是研发希望用 K8S 管理应用，而需要运维跟着变。这样导致迁移到 K8S 的工作较重，但一旦这个阶段过去了，迁移后的效率和成本优势就体现出来了。

因此，这是个新技术落地的问题，涉及到用户教育和习惯的改变，这个需要社区和商业公司一起完成。而且每家公司的技术路线和文化不一样，上 K8S 的路径也不一样，所以没有一个放之四海皆准的最佳实践，但随着容器和微服务逐渐落地，K8S 作为事实标准，会逐步普及。

除了改造业务的成本，另外一方面是 K8S 人才比较缺乏，不同用户的情况不一样，有些用户的运维人员本来就很少，不可能专门抽出一两个人去做 K8S，以及用户又担心它出问题谁来帮我解决？其实，应该是云厂商再往前走一步，除了帮用户构建一个 K8S 平台，还要帮助解决很多技术上的问题。 UCloud 现在就是这么做的，一个用户进来，我们会拉一个群，他们所有技术问题我们帮他们解决。在落地方面，在人才和 K8S 本身对用户架构改造方面，我们可以多做点工作，帮助客户培养K8S的运维人员和为用户制定架构迁移的方案。但我相信随着技术的发展和普及，越来越多人懂 K8S。

最后，K8S 本身也在发展，K8S 刚推出的时候是为了让大家重新面向应用来运维，但是大部分用户用 K8S 同时管理集群里的节点和应用，就会同时有两个负担。我觉得目标应该是用户直接拿一个容器就可以跑起来，而不用知道它的节点在哪里，即 Serverless 形态。一旦这种技术更加成熟，对容器技术的落地也有很大的推动作用。另一方面，Serverless 形态也给用户节省了大量的成本，按需付费，免去用户的运维成本。我觉得 K8S 的落地已经是个趋势了，是不可避免的，但是 K8S 本身是要往前进步，它的革命还没有完成。

容器与 Serverless：覆盖场景不同，非替换关系

记者：你觉得现在目前 Serverless 的发展对于容器这种创新技术的迭代升级有什么影响？是不是可以让容器更加的轻量化？

叶理灯：不完全是这样，其实 Serverless 刚出现的时候是针对计算的。计算分很多层次，有物理机、虚拟机、容器和 Serverless。Serverless 刚出来的时候，它等同于 FaaS，有一个对标的产品叫 Lambda。

Serverless 出现的动力是，由于云计算的发展，带来了如对象存储等很多丰富的中间件，Serverless 概念的提出是希望应用开发者可以不用写后端逻辑，直接把逻辑写在客户端，组合云上的一些服务来完成业务逻辑，这样就没有管理后端资源的负担了。但是后来发现很多时候还是需要后端代码的，所以就演变成如果有后端代码，就拆成函数，托管在 FaaS 服务中，这样的话，你依然是不用管理服务器的，你用的还是一个个服务，没有服务器管理负担。

这个概念在不断进步，2017 年的时候 AWS 提出了一个新的概念，重新定义了什么叫 Serverless，只要一个服务具备了四方面特性：免运维、按需付费、高可用和自动扩容，这个服务就是个 Serverless 的服务。所以 Serverless 这个概念可以对应 FaaS，也可以代表一种架构，也可以代表一种服务的形态，例如 Aurora Serverless 就是把一个数据库的服务变成 Serverless 的。

容器和 Serverless 的区别在于，Serverless 是无容器的，除了不关注服务器，也看不到容器。两者是面向不同场景的，并不是互相替代的关系。FaaS 的特点，接收一个请求拉起一个函数执行，函数是无状态的，它的执行地点也不固定，这意味着延时相对于常驻进程要高，对一些延时敏感的地方它是不合适的，但是有些场景是非常合适的。我举个例子，在 IoT 场景中，有几十万的设备，为了节省电源，它们大部分时候处于睡眠状态，如果用传统的架构去为这几十万设备服务的话，肯定要考虑并发连接的时候，应该有多少计算资源去服务，这很浪费成本。所以最好的方式，来一个请求就拉一个函数服务一下，这就很节省成本。

这是按需的，但它不是完整的替换，相当于说 IT 领域里面不同的场景其实是使用不同的服务。我们推出这个服务的原因，背后的动力还是成本和效率，在某个场景上用某个解决方案它的成本更低、效率更高，而不是说新的东西会替换老的，因为不同场景需求是不一样的。K8S 接受的用户比 FaaS 的用户更多，因为 K8S 的面更广，它覆盖的场景更多，但是它不是替换的。

记者：目前，国内客户对 Serverless 和 PaaS 的接受和普及程度是怎么样的？

叶理灯：我觉得在国内还是处于起步和用户教育阶段。2014 年 Lambda 推出的时候，它的渗透率是 72%，什么原因呢？有 72% 的人用的 Lambda，我们有个 Serverless 产品叫 UGC，腾讯有 FaaS，阿里也有 PaaS，目前都不算是渗透率很高。

原因有几个。第一、国内用户对新技术接受程度是比较低的，可能是习惯问题，国内的IT的发展水平跟国外也有差距，有 5、6 年差距；其次，对国内用户来说，把一个架构改成 Serverless 架构，其实成本是很高，而且改造的收益和规模相关；最后， FaaS 本身不是一个独立能起作用的产品，你会看到 Lambda 推出时，不是个独立的产品，它是体系的副产品，例如其他产品要开放事件源，通过事件去触发 Lambda 函数执行。只有产品体系开放足够多的事件源，FaaS 才能渗透到整个平台里面去，才能覆盖更多场景。

我们国内的厂商还没有做到这一点。AWS 刚推出 FaaS 时，它主要是 S3 上的图片处理，不是每个用户都有这个场景，因此渗透率不高。随着 API 网关方式调用，和体系开放事件源越来越丰富，覆盖场景越来越多，我相信 FaaS 会逐步落地。

在现场的演讲中，提及了一个叫 USQL 的产品，就是 Serverless 方式的大数据分析工具，StepFlow 用 Serverless 的方式编排你的程序，这些都是 Serverless 的服务。

未来，虚拟化容器值得关注

记者：目前 UK8S 的主要发展方向有什么路线图吗？UK8S 是否已经开源？

叶理灯：有的，例如说我们让 K8S 管理更多的资源、异构的资源，还有物理机、GPU 资源，希望用户可以通过 K8S 对这些资源进行统一地管理。另外，再往业务层面走会提供一些微服务的基础设施，通过产品化，一方面减轻用户的资源负担，另一方面减轻应用层的架构负担，从而尽量减轻用户迁移到 K8S 的负担。

目前 UK8S 插件还属于正在整理开源的阶段，还没有正式的发布，但我们已经小范围的开放了代码，把我们的插件代码分发给到很多用户，但公开的开源，我们希望做的更加规范一点再进行，因为我们的插件还在不断的迭代中，有一天我们觉得达到一定程度的稳定了，我们就会进行公开开源。

记者：你认为未来 K8S 以及容器的技术方向上比较值得重点关注的技术点是什么？

叶理灯：虚拟化容器。未来的方向我们相信是 Serverless，这个也是云计算应该做的，持续地为了用户提高效率和降低成本。刚才我也说了，现在用户使用 K8S 还是有资源管理的负担的，不是完全的面向应用来运维，所以需要解决这个问题，让计算节点对用户透明。用户通过 Docker 镜像和配置文件就可以把一个应用跑起来，而不用去管资源问题。这需要我们去提供一个海量的集群去跑客户的应用，这就存在一个问题，多个客户的应用可能跑在一个节点上，考虑 Docker 本身的隔离问题，我们需要类似虚拟化容器的计算方式去做隔离，同时又希望拥有 Docker 本身轻量级快速启动的效率，现在看来，虚拟化容器是比较符合这个需求的。

尾声

通过和叶理灯的交谈，梳理了我对云计算、容器技术和 Serverless 等方面的一些认识，作为一个几年来亲自践行云计算发展，并有深入探讨和研究的专家，他的观点和认识或许值得从业云计算行业的技术人员参考。

伴随着物联网设备使用量的增长，这些设备产生的数据可以让消费者节约巨大的开支，也给商家带来新的机遇。但是当故障不可避免地出现的时候，会发生什么呢？

不管你看的是什么统计数字，很明显物联网正在走进个人和私人生活的方方面面。这种增长虽然有不少好处，但是也带来了新的风险。一个很重要的问题是，出现问题的时候谁来负责呢？

也许最大的问题出在基于物联网数据进行的个性化营销以及定价策略上。保险公司长期以来致力于寻找利用物联网数据的最佳方式，我去年写过家庭财产保险公司是如何开始利用物联网传感器减少水灾带来的损失的。一些公司正在研究保险公司竞购消费者的可能性：这种业务基于智能家居数据所揭示的风险的高低。

但是最大的进步出现在汽车保险领域。许多汽车保险公司已经可以让客户在车辆上安装追踪设备，如果数据证明他们的驾驶习惯良好就可以获取保险折扣。

• 延伸阅读:保险公司终于有了一个利用智能家居物联网的好办法

UBI 车险的崛起

UBI（ 基于使用的保险 usage-based insurance ）车险是一种“按需付费”的业务，可以通过追踪速度、位置，以及其他因素来评估风险并计算车险保费。到 2020 年，预计有 5000 万美国司机会加入到 UBI 车险的项目中。

不出所料，保险公司对 UBI 车险青睐有加，因为 UBI 车险可以帮助他们更加精确地计算风险。事实上，AIG 爱尔兰已经在尝试让国家向 25 岁以下的司机强制推行 UBI 车险。并且，被认定为驾驶习惯良好的司机自然也很乐意节省一笔费用。当然也有反对的声音了，大多数是来自于隐私权倡导者，以及会因此支付更多费用的群体。

出了故障会发生什么？

但是还有一个更加令人担忧的潜在问题：当物联网设备提供的数据有错误，或者在传输过程中出了问题会发生什么？因为尽管有自动化程序、错误检查等等，还是不可避免地会偶尔发生一些故障。

不幸的是，这并不是一个理论上某天会给细心的司机不小心多扣几块钱保费的问题。这已经是一个会带来严重后果的现实问题。就像保险行业仍然没有想清楚谁应该“拥有”面向客户的物联网设备产生的数据一样，我们也不清楚谁将对这些数据所带来的问题负责。

计算机“故障”据说曾导致赫兹的出租车辆被误报为被盗（虽然在这个例子中这并不是一个严格意义上的物联网问题），并且导致无辜的租车人被逮捕并扣留。结果呢？刑事指控，多年的诉讼官司，以及舆论的指责。非常强烈的舆论指责。

我们非常容易想象一些类似的情况，比如说一个物联网传感器出了故障，然后报告说某辆车超速了，然而事实上并没有超速。想想为这件事打官司的麻烦吧，或者想想和你的保险公司如何争执不下。

（当然，这个问题还有另外一面：消费者可能会想办法篡改他们的物联网设备上的数据，以获得更低的费率或者转移事故责任。我们同样也没有可行的办法来应对这个问题。）

政府监管是否有必要

考虑到这些问题的潜在影响，以及所涉及公司对处理这些问题的无动于衷，我们似乎有理由猜想政府干预的必要性。

这可能是美国众议员 Bob Latta（俄亥俄州，共和党）重新引入 SMART IOT（物联网现代应用、研究及趋势的现状）法案背后的一个动机。这项由 Latta 和美国众议员 Peter Welch（佛蒙特州，民主党）领导的两党合作物联网工作组提出的法案，于去年秋天通过美国众议院，但被美国参议院驳回了。美国商务部需要研究物联网行业的状况，并在两年后向美国众议院能源与商业部和美国参议院商务委员会报告。

Latta 在一份声明中表示，“由于预计会有数万亿美元的经济影响，我们需要考虑物联网所带来的的政策，机遇和挑战。SMART IoT 法案会让人们更容易理解美国政府在物联网政策上的做法、可以改进的地方，以及美国联邦政策如何影响尖端技术的研究和发明。”

这项研究受到了欢迎，但该法案甚至可能不会被通过。即便通过了，物联网在两年的等待时间里也可能会翻天覆地，让美国政府还是无法跟上。

via: https://www.networkworld.com/article/3396230/when-iot-systems-fail-the-risk-of-having-bad-iot-data.html

作者：Fredric Paul 选题：lujun9972 译者：chen-ni 校对：wxy

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