AWS规范性指导词汇表 - AWS规范性指导

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

AWS规范性指导词汇表

以下是AWS规范性指南提供的策略、指南和模式中的常用术语。要建议条目,请使用词汇表末尾的提供反馈链接。

移民条款

7 卢比

将应用程序迁移到云端的七种常见迁移策略。这些战略建立在 Gartner 在 2011 年确立的 5 R 基础上,包括以下内容:

  • Refactor/Re-Architect — 通过充分利用云原生功能来移动应用程序并修改其架构,以提高敏捷性、性能和可扩展性。这通常涉及移植操作系统和数据库。示例:将您的本地 Oracle 数据库迁移到亚马逊 Aurora PostgreSQL 兼容版本。

  • 重塑平台(提升和重塑)— 将应用程序迁移到云端,并引入一定程度的优化以利用云功能。示例:将您的本地 Oracle 数据库迁移到AWS云中 Oracle 的亚马逊关系数据库服务 (亚马逊 RDS)。

  • 回购(直接购买)— 切换到其他产品,通常是从传统许可证转向 SaaS 模式。示例:将您的客户关系管理 (CRM) 系统迁移到 Salesforce.com。

  • 重新托管(提起并移动)— 无需进行任何更改即可将应用程序迁移到云端,以利用云功能。示例:将您的本地 Oracle 数据库迁移到AWS云中的 EC2 实例上的 Oracle。

  • 搬迁(虚拟机管理程序级别的提升和迁移)— 无需购买新硬件、重写应用程序或修改现有操作即可将基础架构迁移到云端。此迁移场景特定于 VMware Cloud onAWS,它支持本地环境和之间的虚拟机 (VM) 兼容性和工作负载可移植性。AWS将基础架构迁移到 VMware Cloud 时,您可以使用本地数据中心的 VMware Cloud Foundation 技术AWS。示例:将托管您的 Oracle 数据库的虚拟机管理程序迁移到 VMware 云上。AWS

  • 保留(重新访问)-将应用程序保留在源环境中。其中可能包括需要进行重大重构且您想将这项工作推迟到以后再进行的应用程序,以及您想要保留的传统应用程序,因为迁移这些应用程序没有商业上的理由。

  • 停用-停用或删除源环境中不再需要的应用程序。

主动-主动迁移

一种数据库迁移方法,在这种方法中,源数据库和目标数据库保持同步(通过使用双向复制工具或双重写入操作),两个数据库在迁移期间处理来自连接应用程序的事务。此方法支持小批量受控批量迁移,无需一次性切换。它更灵活,但需要更多的工作主动-被动迁移

主动-被动迁移

一种数据库迁移方法,在这种方法中,源数据库和目标数据库保持同步,但只有源数据库处理来自连接应用程序的事务,同时将数据复制到目标数据库。目标数据库在迁移期间不接受任何事务。

应用程序投资组合

有关组织使用的每个应用程序的详细信息的集合,包括构建和维护应用程序的成本及其业务价值。这些信息是产品组合发现和分析过程的关键,有助于确定需要迁移、现代化和优化的应用程序并确定其优先级。

人工智能运营 (AIOps)

使用机器学习技术解决运营问题、减少操作事件和人为干预以及提高服务质量的过程。有关如何在AWS迁移策略中使用 AIOps 的更多信息,请参阅运营集成指南

AWS云采用框架 (AWSCAF)

指导方针和最佳实践框架AWS,可帮助组织制定高效有效的计划,成功迁移到云端。 AWSCAF 将指导分为六个被称为视角的重点领域:业务、人员、治理、平台、安全和运营。业务、人员和治理视角侧重于业务技能和流程;平台、安全和运营视角侧重于技术技能和流程。例如,人员视角针对的是处理人力资源 (HR)、人员配置职能和人员管理的利益相关者。从这个角度来看,AWSCAF 为人员发展、培训和沟通提供指导,帮助组织为成功采用云做好准备。有关更多信息,请参阅 AWSCAF 网站和 CAF 白皮AWS书

AWS工作负载认证框架 (AWSWQF)

一种评估数据库迁移工作负载、推荐迁移策略和提供工作估算的工具。 AWSWQF 包含在 AWS Schema Conversion Tool (AWS SCT) 中。它分析数据库架构和代码对象、应用程序代码、依赖关系和性能特征,并提供评估报告。

