diff --git a/website/content/zh/wgs/platforms/glossary/_index.md b/website/content/zh/wgs/platforms/glossary/_index.md index cf60aea4..024256e9 100644 --- a/website/content/zh/wgs/platforms/glossary/_index.md +++ b/website/content/zh/wgs/platforms/glossary/_index.md @@ -1,34 +1,43 @@ --- title: 术语表 -description: "平台工作组已发表论文中使用的术语表。" +description: "定义平台工作组使用的关键术语。" --- -另请参见 。 +另可参考：[云原生术语表](https://glossary.cncf.io/) + +如果你希望在平台工作组范围之外引用这些定义，请注意它们是在 CNCF 和应用交付的背景下编写的。 ## 平台 +平台指的是支持开发、部署、运行和/或管理产品与服务交付的功能、文档和工具的集合。平台可以包括门户网站、API、CLI、协议定义、文档、标准和/或黄金路径模板。如果平台做得好，就可以更快、更可靠地交付组织的应用程序和服务。 -平台聚合能力，为开发人员和运营商开发和交付产品、服务和应用程序提供服务。关于它旨在支持的场景，平台可能被命名为“开发人员平台”、“交付平台”、“应用程序平台”甚至是“云平台”。较旧的术语“平台即服务”或 PaaS 的内涵也具有影响力。 +根据平台的不同范围和受众，有时也可称其为“开发者平台”、“内部开发者平台 (IDP)”、“交付平台”、“应用程序平台”，甚至“云平台”。“平台即服务 (PaaS)”一词也常用于描述从组织外部购买或以其他方式采用的平台，它提供了一种可管理性更强但定制化程度较低的平台解决方案。 -## 平台能力提供者 +## 平台工程 +平台工程是关于平台的设计、建设、运营和演进的实践。这种实践可以看成是一种同理心驱动的社会技术组织设计方法1。从该角度来看，这是一个持续的过程，组织通过该过程学习如何以及在何处进行投资，并在内部而不仅仅是外部进行战略性的业务押注。 -平台能力提供者开发和维护平台提供的能力。提供者可以是外部组织或内部团队，能力可以是基础设施、运行时或其他支持服务。 +## 平台团队 +平台团队指的是负责构建和管理平台的人员。平台团队成员包括**平台工程师**，他们专注于建设构成平台体验的工具和功能。平台团队可能包括专门的**平台产品经理**角色，他们专注于满足内部客户需求，同时也支持组织更广泛的战略目标。随着平台的发展，平台团队可能会增加其他专家角色，如运维人员、QA分析人员、UI/UX设计师、技术写作者和开发者布道师。 -## 平台工程师 +## DevOps +“DevOps 是一种方法论，该方法中团队拥有从应用程序开发到生产运维的整个流程。”2 虽然 DevOps 实践可以由团队在不开发专门平台的情况下实施，但将平台工程视为一种通过交付和管理服务于整个组织的统一平台来扩展 DevOps 原则的方法，可能会很有帮助。这种共享平台旨在简化开发、部署和运维流程，为软件交付提供标准化和高效的环境。尽管 DevOps 和平台工程在优化软件交付和运维效能的目标上趋于一致，但平台工程却与众不同地专注于开发有形产品——即平台本身，以促进这些目标的实现。 -平台工程师负责开发和维护界面和工具，以便根据平台产品经理提供的要求和说明，在应用程序中启用平台能力的配置和集成。平台开发人员通常分组在平台团队中。 +## 平台用户 +平台用户是指直接使用平台功能的人员，包括但不限于应用程序开发者、应用程序运维人员、数据科学家、商业采购 (COTS) 软件运维人员和信息员——在平台上运行软件、使用平台提供的功能或需要洞察平台使用情况的人员。平台用户也可能包括在底层功能基础上创建上层平台服务的其他平台工程师。 -## 平台产品经理 +## 门户 +门户指的是基于Web的界面，可集中式访问各种资源、工具和服务。它可以作为更广泛用户的跳板，以便有效地管理底层平台的功能并与之互动。门户网站的存在是为了通过用户友好的界面，简化复杂的流程并提升自助服务能力，从而增强用户体验。 -平台产品经理负责了解平台用户的体验，建立涵盖平台产品差距、需求和机会的路线图，并管理平台团队的日常工作。 +## 平台能力 +平台能力指的是具体的用户价值或者平台提供的**_what_**。这些不应与描述能力**_如何_**体现的平台质量相混淆。这些能力可以处于不同的抽象层次（例如，单一数据库与包含数据库的测试环境），并由不同的供应方提供。随着平台的成熟，它们一般都希望通过自服务来提供能力，从可用能力的可发现性开始，包括不同能力间体验的一致性。能力本身通常相当持久，而供应方及其实现则可能发展得更快。例如，企业不太可能不再需要测试环境，但他们可能会发展到提供容器化解决方案，而不是基于虚拟机的解决方案。 -## 平台团队 +## 平台能力供应方 +这指的是开发和维护平台所提供能力的一组人员。供应方可以是外部组织或内部团队，在较小的组织中，开发更广泛平台的人员自身往往也是供应方。随着平台的成熟，它们可以通过为供应方维护抽象概念来防止锁定，并继续向最薄可行平台（TVP）迈进。 -平台团队负责开发和维护与平台能力的接口和体验，如 Web 门户、自定义 API 和黄金路径模板。平台团队由平台产品经理管理，并涉及平台开发人员。随着平台的发展和越来越先进，其他角色也可以成为平台团队的一部分，包括但不限于运营商、QA 分析师、UI/UX 设计师、技术作家、开发人员倡导者。 +## 平台质量 +平台质量指平台及其能力**_如何**体现，以及在跨功能需求、非功能需求或简单的“功能”方面的预期。例如，管理服务的可靠性或性能可以用服务等级目标（SLO）来衡量；安全性可以用降低已识别风险的时间来衡量；可观测性可以用来调试和报告平台的使用情况。质量常常与能力相混淆，因为有些概念（如可观测性）既可以作为一种能力（如收集应用遥测数据的 OTel 算子），也可以作为一种已声明的质量（如用于测量和预警所提供 OTel 算子正常运行时间的平台指标）。 -## 平台用户 - -平台用户包括但不限于应用程序开发人员和运营人员、数据科学家、COTS 软件操作员和信息工作者 - 在平台上运行软件或使用平台提供的能力的任何人。 +## 认知负荷 +认知负荷是指量化用户从平台功能中获益之前的心理成本。在认知负荷这个总称中，实际上有三种类型的负荷：有效负荷、内在负荷和外在负荷。如果平台能让用户专注于有效负荷（解决工作中的具体问题），同时简化内在负荷（获取新信息或流程以完成任务），并最大限度地减少外在负荷（分散注意力，有时也被戏称为“[牦牛剃须](https://en.wiktionary.org/wiki/yak_shaving#:~:text=yak%20shaving%20(uncountable),to%20solve%20a%20larger%20problem.)”——瞎忙），这样的组织才是最健康的。 ## 最薄可行平台（TVP） - -最薄可行平台（TVP） 是由 Matthew Skelton 和 Manuel Pais 在书籍 *Team Topologies* 中最初定义的一个概念。定义说：“TVP 是在保持平台小的同时确保平台有助于加速和简化团队构建平台的软件交付的谨慎平衡。”。 +TVP 是在 Matthew Skelton 和 Manuel Pais 所著的《团队拓扑》一书中最初被定义的概念，以鼓励企业在小型而有效的平台之间取得谨慎的平衡。这样，企业就能在实现更广泛的业务目标的同时，加速和简化在平台上构建团队的软件交付。他们鼓励平台专注于业务的独特需求，并定期集成第三方能力供应商，以降低平台的复杂性和运营成本。