技术

采纳

1. 将产品管理思维应用于内部平台

2. 基础设施即代码

3. 微前端

4. 流水线即代码

5. 务实的远程结对

6. 最简特性开关

试验

7. 机器学习下的持续交付

8. 道德偏见测试

9. GraphQL用于服务端资源聚合

10. 移动微前端

11. 平台工程产品团队

12. 安全策略即代码

13. 半监督学习循环

14. NLP的迁移学习

15. 使用原生的远程工作方法

16. 零信任架构

评估

17. 数据网格

18. 去中心化身份识别

19. 声明式数据管道定义

20. DeepWalk

21. 通过容器编排管理有状态系统

22. 预检构建

暂缓

23. 云平移

24. 遗留系统迁移的功能一致性

25. 用于业务分析的日志聚合

26. Gitflow的长期分支

27. 仅快照测试

将产品管理思维应用于内部平台

采纳

越来越多的公司正在构建内部平台，借此快速有效地推出新型数字化解决方案。成功实施这一战略的企业正将产品管理思维应用于内部平台。这意味着与内部消费者（开发团队）建立共情，并在设计上彼此协作。平台的产品经理要建立路线图，确保平台为业务交付价值，为开发者改善体验。不幸的是，我们也见到了一些不太成功的方式，团队在未经验证的假设、没有内部客户的情况下，打造出的平台犹如空中楼阁。这些平台尽管采用了激进的内部策略，但往往无法充分利用，还耗尽了组织的交付能力。和其他产品一样，好的产品管理就是为消费者创造喜爱的产品。

基础设施即代码

采纳

尽管基础设施即代码是一种相对旧的技术（我们早在2011年的技术雷达中就已经介绍过它），但在现代云时代，构建基础设施的行为已经成为了将配置指令传递到云平台的重要组成部分，因此它变得非常重要。当我们说“即代码”时，是指我们在软件领域学到的所有良好实践都应应用于基础设施。使用源代码控制，遵守DRY原则、模块化、可维护性以及使用自动化测试和部署都是关键的实践。我们当中具有深厚软件和基础设施背景的人，需要体谅和支持那些没有做过这些的同事。仅仅说像对待代码一样处理基础设施还不够，我们需要确保从软件世界学到的来之不易的经验教训，也能够同样应用到整个基础设施领域。

微前端

采纳

引入微服务令我们受益匪浅，使用微服务，团队可以扩展那些独立部署及维护的服务的交付。遗憾的是，我们也看到许多团队创建了单体前端——一个建立在后端服务之上的大而混乱的浏览器应用程序——这在很大程度上抵消了微服务带来的好处。自从问世以来，微前端持续变得流行。我们已经看到，许多团队采用这种架构的某种形式，来管理多开发人员和多团队的复杂性，以提供相同的用户体验。在去年的六月份，这个技术的发起人之一，发表了一篇介绍性的文章，可以起到微前端参考文献的作用。它展示了这种设计是如何通过各种Web编程机制实现的，以及使用React.js构建了一个示例应用程序。我们有理由相信，随着大型组织尝试在跨多团队中分解UI开发，这种风格将越来越流行。

流水线即代码

采纳

流水线即代码技术强调，用于构建、测试和部署我们应用程序或基础设施的交付流水线配置，都应以代码形式展现。这些代码应置于版本控制系统中，并切分成包含自动化测试和部署的可复用组件。随着组织逐渐演变为构建微服务或微前端的去中心化自治团队，人们越来越需要以代码形式管理流水线这种工程实践，来保证组织内部构建和部署软件的一致性。这种需求使得业界出现了很多交付流水线模板和工具，它们可以以标准的方式构建、部署服务和应用。这些工具用大多采用声明式交付流水线的形式，采用一个流水线蓝图，来执行一个交付生命周期中不同阶段的任务，如构建、测试和部署，而不用关心实现细节。以代码形式来完成构建、测试和部署流水线的能力，应该成为选择CI/CD工具的评估标准之一。

务实的远程结对

采纳

