AWS規範性指導詞彙表 - AWS規範指導

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

AWS規範性指導詞彙表

AI 和 ML 術語|遷移術語|現代化條款

AI 和 ML 術語

以下是人工智能 (AI) 和機器學習 (ML) 相關策略、指南和模式中的常用術語。AWS指導。若要建議參賽作品,請使用提供意見回饋鏈接在詞彙表的末尾。

二元分類

預測二元結果的過程(兩個可能類別其中之一)。例如,您的 ML 模型可能需要預測問題,例如「此電子郵件是垃圾郵件還是不是垃圾郵件?」 或「這個產品是書籍還是汽車?」

分類

有助於生成預測的分類過程。分類問題的 ML 模型預測離散值。離散值始終彼此不同。例如,模型可能需要評估圖像中是否有汽車。

資料預先處理

若要將原始資料轉換為可由 ML 模型輕鬆解析的格式。預處理數據可能意味着刪除某些列或行,並解決缺失、不一致或重複的值。

深層合奏

組合多個深度學習模型進行預測。您可以使用深度合奏獲得更準確的預測或估計預測中的不確定性。

深度學習

一個 ML 子字段,它使用多層人工神經網絡來識別輸入數據和目標變量之間的映射。

探索性資料分析 (EDA)

分析數據集以瞭解其主要特徵的過程。您可以收集或聚合數據,然後執行初始調查以查找模式、檢測異常和檢查假設。EDA 通過計算彙總統計數據和創建數據可視化來執行。

特色

用來進行預測的輸入資料。例如,在製造環境中,要素可能是從製造線定期捕獲的圖像。

功能重要性

