Enable javascript in your browser for better experience. Need to know to enable it? Go here.

技术

采纳 ?

  • 为了度量软件交付的效能,越来越多的组织开始采用由DORA 研究项目定义的 交付核心四指标 ,即:更改前置时间、部署频率、平均修复时间( MTTR )和变更失败率。这项研究及其统计分析展示了高效能交付团队和这些指标的高度相关性,它们为衡量一个团队、甚至整个交付组织的表现提供了极佳的领先指标。

    虽然我们仍是这些指标的支持者,但自从我们最早开始监控它们以来,也得到了一些教训。我们也持续看到被误导的度量方式,这些方式使用的工具仅基于持续交付( CD )流水线。在衡量稳定性指标( MTTR 和更改失败百分比)时,仅依赖 CD 流水线数据提供的信息并不足以确定部署失败对真实用户的影响。 只有包含真实事故(如用户服务降级)的数据时,稳定性指标才有意义。

    与其它所有指标一样,我们建议始终牢记度量这些指标的终极目的,并使用它们反复思考和学习。例如,在花费数周时间构建复杂仪表板工具之前,可以考虑定期在团队回顾会议当中进行 DORA 快速检查。这样的做法能够使团队有机会思考哪些能力应被提升以改进这些指标,这比过于详细的开箱即用工具更有效。

  • 我们继续将 平台工程产品团队 视为默认团队配置,关键在于是他们只是一个专注于内部平台客户的产品团队。因此,在使用与任何其他(以外部为重点的)产品团队相同的工程学科和工作方式的同时,明确定义客户和产品至关重要;平台团队在这方面并不特殊。我们强烈警告不要只将现有的内部团队重命名为“平台团队”,而同时保持工作方式和组织结构不变。在考虑如何最好地组织平台团队时,我们仍然非常喜欢使用团队拓扑中的概念。我们认为平台工程产品团队是一种标准方法,也是高性能 IT 的重要推动者。

  • 我们总是听闻企业发现由于过度依赖“安全”的网络边界,他们的安全性受到严重损害。一旦这个外部边界被攻破,内部系统就会变得欠缺保护,攻击者能够快速而轻松地部署自动数据提取工具和勒索软件,而这些攻击往往在很长一段时间内都不会被察觉。这使我们认为推荐 零信任架构 (ZTA)作为默认方案是一个明智之选。

    ZTA是安全架构和策略的一个范式转变。它基于这样的假设:网络边界不再代表安全边界,同时不应仅仅根据用户或服务的物理或网络位置来予以盲目的信任。可用于实现ZTA各方面的资源、工具和平台的数量不断增加:包括基于最小特权与尽可能细化的原则,还有以持续监控与自动减轻威胁的方式执行安全策略即代码;通过运用服务网格去执行应用到服务与服务到服务的安全控制;通过实现二进制证文去验证二进制执行文件的来源;除了传统的加密方式之外,该架构还添加了安全隔离区去加强数据安全的三大支柱:数据在传输、存储和内存中的安全。关于该主题的介绍,请参考NIST ZTA的出版物和谷歌关于BeyondProd的白皮书。