我们坚信结对编程可以提高代码质量，在团队中传播知识，并可以在总体上更快地交付软件。然而在后COVID的世界中，许多软件团队将是分布式的或完全远程工作的。因此在这种情况下，我们建议采用务实的远程结对，即根据手头的工具调整结对策略。考虑使用Visual Studio Live Share这样的的工具来实行高效、低延迟的协作。仅当结对双方居住的地理位置相对靠近且网络带宽足够高时，才使用高清的屏幕共享。让所处时区相近的开发人员结对工作，而不要无视地理位置。如果出于客观原因导致结对难以进行，也有一些应对措施可以执行，例如独立编码辅以代码审查、基于pull-request的协作（但要提防Gitflow长期分支），或仅在代码关键部分进行短期结对。以我们多年的经验看来，采用实用主义的远程结对编程是有效的。

最简特性开关

采纳

我们遗憾地发现，人们很少使用特性开关，且经常混淆其类型和使用场景。为了从持续集成中受益，一些团队会使用LaunchDarkly等重量级平台来实现特性切换（包括发布切换），即使他们所需要的仅仅是简单地if/else条件控制。因此，除非你需要A/B测试、金丝雀发布或将特性发布的职责交给业务人员，我们建议使用最简特性开关来代替不必要的复杂的特性。

机器学习下的持续交付

试验

利用机器学习使业务应用和服务智能化，并不仅仅是训练模型并为其提供服务。它需要实现一整套端到端、持续可重复的模型训练、测试、部署、监控和运维周期。机器学习下的持续交付（CD4ML）是一种可靠的端到端开发、部署和监控机器学习模型的技术。支撑CD4ML的基础技术栈包括数据访问和探索工具、工件（例如数据、模型和代码）的版本控制、持续交付流水线、用于各种部署和实验的自动化环境设置、模型性能评估和跟踪，以及模型运作的可观测性。公司可以根据现有的技术栈选择自己的工具集。CD4ML强调自动化和避免手工交接。CD4ML是我们开发机器学习模型的默认方法。

道德偏见测试

试验

在过去的一年中，人们对机器学习，尤其是深度神经网络的兴趣发生了转变。到目前为止，人们对各个模型无限潜能的兴奋，驱动了多种工具及技术的发展。然而近期以来，人们越来越担心这些模型可能无意间造成的伤害。例如，模型可以无意中被训练做出有利可图的信用决策，粗暴地排除处于不利地位的申请人。幸运的是，道德偏见测试越来越受关注，这将有助于发现潜在的有害决定。lime 、AI Fairness 360或What-If Tool等工具可以帮助发现训练数据中由少数群体导致的偏差，Google Facets或Facets Dive等可视化工具可用于发现训练数据集内的子组。除了道德偏见测试，我们还将lime（local interpretable model-agnostic explanations，局部可知、模型不可知的解释）用于理解机器学习分类器的预测以及分类器（或模型）的功能。

GraphQL用于服务端资源聚合

试验

我们看到越来越多的工具（例如Apollo Federation）支持将多个GraphQL端点聚合到一个图中。但必须提醒的是，不要滥用GraphQL，尤其是作为服务间的协议时。我们的实践是仅将GraphQL用于服务端资源聚合。使用这种模式时，微服务会持续发布明确定义的RESTful API，而聚合服务或BFF（Backend for Frontends）模式则使用GraphQL解析器集成其他服务资源。图的形状需由领域建模实践驱动，以确保在必要时（在每个限界上下文都是一个微服务的情况下）将统一语言局限在子图内。该技术简化了聚合服务或BFF的内部实现，同时鼓励对服务进行良好的建模以避免贫血REST。

移动微前端

试验

自2016年雷达对其进行介绍以来，我们已经看到微前端在Web UI中得到了广泛应用。然而，最近我们发现不少项目也将这种架构风格扩展到了移动应用程序中，亦可称其为移动微前端。当应用程序变得足够大且复杂时，有必要将其开发分布在多个团队中。如此一来，在保证团队自治的同时，还要将他们的工作集成到单个应用中是很有挑战的。尽管我们已经看到有的团队在编写自己的框架来支持这种开发风格，但是现有的模块化框架（例如Atlas和Beehive）也可以简化多团队应用开发的集成问题。

平台工程产品团队

试验

采用云计算和DevOps，虽然提高了团队生产力，减少了对集中式运维团队和基础设施的依赖，但也制约了那些缺乏自管理完整应用和运维技巧的团队。一些组织通过创建平台工程产品团队来应对这些挑战。这些团队维护着一个内部的应用平台，该平台使交付团队能够自助部署和运维系统，从而减少交付时间和降低技术栈的复杂度。这里的重点是API驱动的自服务和支持工具，而交付团队仍然需要对部署在该平台上的应用负责。当组织考虑组建这样一个团队的时候应当非常小心，避免无意中创建一个独立的Dev-Ops团队，也不要把现有托管及运维设施重新打上平台的标签。关于如何最佳地组建平台团队，我们一直在使用团队拓扑中的概念，将项目中的平台团队划分为赋能团队、核心“平台中的平台”团队和关注流量的团队。