要素對於模型預測的重要性。這通常表示為可通過各種技術(如 Shapley 加法解釋 (SHAP) 和集成梯度計算的數值得分。如需詳細資訊,請參閱「」AWS 的機器學習模型可解釋

特徵轉換

優化 ML 過程的數據,包括使用其他源豐富數據、縮放值或從單個數據字段中提取多組信息。這使 ML 模型能夠從數據中受益。例如,如果將「2021-05-27 00:15:37」日期分為「2021」、「五月」、「週四」和「15」,則可以幫助學習算法學習與不同數據組件相關的細微模式。

解釋性

機器學習模型的一個特徵,描述人類可以理解模型的預測如何依賴於其輸入的程度。如需詳細資訊,請參閱「」AWS 的機器學習模型可解釋

多類別分類

幫助為多類別產生預測的過程(預測兩個以上結果的其中一個)。例如,ML 型號可能會詢問「這個產品是書籍、汽車還是電話?」 或「這個客户最感興趣的產品類別為何?」

回歸

一種預測數值的 ML 技術。例如,要解決「這棟房屋的售價為何?」 ML 模型可以使用線性迴歸模型根據有關房屋的已知事實(例如,平方英尺)預測房屋的銷售價格。

培訓

為 ML 模型提供數據以便從中學習。訓練資料必須包含正確答案。學習演算法會在定型資料中尋找將輸入資料屬性對應至目標的模式 (您想要預測的答案)。它輸出捕獲這些模式的 ML 模型。隨後可使用 ML 模型來預測您不知道目標的新資料。

目標變數

您試圖在受監督 ML 中預測的值。這也稱為結果變數。例如,在製造設置中,目標變量可能是產品缺陷。

調校

更改訓練過程的各個方面以提高 ML 模型的準確性。例如,您可以產生標記集、添加標籤,然後在不同設置下多次重複這些步驟來訓練 ML 模型。

不確定性

指可能損害預測性 ML 模型可靠性的不精確、不完整或未知的信息的概念。不確定性有兩種類型:認識不確定性是由有限的,不完整的數據引起的,而理性不確定性是由數據固有的噪聲和隨機性引起的。如需詳細資訊,請參閲 。量化深度學習系統中的不確定性指南。

遷移術語

以下是遷移相關策略、指南和模式中常用術語。AWS指導。若要建議參賽作品,請使用提供意見回饋鏈接在詞彙表的末尾。

7 Rs

將應用遷移到雲的七種常見遷移策略。這些戰略以 Gartner 在 2011 年確定的 5 Rs 為基礎,包括以下內容:

  • 重構器/重新設計師 — 通過充分利用雲原生功能來提高敏捷性、性能和可擴展性,移動應用程序並修改其體繫結構。這通常涉及移植操作系統和數據庫。範例:將您的內部部署 Oracle 資料庫遷移至 Amazon Aurora PostgreSQL 相容版本。

  • 重新平台(提升和重塑)— 將應用程序移動到雲,並引入一定級別的優化以利用雲功能。範例:將您的內部部署 Oracle 資料庫遷移至適用於 Oracle 的 Amazon Relational Database Service (Amazon RDS),請參AWS雲端。

  • 回購(丟棄和購買)— 切換到其他產品,通常通過從傳統許可證轉換為 SaaS 型號。範例:將您的客户關係管理 (CRM) 系統遷移至 SalesForce.com。

  • 重新主機(提升和移動)— 將應用程序移動到雲,而無需進行任何更改以利用雲功能。範例:將您的內部部署 Oracle 資料庫遷移至 OracleAWS雲端。

  • 重新定位(虛擬機管理程序級別的提升和轉換)— 將基礎架構遷移到雲,而無需購買新硬件、重寫應用程序或修改現有操作。此遷移方案特定於AWS,它支持在您的內部部署環境和AWS。當您將基礎架構遷移到 VMware Cloud 時,您可以使用本地數據中心中的 VMware 雲基礎技術AWS。範例:將託管 Oracle 數據庫的虛擬機管理程序重新定位到AWS。

  • 保留(重新訪問)— 將應用程序保留在源環境中。這些應用程序可能包括需要進行重構的應用程序,並且您希望將其工作推遲到以後,以及您希望保留的舊版應用程序,因為遷移這些應用程序沒有業務理由。

  • 停用 — 停用或刪除源環境中不再需要的應用程序。

應用程式組合

有關組織使用的每個應用程序的詳細信息的集合,包括構建和維護應用程序的成本及其業務價值。這些信息是產品組合發現和分析流程,幫助確定要遷移、現代化和優化的應用程序並確定其優先級。

人工智能操作

使用機器學習技術解決操作問題,減少操作事故和人工幹預,並提高服務質量的過程。如需 AiOps 如何使用的詳細資訊,請參AWS遷移策略,請參閲操作集成指南

AWS雲採用框架 (AWS咖啡館)

一個指導方針和最佳做法框架AWS,幫助企業制定高效、高效的計劃,以便成功遷移到雲。AWSCAF 將指導分為六個重點領域:業務、人員、治理、平台、安全和運營。業務、人員和治理觀點側重於業務技能和流程;平台、安全性和運營觀點側重於技術技能和流程。例如,人員視角針對處理人力資源 (HR)、人員配置職能和人員管理的利益攸關方。從這個角度來看,AWSCAF 為人員發展、培訓和溝通提供指導,幫助組織為成功採用雲做好準備。如需詳細資訊,請參閲 。AWSCAF 網站AWSCAF 白皮書

AWSlanding zone

landing zone 是架構良好的多帳户AWS可擴展且安全的環境。這是一個起點,您的組織可以快速啟動和部署工作負載和應用程序,並對其安全性和基礎架構環境充滿信心。如需着陸區的詳細資訊,請參設置安全且可擴展的多賬户AWS環境

AWS工作負載資格架構 (AWSWQF)

評估數據庫遷移工作負載、建議遷移策略並提供工作估算的工具。AWSWQF 包含在AWS Schema Conversion Tool(AWS SCT。它分析數據庫架構和代碼對象、應用程序代碼、依賴關係和性能特徵,並提供評估報告。

業務連續性規劃

解決中斷事件(如大規模遷移)對運營的潛在影響,並使企業能夠快速恢復運營的計劃。

Cloud Center of Excellence (CCoE)

一個多學科團隊,推動整個組織的雲採用工作,包括開發雲最佳實踐、調動資源、建立遷移時間表以及引導組織完成大規模轉型。如需詳細資訊,請參閲 。共同體委員會員額在AWS雲企業戰略博客。

採用雲階段

組織在遷移到AWS雲端:

  • 項目 — 運行幾個與雲相關的項目,用於概念驗證和學習目的

  • 基礎 — 進行基礎投資以擴展雲採用率(例如,創建 landing zone、定義 CCoE、建立運營模型)

  • 遷移 — 遷移單個應用程序

  • 再創新 — 優化產品和服務,在雲中實現創新

這些階段是由斯蒂芬·奧爾班在博客文章雲優先與採用階段在AWS雲企業戰略博客。如需它們如何與AWS遷移策略,請參閲遷移準備情況指南

配置管理數據庫 (CMDB)

包含有關公司硬件和軟件產品、配置和相互依賴關係的信息的數據庫。您通常在遷移的產品組合發現和分析階段使用 CMDB 中的數據。

史詩

在敏捷方法中,功能類別可幫助組織和優先安排您的工作。Epic 提供了對要求和實施任務的高級描述。例如:AWSCAF 安全史詩包括身份和訪問管理、偵測控制、基礎架構安全性、數據保護和事件響應。如需史詩的詳細資訊,請參AWS遷移策略,請參閲計劃實施指南

異構資料庫遷移

將源數據庫遷移到使用不同數據庫引擎的目標數據庫(例如,Oracle 到 Amazon Aurora)。異構遷移通常是重新架構工作的一部分,轉換架構可能是一項複雜的任務。AWS提供AWS SCT,它有助於模式轉換。

同類資料庫遷移

將源數據庫遷移到共享相同數據庫引擎的目標數據庫(例如,Microsoft SQL Server 到 Amazon RDS for SQL Server)。同類遷移通常是重新託管或平台改革工作的一部分。您可以使用本機數據庫實用程序遷移模式。

閒置應用程式

在 90 天的時間內,CPU 和內存使用率平均在 5% 到 20% 之間的應用程序。在遷移項目中,通常會停用這些應用程序或將其保留在本地。

IT 信息庫 (ITIL)

提供 IT 服務並使這些服務符合業務需求的一組最佳做法。ITIL 為 ITSM 提供了基礎。

資訊科技服務管理

與為組織設計、實施、管理和支持 IT 服務相關的活動。如需整合雲操作與 ITSM 工具的詳細資訊,請參操作集成指南

大型遷移

300 台或更多服務器的遷移。

Migration Acceleration Program

同時AWS計劃,該計劃提供諮詢支持、培訓和服務,幫助企業為遷移到雲打下堅實的運營基礎,並幫助抵消遷移的初始成本。MAP 包括用於以有條不紊的方式執行傳統遷移的遷移方法,以及一組用於自動化和加速常見遷移方案的工具。

遷移組合評估 (MPA)

一個在線工具,它提供信息,用於驗證業務案例以便遷移到AWS雲端。MPA 提供詳細的產品組合評估(服務器適當規模、定價、總擁有成本比較、遷移成本分析)以及遷移規劃(應用程序數據分析和數據收集、應用程序分組、遷移優先級排序和波浪規劃)。所以此MPA 工具(需要登錄)是免費提供給所有AWS顧問和 APN 合作夥伴顧問。

遷移準備情況評估 (MRA)

獲取有關組織雲就緒狀態的洞察、識別優勢和弱點以及制定行動計劃以彌補已發現的差距的過程,使用AWS咖啡館。如需詳細資訊,請參閲 。遷移準備情況指南。MRA 是第一個階段AWS 遷移策略

大規模遷移

將大多數應用程序產品組合移動到雲端的過程,每一波都會以更快的速度移動更多的應用程序。本階段利用早期階段的最佳做法和經驗教訓來實施遷移工廠,通過自動化和敏捷交付來簡化工作負載遷移。這是第三階段AWS遷移策略

遷移工廠

跨職能團隊通過自動化、敏捷的方法簡化工作負載遷移。遷移工廠團隊通常包括運營、業務分析師和所有者、遷移工程師、開發人員和DevOps專業人士在衝刺工作。20% 到 50% 的企業應用程序產品組合由重複的模式組成,這些模式可以通過工廠方法進行優化。如需詳細資訊,請參閲 。關於遷移工廠的討論CloudEndure遷移工廠指南在此內容集中。

遷移元數據

完成遷移所需的有關應用程序和服務器的信息。每個遷移模式都需要一組不同的遷移元數據。遷移元數據的示例包括目標子網、安全組和AWS帳户。

遷移模式

一個可重複的遷移任務,詳細説明遷移策略、遷移目標以及所使用的遷移應用程序或服務。範例:重新託管到 Amazon EC2 的遷移AWS應用程式遷移服務。

遷移策略

用於將工作負載遷移到AWS雲端。如需詳細資訊,請參閲 。7 Rs條目,請參閲調動您的組織以加快大規模遷移

業務一級協議 (法律廳)

一份協議,明確了職能部門 IT 團隊承諾相互交付的內容,以支持服務級別協議 (SLA)。

業務集成 (OI)

雲中運營現代化的過程,涉及就緒性規劃、自動化和集成。如需詳細資訊,請參閲 。操作集成指南

組織變革管理

從人員、文化和領導角度管理重大顛覆性業務轉型的框架。OCM 通過加快變革採用、解決過渡問題以及推動文化和組織變革,幫助組織準備和過渡到新系統和戰略。在 中AWS遷移策略,這個框架被稱為人加速,這是因為雲採用項目所需的更改速度。如需詳細資訊,請參閲 。OCM 指南

行動手冊

一組預定義的步驟,用於捕獲與遷移相關的工作,例如在雲中交付核心操作功能。行動手冊可以採取腳本、自動運行手冊或操作現代化環境所需的流程或步驟摘要的形式。

產品組合評估

發現、分析應用程序組合並確定其優先級的過程,以便規劃遷移。如需詳細資訊,請參閱「」評估遷移準備程度

負責任, 問責, 諮詢, 知情 (RACI) 矩陣

定義和分配項目中的角色和責任的矩陣。例如,您可以創建 RACI 來定義安全控制所有權,或確定遷移項目中特定任務的角色和責任。

Runbook

執行特定工作所需的手動或自動化過程集。這些通常是為了簡化具有高錯誤率的重複性操作或過程。

服務級別協議 (SLA)

一項協議,闡明瞭 IT 團隊承諾為客户提供的服務,例如服務正常運行時間和性能。

任務清單

用於通過運行簿跟蹤進度的工具。任務列表包含 Runbook 的概述和要完成的常規任務列表。對於每個常規任務,它包括所需的估計時間、所有者和進度。

工作流

遷移項目中負責特定任務集的職能組。每個工作流都是獨立的,但支持項目中的其他工作流。例如,產品組合工作流負責確定應用程序的優先級、波浪規劃和收集遷移元數據。產品組合工作流將這些資產提供到遷移工作流,然後遷移服務器和應用程序。

殭屍應用程式

平均 CPU 和內存使用率低於 5% 的應用程序。在遷移項目中,通常會停用這些應用程序。

現代化條款

以下是現代化相關策略、指南和模式中常用術語AWS指導。若要建議參賽作品,請使用提供意見回饋鏈接在詞彙表的末尾。

業務能力

企業如何創造價值(例如,銷售、客户服務或市場營銷)。微服務體繫結構和開發決策可以由業務能力驅動。如需詳細資訊,請參閲 。圍繞業務能力組織的 區段在上運行容器化微服務AWS白皮書。

域驅動設計

一種開發複雜軟件系統的方法,方法是將其組件連接到每個組件所服務的不斷變化的領域或核心業務目標。這個概念是由埃裏克·埃文斯在他的書中介紹,領域驅動設計:解決軟件核心中的複雜性(波士頓:艾迪生-韋斯利專業人員, 2003 年). 如需如何將域驅動設計與扼殺無花果模式結合使用的詳細資訊,請參使用容器和 Amazon API Gateway 以增量方式實現舊版微軟 ASP.NET (ASMX) 網絡服務的現代化

微服務

一種小型、獨立的服務,通過明確定義的 API 進行通信,通常由小型獨立團隊擁有。例如,保險系統可能包括映射到業務能力(如銷售或市場營銷)或子域(如採購、索賠或分析)的微服務。微服務的好處包括敏捷性、靈活的擴展、易於部署、可重複使用的代碼和恢復能力。如需詳細資訊,請參閱「」通過使用集成微服務AWS無伺服器服務

微服務架構

一種使用獨立組件構建應用程序的方法,這些組件將每個應用程序進程作為微服務運行。這些微服務通過使用輕量級 API 通過明確定義的接口進行通信。此體繫結構中的每個微服務都可以進行更新、部署和擴展,以滿足對應用程序特定功能的需求。如需詳細資訊,請參閱「」在上實施微服務AWS

現代化

將過時的(舊式或整體)應用程序及其基礎架構轉變為雲中的敏捷、彈性和高可用性的系統,以降低成本、提高效率並利用創新。如需詳細資訊,請參閱「」現代化應用程序的戰略AWS雲端

現代化準備度評估

一種評估,它有助於確定組織應用程序的現代化就緒性;確定好處、風險和依賴關係;並確定組織可以多大程度支持這些應用程序的未來狀態。評估的結果是目標架構的藍圖、詳細説明發展階段和現代化進程裏程碑的路線圖以及彌補已查明的差距的行動計劃。如需詳細資訊,請參閱「」評估應用程序的現代化就緒性AWS雲端

單片應用(整體)

作為單個服務運行的應用程序,具有緊密耦合的進程。整體應用程序有幾個缺點。如果某個應用程序功能遇到需求高峯,則必須擴展整個體繫結構。當代碼庫增長時,添加或改進單片應用程序的功能也會變得更加複雜。要解決這些問題,您可以使用微服務體繫結構。如需詳細資訊,請參閱「」將整體分解為微服務

持久性多語

根據數據訪問模式和其他要求獨立選擇微服務的數據存儲技術。如果您的微服務具有相同的數據存儲技術,則它們可能會遇到實施挑戰或性能較差。如果微服務使用最適合其需求的數據存儲,則可以更輕鬆地實施並獲得更好的性能和可擴展性。如需詳細資訊,請參閱「」在微服務中啟用數據持久性

split-and-seed 模型

擴展和加速現代化項目的模式。隨着新功能和產品發佈的定義,核心團隊會分裂,以創建新的產品團隊。這有助於擴展組織的能力和服務,提高開發人員的工作效率,並支持快速創新。如需詳細資訊,請參閱「」分階段實現應用程序現代化AWS雲端

扼殺者無花果模式

一種通過逐步重寫和替換系統功能來實現整體系統現代化的方法,直到舊系統可以退役為止。這種模式使用了無花果藤的比喻,它生長成一棵樹,最終克服並取代它的宿主。模式是由馬丁·福勒介紹作為重寫單片系統時管理風險的一種方法。如需應用此模式的範例,請參使用容器和 Amazon API Gateway 以增量方式實現舊版微軟 ASP.NET (ASMX) 網絡服務的現代化

雙披薩團隊

一個小DevOps團隊,你可以用兩個比薩餅飼料。雙披薩團隊規模確保了在軟件開發中進行協作的最佳機會。如需詳細資訊,請參閲 。雙披薩團隊的 區段介紹DevOps上AWS白皮書。