采纳
交付核心四指标为了度量软件交付的效能，越来越多的组织默认采用由DORA 研究项目定义的交付核心四指标，即：更改前置时间、部署频率、平均恢复时间(MTTR)和变更失败率。这项研究及其统计分析展示了高效能交付团队和这些指标的高度相关性，它们为衡量整个交付组织的表现提供了极佳的领先指标。虽然我们依然是这些指标的坚定拥护者，但我们也吸取了一些教训。我们持续看到被误导的度量方式，这些方式使用的工具单纯基于持续交付(CD)流水线。尤其在衡量稳定性指标（MTTR和变更失败率）时，仅依赖CD流水线数据提供的信息并不足以确定部署失败对实际用户的影响。只有包含真实事故，如用户服务降级，稳定性指标才有意义。我们建议始终牢记度量指标背后的终极目的，并使用它们来思考和学习。比如，在花费数周时间构建复杂仪表板工具之前，可以考虑定期在团队回顾会议上进行DORA快速检查。这能够使团队有机会思考他们应该在哪些能力上努力以提升他们的指标，这会远比过于详细的开箱即用工具更有效。需要牢记这四个核心指标源于对高效能交付团队的组织级研究，在团队级别使用这些指标应该作为团队反思自身行为的一种方式，而不仅仅是添加到仪表板上的另一组度量标准。
统一远程团队墙统一远程团队墙是一项简单的技术，可以用虚拟的方式重新引入团队墙实践。我们建议分布式工作的团队采用这种方式；我们从迁移到远程工作的团队那里听到的一件事是，他们怀念使用实体团队墙的时候。这是一个能统一显示各种故事卡、任务、状态和进度的地方，在团队中充当信息辐射器和信息枢纽的角色。但是这种墙仅仅是作为一个集成点存在，实际的数据存储在各种不同的系统中。随着团队越来越远程化，他们不得不回归到各个信息源系统中去查看所需信息，很难再通过团队墙一目了然地了解项目。尽管保持团队墙的最新状态可能会需要一些代价，但我们还是认为这些都是值得去做的。对于一些团队来说，更新实体墙是团队日常“仪式”的一部分，所以远程墙也可以像这样去做。
试验
数据网格数据网格是一种面向分析和机器学习的技术方法，以去中心化的组织和技术方式分享、访问和管理数据。当前数据组织架构日渐复杂，数据使用案例激增以及数据源愈加多样化，面对当前的数据环境，数据网格希望创建一种社会技术方法，旨在规模化的获取数据中的价值。从本质上讲，它创建了一个可靠的数据共享模式，与组织同步发展并持续拥抱变化。据我们所知，业界对数据网格的兴趣正在显著增长。这种方法已经激发了许多组织去拥抱它所提倡的内容，技术供应商也使用现有技术为数据网格找到了新的部署方式。尽管业界对数据网格颇有兴趣，并且也越来越有经验，但是其实施却面临着高昂的整合成本。此外，它所提倡的内容仍旧局限于那些依据数据网格的硬性社会层面进行组织拆分的大型机构以及技术供应商——去中心化的数据所有权和联合治理的运作模式。这些想法在 Data Mesh: Delivering Data-Driven Value at Scale 一书中被探讨，用于指导从业人员、架构师、技术领导以及决策者从传统大数据架构到数据网格的转型。该书完整地介绍了数据网格的原理及其构成要素；涵盖了如何设计数据网格架构、指导和执行数据网格战略以及引导组织设计向去中心化的数据所有权模式发展。本书的目标是为更深层次的对话创造一个新的框架，并引导数据网格到成熟的下一阶段。
生产就绪的定义在一个实践“谁构建，谁运行”原则的组织中，生产就绪的定义（definition of production readiness DPR）是一个可以支持团队评估和准备新服务上线运营就绪情况的有用技术。DPR 以清单或者模板的形式实现，为团队在新服务投入生产前应该考虑的内容提供指导。尽管 DPR 没有定义要实现的特定服务级别的目标（service-level objectives SLOs）（这些目标很难被一刀切地定义），但它们提醒团队要考虑哪些类别的 SLO ，要遵守哪些组织标准，还有需要哪些文档。DPR 提供了一个输入源，团队将这个输入源转换为各自产品特定的需求，以注入到他们的产品待开发项中例如可观察性和可靠性。DPR 和 Google 的 生产就绪审查 production readiness review (PRR) 密切相关。因组织太小而无法拥有专门的网站可靠性工程团队，或者是担心评审过程可能会给团队上线的流程带来负面影响时，DPR 至少可以为组织提供一些指导，并记录商定好的准则。对于非常关键的新服务，可以在需要时通过 PRR 来添加额外的审查来实现 DPR。
文档象限 在软件开发中，撰写良好的文档总是被忽视的一环，它经常被留到最后被随意地完成。我们的团队发现文档象限是一种确保生成正确文档的便捷方式。该技术沿两个轴对文档进行分类：第一个轴与文档信息的性质有关——实践的或是理论的；第二个轴描述了文档的使用情境——学习或是工作。这样定义的四个象限中就可以放置和帮助人们理解诸如教程、操作指南或参考页面之类的文档。该分类系统不仅可以确保关键文档不会被遗漏，而且还可以指导内容的呈现方式。我们发现这十分有助于创建入门文档，可以让开发人员在加入新团队时快速上手。
重新思考远程站会站会一词源于在每日同步会议期间站起来的想法，目的是缩短会议时间。许多团队在他们的站会中试图遵守的共同原则是: 保持简洁扼要。但我们现在看到一些团队挑战这一原则并重新思考远程站会。在线下协作时，在一天的剩余时间里有很多自发进行相互同步的机会，以此作为短暂站会的补充。而在远程办公时，我们的一些团队正在尝试一种更长的会议形式，类似于Honeycomb 的成员所说的“漫谈式团队同步”。这不是要完全摆脱日常同步。我们仍然认为它非常重要和有价值，尤其对于远程的组织方式而言。相反，我们想把日常同步会议的时间延长至一个小时，用以淘汰一部分团队会议，并使团队联系更紧密。会议中仍然可以包括常用的团队看板审阅，但是也可以加入更细节的澄清讨论，快速决策以及社交时间。只要它可以减少整体会议负担并提升团队凝聚力，就是成功的技巧。
服务器端驱动 UI当汇总新一期技术雷达的时候，我们时常被一种似曾相识的感觉所倾倒。随着开发框架的涌现，服务器端驱动 UI技术引发了一个热议话题。这项技术允许移动端开发者利用更快的变更周期，而不违反应用商店关于重新验证移动应用的任何政策。我们在之前的雷达中从赋能移动开发跨团队扩展的角度介绍过这项技术。服务器端驱动 UI 将渲染分离到移动应用程序的一个通用容器中，而每个视图的结构和数据由服务器提供。这意味着对于过去那些需要经历一次应用商店发布之旅的修改，现在只需要简单改变服务器发送的响应数据即可实现。需要说明的是，我们不推荐对所有 UI 开发都使用这种方式。我们的确陷入过一些可怕的过度配置的困境，但是在 AirBnB 和 Lyft 这样巨头的背书下，我们怀疑不只是我们 Thoughtworks 厌倦了一切交给客户端。这一领域值得关注。
软件物料清单 在保障系统安全性的压力不变且总体安全威胁不减的情况下，一个机器可读的软件物料清单（SBOM）可以帮助团队掌握他们所依赖的库中的安全问题。最近的 Log4Shell 零日远程漏洞十分严重且影响广泛。如果团队准备好了一个 SBOM，它就可以被扫描并被快速修复。现在我们已经具备了在项目中使用 SBOM 的生产经验，项目范围从小型企业到大型跨国公司，甚至是政府部门，而且我们确信它能为我们提供益处。一些工具（例如：Syft ），能够让使用 SBOM 进行漏洞检测变得容易。
策略性复刻策略性复刻是一种有助于代码库重组或从单体代码库迁移到微服务的技术。具体来说，更常见的方式是首先对代码库完全模块化，但在很多情况下会花费很长时间或者很难实现。而策略性复刻则为之提供了一种可能的替代方案。通过这种技术，团队可以创建代码库的新分支，并使用它来处理和抽取某个特定的关注点或领域，同时删除不需要的代码。这种技术的应用可能只是整个单体的长期计划的一部分。
团队的认知负载 系统的架构反映了组织架构和沟通机制。我们应当有意识地关注团队如何互动，这并不是什么大新闻，正如康威逆定律 ( Inverse Conway Maneuver )所描述的那样。团队的交互是影响团队向客户交付价值的速度和容易程度的重要因素。我们很高兴找到一种方法来度量这些交互。我们使用高效能团队模式 ( Team Topologies )的作者提供的评估方法，这种评估方法可以让你理解团队构建、测试和维护其服务的难易程度。通过衡量团队的认知负载，我们能够为客户提供更好的建议，帮助他们改变团队架构，改进团队的互动方式。
过渡架构过渡架构（transitional architecture）在替换遗留系统时是一种有用的做法。就像在建筑物建造或翻新过程中可能会建造、重新配置并最终拆除脚手架一样，在遗留系统迁移中也经常会需要临时架构步骤。尽管过渡架构最终会被移除或替换，但它们并不是一种浪费，这是因为过渡架构可以帮助降低风险，并可以将困难问题的解决分解为较小的步骤。这些较小的临时步骤很难构成一个完善的架构，因此避开了使用“大爆炸”方式替换遗留系统的陷阱。需要注意的是，替换结束后要记得移除架构的“脚手架”以避免它在以后成为技术债。
评估
CUPID你应该如何编写好的代码？如何判断自己是否写了好的代码？作为软件开发者，我们总是在寻找一些自然易记的规则、原则和模式，以便在讨论如何编写简单的、易修改的代码时，我们有统一的语言和价值观。Daniel Terhorst-North最近尝试为好代码创建了一个类似于检查表的东西。他认为与其拘泥于像SOLID 这样一套规则，不如使用一组特性作为目标。他设计出了名为 CUPID 的特性组，来描述为了写出"令人愉悦"的代码，我们需要做出哪些努力：在该特性指导下的代码应该是可组合的，遵循Unix哲学的，可预测的，风格自然的以及基于领域的。
包容性设计我们建议各类组织评估包容性设计，以确保自己将无障碍性视为头等需求。因为大家常常直到软件发布之前，甚至是发布之后，才想起与无障碍性和包容性相关的要求。满足这些要求的成本最低也是最简单的方法，就是将它们完全纳入开发过程并同时向团队提供早期反馈。在过去，我们强调了针对安全性和跨功能需求实施“左移”的技术；关于这种技术的一种观点认为，它与实现无障碍性目标一致。
非集群资源的 Operator 模式除了管理部署在集群上的应用程序，我们看到 Kubernetes Operator 模式越来越多地用于其他地方。非集群资源的 Operator 模式可以利用自定义资源和在 Kubernetes 控制面板中实现的事件驱动调度机制，来管理与集群外部相关的活动。该技术建立在由 Kube 管理的云服务的思想之上，并将其扩展到其他活动中，例如持续部署或者及时响应外部存储库的变化。与专门构建的工具相比，这种技术的一个优势就是它开辟了一系列的工具，这些工具有的是 Kubernetes 自带的，有的则来自更广泛的生态社区。您可以使用 diff 、 dry-run 或 apply 等命令与 Operator 的自定义资源进行交互。Kube 的调度机制消除了以正确顺序编排活动的必要性，从而使开发更容易。如 Crossplane 、 Flux 和 Argo CD 等开源工具都利用了这项技术。随着时间的推移，我们希望看到更多这样的工具出现。我们还观察到的一个现象，虽然每个工具都有自己的适用场景，但它们不可避免的会被误用或过度使用。对此我们有个“老生常谈”：一项工具可以应用在某个场景，并不表示它就应当应用在这个场景。在确认简单的传统方法不适用之前，请不要创建自定义资源定义，因为这会导致额外的复杂性。
无边车服务网格服务网格的通常实现形式为与每个服务实例一并部署的反向代理进程，即“边车 (Sidecar)”。尽管这些“边车”属于轻量级进程，但每个新服务实例的创建都意味着一个“边车”的新增，采用服务网格的整体开销和运维复杂度也会随之增加。然而，随着 eBPF 的发展，我们发现一种被称为无边车服务网格的模式能够将网格的功能安全地下沉到操作系统内核层，从而使得相同节点上的服务可以通过套接字透明地通信，而无需额外的代理。您可以通过Cilium 服务网格对上述模式进行尝试，并从“每个服务一个代理”的部署模式简化为“每个节点一个代理”。我们对 eBPF 的能力十分感兴趣，并发现这一服务网格的演进十分重要且值得评估。
SLSA随着软件复杂性的不断增加，软件依赖项的威胁路径变得越来越难以守护。最近的 Log4J 漏洞表明了解这些依赖关系有多困难——许多没有直接使用 Log4J 的公司在不知不觉中就变得脆弱，因其生态系统中的其他软件依赖于 Log4J。软件工件供应链层级，又称 SLSA（读作 “salsa”），是一个由联盟组织策划的，为组织机构提供防范供应链攻击的指南集。该框架衍生于一个 Google 多年来一直使用的内部指南。值得称赞的是，SLSA 并没有承诺提供“银弹”，即仅使用工具确保供应链安全的方法，而是提供了一个基于成熟度模型的具体威胁和实践的清单。这威胁模型是很容易理解的，其中包含了真实世界发生的攻击实例，并且要求文档中也提供了指南，帮助组织基于日渐增强的稳健性水平为其行动措施排定优先级，以改善他们供应链的安全态势。我们认为 SLSA 提供了适用的建议，并期待更多组织机构从中学习。
流式数据仓库更快地响应客户洞察的需求助推了越来越多事件驱动架构和流式处理技术的采用。例如 Spark、Flink、Kafka Streams 等框架提供了一种范式，让简单事件的消费者和生产者可以在复杂的网络中合作，提供实时的数据洞见。但是这种编程风格需要投入时间和精力去掌握，并且当作为单点应用实现时，会缺乏互通性。这也使得流处理技术的大规模广泛应用需要大量的工程投资。如今，一大批新工具正崭露头角，为日渐庞大的使用 SQL 进行熟练分析的开发者群体提供流处理应用方面的帮助。同时，SQL作为通用流式处理语言的标准化也降低了实现流数据应用的门槛。另外，还有一些工具，如ksqlDB 和 Materialize 有助于将这些独立的应用整合为统一的平台。总而言之，企业中这些基于 SQL 的流处理应用集合可以称为流式数据仓库。
TinyML时至今日，在人们眼中，运行机器学习（ML）模型仍然需要高昂的计算成本，并且在某些情况下还需要使用专用硬件。虽然模型的创建仍然大致属于上述情况，但可以通过一种方式创建模型，使它们能够在小型、低成本和低功耗设备上运行。这种技术被称作 TinyML，它为在看上去不可行的情况下运行 ML 模型开辟了新的可能性。例如，在由电池供电的设备上，或者在受限或不稳定的网络环境中，TinyML 能够使模型运行在本地且不需要高昂的成本。如果你一直在考虑使用 ML 但苦于计算能力或网络环境的限制而放弃，那么这种技术值得你去评估。
暂缓
面向编排的 Azure Data Factory目前，Azure Data Factory 是以 Azure 为主要云供应商的组织用来编排数据处理流水线的默认产品。它支持数据提取、在使用不同存储类型的自有产品或者 Azure 服务之间复制数据，以及执行数据转换逻辑。尽管我们已有足够的经验使用 Azure Data Factory 对简单的自有服务数据进行云迁移，但我们不鼓励使用 Azure Data Factory 来编排复杂的数据处理流水线和工作流。对于使用Azure Data Factory进行系统间的数据迁移，我们已经获得了一些成功案例，但对于更复杂的数据流水线，它仍然存在一些挑战——可调试性和错误报告都不尽人意；可观察性也有限（因为 Azure Data Factory 日志记录功能未与 Azure Data Lake Storage 或 Databricks 等其他产品集成，因此难以实现端到端的观察）；以及只有部分地区能够使用数据源触发机制等。因此，目前我们推荐使用其他开源编排工具（例如 Airflow）来处理复杂的数据流水线，而仅使用 Azure Data Factory 进行数据复制或数据快照。我们的团队会继续使用 Azure Data Factory 来移动和提取数据，但对于更庞杂的操作，我们推荐其他功能更全面的工作流工具。
混杂平台团队平台工程产品团队帮助交付团队自行完成部署和运营，缩短交付周期，降低整体复杂性，因此我们在之前的技术雷达中将它分类为采纳状态，认为它有益于内部平台团队的运营。但不幸的是，我们也看到，那些没有清晰产出或者没有明确用户群的团队也被打上了“平台团队”的标签。于是这些团队不得不面对一堆混杂且毫不相干的系统，在高强度但是优先级不明确的工作中勉强完成交付，变成了所谓的混杂平台团队。它们实际上变相的成为了另一个通用支持团队，解决那些其他团队不适合或者不愿意做的事情。我们仍然坚信，平台工程产品团队只有关注那些清晰并且定义明确的（内部）产品，才能交付更好的产出。
测试环境中的生产数据我们一直认为测试环境中的生产数据是值得关注的领域。首先，它引发了许多最终导致了声誉受损的案例，例如从测试系统向整个客户群发送了不正确的警报。其次，测试系统的安全级别往往较低，尤其是围绕隐私数据的保护。当每个开发和测试人员都可以访问测试数据库中的生产数据副本时，对生产数据访问的精心控制就失去意义了。尽管您可以混淆数据，但这往往仅适用于特定字段，例如信用卡号。最后一点，当从不同国家或地区托管或访问测试系统时，将生产数据复制到测试系统可能会违反隐私法，这在复杂的云部署中尤其麻烦。为解决这些问题，使用假数据是一种更安全的策略。现存的工具也能帮我们创建假数据。在某些场景，例如重现错误或训练特定的机器学习模型时，我们承认确实有复制生产数据特定元素的必要。但我们建议此时一定要谨慎行事。
默认选择SPA通常来说，我们会避免将建议过于浅显的条目放在暂缓状态中，包括那些盲目地遵循一种架构风格却没有注意权衡利弊的条目。然而，团队搭建网站时会默认选择单页面应用(SPA)的普遍现象让我们担心人们甚至没意识到 SPA 原本只是一种架构风格时，就立即进行了项目的框架选型。SPA 会招致传统基于服务器的网站所不具备的复杂性：譬如搜索引擎优化，浏览历史管理，网站分析，首页加载时间等。这些复杂性通常是为了确保用户体验，并且工具的持续发展也使得这些问题更容易解决 (尽管 React 社区有关于状态管理的混乱透露出想要得到一个普适的解决方案是多么的困难)。然而，我们通常看不到团队去进行这种权衡分析，即使是在业务需求不能证明这种使用是合理的情况下，也盲目地接受了默认选择 SPA 的复杂性。事实上，我们已经开始注意到许多新的开发人员甚至都不知道有替代的方法，因为他们整个职业生涯都是在类似 React 这样的框架中度过的。我们相信，许多网站都会受益于服务端逻辑的简洁性，并且我们从例如 Hotwire 这种有助于减少用户体验差异的技术中受到了鼓励。 点击【阅读原文】查看本期技术雷达更多内容。
- 相关阅读 -
第26期技术雷达正式发布！部分内容抢先了解
点击【阅读原文】获取本期完整技术雷达。
本文版权属Thoughtworks公司所有，如需转载请在后台留言联系。