试验 ?

  • 尽管 CBOR 协议并不是什么新鲜事物,然而我们发现越来越多的数据交换场景都在使用它,尤其是在多种类型的应用程序需要互相通信的时候,比如服务与服务之间、浏览器与服务之间等等。Borer 是 CBOR 编码器/解码器的 Scala 实现,它允许互相通信的两端通过协商自由选择二进制或者传统 JSON 作为消息格式,这一点我们认为非常有用。同样的消息,既能够以普通文本在浏览器里显示,又能够表示为精简高效的二进制,这是非常实用的特性。在未来,随着物联网、边缘计算以及其他受限环境计算的逐渐兴起,我们认为 CBOR/JSON 混合协议会更加流行。

  • 我们越来越多地看到数据驱动的组织想要实现的目标,与当前数据架构和组织结构所允许的目标是不匹配的。组织希望将数据驱动决策、机器学习和分析嵌入到其产品和服务以及内部运营的许多方面中;从本质上讲,他们希望通过数据驱动的智能来增强其运营环境的各个方面。然而,在我们可以嵌入分析数据、访问并在业务领域和运营中管理这些数据之前,还有很长的路要走。现在,管理分析数据的各个方面,都被外部化到运营业务领域之外的数据团队和数据管理单体:数据湖和数据仓库。数据网格 用于消除分析数据和业务运营的二分法,是一种去中心化的社会技术方法。其目标是将分析数据的共享和使用嵌入运营业务的各个领域,并缩小运营和分析平台之间的差距。它建立在四个原则之上: 域数据所有权、数据即产品、自助数据平台和计算联合治理。

    我们的团队一直在实施数据网格架构;他们创建了新的架构抽象,例如数据产品量子,可以将代码、数据和策略作为分析数据共享的自治单元进行封装,嵌入到运营域中;他们还构建了自助数据平台功能,以声明方式管理数据产品量子的生命周期,如数据网格。尽管我们的技术取得了进步,但仍然在数据网格拓扑中使用现有技术时遇到了阻力,更不用说在某些组织中,将共享和使用数据作为业务领域的首要职责时所遭遇的抵抗。

  • 活文档来自行为驱动开发 (BDD) 社区,通常被视作有可执行规范且维护良好的代码库的“专利”。如今我们发现这种技术也可以应用于遗留系统。团队在进行系统现代化改造时,时常受限于缺乏业务知识。由于人员流动以及现有文档已经过时,代码成了唯一可靠的依据。因此当我们接管遗留系统时,如何重新建立文档与代码间的关联,以及如何在团队中传播业务知识变得尤为重要。在实践中,我们会首先尝试对代码进行简单的清理和安全的重构,以此加深我们对业务的理解。在此过程中,我们需要向代码添加注释,以便随后自动生成活文档。这与在全新项目中使用 BDD 非常不同,但对于遗留系统来说这是个良好的开端。根据生成的文档,我们可以进一步将一些规范转换为可执行的高阶自动化测试。反复执行此操作后,最终可以获得一份与代码密切相关并且部分可执行的 遗留系统的活文档

  • 自2016年雷达介绍了微前端以来,我们已经看到其在 Web UI 中得到了广泛应用。然而,最近我们发现不少项目也将这种架构风格扩展到了移动应用程序中,亦可称其为移动微前端。当应用程序变得足够庞大且复杂时,有必要将其开发分布在多个团队中。如此一来,在保证团队自治的同时,还要将他们的工作集成到单个应用中是很有挑战的。 有的团队在编写自己的框架来支持这种开发风格,过去我们提到过 Atlas 和 Beehive 可以作为可行框架以简化多团队应用开发的集成问题。最近我们看到有的团队亦使用 React Native 达成了此目标。各个 React Native 微前端在各自的代码仓库中保存,以支持独立的编译、测试和部署。负责整体应用的团队则将各个团队构建的微前端统一集成到发布版本中。

  • 我们持续看到许多团队在工作中远程协作。对于这些团队来说, 远程集体编程 是一种值得尝试的技术。远程集体编程允许团队成员快速“蜂拥”在一个问题或者一小段代码周围,不用受多个人挤在一张办公桌前这种物理限制。团队可以对一个问题或者一段代码,使用其选择的视频会议工具进行快速地协作,而无需连接到一个大型显示器,预定会议室或者找一个白板。

  • 随着远程分布式工作的团队越来越多,我们察觉到人们遗漏了一样东西——物理团队墙。它能统一显示各种故事卡、任务、状态和进度,在团队中充当信息辐射器和信息枢纽。通常来说,团队墙仅仅作为一个集成点,实际的数据存储在各种不同的系统中。而随着团队越来越远程化,我们不得不回归在各个信息源系统中查看所需信息的模式,很难再通过团队墙一目了然地了解项目。 统一远程团队墙 是一项重新引入虚拟团队墙的简单技术。与它为团队带来的益处相比,我们认为值得花费一定开销来保持团队墙的更新。对于一些团队来说,更新物理墙是日常“仪式”的一部分,远程墙也可以做到这一点。

  • 系统的架构反映了组织架构和沟通机制。我们应当有意识地关注团队如何互动,这并不是什么大新闻,正如康威逆定律 ( Inverse Conway Maneuver )所描述的那样。团队的交互是影响团队向客户交付价值的速度和容易程度的重要因素。我们很高兴找到一种方法来度量这些交互。我们使用高效能团队模式 ( Team Topologies )的作者提供的评估方法,这种评估方法可以让你理解团队构建、测试和维护其服务的难易程度。通过衡量 团队的认知负载 ,我们能够为客户提供更好的建议,帮助他们改变团队架构,改进团队的互动方式。