安全策略即代码

试验

安全策略是保护我们的系统免受威胁和破坏的规则和程序。例如，访问控制策略定义并强制谁可以在什么情况下访问哪些服务和资源；或者网络安全策略可以动态地限制特定服务的流量速率。当今技术环境的复杂性要求将安全策略视为代码；我们需要定义安全策略脚本、将其加入版本控制中、自动验证、自动部署并监测其性能。Open Policy Agent这样的工具或者Istio之类的平台提供了灵活的策略定义和实施机制，它们都可以支持安全策略即代码的实践。

半监督学习循环

试验

半监督学习循环是一类迭代式的机器学习工作流，它们利用未标记数据中尚待发现的关系，来提升学习性能。这些技术通过不同方式组合已标记和未标记的数据集，从而改进模型。此外，它们还对在不同数据子集上训练出来的模型进行对比。与机器从未标记数据中推断分类的无监督学习，以及训练集完全标记的有监督技术不同，半监督技术利用的是一小部分已标记数据和大量的未标记数据。半监督学习还与主动学习技术密切相关，在主动学习技术中，人们被引导至选择性标记的模糊数据点。因为能够精确标记数据的专家是稀缺资源，并且标记通常是机器学习工作流中最耗时的活动，所以半监督技术不仅降低了训练成本，还使机器学习对于新型用户而言是可行的。我们还看到了弱监督技术的应用，它使用了机器标记的数据，但其可信度低于人工标记的数据。

NLP的迁移学习

试验

该技术之前处于技术雷达的评估维度。NLP（Natural Language Processing），自然语言处理领域的创新在持续快速发展，并且由于无处不在的迁移学习，使得我们可以将这些创新应用到项目中。GLUE基准测试（一套语言理解任务）的得分在过去几年里有了显著的进步，平均分数从刚发布时的70.0上升到2020年4月处于领导地位的90.0。我们在NLP领域的很多项目，从ELMo、BERT和ERNIE等预训练模型开始，然后根据项目需求进行微调，可以取得重大进展。

使用原生的远程工作方法

试验

分布式团队有多种形态和设置；对于我们来说，100%位于同一地点的交付团队反而已经成为例外。我们大多数团队都是多点团队，或者至少有一些团队成员在异地工作。因此，默认情况下使用原生的远程工作方法可以极大地帮助团队提高整体流程和效率。首先要确保每个人都可以访问必要的远程系统。此外，请使用例如Visual Studio Live Share、MURAL或Jamboard等工具，将在线工作坊和远程结对变成惯例，而不是偶尔为之。但是，“使用原生的远程工作方法”不只是将本地的协同实践平移到数字世界：拥抱更多的异步沟通、围绕决策文档的更多纪律以及“始终远程”会议是我们团队默认采用的其他方法，用于应对随时可能发生的位置变换。

零信任架构

试验

随着资产（数据、功能、基础架构和用户）跨越安全边界（本地主机，多云提供商以及各种SaaS供应商），组织的技术版图正在变得越来越复杂。这就要求企业安全计划和系统架构进行范式转变：从基于信任区和网络配置的静态、缓慢改变的安全策略，转变为基于临时访问权限的动态、细粒度的安全策略。

零信任架构（Zero trust architecture，ZTA）是组织针对其所有资产（设备、基础设施、服务、数据及用户）实施零信任安全原则的策略和流程，以及对最佳实践的践行（包括不论网络位置确保所有访问和通信的安全、强制基于最小权限原则并尽可能细粒度控制的策略即代码、持续监控和自动缓解威胁等）。技术雷达介绍了很多赋能技术，例如安全策略即代码，端点安全边车和BeyondCorp。如果准备进一步了解ZTA，请参阅NIST ZTA和Google在BeyondProd上发表的文章，以了解更多关于原则、赋能技术组件及迁移模式的信息。

数据网格

评估