业务连续性规划 (BCP)

该计划旨在应对破坏性事件(例如大规模迁移)对运营的潜在影响,使企业能够快速恢复运营。

更改数据捕获 (CDC)

跟踪数据源(例如数据库表)的更改并记录有关更改的元数据的过程。您可以将 CDC 用于多种用途,例如审计或复制目标系统中的更改以保持同步。

云卓越中心 (CCoE)

一个多学科团队,负责推动整个组织采用云的努力,包括制定云最佳实践、调动资源、制定迁移时间表以及领导组织进行大规模转型。有关更多信息,请参阅AWS云企业战略博客上的 cCoE 文章

云端采用阶段

组织迁移到AWS云端时通常要经历的四个阶段:

  • 项目 — 运行一些与云相关的项目以进行概念验证和学习

  • 基础 — 进行基础投资以扩大您的云采用率(例如,创建着陆区、定义 cCoE、建立运营模式)

  • 迁移-迁移单个应用程序

  • 再创新 — 优化产品和服务,在云端进行创新

这些阶段是斯蒂芬·奥尔班在云企业战略博客上的博客文章《通往云优先的旅程和采用阶段》中AWS定义的。有关它们与AWS迁移策略的关系的信息,请参阅迁移准备指南

配置管理数据库 (CMDB)

一种存储库,用于存储和管理有关数据库及其 IT 环境的信息,包括硬件和软件组件及其配置。您通常在迁移的投资组合发现和分析阶段使用来自 CMDB 的数据。

史诗

在敏捷方法中,有助于组织和确定工作优先级的职能类别。Epics 提供了对需求和实施任务的高级描述。例如,AWSCAF 安全史诗包括身份和访问管理、侦探控制、基础设施安全、数据保护和事件响应。有关AWS迁移策略中史诗的更多信息,请参阅计划实施指南

快捷迁移

一种数据库迁移方法,它使用连续数据复制在尽可能短的时间内迁移数据,而不是使用分阶段的方法。更改数据捕获 (CDC)目标是将停机时间降至最低。

异构数据库迁移

将您的源数据库迁移到使用不同数据库引擎的目标数据库(例如,Oracle 到 Amazon Aurora)。异构迁移通常是重新架构工作的一部分,转换架构可能是一项复杂的任务。 AWS提供AWS SCT有助于架构转换的内容。

同构数据库迁移

将您的源数据库迁移到共享相同数据库引擎的目标数据库(例如,微软 SQL Server 到 Amazon RDS for SQL Server)。同构迁移通常是重新托管或平台重构工作的一部分。您可以使用本机数据库实用程序迁移架构。

过度护理期

切换之后立即是指迁移团队管理和监控云中迁移的应用程序以解决任何问题的时间段。通常,此期限为 1-4 天。在超级护理期结束时,迁移团队通常会将应用程序的责任移交给云运营团队。

空闲应用程序

在 90 天内平均 CPU 和内存使用率介于 5% 到 20% 之间的应用程序。在迁移项目中,通常会停用这些应用程序或将其保留在本地。

增量迁移

一种切换策略,您可以分小部分迁移应用程序,而不是执行单一的完全切换。例如,您最初可能只将几个微服务或用户移至新系统。在确认一切正常运行后,您可以逐步移动其他微服务或用户,直到可以停用旧系统。该策略降低了与大规模迁移相关的风险。

IT 信息库 (ITIL)

一组用于交付 IT 服务并将这些服务与业务需求协调的最佳实践。ITIL 为 ITSM 提供了基础。

IT 服务管理 (ITSM)

与为组织设计、实施、管理和支持 IT 服务相关的活动。有关将云运营与 ITSM 工具集成的信息,请参阅运营集成指南

着陆区

着陆区是一个架构完善的多账户AWS环境,具有可扩展性和安全性。这是您的组织可以自信地快速启动和部署工作负载和应用程序的起点,对自己的安全和基础设施环境充满信心。有关着陆区的更多信息,请参阅设置安全且可扩展的多账户AWS环境

大规模迁移

300 个或更多服务器的迁移。

迁移加速计划 (MAP)

AWS该计划提供咨询支持、培训和服务,帮助组织为迁移到云奠定坚实的运营基础,并帮助抵消迁移的初始成本。MAP 包括一种用于以有条不紊的方式执行传统迁移的迁移方法,以及一组用于自动化和加快常见迁移方案的工具。