评估 ?

  • 许多增强现实(AR)应用需要获得用户设备的位置和方向,为此,它们一般会使用基于 GPS 的方案,但 空间定位点 这一新技术也值得考虑。这一技术利用设备摄像头记录视觉图像,通过图像的特征点以及它们在 3D 空间中的相对位置来识别其在真实世界中的位置,然后在 AR 空间中创建相应的定位点。虽然空间定位点无法取代所有基于 GPS 和标记的定位点,但它们确实比大多数基于 GPS 的方案精度更高,也比基于标记的定位点更能适应不同的视角。目前,我们只使用过 Google 的 Android 云定位点 服务,它确实很有效。此外,Google 还一反常态地推出了 iOS 云定位点 服务,而微软的 Azure 空间定位点 服务甚至支持更多的平台。

  • 继成功发布服务器端 Email 应用 HEY 之后, Basecamp 对外公布,他们于今年夏天将旗舰产品 Basecamp 3 迁移到了 Hotwire 。当很多组织越来越多地把单页应用(SPAs)作为新 Web 开发的首选,我们非常兴奋地看到 Hotwire 一直在逆流而上。和单页应用(SPAs)不同, Hotwire 应用程序的绝大部分业务逻辑和界面导航都在服务器端运行,只有很少量的 JavaScript 在浏览器上运行。 Hotwire 把 HTML 页面模块化为组件(称为 Turbo Frames ),这些组件支持延迟加载,有相互独立的上下文,能够基于用户行为修改上下文从而更新 HTML 页面。单页应用(SPAs)提供无可否认的用户响应能力,但是把传统服务器端 Web 编程的简单性与现代浏览器工具相结合,为平衡开发人员效率和用户响应能力提供了一种令人耳目一新的方式。

  • 除了管理部署在集群上的应用程序,我们看到 Kubernetes Operator 模式越来越多地用于其他地方。非集群资源的 Operator 模式可以利用自定义资源和在 Kubernetes 控制面板中实现的事件驱动调度机制,来管理与集群外部相关的活动。该技术建立在由 Kube 管理的云服务的思想之上,并将其扩展到其他活动,例如持续部署或者及时响应外部存储库的变化。与专门构建的工具相比,这种技术的一个优势就是它开辟了一系列的工具,这些工具有的是 Kubernetes 自带的,有的则来自更广泛的生态社区。您可以使用 diffdry-runapply 等命令与 Operator 的自定义资源进行交互。Kube的调度机制消除了以正确顺序编排活动的必要性,从而使开发更容易。如 CrossplaneFluxArgoCD 等开源工具都利用了这项技术。随着时间的推移,我们希望看到更多这样的工具出现。

  • 我们观察到远程协作工具的持续创新。Slack新增的 Huddles 特性提供了类似Discord的持久化语音通话,供用户随时加入或退出。 Gather 提供了一种有创意的方式,通过头像和视频模拟虚拟办公室。很多集成开发环境 (IDE) 为结对编程和调试提供了直接的协作功能:我们之前列举了 Visual Studio Live Share ,并在本期当中包含了 JetBrains Code With Me 。由于包括视频会议在内的工具持续地演化协作方式,我们看到参与 远程自发技术讨论 的团队数量与日俱增,重新创造了非正式对话的自发性,而非预定 Zoom 或 Microsoft Teams 会议的意向性。我们并不期待通过数字化工具完全重建面对面交流的丰富性,但我们确实看到,通过为团队提供多种协作渠道而非依赖一套工具链的方式,提升了远程团队的效率。

  • 2021年5月,美国白宫发布了《关于改善国家网络安全的行政命令》。该文件提出了一些与我们在过去的技术雷达中展示的项目相关的技术要求,例如零信任架构以及使用安全策略即代码的自动合规性扫描。该文档的大部分内容都致力于提高软件供应链的安全性。特别引起我们注意的一项是要求政府软件应包含机器可读的软件物料清单 (SBOM),它被定义为“包含构建软件使用的各种组件的详细信息和供应链关系的正式记录”。换句话说,它不仅应该详细说明交付的组件,还应该详细说明用于交付软件的工具和框架。这一秩序有可能开启软件开发透明和开放的新时代。这无疑会对以软件为生的我们产生影响。即使不是全部,今天生产的绝大部分软件产品都包含或在构建过程中使用了开源组件。通常,消费者无法得知哪个版本的软件包可能会影响其产品的安全性。于是他们不得不依赖零售供应商提供的安全警报和补丁。该行政命令确保向消费者提供所有组件的明确描述,使他们能够实施自己的安全控制方案。由于 SBOM 是机器可读的,这些控制可以自动化。从这一举措我们感受到了向拥抱开源软件的转变,在享受开源的同时我们也会实际解决它带来的安全风险。