数据网格是一种架构和组织范式，它挑战了我们的传统观念，即必须将大量的可分析数据集中起来才能使用，将数据放在一起或让专门的数据团队来维护。数据网格声称，为了让大数据推动创新，数据的所有权必须和将数据作为产品提供服务的领域数据所有者联合起来（在自助数据平台的支持下，抽象数据产品服务所涉及的技术复杂性）；它还必须通过自动化的方式实现一种新的联合治理形式，以支持面向领域的数据产品间的互操作性。去中心化、互操作性以及数据消费者体验，是数据创新民主化的关键。

如果你的组织有大量的领域，包括大量产生数据的系统和团队，或者多种数据驱动的用户场景和访问模式，我们建议你评估数据网格。构建数据网格需要的投资包括构建自服务的数据平台、支持对领域进行组织结构变更以长期维护其数据产品，以及一个激励机制，来奖励将数据作为产品提供和使用的领域团队。

去中心化身份识别

评估

自互联网诞生以来，技术领域已朝着去中心化的方向加速发展。虽然如HTTP之类的协议和如微服务或数据网格这样的的架构模式，使得去中心化的实现成为可能，但身份管理仍然保持着中心化的实现。然而，分布式账本技术（DLT）的出现使去中心化身份识别的概念成为可能。在一个去中心化身份识别系统里，实体是离散的可识别单元，例如人、组织和事件都可以自由使用任何共享的信任根。相反，常规的身份管理系统基于集中的权限和注册表，例如公司目录服务、证书颁发机构或域名注册表。

去中心化身份标识符的开发是主要的启用标准，它是全球独特的、持久的的且可加密验证的自我主权标识符。尽管规模化的去中心化身份标识符的实现仍然很少见，但我们对这一运动的前提感到兴奋，并已开始在架构中使用这一概念。有关最新的实验和行业合作，请查看Decentralized Identity Foundation。

声明式数据管道定义

评估

许多数据管道都或多或少地使用了Python或Scala编写的命令式脚本来定义。这样的脚本中包含了各个步骤的逻辑以及将这些步骤串联起来的代码。在使用Selenium测试时，出现过类似的情况，而后开发人员发现了Page Object模式，后来许多行为驱动开发（BDD）框架都实现了步骤定义与步骤组合之间的分离。现在，一些团队正在尝试为数据工程引入相同的思路。一个独立的声明式数据管道定义（可能是用YAML编写的）仅包含一些步骤的声明和顺序。它定义了输入和输出的数据集，并且在需要更复杂的逻辑时决定是否需要以及何时引入脚本。我们发现了该领域的第一个开源工具——A La Mode。

DeepWalk

评估

DeepWalk是一个有助于将机器学习应用于图的算法。在处理以图表示的数据集时，关键问题之一就是从图中提取特征。这就是DeepWalk可以发挥作用的地方。DeepWalk使用SkipGram来构造嵌入式节点，它将图视为一种语言，图中的每一个节点都是该语言中的唯一单词，DeepWalk通过随机遍历图中有限的节点来将单词构造成句子。这些图嵌入随后便可应用于各种机器学习模型中。我们有些项目需要在图上应用机器学习，DeepWalk是我们尝试的技术之一。

通过容器编排管理有状态系统

评估

我们建议在利用容器编排平台（例如Kubernetes）管理有状态系统时要谨慎。有些数据库不能为容器的编排提供原生支持——它们不期望被调度器终结并重新部署到另一台主机。在这样的数据库上构建高可用服务并非易事。因此我们仍然建议在裸机或虚拟机（VM）上运行它们，而不是将其强行适配到容器平台上。

预检构建

评估

尽管相比Gitflow来说，我们强烈推荐CI，但我们知道直接向主干提交然后在master分支上跑CI，在团队过大的时候是低效的。构建会变慢或不稳定，也可能团队会缺乏在本地运行完整测试集的纪律。在这种情况下，一次红色的构建可以阻塞多名或多对开发者的工作。许多团队通常依赖功能分支来绕过这些问题，而不是解决潜在的根本原因——构建缓慢、不能本地运行测试或迫使许多人在同一位置工作的单体架构。我们不鼓励功能分支，因为它可能需要巨大的努力来解决合并冲突，并且还可能在解决冲突的过程中拉长了反馈周期和引入缺陷。取而代之的是，我们提议使用预检构建作为替代方案：它是基于Pull Request的构建，针对只在流水线运行期间存在的为每个commit建立的微型分支。为了自动化这一工作流，我们已经见到了类似Bors这样的机器人程序，它将合并master分支和删除迷你分支（当构建成功时）的工作自动化。我们正在评估这个流程，你也应该试试看，但请不要用它去解决错误的问题，因为这样的话可能会带来分支滥用，导致弊大于利。