移民投资组合评估 (MPA)

一种在线工具,为验证迁移到AWS云端的业务案例提供信息。MPA 提供详细的产品组合评估(服务器合理配置、定价、TCO 比较、迁移成本分析)以及迁移规划(应用程序数据分析和数据收集、应用程序分组、迁移优先级和波段规划)。M PA 工具(需要登录)可供所有AWS顾问和 APN 合作伙伴顾问免费使用。

迁移准备情况评估 (MRA)

使用 AWS CAF 深入了解组织的云就绪状态、确定优势和劣势以及制定行动计划以缩小已发现差距的过程。有关更多信息,请参阅迁移准备指南。MRA 是AWS迁移策略的第一阶段。

大规模迁移

将大部分应用程序组合分阶段迁移到云端的过程,每波中都有更多应用程序以更快的速度移动。此阶段使用前期阶段的最佳实践和经验教训,实施由团队、工具和流程组成的迁移工厂,通过自动化和敏捷交付简化工作负载的迁移。这是AWS迁移战略的第三阶段。

迁移工厂

跨职能团队,通过自动化、敏捷的方法简化工作负载迁移。迁移工厂团队通常包括运营人员、业务分析师和所有者、迁移工程师、开发人员和从事冲刺工作的DevOps专业人员。20% 到 50% 的企业应用程序产品组合由重复模式组成,这些模式可以通过工厂方法进行优化。有关更多信息,请参阅本内容集中关于迁移工厂的讨论云迁移工厂指南

迁移元数据

完成迁移所需的有关应用程序和服务器的信息。每种迁移模式都需要一组不同的迁移元数据。迁移元数据的示例包括目标子网、安全组和AWS账户。

迁移模式

一项可重复的迁移任务,详细说明迁移策略、迁移目标以及使用的迁移应用程序或服务。示例:使用AWS应用程序迁移服务重新托管迁移到 Amazon EC2。

迁移策略

用于将工作负载迁移到AWS云端的方法。有关更多信息,请参阅本词汇表中的7 卢比条目和动员您的组织以加快大规模迁移。

离线迁移

一种在迁移过程中移除源工作负载的迁移方法。此方法涉及更长的停机时间,通常用于小型非关键工作负载。

在线移民

一种迁移方法,在这种方法中,源工作负载在不离线的情况下复制到目标系统。在迁移期间,连接到工作负载的应用程序可以继续运行。此方法涉及零至最少的停机时间,通常用于关键生产工作负载。

运营层面协议 (OLA)

该协议明确了职能IT部门承诺相互交付哪些内容以支持服务级别协议 (SLA)。

运营集成 (OI)

云端运营现代化的过程,包括就绪规划、自动化和集成。有关更多信息,请参阅运营集成指南

组织变更管理 (OCM)

从人员、文化和领导力角度管理重大颠覆性业务转型的框架。OCM 通过加快变更采用、解决过渡问题以及推动文化和组织变革,帮助组织为新系统和战略做好准备并过渡到新系统和战略。在AWS迁移策略中,该框架被称为人员加速,因为云采用项目需要加快变革速度。有关更多信息,请参阅 OCM 指南

剧本

一组预定义的步骤,用于记录与迁移相关的工作,例如在云中交付核心运营功能。行动手册可以采用脚本、自动运行手册或操作现代化环境所需的流程或步骤摘要的形式。

投资组合评估

为规划迁移而发现、分析应用程序组合并对其进行优先排序的过程。有关更多信息,请参阅评估迁移准备情况

负责、负责、协商、知情 (RACI) 矩阵

定义和分配项目中角色和职责的矩阵。例如,您可以创建 RACI 来定义安全控制所有权或确定迁移项目中特定任务的角色和职责。

跑步手册

执行特定任务所需的一组手动或自动程序。它们通常是为了简化错误率高的重复操作或程序而构建的。

服务级别协议 (SLA)

该协议阐明了 IT 团队承诺向客户交付的内容,例如服务正常运行时间和性能。

任务清单

一种用于跟踪运行手册进度的工具。任务列表包含运行手册的概述和要完成的常规任务列表。对于每项常规任务,它包括估计所需的时间、所有者和进度。

工作流

