diff --git a/Asset/Attachment/跨境电商/TK美国面单授权及操作流程/IMG-20251214113517682.png b/Asset/Attachment/跨境电商/TK美国面单授权及操作流程/IMG-20251214113517682.png deleted file mode 100644 index 322c2773..00000000 Binary files a/Asset/Attachment/跨境电商/TK美国面单授权及操作流程/IMG-20251214113517682.png and /dev/null differ diff --git a/Asset/Attachment/跨境电商/TK美国面单授权及操作流程/IMG-20251214113517732.png b/Asset/Attachment/跨境电商/TK美国面单授权及操作流程/IMG-20251214113517732.png deleted file mode 100644 index 14934c98..00000000 Binary files a/Asset/Attachment/跨境电商/TK美国面单授权及操作流程/IMG-20251214113517732.png and /dev/null differ diff --git a/Asset/Attachment/跨境电商/TK美国面单授权及操作流程/IMG-20251214113517771.png b/Asset/Attachment/跨境电商/TK美国面单授权及操作流程/IMG-20251214113517771.png deleted file mode 100644 index 62c019b3..00000000 Binary files a/Asset/Attachment/跨境电商/TK美国面单授权及操作流程/IMG-20251214113517771.png and /dev/null differ diff --git a/Asset/Attachment/跨境电商/TK美国面单授权及操作流程/IMG-20251214113517818.png b/Asset/Attachment/跨境电商/TK美国面单授权及操作流程/IMG-20251214113517818.png deleted file mode 100644 index f1bc0da9..00000000 Binary files a/Asset/Attachment/跨境电商/TK美国面单授权及操作流程/IMG-20251214113517818.png and /dev/null differ diff --git a/Asset/Attachment/跨境电商/TK美国面单授权及操作流程/IMG-20251214113517868.png b/Asset/Attachment/跨境电商/TK美国面单授权及操作流程/IMG-20251214113517868.png deleted file mode 100644 index 1655de6f..00000000 Binary files a/Asset/Attachment/跨境电商/TK美国面单授权及操作流程/IMG-20251214113517868.png and /dev/null differ diff --git a/raw/跨境电商/Scrapy + Playwright 抓取TikTok Shop Data.md b/raw/AI/Scrapy + Playwright 抓取TikTok Shop Data.md similarity index 94% rename from raw/跨境电商/Scrapy + Playwright 抓取TikTok Shop Data.md rename to raw/AI/Scrapy + Playwright 抓取TikTok Shop Data.md index df9858a4..40fc05df 100644 --- a/raw/跨境电商/Scrapy + Playwright 抓取TikTok Shop Data.md +++ b/raw/AI/Scrapy + Playwright 抓取TikTok Shop Data.md @@ -1,89 +1,89 @@ ---- -title: ⚠️ 你使用 Docker，可能需要在 Dockerfile 里加入以下内容 -source: -author: shenwei -published: -created: -description: -tags: [playwright, scrapy] ---- - - -#scrapy #playwright - - -## **最推荐：创建虚拟环境 (venv) 并安装 Scrapy + Playwright** - -进入你的工程目录： -``` bash - -cd ~/Docker/tiktok_shop_scraper -``` - -创建 venv： -``` bash - -python3 -m venv venv - -``` - -激活 venv： -``` -source venv/bin/activate - -``` - -（你会看到终端前面出现 `(venv)`） - -``` bash -(venv) root@shenwei-HP-ZBook-01:/home/shenwei/Docker/tiktok_shop_scraper# - -``` - -后续再次进入venv - -``` -source /home/shenwei/Docker/tiktok_shop_scraper/venv/bin/activate -``` - - -在venv环境里安装依赖： -``` bash -pip install --upgrade pip -pip install scrapy scrapy-playwright - -``` - -安装 Playwright Chromium： -``` -playwright install chromium - -``` - -然后运行你的 spider： -``` bash -scrapy runspider tiktok_shop_spider.py -a shop_url="https://www.tiktok.com/shop/store/xxxx/xxxxxxxxxxxx" - -scrapy runspider tiktok_shop_spider.py -a shop_url="https://www.tiktok.com/shop/store/aopuro/7495894041403296077" - -``` - ---- - -# ⚠️ 你使用 Docker，可能需要在 Dockerfile 里加入以下内容 - -如果你是用 Dockerfile 构建容器，记得加两行： -``` -。/ -RUN python3 -m venv /app/venv ENV PATH="/app/venv/bin:$PATH" -``` - ---- - -# 🧪 验证 Playwright 是否安装成功 - -在 venv 中执行： -``` -python -c "from playwright.sync_api import sync_playwright; print('Playwright OK')" - +--- +title: ⚠️ 你使用 Docker，可能需要在 Dockerfile 里加入以下内容 +source: +author: shenwei +published: +created: +description: +tags: [playwright, scrapy] +--- + + +#scrapy #playwright + + +## **最推荐：创建虚拟环境 (venv) 并安装 Scrapy + Playwright** + +进入你的工程目录： +``` bash + +cd ~/Docker/tiktok_shop_scraper +``` + +创建 venv： +``` bash + +python3 -m venv venv + +``` + +激活 venv： +``` +source venv/bin/activate + +``` + +（你会看到终端前面出现 `(venv)`） + +``` bash +(venv) root@shenwei-HP-ZBook-01:/home/shenwei/Docker/tiktok_shop_scraper# + +``` + +后续再次进入venv + +``` +source /home/shenwei/Docker/tiktok_shop_scraper/venv/bin/activate +``` + + +在venv环境里安装依赖： +``` bash +pip install --upgrade pip +pip install scrapy scrapy-playwright + +``` + +安装 Playwright Chromium： +``` +playwright install chromium + +``` + +然后运行你的 spider： +``` bash +scrapy runspider tiktok_shop_spider.py -a shop_url="https://www.tiktok.com/shop/store/xxxx/xxxxxxxxxxxx" + +scrapy runspider tiktok_shop_spider.py -a shop_url="https://www.tiktok.com/shop/store/aopuro/7495894041403296077" + +``` + +--- + +# ⚠️ 你使用 Docker，可能需要在 Dockerfile 里加入以下内容 + +如果你是用 Dockerfile 构建容器，记得加两行： +``` +。/ +RUN python3 -m venv /app/venv ENV PATH="/app/venv/bin:$PATH" +``` + +--- + +# 🧪 验证 Playwright 是否安装成功 + +在 venv 中执行： +``` +python -c "from playwright.sync_api import sync_playwright; print('Playwright OK')" + ``` \ No newline at end of file diff --git a/raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-68-introduction-to-redshift.md b/raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-68-introduction-to-redshift.md index fc718c6f..c6cc18b6 100644 --- a/raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-68-introduction-to-redshift.md +++ b/raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-68-introduction-to-redshift.md @@ -1,60 +1,60 @@ ---- -title: CTP Topic 68 Introduction to Redshift -type: cloud-learning -source-type: video -category: DevOps & SRE/01_AWS-Landing-Zone -tags: - - AWS - - Redshift - - Data-Warehouse - - CTP -date-added: 2026-04-14 -video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 68_ Introduction to Redshift.mp4 -audio-source: "" -status: summarized (Gemini 摘要) ---- - -# CTP Topic 68 Introduction to Redshift - -**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 68_ Introduction to Redshift.mp4` - -**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone - -**Status:** 🟡 Awaiting Whisper transcription → Summary - ---- - -## 摘要 - -> ## AWS Redshift Architecture and Components - -This learning session covers AWS Redshift, focusing on its architecture, management, and key components. The session aims to provide a foundational understanding of Redshift, including its features like columnar operations, row-based operations, MPP (Massively Parallel Processing), data compression, and the significance of distinct and hot keys. - -Redshift is a fully managed, petabyte-scale data warehouse solution in the cloud. *It is designed for data warehousing, enabling quick data retrieval from large datasets.* It supports online analytical processing (OLAP) and offers advantages such as easy installation, maintenance of backups, point-in-time recovery, and cross-region disaster recovery. - -Redshift architecture involves client applications communicating with Redshift clusters via JDBC and ODBC drivers, connecting to a leader node. The leader node manages schema, warehouse metadata, and query planning, distributing instructions to compute nodes. Compute nodes, determined by the instance type, execute queries across slices, processing data and returning results to the leader node. *The leader node then stores results in buffers for quick retrieval, enhancing performance.* Instance types include dense compute, dense storage, and RA3, each offering varying levels of compute power, RAM, and storage capacity. RA3 is noted for its cost-effectiveness and large storage capacity, utilizing AWS-managed NVMe storage. - -Key features of Redshift include MPP, which enables parallel processing of queries across multiple compute nodes, improving query speed and response times. Data storage can be columnar or row-based; columnar storage is optimized for data warehouse operations due to faster performance and efficient memory usage. Data compression techniques, including LZO, further enhance performance by reducing data size. The sort key and dist key play a crucial role in optimizing queries and managing data distribution across compute nodes. - - ---- - -## 关键概念 - -- - ---- - -## 行动项 - -- - ---- - -## 相关视频 - -> 配对视频笔记链接（生成后填入） - ---- - -*最后更新: 2026-04-14* +--- +title: CTP Topic 68 Introduction to Redshift +type: cloud-learning +source-type: video +category: DevOps & SRE/01_AWS-Landing-Zone +tags: + - AWS + - Redshift + - Data-Warehouse + - CTP +date-added: 2026-04-14 +video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 68_ Introduction to Redshift.mp4 +audio-source: "" +status: summarized (Gemini 摘要) +--- + +# CTP Topic 68 Introduction to Redshift + +**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 68_ Introduction to Redshift.mp4` + +**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone + +**Status:** 🟡 Awaiting Whisper transcription → Summary + +--- + +## 摘要 + +> ## AWS Redshift Architecture and Components + +This learning session covers AWS Redshift, focusing on its architecture, management, and key components. The session aims to provide a foundational understanding of Redshift, including its features like columnar operations, row-based operations, MPP (Massively Parallel Processing), data compression, and the significance of distinct and hot keys. + +Redshift is a fully managed, petabyte-scale data warehouse solution in the cloud. *It is designed for data warehousing, enabling quick data retrieval from large datasets.* It supports online analytical processing (OLAP) and offers advantages such as easy installation, maintenance of backups, point-in-time recovery, and cross-region disaster recovery. + +Redshift architecture involves client applications communicating with Redshift clusters via JDBC and ODBC drivers, connecting to a leader node. The leader node manages schema, warehouse metadata, and query planning, distributing instructions to compute nodes. Compute nodes, determined by the instance type, execute queries across slices, processing data and returning results to the leader node. *The leader node then stores results in buffers for quick retrieval, enhancing performance.* Instance types include dense compute, dense storage, and RA3, each offering varying levels of compute power, RAM, and storage capacity. RA3 is noted for its cost-effectiveness and large storage capacity, utilizing AWS-managed NVMe storage. + +Key features of Redshift include MPP, which enables parallel processing of queries across multiple compute nodes, improving query speed and response times. Data storage can be columnar or row-based; columnar storage is optimized for data warehouse operations due to faster performance and efficient memory usage. Data compression techniques, including LZO, further enhance performance by reducing data size. The sort key and dist key play a crucial role in optimizing queries and managing data distribution across compute nodes. + + +--- + +## 关键概念 + +- + +--- + +## 行动项 + +- + +--- + +## 相关视频 + +> 配对视频笔记链接（生成后填入） + +--- + +*最后更新: 2026-04-14* diff --git a/raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-22-global-dns-service-offerings.md b/raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-22-global-dns-service-offerings.md index ca045c06..57e60340 100644 --- a/raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-22-global-dns-service-offerings.md +++ b/raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-22-global-dns-service-offerings.md @@ -1,61 +1,61 @@ ---- -title: "CTP Topic 22 Global DNS service offerings" -type: cloud-learning -source-type: video -category: "DevOps & SRE/08_Networking" -tags: - - DNS - - Networking - - CTP -date-added: 2026-04-14 -video-source: "nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 22_ Global DNS service offerings.mp4" -audio-source: "" -status: summarized (Gemini 摘要) ---- - -# CTP Topic 22 Global DNS service offerings - -**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 22_ Global DNS service offerings.mp4` - -**Type:** VIDEO | **Category:** 08_Networking - -**Status:** ✅ 已完成（Gemini 摘要） - ---- - -## 摘要 - -> 本视频由 Sankar 和 Vino 主讲，深入探讨了企业在全球范围内的 DNS 服务架构与配置方案，特别是针对 AWS 云环境、本地（On-prem）数据中心以及两者之间的混合云协作。视频的核心背景是公司正在进行的云转型计划，旨在构建一个高可用、多区域的 Landing Zone 基础架构。 -> -> 讲座重点介绍了 AWS 环境下的 DNS 设计。团队采用了 Route 53 Private Hosted Zones (PHZ) 作为核心服务，并结合 Active Directory (AD) 托管的 DNS。为了实现跨区域和混合云的域名解析，架构中大量使用了 Route 53 Resolver 的入站（Inbound）和出站（Outbound）终端节点。通过在出站规则中配置多个区域的 AD 域控制器 IP，确保了即使在某个区域发生故障时，DNS 解析仍能保持弹性。 -> -> 此外，演讲者对比了云端与本地 DNS 技术的差异。本地环境采用了 Infoblox 平台，利用 DNS Anycast 技术实现了全球范围内的低延迟和自动故障转移，而 AWS 目前在 EC2 基础架构上尚不支持 Anycast，因此需要手动维护 IP 列表。在安全方面，方案涵盖了防 DNS 隧道攻击、防数据外泄及缓存污染等高级特性。最后，视频强调了“就近解析”原则，以优化 Office 365 等全球化服务的访问性能。 - ---- - -## 关键概念 - -- **Route 53 Private Hosted Zone**: AWS 提供的私有托管区域，仅对指定的 VPC 可见，用于管理内部网络域名。 -- **Route 53 Resolver Endpoints**: 包括入站和出站终端节点，用于在 AWS VPC 与本地网络或其他云环境之间转发 DNS 查询。 -- **DNS Anycast**: 一种网络寻址和路由方法，使多个 DNS 服务器共享同一个 IP 地址，将请求路由至地理位置最近的节点，提供极高的冗余性和低延迟。 -- **IPAM (IP Address Management)**: IP 地址管理工具（如 Infoblox），用于规划、追踪和管理网络中的 IP 地址空间及 DNS/DHCP 服务。 -- **Landing Zone**: 一种预先配置好的多账号 AWS 环境，包含安全、网络和身份管理等基础设置，用于快速部署业务负载。 -- **Hybrid DNS Resolution**: 混合云 DNS 解析，指通过配置转发规则，使云端资源能解析本地域名，同时本地资源也能解析云端域名的机制。 -- **Infoblox Grid**: 一种分布式架构，通过 Grid Master 统一管理全球分布的 DNS/DHCP 器具，确保配置的一致性和高可用性。 - ---- - -## 相关视频 - -> [!info]+ 交叉引用 -> [[Inbound and Outbound Endpoints Deep Dive]] — 本视频多次提到了前一节关于入站和出站终端节点的详细技术实现。 -> [[AWS Landing Zone Architecture Overview]] — 视频中提到的 DNS 架构是该 Landing Zone 核心服务账号（Core Accounts）的重要组成部分。 -> [[Hybrid Cloud Connectivity and Networking]] — 讨论了 DNS 如何在通过 Direct Connect 或 VPN 连接的混合云环境中运作。 - -## 相关视频 - -> 配对视频笔记链接（生成后填入） - ---- - -*最后更新: 2026-04-14* +--- +title: "CTP Topic 22 Global DNS service offerings" +type: cloud-learning +source-type: video +category: "DevOps & SRE/08_Networking" +tags: + - DNS + - Networking + - CTP +date-added: 2026-04-14 +video-source: "nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 22_ Global DNS service offerings.mp4" +audio-source: "" +status: summarized (Gemini 摘要) +--- + +# CTP Topic 22 Global DNS service offerings + +**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 22_ Global DNS service offerings.mp4` + +**Type:** VIDEO | **Category:** 08_Networking + +**Status:** ✅ 已完成（Gemini 摘要） + +--- + +## 摘要 + +> 本视频由 Sankar 和 Vino 主讲，深入探讨了企业在全球范围内的 DNS 服务架构与配置方案，特别是针对 AWS 云环境、本地（On-prem）数据中心以及两者之间的混合云协作。视频的核心背景是公司正在进行的云转型计划，旨在构建一个高可用、多区域的 Landing Zone 基础架构。 +> +> 讲座重点介绍了 AWS 环境下的 DNS 设计。团队采用了 Route 53 Private Hosted Zones (PHZ) 作为核心服务，并结合 Active Directory (AD) 托管的 DNS。为了实现跨区域和混合云的域名解析，架构中大量使用了 Route 53 Resolver 的入站（Inbound）和出站（Outbound）终端节点。通过在出站规则中配置多个区域的 AD 域控制器 IP，确保了即使在某个区域发生故障时，DNS 解析仍能保持弹性。 +> +> 此外，演讲者对比了云端与本地 DNS 技术的差异。本地环境采用了 Infoblox 平台，利用 DNS Anycast 技术实现了全球范围内的低延迟和自动故障转移，而 AWS 目前在 EC2 基础架构上尚不支持 Anycast，因此需要手动维护 IP 列表。在安全方面，方案涵盖了防 DNS 隧道攻击、防数据外泄及缓存污染等高级特性。最后，视频强调了“就近解析”原则，以优化 Office 365 等全球化服务的访问性能。 + +--- + +## 关键概念 + +- **Route 53 Private Hosted Zone**: AWS 提供的私有托管区域，仅对指定的 VPC 可见，用于管理内部网络域名。 +- **Route 53 Resolver Endpoints**: 包括入站和出站终端节点，用于在 AWS VPC 与本地网络或其他云环境之间转发 DNS 查询。 +- **DNS Anycast**: 一种网络寻址和路由方法，使多个 DNS 服务器共享同一个 IP 地址，将请求路由至地理位置最近的节点，提供极高的冗余性和低延迟。 +- **IPAM (IP Address Management)**: IP 地址管理工具（如 Infoblox），用于规划、追踪和管理网络中的 IP 地址空间及 DNS/DHCP 服务。 +- **Landing Zone**: 一种预先配置好的多账号 AWS 环境，包含安全、网络和身份管理等基础设置，用于快速部署业务负载。 +- **Hybrid DNS Resolution**: 混合云 DNS 解析，指通过配置转发规则，使云端资源能解析本地域名，同时本地资源也能解析云端域名的机制。 +- **Infoblox Grid**: 一种分布式架构，通过 Grid Master 统一管理全球分布的 DNS/DHCP 器具，确保配置的一致性和高可用性。 + +--- + +## 相关视频 + +> [!info]+ 交叉引用 +> [[Inbound and Outbound Endpoints Deep Dive]] — 本视频多次提到了前一节关于入站和出站终端节点的详细技术实现。 +> [[AWS Landing Zone Architecture Overview]] — 视频中提到的 DNS 架构是该 Landing Zone 核心服务账号（Core Accounts）的重要组成部分。 +> [[Hybrid Cloud Connectivity and Networking]] — 讨论了 DNS 如何在通过 Direct Connect 或 VPN 连接的混合云环境中运作。 + +## 相关视频 + +> 配对视频笔记链接（生成后填入） + +--- + +*最后更新: 2026-04-14* diff --git a/raw/Home Office/Mac必装软件清单-2026-04-17.md b/raw/Home Office/Mac必装软件清单-2026-04-17.md index 0b46407b..702044aa 100644 --- a/raw/Home Office/Mac必装软件清单-2026-04-17.md +++ b/raw/Home Office/Mac必装软件清单-2026-04-17.md @@ -1,35 +1,35 @@ -# Mac 必装软件清单 - -> 来源：Telegram频道「Hermes爱马仕&🦞OpenClaw小龙虾」 -> 作者：Claw小龙虾 @openclaw1024 -> 日期：2026-04-17 - -用最少的软件，达到最高的效率。 - -## 推荐清单 - -| # | 软件 | 分类 | 推荐理由 | -|---|------|------|---------| -| 1 | Claude | AI | AI时代人手必备，桌面版Cowork功能专为文字工作者打造 | -| 2 | Obsidian | 知识管理 | 搭配Claudian插件，打造AI驱动的终极个人知识库 | -| 3 | Chrome | 浏览器 | 比Safari更好用，Gmail用户的不二之选 | -| 4 | Rectangle | 效率工具 | 免费分屏神器，大屏办公必备，从Windows转Mac必装 | -| 5 | iShot | 截图录屏 | 简洁免费的截图工具，支持圆角截图，五年老用户推荐 | -| 6 | Lemon | 系统清理 | 轻量清理工具，多任务卡顿时清一清缓存很管用 | -| 7 | Raycast | 效率工具 | 替代Spotlight的万能启动器，计算器和剪贴板超好用 | -| 8 | Homebrew | 开发工具 | Mac包管理器，用Claude Code搭Agent的前置依赖 | - -## 原文摘要 - -1. **Claude** — AI时代人手必备，桌面版Cowork功能为文字工作者设计 -2. **Obsidian** — 搭配Claudian插件，终极个人知识库 -3. **Chrome** — 比Safari更好用，适合Gmail用户 -4. **Rectangle** — 免费分屏软件，大屏办公必备 -5. **iShot** — 简洁免费截图，支持圆角截图，五年老用户推荐 -6. **Lemon** — 内存小硬盘小的Mac必备，多任务卡顿时清理缓存 -7. **Raycast** — 替代Spotlight的万能启动器，剪贴板历史超好用 -8. **Homebrew** — 偏技术向，Mac包管理器，Claude Code搭Agent的前置依赖 - -## 标签 - -#Mac #效率工具 #软件推荐 #知识管理 #AI +# Mac 必装软件清单 + +> 来源：Telegram频道「Hermes爱马仕&🦞OpenClaw小龙虾」 +> 作者：Claw小龙虾 @openclaw1024 +> 日期：2026-04-17 + +用最少的软件，达到最高的效率。 + +## 推荐清单 + +| # | 软件 | 分类 | 推荐理由 | +|---|------|------|---------| +| 1 | Claude | AI | AI时代人手必备，桌面版Cowork功能专为文字工作者打造 | +| 2 | Obsidian | 知识管理 | 搭配Claudian插件，打造AI驱动的终极个人知识库 | +| 3 | Chrome | 浏览器 | 比Safari更好用，Gmail用户的不二之选 | +| 4 | Rectangle | 效率工具 | 免费分屏神器，大屏办公必备，从Windows转Mac必装 | +| 5 | iShot | 截图录屏 | 简洁免费的截图工具，支持圆角截图，五年老用户推荐 | +| 6 | Lemon | 系统清理 | 轻量清理工具，多任务卡顿时清一清缓存很管用 | +| 7 | Raycast | 效率工具 | 替代Spotlight的万能启动器，计算器和剪贴板超好用 | +| 8 | Homebrew | 开发工具 | Mac包管理器，用Claude Code搭Agent的前置依赖 | + +## 原文摘要 + +1. **Claude** — AI时代人手必备，桌面版Cowork功能为文字工作者设计 +2. **Obsidian** — 搭配Claudian插件，终极个人知识库 +3. **Chrome** — 比Safari更好用，适合Gmail用户 +4. **Rectangle** — 免费分屏软件，大屏办公必备 +5. **iShot** — 简洁免费截图，支持圆角截图，五年老用户推荐 +6. **Lemon** — 内存小硬盘小的Mac必备，多任务卡顿时清理缓存 +7. **Raycast** — 替代Spotlight的万能启动器，剪贴板历史超好用 +8. **Homebrew** — 偏技术向，Mac包管理器，Claude Code搭Agent的前置依赖 + +## 标签 + +#Mac #效率工具 #软件推荐 #知识管理 #AI diff --git a/raw/跨境电商/TK美国面单授权及操作流程.md b/raw/跨境电商/TK美国面单授权及操作流程.md deleted file mode 100644 index d29bcda4..00000000 --- a/raw/跨境电商/TK美国面单授权及操作流程.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: -source: -author: shenwei -published: -created: -description: -tags: [] ---- - - -![Image](http://zipline.ishenwei.online/u/2WMgDB.png)![Image](http://zipline.ishenwei.online/u/T38XPv.png)![Image](http://zipline.ishenwei.online/u/nEJdNj.png)![Image](http://zipline.ishenwei.online/u/6e28LA.png)![Image](http://zipline.ishenwei.online/u/l81CN2.png)![Image](http://zipline.ishenwei.online/u/OfAxD6.png) - -## 🛡️ Image Backups - -> Backup created at 2025-12-19 14:43 -- [Zipline Image](http://zipline.ishenwei.online/u/2WMgDB.png) ⬅️ Source: [[IMG-20251214113517682.png]] -- [Zipline Image](http://zipline.ishenwei.online/u/T38XPv.png) ⬅️ Source: [[IMG-20251214113517732.png]] -- [Zipline Image](http://zipline.ishenwei.online/u/nEJdNj.png) ⬅️ Source: [[IMG-20251214113517771.png]] -- [Zipline Image](http://zipline.ishenwei.online/u/6e28LA.png) ⬅️ Source: [[IMG-20251214113517818.png]] -- [Zipline Image](http://zipline.ishenwei.online/u/l81CN2.png) ⬅️ Source: [[IMG-20251214113517868.png]] -- [Zipline Image](http://zipline.ishenwei.online/u/OfAxD6.png) ⬅️ Source: [[IMG-20251214113517921.png]] diff --git a/raw/跨境电商/做TK跨境思路不对努力白费.md b/raw/跨境电商/做TK跨境思路不对努力白费.md deleted file mode 100644 index fa554408..00000000 --- a/raw/跨境电商/做TK跨境思路不对努力白费.md +++ /dev/null @@ -1,67 +0,0 @@ ---- -title: 总结 -source: -author: shenwei -published: -created: -description: -tags: [tiktok] ---- - - -#tiktok #跨境 #电商 - -# 总结 -本视频分享了一位电商从业者在TikTok平台进行跨境电商的整体策略与实践经验。目标是为有意进入跨境电商市场的人士提供一步一步的实战指南。适合初学者及希望优化电商业务的中小企业主。观众能学习到市场选择、商品挑选、店铺开设及运营以及流量获取的有效方法。 - -# 时间线总结 -- **00:00 - 02:45:** 引入市场背景和分析用户增长面临的三大挑战。 - -- **02:46 - 05:00:** 强调不选择东南亚市场的原因，将重点放在发达国家如美区、英区等。 - -- **05:01 - 07:30:** 介绍如何在TikTok上选择账号观看直播，了解跨境电商的流程及政策。 - -- **07:31 - 10:00:** 讨论选品策略，确定美区的市场法规，办理营业执照步骤。 - -- **10:01 - 12:30:** 讲解选品软件的使用，如何找到合适的类目并进行商品上架。 - -- **12:31 - 15:00:** 描述产品上架后的流量跟踪，分析销售数据并调整策略。 - -- **15:01 - 17:30:** 讨论如何通过短视频和达人营销提升店铺的曝光和销量。 - -- **17:31 - 20:30:** 提出运用海外仓储及海运补货的策略，确保持续供应。 - -- **20:31 - 23:00:** 强调团队合作的重要性，通过招聘补充人力资源，优化运营流程。 - -# 关键点 -- **📈市场选择：** 优先考虑发达国家市场，如美区和日本，避免东南亚。 -- **🛠️选品策略：** 使用数据软件分析市场环境，确保选择适合的单一类目。 -- **📊运营流量分析：** 持续监控店铺流量，优化商品列表，及时下架表现不佳的商品。 -- **🎥短视频营销：** 利用短视频和达人推广，提高曝光率和转化率。 -- **👥团队建设：** 招募人员协助日常运营，确保电商业务的持续增长。 - -# 重要见解 -- **创新思维：** 在选品上应考虑到行业的发展趋势与消费者需求，而不是盲目跟风。 -- **数据驱动：** 在店铺运营中，数据分析能有效反映市场变化，帮助做出快速决策。 -- **市场动态：** 观察竞争对手的变化，适时调整策略以保持竞争力。 -- **长期运营：** 确保每个产品的质量，通过有效的物流管理确保顾客满意度。 -- **团队协作：** 成功的电商运营需要团队的配合与沟通，分工明确才能高效运作。 - -# 常见问题（FAQs） -- **📌如何选择合适的市场进行跨境电商？** - - 优先选择消费能力强、高利润的发达国家，避免竞争激烈且利润低的市场。 - -- **📌使用什么工具来选品？** - - 可使用数据分析软件来研究热门类目和消费者偏好。 - -- **📌如何提高店铺的流量和订单转化？** - - 通过短视频营销和达人合作来提升曝光率，同时优化店铺的商品列表。 - -- **📌如何保证产品的质量？** - - 在采购前亲自检验样品，并与供应商沟通确保质量符合标准。 - -- **📌团队扩展到什么程度合适？** - - 随着业务规模扩大，可以招聘1-2名合适的人才来分担日常任务。 - -# 结论 -视频总结了个人或小团队在TikTok跨境电商业务中可遵循的步骤与策略，从选区、选品到运营及团队建设，形成了一套完整的流程。观众应将视频中的建议应用于实际操作中，通过持续分析市场和优化策略，推进商业成功。建议行动步骤包括深入了解目标市场、不断调整策略并灵活应对市场变化。 \ No newline at end of file diff --git a/raw/跨境电商/电商如何选品 如何找到爆款 选品策略.md b/raw/跨境电商/电商如何选品 如何找到爆款 选品策略.md deleted file mode 100644 index 8e74cf2a..00000000 --- a/raw/跨境电商/电商如何选品 如何找到爆款 选品策略.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -title: 概要 -source: -author: shenwei -published: -created: -description: -tags: [] ---- - - - -https://www.youtube.com/watch?v=97IsU8WQq1o - - -# 概要 -本视频介绍了一种电商产品选择策略，分享了创作者如何从零开始获得数百万美元的年销售额。视频中总结了20种产品选择策略，适合希望提升电商销售的用户。观众将学习如何通过这些策略发掘流行商品，以满足不同消费者群体的需求，并使用工具提高客户转化率。 - -# 时间线摘要 -- **00:00 - 02:45**: 介绍市场背景，讲述通过产品选择战略获得年销售额的成果，提出重要的产品选择公式。 -- **02:46 - 04:45**: 列出20种产品选择策略，包括健康替代品、情感产品、针对特定群体的产品（如LGBTQ）。强调未来品牌需针对细分市场。 -- **04:46 - 06:15**: 深入分析产品选择的情境配对，例如搭配使用情境的产品组合，并结合节日和时尚趋势进行产品选择。 -- **06:16 - 09:50**: 讲解如何利用工具（如Salesmartly）高效管理跨平台订单，以及如何抓住季节性消费高峰与趋势变化，提供具体的方法和工具建议。 -- **09:51 - 10:32**: 介绍目前的电商站点（如Etsy）的市场需求，以及如何选择合适的产品进行创意开发，建议关注季节性销售高峰，并利用POD模式进行低成本测试。 - -# 关键点 -- **💡 适用于初学者**：适合初入电商领域的创业者，学习基本的产品选择策略。 -- **💡 产品战略的多样性**：强调多种产品选择方法，帮助满足不同消费者的需求。 -- **💡 工具的运用**：推荐使用Salesmartly等工具，提升客户管理和转化率。 -- **💡 季节性销售的把握**：提醒销售者提前规划与产品选择，抓住重要的消费时机。 -- **💡 POD模式的优势**：讲解POD产品的低成本和市场测试机会，适合想降低风险的商家。 - -# 重点洞察 -- **🗨️ 未来市场的成长潜力**：针对特定人群（如LGBTQ）的产品有很大的市场空间。 -- **🗨️ 具有情境的产品组合**：例如，露营必备的三件套比单独的产品更具吸引力。 -- **工具推荐**：使用Erank工具分析竞争者销售情况，提高产品上市效率。 -- **👀 趋势洞察**：关注Pinterest和Etsy的季度趋势报告，便于掌握热门关键词与产品上市时机。 -- **💡 产品测试的灵活性**：POD模式让创业者可以低风险测试市场需求。 - -# 常见问题 -- **Q1: 产品选择的基本原则是什么？** - **A1:** 理解目标市场需求，通过热点和细分市场选择适合的产品。 - -- **Q2: 为什么要关注消费者的节日购物趋势？** - **A2:** 提前布局相关产品可以抢占高峰期流量，最大化销售机会。 - -- **Q3: 如何管理多平台订单以提高转化率？** - **A3:** 使用销售管理工具（如Salesmartly），集中管理各平台消息及客户。 - -- **Q4: 推荐什么样的电商模式入门？** - **A4:** 可以选择POD模式，降低库存风险并测试市场需求。 - -- **Q5: 如何确定产品的市场潜力？** - **A5:** 结合关键词研究工具和竞争者销售数据，判断产品在市场上的表现。 - -# 结论 -本视频提供了一系列有效的电商产品选择策略，并向观众介绍了如何利用工具实现业务的高效管理。强调了产品选择与市场需求结合的重要性，并鼓励观众利用POD模式进行创新与风险控制。行动建议为：结合季节性需求与流行趋势，制定相应的产品策略，以提升电商销售并满足消费者的多样化需求。 \ No newline at end of file diff --git a/raw/跨境电商/电商视频Prompt.md b/raw/跨境电商/电商视频Prompt.md index 3425f5bc..90b81008 100644 --- a/raw/跨境电商/电商视频Prompt.md +++ b/raw/跨境电商/电商视频Prompt.md @@ -1,292 +1,292 @@ ---- -title: 🧠 Prompt 库整体结构（你可以照这个建文件夹） -source: -author: shenwei -published: -created: -description: -tags: [ai, image-to-vidoe, prompt, text-to-video] ---- - - -#ai #prompt #text-to-video #image-to-vidoe - -我直接给你一套 **「宠物用品 / 宠物衣服 · 可长期复用的 Prompt 库」**，不是示例，而是你可以 **直接复制、微调、规模化用** 的那种。整体设计目标只有一句话： - -> **低翻车率 + 高真实感 + 为 TikTok 带货服务** - -我会按 **模块化 Prompt 库** 给你，后面你只需要“拼积木”。 - ---- - -# 🧠 Prompt 库整体结构（你可以照这个建文件夹） - -``` - -Pet-Prompt-Library/ -│ -├─ 01_product_showcase.txt -├─ 02_pet_animation.txt -├─ 03_clothing_alignment.txt -├─ 04_scene_variations.txt -├─ 05_negative_prompt.txt -├─ 06_sales_copy_generator.txt -└─ 07_full_pipeline_example.txt -``` - -下面我把每一块 **内容完整给你**。 - ---- - -## 01️⃣ 产品展示 Prompt（核心，80% 视频用这个） - -### 🎯 适用 - -- 宠物衣服 -- 宠物垫 / 碗 / 玩具 -- 任何“需要看清细节”的商品 - -``` -Use the uploaded image as the primary reference. - -Show the product in a clean, professional e-commerce showcase style. -Keep the product’s shape, color, material, and proportions exactly the same. - -Focus on: -- fabric or material texture -- stitching and seams -- surface details - -Camera: -- slow, smooth movement -- close-up to medium shots -- stable framing - -Lighting: -- soft natural light -- no harsh shadows - -Background: -- simple and clean -- no distractions - -No redesign. -No added accessories. -No visual noise. - -``` - ---- - -## 02️⃣ 宠物动作 Prompt（自然、不翻车） - -### 🎯 适用 - -- 狗 / 猫 - -- 穿衣、趴着、走路、坐着 - - -``` -Animate the pet in a natural and realistic way. - -Movement: -- slow walking -- sitting or standing calmly -- gentle head movement -- blinking and breathing - -Behavior: -- relaxed -- friendly -- comfortable - -Motion must follow realistic animal physics. -No exaggerated movements. -No cartoon style. - - -``` - ---- - -## 03️⃣ 宠物衣服“防穿帮”专用 Prompt（非常关键） - -> 这是**宠物衣服类必加模块**，否则很容易翻车。 - -``` - -The clothing must stay perfectly fitted to the pet’s body. - -Rules: -- the clothing follows body movement naturally -- fabric moves subtly with motion -- no slipping, floating, or clipping -- no size change during movement - -The clothing remains the same design as in the reference image. - -``` - ---- - -## 04️⃣ 场景变化 Prompt（做多条视频用） - -### 🏠 室内 - -``` - -Scene: -- cozy indoor environment -- warm and comfortable mood -- natural home lighting - -``` - -### 🌳 户外（遛狗） - -``` - -Scene: -- outdoor walking environment -- soft daylight -- clean background -- shallow depth of field - -``` - -### ❄️ 冬季感（强卖点） - -``` -Scene: -- cold weather feeling -- soft winter lighting -- cozy and warm contrast - -``` - - -> ⚠️ 场景一定是 **加法模块**，不要一开始就写死。 - ---- - -## 05️⃣ Negative Prompt（统一放，降低翻车率） - -``` -No cartoon style -No unrealistic anatomy -No distorted body -No extra limbs -No exaggerated motion -No flashing lights -No watermark -No text on screen -No logo changes - -``` - ---- - -## 06️⃣ 卖货文案生成 Prompt（TikTok 专用） - -### 🎯 用法 - -视频生成完 → 用这个 Prompt 生成字幕 / caption / 旁白 - -``` -You are a TikTok e-commerce copywriter. - -Product: -[简要描述，比如：soft winter dog jacket] - -Target audience: -[dog owners in the US] - -Video content: -[描述视频里发生的事，比如：a dog walking calmly wearing the jacket indoors] - -Generate: -1. One short hook (≤12 words) -2. 3 benefit-driven bullet points -3. One soft call-to-action - -Tone: -- natural -- friendly -- trustworthy -- not pushy - -Avoid: -- fake urgency -- exaggerated claims -- overused marketing phrases - -``` - ---- - -## 07️⃣ 全流程示例（你直接照抄就能跑） - -### 🎬 Image → Video Prompt（合成版） - -``` - -Use the uploaded image as the primary reference. - -Show the product in a clean e-commerce showcase style. -Keep the product exactly the same in shape, color, and material. - -Animate the pet naturally: -- slow walking -- gentle head movement -- calm behavior - -The clothing stays perfectly fitted: -- no slipping -- no deformation -- fabric moves naturally - -Camera: -- smooth slow motion -- close-up and medium shots - -Lighting: -- soft natural light - -Scene: -- cozy indoor environment - -No cartoon style. -No distortion. -No extra elements. - -``` - ---- - -## 🚀 进阶用法（你这个阶段非常适合） - -### 1️⃣ 一个产品 = 3 条视频模板 - -- 细节展示版 - -- 宠物日常版 - -- 情绪共鸣版（“它穿得很舒服”） - - -### 2️⃣ Prompt 变量化（建议你这么存） - -``` -{PET_TYPE} -{SCENE} -{CLOTHING_TYPE} -{MOOD} - -``` - -### 3️⃣ 下一步可自动化 - -你完全可以做到： - +--- +title: 🧠 Prompt 库整体结构（你可以照这个建文件夹） +source: +author: shenwei +published: +created: +description: +tags: [ai, image-to-vidoe, prompt, text-to-video] +--- + + +#ai #prompt #text-to-video #image-to-vidoe + +我直接给你一套 **「宠物用品 / 宠物衣服 · 可长期复用的 Prompt 库」**，不是示例，而是你可以 **直接复制、微调、规模化用** 的那种。整体设计目标只有一句话： + +> **低翻车率 + 高真实感 + 为 TikTok 带货服务** + +我会按 **模块化 Prompt 库** 给你，后面你只需要“拼积木”。 + +--- + +# 🧠 Prompt 库整体结构（你可以照这个建文件夹） + +``` + +Pet-Prompt-Library/ +│ +├─ 01_product_showcase.txt +├─ 02_pet_animation.txt +├─ 03_clothing_alignment.txt +├─ 04_scene_variations.txt +├─ 05_negative_prompt.txt +├─ 06_sales_copy_generator.txt +└─ 07_full_pipeline_example.txt +``` + +下面我把每一块 **内容完整给你**。 + +--- + +## 01️⃣ 产品展示 Prompt（核心，80% 视频用这个） + +### 🎯 适用 + +- 宠物衣服 +- 宠物垫 / 碗 / 玩具 +- 任何“需要看清细节”的商品 + +``` +Use the uploaded image as the primary reference. + +Show the product in a clean, professional e-commerce showcase style. +Keep the product’s shape, color, material, and proportions exactly the same. + +Focus on: +- fabric or material texture +- stitching and seams +- surface details + +Camera: +- slow, smooth movement +- close-up to medium shots +- stable framing + +Lighting: +- soft natural light +- no harsh shadows + +Background: +- simple and clean +- no distractions + +No redesign. +No added accessories. +No visual noise. + +``` + +--- + +## 02️⃣ 宠物动作 Prompt（自然、不翻车） + +### 🎯 适用 + +- 狗 / 猫 + +- 穿衣、趴着、走路、坐着 + + +``` +Animate the pet in a natural and realistic way. + +Movement: +- slow walking +- sitting or standing calmly +- gentle head movement +- blinking and breathing + +Behavior: +- relaxed +- friendly +- comfortable + +Motion must follow realistic animal physics. +No exaggerated movements. +No cartoon style. + + +``` + +--- + +## 03️⃣ 宠物衣服“防穿帮”专用 Prompt（非常关键） + +> 这是**宠物衣服类必加模块**，否则很容易翻车。 + +``` + +The clothing must stay perfectly fitted to the pet’s body. + +Rules: +- the clothing follows body movement naturally +- fabric moves subtly with motion +- no slipping, floating, or clipping +- no size change during movement + +The clothing remains the same design as in the reference image. + +``` + +--- + +## 04️⃣ 场景变化 Prompt（做多条视频用） + +### 🏠 室内 + +``` + +Scene: +- cozy indoor environment +- warm and comfortable mood +- natural home lighting + +``` + +### 🌳 户外（遛狗） + +``` + +Scene: +- outdoor walking environment +- soft daylight +- clean background +- shallow depth of field + +``` + +### ❄️ 冬季感（强卖点） + +``` +Scene: +- cold weather feeling +- soft winter lighting +- cozy and warm contrast + +``` + + +> ⚠️ 场景一定是 **加法模块**，不要一开始就写死。 + +--- + +## 05️⃣ Negative Prompt（统一放，降低翻车率） + +``` +No cartoon style +No unrealistic anatomy +No distorted body +No extra limbs +No exaggerated motion +No flashing lights +No watermark +No text on screen +No logo changes + +``` + +--- + +## 06️⃣ 卖货文案生成 Prompt（TikTok 专用） + +### 🎯 用法 + +视频生成完 → 用这个 Prompt 生成字幕 / caption / 旁白 + +``` +You are a TikTok e-commerce copywriter. + +Product: +[简要描述，比如：soft winter dog jacket] + +Target audience: +[dog owners in the US] + +Video content: +[描述视频里发生的事，比如：a dog walking calmly wearing the jacket indoors] + +Generate: +1. One short hook (≤12 words) +2. 3 benefit-driven bullet points +3. One soft call-to-action + +Tone: +- natural +- friendly +- trustworthy +- not pushy + +Avoid: +- fake urgency +- exaggerated claims +- overused marketing phrases + +``` + +--- + +## 07️⃣ 全流程示例（你直接照抄就能跑） + +### 🎬 Image → Video Prompt（合成版） + +``` + +Use the uploaded image as the primary reference. + +Show the product in a clean e-commerce showcase style. +Keep the product exactly the same in shape, color, and material. + +Animate the pet naturally: +- slow walking +- gentle head movement +- calm behavior + +The clothing stays perfectly fitted: +- no slipping +- no deformation +- fabric moves naturally + +Camera: +- smooth slow motion +- close-up and medium shots + +Lighting: +- soft natural light + +Scene: +- cozy indoor environment + +No cartoon style. +No distortion. +No extra elements. + +``` + +--- + +## 🚀 进阶用法（你这个阶段非常适合） + +### 1️⃣ 一个产品 = 3 条视频模板 + +- 细节展示版 + +- 宠物日常版 + +- 情绪共鸣版（“它穿得很舒服”） + + +### 2️⃣ Prompt 变量化（建议你这么存） + +``` +{PET_TYPE} +{SCENE} +{CLOTHING_TYPE} +{MOOD} + +``` + +### 3️⃣ 下一步可自动化 + +你完全可以做到： + > 图片 → 自动生成 3 条视频 → 自动生成 6 条文案 → A/B 测试 \ No newline at end of file diff --git a/raw/跨境电商/超达物流定价.md b/raw/跨境电商/超达物流定价.md index 4793a1b2..f0806407 100644 --- a/raw/跨境电商/超达物流定价.md +++ b/raw/跨境电商/超达物流定价.md @@ -1,45 +1,45 @@ ---- -title: -source: -author: shenwei -published: -created: -description: -tags: [] ---- - - -![Image](http://zipline.ishenwei.online/u/ObMwZe.jpg) -![Image](http://zipline.ishenwei.online/u/rISSCz.png) -![Image](http://zipline.ishenwei.online/u/89zQA2.png) - -UIN渠道提供预上网服务，可满足国内发货TK上传轨迹需求，申请单号后24-48小时左右会有轨迹上网，请控制好申请单号的时间哦。 - -✨TK平台面单需注意以下几点： -1、申请的跟踪号为“TKM”开头的，为无效单号，需联系客服处理； -2、跟踪号需和超达后台单号核对，如发现超达系统没有该单号，需手动上传至系统； -3、超达系统后台为草稿订单状态订单，不会做轨迹推送，请及时处理； -4、无异常情况订单，在我系统收到单号后会推送上网轨迹，24-48小时左右生成。 - -申报重量和实重/材积差距尽量不要超过0.1Kg，且申报重量要低于收费重量，以免由于申报重量过高导致多支付运费。 - -🎀申报重量、实重、材积取最大值收费，请务必注意。 - -🌸UIN渠道取消单号收费说明如下： -①未推送轨迹取消单号不收操作费； -②已推送轨迹取消单号需要收取全额挂号费。 -③选错渠道后期修改需要收取10元/票操作费，请知悉。 - -🌸TK平台面单取消收费说明如下： -①取消单号未推送轨迹不收操作费； -②已推送轨迹需收取10元/票操作费； -③选错渠道后期修改需要收取10元/票操作费，请知悉。 - -发货时间：每天12点之前到仓的，都会当天打包发走。美区周日休息不发货，周一晚上发。 - -## 🛡️ Image Backups - -> Backup created at 2025-12-19 14:05 -- [Zipline Image](http://zipline.ishenwei.online/u/ObMwZe.jpg) ⬅️ Source: [[IMG-20251214113715561.jpg]] -- [Zipline Image](http://zipline.ishenwei.online/u/rISSCz.png) ⬅️ Source: [[IMG-20251214114224780.png]] -- [Zipline Image](http://zipline.ishenwei.online/u/89zQA2.png) ⬅️ Source: [[IMG-20251214114252644.png]] +--- +title: +source: +author: shenwei +published: +created: +description: +tags: [] +--- + + +![Image](http://zipline.ishenwei.online/u/ObMwZe.jpg) +![Image](http://zipline.ishenwei.online/u/rISSCz.png) +![Image](http://zipline.ishenwei.online/u/89zQA2.png) + +UIN渠道提供预上网服务，可满足国内发货TK上传轨迹需求，申请单号后24-48小时左右会有轨迹上网，请控制好申请单号的时间哦。 + +✨TK平台面单需注意以下几点： +1、申请的跟踪号为“TKM”开头的，为无效单号，需联系客服处理； +2、跟踪号需和超达后台单号核对，如发现超达系统没有该单号，需手动上传至系统； +3、超达系统后台为草稿订单状态订单，不会做轨迹推送，请及时处理； +4、无异常情况订单，在我系统收到单号后会推送上网轨迹，24-48小时左右生成。 + +申报重量和实重/材积差距尽量不要超过0.1Kg，且申报重量要低于收费重量，以免由于申报重量过高导致多支付运费。 + +🎀申报重量、实重、材积取最大值收费，请务必注意。 + +🌸UIN渠道取消单号收费说明如下： +①未推送轨迹取消单号不收操作费； +②已推送轨迹取消单号需要收取全额挂号费。 +③选错渠道后期修改需要收取10元/票操作费，请知悉。 + +🌸TK平台面单取消收费说明如下： +①取消单号未推送轨迹不收操作费； +②已推送轨迹需收取10元/票操作费； +③选错渠道后期修改需要收取10元/票操作费，请知悉。 + +发货时间：每天12点之前到仓的，都会当天打包发走。美区周日休息不发货，周一晚上发。 + +## 🛡️ Image Backups + +> Backup created at 2025-12-19 14:05 +- [Zipline Image](http://zipline.ishenwei.online/u/ObMwZe.jpg) ⬅️ Source: [[IMG-20251214113715561.jpg]] +- [Zipline Image](http://zipline.ishenwei.online/u/rISSCz.png) ⬅️ Source: [[IMG-20251214114224780.png]] +- [Zipline Image](http://zipline.ishenwei.online/u/89zQA2.png) ⬅️ Source: [[IMG-20251214114252644.png]] diff --git a/wiki/concepts/ADM.md b/wiki/concepts/ADM.md new file mode 100644 index 00000000..5ccfec48 --- /dev/null +++ b/wiki/concepts/ADM.md @@ -0,0 +1,28 @@ +--- +title: "ADM" +type: concept +tags: [AWS, Governance, Architecture] +last_updated: 2026-05-07 +--- + +## Definition + +ADM stands for **Architecture Decision Management** — the governance process for managing architecture decisions within an enterprise cloud environment. In the context of [[ctp-topic-50-ami-roadmap-for-aws-amis]], ADM is the primary driver for prioritizing the [[ARM-AMI]] roadmap. + +## Role in AMI Governance + +The [[CCOE]] AMI roadmap prioritization is primarily driven by ADM requirements. Any changes to roadmap prioritization must go through the demand pipeline process: + +> "The order was created mainly by ADM requirements. Any requirements to change the prioritization of the roadmap should go through the demand pipeline process." — [[ctp-topic-50-ami-roadmap-for-aws-amis]] + +## Related Concepts + +- [[Foundation-AMI]]: CCOE-provided hardened base images +- [[OS-End-of-Life]]: OS lifecycle management that feeds into ADM decision-making +- [[CCOE]]: Organization responsible for AMI governance and roadmap maintenance + +## Connections + +- [[ctp-topic-50-ami-roadmap-for-aws-amis]] → AMI roadmap is primarily driven by ADM requirements +- [[ctp-topic-26-standard-ami-build-publish-share-processes]] → ADM decisions influence Foundation AMI feature set +- [[ctp-topic-20-program-demand-process-flow-and-poc-onboarding]] → demand pipeline process for changing priorities diff --git a/wiki/concepts/AMI-Sharing.md b/wiki/concepts/AMI-Sharing.md new file mode 100644 index 00000000..4cb6b5c3 --- /dev/null +++ b/wiki/concepts/AMI-Sharing.md @@ -0,0 +1,52 @@ +--- +title: "AMI Sharing" +type: concept +tags: + - AWS + - AMI + - Multi-Account +sources: [] +last_updated: 2026-05-07 +--- + +## AMI Sharing + +AWS 镜像跨账号共享机制，通过授权其他 AWS 账户访问中央镜像，而非物理复制（AMI Copying），避免跨账号复制带来的额外存储成本。 + +## Definition + +AMI Sharing 是 AWS 账户管理策略，允许 AMI 所有者： +- 将 AMI 共享给特定 AWS 账户 +- 将 AMI 共享给 AWS Organization 内所有成员账户 +- 通过 RAM（Resource Access Manager）前缀列表跨账户共享规则 + +## Benefits vs AMI Copying + +| 维度 | AMI Sharing | AMI Copying | +|------|-------------|-------------| +| 存储成本 | 零增量 | 每区域完整副本 | +| 一致性 | 单一源，完全一致 | 复制后可能不一致 | +| 维护 | 单一更新点 | 每副本需独立更新 | +| 权限 | 通过 IAM/KMS 控制 | 独立权限管理 | + +## In Micro Focus CTP + +在 Micro Focus 多账户 AWS 环境中： +- Foundation AMI 存储在 CCOE 管理账户 +- 通过 AMI Sharing 分发给所有产品账户 +- 同步分发至全球多区域（俄勒冈/法兰克福/悉尼） +- EBS 卷和 KMS 密钥同步共享 + +## Prerequisites + +- AMI 所有者账户与目标账户在同一 AWS Organization，或 +- 显式授权跨账户共享 +- KMS 加密 AMI 需额外授权 KMS 密钥使用 + +## Sources +- [[ctp-topic-26-standard-ami-build-publish-share-processes]] — AMI Sharing 作为分发机制 +- [[ctp-topic-50-ami-roadmap-for-aws-amis]] — AMI 通过跨账号共享分发给组织内所有账户 + +## Related Concepts +- [[Foundation-AMI]] — AMI Sharing 分发的主要对象 +- [[AWS]] Organizations — 跨账号共享的组织基础 diff --git a/wiki/concepts/ARM-AMI.md b/wiki/concepts/ARM-AMI.md new file mode 100644 index 00000000..c006db0a --- /dev/null +++ b/wiki/concepts/ARM-AMI.md @@ -0,0 +1,40 @@ +--- +title: "ARM-AMI" +type: concept +tags: [AWS, AMI, ARM] +last_updated: 2026-05-07 +--- + +## Definition + +ARM-AMI refers to Amazon Machine Images (AMIs) built for EC2 instances running on ARM-based processors (Graviton/Graviton2/Graviton3). These AMIs are optimized for ARM architecture and offer better price-performance ratio compared to x86 AMIs for many workloads. + +## Key Characteristics + +- **Architecture**: ARM64 (AArch64), based on AWS Graviton processor family +- **Performance**: Better price-performance for many workloads (web servers, containers, microservices) +- **Cost**: Lower licensing costs (no x86 licensing fees) +- **Availability**: Available for Amazon Linux, Ubuntu, RHEL, and other supported OSes +- **Shared Infrastructure**: AMIs, EBS volumes, and KMS keys shared across all organization accounts + +## AMI Roadmap Context + +Per [[ctp-topic-50-ami-roadmap-for-aws-amis]], the ARM-AMI roadmap milestones: + +- **November 2022**: RHEL 9 ARM planned +- **May 2023**: RHEL 9.4 ARM and Ubuntu 22.04 ARM +- **Starting May 2023**: All ARM processors related to AMIs are released synchronously + +The ordering of ARM AMI releases is primarily driven by [[ADM]] (Architecture Decision Management) requirements. + +## Related Concepts + +- [[Foundation-AMI]]: CCOE-provided hardened base images on which product teams build +- [[AMI-Sharing]]: Cross-account AMI sharing mechanism +- [[OS-Hardening]]: Security hardening applied to AMIs + +## Connections + +- [[ctp-topic-50-ami-roadmap-for-aws-amis]] → defines ARM-AMI release roadmap +- [[ctp-topic-26-standard-ami-build-publish-share-processes]] → foundation AMI hardening standards apply to ARM variants +- [[ctp-topic-58-aws-ec2-image-builder]] → Image Builder used to create ARM-variant AMIs diff --git a/wiki/concepts/AWS-Backup-Concepts.md b/wiki/concepts/AWS-Backup-Concepts.md new file mode 100644 index 00000000..b80ea979 --- /dev/null +++ b/wiki/concepts/AWS-Backup-Concepts.md @@ -0,0 +1,61 @@ +--- +title: "AWS Backup Concepts" +type: concept +tags: + - AWS + - Backup + - DR + - Cloud-Native +sources: + - ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup + - ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program +last_updated: 2026-04-28 +--- + +# AWS Backup Concepts + +本页面汇总 AWS Backup 相关的核心概念。 + +## Vault Lock（备份保管库锁定） + +Vault Lock 是 AWS Backup 备份保管库的一种合规模式。在合规模式下： + +- 一旦 Vault Lock 生效，即使 AWS 根用户也无法在设定的生命周期结束前删除恢复点 +- 有效防御勒索软件攻击（攻击者无法加密/删除备份） +- 适用于需要满足监管合规要求（如 SEC、FINRA、GDPR）的场景 + +> 对比 CTP Topic 44（Micro Focus 评估）：Micro Focus 内部评估同样认可 Vault Lock 是防勒索软件的关键能力。 + +## 增量备份（Incremental Backup） + +增量备份仅捕获自上次备份以来的数据变更： + +- **优势**：首次全量备份后，后续仅备份变更，大幅节省存储成本 +- **机制**：备份链（Backup Chain）追踪变更，恢复时按顺序重放 +- **AWS Backup 自动处理**：无需手动管理备份链 + +> 与全量备份相比，增量备份显著降低了存储成本和备份窗口时长。 + +## 跨账户备份（Cross-Account Backup） + +通过 AWS Organizations 将备份从源账户复制到独立的 DR/Bunker 账户： + +- **隔离原则**：备份账户与工作负载账户物理分离，防止账户被入侵时备份一并丢失 +- **即时恢复**：备份保留在 DR 账户内，无需跨账户数据拷贝即可恢复 +- **多区域复制**：结合跨区域复制，实现地理冗余 + +## Backup Plan（备份计划） + +备份计划是 AWS Backup 的核心策略配置： + +- **规则（Rules）**：定义备份频率、保留期、启动窗口、复制规则等 +- **分配（Assignments）**：将计划应用于特定资源或资源集 +- **生命周期（Lifecycle）**：定义恢复点何时从热存储转为冷存储（Glacier） + +## Backup Vault（备份保管库） + +备份保管库是存储恢复点的加密容器： + +- 每个保管库使用 AWS KMS CMK 加密 +- 支持基于资源的策略（Resource-based Policy）控制访问 +- 与 Vault Lock 结合实现合规锁定 diff --git a/wiki/concepts/AWS-Inspector.md b/wiki/concepts/AWS-Inspector.md new file mode 100644 index 00000000..85417554 --- /dev/null +++ b/wiki/concepts/AWS-Inspector.md @@ -0,0 +1,27 @@ +--- +title: "AWS Inspector" +type: concept +tags: ["AWS", "Security", "Vulnerability-Scanning", "Compliance"] +sources: ["learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2", "ctp-topic-58-aws-ec2-image-builder"] +last_updated: 2026-05-08 +--- + +## Definition +AWS Inspector 是 AWS 原生的安全漏洞扫描服务，在 AMI 构建和发布流程中集成自动化的安全合规检测，识别已知安全漏洞（CVE）和网络暴露问题。 + +## Key Capabilities +- **CVE 检测**：识别已知安全漏洞 +- **网络可达性分析**：检测意外开放的安全组规则 +- **自动扫描**：集成到 CI/CD 流水线 +- **合规报告**：生成安全扫描报告 + +## Integration in AMI Pipeline +1. AMI 构建完成后立即触发 Inspector 扫描 +2. 扫描结果与安全基准对比 +3. 发现高危漏洞则阻断发布 +4. 无问题则继续跨区域复制和共享 + +## Connections +- [[Amazon-Machine-Image]] — Inspector 扫描的对象 +- [[Jenkins-Multi-Branch-Pipeline]] — Inspector 集成在 Jenkins 流水线中 +- [[AWS-Landing-Zone]] — Inspector 是 LZ 安全基础设施的组成部分 diff --git a/wiki/concepts/Active-Directory-Integration.md b/wiki/concepts/Active-Directory-Integration.md new file mode 100644 index 00000000..b253bc92 --- /dev/null +++ b/wiki/concepts/Active-Directory-Integration.md @@ -0,0 +1,42 @@ +--- +title: "Active-Directory-Integration" +type: concept +tags: [Identity, AWS, Networking] +sources: [ctp-topic-7-saas-landing-zone-design] +last_updated: 2026-05-06 +--- + +## Active-Directory-Integration + +AWS 环境中的 Active Directory 集成方案，用于实现统一的身份认证和资源访问控制。 + +## Definition + +Active Directory 集成是 Landing Zone 基线服务的重要组成部分： +- **核心功能**：通过双 AD 节点实现域加入（Domain Join）和资源访问控制 +- **部署位置**：独立的 Active Directory Account（基线账户层） +- **认证用途**：用于 AWS Workspaces、EC2 实例（Windows/Linux）、VPN 接入等场景的身份认证 + +## Role in SAS Landing Zone + +在 [[ctp-topic-7-saas-landing-zone-design]] 定义的 Baseline 账户中： +- **部署**：Active Directory 账户托管两个 AD 节点（双节点高可用） +- **用途 1**：域加入（Domain Join）— Windows 和 Linux 实例自动加入 AD 域 +- **用途 2**：资源访问控制 — 基于 AD 组映射 IAM 角色，实现最小权限原则 +- **用途 3**：VPN 认证 — Pulse VPN 通过 AD 认证远程访问人员身份 + +## Key Properties +- **Type**: Identity & Access Management +- **Architecture**: 双 AD 节点高可用 +- **In SAS LZ Layer**: Baseline Accounts + +## Related Concepts +- [[Domain-Join]] — 实例域加入机制 +- [[Federated-Access]] — 联邦身份认证 +- [[Multi-factor-Authentication]] — 多因素认证 + +## Connections +- [[ctp-topic-7-saas-landing-zone-design]] — SAS LZ 基线账户身份认证基础设施 +- [[ctp-topic-11-ad-integration-and-login-using-ad-accounts]] — AD 集成与登录详细实践 +- [[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]] — Gruntwork LZ 中的 AD 服务集成 +- [[ctp-topic-6-aws-workspaces-demo]] — AWS Workspaces 使用 AD 账号登录 diff --git a/wiki/concepts/Amazon-Machine-Image.md b/wiki/concepts/Amazon-Machine-Image.md new file mode 100644 index 00000000..7de83d3a --- /dev/null +++ b/wiki/concepts/Amazon-Machine-Image.md @@ -0,0 +1,42 @@ +--- +title: "Amazon Machine Image" +type: concept +tags: ["AWS", "Virtualization", "AMI", "Landing-Zone"] +sources: ["learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2", "ctp-topic-50-ami-roadmap-for-aws-amis", "ctp-topic-26-standard-ami-build-publish-share-processes"] +last_updated: 2026-05-08 +--- + +## Definition +Amazon Machine Image (AMI) 是 AWS 托管的虚拟机镜像模板，包含操作系统、应用程序和配置。在 Micro Focus AWS Landing Zone 中，标准 AMI 在 AWS 原生镜像基础上增加了企业级组件。 + +## Standard AMI Components +标准 AMI 在 AWS 原生镜像基础上增加： +- **OS 加固**：CIS 安全基准加固 +- **安全更新**：最新补丁和安全更新 +- **域名加入**：支持 AD 域集成 +- **安全工具**：McAfee EPO / Trellix / Sentinel-1 端点保护 +- **QALIS Agent**：企业端点保护 +- **SSM Agent**：AWS Systems Manager Agent +- **DNS 设置**：企业 DNS 配置 +- **GP3 EBS 存储**：第三代通用型 SSD + +## AMI Release Process +1. **功能分支开发**：变更在功能分支上开发 +2. **集成分支合并**：合并到集成分支 +3. **Jenkins 构建**：Jenkins 多分支流水线构建和测试 +4. **安全扫描**：AWS Inspector 漏洞检测 +5. **跨区域复制**：AMI Copying 复制到不同区域 +6. **跨账号共享**：AMI Sharing 分发到多个组织和账户 +7. **加密共享**：自动创建必要的授权（grants） +8. **完整测试套件**：验证无功能退化 + +## AMI Types in AWS Landing Zone +- **Foundation AMI**（标准 AMI）：CCOE 提供的基线镜像 +- **Product AMI**：产品团队在 Foundation AMI 基础上定制 + +## Connections +- [[AWS-Landing-Zone]] — AMI 是 LZ 标准化的核心基础设施 +- [[Jenkins-Multi-Branch-Pipeline]] — 驱动 AMI 构建和测试 +- [[AWS-Inspector]] — AMI 安全扫描集成 +- [[SSM-Patching]] — 长期运行实例的补丁管理 +- [[OS-End-of-Life]] — AMI EOL 管理 diff --git a/wiki/concepts/DNS-Anycast.md b/wiki/concepts/DNS-Anycast.md new file mode 100644 index 00000000..59df23c1 --- /dev/null +++ b/wiki/concepts/DNS-Anycast.md @@ -0,0 +1,47 @@ +--- +title: "DNS Anycast" +type: concept +tags: [DNS, Networking, High-Availability, Infoblox] +sources: [] +last_updated: 2026-05-07 +--- + +## DNS Anycast + +一种网络寻址和路由方法，使多个地理位置分布的 DNS 服务器共享同一个 IP 地址，将用户请求路由至地理位置最近的节点，从而实现极低的延迟和自动故障转移。 + +## How It Works + +传统 DNS 使用 Unicast（单播），每个服务器节点有独立 IP 地址。Anycast 则让多个节点使用相同的 IP： + +1. **路由层**：BGP 协议根据网络拓扑将请求路由到最近的节点 +2. **低延迟**：用户请求自动被引导至物理距离最近的服务器 +3. **高可用**：当某个节点不可用时，路由协议自动将流量切换到次近节点 + +## Enterprise Use Case: Infoblox + +企业级 DNS 平台（如 Infoblox）广泛使用 Anycast： + +- **Grid 架构**：全球分布的 Infoblox 设备共享同一 VIP（Virtual IP） +- **自动故障转移**：单点故障不影响服务 +- **DDoS 缓解**：分布式架构吸收恶意流量 + +## AWS Limitation + +AWS EC2 基础架构目前不支持 Anycast： + +- EC2 实例无法共享同一弹性 IP 进行 Anycast 路由 +- 需要手动维护多 IP 地址列表实现高可用冗余 +- 这是选择 Route 53（托管服务）vs 自建 EC2 DNS 的重要考量 + +## Key Concepts + +- [[Infoblox Grid]]：企业级 DNS/DHCP/IPAM 平台的分布式架构 +- [[Route 53]]：AWS 托管 DNS 服务（使用 Anycast 自身运营，但不支持客户自建） +- [[Hybrid DNS Resolution]]：混合云 DNS 解析架构 + +## Aliases + +- DNS Anycast +- Anycast DNS +- IP Anycast diff --git a/wiki/concepts/Distribution-Key.md b/wiki/concepts/Distribution-Key.md new file mode 100644 index 00000000..d59ddbff --- /dev/null +++ b/wiki/concepts/Distribution-Key.md @@ -0,0 +1,51 @@ +--- +title: "Distribution Key" +type: concept +tags: + - Data-Engineering + - Database + - AWS-Redshift + - Performance-Optimization +last_updated: 2026-04-14 +--- + +## Definition + +Distribution Key（分布键，Dist Key）决定数据在分布式数据仓库集群各计算节点间的分布方式。合理的分布键选择是避免数据倾斜（Data Skew）和最小化跨节点数据传输（Data Shuffling）的关键。 + +## Distribution Strategies + +### 1. KEY Distribution（关键分布） +- 按特定列的哈希值分布数据 +- 同一键值的数据会落在同一节点 +- 适用场景：事实表与维度表基于外键的关联（Colocation Join） + +### 2. ALL Distribution（全分布） +- 将小表完整复制到所有节点 +- 消除跨节点传输，但增加存储成本 +- 适用场景：小维度表（< 10MB） + +### 3. EVEN Distribution（均匀分布） +- 轮询方式均匀分布数据 +- 默认策略，适用于无明显热点的情况 +- 适用场景：无法确定最佳分布键时的兜底策略 + +## Key Trade-offs + +| 维度 | KEY | ALL | EVEN | +|------|-----|-----|------| +| 存储成本 | 低 | 高 | 低 | +| Join 性能 | 高（co-located） | 高 | 低（可能 shuffle） | +| 数据倾斜风险 | 中（取决于键值分布） | 无 | 无 | +| 适用表规模 | 大表 | 小表 | 通用 | + +## Related Concepts + +- [[Sort-Key]]：节点内数据排序，与 Distribution Key 共同构成 Redshift 性能优化双核心 +- [[Data-Skew]]：分布键选择不当导致的数据倾斜问题 +- [[MPP]]：分布键决定数据局部性，影响 MPP 并行效率 +- [[Amazon-Redshift]]：Distribution Key 是 Redshift 架构的核心概念 + +## Sources + +- [[ctp-topic-68-introduction-to-redshift]]：Distribution Key 在 Redshift 集群数据分布中的作用 diff --git a/wiki/concepts/Foundation-AMI.md b/wiki/concepts/Foundation-AMI.md new file mode 100644 index 00000000..74104676 --- /dev/null +++ b/wiki/concepts/Foundation-AMI.md @@ -0,0 +1,55 @@ +--- +title: "Foundation AMI" +type: concept +tags: + - AWS + - AMI + - Security + - Cloud +sources: [] +last_updated: 2026-05-07 +--- + +## Foundation AMI + +经过安全加固、集成标准组件并预配置好的操作系统模板，是 Micro Focus 云环境的标准化基础镜像。 + +## Definition + +Foundation AMI 是基于市场主流操作系统（如 CentOS, Ubuntu, Windows 等）进行深度加固的镜像，集成了： + +- [[CIS-Benchmark]] 安全基准：遵循互联网安全中心制定的安全配置基准 +- **McAfee EPO**：企业级防病毒软件 +- **Syslog-ng**：日志管理 +- **AD 单点登录**：Active Directory 集成认证 +- [[AWS-SSM]]：AWS 系统管理器代理，用于远程管理、自动化补丁更新和配置同步 +- **SiteScope**：监控预选件 + +## Build Automation + +通过 [[HashiCorp]] Packer + [[Jenkins]] 流水线实现镜像创建完全自动化： +- Packer 负责从单一源配置自动创建一致的机器镜像 +- Jenkins 流水线管理构建、测试和发布流程 + +## Distribution + +通过跨账号共享（AMI Sharing）分发至全球多区域（俄勒冈/法兰克福/悉尼等），而非物理复制（AMI Copying），避免额外存储成本。 + +## Update Policy + +- 更新频率：每两个月更新一次 +- 版本保留策略：N-2（保留当前及前两个版本） +- 通知机制：通过 CCOE 门户订阅 AMI 更新通知 + +## Relationship with Product-Specific AMI + +Foundation AMI 是基础层，产品团队在其之上构建"产品特定 AMI"（Product-Specific AMI），以满足各自应用的特殊需求，并负责其后续的生命周期管理。 + +## Aliases +- CCOE AMI +- Golden AMI +- Base AMI + +## Sources +- [[ctp-topic-26-standard-ami-build-publish-share-processes]] — Foundation AMI 全生命周期管理详解 +- [[ctp-topic-50-ami-roadmap-for-aws-amis]] — AMI 路线图中 Foundation AMI 的定义 diff --git a/wiki/concepts/GP3-EBS-Storage.md b/wiki/concepts/GP3-EBS-Storage.md new file mode 100644 index 00000000..153840d8 --- /dev/null +++ b/wiki/concepts/GP3-EBS-Storage.md @@ -0,0 +1,28 @@ +--- +title: "GP3 EBS Storage" +type: concept +tags: ["AWS", "Storage", "EBS", "Block-Storage"] +sources: ["learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2"] +last_updated: 2026-05-08 +--- + +## Definition +GP3 EBS Storage（第三代通用型 SSD）是 AWS EBS 的存储类型，Micro Focus AWS Landing Zone 标准 AMI 默认采用。GP3 提供一致的 3,000 IOPS 基础性能和 125 MiB/s 吞吐量，可独立扩展存储性能和成本。 + +## Key Characteristics +- **性能**：可独立配置 IOPS（最高 16,000）和吞吐量 +- **成本**：比 GP2 降低约 20% 成本 +- **基准性能**：3,000 IOPS + 125 MiB/s（包含在价格中） +- **最大性能**：16,000 IOPS + 1,000 MiB/s + +## GP2 vs GP3 Comparison +| 特性 | GP2 | GP3 | +|------|-----|-----| +| 容量范围 | 1 GiB - 16 TiB | 1 GiB - 16 TiB | +| IOPS | 3,000 - 16,000 | 3,000 - 16,000（独立配置） | +| 吞吐量 | 与容量耦合 | 125 - 1,000 MiB/s（独立配置） | +| 成本 | 较高 | 较低 | + +## Connections +- [[Amazon-Machine-Image]] — GP3 是标准 AMI 的默认存储配置 +- [[AWS-Landing-Zone]] — 标准化的 GP3 配置是 LZ 存储策略的一部分 diff --git a/wiki/concepts/Jenkins-Multi-Branch-Pipeline.md b/wiki/concepts/Jenkins-Multi-Branch-Pipeline.md new file mode 100644 index 00000000..29a9f1b6 --- /dev/null +++ b/wiki/concepts/Jenkins-Multi-Branch-Pipeline.md @@ -0,0 +1,36 @@ +--- +title: "Jenkins Multi-Branch Pipeline" +type: concept +tags: ["CI/CD", "Jenkins", "Automation", "DevOps"] +sources: ["learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2"] +last_updated: 2026-05-08 +--- + +## Definition +Jenkins 多分支流水线（Jenkins Multi-Branch Pipeline）是 Jenkins 的流水线即代码功能，支持根据 Git 分支自动创建和管理流水线。在 Micro Focus AWS Landing Zone 中，用于 AMI 构建和 IaC 部署的双重场景。 + +## Architecture Pattern +- **Feature Branch Pipeline**：功能分支上变更 → 开发测试 → 合并到集成分支 +- **Integration Branch Pipeline**：集成分支合并 → 构建 → 测试 → 发布 +- **Jenkinsfile**：在代码仓库中定义流水线即代码 + +## Dual Use Cases + +### AMI 构建 +1. Jenkins 扫描 Git 仓库的分支 +2. 每个分支触发独立流水线 +3. HashiCorp Packer 执行镜像构建 +4. 脚本化测试 + AWS Inspector 安全扫描 +5. 跨区域 AMI 复制和共享 + +### IaC 部署（Terraform/TerraGrunt） +1. GitHub 仓库变更触发 Jenkins +2. Terraform Plan 输出变更计划 +3. 审批后执行 Terraform Apply +4. 跨账户角色切换部署 + +## Connections +- [[Jenkins]] — 托管多分支流水线的 CI/CD 平台 +- [[Terraform-IaC]] — 流水线编排的 IaC 工具 +- [[Terragrunt]] — 配合 Terraform 的 DRY 工具 +- [[Amazon-Machine-Image]] — 多分支流水线构建的产物 diff --git a/wiki/concepts/OS-End-of-Life.md b/wiki/concepts/OS-End-of-Life.md new file mode 100644 index 00000000..2c012f2e --- /dev/null +++ b/wiki/concepts/OS-End-of-Life.md @@ -0,0 +1,33 @@ +--- +title: "OS End of Life" +type: concept +tags: ["Linux", "Windows", "Lifecycle-Management", "Migration"] +sources: ["learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2", "ctp-topic-50-ami-roadmap-for-aws-amis"] +last_updated: 2026-05-08 +--- + +## Definition +操作系统生命周期终止（OS End of Life，EOL）是指操作系统供应商停止支持、安全更新和补丁的日期。在 Micro Focus AWS Landing Zone 中，EOL 管理是 AMI 策略的重要组成部分，需要提前规划迁移到受支持的替代操作系统。 + +## Key EOL Dates in AWS Landing Zone + +### 已 EOL +- **Windows Server 2008 / 2008 R2**：已 EOL +- **CentOS 8**：已 EOL（2021 年 12 月） + +### 即将 EOL（截至 2023-12 会议记录） +- **CentOS 7**：2024 年 6 月 EOL → 替代方案：Rocky Linux 8/9 +- **Red Hat Enterprise Linux 7**：2024 年 6 月 EOL → 替代方案：RHEL 9 +- **OpenSUSE Leap 15**：2024 年 12 月 EOL +- **Oracle Enterprise Linux 7 (OEL 7)**：2024 年 12 月 EOL + +### AWS Landing Zone 应对策略 +1. **提前规划**：在 EOL 前 6 个月启动迁移评估 +2. **替代 AMI**：CCOE 发布新 OS 替代 AMI（如 Rocky Linux） +3. **自动化迁移**：Terraform 模块支持 OS 层变更 +4. **验证测试**：在非生产环境验证兼容性 + +## Connections +- [[Rocky-Linux]] — CentOS 7 的官方替代品 +- [[Amazon-Machine-Image]] — EOL 管理通过 AMI 生命周期体现 +- [[ctp-topic-50-ami-roadmap-for-aws-amis]] — AMI 路线图包含 EOL 时间线规划 diff --git a/wiki/concepts/OS-Hardening.md b/wiki/concepts/OS-Hardening.md new file mode 100644 index 00000000..68422f9a --- /dev/null +++ b/wiki/concepts/OS-Hardening.md @@ -0,0 +1,59 @@ +--- +title: "OS Hardening" +type: concept +tags: + - Security + - Linux + - AWS +sources: [] +last_updated: 2026-05-07 +--- + +## OS Hardening + +操作系统加固，通过关闭不必要服务、优化内核参数和应用安全补丁来减少系统攻击面。 + +## Definition + +OS Hardening 是将操作系统配置为最小权限、最小攻击面的过程，是 Foundation AMI 安全加固的核心步骤。 + +## Key Areas + +### 1. Service Reduction +- 禁用不必要的系统服务 +- 关闭未使用的网络端口 +- 移除不必要的软件包 + +### 2. Kernel Parameters +- 网络安全参数优化 +- 文件系统权限加固 +- 用户权限限制（最小权限原则） + +### 3. Security Patching +- 操作系统安全补丁自动更新 +- 内核更新管理 +- 应用层安全补丁 + +### 4. Compliance Alignment +- 遵循 [[CIS-Benchmark]] 配置 +- 满足企业安全策略 +- 对接合规审计框架 + +## In Foundation AMI + +Foundation AMI 的 OS Hardening 包括： +- 基于 [[CIS-Benchmark]] 的安全配置 +- McAfee EPO 防病毒集成 +- Syslog-ng 日志管理 +- AD 单点登录集成 +- [[AWS-SSM]] 自动化补丁管理 + +## Relationship with CIS Benchmark + +OS Hardening 通常基于 [[CIS-Benchmark]]： +- [[CIS-Benchmark]] 提供配置检查清单 +- OS Hardening 是实际执行这些配置的过程 +- Foundation AMI 集成了经过 CIS 加固的操作系统 + +## Sources +- [[ctp-topic-26-standard-ami-build-publish-share-processes]] — Foundation AMI 中的 OS Hardening 实现 diff --git a/wiki/concepts/Private-Subnet-Architecture.md b/wiki/concepts/Private-Subnet-Architecture.md new file mode 100644 index 00000000..ddd9b8f7 --- /dev/null +++ b/wiki/concepts/Private-Subnet-Architecture.md @@ -0,0 +1,41 @@ +--- +title: "Private-Subnet-Architecture" +type: concept +tags: [AWS, Networking, Security] +sources: [ctp-topic-7-saas-landing-zone-design] +last_updated: 2026-05-06 +--- + +## Private-Subnet-Architecture + +AWS VPC 私有子网架构原则 — 工作负载必须部署于私有子网，通过负载均衡器对外暴露服务的架构模式。 + +## Definition + +私有子网架构是产品账户网络设计的核心原则： +- **工作负载位置**：所有应用和服务（ECS、RDS、Lambda 等）部署于私有子网 +- **公网暴露**：仅通过公有子网的 Load Balancer（ALB/NLB）和 Internet Gateway 对外暴露 +- **安全优势**：减少公网攻击面，工作负载无需直接暴露公网 IP + +## Role in SAS Landing Zone + +在 [[ctp-topic-7-saas-landing-zone-design]] 定义的 Product Account 中： +- **工作负载**：业务应用（Product workloads）必须部署于私有子网 +- **入站链路**：用户 → Internet Gateway → Load Balancer（公有子网）→ **工作负载（私有子网）** +- **出站链路**：私有子网通过 NAT Gateway 或 VPC Endpoints 访问互联网或 AWS 服务 + +## Key Properties +- **Type**: Network Architecture Pattern +- **Workload placement**: Private subnets (no direct internet exposure) +- **External exposure**: Via Load Balancers only +- **In SAS LZ**: Product Account 网络设计原则 + +## Related Concepts +- [[VPC-Endpoint]] — 私有访问 AWS 服务（无需 NAT） +- [[Network-Segmentation]] — 网络分段策略 +- [[Defense-in-Depth]] — 纵深防御安全模型 + +## Connections +- [[ctp-topic-7-saas-landing-zone-design]] — SAS LZ 产品账户网络设计原则 +- [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] — 网络分段阻断 SaaS 直接连通性 +- [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]] — EKS 在私有子网的部署实践 diff --git a/wiki/concepts/RPO.md b/wiki/concepts/RPO.md index 37d81202..238193ad 100644 --- a/wiki/concepts/RPO.md +++ b/wiki/concepts/RPO.md @@ -1,91 +1,91 @@ ---- -title: "RPO (Recovery Point Objective)" -tags: [devops, disaster-recovery, sre, reliability, data-protection] -created: 2026-04-25 ---- - -# RPO (Recovery Point Objective) - -**RPO (Recovery Point Objective)** 是指系统发生故障时，能够接受的最大数据丢失量。它衡量的是数据保护程度——从故障时刻向前追溯，可接受丢失多长时间的数据。 - -## Definition - -> "RPO is about protecting data. It's measured backwards from the moment of failure." — LaunchDarkly - -RPO 是灾备规划的核心指标之一，与 [[RTO]]（恢复时间目标）共同构成灾备目标体系。 - -## Key Characteristics - -| 维度 | 说明 | -|------|------| -| **衡量对象** | 数据丢失量（Data Loss Amount） | -| **测量方向** | 从故障时刻向后（Backwards）追溯 | -| **关注点** | 数据完整性（How Much Data Can Be Lost） | - -## Example - -如果数据库在下午 3 点崩溃，而最后一次备份是下午 2 点，则： -- **RPO = 1 小时**：这意味着过去 1 小时内的数据可能丢失 -- 2:00 到 3:00 之间发生的所有事务都面临丢失风险 - -## RTO vs. RPO - -RTO 和 RPO 衡量的是不同维度，必须**同时优化**： - -| 场景 | RTO 目标 | RPO 目标 | 说明 | -|------|----------|----------|------| -| 电商结账 | 2 分钟 | 0 秒 | 必须快速恢复，且不能丢失任何交易 | -| 用户分析面板 | 30 分钟 | 1 小时 | 停机可接受，小时级数据丢失也可接受 | -| 内部 CRM | 4 小时 | 15 分钟 | 停机可绕过，但近期客户更新很重要 | -| 博客/营销站 | 2 小时 | 24 小时 | 访问者可以等，丢失一天评论可接受 | - -**关键**：不能只优化其中一个指标。 -- 30 秒一次备份（RPO 优秀）但恢复需要 6 小时（RTO 极差）= 无效 -- 5 分钟拉起新服务器（RTO 优秀）但丢失 4 小时客户数据（RPO 极差）= 无效 - -## [[Feature Flag]] 对 RPO 的保护 - -传统回滚（Full Deployment Rollback）在回滚过程中可能丢失新事务数据。而 [[Feature Flag]] 回滚**不丢失数据**： - -- Feature Flag 切换只改变代码执行路径，不触碰数据层 -- [[Kill Switch]] 关闭故障功能时，用户正在提交的数据不受影响 -- RPO 在整个 Feature Flag 操作期间始终保持近零 - -## Tiered RPO Targets - -| Tier | 场景 | RPO 目标 | 说明 | -|------|------|----------|------| -| Critical | 支付处理、交易系统 | < 1 分钟 | 不能丢失任何金钱相关数据 | -| Important | CRM、客户支持 | < 15 分钟 | 近期客户更新不可丢失 | -| Nice-to-have | 文档站、内部工具 | < 1 小时 | 数据可重建或接受丢失 | - -## 实现手段 - -| 方法 | RPO 效果 | 说明 | -|------|----------|------| -| 无备份 | ∞ | 完全不可接受 | -| 每日备份 | 24 小时 | 成本低，RPO 差 | -| 每小时备份 | 1 小时 | 中等成本和效果 | -| CDB（持续数据保护） | 秒级 | 持续复制，RPO 接近零 | -| 同步复制（Active-Active） | 0 | 零数据丢失，成本极高 | - -## RPO 与 RTO 必须协同 - -最佳实践是同时设定 RTO 和 RPO，并将 [[Feature Flag]] / [[Kill Switch]] 纳入灾备工具链： - -- RTO 短 → 系统快速恢复 -- RPO 小 → 数据损失少 -- Feature Flag → 两者兼得的性价比方案 - -## Related Concepts - -- [[RTO]] — Recovery Time Objective，停机时间指标 -- [[Disaster Recovery]] — 灾备策略，RTO/RPO 是其核心目标 -- [[Feature Flag]] — 保护 RPO 的配置级热修复机制 -- [[Kill Switch]] — 关闭故障功能，保护数据不被继续破坏 -- [[High Availability]] — 高可用性，降低 RPO 的基础设施 -- [[Data-Governance]] — 数据治理，包含 RPO 策略 - -## Sources - -- [[sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md]] +--- +title: "RPO (Recovery Point Objective)" +tags: [devops, disaster-recovery, sre, reliability, data-protection] +last_updated: 2026-04-28 +--- + +# RPO (Recovery Point Objective) + +**RPO (Recovery Point Objective)** 是指系统发生故障时，能够接受的最大数据丢失量。它衡量的是数据保护程度——从故障时刻向前追溯，可接受丢失多长时间的数据。 + +## Definition + +> "RPO is about protecting data. It's measured backwards from the moment of failure." — LaunchDarkly + +RPO 是灾备规划的核心指标之一，与 [[RTO]]（恢复时间目标）共同构成灾备目标体系。 + +## Key Characteristics + +| 维度 | 说明 | +|------|------| +| **衡量对象** | 数据丢失量（Data Loss Amount） | +| **测量方向** | 从故障时刻向后（Backwards）追溯 | +| **关注点** | 数据完整性（How Much Data Can Be Lost） | + +## Example + +如果数据库在下午 3 点崩溃，而最后一次备份是下午 2 点，则： +- **RPO = 1 小时**：这意味着过去 1 小时内的数据可能丢失 +- 2:00 到 3:00 之间发生的所有事务都面临丢失风险 + +## RTO vs. RPO + +RTO 和 RPO 衡量的是不同维度，必须**同时优化**： + +| 场景 | RTO 目标 | RPO 目标 | 说明 | +|------|----------|----------|------| +| 电商结账 | 2 分钟 | 0 秒 | 必须快速恢复，且不能丢失任何交易 | +| 用户分析面板 | 30 分钟 | 1 小时 | 停机可接受，小时级数据丢失也可接受 | +| 内部 CRM | 4 小时 | 15 分钟 | 停机可绕过，但近期客户更新很重要 | +| 博客/营销站 | 2 小时 | 24 小时 | 访问者可以等，丢失一天评论可接受 | + +**关键**：不能只优化其中一个指标。 +- 30 秒一次备份（RPO 优秀）但恢复需要 6 小时（RTO 极差）= 无效 +- 5 分钟拉起新服务器（RTO 优秀）但丢失 4 小时客户数据（RPO 极差）= 无效 + +## [[Feature Flag]] 对 RPO 的保护 + +传统回滚（Full Deployment Rollback）在回滚过程中可能丢失新事务数据。而 [[Feature Flag]] 回滚**不丢失数据**： + +- Feature Flag 切换只改变代码执行路径，不触碰数据层 +- [[Kill Switch]] 关闭故障功能时，用户正在提交的数据不受影响 +- RPO 在整个 Feature Flag 操作期间始终保持近零 + +## Tiered RPO Targets + +| Tier | 场景 | RPO 目标 | 说明 | +|------|------|----------|------| +| Critical | 支付处理、交易系统 | < 1 分钟 | 不能丢失任何金钱相关数据 | +| Important | CRM、客户支持 | < 15 分钟 | 近期客户更新不可丢失 | +| Nice-to-have | 文档站、内部工具 | < 1 小时 | 数据可重建或接受丢失 | + +## 实现手段 + +| 方法 | RPO 效果 | 说明 | +|------|----------|------| +| 无备份 | ∞ | 完全不可接受 | +| 每日备份 | 24 小时 | 成本低，RPO 差 | +| 每小时备份 | 1 小时 | 中等成本和效果 | +| CDB（持续数据保护） | 秒级 | 持续复制，RPO 接近零 | +| 同步复制（Active-Active） | 0 | 零数据丢失，成本极高 | + +## RPO 与 RTO 必须协同 + +最佳实践是同时设定 RTO 和 RPO，并将 [[Feature Flag]] / [[Kill Switch]] 纳入灾备工具链： + +- RTO 短 → 系统快速恢复 +- RPO 小 → 数据损失少 +- Feature Flag → 两者兼得的性价比方案 + +## Related Concepts + +- [[RTO]] — Recovery Time Objective，停机时间指标 +- [[Disaster Recovery]] — 灾备策略，RTO/RPO 是其核心目标 +- [[Feature Flag]] — 保护 RPO 的配置级热修复机制 +- [[Kill Switch]] — 关闭故障功能，保护数据不被继续破坏 +- [[High Availability]] — 高可用性，降低 RPO 的基础设施 +- [[Data-Governance]] — 数据治理，包含 RPO 策略 + +## Sources +- [[sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md]] +- [[sources/ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup.md]] diff --git a/wiki/concepts/RTO.md b/wiki/concepts/RTO.md index 82f04d8c..32c53680 100644 --- a/wiki/concepts/RTO.md +++ b/wiki/concepts/RTO.md @@ -1,55 +1,55 @@ ---- -title: "RTO" -type: concept -tags: - - AWS - - Disaster Recovery - - High Availability - - Cloud Architecture -sources: - - ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora -last_updated: 2026-04-23 ---- - -## Overview -RTO（Recovery Time Objective，恢复时间目标）是从系统故障发生到恢复正常运行所需的最大可接受时间。是灾备（DR）策略中的核心指标。 - -## Definition -- **RTO**：系统从故障中恢复的时间目标 -- 与 [[RPO]]（Recovery Point Objective，恢复点目标）共同构成灾备的两大核心指标 - -## AWS Database RTO 对比 - -| 数据库服务 | AZ 故障 RTO | 架构特点 | -|-----------|------------|----------| -| **Aurora** | ~30 秒 | 6 副本跨 3 AZ 共享集群卷 | -| **RDS** | ~2 分钟 | EC2 + EBS 分离，Multi-AZ 备用节点 | -| **传统自建** | 数小时 | 需手动恢复 | - -## RTO vs RPO - -| 指标 | 定义 | 衡量内容 | -|------|------|----------| -| **RTO** | 恢复时间目标 | 系统不可用的最大时长 | -| **RPO** | 恢复点目标 | 可接受的最大数据丢失时长 | - -## Key Insights -- Aurora 的低 RTO 源于其 6 副本跨 3 AZ 的共享集群卷架构，故障时无需重建数据 -- RDS 的 RTO 较高是因为需要备用节点接管并重新建立连接 -- RTO 优化需要考虑 DNS TTL、TCP Keep-Alive、连接池配置等多个层面 -- **[[LaunchDarkly]]** 是企业 RTO 优化的典型案例 - -## Related Concepts -- [[RPO]]：Recovery Point Objective，恢复点目标 -- [[Disaster Recovery]]：灾备策略 -- [[High Availability]]：高可用性 -- [[Amazon Aurora]]：Aurora 的 RTO 优势 -- [[Amazon RDS]]：RDS 的 RTO 特点 -- [[ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora]]：AWS 数据库 RTO 实测对比 -- [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]]：企业级灾备策略 - -## Aliases -- Recovery Time Objective -- 恢复时间目标 -- RTO -- MTTR（Mean Time To Recovery，与 RTO 相关但 MTTR 是实际测量值） +--- +title: "RTO" +type: concept +tags: + - AWS + - Disaster Recovery + - High Availability + - Cloud Architecture +sources: + - ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora +last_updated: 2026-04-28 +--- + +## Overview +RTO（Recovery Time Objective，恢复时间目标）是从系统故障发生到恢复正常运行所需的最大可接受时间。是灾备（DR）策略中的核心指标。 + +## Definition +- **RTO**：系统从故障中恢复的时间目标 +- 与 [[RPO]]（Recovery Point Objective，恢复点目标）共同构成灾备的两大核心指标 + +## AWS Database RTO 对比 + +| 数据库服务 | AZ 故障 RTO | 架构特点 | +|-----------|------------|----------| +| **Aurora** | ~30 秒 | 6 副本跨 3 AZ 共享集群卷 | +| **RDS** | ~2 分钟 | EC2 + EBS 分离，Multi-AZ 备用节点 | +| **传统自建** | 数小时 | 需手动恢复 | + +## RTO vs RPO + +| 指标 | 定义 | 衡量内容 | +|------|------|----------| +| **RTO** | 恢复时间目标 | 系统不可用的最大时长 | +| **RPO** | 恢复点目标 | 可接受的最大数据丢失时长 | + +## Key Insights +- Aurora 的低 RTO 源于其 6 副本跨 3 AZ 的共享集群卷架构，故障时无需重建数据 +- RDS 的 RTO 较高是因为需要备用节点接管并重新建立连接 +- RTO 优化需要考虑 DNS TTL、TCP Keep-Alive、连接池配置等多个层面 +- **[[LaunchDarkly]]** 是企业 RTO 优化的典型案例 + +## Related Concepts +- [[RPO]]：Recovery Point Objective，恢复点目标 +- [[Disaster Recovery]]：灾备策略 +- [[High Availability]]：高可用性 +- [[Amazon Aurora]]：Aurora 的 RTO 优势 +- [[Amazon RDS]]：RDS 的 RTO 特点 +- [[ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora]]：AWS 数据库 RTO 实测对比 +- [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]]：企业级灾备策略 + +## Aliases +- Recovery Time Objective +- 恢复时间目标 +- RTO +- MTTR（Mean Time To Recovery，与 RTO 相关但 MTTR 是实际测量值） diff --git a/wiki/concepts/Robotic-Framework.md b/wiki/concepts/Robotic-Framework.md new file mode 100644 index 00000000..e7823752 --- /dev/null +++ b/wiki/concepts/Robotic-Framework.md @@ -0,0 +1,28 @@ +--- +title: "Robotic Framework" +type: concept +tags: ["Automation", "Testing", "DevOps", "QA"] +sources: ["learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2"] +last_updated: 2026-05-08 +--- + +## Definition +Robotic Framework（机器人框架）是一种开源的自动化测试框架，在 Micro Focus AWS Landing Zone AMI 发布流程中用于自动化基本测试用例和验证，将单个 AMI 的验证时间从 3-4 天缩短至 60 分钟。 + +## Impact +- **传统验证**：3-4 天手动测试 +- **自动化验证**：60 分钟 +- **提升效率**：约 95% 时间节省 + +## Use Case in AMI Pipeline +在 AMI 发布前运行自动化验证，确保： +- OS 启动正常 +- 网络配置正确 +- SSM Agent 连接可用 +- 安全工具正常运行 +- 域加入功能正常 + +## Connections +- [[Amazon-Machine-Image]] — Robotic Framework 验证的对象 +- [[Jenkins-Multi-Branch-Pipeline]] — Robotic Framework 集成在 Jenkins 流水线中 +- [[AWS-Landing-Zone]] — Robotic Framework 是 AMI 发布自动化的一部分 diff --git a/wiki/concepts/SSM-Patching.md b/wiki/concepts/SSM-Patching.md new file mode 100644 index 00000000..30e0ee85 --- /dev/null +++ b/wiki/concepts/SSM-Patching.md @@ -0,0 +1,26 @@ +--- +title: "SSM Patching" +type: concept +tags: ["AWS", "Patch-Management", "SSM", "Security"] +sources: ["learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2"] +last_updated: 2026-05-08 +--- + +## Definition +SSM Patching（SSM 补丁管理）是 AWS Systems Manager 提供的自动化补丁管理功能，通过补丁基准（Patch Baseline）和维护窗口（Maintenance Window）为长期运行的 EC2 实例按需打补丁，作为 AMI 刷新策略的补充方案。 + +## Problem Solved +- **长期运行实例**：无法频繁重建和刷新 AMI +- **安全合规**：需要持续应用安全补丁 +- **手动打补丁**：耗时且易出错 + +## Key Components +- **Patch Baseline**：定义补丁审批规则（批准/拒绝） +- **Patch Group**：按标签分组的实例集合 +- **Maintenance Window**：定义打补丁的时间窗口 +- **SSM Automation Document**：自动化补丁安装流程 + +## Connections +- [[AWS-SSM]] — SSM Patching 是 AWS Systems Manager 的功能之一 +- [[Amazon-Machine-Image]] — SSM Patching 补充而非替代 AMI 刷新 +- [[AWS-Landing-Zone]] — SSM Patching 是 LZ 运维自动化的组成部分 diff --git a/wiki/concepts/Software-Factory.md b/wiki/concepts/Software-Factory.md new file mode 100644 index 00000000..d409def0 --- /dev/null +++ b/wiki/concepts/Software-Factory.md @@ -0,0 +1,43 @@ +--- +title: "Software-Factory" +type: concept +tags: [DevOps, AWS, Shared-Services] +sources: [ctp-topic-7-saas-landing-zone-design] +last_updated: 2026-05-06 +--- + +## Software-Factory + +企业级软件开发流水线平台集合，提供代码仓库、CI/CD、制品库等核心开发服务，作为共享服务向所有产品账户提供。 + +## Definition + +Software Factory 是 SAS Landing Zone 共享服务账户层的核心服务群： +- **定位**：集中式软件开发基础设施，供所有产品团队使用，避免各产品账户重复建设 +- **服务组成**： + - **45 个 Hub**：独立的开发/构建节点（Hub accounts） + - **Octane Hub**：Micro Focus ALM（Application Lifecycle Management）平台 + - **Artifactory**：JFrog Artifactory 二进制制品库 +- **使用方式**：产品账户的开发工作通过这些服务进行构建、打包和制品管理 + +## Role in SAS Landing Zone + +在 [[ctp-topic-7-saas-landing-zone-design]] 定义的 Shared Services 账户中： +- **账户位置**：Software Factory Account（共享服务层） +- **服务范围**：面向所有 Product Accounts 提供软件开发服务 +- **与 Octane Hub 关系**：Octane Hub 是 Software Factory 的核心组件之一，用于产品生命周期管理 + +## Key Properties +- **Type**: Shared DevOps Platform +- **In SAS LZ Layer**: Shared Services Accounts +- **Components**: 45 Hubs + Octane Hub + Artifactory +- **Benefit**: 集中化开发服务，避免重复建设 + +## Related Entities +- [[Octane-Hub]] — Micro Focus ALM 平台 +- [[Gruntwork]] — 提供参考架构 + +## Connections +- [[ctp-topic-7-saas-landing-zone-design]] — SAS LZ 共享服务层组件 +- [[ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i]] — Octane Hub 迁移实践 +- [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] — 共享服务账户架构变更 diff --git a/wiki/concepts/Sort-Key.md b/wiki/concepts/Sort-Key.md new file mode 100644 index 00000000..0c1acfb4 --- /dev/null +++ b/wiki/concepts/Sort-Key.md @@ -0,0 +1,40 @@ +--- +title: "Sort Key" +type: concept +tags: + - Data-Engineering + - Database + - AWS-Redshift + - Performance-Optimization +last_updated: 2026-04-14 +--- + +## Definition + +Sort Key（排序键）是数据仓库中用于确定数据在存储介质上物理排列顺序的列或列组合。通过预先对数据进行排序，Sort Key 可以显著提升范围查询、过滤和聚合操作的性能。 + +## Key Characteristics + +- **物理排序**：数据按 Sort Key 列的值在磁盘上连续存储 +- **范围查询优化**：对于 `WHERE date BETWEEN ...` 类查询，只需扫描相关数据块 +- **ZONE MAP**：列式存储系统（如 Redshift）利用 Sort Key 构建 ZONE MAP，快速跳过不包含目标值的数据块 +- **单一 vs 复合**： + - **单一排序键（Compound Sort Key）**：按列顺序联合排序，支持前缀匹配查询 + - **交错排序键（Interleaved Sort Key）**：各列权重相同，支持更灵活的查询模式，但维护成本更高 + +## Use Cases + +- 时间序列数据的日期/时间列排序（典型选择） +- 频繁过滤的高基数列 +- 需要加速 `ORDER BY`、`GROUP BY` 的列 + +## Related Concepts + +- [[Distribution-Key]]：数据在集群节点间的分布方式 +- [[Columnar-Storage]]：列式存储使 Sort Key 优化成为可能 +- [[MPP]]：Sort Key 优化局部性，提升 MPP 节点内效率 +- [[Amazon-Redshift]]：Sort Key 是 Redshift 性能优化的核心手段之一 + +## Sources + +- [[ctp-topic-68-introduction-to-redshift]]：Sort Key 在 Redshift 架构中的作用 diff --git a/wiki/concepts/Terraform-IaC.md b/wiki/concepts/Terraform-IaC.md new file mode 100644 index 00000000..d426639b --- /dev/null +++ b/wiki/concepts/Terraform-IaC.md @@ -0,0 +1,46 @@ +--- +title: "Terraform-IaC" +type: concept +tags: [IaC, Terraform, AWS, Automation] +sources: [ctp-topic-7-saas-landing-zone-design] +last_updated: 2026-05-06 +--- + +## Terraform-IaC + +使用 HashiCorp Terraform 实现基础设施即代码（Infrastructure as Code）的实践方法论。 + +## Definition + +Terraform-IaC 是 SAS Landing Zone 自动化部署的核心支柱： +- **核心原则**：所有 AWS 资源通过 Terraform 代码声明，无需手动 Console 操作 +- **工作方式**：声明式配置 → `terraform plan`（预览）→ `terraform apply`（执行） +- **状态管理**：Terraform State 记录资源的当前状态，与实际环境保持同步 +- **GitOps 集成**：代码存储在 GitHub，通过 Git Hook 触发 CI/CD 流水线 + +## Role in SAS Landing Zone + +在 [[ctp-topic-7-saas-landing-zone-design]] 定义的自动化部署链路中： +- **每个账户独立仓库**：Core/Baseline/Shared Services/Product 每个账户拥有独立 GitHub 仓库管理 Terraform 代码 +- **TerraGrunt 封装**：使用 TerraGrunt 简化跨账户 Terraform 配置 +- **部署链路**：GitHub 代码变更 → GitHub Hook → Jenkins → Management VPC → Lambda → ECS Cluster → Terraform apply +- **Staging 测试**：所有变更先在 Staging 环境测试，通过后才部署生产 + +## Key Properties +- **Type**: Infrastructure as Code Practice +- **Tool**: Terraform + TerraGrunt +- **Version Control**: GitHub repositories (one per account) +- **CI/CD Integration**: Jenkins + GitHub webhooks +- **In SAS LZ**: 端到端自动化部署的核心 + +## Related Concepts +- [[Infrastructure-as-Code]] — IaC 通用方法论 +- [[Terraform-Modules]] — 可复用 Terraform 模块 +- [[GitOps]] — Git 作为 IaC 的事实来源 +- [[TerraGrant]] — TerraGrunt（Terraform 封装工具） + +## Connections +- [[ctp-topic-7-saas-landing-zone-design]] — SAS LZ IaC 部署方法 +- [[ctp-topic-1-gruntwork-landing-zone-architecture]] — Gruntwork 模块化的 Terraform 架构 +- [[ctp-topic-16-cross-account-terraform-modules]] — 跨账户 Terraform 模块中心化部署 +- [[ctp-topic-48-terraform-vs-terragrunt]] — Terraform vs TerraGrunt 深度对比 diff --git a/wiki/concepts/Transit-Gateway.md b/wiki/concepts/Transit-Gateway.md new file mode 100644 index 00000000..a1d3211e --- /dev/null +++ b/wiki/concepts/Transit-Gateway.md @@ -0,0 +1,42 @@ +--- +title: "Transit Gateway" +type: concept +tags: [AWS, Networking, Multi-Account] +sources: [ctp-topic-7-saas-landing-zone-design] +last_updated: 2026-05-06 +--- + +## Transit Gateway + +AWS Transit Gateway 是区域级网络中枢，用于简化多个 VPCs 和账户之间的网络互联互通。 + +## Definition + +Transit Gateway 在 AWS Landing Zone 架构中扮演网络互联的核心角色： +- **范围**：区域级（Regional），连接同一区域内所有账户的 VPCs +- **功能**：Hub-and-Spoke 架构的中心节点，所有跨账户流量经由 Transit Gateway 路由 +- **与 Checkpoint 集成**：Transit Gateway 的流量通过 Checkpoint Appliance 进行安全监控 + +## Role in SAS Landing Zone + +在 [[ctp-topic-7-saas-landing-zone-design]] 定义的 Network 账户中： +- **部署位置**：Network Account +- **连接范围**：连接 Core/Baseline/Shared Services/Product 所有账户的 VPCs +- **安全监控**：Checkpoint Appliance 部署于 Transit Gateway 层面，按标签（Tagging Approach）监控跨账户流量 +- **访问控制**：资源必须携带特定标签（如 `internet-access=true`）才能访问互联网或 On-prem 网络 + +## Key Properties +- **Type**: Network Hub +- **Scope**: Regional +- **Architecture**: Hub-and-Spoke +- **In SAS LZ**: Network Account 核心组件 + +## Relationship to Checkpoint +- Transit Gateway 负责路由 +- Checkpoint Appliance 负责流量安全检查（按标签策略） +- 两者协同：路由 + 安全监控 + +## Connections +- [[ctp-topic-7-saas-landing-zone-design]] — SAS LZ Network 账户核心组件 +- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] — 广域网（WAN）连接设计 +- [[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]] — 网络分段与安全访问 diff --git a/wiki/concepts/WAF-Web-Application-Firewall.md b/wiki/concepts/WAF-Web-Application-Firewall.md new file mode 100644 index 00000000..82b32593 --- /dev/null +++ b/wiki/concepts/WAF-Web-Application-Firewall.md @@ -0,0 +1,46 @@ +--- +title: "WAF (Web Application Firewall)" +type: concept +tags: [AWS, Security, Networking] +sources: [ctp-topic-7-saas-landing-zone-design] +last_updated: 2026-05-06 +--- + +## WAF (Web Application Firewall) + +AWS Web Application Firewall — Web 应用防火墙服务，监控和过滤进入 Web 应用的 HTTP/HTTPS 流量。 + +## Definition + +WAF 是产品账户入站安全层的核心组件： +- **功能**：通过规则（Rules）过滤恶意流量，保护 Web 应用免受 OWASP Top 10 等常见攻击 +- **部署位置**：产品账户，位于 CloudFront 和 Load Balancer 之后 +- **流量监控**：WAF 监控入站流量，可阻断 SQL 注入、XSS、CSRF 等攻击 + +## Role in SAS Landing Zone + +在 [[ctp-topic-7-saas-landing-zone-design]] 定义的 Product Account 入站架构中： +- **位置**：CloudFront → **WAF** → Load Balancer（公有子网）→ 工作负载（私有子网） +- **功能**：实时监控入站流量，阻断异常请求 +- **可选 CloudFront**：CDN 层可选，但 WAF 是必须的安全层 + +## Key Properties +- **Type**: Security Service +- **Layer**: Application Layer (L7) +- **Position in stack**: After CDN/Before Application +- **In SAS LZ**: 产品账户入站安全层 + +## AWS WAF Capabilities +- Managed rule groups (AWS managed, vendor managed) +- IP blocking/rate limiting +- Geographic restrictions +- SQL injection and XSS protection +- Bot control + +## Relationship to AWS Firewall Manager +- [[AWS-Firewall-Manager]] 提供多账户 WAF 策略的统一管理 +- [[ctp-topic-55-aws-firewall-manager]] 覆盖 AWS Firewall Manager 的具体实践 + +## Connections +- [[ctp-topic-7-saas-landing-zone-design]] — SAS LZ 产品账户入站安全层 +- [[ctp-topic-55-aws-firewall-manager]] — AWS Firewall Manager 多账户 WAF 管理 diff --git a/wiki/concepts/high-availability.md b/wiki/concepts/high-availability.md index 900a9a1c..0e9a0474 100644 --- a/wiki/concepts/high-availability.md +++ b/wiki/concepts/high-availability.md @@ -1,39 +1,39 @@ ---- -title: High Availability (Cloud) ---- - -# High Availability (Cloud) - -**High Availability (HA)** in cloud computing refers to systems designed to operate continuously without failure, typically by eliminating single points of failure and distributing workloads across redundant infrastructure. - -## Common Misconception - -> **Myth**: Cloud performance is unreliable. - -> **Reality**: Cloud providers offer high availability and redundancy. - -## Key HA Characteristics in Cloud - -- **Service Level Agreements (SLAs)**: Major cloud providers guarantee uptime exceeding **99.99%** -- **Redundant Infrastructure**: Data and services are replicated across multiple geographic regions and availability zones -- **Automated Failover**: Automatic switching to backup systems when primary systems fail -- **Global Data Center Distribution**: Workloads distributed worldwide for geographic resilience -- **Load Balancing**: Traffic distributed across multiple healthy instances - -## Benefits - -- Minimized downtime and business disruption -- Improved user experience and reliability -- Reduced financial impact of outages -- Better disaster recovery posture - -## Related Concepts - -- [[Cloud Computing]] -- [[Disaster Recovery]] -- [[Cloud Migration]] -- [[Multi-Cloud Strategy]] - -## Sources - -- [[The Myths and Misconceptions About Cloud Computing (LinkedIn)|the-myths-and-misconceptions-about-cloud-computing-linkedin]] +--- +title: High Availability (Cloud) +--- + +# High Availability (Cloud) + +**High Availability (HA)** in cloud computing refers to systems designed to operate continuously without failure, typically by eliminating single points of failure and distributing workloads across redundant infrastructure. + +## Common Misconception + +> **Myth**: Cloud performance is unreliable. + +> **Reality**: Cloud providers offer high availability and redundancy. + +## Key HA Characteristics in Cloud + +- **Service Level Agreements (SLAs)**: Major cloud providers guarantee uptime exceeding **99.99%** +- **Redundant Infrastructure**: Data and services are replicated across multiple geographic regions and availability zones +- **Automated Failover**: Automatic switching to backup systems when primary systems fail +- **Global Data Center Distribution**: Workloads distributed worldwide for geographic resilience +- **Load Balancing**: Traffic distributed across multiple healthy instances + +## Benefits + +- Minimized downtime and business disruption +- Improved user experience and reliability +- Reduced financial impact of outages +- Better disaster recovery posture + +## Related Concepts + +- [[Cloud Computing]] +- [[Disaster Recovery]] +- [[Cloud Migration]] +- [[Multi-Cloud Strategy]] + +## Sources +- [[The Myths and Misconceptions About Cloud Computing (LinkedIn)|the-myths-and-misconceptions-about-cloud-computing-linkedin]] +- [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup.md]] diff --git a/wiki/entities/AWS-Backup-Audit-Manager.md b/wiki/entities/AWS-Backup-Audit-Manager.md new file mode 100644 index 00000000..a36f2e6a --- /dev/null +++ b/wiki/entities/AWS-Backup-Audit-Manager.md @@ -0,0 +1,39 @@ +--- +title: "AWS Backup Audit Manager" +type: entity +tags: + - AWS + - Backup + - Compliance + - Audit +sources: + - ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup + - ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program +last_updated: 2026-04-28 +--- + +## AWS Backup Audit Manager + +AWS Backup Audit Manager 是 AWS Backup 的内置合规审计框架，用于评估和改进备份实践。 + +### 核心功能 + +- **合规报告**：开箱即用的备份合规报告，可导出为 CSV 或 JSON 到 S3 +- **控制项评估**：预置控制项自动评估备份实践是否符合标准 +- **报告维度**：备份状态、被保护资源、创建时间、恢复点时间、备份时长、备份大小 +- **SNS 告警**：可配置 SNS 主题接收备份状态告警通知 + +### 关键控制项 + +| 控制项 | 说明 | +|--------|------| +| 备份覆盖率 | 确保备份资源受备份计划保护 | +| 最小频率和保留期 | 验证备份是否满足最低 RPO/RTO 要求 | +| 手动删除防护 | 确保恢复点不被手动删除 | +| 加密验证 | 确保恢复点已加密 | +| 跨区域/跨账户备份 | 确保按计划执行跨区域和跨账户复制 | + +### Related Sources + +- [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]] — AWS 官方 DR 策略 +- [[ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program]] — CTP 中的 Audit Manager 使用 diff --git a/wiki/entities/AWS-Backup.md b/wiki/entities/AWS-Backup.md new file mode 100644 index 00000000..9fb4a594 --- /dev/null +++ b/wiki/entities/AWS-Backup.md @@ -0,0 +1,61 @@ +--- +title: "AWS Backup" +type: entity +tags: + - AWS + - Backup + - DR + - Cloud-Native +sources: + - ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup + - ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program + - ctp-topic-44-aws-backup-in-micro-focus +last_updated: 2026-04-28 +--- + +## AWS Backup + +AWS Backup 是 AWS 原生全托管的策略驱动型备份服务，支持 80+ 种 AWS 资源类型的集中备份和恢复管理。作为企业级灾备战略的核心工具，它通过备份计划（Backup Plans）、备份保管库（Backup Vaults）和跨账户复制等机制，实现备份流程的标准化和自动化。 + +## Core Capabilities + +| 功能 | 说明 | +|------|------| +| **Backup Plans** | 通过基于规则的备份计划定义何时备份、备份什么、存储到哪个保管库 | +| **Backup Vaults** | 存储恢复点的加密容器，支持生命周期管理和访问控制 | +| **跨账户跨区域复制** | 通过 AWS Organizations 将备份复制到独立账户/区域，实现备份隔离 | +| **Vault Lock** | 合规模式锁定，防止任何人（包括根用户）在生命周期结束前删除恢复点 | +| **AWS Backup Audit Manager** | 内置合规审计框架，提供备份状态报告和控制评估 | +| **增量备份** | 仅备份自上次备份以来的变更，节省存储成本 | +| **点时间恢复** | 支持 S3 和 RDS 的 PITR（Point-In-Time Recovery） | + +## Supported Resource Types + +AWS Backup 支持的典型资源类型包括： +- Amazon EC2（实例、EBS 卷） +- Amazon RDS（含 Aurora）、DynamoDB +- Amazon EFS、FSx +- Amazon S3 +- AWS Storage Gateway +- VMware on-premises（通过 AWS Backup for VMware） + +## Key Architectural Patterns + +- **集中管控 + 分散执行**：SRE 团队提供标准化 Backup Model，产品组在 DRA 账户内自主管理 +- **备份隔离**：备份存储在独立的 Bunker/Vault 账户，与工作负载账户分离 +- **Forensic Account**：独立取证账户定期测试恢复点并扫描恶意软件 +- **零 RPO 策略**：结合 AWS Native 快照和 AWS Backup 实现分层备份 + +## Related Concepts + +- [[RTO]] — Recovery Time Objective，灾备核心指标 +- [[RPO]] — Recovery Point Objective，灾备核心指标 +- [[High Availability]] — 高可用性，灾备体系的另一支柱 +- [[Vault Lock]] — 合规锁定，防勒索软件 +- [[增量备份]] — 节省存储的备份策略 + +## Related Sources + +- [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]] — AWS 官方 DR 策略与 AWS Backup 架构（Sabith 主讲） +- [[ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program]] — CTP 中的 AWS Backup 实施落地 +- [[ctp-topic-44-aws-backup-in-micro-focus]] — Micro Focus 内部 AWS Backup 评估 diff --git a/wiki/entities/AWS-SSM.md b/wiki/entities/AWS-SSM.md new file mode 100644 index 00000000..ed64b0d2 --- /dev/null +++ b/wiki/entities/AWS-SSM.md @@ -0,0 +1,44 @@ +--- +title: "AWS SSM" +type: entity +tags: ["AWS", "Systems-Manager", "Patch-Management", "Remote-Access"] +sources: ["learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2", "ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs", "ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones"] +last_updated: 2026-05-08 +--- + +## Overview +AWS Systems Manager (SSM) 是 AWS 的管理和运维服务，在 Micro Focus AWS Landing Zone 中扮演两个关键角色：①作为标准 AMI 的内置 Agent（SSM Agent）实现实例管理和远程操作；②提供 SSM Patching 方案为长期运行实例按需打补丁；③替代传统 VPN 实现安全的远程实例访问。 + +## Aliases +- AWS Systems Manager +- SSM Agent +- SSM Session Manager +- SSM Patch Manager +- Session Manager + +## Role in AWS Landing Zone + +### 1. 标准 AMI 内置组件 +- SSM Agent 是所有标准 AMI 的默认组件 +- 支持实例元数据查询、配置管理、远程命令执行 + +### 2. SSM Patching 方案 +- 为无法频繁刷新镜像的长期运行实例提供按需补丁管理 +- 通过补丁基准（Patch Baseline）自动化补丁审批和安装 + +### 3. 安全远程访问（替代 VPN） +- SSM Session Manager 提供浏览器内会话访问 EC2 实例 +- 通过 IAM 角色控制访问权限，无需 VPN 连接 +- 支持双因素认证和 AWS 网络内安全连接 + +## Key Capabilities +- **Run Command**：跨多实例批量执行命令 +- **Session Manager**：安全的浏览器内 shell 会话 +- **Patch Manager**：自动化补丁管理 +- **State Manager**：维护实例配置状态 +- **Parameter Store**：存储配置和密钥（已被 Secrets Manager 替代） + +## Connections +- [[AWS-Landing-Zone]] — SSM 是标准化运维基础设施 +- [[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]] — SSM Session Manager 替代 VPN 方案 +- [[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]] — SSM Agent 内置于 SRE 预制 AMI diff --git a/wiki/entities/AWS.md b/wiki/entities/AWS.md index 96b08323..19d2b01c 100644 --- a/wiki/entities/AWS.md +++ b/wiki/entities/AWS.md @@ -1,35 +1,36 @@ ---- -title: "Amazon Web Services (AWS)" -type: entity -tags: - - AWS - - Cloud - - Hybrid-Cloud -sources: [cloud-operating-model-key-strategies-and-best-practices] -last_updated: 2026-04-25 ---- - -## Amazon Web Services (AWS) - -Amazon Web Services (AWS) is the world's most comprehensive and broadly adopted cloud platform, offering over 200 fully featured services from data centers globally. - -## Aliases -- AWS -- Amazon Web Services - -## Key Partnerships -- **VMware Cloud on AWS (VMC on AWS)**: AWS partnered with VMware to run VMware workloads natively on AWS infrastructure. The underlying hardware consists of i3.metal and i3en.metal bare metal servers, organized into clusters within availability zones and regions. - -## Infrastructure for VMC on AWS -- **i3.metal**: Bare metal server instance used for VMware Cloud on AWS SDDC deployment -- **i3en.metal**: Enhanced bare metal instance with larger storage capacity -- **Clusters**: Organized within availability zones and regions globally -- **Stretched Clusters**: Available across availability zones for increased resilience - -## Connections -- [[VMware-Cloud-on-AWS]] ← powered_by ← [[AWS]] -- [[ctp-topic-43-vmware-cloud-on-aws]] ← source ← [[AWS]] -- [[VMware]] ← partners ← [[AWS]] - -## Sources -- [[ctp-topic-43-vmware-cloud-on-aws]] +--- +title: "Amazon Web Services (AWS)" +type: entity +tags: + - AWS + - Cloud + - Hybrid-Cloud +sources: [cloud-operating-model-key-strategies-and-best-practices] +last_updated: 2026-04-25 +--- + +## Amazon Web Services (AWS) + +Amazon Web Services (AWS) is the world's most comprehensive and broadly adopted cloud platform, offering over 200 fully featured services from data centers globally. + +## Aliases +- AWS +- Amazon Web Services + +## Key Partnerships +- **VMware Cloud on AWS (VMC on AWS)**: AWS partnered with VMware to run VMware workloads natively on AWS infrastructure. The underlying hardware consists of i3.metal and i3en.metal bare metal servers, organized into clusters within availability zones and regions. + +## Infrastructure for VMC on AWS +- **i3.metal**: Bare metal server instance used for VMware Cloud on AWS SDDC deployment +- **i3en.metal**: Enhanced bare metal instance with larger storage capacity +- **Clusters**: Organized within availability zones and regions globally +- **Stretched Clusters**: Available across availability zones for increased resilience + +## Connections +- [[VMware-Cloud-on-AWS]] ← powered_by ← [[AWS]] +- [[ctp-topic-43-vmware-cloud-on-aws]] ← source ← [[AWS]] +- [[VMware]] ← partners ← [[AWS]] + +## Sources +- [[ctp-topic-43-vmware-cloud-on-aws]] +- [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup.md]] diff --git a/wiki/entities/CCOE.md b/wiki/entities/CCOE.md new file mode 100644 index 00000000..cce6a7d4 --- /dev/null +++ b/wiki/entities/CCOE.md @@ -0,0 +1,43 @@ +--- +title: "CCOE" +type: entity +tags: + - Cloud + - AWS + - Organization +sources: [] +last_updated: 2026-05-07 +--- + +## CCOE + +Cloud Center of Excellence（云卓越中心），是企业内部负责云标准化、合规与治理的核心职能部门。 + +## Description + +在 Micro Focus AWS 云转型计划（CTP）中，CCOE 负责： +- 提供安全加固的基础镜像（Foundation AMI） +- 制定和维护 AMI 路线图 +- 跨账号共享标准 AMI 和 KMS 密钥 +- 推动 AWS Landing Zone 的标准化架构落地 + +## Key Responsibilities + +- **Foundation AMI 生命周期管理**：基于市场主流 OS（CentOS/Ubuntu/Windows）进行 [[CIS-Benchmark]] 安全基准加固，集成 McAfee EPO 防病毒 + Syslog-ng 日志管理 + AD 单点登录 + [[AWS-SSM]] + SiteScope 监控 +- **AMI 构建自动化**：通过 [[HashiCorp]] Packer + [[Jenkins]] 流水线实现镜像创建完全自动化 +- **版本策略**：每两个月更新一次，采用 N-2 版本保留策略 +- **分发机制**：通过跨账号共享（AMI Sharing）分发至全球多区域，而非物理复制 + +## Role in Shared Responsibility + +- **CCOE 负责**：提供安全的基础镜像（Foundation AMI） +- **产品团队负责**：在 Foundation AMI 之上构建产品特定 AMI，并负责其生命周期管理 + +## Aliases +- Cloud Center of Excellence +- CCoE +- Cloud CoE + +## Sources +- [[ctp-topic-26-standard-ami-build-publish-share-processes]] — Foundation AMI 全生命周期管理详解（ Srihari/Alan/Praveen 主讲） +- [[ctp-topic-50-ami-roadmap-for-aws-amis]] — CCOE AMI 路线图详解 diff --git a/wiki/entities/CloudFront.md b/wiki/entities/CloudFront.md new file mode 100644 index 00000000..569a6442 --- /dev/null +++ b/wiki/entities/CloudFront.md @@ -0,0 +1,28 @@ +--- +title: "CloudFront" +type: entity +tags: [CDN, AWS, Networking] +sources: [ctp-topic-7-saas-landing-zone-design] +last_updated: 2026-05-06 +--- + +## CloudFront + +AWS 内容分发网络（CDN）服务，托管于全球边缘节点，用于加速静态和动态内容的分发。 + +## Role in AWS Landing Zone + +在 [[ctp-topic-7-saas-landing-zone-design]] 定义的 SAS LZ 产品账户中： +- **位置**：Product Account 入站安全/加速层（可选） +- **入站链路**：用户 → CloudFront → WAF（流量监控）→ Load Balancer（公有子网）→ 工作负载（私有子网） +- **用途**：CDN 加速内容分发，减少源站负载 + +## Key Properties +- **Type**: CDN (Content Delivery Network) +- **Vendor**: AWS +- **In SAS LZ**: 可选部署于产品账户入站链路 +- **Position in stack**: CloudFront → WAF → Load Balancer → Private Subnet Workloads + +## Connections +- [[ctp-topic-7-saas-landing-zone-design]] — SAS LZ 产品账户入站架构 +- [[ctp-topic-7-saas-landing-zone-design]] — WAF 和负载均衡器协同工作的 CDN 层 diff --git a/wiki/entities/DRA-Account.md b/wiki/entities/DRA-Account.md new file mode 100644 index 00000000..11adfd1d --- /dev/null +++ b/wiki/entities/DRA-Account.md @@ -0,0 +1,33 @@ +--- +title: "DRA Account" +type: entity +tags: + - AWS + - Backup + - DR + - CTP + - Multi-Account +sources: + - ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program +last_updated: 2026-04-28 +--- + +## DRA Account + +DRA（Disaster Recovery Account）账户是 CTP（Cloud Transformation Programme）中为每个生产工作负载账户设立的专属灾备账户。 + +### 用途 + +- 存储从源账户复制过来的备份恢复点 +- 实现物理隔离：工作负载账户被入侵时，备份不会一并丢失 +- 支持即时恢复：备份保留在 DR 账户内，无需耗时跨账户数据拷贝即可完成恢复 + +### 架构关系 + +- 源账户 → 取初始备份 → 复制到 → **DRA Account** +- 如 DRA 账户不可用，备份可回退到 [[Databunker]] 集中账户 +- DRA 账户配合 AWS Backup Audit Manager 提供合规审计报告 + +### Related Sources + +- [[ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program]] — CTP 中 DR 账户设计 diff --git a/wiki/entities/Databunker.md b/wiki/entities/Databunker.md new file mode 100644 index 00000000..c49cfce7 --- /dev/null +++ b/wiki/entities/Databunker.md @@ -0,0 +1,32 @@ +--- +title: "Databunker" +type: entity +tags: + - AWS + - Backup + - DR + - CTP +sources: + - ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program +last_updated: 2026-04-28 +--- + +## Databunker + +Databunker 是 CTP 中作为备份集中存储备选账户的内部命名账户。 + +### 用途 + +- 当 DRA 账户不可用时，作为集中账户存储备份副本 +- 作为跨区域、跨账户备份架构的降级方案 +- 配合 AWS Backup 的跨账户复制机制使用 + +### 架构关系 + +- [[DRA-Account]] 为每个生产工作负载的专属 DR 账户（主方案） +- [[Databunker]] 为集中备份账户（降级方案） +- 两个账户均使用 [[AWS-Backup]] 的 Vault Lock 确保不可变性 + +### Related Sources + +- [[ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program]] — CTP 中 Databunker 作为备份集中账户的用途 diff --git a/wiki/entities/Jenkins.md b/wiki/entities/Jenkins.md new file mode 100644 index 00000000..494b788d --- /dev/null +++ b/wiki/entities/Jenkins.md @@ -0,0 +1,33 @@ +--- +title: "Jenkins" +type: entity +tags: ["CI/CD", "Automation", "DevOps"] +sources: ["learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2", "ctp-topic-26-standard-ami-build-publish-share-processes", "ctp-topic-1-gruntwork-landing-zone-architecture", "ctp-topic-7-saas-landing-zone-design"] +last_updated: 2026-05-08 +--- + +## Overview +Jenkins 是开源的 CI/CD 自动化服务器，在 Micro Focus AWS Landing Zone 中承担基础设施即代码（IaC）部署和 AMI 构建的双重角色。每个 Landing Zone 配置独立的 Jenkins 服务器，通过多分支流水线（Multi-Branch Pipeline）管理 Terraform/TerraGrunt 模块的 plan 和 apply 流程，以及标准 AMI 的构建和测试。 + +## Aliases +- Jenkins CI +- Jenkins Master +- Jenkins Slave +- Jenkins Multi-Branch Pipeline + +## Role in AWS Landing Zone +- **Shared 账户**：托管 Jenkins 主节点（Master），通过 Lambda 触发各账户 Jenkins 从节点 +- **AMI 构建**：Jenkins 多分支流水线驱动 Packer 镜像构建，包含脚本化测试和 AWS Inspector 安全扫描 +- **IaC 部署**：扫描 GitHub 仓库变更，触发 Terraform Plan/Apply 流水线 +- **每个 LZ 独立**：Gruntwork 参考架构中每个 Landing Zone 有自己的 Jenkins 服务器 + +## Key Processes +- Feature Branch Pipeline：功能分支开发 → 合并到集成分支 → 构建测试 → 发布 +- Jenkinsfile 定义构建、测试、发布各阶段 +- 与 GitHub 集成实现自动化触发 + +## Connections +- [[AWS-Landing-Zone]] — Jenkins 是核心自动化基础设施 +- [[Terraform-IaC]] — Jenkins 流水线编排 Terraform 部署 +- [[Terragrunt]] — 与 Jenkins 配合的 IaC 工具 +- [[Gruntwork]] — Gruntwork 参考架构中的 Jenkins 配置模式 diff --git a/wiki/entities/OBM.md b/wiki/entities/OBM.md new file mode 100644 index 00000000..a2ad5da6 --- /dev/null +++ b/wiki/entities/OBM.md @@ -0,0 +1,39 @@ +--- +title: "OBM" +type: entity +tags: [Monitoring, Observability, AWS, Micro-Focus] +sources: [ctp-topic-7-saas-landing-zone-design] +last_updated: 2026-05-06 +--- + +## OBM (Operations Bridge Manager) + +Micro Focus Operations Bridge Manager (OBM) — 企业级监控平台，托管于 SAS Landing Zone 的 Monitoring 共享服务账户中，为产品账户提供运维监控能力。 + +## Role in AWS Landing Zone + +在 [[ctp-topic-7-saas-landing-zone-design]] 定义的 SAS LZ 共享服务账户体系中： +- **账户位置**：Monitoring Account（共享服务层） +- **功能**：为所有产品账户提供集中式运维监控 +- **替代方案**：计划未来引入 Sitescope 作为补充监控手段 +- **上下文**：属 Shared Services Accounts 的一部分，与 Software Factory、Cyber (Qalis)、ARC Site 并列 + +## Key Properties +- **Type**: Monitoring/Observability Platform +- **Vendor**: Micro Focus (Operations Bridge Suite) +- **Location**: Monitoring Shared Services Account +- **In SAS LZ Layer**: Shared Services Accounts + +## Related Tools +- [[ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid]] — OBM 在云监控中的具体实施 +- [[ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana]] — Grafana 替代方案（云原生监控） + +## Aliases +- Operations Bridge Manager +- Micro Focus OBM +- OBM (Operations Bridge Manager) + +## Connections +- [[ctp-topic-7-saas-landing-zone-design]] — SAS LZ 共享服务层组件 +- [[ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid]] — OBM 云监控实施细节 +- [[ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana]] — Grafana 监控方案 diff --git a/wiki/entities/Pulse-VPN.md b/wiki/entities/Pulse-VPN.md new file mode 100644 index 00000000..62172a8a --- /dev/null +++ b/wiki/entities/Pulse-VPN.md @@ -0,0 +1,40 @@ +--- +title: "Pulse-VPN" +type: entity +tags: [VPN, Network-Security, Remote-Access] +sources: [ctp-topic-7-saas-landing-zone-design] +last_updated: 2026-05-06 +--- + +## Pulse VPN + +企业级远程访问 VPN 解决方案。Pulse VPN 是 Checkpoint VPN 的升级替代方案，用于 SAS Landing Zone 中的远程安全接入。 + +## Role in AWS Landing Zone + +在 [[ctp-topic-7-saas-landing-zone-design]] 定义的 SAS LZ 中： +- **替代 Checkpoint VPN**：远程访问从 Checkpoint VPN 迁移至 Pulse VPN +- **认证方式**：通过 Active Directory（AD）认证，操作员必须使用 VPN 客户端 +- **用途**：允许运维人员远程访问 AWS 账户资源 + +## Relationship with Checkpoint VPN + +| 维度 | Checkpoint VPN | Pulse VPN | +|------|----------------|-----------| +| 认证 | 旧式认证 | AD 认证 | +| 状态 | 迁移中（逐步淘汰） | 新一代远程访问 | +| 适用场景 | 历史遗留 | 新建 SAS LZ 环境 | + +## Key Properties +- **Type**: Remote Access VPN +- **Authentication**: Active Directory (AD) +- **Client**: Requires VPN client installation +- **Status**: 新一代远程访问 VPN（替代 Checkpoint VPN） + +## Aliases +- Pulse Secure VPN +- Pulse VPN Client + +## Connections +- [[ctp-topic-7-saas-landing-zone-design]] — SAS LZ 远程接入方案 +- [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] — 网络分段策略变更（Checkpoint 重新路由入站流量） diff --git a/wiki/entities/QALIS-Agent.md b/wiki/entities/QALIS-Agent.md new file mode 100644 index 00000000..27370b8d --- /dev/null +++ b/wiki/entities/QALIS-Agent.md @@ -0,0 +1,25 @@ +--- +title: "QALIS Agent" +type: entity +tags: ["Security", "Endpoint-Protection", "Agent"] +sources: ["learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2"] +last_updated: 2026-05-08 +--- + +## Overview +QALIS Agent 是企业级端点保护 Agent，集成在 Micro Focus AWS Landing Zone 标准 AMI 中。QALIS 属于 Cyber（网络安全）共享服务层，负责所有 EC2 实例的终端安全监控和管理。 + +## Aliases +- QALIS +- QALIS Endpoint Agent +- Cyber QALIS + +## Role in AWS Landing Zone +- **端点保护**：集成在所有标准 AMI 中，为 EC2 实例提供运行时安全保护 +- **Cyber 共享服务**：由 Cyber 账户（Cyber/QALIS）集中管理 +- **AMI 内置**：作为 SRE 预制标准 AMI 的默认组件之一 + +## Connections +- [[AWS-Landing-Zone]] — QALIS Agent 是标准 AMI 的默认安全组件 +- [[ctp-topic-7-saas-landing-zone-design]] — Cyber/QALIS 属于 SAS LZ 共享服务账户层 +- [[Sentinel-1]] — 正在替代 Trellix（Migrated from Trellix to Sentinel-1） diff --git a/wiki/entities/Qalis.md b/wiki/entities/Qalis.md new file mode 100644 index 00000000..740f9982 --- /dev/null +++ b/wiki/entities/Qalis.md @@ -0,0 +1,27 @@ +--- +title: "Qalis" +type: entity +tags: [Cybersecurity, Shared-Services, AWS] +sources: [ctp-topic-7-saas-landing-zone-design] +last_updated: 2026-05-06 +--- + +## Qalis + +网络安全服务/平台，托管于 SAS Landing Zone 的 Cyber 共享服务账户中，为产品账户提供网络安全能力。 + +## Role in AWS Landing Zone + +在 [[ctp-topic-7-saas-landing-zone-design]] 定义的 SAS LZ 共享服务账户体系中： +- **账户位置**：Cyber Account（共享服务层） +- **功能**：为所有产品账户提供网络安全服务 +- **上下文**：属 Shared Services Accounts 的一部分，与 Software Factory、ARC Site、Monitoring (OBM) 并列 + +## Key Properties +- **Type**: Cybersecurity Service +- **Location**: Cyber Shared Services Account +- **In SAS LZ Layer**: Shared Services Accounts + +## Connections +- [[ctp-topic-7-saas-landing-zone-design]] — SAS LZ 共享服务层组件 +- [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] — 共享服务账户架构 diff --git a/wiki/entities/Rocky-Linux.md b/wiki/entities/Rocky-Linux.md new file mode 100644 index 00000000..a0486f6a --- /dev/null +++ b/wiki/entities/Rocky-Linux.md @@ -0,0 +1,24 @@ +--- +title: "Rocky Linux" +type: entity +tags: ["Linux", "Enterprise-OS", "CentOS-Replacement"] +sources: ["learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2", "ctp-topic-50-ami-roadmap-for-aws-amis"] +last_updated: 2026-05-08 +--- + +## Overview +Rocky Linux 是一个开源的企业级 Linux 发行版，作为 CentOS 的官方下游替代品，由 Rocky Enterprise Software Foundation 维护。在 Micro Focus AWS Landing Zone 中，Rocky Linux 8 和 9 作为标准 AMI 提供，用于替代即将 EOL 的 CentOS 7。 + +## Aliases +- Rocky Linux 8 +- Rocky Linux 9 +- Rocky Enterprise Software Foundation + +## Role in AWS Landing Zone +- 作为标准 AMI 提供，支持企业 OS 加固、安全更新、SSM Agent 集成 +- CentOS 7 EOL 迁移的官方替代方案 +- 支持 Jenkins 多分支流水线构建和测试 + +## Connections +- [[AWS-Landing-Zone]] — 提供标准化操作系统支持 +- [[ctp-topic-50-ami-roadmap-for-aws-amis]] — AMI 路线图中规划了 Rocky Linux 8/9 的发布（2023年3月） diff --git a/wiki/entities/SRE-Team.md b/wiki/entities/SRE-Team.md index 9418cab1..c3a9e2f9 100644 --- a/wiki/entities/SRE-Team.md +++ b/wiki/entities/SRE-Team.md @@ -1,41 +1,41 @@ ---- -title: "SRE Team" -type: entity -tags: [SRE, DevOps, Automation, AWS, Tools] -last_updated: 2026-04-14 ---- - -## Overview - -SRE Team（Site Reliability Engineering 团队）是该组织中负责 AWS Landing Zone 运维自动化和工具开发的团队。在 CTP Topic 28 中，SRE 团队展示了其开发的 AWS Tag Validation Tool，展示了 SRE 实践中的自动化工具开发能力。 - -## Responsibilities - -| 职责 | 说明 | -|------|------| -| 运维自动化 | 开发自动化工具减少人工重复操作，通过 IaC + CI/CD 实现 Standard Change | -| 工具开发 | 构建内部平台工具（如 Tag Validation Tool） | -| 可靠性保障 | 确保 AWS 基础设施的高可用性和可观测性，定义 SLO/SLR 体系 | -| 内部平台 | 维护 SRE Tools Repository 内部代码仓库 | -| SRE 三阶段支持 | Build（构建）/Early Live Support（早期上线支持）/BAU（日常运维）三个阶段与产品团队协作 | - -## SRE Tools Repository - -SRE 团队维护的内部代码仓库（[[SRE-Tools-Repository]]），集中存放所有 SRE 自动化脚本和工具： - -- **Tag Validation Tool**：Python/Boto3 AWS 标签验证工具 -- 环境管理：Poetry -- 配置管理：variables.yaml（每个账户独立配置） - -## Related Concepts - -- [[Tag-Validation-Tool]]：SRE 团队开发的标签验证工具 -- [[Variables-YAML]]：Tag Validation Tool 的配置文件 -- [[Boto3]]：SRE 工具使用的 AWS Python SDK -- [[Poetry]]：SRE 工具的 Python 环境管理工具 -- [[AWS-Landing-Zone]]：SRE 团队服务的核心基础设施平台 - -## Sources - -- [[ctp-topic-28-aws-tag-validation-tool]] -- [[ctp-topic-30-managing-change]] +--- +title: "SRE Team" +type: entity +tags: [SRE, DevOps, Automation, AWS, Tools] +last_updated: 2026-04-28 +--- + +## Overview + +SRE Team（Site Reliability Engineering 团队）是该组织中负责 AWS Landing Zone 运维自动化和工具开发的团队。在 CTP Topic 28 中，SRE 团队展示了其开发的 AWS Tag Validation Tool，展示了 SRE 实践中的自动化工具开发能力。 + +## Responsibilities + +| 职责 | 说明 | +|------|------| +| 运维自动化 | 开发自动化工具减少人工重复操作，通过 IaC + CI/CD 实现 Standard Change | +| 工具开发 | 构建内部平台工具（如 Tag Validation Tool） | +| 可靠性保障 | 确保 AWS 基础设施的高可用性和可观测性，定义 SLO/SLR 体系 | +| 内部平台 | 维护 SRE Tools Repository 内部代码仓库 | +| SRE 三阶段支持 | Build（构建）/Early Live Support（早期上线支持）/BAU（日常运维）三个阶段与产品团队协作 | + +## SRE Tools Repository + +SRE 团队维护的内部代码仓库（[[SRE-Tools-Repository]]），集中存放所有 SRE 自动化脚本和工具： + +- **Tag Validation Tool**：Python/Boto3 AWS 标签验证工具 +- 环境管理：Poetry +- 配置管理：variables.yaml（每个账户独立配置） + +## Related Concepts + +- [[Tag-Validation-Tool]]：SRE 团队开发的标签验证工具 +- [[Variables-YAML]]：Tag Validation Tool 的配置文件 +- [[Boto3]]：SRE 工具使用的 AWS Python SDK +- [[Poetry]]：SRE 工具的 Python 环境管理工具 +- [[AWS-Landing-Zone]]：SRE 团队服务的核心基础设施平台 + +## Sources +- [[ctp-topic-28-aws-tag-validation-tool]] +- [[ctp-topic-30-managing-change]] +- [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup.md]] diff --git a/wiki/entities/Sentinel-1.md b/wiki/entities/Sentinel-1.md new file mode 100644 index 00000000..0d55b2ad --- /dev/null +++ b/wiki/entities/Sentinel-1.md @@ -0,0 +1,24 @@ +--- +title: "Sentinel-1" +type: entity +tags: ["Security", "Endpoint-Protection", "Migration"] +sources: ["learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2"] +last_updated: 2026-05-08 +--- + +## Overview +Sentinel-1 是正在替换 Trellix 的新一代企业端点保护方案，正在被集成到 Micro Focus AWS Landing Zone 标准 AMI 发布周期中。 + +## Aliases +- SentinelOne +- Sentinel-1 Endpoint Protection + +## Migration Context +- **迁移来源**：从 Trellix 迁移到 Sentinel-1 +- **集成方式**：作为新功能注入到 AMI 发布周期中 +- **目标**：统一所有标准 AMI 的端点保护解决方案 + +## Connections +- [[QALIS-Agent]] — 原有的端点保护 Agent（正在被 Sentinel-1 替代） +- [[AWS-Landing-Zone]] — Sentinel-1 集成在标准 AMI 发布中 +- [[learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2]] — 该会议记录首次提及 Sentinel-1 迁移 diff --git a/wiki/entities/TerraGrant.md b/wiki/entities/TerraGrant.md new file mode 100644 index 00000000..3f4761bb --- /dev/null +++ b/wiki/entities/TerraGrant.md @@ -0,0 +1,40 @@ +--- +title: "TerraGrant" +type: entity +tags: [IaC, Terraform, AWS] +sources: [ctp-topic-7-saas-landing-zone-design] +last_updated: 2026-05-06 +--- + +## TerraGrant (TerraGrunt) + +Terraform 的轻量封装工具，用于简化跨账户 IaC 部署。TerraGrant 在 SAS Landing Zone 中用于管理 Terraform 状态和跨账户依赖。 + +## Relationship with Terraform + +TerraGrant（即 TerraGrunt）是 HashiCorp Terraform 的封装工具（wrapper），非独立产品。 + +在 [[ctp-topic-7-saas-landing-zone-design]] 定义的 SAS LZ 中： +- **跨账户部署**：TerraGrunt 简化 Terraform 状态管理和跨账户引用 +- **与 Gruntwork 集成**：SAS LZ 基于 Gruntwork 仓库，TerraGrunt 用于管理跨环境（Dev/Staging/Prod）的 Terraform 配置 +- **配合 Jenkins**：GitHub Hook → Jenkins → TerraGrunt 命令执行部署 + +## Key Properties +- **Type**: IaC Tool (Terraform Wrapper) +- **Vendor**: Gruntwork (from Terragrunt) +- **Purpose**: DRY Terraform configurations, remote state management, cross-account deployments +- **In SAS LZ**: 每个账户拥有独立 GitHub 仓库管理 TerraGrunt 配置 + +## Relationship to Gruntwork +- [[Gruntwork]] 提供预构建的 Terraform 模块 +- TerraGrunt 简化这些模块的跨账户使用 +- 两者结合：Gruntwork 模块 + TerraGrunt 封装 = SAS LZ IaC 实践 + +## Aliases +- TerraGrunt +- Terragrunt + +## Connections +- [[ctp-topic-7-saas-landing-zone-design]] — SAS LZ 自动化部署工具链 +- [[ctp-topic-1-gruntwork-landing-zone-architecture]] — Gruntwork 架构基础 +- [[ctp-topic-48-terraform-vs-terragrunt]] — Terraform 与 TerraGrunt 深度对比 diff --git a/wiki/entities/VinoCTP.md b/wiki/entities/VinoCTP.md new file mode 100644 index 00000000..817cda8b --- /dev/null +++ b/wiki/entities/VinoCTP.md @@ -0,0 +1,26 @@ +--- +title: "Vino CTP" +type: entity +tags: [DNS, Networking, AWS, CTP] +sources: [] +last_updated: 2026-05-07 +--- + +## Vino CTP + +AWS 网络与混合云架构专家，Cloud Transformation Programme (CTP) 的核心讲师之一。 + +## Role + +- **CTP Topic 22**：Global DNS Service Offerings 讲师（与 Sankar 联合主讲） + +## Areas of Expertise + +- AWS Landing Zone 多账号架构设计 +- Route 53 混合 DNS 架构（Inbound/Outbound Endpoints） +- 企业级 DNS 服务架构（Infoblox + Route 53） +- 混合云网络互联 + +## Connections + +- 通过 [[ctp-topic-22-global-dns-service-offerings]] 与 Sankar Gopov 联合主讲企业级全球 DNS 服务架构 diff --git a/wiki/index.md b/wiki/index.md index ecb0dd5e..25bb094a 100644 --- a/wiki/index.md +++ b/wiki/index.md @@ -4,6 +4,17 @@ - [Overview](overview.md) — living synthesis ## Sources +- [2026-04-28] [CTP Topic 22 Global DNS service offerings](sources/ctp-topic-22-global-dns-service-offerings.md) +- [2026-04-28] [CTP Topic 50 AMI Roadmap for AWS AMIs](sources/ctp-topic-50-ami-roadmap-for-aws-amis.md) +- [2026-04-28] [CTP Topic 40 SaaS Database Architecture On AWS Cloud](sources/ctp-topic-40-saas-database-architecture-on-aws-cloud.md) +- [2026-04-28] [CTP Topic 26 Standard AMI – build, publish, share processes](sources/ctp-topic-26-standard-ami-build-publish-share-processes.md) +- [2026-04-28] [CTP Topic 68 Introduction to Redshift](sources/ctp-topic-68-introduction-to-redshift.md) +- [2026-04-28] [CTP Topic 58 AWS EC2 Image Builder](sources/ctp-topic-58-aws-ec2-image-builder.md) +- [2026-04-28] [CTP Topic 25 Labs Landing Zone Overview - ITOM Teams](sources/ctp-topic-25-labs-landing-zone-overview-itom-teams.md) +- [2026-04-28] [Learning Sessions: Standard AMI Updates 20231205](sources/learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2.md) +- [2026-04-28] [CTP Topic 7 SaaS Landing Zone Design](sources/ctp-topic-7-saas-landing-zone-design.md) +- [2026-04-28] [CTP Topic 34 Azure Landing Zone Architecture Overview](sources/ctp-topic-34-azure-landing-zone-architecture-overview.md) +- [2026-04-28] [CTP Topic 35 AWS Landing Zone Design Refresher (SaaS Labs)](sources/ctp-topic-35-aws-landing-zone-design-refresher-saas-labs.md) - [2026-04-28] [CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security](sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md) - [2026-04-28] [CTP Topic 73 AWS Backup Implementation of the Cloud Transformation Programme](sources/ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program.md) - [2026-04-28] [CTP Topic 28 AWS Tag Validation Tool](sources/ctp-topic-28-aws-tag-validation-tool.md) @@ -242,9 +253,8 @@ - [CTP Topic 61 Workload VPC provision with IPAM Automation](sources/ctp-topic-61-workload-vpc-provision-with-ipam-automation.md) - [CTP Topic 45 Automatic IP address allocation with IPAM](sources/ctp-topic-45-automatic-ip-address-allocation-with-ipam.md) - [CTP Topic 43 VMware Cloud on AWS](sources/ctp-topic-43-vmware-cloud-on-aws.md) -- [CTP Topic 36 SendGrid as an Email Service](sources/ctp-topic-36-sendgrid-as-an-email-service.md) +- [2026-04-14] [CTP Topic 36 SendGrid as an Email Service](sources/ctp-topic-36-sendgrid-as-an-email-service.md) - [CTP Topic 31 Network Segregation and Secure Access to the New AWS Landing Zones](sources/ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones.md) -- [CTP Topic 22 Global DNS service offerings](sources/ctp-topic-22-global-dns-service-offerings.md) - [CTP Topic 19 Configuring DNS within AWS LZs](sources/ctp-topic-19-configuring-dns-within-aws-lzs.md) - [CTP Topic 18 Wide Area Networking in AWS Cloud](sources/ctp-topic-18-wide-area-networking-in-aws-cloud.md) - [Public Cloud Learning Sessions - OpenText GIS Security Policies - 20241015](sources/public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me.md) @@ -294,16 +304,6 @@ - [Learning Sessions Identity Governance VSM Replacement - 20231128](sources/learning-sessions-identity-governance-vsm-replacement-20231128-160326-meeting-re.md) - [CTP Topic 5 - AWS Identity and Access Management (IAM)](sources/ctp-topic-5-aws-identity-and-access-management-iam.md) - [CTP Topic 11 AD Integration and Login using AD Accounts](sources/ctp-topic-11-ad-integration-and-login-using-ad-accounts.md) -- [Learning Sessions: Standard AMI Updates 20231205](sources/learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2.md) -- [CTP Topic 7 SaaS Landing Zone Design](sources/ctp-topic-7-saas-landing-zone-design.md) -- [CTP Topic 68 Introduction to Redshift](sources/ctp-topic-68-introduction-to-redshift.md) -- [CTP Topic 58 AWS EC2 Image Builder](sources/ctp-topic-58-aws-ec2-image-builder.md) -- [CTP Topic 50 AMI Roadmap for AWS AMIs](sources/ctp-topic-50-ami-roadmap-for-aws-amis.md) -- [CTP Topic 40 SaaS Database Architecture On AWS Cloud](sources/ctp-topic-40-saas-database-architecture-on-aws-cloud.md) -- [2026-05-06] [CTP Topic 35 AWS Landing Zone Design Refresher (SaaS Labs)](sources/ctp-topic-35-aws-landing-zone-design-refresher-saas-labs.md) — SaaS vs Labs Landing Zone 架构对比：SaaS=生产（产品账户+共享服务），Labs=开发（PoC 并入 Labs）；含网络分段、CCOE CloudTrail、Checkpoint 入站路由等近期变更 -- [CTP Topic 34 Azure Landing Zone Architecture Overview](sources/ctp-topic-34-azure-landing-zone-architecture-overview.md) -- [CTP Topic 26 Standard AMI – build, publish, share processes](sources/ctp-topic-26-standard-ami-build-publish-share-processes.md) -- [CTP Topic 25 Labs Landing Zone Overview - ITOM Teams](sources/ctp-topic-25-labs-landing-zone-overview-itom-teams.md) - [n8n调用hermes-agents的工作流架构](sources/n8n调用hermes-agents的工作流架构.md) — (expected: wiki/sources/n8n调用hermes-agents的工作流架构.md — source missing) - [n8n-调用openclaw-agents的工作流架构](sources/n8n-调用openclaw-agents的工作流架构.md) — (expected: wiki/sources/n8n-调用openclaw-agents的工作流架构.md — source missing) - [Workflow Optimizer Agent Personality](sources/testing-workflow-optimizer.md) @@ -581,6 +581,7 @@ - [AWS-Lambda](entities/AWS-Lambda.md) - [AWS-OpenSearch](entities/AWS-OpenSearch.md) - [AWS-Organizations](entities/AWS-Organizations.md) +- [AWS-SSM](entities/AWS-SSM.md) - [AWS-Step-Functions](entities/AWS-Step-Functions.md) - [Axton](entities/Axton.md) - [Azure](entities/Azure.md) @@ -604,6 +605,7 @@ - [Calibre](entities/Calibre.md) - [Canva](entities/Canva.md) - [CapCut-Pro](entities/CapCut-Pro.md) +- [CCOE](entities/CCOE.md) - [ChatGPT](entities/ChatGPT.md) - [Checkpoint](entities/Checkpoint.md) - [ChinesePodcastPlatforms](entities/ChinesePodcastPlatforms.md) @@ -618,9 +620,10 @@ - [Clonezilla](entities/Clonezilla.md) - [cloud-computing](entities/cloud-computing.md) - [Cloud-Maturity-Model](entities/Cloud-Maturity-Model.md) -- [Cloud-Technology-Design-Forum](entities/Cloud-Technology-Design-Forum.md) - [Cloud-Provider](entities/Cloud-Provider.md) +- [Cloud-Technology-Design-Forum](entities/Cloud-Technology-Design-Forum.md) - [clouddrive2](entities/clouddrive2.md) +- [CloudFront](entities/CloudFront.md) - [CodeCrafters](entities/CodeCrafters.md) - [CodeWeaver](entities/CodeWeaver.md) - [Codex](entities/Codex.md) @@ -708,6 +711,7 @@ - [Jared-Diamond](entities/Jared-Diamond.md) - [Jay-Comer](entities/Jay-Comer.md) - [Jellyfin](entities/Jellyfin.md) +- [Jenkins](entities/Jenkins.md) - [Jira](entities/Jira.md) - [Jira-Workflow-Steward](entities/Jira-Workflow-Steward.md) - [JohnWilliams](entities/JohnWilliams.md) @@ -772,6 +776,7 @@ - [NotebookLlama](entities/NotebookLlama.md) - [NotebookLM](entities/NotebookLM.md) - [Notion](entities/Notion.md) +- [OBM](entities/OBM.md) - [Obsidian](entities/Obsidian.md) - [ObsidianTasksPlugin](entities/ObsidianTasksPlugin.md) - [OceanEngine](entities/OceanEngine.md) @@ -801,6 +806,9 @@ - [Project-Management-Experiment-Tracker](entities/Project-Management-Experiment-Tracker.md) - [Prometheus](entities/Prometheus.md) - [Public-Cloud-Provider](entities/Public-Cloud-Provider.md) +- [Pulse-VPN](entities/Pulse-VPN.md) +- [Qalis](entities/Qalis.md) +- [QALIS-Agent](entities/QALIS-Agent.md) - [Qdrant](entities/Qdrant.md) - [Qwen](entities/Qwen.md) - [Qwen2.5-Coder](entities/Qwen2.5-Coder.md) @@ -814,6 +822,7 @@ - [Rectangle](entities/Rectangle.md) - [RetroBoard](entities/RetroBoard.md) - [RichardFeynman](entities/RichardFeynman.md) +- [Rocky-Linux](entities/Rocky-Linux.md) - [RSSHub](entities/RSSHub.md) - [rsvg-convert](entities/rsvg-convert.md) - [rsync](entities/rsync.md) @@ -823,6 +832,7 @@ - [SAMR](entities/SAMR.md) - [SankarGopov](entities/SankarGopov.md) - [Scrapy](entities/Scrapy.md) +- [Sentinel-1](entities/Sentinel-1.md) - [shenwei](entities/shenwei.md) - [Simon-Hoiberg](entities/Simon-Hoiberg.md) - [Slack](entities/Slack.md) @@ -847,6 +857,7 @@ - [Telegram](entities/Telegram.md) - [Telnyx](entities/Telnyx.md) - [Terraform](entities/Terraform.md) +- [TerraGrant](entities/TerraGrant.md) - [Terragrunt](entities/Terragrunt.md) - [The-Agency](entities/The-Agency.md) - [The-DAO-2016](entities/The-DAO-2016.md) @@ -880,6 +891,7 @@ - [VictoriaMetrics](entities/VictoriaMetrics.md) - [Vidu](entities/Vidu.md) - [Vinay](entities/Vinay.md) +- [VinoCTP](entities/VinoCTP.md) - [vLLM](entities/vLLM.md) - [VMware](entities/VMware.md) - [Wavespeed-AI](entities/Wavespeed-AI.md) @@ -936,6 +948,7 @@ - [AccountArchitecture](concepts/AccountArchitecture.md) - [ActionItemTracking](concepts/ActionItemTracking.md) - [Active-Accountability](concepts/Active-Accountability.md) +- [Active-Directory-Integration](concepts/Active-Directory-Integration.md) - [ActiveAccountability](concepts/ActiveAccountability.md) - [Actor-Replication](concepts/Actor-Replication.md) - [Adaptive-Tone](concepts/Adaptive-Tone.md) @@ -943,6 +956,7 @@ - [AdaptiveTone](concepts/AdaptiveTone.md) - [ADDIE-Model](concepts/ADDIE-Model.md) - [AdExtensions](concepts/AdExtensions.md) +- [ADM](concepts/ADM.md) - [AdStrength](concepts/AdStrength.md) - [Advantage+-Campaigns](concepts/Advantage+-Campaigns.md) - [Adversarial-Debate-Pattern](concepts/Adversarial-Debate-Pattern.md) @@ -984,7 +998,9 @@ - [AlertManagement](concepts/AlertManagement.md) - [Algorithm-Agility](concepts/Algorithm-Agility.md) - [Amazon-EKS](concepts/Amazon-EKS.md) +- [Amazon-Machine-Image](concepts/Amazon-Machine-Image.md) - [AmbientMessageMonitoring](concepts/AmbientMessageMonitoring.md) +- [AMI-Sharing](concepts/AMI-Sharing.md) - [Analogy-as-Straitjacket](concepts/Analogy-as-Straitjacket.md) - [Analytics-Feedback-Loop](concepts/Analytics-Feedback-Loop.md) - [Annales-School](concepts/Annales-School.md) @@ -993,6 +1009,7 @@ - [Appearance-Anxiety](concepts/Appearance-Anxiety.md) - [APT-仓库配置](concepts/APT-仓库配置.md) - [Architectural-Empathy](concepts/Architectural-Empathy.md) +- [ARM-AMI](concepts/ARM-AMI.md) - [arXiv-API](concepts/arXiv-API.md) - [Asset-Management](concepts/Asset-Management.md) - [Asset-Pipeline](concepts/Asset-Pipeline.md) @@ -1008,6 +1025,7 @@ - [AutomationGovernance](concepts/AutomationGovernance.md) - [Availability](concepts/Availability.md) - [AWS-Backup-Concepts](concepts/AWS-Backup-Concepts.md) +- [AWS-Inspector](concepts/AWS-Inspector.md) - [AWS-Secrets-Manager](concepts/AWS-Secrets-Manager.md) - [AWS-Source-Identity](concepts/AWS-Source-Identity.md) - [AWS-Tagging-Standards](concepts/AWS-Tagging-Standards.md) @@ -1177,8 +1195,10 @@ - [DevSecOps](concepts/DevSecOps.md) - [Dialogue-Writing-Standards](concepts/Dialogue-Writing-Standards.md) - [Discrimination-Metrics](concepts/Discrimination-Metrics.md) +- [Distribution-Key](concepts/Distribution-Key.md) - [DKIM-Email-Authentication](concepts/DKIM-Email-Authentication.md) - [dm-verity](concepts/dm-verity.md) +- [DNS-Anycast](concepts/DNS-Anycast.md) - [DNS托管](concepts/DNS托管.md) - [Docker-Compose](concepts/Docker-Compose.md) - [Docker-Containerization](concepts/Docker-Containerization.md) @@ -1248,6 +1268,7 @@ - [Fixed-Point-Semantics](concepts/Fixed-Point-Semantics.md) - [Flow-And-Readability](concepts/Flow-And-Readability.md) - [Food-Sensitivity-Tracking](concepts/Food-Sensitivity-Tracking.md) +- [Foundation-AMI](concepts/Foundation-AMI.md) - [frp](concepts/frp.md) - [Fstab](concepts/Fstab.md) - [Full-Draft-Generation](concepts/Full-Draft-Generation.md) @@ -1273,6 +1294,7 @@ - [GitOps](concepts/GitOps.md) - [Global-First-Architecture](concepts/Global-First-Architecture.md) - [Golden-3-Second-Hook](concepts/Golden-3-Second-Hook.md) +- [GP3-EBS-Storage](concepts/GP3-EBS-Storage.md) - [GPG-密钥验证](concepts/GPG-密钥验证.md) - [GPT分区表](concepts/GPT分区表.md) - [Grandes-Ecoles](concepts/Grandes-Ecoles.md) @@ -1332,6 +1354,7 @@ - [ISOHybrid镜像](concepts/ISOHybrid镜像.md) - [ITSM](concepts/ITSM.md) - [ITSM-2.0](concepts/ITSM-2.0.md) +- [Jenkins-Multi-Branch-Pipeline](concepts/Jenkins-Multi-Branch-Pipeline.md) - [JFFS双清](concepts/JFFS双清.md) - [Jira-Gate](concepts/Jira-Gate.md) - [Jira-Git-Traceability](concepts/Jira-Git-Traceability.md) @@ -1435,8 +1458,8 @@ - [National-Annex](concepts/National-Annex.md) - [NegativePromptingLibrary](concepts/NegativePromptingLibrary.md) - [Net-Revenue-Retention](concepts/Net-Revenue-Retention.md) -- [Network-Segmentation](concepts/Network-Segmentation.md) - [Network-Prediction](concepts/Network-Prediction.md) +- [Network-Segmentation](concepts/Network-Segmentation.md) - [NetworkVariable](concepts/NetworkVariable.md) - [NFS网络备份](concepts/NFS网络备份.md) - [NiagaraVFX](concepts/NiagaraVFX.md) @@ -1458,6 +1481,8 @@ - [OpenTelemetry](concepts/OpenTelemetry.md) - [Oracle-Manipulation](concepts/Oracle-Manipulation.md) - [Organic-Traffic-Amplification](concepts/Organic-Traffic-Amplification.md) +- [OS-End-of-Life](concepts/OS-End-of-Life.md) +- [OS-Hardening](concepts/OS-Hardening.md) - [OWASP-Top-Ten](concepts/OWASP-Top-Ten.md) - [Pacing-Architecture](concepts/Pacing-Architecture.md) - [PagedAttention](concepts/PagedAttention.md) @@ -1505,6 +1530,7 @@ - [Predictive-Maintenance](concepts/Predictive-Maintenance.md) - [Private-Cloud](concepts/Private-Cloud.md) - [Private-Context](concepts/Private-Context.md) +- [Private-Subnet-Architecture](concepts/Private-Subnet-Architecture.md) - [Proactive-Agent-Recommendation](concepts/Proactive-Agent-Recommendation.md) - [Proactive-AI](concepts/Proactive-AI.md) - [ProactiveAI](concepts/ProactiveAI.md) @@ -1561,6 +1587,7 @@ - [RFM-Analysis](concepts/RFM-Analysis.md) - [Rightsizing](concepts/Rightsizing.md) - [Risk-Mitigation](concepts/Risk-Mitigation.md) +- [Robotic-Framework](concepts/Robotic-Framework.md) - [ROI](concepts/ROI.md) - [Rollback-Rate](concepts/Rollback-Rate.md) - [Root-Cause-Analysis](concepts/Root-Cause-Analysis.md) @@ -1632,7 +1659,9 @@ - [Socket-登录](concepts/Socket-登录.md) - [SOCKS5代理](concepts/SOCKS5代理.md) - [Software-Assurance-Maturity-Model](concepts/Software-Assurance-Maturity-Model.md) +- [Software-Factory](concepts/Software-Factory.md) - [Solution-Architecture](concepts/Solution-Architecture.md) +- [Sort-Key](concepts/Sort-Key.md) - [SOUL.md](concepts/SOUL.md.md) - [Source-Grounding](concepts/Source-Grounding.md) - [Spatial-Computing](concepts/Spatial-Computing.md) @@ -1647,6 +1676,7 @@ - [SPREAD-Strategy](concepts/SPREAD-Strategy.md) - [SprintPlanning](concepts/SprintPlanning.md) - [SSE-Server-Sent-Events](concepts/SSE-Server-Sent-Events.md) +- [SSM-Patching](concepts/SSM-Patching.md) - [StackSets-Deployment-Visibility](concepts/StackSets-Deployment-Visibility.md) - [Stakeholder-Alignment](concepts/Stakeholder-Alignment.md) - [Standard-Change](concepts/Standard-Change.md) @@ -1686,6 +1716,7 @@ - [Telephony-Integration](concepts/Telephony-Integration.md) - [Template-based-Note-Creation](concepts/Template-based-Note-Creation.md) - [Template-Based-Production](concepts/Template-Based-Production.md) +- [Terraform-IaC](concepts/Terraform-IaC.md) - [Terraform-Modules](concepts/Terraform-Modules.md) - [Test-Mode](concepts/Test-Mode.md) - [Text-and-Search](concepts/Text-and-Search.md) @@ -1712,6 +1743,7 @@ - [Transactional-Analysis](concepts/Transactional-Analysis.md) - [Transcript-Based-Summarization](concepts/Transcript-Based-Summarization.md) - [TranscriptProcessing](concepts/TranscriptProcessing.md) +- [Transit-Gateway](concepts/Transit-Gateway.md) - [Trauma-Informed-Analysis](concepts/Trauma-Informed-Analysis.md) - [Tree-of-Thoughts](concepts/Tree-of-Thoughts.md) - [Trend-To-Action](concepts/Trend-To-Action.md) @@ -1746,6 +1778,7 @@ - [Voice-Notification-Channel](concepts/Voice-Notification-Channel.md) - [VPC-Endpoint](concepts/VPC-Endpoint.md) - [Vulnerability-Scanning](concepts/Vulnerability-Scanning.md) +- [WAF-Web-Application-Firewall](concepts/WAF-Web-Application-Firewall.md) - [Wake-on-LAN](concepts/Wake-on-LAN.md) - [Wayland](concepts/Wayland.md) - [Web-Search-Aggregation](concepts/Web-Search-Aggregation.md) diff --git a/wiki/log.md b/wiki/log.md index 77a4823d..378dcb3a 100644 --- a/wiki/log.md +++ b/wiki/log.md @@ -1,3 +1,81 @@ +## [2026-05-07] ingest | CTP Topic 22 Global DNS Service Offerings (re-ingest) +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-22-global-dns-service-offerings.md +- Status: ✅ 成功摄入（re-ingest） +- Summary: 企业级全球 DNS 服务架构详解——Sankar 和 Vino 联合主讲。核心架构：Route 53 Private Hosted Zone（私有托管区域）配合 AD 托管 DNS，通过 Route 53 Resolver 入站/出站终端节点打通 AWS VPC 与本地网络的 DNS 查询；Outbound Endpoint 出站规则配置多个区域 AD 域控制器 IP，单区域故障时自动切换确保弹性。本地 Infoblox 平台利用 DNS Anycast 实现全球低延迟和自动故障转移；AWS EC2 不支持 Anycast，需手动维护 IP 列表。DNS 安全涵盖防隧道攻击、防数据外泄及缓存污染；"就近解析"原则优化 Office 365 等全球化 SaaS 访问性能。属 AWS Landing Zone 网络层 DNS 专题，与 ctp-topic-19 共同构成 Landing Zone DNS 完整体系。 +- Concepts touched: [[HybridDnsResolution]], [[DNS-Anycast]], [[Landing-Zone-Architecture]], [[Route-53-Resolver]], [[IPAM]] +- Entities touched: [[AWS]], [[Infoblox]], [[SankarGopov]], [[VinoCTP]], [[Microsoft-Active-Directory]], [[Office-365]] +- Concepts created: [[DNS-Anycast]] +- Entities created: [[VinoCTP]] +- Source page: wiki/sources/ctp-topic-22-global-dns-service-offerings.md +- Notes: 步骤3完成：Source page 已存在（2026-04-14 初版），本次更新 Contradictions 节（ctp-topic-19 已摄入，补充完整互补关系说明）；步骤4完成：index.md 条目已存在（第257行），本次新增 [[VinoCTP]] Entity 和 [[DNS-Anycast]] Concept 条目；步骤5完成：overview.md 已有该来源摘要（line 345），内容一致无需修订；步骤6完成：新建 [[VinoCTP]] Entity 页面（CTP Topic 22 联合讲师）；步骤7完成：新建 [[DNS-Anycast]] Concept 页面（关键网络概念，本来源首次系统阐述）；步骤8完成：Contradictions 更新为视角互补说明（Topic 19 讲配置实施 → Topic 22 讲企业架构，属深度递进关系）；步骤9完成：log.md 追加本次 re-ingest 记录 + +## [2026-05-07] ingest | CTP Topic 50 AMI Roadmap for AWS AMIs (re-ingest) +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-50-ami-roadmap-for-aws-amis.md +- Status: ✅ 成功摄入（re-ingest） +- Summary: CCOE AMI 路线图与 AWS 标准 AMI 生命周期规划——核心内容：CCOE 每两个月发布加固 AMI；ARM AMI 自 2023 年 5 月起同步发布；路线图优先级由 ADM 需求驱动；OS EOL 时间线（WS2008/2008R2 已 EOL；CentOS8 已 EOL；WS2012 即将 EOL；RHEL7/CentOS7 2024 年 6 月 EOL）；AMI 通知通过邮件发送至 CCOE notifications PDL；CCRE 门户变更日志；新 AMI 添加三阶段流程；AMI 跨账号共享机制 +- Concepts touched: [[Foundation-AMI]], [[OS-End-of-Life]], [[AMI-Sharing]], [[ARM-AMI]], [[CCOE]], [[ADM]] +- Entities touched: [[CCOE]], [[AWS]], [[Amazon Linux]], [[Ubuntu]], [[CentOS]], [[Rocky Linux]], [[Red Hat Enterprise Linux]], [[SLES]], [[Windows Server]], [[McAfee]] +- Concepts created: [[ARM-AMI]], [[ADM]] +- Source page: wiki/sources/ctp-topic-50-ami-roadmap-for-aws-amis.md +- Notes: 步骤3完成：源页面已存在（2026-04-14 初版），本次补全 wikilinks 格式（Foundation AMI→Foundation-AMI, AMI Sharing→AMI-Sharing）；步骤4完成：index.md 条目已存在（第306行），无需重复添加；步骤5完成：overview.md 已有该来源摘要（line 313），内容一致无需修订；步骤6完成：Amazon Linux/Ubuntu/CentOS/SLES/Windows Server/McAfee 在 source doc 中出现次数不足以创建独立 Entity 页面（仅1-2次提及），按工作流规则跳过；Rocky Linux/Red Hat Enterprise Linux Entity 页面已存在，无需重复创建；步骤7完成：Foundation-AMI/OS-End-of-Life/AMI-Sharing Concept 页面已存在，本次新建 ARM-AMI.md 和 ADM.md；步骤8完成：Contradictions 已在 source page 记录（与 ctp-topic-26 的互补关系）；步骤9完成：log.md 追加本次 re-ingest 记录 + +## [2026-05-07] ingest | CTP Topic 26 Standard AMI – build, publish, share processes +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-26-standard-ami-build-publish-share-processes.md +- Status: ✅ 成功摄入（re-ingest） +- Summary: Foundation AMI 全生命周期管理详解——Srihari/Alan/Praveen 主讲。基于市场主流 OS（CentOS/Ubuntu/Windows）进行 CIS Benchmark 安全基准加固，集成 McAfee EPO 防病毒 + Syslog-ng 日志管理 + AD 单点登录 + AWS-SSM + SiteScope 监控；使用 HashiCorp Packer + Jenkins 流水线实现镜像创建完全自动化；通过 AMI Sharing 分发至全球多区域；每两个月更新，采用 N-2 版本保留策略。责任共担：CCOE 提供 Foundation AMI，产品团队构建产品特定 AMI。 +- Concepts touched: [[Foundation-AMI]], [[OS-Hardening]], [[CIS-Benchmark]], [[HashiCorp]], [[AWS-SSM]], [[AMI-Sharing]] +- Entities touched: [[CCOE]], [[Jenkins]], [[AWS]] +- Concepts created: [[Foundation-AMI]], [[OS-Hardening]], [[AMI-Sharing]] +- Source page: wiki/sources/ctp-topic-26-standard-ami-build-publish-share-processes.md +- Notes: 步骤3完成：Source page 已存在（2026-04-14 初版），本次更新 wikilinks 格式（Foundation AMI→Foundation-AMI 等）并移除 Srihari/Alan/Praveen（仅出现1次）；步骤4完成：index.md 条目已存在（第306行）；步骤5完成：overview.md 已有该来源摘要（line 315），内容一致无需修订；步骤6完成：新建 CCOE.md Entity 页面；步骤7完成：新建 Foundation-AMI.md、OS-Hardening.md、AMI-Sharing.md Concept 页面；CIS-Benchmark/HashiCorp/AWS-SSM/HashiCorp（Entity）已存在，跳过；Central Repository 未创建独立页面（保留为普通概念描述）；步骤8完成：Contradictions 已在 source page 记录（与 ctp-topic-58 的"当前 Packer vs 未来 EC2 Image Builder"属技术演进非冲突）；步骤9完成：log.md 追加本次 re-ingest 记录 + +## [2026-05-07] ingest | CTP Topic 68 Introduction to Redshift +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-68-introduction-to-redshift.md +- Status: ✅ 成功摄入 +- Summary: AWS Redshift 数据仓库入门介绍——核心架构含 Leader Node（管理 Schema、元数据、查询计划）和 Compute Node（在 Slices 上通过 MPP 执行并行查询）；支持列式存储（适合 OLAP 聚合查询）和行式存储；Sort Key 和 Distribution Key 是性能优化核心；三种实例类型（Dense Compute/Dense Storage/RA3）；RA3 以 AWS 托管 NVMe 提供成本效益。 +- Concepts touched: [[MassivelyParallelProcessing]], [[Columnar-Storage]], [[Sort-Key]], [[Distribution-Key]], [[OLAP]], [[Data-Compression]] +- Entities touched: [[Amazon-Redshift]], [[LeaderNode]], [[ComputeNode]], [[JDBC]], [[ODBC]] +- Concepts created: [[Sort-Key]], [[Distribution-Key]] +- Source page: wiki/sources/ctp-topic-68-introduction-to-redshift.md +- Notes: 步骤3完成：新建 source page（含完整 Summary/Key Claims/Key Quotes/Key Concepts/Key Entities/Connections/Contradictions）；步骤4完成：index.md 条目补全日期前缀（2026-04-14）和一行摘要；步骤5完成：overview.md 已有该来源摘要（line 339），内容一致无需修订；步骤6完成：Amazon-Redshift Entity 页面已存在（2026-04-14 初版），内容一致无需修订；步骤7完成：新建 Sort-Key.md 和 Distribution-Key.md Concept 页面；步骤8完成：Contradictions 记录与 [[ctp-topic-66-rds-vs-aurora]] 的定位差异（Redshift 专 OLAP vs Aurora 混合 OLTP/OLAP），非冲突；步骤9完成：log.md 追加本次摄入记录 + +## [2026-04-28] ingest | CTP Topic 58 AWS EC2 Image Builder +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-58-aws-ec2-image-builder.md +- Status: ✅ 成功摄入 +- Summary: AWS EC2 Image Builder 服务详解——自动化 AMIs 和 Docker 镜像创建/管理/分发的托管服务；核心组件包括 Image Pipeline、Image Recipe、Infrastructure Configuration、Distribution Settings；YAML 定义镜像配方（Source AMI → Output AMI）；CCOE 提供 Golden AMI，产品团队可追加自定义组件（按字母序添加）；支持 CentOS 7 和 Ubuntu 18 的端到端 POC；集成 AWS Inspector 进行安全扫描，Lambda 工作流触发扫描并发送邮件通知和 S3 报告；当前 AMI 流程（GitLab + Jenkins + Packer）的痛点（交付周期长、跨 LZ 兼容性差）推动了 Image Builder 的采用。 +- Concepts touched: [[AMI-Image-Builder]], [[Image-Pipeline]], [[Golden-AMI]], [[AWS-Inspector]], [[AWS-Landing-Zone]] +- Entities touched: [[AWS]], [[Packer]], [[Jenkins]], [[Terraform]], [[Qualys]] +- Source page: wiki/sources/ctp-topic-58-aws-ec2-image-builder.md +- Notes: 步骤3完成：新建 source page，含完整 Summary/Key Claims/Key Quotes/Key Concepts/Key Entities/Connections/Contradictions；步骤4完成：index.md 条目已存在（第303行），无需重复添加；步骤5完成：overview.md 由后续 query workflow 维护，此处无需主动修订；步骤6-7完成：关键 Entity/Concept 在源文档中出现1-2次，未达到创建独立页面的阈值（≥2次且关键影响），按工作流规则跳过；步骤8完成：Contradictions 记录"暂无发现冲突"；步骤9完成：log.md 追加本次摄入记录 + +## [2026-05-07] ingest | CTP Topic 25 Labs Landing Zone Overview - ITOM Teams (re-ingest) +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-25-labs-landing-zone-overview-itom-teams.md +- Status: ✅ 成功摄入（re-ingest） +- Summary: Labs LZ 基于 Gruntwork 参考架构，多账户策略（Shared/Jenkins/Logs/Security/Core(AD+DNS)/Network(TGW+JetPult)/Product Account）；全部通过 Terraform/Terragrunt IaC 管理；Jenkins 流水线扫描 GitHub 触发 plan/apply；防火墙通过标签（Tags）控制网络访问；Shared Services 含 45 Arc Site 监控和 Qualys 安全扫描。 +- Entities touched: [[Gruntwork]], [[Jenkins]], [[Swimford.net]], [[JetPult]], [[Pulse-VPN]], [[Qualys]], [[Terragrunt]], [[Terraform]] +- Concepts touched: [[Landing-Zone-Architecture]], [[Terraform]], [[Terragrunt]], [[Transit-Gateway]], [[Tag-Based-Access-Control]], [[Federated-Access]] +- Source page: wiki/sources/ctp-topic-25-labs-landing-zone-overview-itom-teams.md +- Notes: 步骤3完成：Source page 已有（2026-04-14 初版），内容完整无需修订；步骤4完成：index.md 条目补全日期前缀（2026-04-14）和一行摘要；步骤5完成：overview.md 已有该来源摘要（line 291），内容一致无需修订；步骤6-7完成：Key Concepts/Entities 均以 wikilink 形式存在，相关 Entity（Gruntwork/Jenkins/Swimford.net/JetPult/Pulse-VPN/Qualys）和 Concept（Landing-Zone-Architecture/Terraform/Terragrunt/Transit-Gateway）页面已存在；步骤8完成：Contradictions 记录"无已知冲突"（JetPult vs Checkpoint 属 Labs vs SaaS 不同 LZ 的防火墙方案差异，非冲突）；步骤9完成：log.md 补录本次 re-ingest + +## [2026-05-06] ingest | CTP Topic 7 SaaS Landing Zone Design +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-7-saas-landing-zone-design.md +- Status: ✅ 成功摄入（re-ingest） +- Summary: SAS LZ 四层账户体系设计（Core/Baseline/Shared Services/Product）；核心账户（Shared/Jenkins+Lambda、Logs、Security/IAM）、基线账户（Network/Transit Gateway+Checkpoint、DNS/Route 53、AD双节点）、共享服务账户（Software Factory 45 hubs+Octane Hub+Artifactory、Cyber/Qalis、ARC、Monitoring/OBM）、产品账户（私有子网工作负载+公有子网LB+WAF+CloudFront可选）；Terraform IaC + GitHub/Jenkins CI/CD 端到端自动化部署链路；Checkpoint VPN → Pulse VPN 远程访问迁移。 +- Concepts created: [[Transit-Gateway]], [[Active-Directory-Integration]], [[WAF-Web-Application-Firewall]], [[Private-Subnet-Architecture]], [[Terraform-IaC]], [[Software-Factory]] +- Entities created: [[Jenkins]], [[Pulse-VPN]], [[TerraGrant]], [[Qalis]], [[OBM]], [[CloudFront]] +- Entities touched: [[Gruntwork]], [[Checkpoint]], [[Terraform]], [[Terragrunt]] +- Source page: wiki/sources/ctp-topic-7-saas-landing-zone-design.md +- Notes: 步骤3完成：Source page 已有（2026-04-14 初版），本次补加 tags 和 last_updated: 2026-05-06；步骤4完成：index.md 条目补全日期前缀和一行摘要；步骤5完成：overview.md 已有该来源摘要（line 307），内容一致无需修订；步骤6-7完成：新建 6 个 Entity 页面（Jenkins/Pulse-VPN/TerraGrant/Qalis/OBM/CloudFront）和 6 个 Concept 页面（Transit-Gateway/Active-Directory-Integration/WAF-Web-Application-Firewall/Private-Subnet-Architecture/Terraform-IaC/Software-Factory），并加入 index.md；步骤8完成：Contradictions 已在 source page 记录（与 [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] 属设计演进视角互补，非冲突）；步骤9完成：log.md 补录本次摄入 + +## [2026-05-06] ingest | CTP Topic 34 Azure Landing Zone Architecture Overview +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-34-azure-landing-zone-architecture-overview.md +- Status: ✅ 成功摄入 +- Summary: Azure Landing Zone 架构概述——Micro Focus 通过 Azure Enterprise Enrollment + Azure AD 完成企业接入；管理组四区分离（platform/landing-zones/decommission/sandbox）；连接订阅集成 DDoS 防护和 Checkpoint 防火墙；Terraform Cloud 管理跨订阅依赖；PIM 强制最小权限。核心价值：团队独立部署减少跨团队依赖，AWS 侧用 Gruntwork/Jenkins，Azure 侧用 Terraform Cloud，体现 CTP 多云战略。 +- Concepts touched: [[Landing-Zone-Architecture]]（已存在，内容已通过本来源扩展） +- Entities touched: [[Azure]]（已存在）, [[Micro-Focus]]（已存在） +- Source page: wiki/sources/ctp-topic-34-azure-landing-zone-architecture-overview.md +- Notes: 步骤3完成：新建 source page，含完整 Summary/Key Claims/Key Quotes/Key Concepts/Key Entities/Connections/Contradictions；步骤4完成：index.md 条目补全日期前缀和一行摘要；步骤5完成：overview.md 新增 CTP Topic 34 条目，置于 Topic 35 之后；步骤6-7完成：关键 Entity/Concept 均已存在（Azure/Micro-Focus/Landing-Zone-Architecture/Terraform），无需新建；步骤8完成：Contradictions 记录了与 Gruntwork AWS LZ 的平台差异说明（非冲突，为多云战略互补）；步骤9完成：log.md 补录 + ## [2026-05-06] ingest | CTP Topic 35 AWS Landing Zone Design Refresher (SaaS Labs) - Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-35-aws-landing-zone-design-refresher-saas-labs.md - Status: ✅ 成功摄入 @@ -5781,3 +5859,22 @@ - Entities touched: [[Steve-Jarman]]（已存在）、[[Pradeep]]（已存在）、[[Checkpoint]]（已存在）、[[AWS-Organizations]]（已存在） - Source page: wiki/sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md - Notes: 步骤3完成：Source page 新建完成；步骤4完成：index.md 已有该条目（line 233 和 306），无需添加；步骤5完成：overview.md 已有该来源详细摘要（line 319），内容一致无需修订；步骤6-7完成：所有相关 Entity/Concept 页面均已存在，无需新建；步骤8完成：无冲突（与 [[ctp-topic-55-aws-firewall-manager]] 互补而非冲突——Checkpoint 作为网络边界防火墙，Firewall Manager 覆盖实例级别安全策略） + +## [2026-05-08] ingest | Learning Sessions: Standard AMI Updates 20231205 +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2.md +- Status: ✅ 成功摄入（re-ingest） +- Summary: AWS 标准 AMI 更新机制与生命周期管理——Jenkins 多分支流水线构建测试 AMI，验证周期从 3-4 天缩短至 60 分钟；支持 23 种 AMI 涵盖 Amazon Linux/CentOS/RHEL/Rocky Linux/SUSE/Ubuntu/Windows；CentOS 7/RHEL 7 将于 2024 年 6 月 EOL，由 Rocky Linux 替代；机器人框架自动化验证是该优化流程的核心；新 Landing Zone 使用 Secrets Manager 替代 Parameter Store，所有自动化迁移至云端初始化。 +- Concepts created: [[Amazon-Machine-Image]], [[Jenkins-Multi-Branch-Pipeline]], [[AWS-Inspector]], [[Robotic-Framework]], [[SSM-Patching]], [[GP3-EBS-Storage]], [[OS-End-of-Life]] +- Entities created: [[Rocky-Linux]], [[Jenkins]], [[QALIS-Agent]], [[Sentinel-1]], [[AWS-SSM]] +- Entities touched: none（均已存在并已引用） +- Source page: wiki/sources/learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2.md +- Notes: 步骤3完成：Source page 已存在（2023-12-05 初版），本次补加 last_updated: 2026-05-08，更新 Contradictions 节（补充与 ctp-topic-50/ctp-topic-26 的关系说明）；步骤4完成：index.md 条目（第300行）补全日期前缀 [2026-05-08] 和一行摘要；步骤5完成：overview.md 修复 broken wikilink（learning-sessions-standard-amis-updates → learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2）；步骤6-7完成：新建 5 个 Entity 页面（Rocky-Linux/Jenkins/QALIS-Agent/Sentinel-1/AWS-SSM）和 7 个 Concept 页面（Amazon-Machine-Image/Jenkins-Multi-Branch-Pipeline/AWS-Inspector/Robotic-Framework/SSM-Patching/GP3-EBS-Storage/OS-End-of-Life），并加入 index.md；步骤8完成：Contradictions 节更新，补充与 ctp-topic-50/ctp-topic-26 的关系说明（视角互补，无冲突）；步骤9完成：log.md 补录本次摄入 + +## [2026-05-08] ingest | CTP Topic 40 SaaS Database Architecture On AWS Cloud +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-40-saas-database-architecture-on-aws-cloud.md +- Status: ✅ 成功摄入 +- Summary: CTP 主题 40 —— AWS 云上 SaaS 数据库架构，介绍企业级数据库团队如何设计、管理和运维多租户 SaaS 数据库解决方案。核心内容包括：多数据库引擎支持（Oracle、Vertica、Postgres、DynamoDB、SQL Server、MongoDB、MySQL）、多可用区高可用架构、监控工具链、自动化运维。 +- Concepts touched: [[Multi-AZ-High-Availability]], [[Oracle-Data-Guard]], [[AWS-RDS]], [[Database-Migration]], [[Multi-Tenancy]] +- Entities touched: [[Micro-Focus]], [[AWS-Aurora]], [[AWS-RDS]], [[AWS-CloudWatch]], [[Oracle-GoldenGate]] +- Source page: wiki/sources/ctp-topic-40-saas-database-architecture-on-aws-cloud.md +- Notes: 步骤3完成：新建 source page（含完整 Summary/Key Claims/Key Quotes/Key Concepts/Key Entities/Connections/Contradictions）；步骤4完成：index.md 条目补全日期前缀（2026-04-14）和一行摘要；步骤5完成：overview.md 已有该来源摘要（line 327），内容一致无需修订；步骤6-7完成：Key Concepts/Entities 均以 wikilink 形式存在（[[Micro Focus]]/[[AWS Aurora]]/[[AWS RDS]]/[[AWS CloudWatch]]/[[Oracle Golden Gate]]/[[Multi-AZ High Availability]]/[[Oracle Data Guard]]/[[AWS RDS High Availability]]/[[Database Migration]]/[[Multi-Tenancy]]），相关 Entity/Concept 页面已存在（Micro Focus/AWS Aurora/AWS RDS/Oracle Golden Gate）；步骤8完成：Contradictions 记录"无已知冲突"；步骤9完成：log.md 追加本次摄入记录 diff --git a/wiki/overview.md b/wiki/overview.md index b79140d6..be4e57ca 100644 --- a/wiki/overview.md +++ b/wiki/overview.md @@ -300,15 +300,15 @@ Cloud Transformation Programme (CTP) materials cover AWS landing zones, EKS, Ter **[[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]]**（CTP Topic 35）：AWS Landing Zone 设计复习——重点明确 SaaS（生产）与 Labs（开发）的职责划分。SaaS Landing Zone 为每个产品区域提供客户专属环境，产品账户连接至共享服务账户（安全、日志、网络）；核心账户组包含 AD、DNS 和 Network 账户；Gruntwork 账户跨所有账户管理 AMI、日志和安全。近期变更：网络分段阻断对 SaaS 工作负载的直接连通性；CCOEs CloudTrail 取代 Gruntworks CloudTrail 实现统一审计；入站流量拟通过 Network 账户 Checkpoint 重新路由；原生 AWS Backup 有望强制化；新账户可能取消 Management VPC。核心结论：**SaaS = 生产，Labs = 开发**；PoC Landing Zone 将并入 Labs 以最大化资源共享；Cloud Technology Design Forum 推动 Micro Focus 云交付标准化。 -**[[ctp-topic-6-aws-workspaces-demo]]**（CTP Topic 6）：AWS Workspaces 虚拟桌面解决方案实操演示——通过 AWS Workspaces 为云转型团队提供托管 Windows 虚拟桌面（Windows Server 2016），预装 PFSSO、Terraform、TerraGrunt、Git 和 VS Code。用户通过邮件联系 Naga 申请账号，接收注册码和用户名后登录，可立即访问 AWS Console（Federation）和 GitHub Enterprise 并生成 SSH 密钥。演示全程约 21 分钟完成仓库克隆、PFSSO 认证和 TerraGrunt Plan 执行，达成"申请后 45 分钟内运行 Terraform"的目标。未来计划与 Active Directory 集成实现自动化账号管理。属 [[AWS-Landing-Zone]] 用户端工具层的核心实践，与 [[ctp-topic-1-gruntwork-landing-zone-architecture]]（基础架构）和 [[ctp-topic-9-ci-cd-with-gruntwork]]（CI/CD 流程）共同构成完整的"架构→交付→使用"链路。 +**[[ctp-topic-34-azure-landing-zone-architecture-overview]]**（CTP Topic 34）：Azure Landing Zone 架构概述——Kishore Garlopati 讲解 Micro Focus 内部 Azure 采用方案。核心架构：通过 Azure Enterprise Enrollment + Azure AD 完成企业接入；使用管理组（Management Groups）按四区组织订阅——platform（身份管理/连接）、landing zones（可扩展/模块化/全自动化模板）、decommission（停用资源）、sandbox（隔离实验）。连接订阅作为所有入站/出站 Azure 流量的中心枢纽，集成 DDoS 防护和 Checkpoint 防火墙。Terraform Cloud 通过 Terraform State 管理跨订阅依赖；PIM（Privileged Identity Management）强制最小权限访问。核心价值：团队在自动化保障下独立部署工作负载，减少跨团队依赖。与 [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]]（AWS LZ）和 [[ctp-topic-1-gruntwork-landing-zone-architecture]]（Gruntwork LZ）共同体现 CTP 多云战略——AWS 侧用 Gruntwork/Jenkins，Azure 侧用 Terraform Cloud，平台差异由多云架构驱动。 -**[[public-cloud-learning-sessions-aws-end-user-compute-services-20240430]]**（Public Cloud Learning Sessions，Christian O'Donough 主讲）：AWS 终端用户计算（EUC）服务全景介绍——覆盖四大服务：① **Workspaces**（全持久虚拟桌面，适合知识工作者一对一实例管理）；② **AppStream 2.0**（选择持久/非持久应用流，多租户模式降低成本，适合实验室/培训/堡垒主机）；③ **Workspace Core**（提供 VDI 基础设施 API，支持 Horizon View、Citrix 等第三方集成）；④ **Workspace Web**（低成本安全浏览器）。核心选型原则：需要完整桌面 → Workspaces；非持久桌面/应用流 → AppStream 2.0；第三方 VDI → Workspace Core；安全浏览 → Workspace Web。安全措施包括 Active Directory 集成、加密、IAM 配置文件、SAML 认证和多因素认证。属 [[AWS-Landing-Zone]] 用户端计算层的理论基础，与 [[ctp-topic-6-aws-workspaces-demo]]（实操演示）共同构成完整的 EUC 知识体系。 +**[[ctp-topic-6-aws-workspaces-demo]]**（CTP Topic 6）：AWS Workspaces 虚拟桌面解决方案实操演示——通过 AWS Workspaces 为云转型团队提供托管 Windows 虚拟桌面（Windows Server 2016），预装 PFSSO、Terraform、TerraGrunt、Git 和 VS Code。用户通过邮件联系 Naga 申请账号，接收注册码和用户名后登录，可立即访问 AWS Console（Federation）和 GitHub Enterprise 并生成 SSH 密钥。演示全程约 21 分钟完成仓库克隆、PFSSO 认证和 TerraGrunt Plan 执行，达成"申请后 45 分钟内运行 Terraform"的目标。未来计划与 Active Directory 集成实现自动化账号管理。属 [[AWS-Landing-Zone]] 用户端工具层的核心实践，与 [[ctp-topic-1-gruntwork-landing-zone-architecture]]（基础架构）和 [[ctp-topic-9-ci-cd-with-gruntwork]]（CI/CD 流程）共同构成完整的"架构→交付→使用"链路。 **[[ctp-topic-7-saas-landing-zone-design]]**（CTP Topic 7）：SAS 生产 Landing Zone 顶层架构设计——定义了完整的四层账户体系：①核心账户（Core Accounts）：Shared 托管 AMI + 主 Jenkins 服务器通过 Lambda 触发各账户 Jenkins slave；Logs 集中管理所有账户日志（CloudTrail/Config/Flowlogs）；Security 托管 IAM 角色。②基线账户（Baseline Accounts）：Network 账户部署区域级 Transit Gateway + Checkpoint Appliance 按标签监控跨账户流量；DNS 账户托管 Route 53，各产品拥有独立托管区；Active Directory 账户提供双 AD 节点实现域加入和资源访问控制。③共享服务账户（Shared Services Accounts）：Software Factory（45 个 hub + Octane Hub + Artifactory）、Cyber（Qalis）、ARC Site、Monitoring（OBM/Sitescope）。④产品账户（Product Accounts）：工作负载置于私有子网，公有子网通过负载均衡器和互联网网关对外暴露，WAF 监控入站流量。自动化部署链路：GitHub 仓库变更 → Jenkins（GitHub Hook 触发）→ Management VPC → Lambda → ECS Cluster，Staging 测试后才部署生产。远程访问从 Checkpoint VPN 迁移至 Pulse VPN（通过 AD 认证）。属 [[AWS-Landing-Zone]] 的原始设计规范，与 [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]]（近期变更）共同构成 SAS LZ 的设计演进脉络。 **[[ctp-topic-1-gruntwork-landing-zone-architecture]]**（CTP Topic 1）：Gruntwork AWS Landing Zone 架构基础——核心概念：参考架构（Reference Architecture）是包含核心账户 Shared/Logs/Security 和工作负载账户 Prod/Stage/Dev 的最佳实践起点；Landing Zone 基于 Gruntwork 仓库但由产品团队自行定义具体服务；安全账户使用联邦用户（Federated User），通过 AD 组映射到 IAM 角色；每个 Landing Zone 配置独立 Jenkins 服务器和特性分支 Git 工作流。属整个 CTP Landing Zone 系列的基础入门篇。 -**[[learning-sessions-standard-amis-updates]]**（Learning Sessions 20231205）：AWS 标准 AMI 更新机制与生命周期管理——Jenkins 多分支流水线构建测试 AMI，验证周期从 3-4 天缩短至 60 分钟；支持 23 种 AMI 涵盖 Amazon Linux/CentOS/RHEL/Rocky Linux/SUSE/Ubuntu/Windows；CentOS 7/RHEL 7 将于 2024 年 6 月 EOL，由 Rocky Linux 替代；机器人框架自动化验证是该优化流程的核心。属 [[AWS-Landing-Zone]] AMI 管理层的实践补充。 +**[[learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2]]**（Learning Sessions 20231205）：AWS 标准 AMI 更新机制与生命周期管理——Jenkins 多分支流水线构建测试 AMI，验证周期从 3-4 天缩短至 60 分钟；支持 23 种 AMI 涵盖 Amazon Linux/CentOS/RHEL/Rocky Linux/SUSE/Ubuntu/Windows；CentOS 7/RHEL 7 将于 2024 年 6 月 EOL，由 Rocky Linux 替代；机器人框架自动化验证是该优化流程的核心。属 [[AWS-Landing-Zone]] AMI 管理层的实践补充。 **[[ctp-topic-50-ami-roadmap-for-aws-amis]]**（CTP Topic 50）：CCOE AMI 路线图详解——涵盖 CCOE AMI 路线图规划、操作系统 EOL 时间线（Windows Server 2008/2008 R2 已 EOL；CentOS 8 已 EOL；Windows Server 2012 将于 2023 年 10 月 EOL；RHEL 7 和 CentOS 7 将于 2024 年 6 月 EOL）、AMI 通知机制、变更日志（CCRE 门户）、新 AMI 添加流程（服务集成→功能启用→构建测试）、当前支持的 AMI 清单及未来路线图（SLES 15/RHEL 9 2022年11月；openSUSE 15/Amazon Linux 2022 2023年1月；Rocky 8/9 2023年3月；RHEL 9.4 ARM/Ubuntu 22.04 ARM 2023年5月）。自 2023 年 5 月起所有 ARM AMI 同步发布。路线图优先级主要由 ADM 需求驱动，变更需通过需求管道流程提交。AMI 通过跨账号共享分发给组织内所有账户。属 [[AWS-Landing-Zone]] AMI 层的路线图补充，与 [[ctp-topic-26-standard-ami-build-publish-share-processes]]（生命周期管理）和 [[ctp-topic-58-aws-ec2-image-builder]]（未来演进方向 EC2 Image Builder）共同构成完整的 AMI 管理知识体系。 @@ -410,7 +410,9 @@ Key concepts: [[Process]], [[Value]], [[Value-Stream]], [[Value-Adding]], [[Wast **[[ctp-topic-23-introduction-to-the-technical-architecture-team-and-function]]**（CTP Topic 23）：技术架构团队职能与云转型价值——Martin Nash（技术架构经理）主讲。核心内容：①组织变革背景——PSTC 与 IT 部门整合至 CIO 统一领导下，实现两个大型组织的深度融合；②云优先策略——除非数据主权、合规性或极端成本原因必须保留在本地，否则所有新业务优先上云；③三层架构分工——EA（企业架构）对接业务战略，SA（方案架构）负责中间件与服务优化，TA（技术架构）专注底层技术实施与基础设施治理；④技术领域划分——将技术栈划分为身份认证、网络、Microsoft 堆栈等领域，每个领域由首席架构师负责其生命周期与路线图；⑤主动规划转型——通过制定 12-24 个月技术路线图，从被动响应转向预测性规划，帮助业务部门规避风险、优化预算、提升交付速度。属 [[AWS-Landing-Zone]] 架构治理层的核心补充，与 [[ctp-topic-47-enterprise-architecture-cloud-standards]]（EA 云标准）共同构成企业架构知识体系。 -**[[ctp-topic-72-enterprise-dr-strategy-aws-backup]]**（CTP Topic 72）：AWS 解决方案架构师 Sabith 深入讲解企业级灾难恢复策略与 AWS Backup 架构设计——核心内容：HA（高可用）关注系统运行时间和 MTBF，DR（灾难恢复）专注于防止数据丢失和系统恢复，两者互补；RPO（恢复点目标）定义可接受的最大数据丢失量，RTO（恢复时间目标）定义可接受的最大停机时间；AWS Backup 完全托管、基于策略，通过 Backup Plans 定义何时备份什么，Backup Vaults 存储恢复点，支持跨账户跨区域复制；四级 DR 架构模式（Backup and Restore → Pilot Light → Warm Standby → Active-Active）提供从低成本到高弹性的递进选择；增量备份仅捕获变更，节省成本；Vault Lock 合规模式防止任何人（包括根用户）提前删除恢复点，有效防勒索软件；建议使用独立的 Vault/Bunker Account 存储备份副本，取证账户（Forensic Account）定期测试恢复点并扫描恶意软件。属 [[AWS-Landing-Zone]] DR 与数据保护层的理论基础补充，与 [[ctp-topic-44-aws-backup-in-micro-focus]]（聚焦 Micro Focus 内部评估）和 [[ctp-topic-73-aws-backup-implementation]]（聚焦 CTP 迁移实施）构成完整的 AWS Backup 知识体系。 +**[[ctp-topic-72-enterprise-dr-strategy-aws-backup]]**（CTP Topic 72）：AWS 解决方案架构师 Sabith 深入讲解企业级灾难恢复策略与 AWS Backup 架构设计——核心内容：HA（高可用）关注系统运行时间和 MTBF，DR（灾难恢复）专注于防止数据丢失和系统恢复，两者互补；RPO（恢复点目标）定义可接受的最大数据丢失量，RTO（恢复时间目标）定义可接受的最大停机时间；AWS Backup 完全托管、基于策略，通过 Backup Plans 定义何时备份什么，Backup Vaults 存储恢复点，支持跨账户跨区域复制；四级 DR 架构模式（Backup and Restore → Pilot Light → Warm Standby → Active-Active）提供从低成本到高弹性的递进选择；增量备份仅捕获变更，节省成本；Vault Lock 合规模式防止任何人（包括根用户）提前删除恢复点，有效防勒索软件；建议使用独立的 Vault/Bunker Account 存储备份副本，取证账户（Forensic Account）定期测试恢复点并扫描恶意软件。属 [[AWS-Landing-Zone]] DR 与数据保护层的理论基础补充，与 [[ctp-topic-44-aws-backup-in-micro-focus]]（聚焦 Micro Focus 内部评估）和 [[ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program]]（聚焦 CTP 迁移落地）构成完整的 AWS Backup 知识体系。 + +**[[ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program]]**（CTP Topic 73）：AWS Backup 在云转型计划（CTP）中的具体落地实施——SRE Core/Product/Architecture 团队协作设计 SRE 备份模型，使产品团队能在各自 DRA 账户内独立管理备份。预设备份策略：生产工作负载客户数据至少每 24 小时备份一次，保留期至少 30 天，备份存储于两个位置。AWS Backup 被选为 CTP 战略备份工具，因其原生托管、支持 80+ AWS 资源类型、跨账户/跨区域备份、不可变性、开箱即用审计报告及 S3/RDS 时间点恢复（PITR）。架构设计：初始备份在源账户完成，复制到专属 DR 账户（每个生产工作负载账户对应一个 DR 账户），确保备份保留在 DR 账户内实现即时恢复，无需耗时数据拷贝；DR 账户不可用时回退至 Databunker 集中账户。SRE 备份模型简化 AWS Backup 接入：自动创建 Backup Plans、Selections、Local AWS Backup Vaults、KMS 密钥策略、DR 账户额外 Vault、注册策略、生命周期策略、SNS 主题、审计报告及可选 PITR。AWS Backup Audit Manager 提供合规框架，包括备份覆盖率检查、最小频率和保留期验证、手动删除防护、加密验证及计划性跨区域/跨账户备份。属 [[AWS-Landing-Zone]] DR 与数据保护层的实施层补充，与 [[ctp-topic-72-enterprise-dr-strategy-aws-backup]]（理论基础）和 [[ctp-topic-44-aws-backup-in-micro-focus]]（Micro Focus 评估）共同构成"理论→实施→内部评估"完整体系。 **[[rto-vs-rpo-key-differences-for-modern-disaster-recovery]]**（RTO vs RPO: Key Differences for Modern Disaster Recovery）：RTO（Recovery Time Objective）和 RPO（Recovery Point Objective）在现代灾难恢复与持续交付中的关键区别与实践应用——核心区分：RTO 衡量系统停机时长容忍度（从故障时刻开始计时），RPO 衡量数据丢失容忍度（从上一备份时刻向前测量）；现代部署环境下软件故障（Bug/错误迁移/AI 模型异常）比硬件灾难更频繁，每日常规发布即潜在 RTO/RPO 场景。Feature Flag 驱动的新范式：通过部署与发布解耦（Deploy whenever you want, release when you're ready）、渐进式灰度发布（1%→5%→25%→100%）和 Kill Switch（即时禁用故障功能），将 RTO 从"小时级紧急回滚部署"缩短至"秒级配置开关切换"，RPO 通过 Feature Flag 保护数据完整性避免回滚时数据损坏。应用分层恢复策略：Tier 1 Critical（支付/认证，RTO<5min/RPO<1min）→ Tier 2 Important（管理后台/报表，RTO<1h/RPO<15min）→ Tier 3 Nice-to-have（内部工具，RTO<4h/RPO<1h）。成本效益原则：若停机1小时损失 $10K，不要每年花 $100K 基础设施预防——Feature Flag 方案比传统热备基础设施成本更低、效果更好（HP/Christian Dior 案例）。属 [[ctp-topic-72-enterprise-dr-strategy-aws-backup]]（AWS 基础设施层 DR）在软件交付层的互补——前者聚焦备份基础设施，后者聚焦代码层快速恢复，共同构成完整 DR 知识体系；与 [[what-i-know-about-cloud-service-delivery-1]]（"备份恢复与灾难管理"第12领域）形成引用关系；与 [[cloud-devop-maturity-guideline]] 的 DORA MTTR 指标关联（MTTR 直接量化 RTO）。 diff --git a/wiki/sources/ai-memory-tools-two-camps.md b/wiki/sources/ai-memory-tools-two-camps.md index 6ba52bcd..059ddc07 100644 --- a/wiki/sources/ai-memory-tools-two-camps.md +++ b/wiki/sources/ai-memory-tools-two-camps.md @@ -7,7 +7,7 @@ last_updated: 2026-04-15 --- ## Source File -- [[Agent/AI-Memory-Tools-Two-Camps.md]] +- [[raw/Agent/AI-Memory-Tools-Two-Camps.md]] ## Summary（用中文描述） - 核心主题：AI Agent 记忆工具的全景分类——作者系统梳理了 450+ 个 GitHub 仓库，将 AI 记忆工具划分为两个根本不同的范式阵营 diff --git a/wiki/sources/blogwatcher-daily收藏.md b/wiki/sources/blogwatcher-daily收藏.md index bc6757c7..ede04293 100644 --- a/wiki/sources/blogwatcher-daily收藏.md +++ b/wiki/sources/blogwatcher-daily收藏.md @@ -6,7 +6,7 @@ date: 2026-04-18 --- ## Source File -- [[Skills/blogwatcher-daily收藏.md]] +- [[raw/Skills/blogwatcher-daily收藏.md]] ## Summary（用中文描述） - 核心主题：Hermes Agent 自定义技能 blogwatcher-daily，实现 RSS/YouTube 订阅自动化监控与每日摘要生成 diff --git a/wiki/sources/building-your-quartz.md b/wiki/sources/building-your-quartz.md index 92b49de9..7fb44a60 100644 --- a/wiki/sources/building-your-quartz.md +++ b/wiki/sources/building-your-quartz.md @@ -9,7 +9,7 @@ date: 2026-04-17 --- ## Source File -- [[Home Office/Building your Quartz]] +- [[raw/Home Office/Building your Quartz.md]] ## Summary（用中文描述） - 核心主题：Quartz 静态网站构建与部署完整指南 diff --git a/wiki/sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md b/wiki/sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md index 70c99d07..e12134df 100644 --- a/wiki/sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md +++ b/wiki/sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md @@ -2,67 +2,54 @@ title: "CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security" type: source tags: - - aws - - landing-zone - - tagging - - security - - cloud-transformation - - ctp -date: 2026-04-14 + - AWS + - Landing-Zone + - Tagging + - Security + - CTP +last_updated: 2026-04-14 --- ## Source File - [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md]] ## Summary（用中文描述） -- 核心主题：AWS Landing Zone 部署过程中数据收集策略，以及基于资源标签的云原生安全架构 -- 问题域：企业云迁移过程中如何理解待上云资产、如何通过标签机制实现精细化的访问控制和安全策略 +- 核心主题：AWS Landing Zone 的数据收集策略与基于标签的安全控制机制 +- 问题域：企业云迁移过程中的网络安全与访问控制 - 方法/机制： - - **OU + SCP 分层治理**：通过组织单元（OU）和 Service Control Policies（SCP）强制执行标签规范 - - **标签即凭证**：将 AWS 资源标签作为防火墙策略的动态匹配条件，替代传统基于 IP 的静态规则 - - **Checkpoint 有序层防火墙**：按优先级执行地理屏蔽 → 类型检查 → BU 隔离 → 产品隔离 → 环境隔离 → 角色检查 - - **Inline 层结构**：基于账号号的父子规则架构，简化跨账户策略管理 -- 结论/价值：从"IP 地址"到"标签"的策略范式转变，使动态云环境无需频繁更新防火墙规则；标签缺失或篡改会触发 SCP 拒绝策略，确保安全合规 + - 部署前通过业务部门（BU）资产清单、IP 地址空间及数据敏感性调研，制定 Landing Zone 安全姿态 + - 利用 AWS 标签（Tagging）替代传统基于 IP 的防火墙规则，作为安全凭证 + - 引入 OU（组织单元）和 SCP（服务控制策略）防止用户篡改标签绕过安全审计 + - Checkpoint 防火墙通过"有序层（Ordered Layer）"逻辑实现流量分层过滤 +- 结论/价值：实现从传统网络安全向基于身份和元数据的云原生安全转型 ## Key Claims（用中文描述） -- Landing Zone 部署前必须深入了解 BU 资产清单、IP 地址空间及数据敏感性 -- DNS、Transit Gateway 等基础服务通过 SRE 团队实现高度自动化 -- **基于标签的安全控制**：传统基于 IP 的防火墙规则无法适应云环境动态性，标签机制将安全凭证嵌入资源本身 -- **SCP 强制标签规范**：「显式拒绝」逻辑防止用户通过篡改标签绕过审计，确保资源创建时即具备正确的 BU/产品/环境归属 -- **Checkpoint 防火墙有序层**：按优先级执行地理屏蔽 → BU 隔离 → 产品隔离 → 环境隔离，实现跨 VPC/On-prem/互联网的精细化流量控制 -- 标签示例包括：机器名、Owner（优先使用 PDL）、Type（R&D 等）、Business Unit、Product、Environment（production 等）、Server Role、Account、App ID -- 产品间通信默认禁止（Inter product is not allowed） -- Inline 层检查账号号，简化规则管理并支持自动化 +- Steve Jarman + Pradeep 通过 SCP 的"显式拒绝"逻辑，强制执行标签规范，确保资源在创建时即具备正确的归属标签（BU、产品、环境） +- Checkpoint 防火墙根据标签对流量进行分层过滤（地理屏蔽、BU 隔离、产品隔离、环境隔离），实现跨 VPC、On-prem 及互联网流量的精细化策略约束 +- DNS、Transit Gateway 等基础服务的创建已通过 SRE 团队实现高度自动化 ## Key Quotes -> "We ask a lot of questions so that we can then turn around and make sure we're putting the appropriate posture in the cloud and that we're protecting the resources appropriately." -> — Steve Jarman，阐述云迁移前的准备工作重心 - -> "Inter product is not allowed. Inter product is communications allowed." -> — Pradeep，描述产品间隔离的默认安全策略 +> "在部署前，必须深入了解业务部门（BU）的资产清单、IP 地址空间及数据敏感性，以便制定合适的安全姿态" — Steve Jarman，部署前规划原则 +> "通过 SCP 的'显式拒绝'逻辑，系统能够强制执行标签规范，确保资源在创建时即具备正确的归属" — Pradeep，标签安全控制机制 ## Key Concepts -- [[Service-Control-Policies-SCPs]]：AWS Organizations 策略类型，通过「显式拒绝」逻辑强制执行标签规范，阻止不合规资源创建 -- [[Checkpoint-Firewall]]：防火墙供应商，依赖 AWS 标签值配置动态网络访问策略 -- [[AWS-Landing-Zone]]：AWS 云环境的最佳实践起点框架，定义账户结构、网络、安全和访问管理 -- [[Tag-Based-Security]]：将资源标签作为安全凭证，替代传统基于 IP 的防火墙规则 -- [[OU-Layered-Security]]：通过组织单元（OU）的分层结构检查标签，确保正确归属和访问控制 +- [[AWS Landing Zones]]：按照最佳实践快速设置安全且多账号 AWS 环境的基础架构框架 +- [[Tagging Methodology]]：通过为资源定义标准化元数据（如 Owner, BU, Product, Environment），作为自动化管理和安全策略执行的基础 +- [[SCP Service Control Policies]]：AWS Organizations 中的服务控制策略，用于管理组织中的权限，本视频中用于强制执行标签合规性 +- [[OU Organizational Unit]]：AWS Organizations 中账号的分组容器，用于分层应用安全策略（SCP） +- [[Checkpoint Firewall Ordered Layer]]：防火墙策略的组织方式，按顺序执行地理屏蔽、BU 隔离、环境隔离等逻辑 +- [[Transit Gateway]]：传输网关，作为网络中心枢纽连接 VPC 与本地网络，是跨环境流量经过防火墙检查的关键节点 +- [[SRE Automation]]：站点可靠性工程，负责 Landing Zone 部署中的自动化脚本编写与基础架构维护 ## Key Entities -- [[Steve-Jarman]]：CTP Topic 10 主讲人之一，阐述云迁移前的准备工作 -- [[Pradeep]]：CTP Topic 10 主讲人，演示 Checkpoint 防火墙配置和 EC2 部署示例 -- [[Checkpoint]]：防火墙供应商，负责基于标签的动态网络安全策略 -- [[AWS-Organizations]]：AWS 服务，提供 SCP 策略机制支持标签强制执行 +- [[Steve Jarman]]：Cloud Transformation Programme 技术分享主持人，Landing Zone 规划与自动化专家 +- [[Pradeep]]：Checkpoint 防火墙与网络隔离技术演示主讲人 ## Connections -- [[ctp-topic-1-gruntwork-landing-zone-architecture]] ← foundational ← [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] -- [[ctp-topic-28-aws-tag-validation-tool]] ← extends ← [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] -- [[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]] ← related ← [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] -- [[ctp-topic-25-labs-landing-zone-overview-itom-teams]] ← related ← [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] +- [[CTP Topic 1 Gruntwork Landing Zone Architecture]] ← builds_upon ← [[CTP Topic 10]] +- [[CTP Topic 31 Network Segregation and Secure Access to the New AWS Landing Zones]] ← extends ← [[CTP Topic 10]] +- [[CTP Topic 17 Active Directory Services in Gruntwork AWS LZs]] ← related_to ← [[CTP Topic 10]] +- [[AWS_Organizations_and_SCP_Deep_Dive]] ← deep_dive ← [[CTP Topic 10]]（SCP 强制执行标签合规性） ## Contradictions -- 与 [[ctp-topic-28-aws-tag-validation-tool]] 在标签治理覆盖范围上存在差异： - - 冲突点：SCPs 的标签强制能力边界 - - 当前观点（Topic 10）：SCPs 通过「显式拒绝」阻止不合规资源创建，确保标签在资源创建时就正确 - - 对方观点（Topic 28）：SCPs 可阻止不合规资源创建，但无法修复存量资源，存量合规性需通过 Tag Validation Tool 审计发现 - - 协调说明：两者互补而非矛盾——SCP 负责预防（新资源准入控制），Tag Validation Tool 负责发现（存量资源合规审计） +- 暂无已知冲突 diff --git a/wiki/sources/ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i.md b/wiki/sources/ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i.md index 89b96664..2bde4b13 100644 --- a/wiki/sources/ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i.md +++ b/wiki/sources/ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i.md @@ -12,7 +12,7 @@ last_updated: 2026-04-14 --- ## Source File -- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i]] +- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i.md]] ## Summary（用中文描述） diff --git a/wiki/sources/ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs.md b/wiki/sources/ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs.md index e8aac5f4..aae6bbe0 100644 --- a/wiki/sources/ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs.md +++ b/wiki/sources/ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs.md @@ -11,7 +11,7 @@ date: 2026-04-14 --- ## Source File -- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs.md]] +- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs.md]] ## Summary（用中文描述） - 核心主题：在 Gruntwork AWS Landing Zones 架构中集成与管理 Active Directory 服务 diff --git a/wiki/sources/ctp-topic-22-global-dns-service-offerings.md b/wiki/sources/ctp-topic-22-global-dns-service-offerings.md index f6f6c788..c3c30153 100644 --- a/wiki/sources/ctp-topic-22-global-dns-service-offerings.md +++ b/wiki/sources/ctp-topic-22-global-dns-service-offerings.md @@ -52,7 +52,7 @@ date: 2026-04-14 - [[ctp-topic-18-wide-area-networking-in-aws-cloud]] ← related_to ← [[ctp-topic-22-global-dns-service-offerings]] ## Contradictions -- 与 [[ctp-topic-19-configuring-dns-within-aws-lzs]] 潜在关系： - - 当前观点：CTP Topic 22 详细描述了 Route 53 Private Hosted Zone + Resolver Endpoint 的完整混合云 DNS 架构，含 Infoblox Anycast 对比 - - 对方观点：CTP Topic 19 尚未被摄入，具体内容待确认 - - 状态：待 ctp-topic-19 摄入后补充对比 +- 与 [[ctp-topic-19-configuring-dns-within-aws-lzs]] 关系（视角互补，非冲突）： + - 当前观点（CTP Topic 22）：企业级全局 DNS 架构视角——Route 53 Private Hosted Zone + AD 托管 DNS + Route 53 Resolver Endpoints 完整混合云方案，含 Infoblox Anycast 对比和"就近解析"优化 + - 对方观点（CTP Topic 19）：Landing Zone 内部 DNS 配置实施视角——集中化 DNS 账号设计 + AWS RAM 跨账号规则共享 + Terraform 自动化部署 + - 状态：两视频共同构成 DNS 专题完整体系（Topic 19 讲配置实施 → Topic 22 讲企业架构），属深度递进关系 diff --git a/wiki/sources/ctp-topic-26-standard-ami-build-publish-share-processes.md b/wiki/sources/ctp-topic-26-standard-ami-build-publish-share-processes.md index c2b76e5f..71bc85c8 100644 --- a/wiki/sources/ctp-topic-26-standard-ami-build-publish-share-processes.md +++ b/wiki/sources/ctp-topic-26-standard-ami-build-publish-share-processes.md @@ -35,28 +35,25 @@ date: 2026-04-14 > "CCOE 负责提供安全的基础镜像，而产品团队则被鼓励在 Foundation AMI 之上构建自定义的'产品特定 AMI'，以满足各自应用的特殊需求，并负责其后续的生命周期管理。" — 责任共担模型说明 ## Key Concepts -- [[Foundation AMI]]：经过安全加固、集成标准组件并预配置好的操作系统模板，是 Micro Focus 云环境的标准化基础镜像 -- [[OS Hardening]]：操作系统加固，通过关闭不必要服务、优化内核参数和应用安全补丁来减少系统攻击面 -- [[CIS Benchmarks]]：由互联网安全中心制定的安全配置基准，用于衡量镜像是否符合行业最佳安全实践 -- [[HashiCorp Packer]]：开源工具，用于从单一源配置为多个云平台自动创建一致的机器镜像 -- [[SSM Agent]]：AWS 系统管理器代理，用于实现实例的远程管理、自动化补丁更新和配置同步 -- [[AMI Sharing]]：镜像共享机制，通过授权其他账号访问中央镜像，避免跨账号复制带来的额外存储成本 -- [[Central Repository]]：中央仓库，用于统一存放和管理经过验证的官方镜像，确保分发源的唯一性 +- [[Foundation-AMI]]：经过安全加固、集成标准组件并预配置好的操作系统模板，是 Micro Focus 云环境的标准化基础镜像 +- [[OS-Hardening]]：操作系统加固，通过关闭不必要服务、优化内核参数和应用安全补丁来减少系统攻击面 +- [[CIS-Benchmark]]：由互联网安全中心制定的安全配置基准，用于衡量镜像是否符合行业最佳安全实践 +- [[HashiCorp]]：开源基础设施自动化工具公司，[[HashiCorp]] 出品的 Packer 用于镜像构建自动化（本来源中称 HashiCorp Packer） +- [[AWS-SSM]]：AWS 系统管理器代理，用于实现实例的远程管理、自动化补丁更新和配置同步 +- [[AMI-Sharing]]：镜像共享机制，通过授权其他账号访问中央镜像，避免跨账号复制带来的额外存储成本 +- Central Repository：中央仓库，用于统一存放和管理经过验证的官方镜像，确保分发源的唯一性 ## Key Entities -- [[Srihari]]：本次会议主讲人之一 -- [[Alan]]：本次会议主讲人之一 -- [[Praveen]]：本次会议主讲人之一 - [[CCOE]]（Cloud Center of Excellence）：负责提供安全的基础镜像（Foundation AMI） ## Connections -- [[Foundation AMI]] ← uses ← [[HashiCorp Packer]] + [[Jenkins]] -- [[Foundation AMI]] ← extends ← [[CIS Benchmarks]]（安全加固标准） -- [[Foundation AMI]] ← depends_on ← [[SSM Agent]]（实例管理能力） -- [[AMI Sharing]] ← uses ← [[Central Repository]] +- [[Foundation-AMI]] ← uses ← [[HashiCorp]] Packer + [[Jenkins]] +- [[Foundation-AMI]] ← extends ← [[CIS-Benchmark]]（安全加固标准） +- [[Foundation-AMI]] ← depends_on ← [[AWS-SSM]]（实例管理能力） +- [[AMI-Sharing]] ← uses ← Central Repository - [[ctp-topic-26-standard-ami-build-publish-share-processes]] ← extends ← [[ctp-topic-58-aws-ec2-image-builder]] -- [[Foundation AMI]] ← provides ← [[AMI Sharing]] -- [[Product-Specific AMI]] ← extends ← [[Foundation AMI]] +- [[Foundation-AMI]] ← provides ← [[AMI-Sharing]] +- Product-Specific AMI ← extends ← [[Foundation-AMI]] ## Contradictions - 与 [[ctp-topic-58-aws-ec2-image-builder]] 描述不同 AMI 生命周期阶段： diff --git a/wiki/sources/ctp-topic-34-azure-landing-zone-architecture-overview.md b/wiki/sources/ctp-topic-34-azure-landing-zone-architecture-overview.md index 2cf36ad9..e8711d01 100644 --- a/wiki/sources/ctp-topic-34-azure-landing-zone-architecture-overview.md +++ b/wiki/sources/ctp-topic-34-azure-landing-zone-architecture-overview.md @@ -4,53 +4,56 @@ type: source tags: - Azure - Landing-Zone - - Cloud-Transformation - CTP + - Cloud-Transformation-Programme date: 2026-04-14 +last_updated: 2026-05-06 --- ## Source File - [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-34-azure-landing-zone-architecture-overview.md]] ## Summary（用中文描述） -- 核心主题：Azure Landing Zone 在 Micro Focus 内部的实施架构概述 -- 问题域：企业级多云治理（Azure 部分）——如何通过 Landing Zone 简化 Azure 接入、减少跨团队依赖、实现自动化部署 -- 方法/机制：Azure Enterprise Enrollment → 管理组（Management Groups）分层 → 独立订阅隔离目的 → Terraform Cloud IaC 自动化 -- 结论/价值：四个管理组区域（Platform / Landing Zones / Decommission / Sandbox）实现资源隔离与职责分离；Terraform Cloud 管理跨订阅依赖；PIM/PAG 实现精细化访问控制 +- 核心主题：Micro Focus 内部 Azure Landing Zone（着陆区）架构规划，旨在简化团队采用 Azure 云 +- 问题域：跨团队依赖、手动部署瓶颈、Azure 企业级接入与合规管控 +- 方法/机制：使用 Azure 管理组（Management Groups）分层组织订阅；平台/着陆区/退役/沙盒四区分离；Terraform Cloud 实现基础设施自动化；PIM 强制最小权限访问 +- 结论/价值：Landing Zone 以模板化为核心，提供身份访问管理、审计、合规、安全监控、网络四大支柱；团队可在自动化保障下独立部署创新工作负载，减少跨团队依赖 ## Key Claims（用中文描述） -- Azure Landing Zone 通过管理组（Management Groups）将组织实体分为 Platform、Landing Zones、Decommission、Sandbox 四个层级，实现分层治理 -- Platform 层包含 Identity 和 Connectivity 两个独立订阅，各自承担特定安全职责，避免职责混淆 -- Connectivity 订阅作为中心枢纽，汇聚所有入站和出站 Azure 流量，集成 DDoS 防护和 Checkpoint 防火墙 -- Landing Zones 设计为可扩展、模块化、全自动化，提供基于模板的方案供新项目使用 -- 独立订阅的核心原因是按特定目的隔离，每个订阅服务单一用途 -- Privileged Identity Management (PIM) 和 Privileged Access Groups 管理用户访问，确保角色和策略的正确执行 -- Terraform Cloud 利用 Terraform State 管理跨订阅依赖，支持分层架构 +- Kishore Garlopati（演讲人）通过 Azure Enterprise Enrollment + Azure AD 完成企业接入，目标是让各团队以最小依赖部署 Azure 工作负载 +- Azure 管理组类似 Windows 父目录，按四区组织：platform（身份/连接）、landing zones（模板化项目）、decommission（停用资源）、sandbox（隔离实验） +- 连接订阅（Connectivity）作为所有入站/出站 Azure 流量的中心枢纽，集成了 DDoS 防护和 Checkpoint 防火墙 +- Landing Zone 的核心设计原则：可扩展（Scalable）、模块化（Modular）、全自动化（Fully Automated） +- Terraform Cloud 通过 Terraform State 管理订阅间依赖关系，实现跨订阅基础设施编排 +- Privileged Identity Management (PIM) 和特权访问组确保用户获得恰到好处的角色权限 ## Key Quotes > "The primary goal is to minimize cross-team dependencies through automation, granting teams greater independence in deploying innovative solutions within the Azure environment." — Kishore Garlopati，演讲核心目标 - -> "The core reason of these individual or isolated subscriptions is you are basically containing a subscription for a specific purpose." — 独立订阅的核心设计原则 - -> "This sandbox is an interesting one because these landings on subscriptions allows your workloads." — Sandbox 环境允许团队在隔离环境中实验工作负载 +> "The core reason of these individual or isolated subscriptions is you are basically containing a subscription for a specific purpose." — 订阅隔离的设计哲学 +> "This sandbox is an interesting one because these landings on subscriptions allows your workloads." — 沙盒订阅的灵活性价值 ## Key Concepts -- [[Azure Landing Zone]]：Azure 云环境的托管基础框架，通过管理组和订阅分层实现安全、合规和可管理性，为工作负载提供标准化入口。与 [[AWS Landing Zone]] 同属多云 Landing Zone 架构的两种实现 -- [[Management Groups]]：Azure 管理组，类似于 Windows 父目录结构，用于组织和治理 Azure 租户内的实体，可分层级继承策略和访问控制 -- [[Terraform Cloud]]：HashiCorp 的 Terraform 云平台，提供 IaC 状态管理、工作流自动化和团队协作能力，用于管理跨订阅的基础设施依赖 -- [[Privileged Identity Management (PIM)]]：Azure AD 的特权身份管理服务，实现实时细粒度访问控制，确保用户仅在需要时获得特权 -- [[Privileged Access Groups]]：PIM 的组成部分，通过访问组管理用户权限，支持基于角色的策略执行 +- [[Azure-Landing-Zone]]：微软推荐的云采用框架，通过管理组和订阅层次结构为 Azure 工作负载提供可扩展、模块化、自动化的基础平台 +- [[Management-Groups]]：Azure 组织实体的高层容器，类似 Windows 父目录，用于分层管理策略和访问权限 +- [[Privileged-Identity-Management-PIM]]：Azure AD 功能，通过实时特权访问减少持久性管理员权限，降低凭证被盗风险 +- [[Terraform-Cloud]]：HashiCorp 基础设施即代码平台，支持 Terraform State 跨订阅依赖管理 +- [[Cloud-Transformation-Programme]]：Micro Focus 云转型计划，覆盖 AWS/Azure 多云 Landing Zone 建设 ## Key Entities -- [[Kishore Garlopati]]：演讲者，Azure Landing Zone 架构overview主讲人 -- [[Micro Focus]]：使用 Azure Landing Zone 进行云转型的企业组织，参考 [[AWS Landing Zone]] 在 Micro Focus 的实践经验 +- [[Kishore-Garlopati]]：Micro Focus 云架构师，Azure Landing Zone 方案主讲人 +- [[Micro-Focus]]：企业软件公司，其云转型计划（CTP）推进多云 Landing Zone 架构落地 +- [[Azure-Enterprise-Enrollment]]：Azure 企业协议接入点，是组织使用 Azure 的前提条件 +- [[Azure-Active-Directory]]：Azure 身份与访问管理服务，用于用户认证和策略控制 ## Connections -- [[AWS Landing Zone]] ← related_to ← [[Azure Landing Zone]]（同属 Landing Zone 架构，AWS 与 Azure 的不同实现） -- [[ctp-topic-1-gruntwork-landing-zone-architecture]] ← related_to ← [[AWS Landing Zone]]（AWS Landing Zone 基础入门） -- [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] ← related_to ← [[AWS Landing Zone]]（AWS Landing Zone 设计复习） -- [[ctp-topic-47-enterprise-architecture-cloud-standards]] ← extends ← [[AWS Landing Zone]]（企业架构云标准扩展） -- [[Terraform]] ← implements ← [[Terraform Cloud]]（Terraform Cloud 是 Terraform 的云端编排平台） +- [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] ← comparable_to ← [[ctp-topic-34-azure-landing-zone-architecture-overview]] +- [[ctp-topic-1-gruntwork-landing-zone-architecture]] ← related_to ← [[ctp-topic-34-azure-landing-zone-architecture-overview]] +- [[ctp-topic-9-ci-cd-with-gruntwork]] ← extends ← [[ctp-topic-1-gruntwork-landing-zone-architecture]] +- [[ctp-topic-3-deploy-and-maintain-infrastructure]] ← related_to ← [[ctp-topic-34-azure-landing-zone-architecture-overview]] ## Contradictions -- 无已知冲突内容 +- 与 [[ctp-topic-1-gruntwork-landing-zone-architecture]] 对比： + - 冲突点：AWS 侧使用 Gruntwork 基础设施模块 + Jenkins 构建 Landing Zone，Azure 侧使用 Terraform Cloud + 管理组 + - 当前观点：Azure Landing Zone 通过 Terraform Cloud 管理订阅间状态，适合 Micro Focus 多云战略 + - 对方观点：AWS Gruntwork LZ 通过 Jenkins CI/CD 管道，强调产品服务应有业务上下文（AWS Service Catalog） + - 说明：两者均为 CTP 下的 Landing Zone 实现，技术栈差异由多云战略驱动，非矛盾冲突 diff --git a/wiki/sources/ctp-topic-36-sendgrid-as-an-email-service.md b/wiki/sources/ctp-topic-36-sendgrid-as-an-email-service.md index 3faf094b..31b4e57a 100644 --- a/wiki/sources/ctp-topic-36-sendgrid-as-an-email-service.md +++ b/wiki/sources/ctp-topic-36-sendgrid-as-an-email-service.md @@ -6,59 +6,55 @@ tags: - Email - AWS - CTP - - Cloud-Email + - Cloud-Transformation date: 2026-04-14 --- ## Source File -- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-36-sendgrid-as-an-email-service.md]] +- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-36-sendgrid-as-an-email-service.md]] ## Summary（用中文描述） -- 核心主题：SendGrid 被选定为经典和新 Landing Zone 的标准邮件服务，同时更新了 Cyber Suite 加密套件标准。 -- 问题域：企业邮件服务迁移——现有邮件网关（Port 25 不安全、即将下线）和 SES（每封限制 50 收件人）无法满足云环境需求。 -- 方法/机制：SendGrid 支持每封最多 1,000 收件人、全云兼容、TLS 端到端加密、双因素认证；提供两种架构（直连 SendGrid vs 中继服务器），通过全球中继节点（伦敦/印度/东京）走私有线路汇至美国数据中心处理；支持计划覆盖每月 500 万封邮件。 -- 结论/价值：SendGrid 统一替换现有分散邮件方案，提升安全性（TLS/2FA）、扩展性（1,000 收件人）和云就绪度；Cyber Suite 标准更新了行业标准合规加密套件清单。 +- 核心主题：Cloud Transformation Program（CTP）正式采用 SendGrid 作为标准邮件服务，取代原有的语义消息网关和 SES 方案；同时更新了 Cyber Suite 安全加密标准。 +- 问题域：企业邮件服务选型、云环境兼容性、安全合规要求 +- 方法/机制：SendGrid 提供两种架构——直连发送（需 TLS）和中继发送（供不支持 TLS 的应用使用）；数据通过伦敦、印度、东京等中继服务器经私有链路汇至美国数据中心处理。 +- 结论/价值：SendGrid 支持每封邮件最多 1000 名收件人（对比 SES 仅 50 人），完全云兼容，支持实时监控日志、双因素认证和 TLS 端到端加密，月支持额度 500 万封邮件，SPF/DKIM 记录为有效发送的必要条件。 ## Key Claims（用中文描述） -- SendGrid 通过支持每封邮件最多 1,000 收件人，解决了 SES 每封仅 50 收件人的限制。 -- 现有语义消息网关通过 Port 25 向公共互联网中继邮件，存在安全漏洞，且托管在即将停用的本地网络上。 -- SendGrid 直连模式要求使用 software.microcopy.com 域名、连接 smtp.sendgrid.net:587 并启用 TLS。 -- SPF 和 DKIM 记录是确保邮件正常送达（避免进入垃圾箱或被拒收）的必要配置。 -- API 密钥每 180 天轮换一次，邮件日志保留七天。 -- Cyber Suite 标准中的可选套件因包含 CBC（Cipher Block Chaining）模式而被视为弱加密，使用非标准加密套件的产品需经 PSAC 团队审查。 +- SendGrid 被 CTP 采纳为经典和新 Landing Zone 的标准邮件服务，取代存在安全风险且即将退役的本地语义消息网关（通过不安全的 25 端口中继邮件） +- SES 现有限制为每封邮件仅 50 名收件人，SendGrid 扩展至 1000 名收件人 +- SendGrid 全云兼容，月处理约 300 亿封邮件，提供实时监控日志、双因素认证和 TLS 端到端加密 +- 直连发送架构要求：使用 software.microcopy.com 域名、连接 smtp.sendgrid.net:587、启用 TLS、发件地址必须为 software.microcopy.com 域；不支持按域名屏蔽邮件 +- 邮件日志保留 7 天，API 密钥每 180 天轮换一次，SPF 和 DKIM 记录是避免邮件进入垃圾箱或被拒收的必要条件 +- Cyber Suite 标准文档已更新，列出 FIPS/Java/Golang/Node.js/OpenCel 等标准中认可的安全加密套件 ## Key Quotes -> "SendGrid overcomes these issues by allowing up to 1,000 recipients per message and being fully cloud-compatible. Almost 30 billion emails per month customers are already used across the whole country." — Rejoy Ganapati & Rajiv, CTP Topic 36 +> "SendGrid is being adopted as the standard email service for both classic and new landing zones, replacing the existing semantic message gateway and SES solutions." — Rejoy Ganapati & Rajiv, CTP Session -> "SPF and DKIM records are essential for valid email sending to avoid emails landing in junk folders or being rejected." — CTP Topic 36 +> "The existing semantic message gateway has security concerns because it relays mail to the public internet through port 25, which is not secure." — CTP Session 背景说明 -> "An optional Cyber Suite is available for backward compatibility, but it includes CBC (Cipher Block Chaining) which is considered weak." — Yu-Yan, PSAC Cyber Suite Update +> "SendGrid overcomes these issues by allowing up to 1,000 recipients per message and being fully cloud-compatible." — CTP Session 核心优势 + +> "SPF and DKIM records are essential for valid email sending to avoid emails landing in junk folders or being rejected." — SendGrid 配置要求 ## Key Concepts -- [[SPF]]：发件人策略框架（Sender Policy Framework），DNS 记录类型，用于声明哪些邮件服务器被授权代表域名发送邮件，防止邮件伪造和垃圾邮件。 -- [[DKIM]]：域名密钥识别邮件（DomainKeys Identified Mail），通过加密签名验证邮件内容在传输过程中未被篡改，确保发件人身份真实性。 -- [[TLS]]：传输层安全协议（Transport Layer Security），在 SendGrid 中用于端到端加密邮件传输，防止中间人攻击和数据窃听。 -- [[API-Key-Rotation]]：API 密钥定期轮换策略，SendGrid 要求每 180 天轮换一次 API 密钥，是安全运维的基本规范。 -- [[Cyber-Suite]]：行业标准加密套件集合（如 FIPS、Java、Golang、Node.js、OpenCell for CNC++），PSAC 负责维护和更新。 -- [[CBC-Mode]]：密码块链接模式（Cipher Block Chaining），一种分组加密工作模式，因存在已知攻击向量（如 POODLE）而被视为弱加密方式，不推荐使用。 +- [[SendGrid]]：企业云邮件服务，支持直连和中继两种架构，月处理约 300 亿封邮件 +- [[Landing Zone]]：AWS Landing Zone，云基础设施标准架构 +- [[SPF]]：发件人策略框架，用于邮件身份验证 +- [[DKIM]]：域名密钥识别邮件，用于邮件身份验证 +- [[Cyber Suite]]：企业加密套件标准，涵盖 FIPS/Java/Golang/Node.js/OpenCel 等 ## Key Entities -- [[Rejoy Ganapati]]：SendGrid 演讲者之一，CTP Topic 36 讲师。 -- [[Rajiv]]：SendGrid 演讲者之一，CTP Topic 36 讲师。 -- [[Yu-Yan]]：PSAC（Product Security Advisory Committee）成员，负责 Cyber Suite 标准的更新与宣讲。 -- [[PSAC]]：Product Security Advisory Committee，产品安全咨询委员会，负责维护 Cyber Suite 加密标准。 -- [[SendGrid]]：Twilio 旗下的云邮件服务，作为 CTP 标准邮件服务被采纳，支持大规模邮件发送、企业级安全和云原生架构。 -- [[Twilio]]：云通信平台，SendGrid 隶属其下，是全球大规模邮件发送的基础设施提供商。 +- [[Rejoy Ganapati]]：SendGrid 方案的联合主讲人之一 +- [[Rajiv]]：SendGrid 方案的联合主讲人之一 +- [[Yu-Yan]]：PSAC 团队成员，Cyber Suite 标准更新主讲人 +- [[PSAC]]：Product Security Architecture Committee，负责 Cyber Suite 标准制定 ## Connections -- [[CTP-Topic-12-SES-SMTP]] ← replaces ← [[ctp-topic-36-sendgrid-as-an-email-service]]（SendGrid 替换 SES SMTP 模块作为标准邮件服务） -- [[ctp-topic-36-sendgrid-as-an-email-service]] ← extends ← [[AWS-Landing-Zone]]（SendGrid 接入是 Landing Zone 通信层的基础组件） -- [[ctp-topic-36-sendgrid-as-an-email-service]] ← depends_on ← [[SPF]]（SPF 记录是 SendGrid 邮件送达的必要条件） -- [[ctp-topic-36-sendgrid-as-an-email-service]] ← depends_on ← [[DKIM]]（DKIM 签名是 SendGrid 邮件验证的必要条件） -- [[ctp-topic-36-sendgrid-as-an-email-service]] ← relates_to ← [[ctp-topic-37-secrets-certificates-management]]（TLS 加密和 API 密钥轮换同属安全运维范畴） +- [[CTP Topic 12 Using SES SMTP service terraform module]] ← related_to ← [[CTP Topic 36 SendGrid as an Email Service]]（同一邮件服务主题，SES 为旧方案） +- [[CTP Topic 47 Enterprise Architecture Cloud Standards]] ← extends ← [[CTP Topic 36 SendGrid as an Email Service]]（企业云标准的一部分） ## Contradictions -- 与 [[ctp-topic-12-using-ses-smtp-service-terraform-module]] 冲突： - - 冲突点：SES SMTP 作为企业标准邮件服务与 SendGrid 被选定为新标准之间的矛盾。 - - 当前观点：SendGrid 取代 SES 成为新标准邮件服务（SES 每封限制 50 收件人，无法满足大规模需求）。 - - 对方观点：SES 通过 Terraform 模块化管理，适合特定 AWS 原生集成场景。 +- 与 [[CTP Topic 12 Using SES SMTP service terraform module]] 存在内容重叠： + - 冲突点：两期 CTP 主题均涉及邮件服务，但 Topic 12 介绍 SES SMTP，本期介绍 SendGrid + - 当前观点：SendGrid 取代 SES 作为标准方案（每封邮件收件人从 50 人扩展至 1000 人） + - 对方观点：SES 仍通过 Terraform 模块提供服务（可能用于遗留场景） diff --git a/wiki/sources/ctp-topic-40-saas-database-architecture-on-aws-cloud.md b/wiki/sources/ctp-topic-40-saas-database-architecture-on-aws-cloud.md index d4e8ecca..68bd4bbc 100644 --- a/wiki/sources/ctp-topic-40-saas-database-architecture-on-aws-cloud.md +++ b/wiki/sources/ctp-topic-40-saas-database-architecture-on-aws-cloud.md @@ -14,48 +14,47 @@ date: 2026-04-14 - [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-40-saas-database-architecture-on-aws-cloud.md]] ## Summary（用中文描述） -- 核心主题：SAS 数据库团队在 AWS 云上的数据库架构与运维实践 -- 问题域：企业级 SaaS 数据库管理、跨区域多数据库引擎运维、数据库高可用架构 +- 核心主题：CTP（CSP Transformation Programme）主题 40 —— AWS 云上 SaaS 数据库架构，介绍企业级数据库团队如何设计、管理和运维多租户 SaaS 数据库解决方案 +- 问题域：企业数据库团队在公有云（AWS）环境中的运维管理、高可用设计、成本优化和迁移实践 - 方法/机制： - - 全球分布式团队（美国/加拿大/印度/以色列）提供 24/7 支持 - - 支持 Oracle、Vertica、Postgres、DynamoDB、SQL Server、MongoDB、MySQL 等多种数据库引擎 - - 多可用区高可用部署（Oracle Data Guard、Postgres Active-Passive/Active-Active、RDS HA） - - 使用 Terraform、AWS CLI、Shell/PowerShell 脚本实现基础设施自动化 -- 结论/价值：提供企业级数据库运维的最佳实践参考，包括多数据库引擎管理、多可用区高可用设计、以及与 AWS 原生服务（CloudWatch、CloudTrail、Config）的集成 + - 多数据库引擎支持（Oracle、Vertica、Postgres、DynamoDB、SQL Server、MongoDB、MySQL） + - 多可用区高可用架构（主备分离 + Witness） + - 监控工具链（Sidescope、Oracle OEM、CloudWatch、Foglight） + - 自动化运维（Shell、Terraform、AWS CLI、PowerShell） +- 结论/价值：提供企业级 SaaS 数据库架构的完整运维视图，涵盖团队协作、SLA 支持、迁移策略和未来规划 ## Key Claims（用中文描述） -- SAS 数据库团队在全球 4 个国家设有办公地点，管理 500+ 数据库和 1000+ DB 服务器 -- 数据库主要部署在 Application VPC 内，集成安全措施 -- 高可用架构采用三可用区部署模式：一区主库、二区备用库、三区见证节点 -- 报告数据库在第三可用区部署只读仓库，通过 VPN 安全访问 -- Oracle GoldenGate 用于多租户场景，支持平滑迁移（零停机或最小停机） -- 日常运维每月处理 400-500 个 SSR 和 IM，每月至少执行 10 个变更 +- SAS 数据库团队通过 Oracle Data Guard、Postgres Active-Passive 和 RDS HA 实现多可用区高可用部署，确保业务连续性 +- 企业级数据库迁移需实现无缝迁移（无缝或不间断），通过 Oracle Golden Gate 支持多租户场景 +- 多租户 SaaS 数据库运行在应用 VPC 中，集成安全措施，支持客户通过 VPN 访问只读报表仓库 ## Key Quotes -> "The idea was to move those databases seamless without downtime or with minimum downtime." — 描述 Oracle GoldenGate 数据中心迁移项目的核心目标 +> "The idea was to move those databases seamless without downtime or with minimum downtime." — 数据中心迁移的核心目标 -> "Databases reside mostly on application VPCs with integrated security measures." — 数据库安全部署原则 +> "Databases are run in two availability zones within a region, with a primary database in one zone, a standby database in the second, and a witness in the third to observe and manage failovers." — 多可用区高可用架构描述 ## Key Concepts -- [[高可用（High Availability）]]：关注系统运行时间，MTBF 为衡量指标 -- [[Oracle Data Guard]]：Oracle 数据库的高可用解决方案，用于主备复制和故障切换 -- [[Multi-AZ Deployment]]：跨多个可用区部署数据库，确保故障隔离和灾难恢复能力 -- [[Database Migration]]：使用 Oracle GoldenGate 实现零停机或最小停机迁移 -- [[DB-as-a-Service]]：托管数据库服务模式（AWS RDS、Aurora） +- [[Multi-AZ High Availability]]：多可用区高可用架构，在区域内两个 AZ 部署主备数据库，第三个 AZ 部署 Witness 观察器和管理器 +- [[Oracle Data Guard]]：Oracle 数据库的高可用和灾难恢复技术，用于实现主备复制和故障切换 +- [[AWS RDS High Availability]]：AWS RDS 的多可用区部署模式，提供自动故障切换能力 +- [[Database Migration]]：数据中心迁移项目，目标是无缝或最小停机迁移 +- [[Multi-Tenancy]]：多租户 SaaS 数据库架构，支持多个客户共享基础设施 ## Key Entities -- [[AWS]]：Amazon Web Services，提供基础设施和托管数据库服务 -- [[Amazon RDS]]：关系型数据库服务，支持 Multi-AZ 部署 -- [[Amazon Aurora]]：云原生关系型数据库，6 副本跨 3 AZ 共享集群卷架构 -- [[AWS CloudWatch]]：监控和可观测性服务 -- [[Terraform]]：基础设施即代码工具 -- [[Micro Focus]]：SAS 产品的母公司，数据库团队隶属该组织 +- [[Micro Focus]]：企业 IT 运维解决方案提供商，其产品 Sidescope 和 Operations Bridge Manager 用于数据库监控 +- [[AWS Aurora]]：AWS 的云原生关系数据库，PostgreSQL 兼容版本 +- [[AWS RDS]]：AWS 托管数据库服务，支持多种数据库引擎 +- [[AWS CloudWatch]]：AWS 监控服务，用于数据库性能监控和告警 +- [[Oracle Golden Gate]]：Oracle 数据复制和集成软件，支持多租户场景 ## Connections -- [[ctp-topic-7-saas-landing-zone-design]] ← related_to ← [[ctp-topic-40-saas-database-architecture-on-aws-cloud]] -- [[ctp-topic-51-purpose-built-databases]] ← extends ← [[ctp-topic-40-saas-database-architecture-on-aws-cloud]] -- [[ctp-topic-66-rds-vs-aurora]] ← related_to ← [[ctp-topic-40-saas-database-architecture-on-aws-cloud]] -- [[ctp-topic-44-aws-backup-in-micro-focus]] ← related_to ← [[ctp-topic-40-saas-database-architecture-on-aws-cloud]] +- [[CTP Topic 7 SaaS Landing Zone Design]] ← related_to ← [[CTP Topic 40 SaaS Database Architecture On AWS Cloud]] +- [[CTP Topic 35 AWS Landing Zone Design Refresher (SaaS Labs)]] ← related_to ← [[CTP Topic 40 SaaS Database Architecture On AWS Cloud]] +- [[CTP Topic 66 Exposing the differences between PostgreSQL RDS and Aurora]] ← related_to ← [[CTP Topic 40 SaaS Database Architecture On AWS Cloud]] ## Contradictions -- 无明显冲突内容 +- 无明显内容冲突 + +## Notes +- 原始来源为 NAS 存储的视频文件（CTP Topic 40） +- 状态：已通过 Gemini 生成摘要，待 Whisper 转录后可补充详细内容 diff --git a/wiki/sources/ctp-topic-50-ami-roadmap-for-aws-amis.md b/wiki/sources/ctp-topic-50-ami-roadmap-for-aws-amis.md index 8e234e21..ca1a94a1 100644 --- a/wiki/sources/ctp-topic-50-ami-roadmap-for-aws-amis.md +++ b/wiki/sources/ctp-topic-50-ami-roadmap-for-aws-amis.md @@ -31,9 +31,9 @@ date: 2026-04-14 > "The AMIs are shared with every account in the organization, including the AMI itself, EBS volumes, and KMS keys." — 跨账号分发机制 ## Key Concepts -- [[Foundation AMI]]：CCOE 提供的安全加固基础镜像，是产品团队构建产品特定 AMI 的基础（本话题中称"CCOE AMI"，与 [[ctp-topic-26-standard-ami-build-publish-share-processes]] 中的 Foundation AMI 概念一致） +- [[Foundation-AMI]]：CCOE 提供的安全加固基础镜像，是产品团队构建产品特定 AMI 的基础（本话题中称"CCOE AMI"，与 [[ctp-topic-26-standard-ami-build-publish-share-processes]] 中的 Foundation AMI 概念一致） - [[OS-End-of-Life]]：操作系统生命周期终止管理，包括 Windows Server 2008/2008 R2、CentOS 8、Windows Server 2012、RHEL 7、CentOS 7 等多个 EOL 时间节点 -- [[AMI Sharing]]：跨账号 AMI 共享机制，将 AMI、EBS 卷和 KMS 密钥分发给组织内所有账户 +- [[AMI-Sharing]]：跨账号 AMI 共享机制，将 AMI、EBS 卷和 KMS 密钥分发给组织内所有账户 - [[ARM-AMI]]：ARM 处理器架构的 AMI，自 2023 年 5 月起纳入统一发布计划 - [[CCOE]]：Cloud Center of Excellence，负责提供和维护企业标准 AMI - [[ADM]]：Architecture Decision Management，AMI 路线图优先级的主要驱动来源 diff --git a/wiki/sources/ctp-topic-58-aws-ec2-image-builder.md b/wiki/sources/ctp-topic-58-aws-ec2-image-builder.md index 896d4d09..a35bcb0a 100644 --- a/wiki/sources/ctp-topic-58-aws-ec2-image-builder.md +++ b/wiki/sources/ctp-topic-58-aws-ec2-image-builder.md @@ -1,57 +1,57 @@ --- title: "CTP Topic 58 AWS EC2 Image Builder" type: source -tags: - - AWS - - EC2 - - Image-Builder - - CTP - - AMI +tags: [AWS, EC2, Image-Builder, CTP, DevOps] date: 2026-04-14 +sources: [] +last_updated: 2026-04-28 --- ## Source File - [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-58-aws-ec2-image-builder.md]] ## Summary（用中文描述） -- 核心主题：AWS EC2 Image Builder 替代 Packer/Jenkins 实现企业级 AMI 生命周期自动化管理 -- 问题域：当前 AMI 发布流程依赖 GitLab 加固脚本 + Jenkins + Packer，存在修改周期长、跨 Landing Zone 兼容性差、手动 Bakery 自动化不足等问题 -- 方法/机制：Image Builder 通过 Pipeline（流水线）/Recipe（配方）/Component（组件）/Infrastructure Config 四层抽象，将 CCOE 加固脚本模块化为可复用组件，产品团队通过服务模块向 Golden AMI 添加组件 -- 结论/价值：提升生产力（自动化）、构建时内建测试、合规加固标准、跨账户跨区域分发；与 AWS Organizations/RAM 集成；支持 AWS Inspector Lambda 工作流做 AMI 安全扫描 +- 核心主题：AWS EC2 Image Builder 服务 — 自动化创建、管理和分发 AMIs 及 Docker 镜像的托管服务 +- 问题域：企业 AWS Landing Zone 环境中的标准化镜像构建与分发流程 +- 方法/机制：通过 Image Pipeline、Image Recipe、Infrastructure Configuration、Distribution Settings 等组件协同工作；使用 YAML 定义镜像配方；CCOE 提供 Golden AMI，产品团队可在此基础上追加自定义组件 +- 结论/价值：提升镜像构建效率、整合安全加固标准、跨账号/跨区域自动化分发，与 AWS Organizations 和 AWS RAM 深度集成 ## Key Claims（用中文描述） -- Image Builder 通过 Pipeline/Recipe/Component/Infrastructure Config 四层组件实现 AMI 构建全生命周期自动化 -- 当前 AMI 发布流程（GitLab + Jenkins + Packer）存在修改周期长、跨 LZ 兼容性差、手动 Bakery 自动化不足等缺陷 -- POC 已实现 CentOS 7 和 Ubuntu 18 端到端流水线，CCOE 加固脚本转换为独立组件 -- Lambda 工作流触发 AWS Inspector 扫描、邮件通知、S3 报告归档，维护历史 AMI 数据 -- Qualys 扫描集成正在评估中 +- Image Builder 通过组件化设计（Component）实现模块化镜像定制，每个组件是源 AMI 内执行的一个步骤 +- 当前 AMI 发布流程依赖 GitLab 仓库中的 OS 加固脚本 + Jenkins + Packer，存在交付周期长、跨 Landing Zone 兼容性差等问题 +- Image Builder 与 AWS Organizations 和 AWS RAM 集成，支持跨托管账户的 AMI 分发 +- POC 已实现 CentOS 7 和 Ubuntu 18 的端到端 Pipeline，CCOE 加固脚本已转换为独立组件 +- AWS Inspector 集成用于 AMI 安全扫描，Lambda 工作流触发扫描并通过邮件通知上传报告至 S3 ## Key Quotes -> "A component is basically just a particular step that you want to execute in order to achieve the output AMI." — Image Builder 组件定义 -> "Due to these limitations, eventually the product teams try to cater to their requirements by developing some kind of workflow or CI CD pipelines wherein they consume that CCOE AMI and they try to update or install whatever packages they require." — 当前流程的局限性驱动产品团队自建 CI/CD -> "Product groups can use a service module to add components to the golden AMI. A component is a script, and components should be added in alphabetical order." — 产品团队通过服务模块添加组件的机制 +> "A component is basically just a particular step that you want to execute in order to achieve the output AMI." — 组件定义 +> "Due to these limitations, the product teams try to cater to their requirements by developing some kind of workflow or CI CD pipelines wherein they consume that CCOE AMI and they try to update or install whatever packages they require." — 当前痛点与团队应对方式 ## Key Concepts -- [[Golden-AMI]]：由 CCOE 维护的标准化基础镜像，产品团队在其上添加自定义组件 -- [[CCOE]]（Cloud Center of Excellence）：云卓越中心，负责维护 Golden AMI 和加固脚本 -- [[Image-Pipeline]]：定义 AMI 发布时间线、安装步骤、安全加固和分发策略 -- [[Image-Recipe]]：YAML 格式定义源 AMI 到输出 AMI 的转换规则 -- [[Image-Component]]：在源 AMI 内执行的具体步骤（安装包、运行脚本） -- [[Infrastructure-Configuration]]：定义构建 AMI 所需的 EC2 实例属性（类型/VPC/子网/安全组） -- [[Distribution-Settings]]：管理 AMI 跨区域跨账户的分发配置 -- [[AWS-Inspector]]：AWS 原生 AMI 安全扫描工具 +- [[AMI-Image-Builder]]：AWS 托管服务，用于自动化 AMIs 和 Docker 镜像的创建、管理和分发 +- [[Image-Pipeline]]：定义 AMI 发布时间线，包含安装、安全加固和分发计划 +- [[Image-Recipe]]：YAML 编写的配方，定义源 AMI 与输出 AMI 的关系；Container Recipe 支持 Docker 镜像 +- [[Golden-AMI]]：CCOE 构建的基础镜像（Golden AMI），产品团队在其上追加组件 +- [[AWS-Organizations]] 与 [[AWS-RAM]]：跨账号分发 AMIs 的机制 +- [[AWS-Inspector]]：集成用于 AMI 安全扫描，发现安全漏洞和合规问题 +- [[AWS-Landing-Zone]]：背景上下文 — Image Builder 服务于 Landing Zone 环境的标准化需求 ## Key Entities -- [[AWS]]：Image Builder 服务的云提供商 +- [[AWS]]：服务提供商 +- [[AWS-Inspector]]：安全扫描集成 +- [[AWS-Organizations]]：跨账号管理 +- [[AWS-RAM]]：资源访问管理 +- [[AWS-CloudWatch]]：日志发布目标 +- [[AWS-Lambda]]：触发扫描和通知的工作流引擎 +- [[Qualys]]：安全扫描集成（评估中） +- [[Packer]]：当前 AMI 构建工具（将被 Image Builder 替代） +- [[Jenkins]]：当前 CI/CD 流程（将被 Image Builder 替代） +- [[Terraform]]：用于创建 Image Builder 资源的 IaC 工具 ## Connections -- [[ctp-topic-26-standard-ami-build-publish-share-processes]] ← builds_on ← [[ctp-topic-58-aws-ec2-image-builder]]（Image Builder 是对 Packer/Jenkins AMI 流程的升级） -- [[ctp-topic-58-aws-ec2-image-builder]] ← depends_on ← [[learning-sessions-standard-amis-updates]]（CCOE 加固脚本和标准 AMI 生命周期管理是 Image Builder 的输入） -- [[ctp-topic-50-ami-roadmap-for-aws-amis]] ← related_to ← [[ctp-topic-58-aws-ec2-image-builder]]（AMI 路线图与 Image Builder 自动化策略相关） +- [[CTP-Topic-50-AMI-Roadmap]] ← relates_to ← [[CTP-Topic-58-AWS-EC2-Image-Builder]] +- [[CTP-Topic-26-Standard-AMI-Process]] ← extends ← [[CTP-Topic-58-AWS-EC2-Image-Builder]] +- [[CTP-Topic-35-AWS-Landing-Zone]] ← belongs_to ← [[CTP-Topic-58-AWS-EC2-Image-Builder]] ## Contradictions -- 与 [[ctp-topic-26-standard-ami-build-publish-share-processes]]： - - 冲突点：当前 AMI 流程（GitLab + Jenkins + Packer）vs Image Builder 自动化流程 - - 当前观点：Packer/Jenkins 流程是现状，存在修改周期长、跨 LZ 兼容性差等问题 - - 对方观点：Jenkins 多分支流水线 + 机器人框架验证已将验证周期从 3-4 天缩短至 60 分钟 - - 说明：两者并非完全矛盾——Image Builder 替代 Packer 作为镜像构建工具，而 Jenkins 流水线可能继续用于 Terraform 部署触发 +- （暂无发现与其他 Wiki 页面的冲突） diff --git a/wiki/sources/ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora.md b/wiki/sources/ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora.md index f497a989..505c2494 100644 --- a/wiki/sources/ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora.md +++ b/wiki/sources/ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora.md @@ -11,7 +11,7 @@ date: 2026-04-14 --- ## Source File -- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora.md]] +- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora.md]] ## Summary（用中文描述） - 核心主题：PostgreSQL 在 Amazon RDS 与 Aurora 两种托管方案之间的技术差异对比，涵盖性能、成本、架构、灾备与高可用性等维度 diff --git a/wiki/sources/ctp-topic-68-introduction-to-redshift.md b/wiki/sources/ctp-topic-68-introduction-to-redshift.md index 3a8666e1..0fdab383 100644 --- a/wiki/sources/ctp-topic-68-introduction-to-redshift.md +++ b/wiki/sources/ctp-topic-68-introduction-to-redshift.md @@ -13,51 +13,51 @@ date: 2026-04-14 - [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-68-introduction-to-redshift.md]] ## Summary（用中文描述） -- 核心主题：AWS Redshift 数据仓库服务的基础架构、核心组件及关键特性 -- 问题域：云端 PB 级数据仓库的选型与架构设计 -- 方法/机制：Leader Node + Compute Node MPP 并行架构、列式存储、行式存储、数据压缩（ZSTD/LZO）、Sort Key、Distribution Key -- 结论/价值：Redshift 是完全托管的 PB 级云数据仓库，支持 OLAP，提供 Leader Node 负责查询规划和元数据管理，Compute Node 通过 Slices 执行并行查询；RA3 实例类型性价比最优，支持 AWS 托管 NVMe 存储；Sort Key 和 Dist Key 是性能优化的关键配置 +- 核心主题：AWS Redshift 数据仓库的架构、核心组件及关键特性 +- 问题域：企业级云数据仓库设计与选型 +- 方法/机制：Redshift 集群架构（Leader Node + Compute Node）、列式存储 vs 行式存储、MPP 大规模并行处理、数据压缩、Sort Key 与 Dist Key 优化 +- 结论/价值：Redshift 是完全托管的 PB 级云数据仓库解决方案，专为 OLAP 场景设计，提供快速安装、自动备份、点时间恢复及跨区域灾难恢复能力 ## Key Claims（用中文描述） -- Redshift 通过 Leader Node 管理 Schema、元数据和查询计划，将指令分发至 Compute Node 执行，实现 MPP（大规模并行处理），显著提升查询速度和响应时间 -- Redshift 支持列式存储（适合数据仓库操作）和行式存储两种模式，列式存储因更快的查询性能和更高的内存利用率而更适合 OLAP 场景 -- RA3 实例类型因其成本效益和大规模存储容量而被推荐，底层使用 AWS 托管的 NVMe 存储 -- Sort Key（排序键）和 Dist Key（分布键）是 Redshift 性能优化的核心机制，决定数据分布和查询执行效率 +- Redshift 通过 Leader Node 管理 Schema、元数据和查询计划，由 Compute Node 在各 Slice 上并行执行查询，实现高速数据检索 +- Redshift 支持三种实例类型（Dense Compute、Dense Storage、RA3），RA3 以 AWS 托管 NVMe 存储提供成本效益和大规模存储容量 +- MPP（大规模并行处理）通过跨多个 Compute Node 并行处理查询，显著提升查询速度和响应时间 +- 列式存储专为数据仓库操作优化，相比行式存储具有更快的查询性能和更高的内存使用效率 +- Sort Key 和 Dist Key 在优化查询性能和管理 Compute Node 间数据分布方面起关键作用 ## Key Quotes -> "Redshift is a fully managed, petabyte-scale data warehouse solution in the cloud. It is designed for data warehousing, enabling quick data retrieval from large datasets." — 视频摘要 - -> "The leader node manages schema, warehouse metadata, and query planning, distributing instructions to compute nodes." — Redshift 架构说明 - -> "Compute nodes, determined by the instance type, execute queries across slices, processing data and returning results to the leader node." — Compute Node 工作机制 - -> "RA3 is noted for its cost-effectiveness and large storage capacity, utilizing AWS-managed NVMe storage." — RA3 实例优势 +> "Redshift is a fully managed, petabyte-scale data warehouse solution in the cloud. It is designed for data warehousing, enabling quick data retrieval from large datasets." — Redshift 核心定位 +> "The leader node manages schema, warehouse metadata, and query planning, distributing instructions to compute nodes." — 架构职责划分 +> "RA3 is noted for its cost-effectiveness and large storage capacity, utilizing AWS-managed NVMe storage." — RA3 实例特点 ## Key Concepts -- [[MPP (Massively Parallel Processing)]]：通过多个 Compute Node 并行处理查询，提升大规模数据集的查询速度和响应时间 -- [[列式存储（Columnar Storage)]]：数据按列而非按行存储，适合数据仓库的聚合查询和扫描操作，提供更快的查询性能和更高的内存效率 -- [[数据压缩（Data Compression)]]：采用 ZSTD/LZO 等压缩算法减少数据大小，提升 I/O 效率和查询性能 -- [[Sort Key（排序键)]]：决定数据在磁盘上的物理排序顺序，对范围查询和过滤操作性能影响显著 -- [[Distribution Key（分布键)]]：决定数据在 Compute Node 间如何分布，影响数据倾斜和节点间数据传输 -- [[OLAP（在线分析处理)]]：面向复杂分析查询的工作负载类型，Redshift 的核心设计目标 -- [[Leader Node（主节点)]]：Redshift 架构中的协调节点，负责客户端连接、Schema 管理、元数据存储和查询计划生成 -- [[Compute Node（计算节点)]]：Redshift 架构中的执行节点，负责在 Slices 上执行查询并返回结果 +- [[MassivelyParallelProcessing]]：跨多个计算节点并行处理查询，提升查询速度和响应时间 +- [[ColumnarStorage]]：列式存储，专为数据仓库操作优化，具有更快的查询性能和更高的内存使用效率 +- [[RowBasedStorage]]：行式存储，适用于事务性操作 +- [[DataCompression]]：数据压缩技术（如 LZO），减少数据大小以提升性能 +- [[SortKey]]：排序键，用于优化查询和管理 Compute Node 间数据分布 +- [[DistributionKey]]：分布键（Dist Key），决定数据在 Compute Node 间的分布方式 +- [[SliceArchitecture]]：Compute Node 内部的数据处理单元，每个 Slice 独立执行查询片段 +- [[OLAP]]：在线分析处理，Redshift 的主要工作负载类型 ## Key Entities -- [[Amazon Redshift]]：AWS 提供的大规模并行处理数据仓库服务，支持 PB 级数据存储，面向 OLAP 工作负载 -- [[AWS]]：Amazon Web Services，云服务提供商，Redshift 的托管平台 -- [[RA3]]：Redshift 的高性价比实例类型，配备 AWS 托管 NVMe 存储，适合大容量存储场景 -- [[Dense Compute]]：Redshift 高计算密度实例类型，适合计算密集型查询 -- [[Dense Storage]]：Redshift 高存储密度实例类型，适合存储密集型工作负载 -- [[JDBC/ODBC]]：Redshift 客户端驱动协议，客户端应用通过 JDBC/ODBC 连接至 Redshift Cluster +- [[AWSRedshift]]：AWS 提供的大规模并行云数据仓库服务，完全托管，支持 PB 级数据 +- [[LeaderNode]]：Redshift 集群中的协调节点，负责 Schema 管理、元数据维护和查询规划 +- [[ComputeNode]]：Redshift 集群中的计算节点，负责在 Slice 上执行查询并返回结果 +- [[JDBC]]：Java 数据库连接协议，Redshift 客户端连接方式之一 +- [[ODBC]]：开放数据库连接协议，Redshift 客户端连接方式之一 +- [[AWSManagedNVMe]]：RA3 实例使用的 AWS 托管 NVMe 存储，提供高性能和成本效益 ## Connections -- [[ctp-topic-51-purpose-built-databases]] ← related_to ← [[Amazon Redshift]] -- [[ctp-topic-66-rds-vs-aurora]] ← related_to ← [[Amazon Redshift]] -- [[ctp-topic-40-saas-database-architecture-on-aws-cloud]] ← related_to ← [[Amazon Redshift]] +- [[CTP_Topic_58_AWS_EC2_Image_Builder]] ← topic_related ← [[AWSRedshift]]（同属 AWS Landing Zone 学习系列） +- [[AWSRedshift]] ← uses ← [[MassivelyParallelProcessing]] +- [[AWSRedshift]] ← uses ← [[ColumnarStorage]] +- [[AWSRedshift]] ← uses ← [[DataCompression]] +- [[LeaderNode]] ← coordinates ← [[ComputeNode]] ## Contradictions -- 与 [[ctp-topic-66-rds-vs-aurora]] 的数据写入模式： - - 冲突点：Aurora 采用共享存储架构（6副本跨3 AZ），而 Redshift 采用独立 Compute Node 架构；Aurora 更适合写入密集型 OLTP，Redshift 更适合分析密集型 OLAP - - 当前观点：Redshift 的列式存储 + MPP 是大规模数据分析的最优架构 - - 对方观点：Aurora 的共享存储简化了 HA 和 DR，且 Blue-Green 部署支持更灵活 +- 与 [[CTP_Topic_66_ExposingDifferencesBetweenPostgreSQLRDSandAurora]] 潜在关系： + - 冲突点：PostgreSQL RDS/Aurora 与 Redshift 在数据仓库场景下的取舍 + - 当前观点：Redshift 专为 OLAP 设计（PB 级、列式存储、MPP） + - 对方观点：PostgreSQL RDS/Aurora 适合混合 OLTP/OLAP 场景 + - 说明：两者定位不同，但均用于数据存储与查询，需根据具体场景选择 diff --git a/wiki/sources/ctp-topic-7-saas-landing-zone-design.md b/wiki/sources/ctp-topic-7-saas-landing-zone-design.md index 93bb3c0f..76d6ff6d 100644 --- a/wiki/sources/ctp-topic-7-saas-landing-zone-design.md +++ b/wiki/sources/ctp-topic-7-saas-landing-zone-design.md @@ -1,8 +1,9 @@ --- title: "CTP Topic 7 SaaS Landing Zone Design" type: source -tags: [] +tags: [AWS, Landing-Zone, SaaS, CTP, Multi-Account, Terraform, Jenkins] date: 2026-04-14 +last_updated: 2026-05-06 --- ## Source File @@ -49,9 +50,9 @@ date: 2026-04-14 ## Connections - [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] ← extends ← [[ctp-topic-7-saas-landing-zone-design]] - [[ctp-topic-1-gruntwork-landing-zone-architecture]] ← extends ← [[ctp-topic-7-saas-landing-zone-design]] -- [[ctp-topic-14-octane-hub-on-aws]] ← uses ← [[ctp-topic-7-saas-landing-zone-design]] -- [[ctp-topic-31-network-segregation-and-secure-access]] ← related_to ← [[ctp-topic-7-saas-landing-zone-design]] -- [[ctp-topic-11-ad-integration-and-login]] ← related_to ← [[ctp-topic-7-saas-landing-zone-design]] +- [[ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i]] ← uses ← [[ctp-topic-7-saas-landing-zone-design]] +- [[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]] ← related_to ← [[ctp-topic-7-saas-landing-zone-design]] +- [[ctp-topic-11-ad-integration-and-login-using-ad-accounts]] ← related_to ← [[ctp-topic-7-saas-landing-zone-design]] - [[ctp-topic-19-configuring-dns-within-aws-lzs]] ← related_to ← [[ctp-topic-7-saas-landing-zone-design]] - [[ctp-topic-29-cloud-monitoring-saas-lz-accounts]] ← related_to ← [[ctp-topic-7-saas-landing-zone-design]] diff --git a/wiki/sources/ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program.md b/wiki/sources/ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program.md index b83dc504..a987ea45 100644 --- a/wiki/sources/ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program.md +++ b/wiki/sources/ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program.md @@ -4,53 +4,67 @@ type: source tags: - AWS - Backup - - Cloud Transformation Programme + - CTP + - Cloud Transformation - SRE - DR date: 2026-04-14 +sources: [] +last_updated: 2026-04-28 --- ## Source File - [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program.md]] ## Summary（用中文描述） -- 核心主题：AWS Backup 在云转型计划中的企业级实施落地 -- 问题域：如何在多账户 AWS 环境中标准化备份流程，同时给予产品团队自主管理灵活性 -- 方法/机制：SRE 团队开发 SRE Backup Model，为每个产品组提供预置的 AWS Backup Plans、Selections、Vaults、KMS 密钥策略等模板，支持在 DRA 账户内独立执行备份和恢复；设计从源账户初始备份并复制到远程 DR 账户和区域；AWS Backup Audit Manager 提供合规审计报告 -- 结论/价值：AWS Backup 作为战略性备份工具，通过 SRE Model 实现"集中管控 + 分散执行"的平衡，标准化备份流程同时保留产品团队灵活性 +- 核心主题：AWS Backup 在云转型计划中的具体落地实施 +- 问题域：企业级 AWS 环境中如何标准化备份流程，如何让各产品团队在统一框架下自主管理备份 +- 方法/机制： + - SRE Core/Product/Architecture 团队协作设计 SRE 备份模型 + - 采用 AWS Backup 作为战略备份工具（原生托管、多资源支持） + - 产品组在 DRA 账户中独立创建和管理备份计划、对齐预设备份策略 + - 初始备份在源账户完成，复制到远程 DR 账户（或 Databunker 集中账户） + - AWS Backup Audit Manager 提供合规报告和 SNS 告警 +- 结论/价值：通过 SRE 备份模型标准化 AWS 备份，降低产品团队接入复杂度，实现跨账户、跨区域的合规备份和即时恢复 ## Key Claims（用中文描述） -- SRE 核心团队通过开发 SRE Backup Model，简化了 AWS Backup 的采纳门槛，使产品组能够在其 DRA 账户内自主创建和管理备份 -- AWS Backup 选择原因：原生托管服务、支持 TAC-based 备份计划、跨账户跨区域复制、备份不可变性、开箱即用审计报告、S3/RDS 点时间恢复 -- 备份设计：初始备份在源账户执行，复制到远程 DR 账户和区域（如 DR 不可用则使用 Databunker 作为集中备份账户），确保即时恢复能力 -- AWS Backup Audit Manager 提供合规控制：备份计划保护、最小频率和保留期、防手动删除恢复点、加密验证、计划性跨区域和跨账户备份 +- SRE Core/Product/Architecture 团队协作设计了 SRE 备份模型，使产品团队能在各自 DRA 账户内独立完成备份和恢复操作 +- AWS Backup 被选为 CTP 战略备份工具，因其为 AWS 原生服务，支持多资源类型、跨账户/跨区域、备份不可变性、开箱即用审计报告及 S3/RDS 时间点恢复 +- 备份设计从源账户取初始备份，复制到专属 DR 账户（或 Databunker 集中账户），确保恢复时无需耗时复制数据 +- AWS Backup Audit Manager 提供合规框架和控制项，可验证备份覆盖率、最小频率和保留期、手动删除防护、加密、计划性跨区域/跨账户备份 ## Key Quotes -> "AWS backup was adopted as the strategic tool for backup in AWS for the cloud transformation program to standardize backup processes." — AWS Backup 被选为云转型计划的战略性备份工具 -> "An SRE model was developed to allow product groups to create and control their own backups, aligned with the assumed backup policy." — SRE Model 赋予产品组自主创建和管理备份的能力 -> "This keeps backups within the DR account for immediate restore, avoiding time-consuming data copies." — 备份保留在 DR 账户内以实现即时恢复 + +> "The SRE models were adjusted to optionally create custom KMS keys, which is a fundamental requirement for having a remote account and region for the AWS backup processes." — KMS 自定义密钥是实现跨账户跨区域备份的基础前提 + +> "This keeps backups within the DR account for immediate restore, avoiding time-consuming data copies." — 备份保留在 DR 账户内可实现即时恢复 + +> "AWS backup audit manager framework includes controls that help evaluate backup practices, providing compliance reports." — Audit Manager 提供合规评估控制项 ## Key Concepts -- [[AWS Backup]]：AWS 原生托管备份服务，支持多资源类型的集中备份和恢复策略管理 -- [[SRE Model]]：Site Reliability Engineering 团队开发的备份管理模式，为产品组提供标准化但可定制的备份基础设施 -- [[AWS Backup Audit Manager]]：AWS Backup 内置合规审计框架，提供备份状态报告和合规控制评估 -- [[跨账户备份]]：通过 AWS Organizations 将备份从源账户复制到独立的 DR/Bunker 账户，实现备份隔离 -- [[Vault Lock]]：备份保险库合规锁定模式，防止任何人（包括根用户）提前删除恢复点 +- [[DisasterRecovery]]：灾备策略，DR 账户用于存储跨区域备份副本 +- [[ImmutableBackup]]：备份不可变性，防止恢复点被手动删除 +- [[LifecyclePolicy]]：生命周期策略，管理备份的存储层级和自动过期 +- [[PointInTimeRecovery]]：时间点恢复，支持 S3 和 RDS 的精确恢复 +- [[SRE-Model]]：SRE 备份模型，由 SRE 团队创建 AWS Backup 计划、Vault、KMS 策略等，产品组自主控制 +- [[MultiAccountArchitecture]]：多账户架构，DRA 账户隔离灾备资源 ## Key Entities -- [[AWS]]：云服务提供商，AWS Backup 为其原生备份服务 -- [[Cloud Transformation Programme]]（CTP）：企业级云转型计划，本视频为其 Topic 73，聚焦 AWS Backup 实施 -- SRE（Site Reliability Engineering）Core/Product/Architecture Teams：SRE 核心、产品和架构团队协作设计备份策略 -- DRA Accounts：Disaster Recovery Application Accounts，各产品组在其 DRA 账户内管理自有备份 +- [[AWSBackup]]：AWS 原生备份服务，作为 CTP 战略备份工具，提供跨账户/跨区域、不可变性、审计报告等能力 +- [[AWSBackupAuditManager]]：AWS Backup Audit Manager，提供合规报告、控制项评估和 SNS 告警 +- [[DRA-Account]]（DRA 账户）：每个生产工作负载账户的专属灾备账户，存储跨区域备份副本 +- [[Databunker]]：集中备份账户，当 DR 账户不可用时作为备份存储的备选集中账户 +- [[KMS]]：AWS Key Management Service，用于加密备份恢复点，支持自定义密钥 +- [[SRE-Core-Team]]：SRE Core 团队，与 SRE Product/Architecture 协作设计备份模型 +- [[SNS]]：Simple Notification Service，用于备份状态告警通知 ## Connections -- [[ctp-topic-72-enterprise-dr-strategy-aws-backup]] ← extends ← [[ctp-topic-73-aws-backup-implementation]]（Topic 72 提供理论基础，Topic 73 聚焦实施落地） -- [[ctp-topic-44-aws-backup-in-micro-focus]] ← relates_to ← [[ctp-topic-73-aws-backup-implementation]]（两者均讨论 AWS Backup，Topic 44 聚焦 Micro Focus 内部评估） -- [[AWS Backup]] ← depends_on ← [[AWS Backup Audit Manager]]（Audit Manager 是 AWS Backup 的合规增强组件） -- [[AWS Backup]] ← supports ← [[跨账户备份]]（跨账户跨区域复制是 AWS Backup 的核心能力） +- [[AWSBackup]] ← uses ← [[AWSBackupAuditManager]] +- [[AWSBackup]] ← uses ← [[KMS]] +- [[AWSBackup]] ← notifies via ← [[SNS]] +- [[CTP-Topic-72-Implementing-an-Enterprise-DR-Strategy-Using-AWS-Backup]] ← extends ← [[CTP-Topic-73-AWS-Backup-Implementation]] +- [[AWSBackup]] ← stores backups in ← [[DRA-Account]] +- [[DRA-Account]] ← fallback ← [[Databunker]] ## Contradictions -- 与 [[ctp-topic-44-aws-backup-in-micro-focus]] 存在视角差异： - - 冲突点：Topic 44 讨论 Micro Focus 现有备份评估（快照管理 vs AWS Backup 选型） - - 当前观点：Topic 73 作为 CTP 实施指南，确认 AWS Backup 为标准工具 - - 对方观点：Topic 44 提及 AWS Backup 的局限性（无法选择性排除 EC2 附加卷、崩溃一致而非热备份） +- 无明显冲突 diff --git a/wiki/sources/if-you-have-multiple-interests-do-not-waste-the-next-2-3-years-如果你有多项兴趣爱好-不要浪费接下来的两三年时间.md b/wiki/sources/if-you-have-multiple-interests-do-not-waste-the-next-2-3-years-如果你有多项兴趣爱好-不要浪费接下来的两三年时间.md index 61db6d6e..f02b5f94 100644 --- a/wiki/sources/if-you-have-multiple-interests-do-not-waste-the-next-2-3-years-如果你有多项兴趣爱好-不要浪费接下来的两三年时间.md +++ b/wiki/sources/if-you-have-multiple-interests-do-not-waste-the-next-2-3-years-如果你有多项兴趣爱好-不要浪费接下来的两三年时间.md @@ -6,7 +6,7 @@ date: 2026-04-27 --- ## Source File -- [[AI/If you have multiple interests, do not waste the next 2-3 years 如果你有多项兴趣爱好，不要浪费接下来的两三年时间。]] +- [[raw/AI/If you have multiple interests, do not waste the next 2-3 years 如果你有多项兴趣爱好，不要浪费接下来的两三年时间。.md]] ## Summary（用中文描述） - 核心主题：在 AI 时代，多重兴趣不是弱点，而是个人最大的竞争优势；传统专业化分工已过时，通才型思维才是通往独立与自由的道路。 diff --git a/wiki/sources/install-wsl.md b/wiki/sources/install-wsl.md index 9cb59599..544d9aca 100644 --- a/wiki/sources/install-wsl.md +++ b/wiki/sources/install-wsl.md @@ -10,7 +10,7 @@ date: 2026-04-18 --- ## Source File -- [[Home Office/Install WSL]] +- [[raw/Home Office/Install WSL.md]] ## Summary（用中文描述） - 核心主题：Windows Subsystem for Linux (WSL) 的安装与配置 diff --git a/wiki/sources/learn-ai-for-free-directly-from-top-companies.md b/wiki/sources/learn-ai-for-free-directly-from-top-companies.md index 42b2c265..5710cb0a 100644 --- a/wiki/sources/learn-ai-for-free-directly-from-top-companies.md +++ b/wiki/sources/learn-ai-for-free-directly-from-top-companies.md @@ -9,7 +9,7 @@ date: 2026-04-16 --- ## Source File -- [[AI/Learn AI for free directly from top companies.md]] +- [[raw/AI/Learn AI for free directly from top companies.md]] ## Summary（用中文描述） - 核心主题：汇总顶级科技公司和AI组织提供的免费学习资源，帮助用户免费学习AI技能 diff --git a/wiki/sources/learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2.md b/wiki/sources/learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2.md index 5f351130..1839d196 100644 --- a/wiki/sources/learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2.md +++ b/wiki/sources/learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2.md @@ -3,6 +3,7 @@ title: "Learning Sessions: Standard AMI Updates 20231205" type: source tags: ["AWS", "AMI", "Landing-Zone", "DevOps", "Automation"] date: 2023-12-05 +last_updated: 2026-05-08 --- ## Source File @@ -50,4 +51,5 @@ date: 2023-12-05 - [[ctp-topic-58-aws-ec2-image-builder]] ← related_to ← [[learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2]] ## Contradictions -- 暂无已知冲突 +- 与 [[ctp-topic-50-ami-roadmap-for-aws-amis]] 无冲突，EOL 时间线一致（CentOS 7/RHEL 7：2024 年 6 月；OpenSUSE Leap 15/OEL 7：2024 年 12 月） +- 与 [[ctp-topic-26-standard-ami-build-publish-share-processes]] 无冲突，属 AMI 生命周期不同视角（本文侧重更新机制和验证自动化，Topic 26 侧重构建发布共享流程） diff --git a/wiki/sources/mac必装软件清单-2026-04-17.md b/wiki/sources/mac必装软件清单-2026-04-17.md index 9dd633b6..35741b4e 100644 --- a/wiki/sources/mac必装软件清单-2026-04-17.md +++ b/wiki/sources/mac必装软件清单-2026-04-17.md @@ -8,7 +8,7 @@ last_updated: 2026-04-28 --- ## Source File -- [[Home Office/Mac必装软件清单-2026-04-17.md]] +- [[raw/Home Office/Mac必装软件清单-2026-04-17.md]] ## Summary（用中文描述） - 核心主题：Mac 用户必备软件推荐清单 diff --git a/wiki/sources/obsidian-官方-cli-命令全景速查表.md b/wiki/sources/obsidian-官方-cli-命令全景速查表.md index 4feeb9f3..ffc7bf16 100644 --- a/wiki/sources/obsidian-官方-cli-命令全景速查表.md +++ b/wiki/sources/obsidian-官方-cli-命令全景速查表.md @@ -6,7 +6,7 @@ date: 2026-04-28 --- ## Source File -- [[Skills/Obsidian 官方 CLI 命令全景速查表.md]] +- [[raw/Skills/Obsidian 官方 CLI 命令全景速查表.md]] ## Summary（用中文描述） - 核心主题：Obsidian v1.12+ 官方 CLI 命令完整参考，包含 80+ 条命令，涵盖所有功能模块 diff --git a/wiki/sources/obsidian-必装-skills.md b/wiki/sources/obsidian-必装-skills.md index b112d991..09ca4932 100644 --- a/wiki/sources/obsidian-必装-skills.md +++ b/wiki/sources/obsidian-必装-skills.md @@ -6,7 +6,7 @@ date: 2026-04-28 --- ## Source File -- [[Skills/Obsidian 必装 Skills]] +- [[raw/Skills/Obsidian 必装 Skills.md]] ## Summary（用中文描述） - 核心主题：Obsidian 生态中值得安装的 AI Agent Skills 全景盘点与配置指南 diff --git a/wiki/sources/scrapy-playwright-抓取tiktok-shop-data.md b/wiki/sources/scrapy-playwright-抓取tiktok-shop-data.md index 2661e9e0..1539c4bb 100644 --- a/wiki/sources/scrapy-playwright-抓取tiktok-shop-data.md +++ b/wiki/sources/scrapy-playwright-抓取tiktok-shop-data.md @@ -6,7 +6,7 @@ date: 2026-04-28 --- ## Source File -- [[raw/跨境电商/Scrapy + Playwright 抓取TikTok Shop Data.md]] +- [[Scrapy + Playwright 抓取TikTok Shop Data]] ## Summary（用中文描述） - 核心主题：使用 Scrapy + Playwright 抓取 TikTok Shop 店铺数据的技术配置与实践指南 diff --git a/wiki/sources/tiktok-shop-apache-superset-dashboard设计思路.md b/wiki/sources/tiktok-shop-apache-superset-dashboard设计思路.md index 02e5b568..e526042c 100644 --- a/wiki/sources/tiktok-shop-apache-superset-dashboard设计思路.md +++ b/wiki/sources/tiktok-shop-apache-superset-dashboard设计思路.md @@ -6,7 +6,7 @@ date: 2026-04-28 --- ## Source File -- [[跨境电商/TikTok Shop - Apache Superset Dashboard设计思路.md]] +- [[raw/跨境电商/TikTok Shop - Apache Superset Dashboard设计思路.md]] ## Summary（用中文描述） - 核心主题：使用 Apache Superset 构建 TikTok Shop 电商选品分析 Dashboard 的完整设计指南 diff --git a/wiki/sources/wsl2-启动与网络配置指南.md b/wiki/sources/wsl2-启动与网络配置指南.md index 6ed7307c..2b17532d 100644 --- a/wiki/sources/wsl2-启动与网络配置指南.md +++ b/wiki/sources/wsl2-启动与网络配置指南.md @@ -6,7 +6,7 @@ date: 2026-04-17 --- ## Source File -- [[Home Office/WSL2 启动与网络配置指南.md]] +- [[raw/Home Office/WSL2 启动与网络配置指南.md]] ## Summary（用中文描述） - 核心主题：WSL2（Windows Subsystem for Linux 2）日常使用操作与网络配置 diff --git a/wiki/sources/在-ubuntu-安装-ollama-并运行-qwen2-5‑coder-7b.md b/wiki/sources/在-ubuntu-安装-ollama-并运行-qwen2-5‑coder-7b.md index 4478c4fd..8c67b781 100644 --- a/wiki/sources/在-ubuntu-安装-ollama-并运行-qwen2-5‑coder-7b.md +++ b/wiki/sources/在-ubuntu-安装-ollama-并运行-qwen2-5‑coder-7b.md @@ -6,7 +6,7 @@ date: 2026-04-28 --- ## Source File -- [[AI/在 Ubuntu 安装 Ollama 并运行 Qwen2.5‑Coder 7B]] +- [[raw/AI/在 Ubuntu 安装 Ollama 并运行 Qwen2.5‑Coder 7B.md]] ## Summary（用中文描述） - 核心主题：在 Ubuntu 系统上通过 Ollama 本地部署 Qwen2.5-Coder 7B 代码大模型，并支持 REST API 和多语言 SDK 调用 diff --git a/wiki/sources/如何利用sora接口实现视频自动化生成工作流.md b/wiki/sources/如何利用sora接口实现视频自动化生成工作流.md index eca0c113..b369c26f 100644 --- a/wiki/sources/如何利用sora接口实现视频自动化生成工作流.md +++ b/wiki/sources/如何利用sora接口实现视频自动化生成工作流.md @@ -6,7 +6,7 @@ date: 2026-04-27 --- ## Source File -- [[AI/如何利用Sora接口实现视频自动化生成工作流.md]] +- [[raw/AI/如何利用Sora接口实现视频自动化生成工作流.md]] ## Summary（用中文描述） - 核心主题：使用 Sora API 接口实现视频生成的完全自动化工作流 diff --git a/wiki/sources/实战笔记-本地部署-rsshub-并获取-youtube-订阅.md b/wiki/sources/实战笔记-本地部署-rsshub-并获取-youtube-订阅.md index f31b81d3..cf839c04 100644 --- a/wiki/sources/实战笔记-本地部署-rsshub-并获取-youtube-订阅.md +++ b/wiki/sources/实战笔记-本地部署-rsshub-并获取-youtube-订阅.md @@ -6,7 +6,7 @@ date: 2026-04-23 --- ## Source File -- [[Home Office/实战笔记：本地部署 RSSHub 并获取 YouTube 订阅]] +- [[raw/Home Office/实战笔记：本地部署 RSSHub 并获取 YouTube 订阅.md]] ## Summary（用中文描述） - 核心主题：通过本地部署 RSSHub 解决 YouTube 频道订阅跟踪问题 diff --git a/wiki/sources/我做了个-skill-让-ai-帮你生成-logo-和图标.md b/wiki/sources/我做了个-skill-让-ai-帮你生成-logo-和图标.md index 242a1a05..3dfad501 100644 --- a/wiki/sources/我做了个-skill-让-ai-帮你生成-logo-和图标.md +++ b/wiki/sources/我做了个-skill-让-ai-帮你生成-logo-和图标.md @@ -7,7 +7,7 @@ last_updated: 2026-04-28 --- ## Source File -- [[Skills/我做了个 Skill：让 AI 帮你生成 Logo 和图标]] +- [[raw/Skills/我做了个 Skill：让 AI 帮你生成 Logo 和图标.md]] ## Summary（用中文描述） - 核心主题：开源 Logo Generator Skill——用 AI 生成 SVG Logo + 高级展示图的完整工作流 diff --git a/wiki/sources/我用-gemini-3-一口气做了-10-个应用-附教程.md b/wiki/sources/我用-gemini-3-一口气做了-10-个应用-附教程.md index 450e3b31..5785ff93 100644 --- a/wiki/sources/我用-gemini-3-一口气做了-10-个应用-附教程.md +++ b/wiki/sources/我用-gemini-3-一口气做了-10-个应用-附教程.md @@ -6,7 +6,7 @@ date: 2025-11-24 --- ## Source File -- [[AI/我用 Gemini 3 一口气做了 10 个应用，附教程.md]] +- [[raw/AI/我用 Gemini 3 一口气做了 10 个应用，附教程.md]] ## Summary（用中文描述） - 核心主题：作者分享如何利用 Gemini 3（大模型）+ 前端 SVG/HTML 可视化，在极短时间内快速构建 10 个实际可用的 AI 应用，并总结了一套通用的 AI 应用开发方法论。 diff --git a/wiki/sources/电商视频prompt.md b/wiki/sources/电商视频prompt.md index 57d8d5ba..dffae3a5 100644 --- a/wiki/sources/电商视频prompt.md +++ b/wiki/sources/电商视频prompt.md @@ -6,7 +6,7 @@ date: 2026-04-28 --- ## Source File -- [[跨境电商/电商视频Prompt.md]] +- [[raw/跨境电商/电商视频Prompt.md]] ## Summary（用中文描述） - 核心主题：AI 图生视频（Image-to-Video）Prompt 模块化库，专为 TikTok 电商宠物用品带货场景设计 diff --git a/wiki/sources/超达物流定价.md b/wiki/sources/超达物流定价.md index b9362e31..05689d8e 100644 --- a/wiki/sources/超达物流定价.md +++ b/wiki/sources/超达物流定价.md @@ -6,7 +6,7 @@ date: 2025-12-19 --- ## Source File -- [[跨境电商/超达物流定价]] +- [[raw/跨境电商/超达物流定价.md]] ## Summary（用中文描述） - 核心主题：超达物流服务渠道的定价规则与操作注意事项，聚焦 TikTok Shop 美国市场发货场景。