采纳
将产品管理思维应用于内部平台
我们持续从那些将产品管理思维应用于内部平台的团队获得良好的反馈。不过，要记住一个关键特征：这不只是关于团队结构或重命名已有的平台团队；它还涉及到在团队中应用以产品为中心的工作实践。具体来说，我们收到的反馈表明，除非团队具有以产品为中心的思维方式，否则他们在使用此技术时将面临挑战。这可能意味着需要额外的角色，比如产品经理，以及对其他领域的改变，比如需求收集和对成功的衡量。以这种方式工作意味着与内部消费者（开发团队）建立同理心并且在设计上与他们合作。平台产品经理制定路线图并确保平台为业务带来价值和增强开发人员的体验。我们会继续将这项技术视为构建内部平台的关键，以求快速而高效地推出新数字解决方案。
将 CI/CD 基础设施作为一种服务
将 CI/CD 基础设施作为一种服务已经是很多元化以及成熟的方案，以至于需要自己管理整个 CI 基础设施的情况变得非常少见。使用 GitHub Actions、Azure DevOps 或 Gitlab CI/CD 等管理服务，具有托管云服务的所有常见优势（和权衡）。您不需要花时间、精力和硬件成本来维护和运营这个通常很复杂的基础设施。对于自己托管 CI 设施的公司，虽然团队可以受益于弹性和自助服务，然而往往在配置更多合适的代理或获得新的插件或功能时遇到瓶颈。即使是需要在自己的硬件上运行构建和验证的用例，现在也大多可以用自我托管的运行器来满足需求（我们已经写过一些关于 GitHub Actions 的文章，actions-runner-controller 和 Philips 的自我托管 GitHub 运行器）。然而，请注意，使用托管服务并不意味着您可以轻易获得安全保障；虽然成熟的服务提供了所需要的所有安全功能，但仍然需要实施对 CI/CD 基础架构的零信任安全。
精简软件依赖项
初始工具包和模板被广泛用于软件项目以加快初始设置，但它们可能会为项目引入许多不必要的依赖项。实践依赖裁剪很重要——定期仔细检查这些依赖并剔除未使用的依赖，这有助于减少构建和部署时间，并且可以通过移除潜在漏洞来降低项目受攻击的风险。尽管这不是一项新技术，但鉴于对软件上下游的攻击频率越来越高，我们提倡重新关注它。
将运行成本作为架构健康度的考量
自动估算、跟踪和预测云基础设施运行成本对于今天的组织至关重要。云服务商精心设计的定价模型，加上价格参数的不断增多以及持续变化的架构，可能会导致运行成本超出预算。尽管这种技术已经在2019年后被采用，我们仍然想强调考虑将运行成本作为架构健康度的考量 的重要性，特别是在云服务被广泛采用和 FinOps 实践越来越受到关注的今天。许多商业平台提供了工具来协助企业的负责人人整合并说明云服务的成本。其中一些旨在向财务机构或原始业务单位显示云服务运行成本。然而，云服务消费决策通常是在系统设计时做出。因此在做出设计决策时使用一些方法来预测其架构决策对成本产生的影响就显得很重要。一些团队会在开发进程的初期通过自动化方式预算成本。像 Infracost 这样的工具可以帮助团队在考虑更改“基础设施即代码”时预测成本影响，这种计算可以自动化执行，并纳入持续集成（CD）流程中。请注意，成本将受架构决策和实际使用水平的影响；要做到这一点，您需要对期望使用水平进行审慎地预测。及早和频繁地反馈运行成本可以防止其失控。当预测成本偏离了预期或可接受的范围时，团队可以讨论是否是时候进一步调整架构了。
试验
设计中的无障碍注解
在软件交付中越早考虑无障碍，就能越简单、更低成本的保证交付物对尽可能多的人可用。设计中的无障碍注释工具能促进沟通，帮助团队从工作的开始就考虑到文档结构、语义化的 HTML 和替代文本等重要的元素。这使得团队确保用户界面符合国际无障碍标准，并解决那些实际上很容易避免的常见无障碍问题。Figma 提供了一系列的无障碍性注释插件：The A11y Annotation Kit, Twitter 的 Accessibility Annotation Library和 Axe 的工具集 Axe for Designers。
有限界的使用低代码平台
我们一直倡导写尽可能少的代码。简洁是我们在软件开发时笃信的核心价值之一。例如，我们尽量不预测未来的需求，只实现满足当前业务需求的代码，而不考虑其他内容。创建工程平台是一个在组织层面上实现这个目标的可能方法。
这也是现在许多流行的低代码平台的既定目标。像 Mendix 或 Microsoft Power Apps 这些平台可以展示通用的业务流程以方便重复使用，并简化了部署新功能和交付给用户的问题。近年来，这些平台在可测试性和对良好工程实践的支持方面取得了巨大的进步。它们特别适用于简单的任务或事件触发的应用程序。然而，要求它们适应几乎无限的业务需求会带来复杂性。虽然开发人员可能会少写（或不写）代码，但他们也必须成为一个全面的商业平台的专家。我们建议企业考虑他们是否需要这些产品带来的所有功能，或者他们是否更应该追求限界的低代码平台，无论是开发自己的作为内部产品的平台，还是通过谨慎限制商业低代码平台的使用范围，使其仅限完成于它们擅长的简单任务。
对仅提供 API 的产品的演示前端
捕捉并传达 API 的业务价值是开发 API 时的一大挑战。就其本质而言，API 是一种技术产品。尽管开发人员可以轻松理解 JSON 数据、OpenAPI (Swagger) 规范和 Postman 演示，但业务利益相关者会更倾向于可交互的 API 产品演示。通常当我们能够实际看到并亲身体验产品时，产品的价值会更加清晰地表达出来。也正是因为这样，我们有时会认为投资 对仅提供API的产品的演示前端 是值得的。当定制化界面 UI 与 API 产品一起构建时，业务利益相关者可以将产品与他们可能更熟悉的纸质表格或报告进行类比。随着交互模型和 UI 演示的丰富性不断发展，业务利益相关者可以对 API 产品的发展方向做出更明智的决策。基于 UI 工作也有额外的益处，它可以增加开发人员对业务用户的同理心。虽然 API 产品的演示前端 并不是一项新技术——当 API 产品出现时，我们就能在必要时构建演示前端 。然而，由于这项技术并不广为人知，我们仍然认为该技术值得关注。
Lakehouse 架构
Lakehouse（数据湖仓一体）架构 是一种数据湖的可扩展性与数据仓库可靠性和性能相结合的架构风格，它使得组织能在一个平台上使用类似于 SQL 的工具和技术，储存分析大量不同的数据，而不是将他们放在单独的在数据湖和数据仓库层中。尽管这个术语(LakeHouse)经常与作为供应商的 Databricks 之类的厂商有关，像 Delta Lake， Apache Iceberg 和 Apache Hudi 之类的开源方案也值得考虑。Lakehouse 架构可以补充 数据网格 的实现。自治的数据产品团队可以在他们的数据产品选择使用 Lakehouse。
可验证凭证
三年前，当我们第一次在雷达中提及可验证凭证（VC）时， 它是一个引人注目的标准，有着一些潜在的应用前景，但在爱好者群体之外并没有广为人知。对于如州政府等负责实施该标准的证书授予机构，情况更是如此。三年疫情之后，随着加密安全、尊重隐私和机器可验证电子证书的需求增长，政府开始意识到可验证凭证的潜力。W3C 标准以凭证持有者为中心，这与我们使用物理凭证时的体验相似：用户可以将他们可验证的凭证放到自己的数字钱包中，并在任何时候向任何人展示，而无需得到凭证发行者的许可。这种去中心化的方式有助于用户更好地管理和有选择地披露自己的信息，大大提高了数据隐私的保护。在过去的 6 个月里，我们的一些团队参与了使用可验证凭证技术的项目。毫不意外，不同国家和政府部门的情况并不相同。我们的团队在多个项目上探索了去中心化标识、可验证凭证和可验证展示的不同组合。这是一个仍在发展的领域，现在我们有了更多的经验，我们希望在雷达中持续跟踪它。
评估
无障碍意识的组件测试设计
在软件交付过程中，需要提早考虑无障碍设计的地方有很多，Web 组件测试是其中环节之一。像 chai-a11y-axe 这样的测试框架插件在其 API 中提供了断言，以检查基本的无障碍设计。但是，除了使用测试框架所提供的功能外，无障碍意识组件测试设计进一步提供了屏幕阅读器和其他辅助技术所需的所有语义元素。
首先，不要使用 test id 或 class 来寻找和选择你要验证的元素，而是使用通过 ARIA 角色或其他辅助技术使用的语义属性来识别元素。一些测试库，如 Testing Library ，甚至在文档中直接推荐这样做。其次，不要只测试点击交互，还要考虑不能使用鼠标或看不到屏幕的用户，并考虑增加对键盘和其他交互的测试。
基于 AI 辅助的测试驱动开发
和软件行业的许多人一样，我们一直在探索快速演进的 AI 工具，以帮助我们编写代码。我们看到很多人通过将实现代码输入 ChatGPT，然后请求其生成测试代码。但作为 TDD（测试驱动开发）的坚定支持者，我们并不想经常将可能包含敏感信息的实现代码输入到外部模型中，因此我们尝试了基于 AI 辅助的测试驱动开发的技术。在这种方法中，我们让 ChatGPT 为我们生成测试代码，然后由开发人员来实现功能。具体而言，我们首先在一个可在多个用例中重复使用的提示“片段”中描述我们使用的技术栈和设计模式。然后，我们描述我们想要实现的具体功能，包括验收标准。基于这些信息，我们要求 ChatGPT 生成在我们的架构风格和技术栈中实现这一功能的实现计划。一旦我们对这个实现计划进行了合理性检查，我们就要求它为我们的验收标准生成测试代码。
这种方法对我们来说效果出奇的好：它要求团队提供对其架构风格的简明描述，帮助初级开发人员和新团队成员编写符合团队现有风格的功能特性。这种方法的主要缺点是，尽管我们没有向模型提供源代码，但我们仍然向其输入了可能包含敏感信息的技术栈和功能描述。至少在这些AI工具的“商业版”面世之前，团队应确保与法律顾问合作，以避免任何知识产权问题。
领域特定的大型语言模型
在之前的技术雷达中，我们已经提到过 BERT 和 ERNIE 之类的大型语言模型 (LLMs)；但是领域特定的大型语言模型是一个新兴的趋势。使用领域特定数据对通用大型语言模型进行微调能将它们用于各种各样的任务，包括信息查询，增强用户支持和内容创作。这种实践已经在法律和金融领域展现出现它的潜力，例如使用 OpenNYAI 进行法律文书分析。随着越来越多的组织开始对大型语言模型进行试验和越来越多像 GPT-4 这样的新模型的发布，我们预期大型语言模型在不久的将来会有更多领域特定的用例。但是使用大型语言模型仍面临许多挑战和缺陷。首先，大型语言模型能”很自信地犯错”，所以需要构建一些机制来保证结果的准确性。其次，第三方大型语言模型可能保留或二次分享你的数据，这会对保密信息和数据的所有权带来风险。组织应当仔细审阅使用条款和供应商的可信度，或考虑在自己控制的基础设施上训练和运行大型语言模型。就像其他的新技术一样，在业务上使用大语言模型前需要保持谨慎，并理解采用大型语言模型带来的后果和风险。
智能引导无障碍测试
对于从未使用过辅助技术，并且觉得对像 Web内容无障碍指南 (WCAG) 这样的标准仍然一无所知的人来说，使网页应用程序兼容辅助技术可能会有些困难。智能辅助无障碍测试是这样一类可以帮助测试已正确实现无障碍设计的工具，而无需成为无障碍技术专家。这些工具是浏览器扩展，它们会扫描网站，总结辅助技术会如何解释网页，然后通过一组问题以确认您创建的结构和元素是否符合预期。我们已经在一些项目中使用过 axe DevTools、Web Accessibility Insights for Web 或 ARC Toolkit 等工具。
使用 Logseq 构建团队知识库
团队知识管理是一个熟悉的概念，团队使用诸如维基（wikis）等工具来存储信息和培训新团队成员。我们的一些团队现在更倾向于将 Logseq 作为团队知识库。Logseq 是一种开源的知识管理系统，由图形数据库驱动，帮助用户组织想法、笔记和创意，并可以通过基于 Git 的存储方式适应团队使用。Logseq 允许团队构建一个公开透明的知识库，为每个成员提供个性化的学习路径，促进高效的启动培训。然而，与任何知识管理工具一样，团队需要对他们的知识库进行良好的归纳整理，以避免信息过载或组织混乱。
虽然类似的功能也可以在像 Obsidian 这样的工具中找到，但 Logseq 的关键区别在于其注重于知识的使用，基于段落的链接使团队成员能够快速找到相关的上下文，而无需阅读整篇文章。
提示工程
提示工程（Prompt engineering）指的是为生成式 AI 模型设计和优化提示的过程，以获得高质量的模型响应。这个过程包括精心设计特定、清晰易懂和与所需任务或应用相关的提示，以引导模型输出有用的结果。提示工程旨在增强大型语言模型（LLM）在问题回答、算术推理任务或特定领域上下文中的能力。在软件开发中，我们可以使用提示工程让 LLM 根据与利益相关者的简要对话或一些笔记撰写故事、API 或测试套件。培养有效的提示技巧正在成为处理人工智能系统的重要技能。提示工程被一些人认为是一门艺术，而另一些人则认为它是一门科学。同时我们也需要考虑到其潜在的安全风险，例如“提示注入攻击”。
测试基础设施时的可达性分析
在部署基础设施代码时，我们发现很多时间会花费在诊断和修复因系统之间无法相互通信导致的生产问题上。由于它们之间的网络拓扑结构可能非常复杂，即使已经正确配置了单个端口和端点，整个路由也可能无法完全遍历。基础设施测试实践通常包括验证正确的端口是开放还是关闭，或者某个端点是否可以被访问，但我们最近才开始在测试基础设施时进行可达性分析。该分析通常涉及比简单的是/否判断更多的内容。例如，工具可能会遍历并报告通过中转网关的多个路由。此技术得到了所有主要云供应商工具的支持。Azure 有一个名为网络观察程序的服务，可以在自动化测试中进行脚本编写，而 GCP 则支持连通性测试。而现在，在 AWS 中，您可以测试同一组织内跨账户的可达性。
自托管式大型语言模型
大型语言模型通常会运行在具有强大的 GPU 的基础设施上。我们如今可以看到一些大型语言模型的移植版本，比如 llama.cpp，这些模型能在不同的硬件上运行，包括 Raspberry Pi(树莓派)、笔记本电脑和通用服务器等。因此自托管式大型语言模型已经成为现实。目前，有许多开源的自托管式大型语言模型，如 GPT-J、GPT-JT和 LLaMA。自托管这种方式有许多好处，比如可以更好地控制模型在一些特定使用场景的微调、提高安全性和隐私性，以及支持离线访问。不过在决定使用自托管这种方式之前，您应该仔细评估组织的能力和运行此类大型语言模型需要消耗的成本。
管理技术健康状况优先于技术债务
在软件交付组织中，如何管理技术债务是一个经久不衰的话题。哪些是技术债务而哪些不是？如何确定它的优先级？最重要的是，如何向内部利益相关者展示偿还技术债务的价值？遵循敏捷宣言的推理方式——“尽管右项有其价值，我们更重视左项的价值”，我们喜欢“管理技术健康状况优先于技术债务”的想法。澳大利亚的 REA 团队分享了一个很好的案例，介绍了他们如何追踪管理开发、运维和架构三个方面的系统健康状况。
将关注点放在技术健康状况而非技术债务上更有建设性。这样将团队与减少技术债务的最终价值联系起来，并帮助团队确定优先级。理想情况下，每个被解决的技术债务都应与某项已达成共识的期望相关联。团队应将技术健康状况评级与其他服务级别目标 (SLO) 一样对待，并在某个类别的健康评级跌出“安全区域”时优先进行改进。
CI/CD 的零信任保护
如果没有得到正确的安全配置，运行构建和交付的流水线的基础设施和工具可能成为一个大麻烦。流水线需要访问关键数据和系统比如源代码，凭证和密码来构建和部署软件。这让这些系统非常容易吸引恶意攻击者。因此，我们强烈推荐引入零信任安全机制来保障 CI/CD 流水线和基础设施 —— 尽可能少地信赖它们。这包含一系列技术：如果可行，根据你的云供应商通过联合身份校验机制如 OIDC 来验证你的流水线，而不是直接给他们获取机密数据的权限。实现最小特权原则，最小化个人用户和执行账户的权限，而不是创建一个拥有无限访问权限的全能账户。用临时的方式去使用任务执行器而不是复用他们，来减少暴露先前任务的秘密或在受到攻击的运行器上运行任务的风险。保证软件在你的代理服务器和任务执行器上是最新的。像监控你的生产环境软件一样监控你的 CI/CD 系统的完整性，保密性和可用性。我们不断见到有团队会忘记这些实践，特别是当他们使用在内网自我管理的 CI/CD 基础设施的时候。所有这些实践在不仅在内网中都很重要，在使用托管服务时，因为扩大了攻击面和影响范围，这种实践会变得更加重要。
暂缓
对 Webhooks 的管理不够严谨
随着远程工作的增加，聊天协作平台和 ChatOps的采用也在增加。这些平台通常提供Webhook(网络挂钩)作为自动发送消息和通知的简单方式，但我们关注到一个令人担忧的趋势：对Webhooks的管理不够严谨—将它们视为配置而不是秘密或凭据。这可能会导致钓鱼攻击和内部信息泄露。
Webhook 是提供对内部空间的特权访问的凭据，可能包含可以轻松提取和直接使用的 API 密钥。不将它们视为密钥会导致钓鱼攻击的发生。在 Git 仓库中的Webhook可以轻松提取并用于发送有效的欺诈信息，用户可能没有任何身份验证的方式。为了缓解这种威胁，处理Webhook的团队需要改变他们的习惯，并将Webhook视为敏感凭据。软件开发人员与 ChatOps 平台构建集成必须注意到这种风险，确保这些Webhook具备适当的安全措施。
Lambda 弹球
虽然无服务器架构对解决一些问题非常有用，但它们确实有一定的复杂性，尤其是当它们涉及到复杂执行和跨多个相互依赖的 Lambdas 的数据流时--这有时会导致所谓的 Lambda 弹球架构。我们团队发现维护和测试 Lambda 弹球架构可能非常有挑战：理解基础设施、部署、诊断和调试都会变得困难。在代码层面上，根本不可能将领域概念和所涉及的多个 Lambdas 之间做简单映射，这使得任何改变和添加都具有挑战。尽管我们相信无服务器是适合某些问题和领域的，但它并不是每个问题的 "万能解法"，这就是为什么你应该尽量避免陷入 Lambda 弹球。一种有助于解决这个问题的方法，就是区分公共接口（public interface）和已发布接口（published interface），并在它们之间应用带有已发布接口的领域边界。
竭尽全力的计划
虽然在产品管理社区中，应该预留一些交付能力余量是众所周知的，但我们发现仍然有许多团队会为团队制订竭尽全力的计划。在迭代计划中预留一定的产能，往往可以提高可预测性以及更好的质量。因为这不仅有助于增强团队应对意外事件（如疾病、生产问题、意外的产品请求和技术债务）的弹性，还让团队可以进行提升生产力的活动，比如团队建设和创意构思，从而推动产品创新。留有一定的交付余量，可以让团队更加专注于所生产的软件的健壮性，并更加关注正确的度量信息。我们的经验表明，就像高速公路的车辆过多就会导致缓慢而令人沮丧的交通一样，充分利用团队的能力往往会导致生产效率的崩溃。当我们的一个团队需要处理不可预测的支持请求时，他们只按照开发能力的2/3来计划功能交付的速度，从而增加了25%的交付量，并减少了50%的周期时间波动。