云平移

暂缓

奇怪的是，有了十多年的云迁移行业经验之后，我们仍然认为有必要呼吁大家警惕云平移。因为它只将云视为托管的解决方案，并且在云上直接简单复制现有的架构、安全实践和IT运营模式。这种方式并未意识到云在敏捷性和数字创新方面的优势。云迁移需要有意地跨多个轴向云原生状态转变，并且根据独特的迁移环境，每个组织最终的结果可能会处于从云平移到云原生迁移这样一个波谱中的某个位置。例如，系统架构作为交付敏捷性的支柱之一，我们通常需要对其进行修改。简单地将现有系统平移为容器具有很强的诱惑性。尽管此策略可以加快云迁移的速度，但在创建敏捷性以及交付功能和价值方面却存在不足。云上的企业安全与传统的通过防火墙和分区的基于边界的安全从根本上是不同的，它需要企业迈向零信任架构。同时，它还需要IT运营模式的改革，以便于通过自助式的自动化平台安全地提供云服务，使团队能够承担更多的运营责任并获得自治权。最后，组织必须建立起能支撑持续变化的基础，例如同样迁移为应用和基础设施进行持续测试而创建的的流水线。这些将有助于迁移过程，并最终构建一个更健壮和完善的系统，同时也为组织提供了持续演进和改进自身系统的方式。

遗留系统迁移的功能一致性

暂缓

我们发现，越来越多的组织需要替换陈旧的遗留系统，以适应其客户（内部和外部）的需求。我们持续看到的一种反模式是遗留系统迁移的功能一致性，即保留旧版本同样功能的愿望。我们认为这错失了一个巨大的机会。随着时间流逝，旧系统往往会变得臃肿，包含了许多不被用户使用的功能（根据2014年Standish Group的报告，这一比例为50%）和随着时间而发展的业务流程。替换这些功能是一种浪费。我们的建议：说服你的客户退一步思考，了解他们的用户当前需要什么，并根据业务结果和指标，对这些需求进行优先排序——这通常说起来容易做起来难。这意味着需要进行用户调研，并采用现代产品开发实践，而不是简单地替换现有的系统。

用于业务分析的日志聚合

暂缓

几年前，出现了新一代的日志聚合平台，该平台能够存储和搜索大量的日志数据，用来发掘运营数据中的趋势和洞见。这种工具有很多，Splunk是其中最著名的。由于这些平台可在整个应用程序范围内提供广泛的运营和安全可见性，因此管理员和开发人员越来越依赖于它们。当干系人发现可以使用“日志聚合进行业务分析”时，他们便开始乐于此道。但是，业务需求可能会很快超越这些工具的灵活性和可用性。旨在提供技术可观察性的日志通常很难对用户有深刻的理解。我们更喜欢使用专门为用户分析而设计的工具和指标，或者采用更具事件驱动性的可观察性方法，其中收集、存储业务和运营事件的方式可以用更多专用工具来重现和处理。

Gitflow的长期分支

暂缓

五年前，我们强调了Gitflow长期分支的问题。从本质上讲，长期分支与将所有更改持续集成到源代码中的方法背道而驰。并且，根据我们的经验，持续集成对大多数软件开发来说是更好的方法。后来，因为看到不少团队几乎只用长期分支，我们将警惕的态度扩大到Gitflow本身。时至今日，我们依然能看到以Web系统持续交付为既定目标的团队沉迷于长期分支。因此当看到Gitflow的作者现在已经在他的原有文章中添加了一条注释，解释说Gitflow当初不是为此类场景而设计时，我们非常高兴。

仅快照测试

暂缓

在遗留系统中工作时，为了保证系统继续运行且不破坏遗留代码功能，快照测试的价值是不可否认的。然而，我们看到了使用仅快照测试作为主要测试机制这种常见但有害的做法。快照测试可以验证组件在DOM中生成的确切结果，但不能验证组件的行为。因此，它可能是脆弱且不可靠的，还会催生“仅删除快照后重新生成快照”这样不好的实践。与此相反，您应该通过模拟用户的操作，对组件的逻辑和行为进行测试。Testing Library系列中的工具也鼓励这种思维方式。