暂缓 ?

  • 一些组织似乎觉得Pull request 等同于代码同行评审。他们认为唯一能够实现代码同行评审的方法就是 Pull request 。我们发现这种方法会造成严重的团队瓶颈,并且显著地降低反馈的质量,因为超负荷的评审人员会开始简单地拒绝 Pull requests 。虽然有观点认为,这是一种展示代码评审强制性的方式,但是我们的一个客户被告知,这种观点没有任何的依据,因为没有证据能够表明代码在接受之前被任何人实际阅读过。Pull requests 只是管理代码评审工作流的一种方式,我们敦促人们考虑其它的方法,特别是在需要仔细提供指导和反馈的情况下。

  • 我们一直认为 测试环境中的生产数据 是值得关注的领域。首先,它引发了许多最终导致了声誉受损的案例,例如从测试系统向整个客户群发送了不正确的警报。其次,测试系统的安全级别往往较低,尤其是围绕隐私数据的保护。当每个开发和测试人员都可以访问测试数据库中的生产数据副本时,对生产数据访问的精心控制就失去意义了。尽管您可以混淆数据,但这往往仅适用于特定字段,例如信用卡号。最后一点,当从不同国家或地区托管或访问测试系统时,将生产数据复制到测试系统可能会违反隐私法,这在复杂的云部署中尤其麻烦。为解决这些问题,使用假数据是一种更安全的策略。现存的工具也能帮我们创建假数据。在某些场景,例如重现错误或训练特定的机器学习模型时,我们承认确实有复制生产数据特定元素的必要。但我们建议此时一定要谨慎行事。

 
新建
移进/移出
没有变化

无法找到需要的信息?

 

每期技术雷达中的条目都在试图反映我们在过去六个月中的技术洞见,或许你所搜索的内容已经在前几期中出现过。由于我们有太多想要谈论的内容,有时候不得不剔除一些长期没有发生变化的条目。技术雷达来自于我们的主观经验,而非全面的市场分析,所以你可能会找不到自己最在意的技术条目。

无法找到需要的信息?

 

每期技术雷达中的条目都在试图反映我们在过去六个月中的技术洞见,或许你所搜索的内容已经在前几期中出现过。由于我们有太多想要谈论的内容,有时候不得不剔除一些长期没有发生变化的条目。技术雷达来自于我们的主观经验,而非全面的市场分析,所以你可能会找不到自己最在意的技术条目。

Radar

下载第25期技术雷达

English | Español | Português | 中文

Radar

获取最新技术洞见

 

立即订阅

查看存档并阅读往期内容