迁移项目中负责一组特定任务的职能组。每个工作流都是独立的,但支持项目中的其他工作流。例如,产品组合工作流负责确定应用程序的优先级、波段规划和收集迁移元数据。产品组合工作流将这些资产交付到迁移工作流,然后迁移服务器和应用程序。

僵尸应用程序

平均 CPU 和内存使用率低于 5% 的应用程序。在迁移项目中,通常会停用这些应用程序。

现代化条款

业务能力

企业为创造价值而做的事情(例如,销售、客户服务或营销)。微服务架构和开发决策可以由业务能力驱动。有关更多信息,请参阅在白皮书上运行容器化微服务的 “围绕业务能力进行组织” 部分。AWS

领域驱动的设计

一种通过将复杂软件系统的组件连接到每个组件所服务的不断变化的领域或核心业务目标来开发复杂软件系统的方法。埃里克·埃文斯在他的《领域驱动设计:解决软件核心中的复杂性》(波士顿:Addison-Wesley Professional,2003 年)一书中介绍了这个概念。有关如何将域驱动的设计与奇怪的图案模式结合使用的信息,请参阅使用容器和 Amazon API Gateway 逐步实现传统 Microsoft ASP.NET (ASMX) Web 服务的现代化

微服务

一种通过明确定义的 API 进行通信的小型独立服务,通常由独立的小型团队拥有。例如,保险系统可能包括与业务能力(例如销售或营销)或子域(例如采购、理赔或分析)对应的微服务。微服务的好处包括敏捷性、灵活扩展、易于部署、可重复使用的代码和弹性。有关更多信息,请参阅使用AWS无服务器服务集成微服务

微服务架构

一种使用独立组件构建应用程序的方法,这些组件将每个应用程序进程作为微服务运行。这些微服务使用轻量级 API 通过定义明确的接口进行通信。该架构中的每个微服务都可以更新、部署和扩展,以满足对应用程序特定功能的需求。有关更多信息,请参阅在上实现微服务。AWS

现代化

将过时(传统或整体式)应用程序及其基础架构转变为灵活、灵活且高度可用的云端系统,以降低成本、提高效率并利用创新。有关更多信息,请参阅实现AWS云端应用程序现代化的策略。

现代化准备情况评估

一种评估,可帮助确定组织应用程序的现代化准备情况;确定优点、风险和依赖关系;并确定组织支持这些应用程序的未来状态的程度。评估的结果是目标架构的蓝图、详细说明现代化过程的开发阶段和里程碑的路线图以及解决已发现差距的行动计划。有关更多信息,请参阅评估AWS云中应用程序的现代化准备情况

单片应用程序(单体)

作为单一服务运行且进程紧密耦合的应用程序。单片应用程序有几个缺点。如果一项应用程序功能的需求激增,则必须扩展整个架构。随着代码库的增长,添加或改进单体应用程序的功能也变得更加复杂。要解决这些问题,您可以使用微服务架构。有关更多信息,请参阅将整体分解为微服务。

通晓多国语言的持久性

根据数据访问模式和其他要求独立选择微服务的数据存储技术。如果您的微服务采用相同的数据存储技术,则它们可能会遇到实施挑战或性能不佳。如果微服务使用最适合其要求的数据存储,则可以更轻松地实现并实现更好的性能和可扩展性。有关更多信息,请参阅在微服务中启用数据持久性

split-and-seed 模型

一种扩展和加速现代化项目的模式。随着新功能和产品版本的定义,核心团队会分成几个组成新的产品团队。这有助于扩展组织的能力和服务,提高开发人员的工作效率并支持快速创新。有关更多信息,请参阅实现AWS云端应用程序现代化的分阶段方法。

勒死者无花果图案

一种对整体系统进行现代化改造的方法,方法是逐步重写和替换系统功能,直到旧系统可以停用。这种模式使用无花果树的比喻,它长成了一棵成熟的树木,最终克服并取代了宿主。这种模式是马丁·福勒引入的,目的是为了在重写整体系统时管理风险。有关如何应用此模式的示例,请参阅使用容器和 Amazon API 网关逐步实现传统微软 ASP.NET (ASMX) Web 服务的现代化

双披萨小组

一个小DevOps团队,你可以用两个披萨来养活他们。两个披萨的团队规模确保了在软件开发方面进行协作的最佳机会。有关更多信息,请参阅AWS白皮书简介中的 Two-Pizza 团队部分。DevOps