From 4e9ee6f51eb49f43f6f7a612468c58817666b32c Mon Sep 17 00:00:00 2001 From: weishen Date: Fri, 24 Apr 2026 00:03:01 +0800 Subject: [PATCH] Auto-sync: 2026-04-24 00:02 --- wiki/concepts/14种UML图.md | 41 ++ wiki/concepts/7种视觉风格系统.md | 58 +++ wiki/concepts/AWS-Tagging-Standards.md | 66 +++ wiki/concepts/AWS-Tags.md | 44 ++ wiki/concepts/CI-CD-Pipeline.md | 90 ++-- wiki/concepts/Columnar-Storage.md | 39 ++ wiki/concepts/DBA-Role-Evolution.md | 64 +++ wiki/concepts/Docker-Containerization.md | 50 +++ wiki/concepts/EFS-vs-EBS.md | 64 +++ wiki/concepts/Federated-Access.md | 39 ++ wiki/concepts/Landing-Zone-Architecture.md | 44 ++ wiki/concepts/MPP.md | 40 ++ wiki/concepts/Multi-Database-Architecture.md | 89 ++++ wiki/concepts/Purpose-Built-Databases.md | 70 ++++ wiki/concepts/RTO.md | 110 ++--- wiki/concepts/Reference-Architecture.md | 39 ++ .../concepts/Service-Control-Policies-SCPs.md | 98 +++++ wiki/concepts/SnapMirror.md | 43 ++ wiki/concepts/Tag-Validation-Tool.md | 71 ++++ wiki/concepts/Terraform-Modules.md | 62 +++ wiki/concepts/Variables-YAML.md | 103 +++++ wiki/concepts/技术图生成.md | 45 ++ wiki/concepts/语义形状词汇表.md | 38 ++ wiki/concepts/语义箭头系统.md | 28 ++ wiki/entities/Amazon-Aurora.md | 48 +++ wiki/entities/Amazon-DocumentDB.md | 42 ++ wiki/entities/Amazon-DynamoDB.md | 41 ++ wiki/entities/Amazon-ElastiCache.md | 50 +++ wiki/entities/Amazon-Keyspaces.md | 42 ++ wiki/entities/Amazon-Neptune.md | 34 ++ wiki/entities/Amazon-RDS.md | 54 +++ wiki/entities/Amazon-Redshift.md | 54 +++ wiki/entities/Amazon-Timestream.md | 41 ++ wiki/entities/Checkpoint.md | 57 +++ wiki/entities/Gruntwork.md | 30 ++ wiki/entities/Intsas.local.md | 23 + wiki/entities/NetApp.md | 48 +++ wiki/entities/Octane-Hub.md | 57 +++ wiki/entities/SMACKS.md | 22 + wiki/entities/SRE-Team.md | 39 ++ wiki/entities/Swinford.net.md | 23 + wiki/entities/fireworks-tech-graph.md | 35 ++ wiki/entities/rsvg-convert.md | 25 ++ wiki/index.md | 99 +++-- wiki/log.md | 395 ++++++++++++++++++ wiki/overview.md | 61 ++- wiki/sources/blogwatcher-daily收藏.md | 58 +++ ...c-1-gruntwork-landing-zone-architecture.md | 56 +++ ...ata-collection-tagging-related-security.md | 57 +++ ...experience-moving-production-services-i.md | 69 +++ ...directory-services-in-gruntwork-aws-lzs.md | 59 +++ ...5-labs-landing-zone-overview-itom-teams.md | 70 ++++ ...ndard-ami-build-publish-share-processes.md | 66 +++ .../ctp-topic-28-aws-tag-validation-tool.md | 52 +++ ...zure-landing-zone-architecture-overview.md | 56 +++ ...landing-zone-design-refresher-saas-labs.md | 52 +++ ...saas-database-architecture-on-aws-cloud.md | 61 +++ .../ctp-topic-44-aws-backup-in-micro-focus.md | 61 +++ wiki/sources/ctp-topic-46-netapps-on-aws.md | 67 +++ ...enterprise-architecture-cloud-standards.md | 46 ++ .../ctp-topic-50-ami-roadmap-for-aws-amis.md | 64 +++ ...ecting-with-aws-purpose-built-databases.md | 64 +++ .../ctp-topic-58-aws-ec2-image-builder.md | 57 +++ ...ences-between-postgresql-rds-and-aurora.md | 69 +++ .../ctp-topic-68-introduction-to-redshift.md | 63 +++ .../ctp-topic-7-saas-landing-zone-design.md | 63 +++ ...enterprise-dr-strategy-using-aws-backup.md | 75 ++++ ...ion-of-the-cloud-transformation-program.md | 56 +++ wiki/sources/fireworks-tech-graph.md | 49 +++ wiki/sources/install-wsl.md | 49 +++ ...tes-20231205-160324-meeting-recording-2.md | 53 +++ wiki/sources/mac必装软件清单-2026-04-17.md | 47 +++ wiki/sources/wsl2-启动与网络配置指南.md | 42 ++ ...笔记-本地部署-rsshub-并获取-youtube-订阅.md | 51 +++ 74 files changed, 4235 insertions(+), 152 deletions(-) create mode 100644 wiki/concepts/14种UML图.md create mode 100644 wiki/concepts/7种视觉风格系统.md create mode 100644 wiki/concepts/AWS-Tagging-Standards.md create mode 100644 wiki/concepts/AWS-Tags.md create mode 100644 wiki/concepts/Columnar-Storage.md create mode 100644 wiki/concepts/DBA-Role-Evolution.md create mode 100644 wiki/concepts/Docker-Containerization.md create mode 100644 wiki/concepts/EFS-vs-EBS.md create mode 100644 wiki/concepts/Federated-Access.md create mode 100644 wiki/concepts/Landing-Zone-Architecture.md create mode 100644 wiki/concepts/MPP.md create mode 100644 wiki/concepts/Multi-Database-Architecture.md create mode 100644 wiki/concepts/Purpose-Built-Databases.md create mode 100644 wiki/concepts/Reference-Architecture.md create mode 100644 wiki/concepts/Service-Control-Policies-SCPs.md create mode 100644 wiki/concepts/SnapMirror.md create mode 100644 wiki/concepts/Tag-Validation-Tool.md create mode 100644 wiki/concepts/Terraform-Modules.md create mode 100644 wiki/concepts/Variables-YAML.md create mode 100644 wiki/concepts/技术图生成.md create mode 100644 wiki/concepts/语义形状词汇表.md create mode 100644 wiki/concepts/语义箭头系统.md create mode 100644 wiki/entities/Amazon-Aurora.md create mode 100644 wiki/entities/Amazon-DocumentDB.md create mode 100644 wiki/entities/Amazon-DynamoDB.md create mode 100644 wiki/entities/Amazon-ElastiCache.md create mode 100644 wiki/entities/Amazon-Keyspaces.md create mode 100644 wiki/entities/Amazon-Neptune.md create mode 100644 wiki/entities/Amazon-RDS.md create mode 100644 wiki/entities/Amazon-Redshift.md create mode 100644 wiki/entities/Amazon-Timestream.md create mode 100644 wiki/entities/Checkpoint.md create mode 100644 wiki/entities/Gruntwork.md create mode 100644 wiki/entities/Intsas.local.md create mode 100644 wiki/entities/NetApp.md create mode 100644 wiki/entities/Octane-Hub.md create mode 100644 wiki/entities/SMACKS.md create mode 100644 wiki/entities/SRE-Team.md create mode 100644 wiki/entities/Swinford.net.md create mode 100644 wiki/entities/fireworks-tech-graph.md create mode 100644 wiki/entities/rsvg-convert.md create mode 100644 wiki/sources/blogwatcher-daily收藏.md create mode 100644 wiki/sources/ctp-topic-1-gruntwork-landing-zone-architecture.md create mode 100644 wiki/sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md create mode 100644 wiki/sources/ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i.md create mode 100644 wiki/sources/ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs.md create mode 100644 wiki/sources/ctp-topic-25-labs-landing-zone-overview-itom-teams.md create mode 100644 wiki/sources/ctp-topic-26-standard-ami-build-publish-share-processes.md create mode 100644 wiki/sources/ctp-topic-28-aws-tag-validation-tool.md create mode 100644 wiki/sources/ctp-topic-34-azure-landing-zone-architecture-overview.md create mode 100644 wiki/sources/ctp-topic-35-aws-landing-zone-design-refresher-saas-labs.md create mode 100644 wiki/sources/ctp-topic-40-saas-database-architecture-on-aws-cloud.md create mode 100644 wiki/sources/ctp-topic-44-aws-backup-in-micro-focus.md create mode 100644 wiki/sources/ctp-topic-46-netapps-on-aws.md create mode 100644 wiki/sources/ctp-topic-47-enterprise-architecture-cloud-standards.md create mode 100644 wiki/sources/ctp-topic-50-ami-roadmap-for-aws-amis.md create mode 100644 wiki/sources/ctp-topic-51-architecting-with-aws-purpose-built-databases.md create mode 100644 wiki/sources/ctp-topic-58-aws-ec2-image-builder.md create mode 100644 wiki/sources/ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora.md create mode 100644 wiki/sources/ctp-topic-68-introduction-to-redshift.md create mode 100644 wiki/sources/ctp-topic-7-saas-landing-zone-design.md create mode 100644 wiki/sources/ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup.md create mode 100644 wiki/sources/ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program.md create mode 100644 wiki/sources/fireworks-tech-graph.md create mode 100644 wiki/sources/install-wsl.md create mode 100644 wiki/sources/learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2.md create mode 100644 wiki/sources/mac必装软件清单-2026-04-17.md create mode 100644 wiki/sources/wsl2-启动与网络配置指南.md create mode 100644 wiki/sources/实战笔记-本地部署-rsshub-并获取-youtube-订阅.md diff --git a/wiki/concepts/14种UML图.md b/wiki/concepts/14种UML图.md new file mode 100644 index 00000000..8bf8fe31 --- /dev/null +++ b/wiki/concepts/14种UML图.md @@ -0,0 +1,41 @@ +--- +title: "14种UML图" +type: concept +tags: [] +sources: [fireworks-tech-graph] +last_updated: 2026-04-18 +--- + +## Description +fireworks-tech-graph 完整支持的 14 种 UML（统一建模语言）图类型，涵盖结构图、行为图和交互图三大类。 + +## 完整图类型列表 + +| UML 类型 | 描述 | 推荐风格 | +|---------|------|---------| +| **类图** | 类、属性、方法、关系 | 风格 1, 4 | +| **组件图** | 软件组件和依赖关系 | 风格 1, 3 | +| **部署图** | 硬件节点和软件部署 | 风格 3 | +| **包图** | 包组织和依赖关系 | 风格 1, 4 | +| **复合结构图** | 类/组件的内部结构 | 风格 1, 3 | +| **对象图** | 对象实例和关系 | 风格 1, 4 | +| **用例图** | 参与者、用例、系统边界 | 风格 1 | +| **活动图** | 工作流、并行流程 | 风格 3 | +| **状态机图** | 状态转换和事件 | 风格 2, 3 | +| **序列图** | 时间顺序的消息交换 | 风格 2 | +| **通信图** | 对象交互和消息 | 风格 1, 2 | +| **时序图** | 状态随时间的变化 | 风格 2 | +| **交互概览图** | 高层交互流程 | 风格 1, 2 | +| **ER 图** | 实体关系数据模型 | 风格 1, 3 | + +## 分类 + +**结构图（7种）：** 类图、组件图、部署图、包图、复合结构图、对象图、用例图 + +**行为图（2种）：** 活动图、状态机图 + +**交互图（5种）：** 序列图、通信图、时序图、交互概览图 + +## Relationships +- [[14种UML图]] is supported_by [[fireworks-tech-graph]] +- [[14种UML图]] is used_by [[7种视觉风格系统]] diff --git a/wiki/concepts/7种视觉风格系统.md b/wiki/concepts/7种视觉风格系统.md new file mode 100644 index 00000000..33bde34a --- /dev/null +++ b/wiki/concepts/7种视觉风格系统.md @@ -0,0 +1,58 @@ +--- +title: "7种视觉风格系统" +type: concept +tags: [] +sources: [fireworks-tech-graph] +last_updated: 2026-04-18 +--- + +## Description +fireworks-tech-graph 内置的 7 种视觉风格系统，每种风格定义了背景色、字体、颜色 Token、布局规范和使用场景推荐。 + +## The 7 Styles + +| # | 名称 | 背景色 | 字体 | 适用场景 | +|---|------|--------|------|---------| +| 1 | **扁平图标风**（默认） | `#ffffff` | Helvetica | 博客、幻灯片、技术文档 | +| 2 | **暗黑极客风** | `#0f0f1a` | SF Mono / Fira Code | GitHub README、开发者文章 | +| 3 | **工程蓝图风** | `#0a1628` | Courier New | 架构设计文档、工程规范 | +| 4 | **Notion 极简风** | `#ffffff` | system-ui | Notion、Confluence、内部 Wiki | +| 5 | **玻璃态卡片风** | `#0d1117` 渐变 | Inter | 产品官网、演讲 Keynote | +| 6 | **Claude 官方风格** | `#f8f6f3` | system-ui | Anthropic 风格图表，温暖专业美学 | +| 7 | **OpenAI 官方风格** | `#ffffff` | system-ui | OpenAI 风格图表，简洁现代设计 | + +## 风格选择指南 + +**UML 图类型：** +- 类图/组件图/包图：风格 1（扁平图标风）或风格 4（Notion极简风） +- 序列图/时序图：风格 2（暗黑极客风） +- 状态机图/活动图：风格 3（工程蓝图风） +- 用例图/交互图：风格 1（扁平图标风） + +**AI/Agent 图类型：** +- RAG/Agentic Search：风格 2（暗黑极客风）或风格 5（玻璃态卡片风） +- 记忆架构：风格 3（工程蓝图风） +- Multi-Agent：风格 5（玻璃态卡片风） + +**文档类型：** +- 内部文档：风格 4（Notion极简风） +- 技术博客：风格 1（扁平图标风） +- GitHub README：风格 2（暗黑极客风） +- 演示文稿：风格 5（玻璃态卡片风）或风格 6（Claude官方风格） + +**品牌特定：** +- Anthropic/Claude 项目：风格 6（Claude官方风格） +- OpenAI 项目：风格 7（OpenAI官方风格） + +## Key Enhancements +- `style_overrides`：微调标题对齐或配色 token +- `containers[].header_prefix` / `containers[].header_text`：工程编号分区标题（风格3） +- `containers[].side_label`：左侧 Layer Label（风格6） +- `window_controls` / `meta_*`：终端/文档风格顶部 chrome +- `blueprint_title_block`：蓝图标题信息框（风格3） + +## Relationships +- [[7种视觉风格系统]] is implemented_by [[fireworks-tech-graph]] +- [[7种视觉风格系统]] is used_for [[14种UML图]] +- [[7种视觉风格系统]] is used_for [[RAG]] +- [[7种视觉风格系统]] is used_for [[AI Agent]] diff --git a/wiki/concepts/AWS-Tagging-Standards.md b/wiki/concepts/AWS-Tagging-Standards.md new file mode 100644 index 00000000..d2060fe7 --- /dev/null +++ b/wiki/concepts/AWS-Tagging-Standards.md @@ -0,0 +1,66 @@ +--- +title: "AWS Tagging Standards" +type: concept +tags: [AWS, Tagging, Governance, Compliance, Policy] +last_updated: 2026-04-14 +--- + +## Definition + +AWS Tagging Standards（AWS 标签规范）是企业级 AWS Landing Zone 治理框架的核心组成部分，定义了 AWS 资源上必须使用的标准标签键（Mandatory Tags）、命名约定（Naming Conventions）和允许值列表（Allowed Values）。标签规范是企业云治理的第一道防线，直接影响网络安全策略、成本分配和资源管理效率。 + +## Aliases +- Tagging Policy +- Tag Standard +- AWS Tagging Policy +- Tag Governance + +## Core Components + +### 1. Mandatory Tags（强制标签） +组织定义的必须存在于所有 AWS 资源上的标签键，例如： +- `Environment`: `dev | staging | prod` +- `CostCenter`: 成本中心代码 +- `Owner`: 资源负责人 +- `Application`: 应用名称 +- `Project`: 项目名称 + +### 2. Naming Conventions（命名约定） +资源命名的标准化规则，例如： +- `prod-web-server-001` +- `dev-db-postgres-01` + +### 3. Allowed Values（允许值列表） +每个标签键对应的允许值集合，例如： +```yaml +Environment: + - dev + - staging + - prod + - uat +CostCenter: + - CC-001 + - CC-002 +``` + +## Context in This Wiki + +在该组织的 AWS Landing Zone 环境中，标签规范具有双重关键性： + +1. **Checkpoint 防火墙安全策略**：Checkpoint 防火墙读取 EC2、安全组和负载均衡器的标签值来配置网络访问策略，标签缺失或无效将直接导致流量被拦截。 +2. **服务控制策略（SCPs）**：AWS Organizations 的 SCPs 基于标签规范阻止不合规资源的新建，但仅能阻止新资源，无法处理存量不合规资源。 +3. **标签验证工具（Tag Validation Tool）**：SRE 团队开发的 Python/Boto3 工具，通过 `variables.yaml` 配置文件扫描所有现有资源并与规范比对，生成 CSV 审计报告。 +4. **未来成本核算**：标签计划用于区分同一账户下不同产品的资源消耗，支持 FinOps 成本分摊。 + +## Related Concepts + +- [[AWS-Tags]]：AWS 资源标签的基础定义 +- [[Tag-Validation-Tool]]：基于标签规范的自动化审计工具 +- [[Service-Control-Policies-SCPs]]：基于标签规范的上游强制机制 +- [[Variables-YAML]]：标签验证工具的核心配置文件 +- [[FinOps]]：利用标签实现成本分摊 + +## Sources + +- [[ctp-topic-28-aws-tag-validation-tool]] +- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] diff --git a/wiki/concepts/AWS-Tags.md b/wiki/concepts/AWS-Tags.md new file mode 100644 index 00000000..57e8ffce --- /dev/null +++ b/wiki/concepts/AWS-Tags.md @@ -0,0 +1,44 @@ +--- +title: "AWS Tags" +type: concept +tags: [AWS, Tagging, Metadata, Cloud-Governance] +last_updated: 2026-04-14 +--- + +## Definition + +AWS Tags（AWS 资源标签）是附加在 AWS 资源上的键值对（Key-Value Pair）元数据，用于识别、分类和管理云资源。在企业 AWS Landing Zone 环境中，标签不仅是资源管理的工具，更是安全策略（Checkpoint 防火墙网络访问控制）和成本核算的基础。 + +## Aliases +- Resource Tags +- AWS Resource Tags +- 标签策略（Tagging Policy） + +## Core Attributes + +| 属性 | 说明 | +|------|------| +| 格式 | `Key: Value`（键值对） | +| 作用对象 | EC2, Security Groups, Load Balancers, Lambda, RDS 等 | +| 常见标签键 | `Name`, `Environment`, `CostCenter`, `Owner`, `Application`, `Project` | +| 适用层面 | 网络安全、成本核算、资源分组、访问控制 | + +## Context in This Wiki + +AWS Tags 在该组织中扮演双重关键角色： + +1. **网络安全**：Checkpoint 防火墙通过读取 EC2、安全组和负载均衡器的标签值动态配置网络访问策略；标签缺失或无效时，防火墙将拦截相关流量。 +2. **成本核算**：标签用于按产品/部门/环境区分同一账户下不同资源的成本消耗。 + +## Related Concepts + +- [[AWS-Tagging-Standards]]：AWS 标签规范，包括强制标签键、命名约定 +- [[Tag-Validation-Tool]]：用于审计 AWS 资源标签合规性的自动化工具 +- [[Service-Control-Policies-SCPs]]：AWS Organizations 策略，用于强制执行标签规范 +- [[FinOps]]：云财务管理，标签是成本分摊的基础 +- [[Checkpoint-Firewall]]：依赖标签值配置网络策略 + +## Sources + +- [[ctp-topic-28-aws-tag-validation-tool]] +- [[ctp-topic-10-aws-tagging-deep-dive]] diff --git a/wiki/concepts/CI-CD-Pipeline.md b/wiki/concepts/CI-CD-Pipeline.md index d331af76..f93fca86 100644 --- a/wiki/concepts/CI-CD-Pipeline.md +++ b/wiki/concepts/CI-CD-Pipeline.md @@ -1,61 +1,51 @@ -# CI/CD Pipeline +--- +title: "CI/CD Pipeline" +type: concept +sources: [ctp-topic-1-gruntwork-landing-zone-architecture, ctp-topic-9-ci-cd-with-gruntwork] +last_updated: 2026-04-14 +--- ## Definition -CI/CD (Continuous Integration/Continuous Delivery/Deployment) pipelines automate the process of building, testing, and deploying software changes. +CI/CD 流水线（CI/CD Pipeline）是持续集成（Continuous Integration）和持续交付/部署（Continuous Delivery/Deployment）的自动化流程，用于管理基础设施代码（IaC）的构建、测试和部署。在 Gruntwork Landing Zone 架构中，每个 Landing Zone 配置独立的 Jenkins 服务器和 CI/CD 流水线来自动化 Terraform 基础设施变更。 -## Components +## Core Components -### Continuous Integration (CI) -- Automated builds on code commits -- Automated testing (unit, integration, e2e) -- Code quality checks and linting -- Artifact generation +### CI（持续集成） +- **代码提交**：开发人员将特性分支代码推送到 GitHub 仓库 +- **自动构建**：Jenkins 触发 Terraform 初始化和格式化验证 +- **自动测试**：TerraTest 执行基础设施单元测试和集成测试 +- **代码审查**：Pull Request 必须通过审查才能合并到主分支 -### Continuous Delivery (CD) -- Automated deployment to staging environments -- Manual approval gates for production -- Configuration management +### CD（持续交付/部署） +- **自动部署**：合并到主分支后，Jenkins 自动执行 Terraform Plan +- **审批流程**：变更需要人工审批后才执行 Apply +- **渐进式部署**：支持 Blue-Green 部署和 Canary Release 策略 -### Continuous Deployment -- Fully automated deployment to production -- Feature flags for gradual rollout -- Automated rollback capabilities +### Infrastructure-Specific Considerations +- **状态管理**：Terraform State 的锁定和远程存储（使用 S3 + DynamoDB） +- **幂等性**：Terraform 模块设计必须支持重复执行而不产生副作用 +- **回滚机制**：通过 Terraform State 历史版本实现快速回滚 +- **漂移检测**：定期运行 `terraform plan` 检测配置漂移 -## Tools -- **CI/CD Platforms**: Jenkins, GitLab CI, GitHub Actions, CircleCI, ArgoCD -- **Build Tools**: Maven, Gradle, npm, Docker -- **Testing**: JUnit, PyTest, Selenium, Playwright +## Tools in Gruntwork Landing Zone Context +- **Jenkins**：核心 CI/CD 引擎，每个 Landing Zone 独立部署 +- **Terraform**：IaC 工具，定义和管理 AWS 资源 +- **TerraTest**：Go 语言编写的基础设施测试框架 +- **GitHub**：代码仓库，支持特性分支和 Pull Request 工作流 -## Best Practices -1. Keep the pipeline fast (under 10 minutes) -2. Fail fast — run fastest tests first -3. Use meaningful commit messages and branch names -4. Implement proper caching strategies -5. Store build artifacts securely -6. Enable parallel test execution - -## CI/CD Pipeline Across DevOps Maturity Levels - -| Maturity | Pipeline Maturity | -|----------|------------------| -| Phase 1 | No CI/CD — manual builds, manual testing, milestone-based releases | -| Phase 2 | Basic version control, some automation for risk reduction, unit/integration/E2E tests | -| Phase 3 | Automated infrastructure provisioning, security scans in CI, more frequent deployments | -| Phase 4 | Continuous integration pipeline, immutable infrastructure managed through pipelines, performance testing | -| Phase 5 | Zero human intervention, real-time data-driven decisions, multiple daily deployments | - -## Sources -- [[sources/cloud-devop-maturity-guideline.md]] -- [[sources/devops-maturity-model-from-traditional-it-to-advanced-devops.md]] +## Git Workflow +- 特性分支开发：`feature/` +- 通过 Pull Request 合并到主分支 +- 必须经过代码审查和 CI 测试 +- 合并后触发自动部署流水线 ## Related Concepts -- [[concepts/DevOps-Maturity]] -- [[concepts/Infrastructure-as-Code]] -- [[concepts/DevSecOps]] -- [[concepts/Continuous-Integration]] -- [[concepts/Continuous-Deployment]] -- [[concepts/Change-Failure-Rate]] +- [[Landing-Zone-Architecture]]：CI/CD 流水线是 Landing Zone 自动化运维的核心机制 +- [[Terraform-Modules]]：被 CI/CD 流水线自动化部署的 IaC 模块 +- [[GitOps]]：基于 Git 的运维方式，CI/CD 是其技术实现 +- [[TerraTest]]：用于基础设施变更的自动化测试工具 -## Ingested -- Date: 2026-04-21 -- Date: 2026-04-24 (updated with maturity level progression) +## References +- [[ctp-topic-1-gruntwork-landing-zone-architecture]] +- [[ctp-topic-9-ci-cd-with-gruntwork]] +- [[ctp-topic-2-git]] diff --git a/wiki/concepts/Columnar-Storage.md b/wiki/concepts/Columnar-Storage.md new file mode 100644 index 00000000..e89422a7 --- /dev/null +++ b/wiki/concepts/Columnar-Storage.md @@ -0,0 +1,39 @@ +--- +title: "Columnar Storage" +type: concept +tags: + - Data-Warehouse + - Storage + - Performance +sources: + - ctp-topic-68-introduction-to-redshift +last_updated: 2026-04-23 +--- + +## Overview +列式存储（Columnar Storage）是一种数据存储格式，数据按列而非按行组织。专为分析型工作负载（OLAP）设计，相比传统行式存储能显著提升聚合查询和全表扫描性能，同时降低存储空间需求。 + +## How It Works +行式存储按行存储：`[row1_col1, row1_col2, row1_col3, row2_col1, row2_col2, row2_col3, ...]` +列式存储按列存储：`[col1_row1, col1_row2, ..., col2_row1, col2_row2, ..., col3_row1, col3_row2, ...]` + +## Key Advantages +- **查询性能**：只需读取查询涉及的列，避免全行读取 I/O 开销 +- **压缩效率**：同一列数据类型一致，压缩比更高（如 Dictionary Encoding、Run-Length Encoding） +- **向量化执行**：列式数据可直接进行 SIMD 向量化计算，CPU 利用率更高 +- **聚合查询友好**：COUNT/SUM/AVG 等聚合仅需读取相关列 + +## Trade-offs +- **点查询效率低**：单行更新/插入需读写整列数据 +- **写入放大**：行更新涉及多列修改 +- **适用场景受限**：适合读密集型分析，不适合频繁更新的事务处理 + +## Applications +- **数据仓库**：Amazon Redshift、Google BigQuery、Snowflake、ClickHouse +- **列式文件系统**：Apache Parquet、Apache ORC +- **分析型数据库**：Apache Druid、Apache Kylin + +## Related Concepts +- [[MPP]]：列式存储常与 MPP 架构结合，实现大规模并行分析 +- [[Sort-Key]]：在列式存储中排序键可进一步优化范围查询性能 +- [[Data Compression]]：列式存储天然适合高压缩比 diff --git a/wiki/concepts/DBA-Role-Evolution.md b/wiki/concepts/DBA-Role-Evolution.md new file mode 100644 index 00000000..bcaa221d --- /dev/null +++ b/wiki/concepts/DBA-Role-Evolution.md @@ -0,0 +1,64 @@ +--- +title: "DBA Role Evolution" +type: concept +tags: + - AWS + - Cloud + - Database + - Career +sources: + - ctp-topic-51-architecting-with-aws-purpose-built-databases +last_updated: 2026-04-23 +--- + +## Definition +云时代 DBA 角色演变（Cloud DBA Evolution）是指数据库管理员（Database Administrator）的职能从传统的底层平台管理（备份、补丁、容量规划）向现代的应用层创新（架构设计、查询优化、性能调优）转变的过程。 + +## Traditional DBA Responsibilities (On-Premises) +传统 DBA 的核心职责： +- **平台管理**：数据库安装、配置、补丁升级 +- **备份恢复**：执行备份、验证恢复、灾难演练 +- **容量规划**：存储计算资源规划、采购 +- **性能监控**：数据库指标监控、瓶颈诊断 +- **安全合规**：用户权限管理、合规审计 + +## Cloud-Native DBA Responsibilities (AWS) +云时代 AWS 环境下的 DBA 职能转变： + +| 传统职责 | 云时代处理方式 | DBA 新焦点 | +|---------|--------------|-----------| +| 备份恢复 | AWS 自动备份（ RDS/Aurora 内置） | 制定备份策略、验证 RTO/RPO | +| 补丁升级 | AWS 自动打补丁（Managed Service） | 评估补丁影响、安排维护窗口 | +| 容量规划 | 按需扩展（Auto Scaling / Serverless） | 成本优化、右规格选型 | +| 故障恢复 | Multi-AZ 自动故障转移 | 架构设计、演练自动化 | +| 硬件维护 | AWS 负责 | 更高层次的架构决策 | + +## New DBA Focus Areas +云时代 DBA 应聚焦的领域： + +1. **数据库架构设计**：专用数据库选型（[[Purpose-Built-Databases]]）、多数据库混合架构 +2. **查询优化**：慢查询分析、索引策略、执行计划优化 +3. **性能调优**：Aurora Serverless、DynamoDB On-Demand 的合理使用 +4. **安全加固**：VPC 安全组、加密（KMS）、IAM 权限最小化 +5. **成本优化**：Reserved Instances、Savings Plans、冷热数据分层 +6. **应用集成**：连接池配置（ RDS Proxy）、读写分离、缓存策略 +7. **数据治理**：Schema 设计规范、数据生命周期管理 + +## Key Quote +> "The role of the DBA is evolving in the cloud." — Femi George, AWS Database Sales Specialist + +AWS 负责底层平台管理，DBA 的价值转移到**应用创新**而非平台维护。 + +## Aliases +- Cloud DBA +- 云时代 DBA +- DBA 职能转变 +- Database Administrator Evolution +- Database Reliability Engineer + +## Related Concepts +- [[Purpose-Built-Databases]]：云时代 DBA 需要掌握多种专用数据库的选型能力 +- [[Multi-Database-Architecture]]：DBA 负责设计多数据库混合架构 +- [[RTO]]：云时代 DBA 关注的关键灾备指标 +- [[Amazon-RDS]]：托管关系型数据库，DBA 从平台管理转向应用优化 +- [[Amazon-Aurora]]：云原生数据库，存储计算分离架构 diff --git a/wiki/concepts/Docker-Containerization.md b/wiki/concepts/Docker-Containerization.md new file mode 100644 index 00000000..ed182d09 --- /dev/null +++ b/wiki/concepts/Docker-Containerization.md @@ -0,0 +1,50 @@ +--- +title: "Docker Containerization" +type: concept +tags: [docker, cloud-migration, devops, aws] +last_updated: 2026-04-23 +--- + +## Definition +Docker 容器化是一种操作系统级虚拟化技术，将应用程序及其所有依赖项打包为轻量级、可移植的容器，确保应用程序在任何环境中一致运行。 + +## Key Features +- **轻量级**：共享主机操作系统内核，无需完整虚拟机开销 +- **可移植性**：容器在任何支持 Docker 的环境中一致运行 +- **隔离性**：每个容器独立运行，拥有自己的文件系统、网络和进程空间 +- **版本控制**：容器镜像支持版本化，便于回滚和审计 +- **可组合性**：通过 Docker Compose 定义多容器应用 + +## Cloud Migration Context +在 [[Octane-Hub]] 的 AWS 迁移案例中，Docker 容器化是关键基础设施： + +| 组件 | 原环境 | 目标环境 | +|------|--------|----------| +| QuickSee | 物理服务器 | AWS Docker | +| Release Manager | 物理服务器 | AWS Docker | +| Patch Manager | 物理服务器 | AWS Docker | +| 安全程序板 | 物理服务器 | AWS Docker | + +### Octane Hub 迁移经验 +- Docker 是主要部署模式，运行在 AWS Landing Zone 账户中 +- 后台作业（支持集成、数据复制、内部空闲搜索）同样容器化 +- 迁移策略："紧密镜像现有设置"，保持应用架构不变 + +### 未来演进 +- 当前：Docker 容器运行在 EC2 实例上 +- 目标：迁移到 AWS ECS（Elastic Container Service）以获得更好的编排能力 + +## Key Concepts +- **镜像 (Image)**：应用程序及其依赖项的可读模板 +- **容器 (Container)**：镜像的运行实例 +- **Dockerfile**：定义镜像构建步骤的脚本 +- **Docker Compose**：定义和运行多容器应用的工具 +- **Volume**：容器持久化数据存储 + +## Related Concepts +- [[Packer]]：用于构建 Docker AMI 镜像 +- [[Terraform]]：用于在 AWS 上部署容器基础设施 +- [[AWS-Landing-Zone]]：企业级多账户 AWS 环境 + +## References +- [[ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i]] diff --git a/wiki/concepts/EFS-vs-EBS.md b/wiki/concepts/EFS-vs-EBS.md new file mode 100644 index 00000000..e338d6a4 --- /dev/null +++ b/wiki/concepts/EFS-vs-EBS.md @@ -0,0 +1,64 @@ +--- +title: "EFS vs EBS" +type: concept +tags: [aws, storage, cloud-migration, devops] +last_updated: 2026-04-23 +--- + +## Definition +AWS 提供多种存储解决方案，其中 EFS（Elastic File System）和 EBS（Elastic Block Store）是两种核心存储类型，适用于不同场景。 + +## Comparison Table + +| 特性 | EBS | EFS | +|------|-----|-----| +| **类型** | 块存储（类似虚拟硬盘） | 文件存储（类似网络文件系统 NFS）| +| **访问方式** | 单个 EC2 实例 | 多个 EC2 实例同时访问 | +| **性能** | 高性能、低延迟 | 中等性能，适合共享访问 | +| **价格** | 按存储量和 Provisioned IOPS 计费 | 按实际使用量计费 | +| **持久性** | 独立于 EC2 生命周期 | 可用区冗余存储 | +| **适用场景** | 数据库、日志、系统盘 | 共享文件存储、备份、内容管理 | + +## Cloud Migration Context + +### [[Octane-Hub]] 的存储选型经验 + +#### 问题发现 +- 最初考虑使用 EFS 用于存储 +- 发现性能问题：**数据库无法直接在 EFS 上运行** +- EFS 的延迟和吞吐量不适合高 IOPS 需求的工作负载 + +#### 最终方案 +| 数据类型 | 存储选型 | 原因 | +|----------|----------|------| +| MSSQL 数据库（实时）| EBS | 需要高 IOPS、低延迟 | +| 数据库备份 | EFS | 适合大容量、低频访问 | +| 未来规划 | S3 | 成本优化目标 | + +### 存储选型原则 +1. **高 IOPS 需求**（数据库）→ EBS +2. **共享文件访问**（多实例）→ EFS +3. **成本优化/归档** → S3 +4. **混合策略**：热数据用 EBS/EFS，冷数据用 S3 + +## Key Differences + +### EBS 特点 +- 作为 EC2 实例的独立卷挂载 +- 可单独创建快照进行备份 +- 支持 `io1`/`io2` 类型提供高 IOPS +- 适合：操作系统、数据库、应用数据 + +### EFS 特点 +- 通过 NFS 协议访问 +- 支持多可用区部署 +- 自动扩展，按使用量计费 +- 适合：Web 服务器共享存储、代码仓库、备份文件 + +## Related Concepts +- [[AWS-Landing-Zone]]：企业级 AWS 环境架构 +- [[Octane-Hub]]：Docker 容器化工作负载迁移案例 +- [[Cloud-Migration]]：云迁移最佳实践 + +## References +- [[ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i]] diff --git a/wiki/concepts/Federated-Access.md b/wiki/concepts/Federated-Access.md new file mode 100644 index 00000000..041d0c00 --- /dev/null +++ b/wiki/concepts/Federated-Access.md @@ -0,0 +1,39 @@ +--- +--- +title: "Federated Access" +type: concept +sources: [ctp-topic-1-gruntwork-landing-zone-architecture, ctp-topic-11-ad-integration-and-login-using-ad-accounts] +last_updated: 2026-04-14 +--- + +## Definition +联邦访问（Federated Access）是一种基于身份联合（Identity Federation）的 AWS 身份管理机制。用户通过企业现有身份提供者（如 Active Directory）进行身份验证，由 AD 组自动映射到对应的 IAM 角色，从而获得云平台资源的访问权限，无需在 AWS 中单独创建和管理 IAM 用户。 + +## Key Benefits +- **集中身份管理**：使用企业现有 AD，无需在 AWS 中单独管理用户账号 +- **自动化权限分配**：AD 组 → IAM 角色的映射自动化，人员变动即时生效 +- **安全审计**：所有访问通过 AD 域控制器统一记录和审计 +- **消除凭证共享**：避免 IAM Access Key 的分发和管理风险 + +## Architecture +- **Identity Provider (IdP)**：企业 Active Directory +- **AWS IAM Identity Provider**：在 AWS 中配置 SAML 2.0 联合身份 +- **IAM Roles**：定义具体权限策略，信任策略允许 IdP 中的特定 AD 组 +- **AD Groups**：在 AD 中维护的组，按职能或项目划分 + +## Workflow +1. 用户在企业网络登录 AD 账户 +2. 通过 AWS SSO 或 SAML 联合发起 AWS 控制台或 CLI 访问请求 +3. AWS 使用 AD 凭证验证用户身份 +4. 根据用户所属 AD 组，分配对应 IAM 角色的临时凭证 +5. 凭证自动过期，强制定期重新认证 + +## Related Concepts +- [[Landing-Zone-Architecture]]：联邦访问是 Landing Zone 安全账户的核心身份管理机制 +- [[IAM]]：AWS 身份和访问管理的底层服务 +- [[Active-Directory]]：企业侧的联合身份提供者 + +## References +- [[ctp-topic-1-gruntwork-landing-zone-architecture]] +- [[ctp-topic-11-ad-integration-and-login-using-ad-accounts]] +- [[ctp-topic-5-aws-identity-and-access-management-iam]] diff --git a/wiki/concepts/Landing-Zone-Architecture.md b/wiki/concepts/Landing-Zone-Architecture.md new file mode 100644 index 00000000..15a4e5b5 --- /dev/null +++ b/wiki/concepts/Landing-Zone-Architecture.md @@ -0,0 +1,44 @@ +--- +title: "Landing Zone Architecture" +type: concept +sources: [ctp-topic-1-gruntwork-landing-zone-architecture, ctp-topic-35-aws-landing-zone-design-refresher-saas-labs] +last_updated: 2026-04-14 +--- + +## Definition +Landing Zone（落地区）是基于 Gruntwork 仓库的 AWS 多账户基础设施部署单元。每个 Landing Zone 对应一个独立的 AWS 环境（如 R&D Labs、SAS/Staging/Production），由产品团队在 Gruntwork 参考架构基础上自行定义具体服务（如 ECS 集群、RDS 数据库），并通过独立的 GitHub 仓库管理 IaC 代码。 + +## Key Characteristics + +### 与 Reference Architecture 的区别 +- **Reference Architecture**：标准化的最佳实践起点和蓝图 +- **Landing Zone**：基于 Reference Architecture 的具体部署实现，由产品团队定制 +- **关键区别**：Landing Zone 不包含 ECS 集群或 RDS 数据库等具体服务，而是由各产品团队自行填充 + +### 部署结构 +- 每个 Landing Zone 拥有独立的 GitHub 仓库管理 Terraform/IaC 代码 +- 每个 Landing Zone 配置独立的 Jenkins 服务器用于部署基础设施变更 +- 每个产品团队维护自己的 Jenkins 任务来部署其负责的基础设施 + +### 身份管理 +- 安全账户使用**联邦用户（Federated User）** +- 通过 AD（Active Directory）组映射到 IAM 角色 +- 替代传统的 IAM 用户管理方式 + +## Deployment Workflow +1. Gruntwork 提供参考架构和 Terraform 模块库 +2. 产品团队基于 Gruntwork 仓库创建自己的 Landing Zone +3. 使用特性分支开发，通过 Pull Request 合并到主分支 +4. Jenkins CI/CD 流水线自动化执行 Terraform Plan/Apply +5. TerraTest 用于基础设施变更的自动化测试 + +## Related Concepts +- [[Reference-Architecture]]：Landing Zone 的设计蓝图 +- [[Federated-Access]]：Landing Zone 安全账户的身份管理机制 +- [[CI-CD-Pipeline]]：Landing Zone 的自动化部署流水线 +- [[Terraform-Modules]]：Gruntwork 提供的 IaC 模块库 + +## References +- [[ctp-topic-1-gruntwork-landing-zone-architecture]] +- [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] +- [[ctp-topic-9-ci-cd-with-gruntwork]] diff --git a/wiki/concepts/MPP.md b/wiki/concepts/MPP.md new file mode 100644 index 00000000..4b4d98c0 --- /dev/null +++ b/wiki/concepts/MPP.md @@ -0,0 +1,40 @@ +--- +title: "MPP (Massively Parallel Processing)" +type: concept +tags: + - Distributed Computing + - Data-Warehouse + - Performance +sources: + - ctp-topic-68-introduction-to-redshift +last_updated: 2026-04-23 +--- + +## Overview +MPP（大规模并行处理）是一种分布式计算架构，通过多个计算节点并行执行查询和数据处理任务，显著提升大规模数据集的查询速度和系统吞吐量。 + +## How It Works +1. **任务分解**：协调节点（Leader/Coordinator）将大型查询分解为多个子任务 +2. **并行分发**：子任务分发至多个计算节点（Compute Node） +3. **独立执行**：各节点在本地数据子集（Slice/Partition）上并行执行计算 +4. **结果汇总**：各节点结果返回协调节点，进行最终聚合和输出 + +## Key Benefits +- **线性扩展**：增加节点数量可线性提升查询性能 +- **高吞吐量**：适合复杂分析查询和大规模数据聚合 +- **容错性**：单节点故障不影响整体系统（部分实现） + +## Trade-offs +- **数据倾斜（Data Skew）**：数据分布不均导致部分节点负载过重 +- **跨节点通信**：节点间数据传输增加延迟 +- **复杂查询优化**：需精心设计数据分布策略 + +## Applications +- **数据仓库**：Amazon Redshift、Snowflake、Google BigQuery +- **大数据处理**：Apache Spark（Spark SQL）、Presto/Trino +- **科学计算**：分布式矩阵运算、基因组分析 + +## Related Concepts +- [[Columnar-Storage]]：列式存储与 MPP 协同优化分析查询 +- [[Distribution-Key]]：数据分布策略影响 MPP 性能 +- [[Sort-Key]]：排序键优化局部性，提升 MPP 节点内效率 diff --git a/wiki/concepts/Multi-Database-Architecture.md b/wiki/concepts/Multi-Database-Architecture.md new file mode 100644 index 00000000..a18db6ab --- /dev/null +++ b/wiki/concepts/Multi-Database-Architecture.md @@ -0,0 +1,89 @@ +--- +title: "Multi-Database Architecture" +type: concept +tags: + - AWS + - Database + - Architecture + - Microservices +sources: + - ctp-topic-51-architecting-with-aws-purpose-built-databases +last_updated: 2026-04-23 +--- + +## Definition +多数据库混合架构（Multi-Database Architecture）是指在单一应用中根据各部分的数据特征选用不同类型专用数据库的架构模式，以实现最优的数据层性能。 + +## Core Principle +每个数据模型应使用最适合它的数据库类型： +- **关系型数据** → 关系型数据库（Aurora / RDS） +- **高频读取** → 内存缓存（ElastiCache） +- **无结构键值** → 键值数据库（ DynamoDB） +- **高度互连** → 图数据库（Neptune） + +## Real-World Case Studies + +### Duolingo 案例（来源：[[ctp-topic-51-purpose-built-databases]]） +| 数据类型 | 数据库 | 选型原因 | +|---------|--------|---------| +| 个性化学习进度 | DynamoDB | 高写入、低延迟、弹性扩展 | +| 高频词/短语 | ElastiCache | 微秒级读取缓存 | +| 事务数据（购买、订阅）| Aurora | ACID 强一致性、复杂查询 | + +### Netflix 案例（来源：[[ctp-topic-51-purpose-built-databases]]） +| 数据类型 | 数据库 | 选型原因 | +|---------|--------|---------| +| JSON 文档（用户数据、偏好）| DynamoDB | 高弹性、低延迟、JSON 原生支持 | + +### Peloton 案例（来源：[[ctp-topic-51-purpose-built-databases]]） +| 数据类型 | 数据库 | 选型原因 | +|---------|--------|---------| +| 实时健身反馈 | ElastiCache Redis | 微秒级响应、即时用户体验 | + +## Architecture Patterns + +### Cache-Aside Pattern（旁路缓存） +``` +应用 → DynamoDB/RDS（主数据库） + ↘ ElastiCache（缓存层） +``` +- 读取：先查缓存，未命中则查数据库并回填缓存 +- 写入：先写数据库，再失效/更新缓存 + +### CQRS Pattern（命令查询职责分离） +``` +写入 → DynamoDB（优化写入） +读取 → DynamoDB + ElastiCache（优化读取） + ↘ Aurora（复杂查询读取） +``` + +### Event-Driven Data Sync +``` +DynamoDB Streams → Lambda → Aurora + → Lambda → Elasticsearch（搜索） + → Lambda → S3（归档） +``` + +## Trade-offs +| 优势 | 挑战 | +|------|------| +| 最优性能：每个场景用最佳数据库 | 复杂度：多数据库运维成本 | +| 弹性扩展：各层独立扩展 | 一致性：跨数据库事务管理 | +| 成本优化：按需选择规格 | 学习曲线：团队需掌握多种数据库 | +| 容错隔离：单库故障不扩散 | 数据迁移：服务间数据同步 | + +## Aliases +- Polyglot Persistence +- 多数据库混合架构 +- 数据库混合部署 +- Database Polyglot +- Mixed Database Architecture + +## Related Concepts +- [[Purpose-Built-Databases]]：多数据库架构的基础——专用数据库选型原则 +- [[Amazon-DynamoDB]]：多数据库架构中的键值/文档数据存储 +- [[Amazon-ElastiCache]]：多数据库架构中的缓存层组件 +- [[Amazon-Aurora]]：多数据库架构中的关系型事务数据存储 +- [[Amazon-Neptune]]：多数据库架构中的图数据存储 +- [[Amazon-Timestream]]：多数据库架构中的时序数据存储 +- [[DBA-Role-Evolution]]：云时代 DBA 需要掌握多数据库架构设计能力 diff --git a/wiki/concepts/Purpose-Built-Databases.md b/wiki/concepts/Purpose-Built-Databases.md new file mode 100644 index 00000000..6f66aceb --- /dev/null +++ b/wiki/concepts/Purpose-Built-Databases.md @@ -0,0 +1,70 @@ +--- +title: "Purpose-Built Databases" +type: concept +tags: + - AWS + - Database + - Architecture + - Cloud-Native +sources: + - ctp-topic-51-architecting-with-aws-purpose-built-databases +last_updated: 2026-04-23 +--- + +## Definition +专用数据库（Purpose-Built Databases）是一种数据库选型原则——根据应用的数据模型、访问模式和性能需求，选择最适合该用例的专用数据库类型，而非用单一数据库解决所有问题。 + +## Core Principle +> "We need to start thinking of the right purpose-built database for the right application." — Femi George, AWS Database Sales Specialist + +核心理念：**从用例出发，选择最佳工具，避免一刀切（One-Size-Fits-All）**。 + +## AWS Database Categories + +| 类别 | AWS 产品 | 适用场景 | +|------|---------|---------| +| 关系型 | RDS, Aurora | 固定 schema、ACID 事务、复杂关联查询 | +| 键值 | DynamoDB | 高吞吐量、简单键值访问、无 schema 约束 | +| 文档 | DocumentDB | 半结构化 JSON、灵活 schema、嵌套查询 | +| 宽列 | Keyspaces | 大规模写入、Cassandra 兼容工作负载 | +| 内存缓存 | ElastiCache | 微秒级延迟、高频读取、会话存储 | +| 图数据库 | Neptune | 高度互连数据、欺诈检测、推荐引擎 | +| 时序数据库 | Timestream | IoT 遥测、监控指标、时间序列分析 | +| 账本数据库 | QLDB | 不可变事务日志、审计追踪 | + +## Selection Criteria +选择专用数据库时应考虑： +1. **应用规模**：用户数量、请求量、数据量 +2. **访问模式**：读密集 vs 写密集、点查 vs 范围查询 +3. **数据模型**：结构化 vs 半结构化、关系复杂度 +4. **性能需求**：延迟、吞吐量、可用性 +5. **运维成本**：托管 vs 自管理、团队技能 + +## Multi-Database Architecture +现代应用常采用多数据库混合架构： + +**Duolingo 案例**（来源：[[ctp-topic-51-purpose-built-databases]]）： +- **DynamoDB**：存储个性化学习进度数据（键值访问） +- **ElastiCache**：缓存高频词/短语（内存缓存） +- **Aurora**：处理事务性数据（关系型） + +**Netflix 案例**（来源：[[ctp-topic-51-purpose-built-databases]]）： +- **DynamoDB**：高弹性、低延迟 JSON 文档访问 + +## Aliases +- Purpose-Built Databases +- 专用数据库 +- 专用数据库选型 +- Database Polyglot +- Polyglot Persistence + +## Related Concepts +- [[Multi-Database-Architecture]]：多数据库混合架构模式 +- [[Amazon-DynamoDB]]：AWS 专用键值数据库 +- [[Amazon-Aurora]]：云原生关系型数据库 +- [[Amazon-Neptune]]：AWS 图数据库 +- [[Amazon-Timestream]]：AWS 时序数据库 +- [[Amazon-Keyspaces]]：AWS 宽列数据库 +- [[Amazon-DocumentDB]]：AWS 文档数据库 +- [[Amazon-ElastiCache]]：AWS 内存缓存数据库 +- [[DBA-Role-Evolution]]：云时代数据库架构师角色的转变 diff --git a/wiki/concepts/RTO.md b/wiki/concepts/RTO.md index 8eba031f..157680f0 100644 --- a/wiki/concepts/RTO.md +++ b/wiki/concepts/RTO.md @@ -1,81 +1,55 @@ --- -title: "RTO (Recovery Time Objective)" -tags: [devops, disaster-recovery, sre, reliability] -created: 2026-04-25 +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 --- -# RTO (Recovery Time Objective) - -**RTO (Recovery Time Objective)** 是指系统发生故障后，业务能够容忍的最大停机时间。它衡量的是恢复速度——从系统下线到用户可以重新使用系统的时间窗口。 +## Overview +RTO（Recovery Time Objective，恢复时间目标）是从系统故障发生到恢复正常运行所需的最大可接受时间。是灾备（DR）策略中的核心指标。 ## Definition +- **RTO**：系统从故障中恢复的时间目标 +- 与 [[RPO]]（Recovery Point Objective，恢复点目标）共同构成灾备的两大核心指标 -> "RTO is about getting back online. It's the clock that starts ticking the moment your system goes down." — LaunchDarkly +## AWS Database RTO 对比 -RTO 是灾备规划的核心指标之一，与 [[RPO]]（恢复点目标）共同构成灾备目标体系。 +| 数据库服务 | AZ 故障 RTO | 架构特点 | +|-----------|------------|----------| +| **Aurora** | ~30 秒 | 6 副本跨 3 AZ 共享集群卷 | +| **RDS** | ~2 分钟 | EC2 + EBS 分离，Multi-AZ 备用节点 | +| **传统自建** | 数小时 | 需手动恢复 | -## Key Characteristics +## RTO vs RPO -| 维度 | 说明 | -|------|------| -| **衡量对象** | 停机时间（Downtime Duration） | -| **起点** | 系统故障发生的时刻 | -| **终点** | 用户可以重新使用系统 | -| **关注点** | 速度（How Fast） | +| 指标 | 定义 | 衡量内容 | +|------|------|----------| +| **RTO** | 恢复时间目标 | 系统不可用的最大时长 | +| **RPO** | 恢复点目标 | 可接受的最大数据丢失时长 | -## RTO vs. RPO - -RTO 和 RPO 经常被混淆，但衡量的是完全不同的维度： - -- **RTO** — 关注速度：系统多久能恢复？ -- **RPO** — 关注数据：能承受多少数据丢失？ - -两者可以独立设定：快速恢复不代表数据不丢失，反之亦然。 - -## Tiered RTO Targets - -| Tier | 场景 | RTO 目标 | 说明 | -|------|------|----------|------| -| Critical | 支付处理、用户认证 | < 5 分钟 | 业务立即停止，需要 3AM 告警 | -| Important | 管理后台、报表 | < 1 小时 | 业务减速但不停止 | -| Nice-to-have | 内部工具、文档站 | < 4 小时 | 仅造成不便 | - -## RTO in Modern CD Context - -传统灾备规划假设 RTO 针对的是硬件故障（服务器宕机、数据中心断电），但现代持续交付中最大的风险来自**代码变更**： - -- 支付流程 Bug 导致结账失败 -- 数据库迁移锁死应用 -- AI 模型更新产生异常响应 -- 新功能在负载下性能骤降 - -**[[Feature Flag]]** 将 RTO 从小时级降至秒级：只需切换配置，无需重新部署代码。 - -## 实现手段 - -| 方法 | RTO 效果 | 说明 | -|------|----------|------| -| 传统灾备（从备份恢复） | 小时级 | 需要重建基础设施 | -| [[Kill Switch]]（Feature Flag） | 秒级 | 配置变更，无需部署 | -| 容器化 + 自动扩缩容 | 分钟级 | 需要容器编排平台 | -| Active-Active 多活 | 近零 | 成本极高 | - -## RTO 与成本的关系 - -- 近零 RTO 需要"冗余一切"（服务器、数据库、网络、跨数据中心） -- 大多数团队无法承担如此高的成本 -- **建议**：按应用分层级设定 RTO，而非对所有系统一刀切 - -> "What does an hour of downtime actually cost your business? If it's $10K, don't spend $100K/year on infrastructure to prevent it." +## 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]]：企业级灾备策略 -- [[RPO]] — Recovery Point Objective，数据丢失量指标 -- [[Disaster Recovery]] — 灾备策略，RTO/RPO 是其核心目标 -- [[Kill Switch]] — 通过 Feature Flag 实现秒级 RTO -- [[High Availability]] — 高可用性，降低 RTO 的基础设施 -- [[Feature Flag]] — 实现配置级热修复的核心机制 - -## Sources - -- [[sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md]] +## Aliases +- Recovery Time Objective +- 恢复时间目标 +- RTO +- MTTR（Mean Time To Recovery，与 RTO 相关但 MTTR 是实际测量值） diff --git a/wiki/concepts/Reference-Architecture.md b/wiki/concepts/Reference-Architecture.md new file mode 100644 index 00000000..15dc43be --- /dev/null +++ b/wiki/concepts/Reference-Architecture.md @@ -0,0 +1,39 @@ +--- +title: "Reference Architecture" +type: concept +sources: [ctp-topic-1-gruntwork-landing-zone-architecture, ctp-topic-35-aws-landing-zone-design-refresher-saas-labs] +last_updated: 2026-04-14 +--- + +## Definition +参考架构（Reference Architecture）是一套经过实战验证的最佳实践集合，作为企业云平台部署的起点和蓝图。它定义了标准化的账户结构、网络拓扑、安全边界和服务组合，帮助组织快速建立符合安全和合规要求的云基础设施。 + +## Key Components + +### Account Structure +- **Core Accounts（核心账户）**： + - `Shared`：共享服务账户，提供 CI/CD 工具、NTP、DNS 等公共服务 + - `Logs`：日志账户，集中收集和存储所有账户的审计日志 + - `Security`：安全账户，托管 IAM 角色和联邦身份配置 +- **Workload Accounts（工作负载账户）**： + - `Prod`：生产环境账户 + - `Stage`：预发布环境账户 + - `Dev`：开发环境账户 + +### Network Topology +- Centralized network design with VPCs per account +- Transit Gateway for cross-account connectivity +- Shared services accessible via VPC peering or Transit Gateway + +## Relationship with Landing Zone +- **Reference Architecture**：标准化的起点和蓝图，定义通用模式 +- **Landing Zone**：基于 Reference Architecture 的具体部署单元，由各产品团队在 Gruntwork 仓库基础上定制 + +## Related Concepts +- [[Landing-Zone-Architecture]]：Reference Architecture 的具体部署实例 +- [[Federated-Access]]：安全账户的身份管理机制 +- [[Terraform-Modules]]：实现 Reference Architecture 的 IaC 模块库 + +## References +- [[ctp-topic-1-gruntwork-landing-zone-architecture]] +- [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] diff --git a/wiki/concepts/Service-Control-Policies-SCPs.md b/wiki/concepts/Service-Control-Policies-SCPs.md new file mode 100644 index 00000000..f46caba6 --- /dev/null +++ b/wiki/concepts/Service-Control-Policies-SCPs.md @@ -0,0 +1,98 @@ +--- +title: "Service Control Policies (SCPs)" +type: concept +tags: [AWS, Organizations, Policy, Security, Compliance, Tagging] +last_updated: 2026-04-14 +--- + +## Definition + +Service Control Policies（SCPs，服务控制策略）是 AWS Organizations 的一种高级策略类型，用于集中定义在组织单元（OU）或账户级别上所有成员账户的最大可用权限。SCPs 属于预防性控制（Preventive Controls），在 IAM 权限被评估之前先被执行，确保任何账户中的任何操作都不会超出组织设定的安全边界。与 IAM 策略不同，SCPs 本身不授予权限，而是限制可授予的权限范围。 + +## Aliases +- SCP +- Service Control Policy +- Organization Policy +- AWS Organization Policy + +## Core Attributes + +| 属性 | 说明 | +|------|------| +| 作用层级 | Organization Root / Organizational Unit (OU) / Account | +| 策略类型 | 预防性控制（Preventive） | +| 执行顺序 | 在 IAM 权限评估之前执行 | +| 默认行为 | 除非显式允许，否则拒绝（Default Deny） | +| 影响范围 | 组织内所有成员账户 | +| 不支持的操作 | 无法在根账户上附加 SCP | + +## Use Cases + +### 1. 标签合规性强制执行 +在该组织的 AWS Landing Zone 中，SCPs 用于强制执行标签规范——阻止不合规资源（如缺少必需标签键或标签值不在允许列表中）的创建。这确保了新资源从一开始就符合组织的安全和网络策略要求。 + +### 2. 服务限制 +```json +{ + "Version": "2012-10-17", + "Statement": [ + { + "Sid": "DenyUnapprovedRegions", + "Effect": "Deny", + "Action": "*", + "Resource": "*", + "Condition": { + "StringNotEquals": { + "aws:RequestedRegion": ["us-east-1", "eu-west-1"] + } + } + } + ] +} +``` + +## Limitations + +| 限制 | 说明 | +|------|------| +| 存量资源 | SCPs 无法修改或删除已存在的资源，只能阻止新资源的创建 | +| 根账户 | 无法对组织的根账户附加 SCP | +| 服务控制粒度 | 无法直接基于资源标签值做细粒度控制（需配合其他机制） | +| Tag-based SCPs | 可基于标签键存在性做过滤，但无法基于标签值列表做精确限制 | + +在标签合规性场景下，SCPs 可以强制要求"必须包含某标签键"，但对于"标签值必须在允许列表中"这类精确验证，则需要依赖 Tag Validation Tool 进行审计。 + +## SCPs vs IAM Policies + +| 维度 | SCPs | IAM Policies | +|------|------|-------------| +| 作用对象 | 组织/OU/账户级别 | IAM 用户/角色/组 | +| 执行顺序 | 先于 IAM | 后于 SCPs | +| 授予权限 | 否（仅限制范围） | 是 | +| 覆盖范围 | 全账户所有实体 | 指定实体 | + +## Context in This Wiki + +SCPs 与 Tag Validation Tool 在标签治理中形成互补关系： + +``` +SCPs（预防性控制） + ↓ 阻止不合规资源的新建 + ↓ +Tag Validation Tool（检测性控制） + ↓ 发现已存在的不合规存量资源 + ↓ +CSV 审计报告 → 团队手动修复 +``` + +## Related Concepts + +- [[AWS-Tagging-Standards]]：SCPs 强制执行的对象规范 +- [[Tag-Validation-Tool]]：SCPs 的下游补充（处理存量资源审计） +- [[Policy-as-Code]]：SCPs 本身应以代码形式管理（版本控制/GitOps） +- [[AWS-Organizations]]：SCPs 的承载平台 +- [[Zero-Trust-Architecture]]：SCPs 是零信任原则在 AWS Organizations 中的体现 + +## Sources + +- [[ctp-topic-28-aws-tag-validation-tool]] diff --git a/wiki/concepts/SnapMirror.md b/wiki/concepts/SnapMirror.md new file mode 100644 index 00000000..a3f81dc1 --- /dev/null +++ b/wiki/concepts/SnapMirror.md @@ -0,0 +1,43 @@ +--- +title: "SnapMirror" +type: concept +tags: [NetApp, Data-Replication, Disaster-Recovery, Storage] +sources: [ctp-topic-46-netapps-on-aws] +last_updated: 2026-04-14 +--- + +## Definition + +SnapMirror 是 NetApp 提供的数据复制技术，用于在 NetApp 存储系统之间（本地到云端、跨区域或跨集群）复制数据和快照。通过块级复制实现高效的数据同步，初始基线复制后，后续更新仅传输变更数据（增量复制）。 + +## Mechanism + +1. **Peering Relationship**：在集群之间和 SVM 之间建立对等关系 +2. **Baseline Copy**：初始全量复制，将源卷的完整数据复制到目标卷 +3. **Incremental Updates**：基线后，仅复制自上次更新以来更改的数据块 +4. **Read-Only Destination**：SnapMirror 关系中的目标卷为只读 + +## Key Characteristics + +- **Block-Level Replication**：块级复制而非文件级，支持 Deduplication 和 Compression 保留 +- **Encryption Support**：可选加密传输 +- **SnapMirror Relationships**：可建立级联或扇出配置 +- **Transfer Priority**：可配置传输优先级 + +## Use Cases + +- **Disaster Recovery**：本地 NetApp 到 AWS CVO 的灾备复制 +- **Data Migration**：从本地迁移到云端（配合 Cloud Volume ONTAP） +- **Cross-Region Replication**：跨 AWS 区域的数据保护 +- **Backup to Cloud**：冷数据备份到 S3（通过 CVO） + +## Related Concepts + +- [[Snapshot]]：SnapMirror 复制快照作为数据一致性的保证 +- [[Cloud Volume ONTAP (CVO)]]：AWS 云端运行 SnapMirror 的目标存储 +- [[Data Tiering]]：可与 SnapMirror 结合实现数据生命周期管理 +- [[Disaster Recovery]]：SnapMirror 是 DR 策略的核心组件 + +## Related Entities + +- [[NetApp]]：SnapMirror 的提供方 diff --git a/wiki/concepts/Tag-Validation-Tool.md b/wiki/concepts/Tag-Validation-Tool.md new file mode 100644 index 00000000..cf5d7a8d --- /dev/null +++ b/wiki/concepts/Tag-Validation-Tool.md @@ -0,0 +1,71 @@ +--- +title: "Tag Validation Tool" +type: concept +tags: [AWS, Tagging, Validation, SRE, Python, Boto3, Automation] +last_updated: 2026-04-14 +--- + +## Definition + +AWS Tag Validation Tool（SRE 团队开发的 AWS 标签验证工具）是一个基于 Python 和 Boto3 的自动化审计工具，用于扫描 AWS 账户中的资源标签合规性。该工具通过 YAML 配置文件（`variables.yaml`）定义每个账户的合法标签键及允许值，自动扫描 EC2、安全组（Security Groups）、负载均衡器（Load Balancers）和 Lambda 函数等资源类型，将扫描结果与预期值进行比对，最终生成详细的 CSV 审计报告。 + +## Aliases +- AWS Tag Validator +- Tag Audit Tool +- Tag Compliance Scanner + +## Core Components + +### Architecture +``` +variables.yaml → Python/Boto3 扫描器 → CSV 审计报告 + ↑ ↑ + 合法标签配置 不合规资源列表 + (per account) (Resource ID + 问题描述) +``` + +### Technology Stack +| 组件 | 技术 | +|------|------| +| 语言 | Python | +| AWS SDK | Boto3 | +| 环境管理 | Poetry | +| 扫描对象 | EC2, Security Groups, Load Balancers, Lambda | +| 配置格式 | YAML | +| 输出格式 | CSV | + +### Configuration (variables.yaml) +```yaml +tags: + Environment: + allowed_values: + - dev + - staging + - prod + CostCenter: + allowed_values: + - CC-001 + - CC-002 +``` + +## Context in This Wiki + +该工具解决了 Checkpoint 防火墙依赖标签配置网络访问策略所带来的合规性问题： + +- **问题背景**：SCPs（Service Control Policies）仅能阻止不合规资源的新建，无法修复已存在的存量资源 +- **解决方案**：该工具扫描存量资源，识别缺失或值错误的标签，生成 CSV 报告供团队修复 +- **工具定位**：属标签治理闭环的第三环——制定规范（Topic 10）→ 强制执行（SCPs）→ 审计发现（Topic 28） + +## Related Concepts + +- [[AWS-Tags]]：被验证的 AWS 资源标签 +- [[AWS-Tagging-Standards]]：标签规范的定义 +- [[Variables-YAML]]：工具的核心配置文件 +- [[Service-Control-Policies-SCPs]]：上游强制机制（阻止新资源创建但无法处理存量） +- [[Boto3]]：工具使用的 AWS Python SDK +- [[Poetry]]：工具的环境管理工具 +- [[Checkpoint-Firewall]]：依赖正确标签值配置网络访问策略 + +## Sources + +- [[ctp-topic-28-aws-tag-validation-tool]] diff --git a/wiki/concepts/Terraform-Modules.md b/wiki/concepts/Terraform-Modules.md new file mode 100644 index 00000000..693e7e08 --- /dev/null +++ b/wiki/concepts/Terraform-Modules.md @@ -0,0 +1,62 @@ +--- +title: "Terraform Modules" +type: concept +sources: [ctp-topic-1-gruntwork-landing-zone-architecture, ctp-topic-3-deploy-and-maintain-infrastructure] +last_updated: 2026-04-14 +--- + +## Definition +Terraform 模块（Terraform Modules）是一组可复用、经过测试的 Terraform 配置文件，用于构建具有业务上下文的 AWS 云服务。Gruntwork 的 Terraform AWS 服务目录（Service Catalog）提供了经过生产环境实战验证的模块集合，强调服务应具有业务上下文，而非简单的资源堆砌。 + +## Key Principles + +### Business Context Over Raw Resources +- 传统 IaC：定义单个 AWS 资源（EC2 实例、安全组等） +- Gruntwork 模块：封装完整的服务逻辑（如"Web 应用服务"而非"VPC + EC2 + ALB"） +- 模块包含服务所需的全部配置：网络、安全、监控、日志、备份等 + +### Reusability +- 一次编写，多处使用 +- 版本化管理，通过 Terraform Module Registry 分发 +- 支持参数化配置，适应不同环境 + +### Production-Ready +- 经过多个客户生产环境验证 +- 内置安全最佳实践（加密、访问控制、审计日志） +- 包含监控和告警配置 +- 支持灾难恢复和备份策略 + +## Module Structure +``` +module/ +├── main.tf # 主要资源定义 +├── variables.tf # 输入变量 +├── outputs.tf # 输出值 +├── versions.tf # Terraform 版本约束 +├── examples/ # 使用示例 +└── test/ # TerraTest 测试 +``` + +## Gruntwork Service Catalog +Gruntwork 提供的 Terraform 模块库，涵盖： +- 网络层：VPC、子网、NAT Gateway、VPN +- 计算层：ECS 集群、自动扩展组 +- 数据层：RDS 数据库、DynamoDB 表 +- 安全层：IAM 角色、KMS 密钥、安全组 +- 监控层：CloudWatch 告警、日志配置 + +## Relationship with Landing Zone +- Landing Zone 基于 Gruntwork 仓库创建 +- 产品团队使用 Gruntwork 模块构建业务服务 +- CI/CD 流水线自动化部署 Terraform 模块 + +## Related Concepts +- [[Landing-Zone-Architecture]]：使用 Terraform 模块构建 Landing Zone +- [[Terraform]]：基础设施即代码工具，Terraform 模块是其复用单元 +- [[TerraTest]]：用于测试 Terraform 模块的 Go 测试框架 +- [[CI-CD-Pipeline]]：自动化部署 Terraform 模块的流水线 + +## References +- [[ctp-topic-1-gruntwork-landing-zone-architecture]] +- [[ctp-topic-3-deploy-and-maintain-infrastructure]] +- [[ctp-topic-9-ci-cd-with-gruntwork]] diff --git a/wiki/concepts/Variables-YAML.md b/wiki/concepts/Variables-YAML.md new file mode 100644 index 00000000..3727c854 --- /dev/null +++ b/wiki/concepts/Variables-YAML.md @@ -0,0 +1,103 @@ +--- +title: "Variables YAML" +type: concept +tags: [AWS, Tagging, Configuration, YAML, Automation] +last_updated: 2026-04-14 +--- + +## Definition + +`variables.yaml` 是 AWS Tag Validation Tool 的核心配置文件，采用 YAML 格式定义每个 AWS 账户所期望的合法标签键及其对应的允许值列表（Allowed Values）。该文件是标签验证工具进行合规性比对的数据来源，每个账户可拥有独立的 `variables.yaml` 配置。 + +## Aliases +- variables.yml +- tag-variables.yaml +- account-vars.yaml + +## File Structure + +```yaml +# variables.yaml — 每个账户一份 +account_id: "123456789012" +account_name: "sas-prod" + +tags: + Environment: + required: true + allowed_values: + - dev + - staging + - prod + - uat + + CostCenter: + required: true + allowed_values: + - CC-FINANCE + - CC-ENGINEERING + - CC-OPERATIONS + + Owner: + required: true + allowed_values: + - team-platform + - team-data + - team-security + + Application: + required: false + allowed_values: [] # any value accepted + + Project: + required: true + allowed_values: + - project-alpha + - project-beta + - poc-ml-pipeline +``` + +## Core Attributes + +| 属性 | 说明 | +|------|------| +| 文件格式 | YAML | +| 作用域 | Per-account（每个账户独立配置） | +| 用途 | Tag Validation Tool 合规性比对的数据源 | +| 存储位置 | SRE Tools Repository | +| 管理方式 | 版本控制（Git） | + +## Fields + +| 字段 | 类型 | 必填 | 说明 | +|------|------|------|------| +| `account_id` | string | 是 | AWS 账户 ID | +| `account_name` | string | 是 | 账户名称（便于识别） | +| `tags` | dict | 是 | 标签键→约束映射 | +| `required` | bool | 否 | 该标签是否为必填项 | +| `allowed_values` | list | 否 | 该标签的允许值集合；空列表表示任意值 | + +## Context in This Wiki + +在 AWS Tag Validation Tool 的工作流中，`variables.yaml` 扮演数据模型的角色： + +``` +variables.yaml 定义规范 + ↓ +Tag Validation Tool 读取配置 + ↓ +扫描 AWS 账户资源（EC2/SG/LB/Lambda） + ↓ +比对实际标签值与 allowed_values + ↓ +生成 CSV 报告（Resource ID + 问题类型 + 期望值 vs 实际值） +``` + +## Related Concepts + +- [[Tag-Validation-Tool]]：使用 variables.yaml 作为数据源的工具 +- [[AWS-Tagging-Standards]]：标签规范的来源 +- [[Service-Control-Policies-SCPs]]：与 variables.yaml 共同构成标签治理的"规则定义 + 强制 + 审计"三层体系 + +## Sources + +- [[ctp-topic-28-aws-tag-validation-tool]] diff --git a/wiki/concepts/技术图生成.md b/wiki/concepts/技术图生成.md new file mode 100644 index 00000000..1c66733b --- /dev/null +++ b/wiki/concepts/技术图生成.md @@ -0,0 +1,45 @@ +--- +title: "技术图生成" +type: concept +tags: [] +sources: [fireworks-tech-graph] +last_updated: 2026-04-18 +--- + +## Description +用自然语言描述系统架构、流程或关系，自动生成可直接发布的 SVG/PNG 技术图的过程。核心技术栈包括 LLM 生成 SVG 代码 + 渲染工具导出 PNG。 + +## 核心流程 +1. **自然语言描述** → 用户用文字描述想要的图（架构/流程/对比/思维导图等） +2. **LLM 解析 + SVG 生成** → AI 理解描述，生成符合形状词汇表和箭头语义的 SVG 代码 +3. **渲染导出** → `rsvg-convert` 将 SVG 渲染为 1920px PNG +4. **发布** → PNG 直接嵌入文章/Slide/文档 + +## 关键工具 +- [[fireworks-tech-graph]]：Claude Code Skill，内置 7 种风格 + 14 种 UML 图 +- [[rsvg-convert]]：SVG → PNG 渲染工具 +- [[7种视觉风格系统]]：确保图形风格一致性 +- [[语义形状词汇表]]：确保图形元素语义一致性 +- [[语义箭头系统]]：确保箭头语义一致性 +- [[14种UML图]]：覆盖完整 UML 图类型 + +## 应用场景 +- **技术文档**：RAG 架构图、Agent 流程图、系统架构图 +- **博客文章**：配图生成，提升文章可读性 +- **演示文稿**：Keynote/Slide 配图，支持多种视觉风格 +- **内部 Wiki**：知识图谱、流程说明 +- **GitHub README**：项目架构图、流程图 + +## 优势 +- **速度**：几秒生成，无需手动绘图 +- **一致性**：形状词汇表 + 语义箭头系统确保视觉语义统一 +- **可编辑**：SVG 输出可随时修改 +- **可发布**：PNG 可直接嵌入文档 + +## Relationships +- [[技术图生成]] uses [[fireworks-tech-graph]] +- [[技术图生成]] uses [[7种视觉风格系统]] +- [[技术图生成]] uses [[语义形状词汇表]] +- [[技术图生成]] uses [[语义箭头系统]] +- [[技术图生成]] uses [[14种UML图]] +- [[技术图生成]] uses [[rsvg-convert]] diff --git a/wiki/concepts/语义形状词汇表.md b/wiki/concepts/语义形状词汇表.md new file mode 100644 index 00000000..f55880c8 --- /dev/null +++ b/wiki/concepts/语义形状词汇表.md @@ -0,0 +1,38 @@ +--- +title: "语义形状词汇表" +type: concept +tags: [] +sources: [fireworks-tech-graph] +last_updated: 2026-04-18 +--- + +## Description +fireworks-tech-graph 中定义的语义化形状系统——每种概念类型（LLM/Agent/存储/工具等）对应特定的 SVG 形状，确保图形在不同风格中保持一致的视觉语义。 + +## 形状映射表 + +| 概念类型 | SVG 形状 | 说明 | +|---------|---------|------| +| 用户 / 人类 | 圆形 + 身体路径 | 人形图标 | +| LLM / 模型 | 圆角矩形，双边框，⚡ | 双边框表示智能，双闪电表示计算 | +| Agent / 编排器 | 六边形 | 六边形表示协调/编排角色 | +| 短期记忆 | 虚线边框圆角矩形 | 虚线表示非持久性 | +| 长期记忆 | 实线圆柱体 | 圆柱体表示数据库/持久存储 | +| Vector Store | 带内环圆柱 | 内环表示向量/语义检索 | +| Graph DB | 三圆簇 | 三圆簇表示图结构关系 | +| 工具 / 函数 | 带 ⚙ 的矩形 | 齿轮表示工具/函数 | +| API / 网关 | 六边形（单边框） | 单边框六边形表示对外接口 | +| 消息队列 / 流 | 横向管道 | 管道表示流式/队列 | +| 文档 / 文件 | 折角矩形 | 折角表示文档 | +| 浏览器 / UI | 带三点标题栏的矩形 | 浏览器 chrome | +| 决策节点 | 菱形 | 菱形表示判断/决策 | +| 外部服务 | 虚线边框矩形 | 虚线表示外部依赖 | + +## 核心价值 +确保 AI Agent 生成的技术图在不同风格、不同时间生成时保持**图形语义一致性**——看到六边形就知道是 Agent，看到带内环圆柱就知道是向量数据库，无需解释。 + +## Relationships +- [[语义形状词汇表]] is used_by [[fireworks-tech-graph]] +- [[语义形状词汇表]] implements [[AI Agent]] visual representation +- [[语义形状词汇表]] implements [[RAG]] visual representation +- [[语义形状词汇表]] implements [[Mem0]] visual representation diff --git a/wiki/concepts/语义箭头系统.md b/wiki/concepts/语义箭头系统.md new file mode 100644 index 00000000..9d0840f6 --- /dev/null +++ b/wiki/concepts/语义箭头系统.md @@ -0,0 +1,28 @@ +--- +title: "语义箭头系统" +type: concept +tags: [] +sources: [fireworks-tech-graph] +last_updated: 2026-04-18 +--- + +## Description +fireworks-tech-graph 中定义的语义化箭头系统——通过颜色和虚线样式编码箭头的含义，使技术图的箭头本身携带语义信息，无需额外图例说明。 + +## 箭头语义表 + +| 流类型 | 线宽 | 虚线 | 含义 | +|--------|------|------|------| +| 主数据流 | 2px 实线 | — | 主要请求/响应路径 | +| 控制 / 触发 | 1.5px 实线 | — | 系统 A 触发 B | +| 记忆读取 | 1.5px 实线 | — | 从存储检索数据 | +| 记忆写入 | 1.5px | `5,3` | 写入/存储操作 | +| 异步 / 事件 | 1.5px | `4,2` | 非阻塞异步事件 | +| 反馈 / 循环 | 1.5px 曲线 | — | 迭代推理循环 | + +## 核心价值 +AI Agent 生成技术图时，通过统一箭头规范确保不同人、不同时生成的图保持**箭头语义一致性**——阅读者看到虚线箭头就知道是写入操作，看到曲线就知道是反馈循环，无需查阅图例。 + +## Relationships +- [[语义箭头系统]] is used_by [[fireworks-tech-graph]] +- [[语义箭头系统]] is part_of [[技术图生成]] diff --git a/wiki/entities/Amazon-Aurora.md b/wiki/entities/Amazon-Aurora.md new file mode 100644 index 00000000..ad24326f --- /dev/null +++ b/wiki/entities/Amazon-Aurora.md @@ -0,0 +1,48 @@ +--- +title: "Amazon Aurora" +type: entity +tags: + - AWS + - Database + - Cloud-Native + - Relational Database +sources: + - ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora +last_updated: 2026-04-23 +--- + +## Overview +Amazon Aurora 是 AWS 提供的云原生关系型数据库，采用 6 副本跨 3 可用区（AZ）的共享集群卷架构，相比传统 RDS 提供更高的性能、可用性和自动扩展能力。 + +## Core Architecture +- **Shared Cluster Volume**：跨 3 AZ 的 6 块 EBS 卷组成的共享存储，写入时自动复制到所有副本 +- **无需数据复制**：新增读副本时直接连接同一集群卷，无需重新复制数据 +- **Writer/Reader Endpoints**：独立的写入端点和读取端点，支持自动负载均衡 + +## Key Advantages +- **RTO 30 秒**：AZ 故障时恢复时间目标仅 30 秒 +- **自动扩缩容**：Aurora Serverless v2 支持按需自动扩缩（实例类型/版本/区域有限制） +- **Aurora Global**：跨区域复制方案，支持托管式切换和故障转移 +- **Blue-Green Deployment**：Aurora MySQL 支持 Blue-Green 大版本升级（PostgreSQL 不支持） + +## Key Limitations +- 最小规格和成本高于 RDS +- Serverless v2 对实例类型、版本和区域有限制 +- 按 IO 收费，高 IO 场景成本可能较高 +- PostgreSQL 不支持 Blue-Green 部署 + +## Cost Considerations +Aurora 按 IO 计数收费，IO 理论上无上限（AWS 鼓励提供尽可能高的 IO 以增加收入）。适合超过 10-20 TB 的数据库或对 IO 性能有严格要求的场景。 + +## Related Entities +- [[Amazon RDS]]：传统关系型数据库托管服务 +- [[AWS]]：云服务提供商 +- [[EBS]]：Elastic Block Store，Aurora 的底层存储 +- [[ctp-topic-51-architecting-with-aws-purpose-built-databases]]：AWS 专用数据库架构 +- [[ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora]]：RDS vs Aurora 详细对比 + +## Aliases +- Aurora +- Aurora PostgreSQL +- Aurora MySQL +- Amazon Aurora Database diff --git a/wiki/entities/Amazon-DocumentDB.md b/wiki/entities/Amazon-DocumentDB.md new file mode 100644 index 00000000..240b914d --- /dev/null +++ b/wiki/entities/Amazon-DocumentDB.md @@ -0,0 +1,42 @@ +--- +title: "Amazon DocumentDB" +type: entity +tags: + - AWS + - Database + - Document + - MongoDB +sources: + - ctp-topic-51-architecting-with-aws-purpose-built-databases +last_updated: 2026-04-23 +--- + +## Overview +Amazon DocumentDB 是 AWS 全托管的 MongoDB 兼容文档数据库（Document Database），支持灵活 schema（Flexible Schema），适合存储 JSON 类半结构化数据。 + +## Key Characteristics +- **兼容性**：MongoDB 3.6、4.0、5.0 API 兼容 +- **数据模型**：文档（Document），存储为 BSON 格式 +- **Schema 灵活性**：无需预定义 schema，可随时添加/修改字段 +- **查询能力**：支持深度嵌套查询、数组查询、聚合管道 +- **规模**：存储和计算分离，支持横向扩展至数 TB + +## Key Use Cases +- **内容管理**：CMS、博客、产品目录 +- **用户档案**：灵活属性的用户配置文件 +- **物联网数据**：设备配置和状态文档 +- **实时分析**：日志和事件数据的快速写入 + +## Aliases +- DocumentDB +- Amazon DocumentDB +- AWS DocumentDB +- Amazon DocumentDB (with MongoDB compatibility) + +## Related Entities +- [[Amazon-DynamoDB]]：均为 NoSQL，DocumentDB 支持更深的查询能力，DynamoDB 提供更简单的 API 和更高的一致性保证 +- [[Amazon-RDS]]：关系型数据库，DocumentDB 提供 schema 灵活性，RDS 提供强 schema 和事务支持 + +## Related Concepts +- [[Purpose-Built-Databases]]：DocumentDB 是 AWS 专用数据库家族中的文档数据库成员 +- [[Document-Database]]：文档数据库核心概念——无 schema JSON/BSON 存储、嵌套文档、聚合管道 diff --git a/wiki/entities/Amazon-DynamoDB.md b/wiki/entities/Amazon-DynamoDB.md new file mode 100644 index 00000000..12b343cb --- /dev/null +++ b/wiki/entities/Amazon-DynamoDB.md @@ -0,0 +1,41 @@ +--- +title: "Amazon DynamoDB" +type: entity +tags: + - AWS + - Database + - NoSQL + - Key-Value + - Document +sources: + - ctp-topic-51-architecting-with-aws-purpose-built-databases +last_updated: 2026-04-23 +--- + +## Overview +Amazon DynamoDB 是 AWS 全托管的 NoSQL 键值和文档数据库，提供单位数毫秒（single-digit millisecond）性能，支撑日处理万亿级请求规模。 + +## Key Characteristics +- **数据类型**：键值（Key-Value）和文档（Document，JSON） +- **性能**：单-digit 毫秒延迟，任何规模下均保持一致性能 +- **规模**：可扩展至日处理万亿级请求 +- **管理模式**：全托管（无服务器），无需容量规划 +- **API**：支持 CRUD 操作，自动分区 + +## Aliases +- DynamoDB +- AWS DynamoDB +- Amazon DynamoDB + +## Used By +- **Netflix**：使用 DynamoDB 实现高弹性和低延迟的 JSON 文档访问（来源：[[ctp-topic-51-purpose-built-databases]]） +- **Duolingo**：使用 DynamoDB 存储个性化学习数据（来源：[[ctp-topic-51-purpose-built-databases]]） + +## Related Entities +- [[Amazon-Aurora]]：关系型数据库，Aurora 是 DynamoDB 在强一致性事务场景的替代方案 +- [[Amazon-RDS]]：关系型数据库，固定 schema vs DynamoDB 的无 schema 灵活性 +- [[Amazon-ElastiCache]]：缓存层，可与 DynamoDB 组合使用提升读取性能 + +## Related Concepts +- [[Purpose-Built-Databases]]：DynamoDB 是 AWS 专用数据库家族的核心成员 +- [[Multi-Database-Architecture]]：DynamoDB 常与其他数据库（如 ElastiCache、Aurora）组合使用 diff --git a/wiki/entities/Amazon-ElastiCache.md b/wiki/entities/Amazon-ElastiCache.md new file mode 100644 index 00000000..9f46b372 --- /dev/null +++ b/wiki/entities/Amazon-ElastiCache.md @@ -0,0 +1,50 @@ +--- +title: "Amazon ElastiCache" +type: entity +tags: + - AWS + - Database + - In-Memory + - Cache + - Redis + - Memcached +sources: + - ctp-topic-51-architecting-with-aws-purpose-built-databases +last_updated: 2026-04-23 +--- + +## Overview +Amazon ElastiCache 是 AWS 全托管的内存缓存服务，支持 Redis 和 Memcached 两种引擎，是降低数据库负载和提升应用响应速度的核心组件。 + +## Key Characteristics +- **双引擎**：Redis（全功能，支持数据结构丰富）和 Memcached（简单，高并发多核） +- **性能**：内存访问，微秒至毫秒级延迟 +- **全托管**：自动补丁、故障恢复、备份 +- **复制**：支持只读副本，提升读取吞吐量 + +## Key Use Cases +- **数据库缓存**：将高频读取数据缓存，减少数据库负载（典型命中率 80%+） +- **会话存储**：用户会话数据（登录状态、购物车） +- **实时分析**：排行榜、计数器、实时指标 +- **媒体流缓存**：视频/音乐流媒体缓存热点内容 +- **消息队列**：Redis Pub/Sub 实现发布/订阅模式 + +## Notable Users +- **Peloton**：使用 ElastiCache Redis 为健身用户提供即时反馈（来源：[[ctp-topic-51-purpose-built-databases]]） +- **Duolingo**：使用 ElastiCache 缓存高频词和短语（来源：[[ctp-topic-51-purpose-built-databases]]） + +## Aliases +- ElastiCache +- Amazon ElastiCache +- AWS ElastiCache +- Amazon ElastiCache for Redis + +## Related Entities +- [[Amazon-RDS]]：数据库层，ElastiCache 作为缓存层配合使用 +- [[Amazon-DynamoDB]]：NoSQL 数据库，ElastiCache 可作为 DynamoDB 的读取加速层 +- [[Amazon-Aurora]]：关系型数据库，ElastiCache 可缓存 Aurora 的热点查询结果 + +## Related Concepts +- [[Purpose-Built-Databases]]：ElastiCache 是 AWS 专用数据库家族中的内存缓存数据库成员 +- [[In-Memory-Database]]：内存数据库核心概念——数据驻留内存 vs 磁盘，权衡成本与性能 +- [[Multi-Database-Architecture]]：ElastiCache 常作为 Aurora/DynamoDB/RDS 的缓存层，与主数据库构成读写分离架构 diff --git a/wiki/entities/Amazon-Keyspaces.md b/wiki/entities/Amazon-Keyspaces.md new file mode 100644 index 00000000..16ad23d4 --- /dev/null +++ b/wiki/entities/Amazon-Keyspaces.md @@ -0,0 +1,42 @@ +--- +title: "Amazon Keyspaces" +type: entity +tags: + - AWS + - Database + - Wide-Column + - Cassandra +sources: + - ctp-topic-51-architecting-with-aws-purpose-built-databases +last_updated: 2026-04-23 +--- + +## Overview +Amazon Keyspaces 是 AWS 全托管的 Apache Cassandra 兼容数据库（Wide-Column Database），提供无服务器选项，无需管理底层基础设施。 + +## Key Characteristics +- **兼容性**：与 Apache Cassandra Query Language (CQL) 兼容 +- **部署模式**：提供有服务器（预置容量）和无服务器（按请求计费）两种模式 +- **规模**：支持大规模无结构 schema 的工作负载 +- **可用性**：多 AZ 部署，自动复制保证持久性 +- **管理模式**：全托管，无需运维 Cassandra 集群 + +## Key Use Cases +- **大规模时间序列数据**：IoT 事件日志 +- **产品目录**：灵活属性的电商产品数据 +- **用户事件追踪**：高写入吞吐的用户行为分析 +- **消息历史**：聊天记录、邮件等时序消息存储 + +## Aliases +- Keyspaces +- Amazon Keyspaces +- AWS Keyspaces +- Amazon Keyspaces for Apache Cassandra + +## Related Entities +- [[Amazon-DynamoDB]]：均为 NoSQL，DynamoDB 是 AWS 自研的键值/文档数据库，Keyspaces 是托管版 Cassandra +- [[Amazon-Neptune]]：图数据库，Keyspaces 是宽列数据库，适用场景不同 + +## Related Concepts +- [[Purpose-Built-Databases]]：Keyspaces 是 AWS 专用数据库家族中的宽列数据库成员 +- [[Wide-Column-Database]]：宽列数据库核心概念——Cassandra 数据模型（Row Key / Column Family / Super Column） diff --git a/wiki/entities/Amazon-Neptune.md b/wiki/entities/Amazon-Neptune.md new file mode 100644 index 00000000..45ff527d --- /dev/null +++ b/wiki/entities/Amazon-Neptune.md @@ -0,0 +1,34 @@ +--- +title: "Amazon Neptune" +type: entity +tags: + - AWS + - Database + - Graph +sources: + - ctp-topic-51-architecting-with-aws-purpose-built-databases +last_updated: 2026-04-23 +--- + +## Overview +Amazon Neptune 是 AWS 全托管的图数据库（Graph Database），专为高度互连数据设计，支持 Apache TinkerPop Gremlin 和 SPARQL 查询语言。 + +## Key Use Cases +- **欺诈检测**：发现传统关系型数据库难以识别的关联模式 +- **社交网络**：好友推荐、共同联系人分析 +- **推荐系统**：基于用户行为图的个性化推荐 +- **知识图谱**：实体关系的存储与查询 + +## Aliases +- Neptune +- Amazon Neptune +- AWS Neptune +- Amazon Neptune Graph Database + +## Related Entities +- [[Amazon-DynamoDB]]：NoSQL 键值数据库，Neptune 处理高度互连数据，DynamoDB 处理简单键值访问 +- [[Amazon-RDS]]：关系型数据库，Neptune 在关联复杂度的场景优于关系型数据库 + +## Related Concepts +- [[Purpose-Built-Databases]]：Neptune 是 AWS 专用数据库家族中的图数据库成员 +- [[Graph-Database]]：图数据库的核心概念——节点（实体）、边（关系）、属性 diff --git a/wiki/entities/Amazon-RDS.md b/wiki/entities/Amazon-RDS.md new file mode 100644 index 00000000..9d9e7a7a --- /dev/null +++ b/wiki/entities/Amazon-RDS.md @@ -0,0 +1,54 @@ +--- +title: "Amazon RDS" +type: entity +tags: + - AWS + - Database + - Relational Database + - Managed Service +sources: + - ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora +last_updated: 2026-04-23 +--- + +## Overview +Amazon RDS（Relational Database Service）是 AWS 提供的托管关系型数据库服务，计算（EC2）与存储（EBS）分离，支持 Multi-AZ 部署，相比 Aurora 成本更低、存储选项更灵活。 + +## Core Architecture +- **Compute + Storage Separation**：EC2 计算节点 + EBS 存储卷的分离架构 +- **Multi-AZ Deployment**：主节点 + 备用节点（独立计算和存储），故障时备用节点接管 +- **Single Endpoint**：每个集群一个端点（不同于 Aurora 的 Writer/Reader 分离） + +## Key Advantages +- **更低入门成本**：提供更小规格实例，适合小型数据库 +- **存储灵活性**：支持 GP2、GP3、预置 IOPS、磁性存储多种类型 +- **广泛引擎支持**：PostgreSQL、MySQL、MariaDB、Oracle、SQL Server 等 +- **更成熟**：发布更久，文档和社区资源更丰富 + +## Key Limitations +- **RTO 2 分钟**：AZ 故障时恢复时间目标约 2 分钟 +- **读副本需数据复制**：新增读副本需重新复制数据 +- **无 Blue-Green Deployment**（PostgreSQL/MySQL 均不支持跨版本 Blue-Green） +- **最大 IO 受 EBS 限制**：不如 Aurora 的无上限 IO 能力 + +## Storage Types +| 类型 | 特点 | 适用场景 | +|------|------|----------| +| GP2 | 通用 SSD，平衡性能与成本 | 大多数工作负载 | +| GP3 | 通用 SSD，独立性能配置 | 需要成本优化的场景 | +| 预置 IOPS | 高性能，稳定的 IOPS | IO 密集型应用 | +| 磁性 | 低成本，较低性能 | 归档/不常访问的数据 | + +## Related Entities +- [[Amazon Aurora]]：云原生数据库，性能更高但成本更高 +- [[AWS]]：云服务提供商 +- [[EBS]]：Elastic Block Store，RDS 的存储后端 +- [[ctp-topic-51-architecting-with-aws-purpose-built-databases]]：AWS 专用数据库架构 +- [[ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora]]：RDS vs Aurora 详细对比 + +## Aliases +- RDS +- Amazon RDS +- RDS PostgreSQL +- Amazon Relational Database Service +- AWS RDS diff --git a/wiki/entities/Amazon-Redshift.md b/wiki/entities/Amazon-Redshift.md new file mode 100644 index 00000000..975919e9 --- /dev/null +++ b/wiki/entities/Amazon-Redshift.md @@ -0,0 +1,54 @@ +--- +title: "Amazon Redshift" +type: entity +tags: + - AWS + - Data-Warehouse + - OLAP + - Managed Service +sources: + - ctp-topic-68-introduction-to-redshift +last_updated: 2026-04-23 +--- + +## Overview +Amazon Redshift 是 AWS 提供的大规模并行处理（MPP）云数据仓库服务，支持 PB 级数据存储，面向 OLAP（在线分析处理）工作负载。完全托管，无需自行管理基础设施，具备自动备份、点时间恢复和跨区域灾难恢复能力。 + +## Core Architecture +- **Leader Node**：协调节点，负责客户端连接（JDBC/ODBC）、Schema 管理、仓库元数据和查询计划生成，将查询指令分发至 Compute Node +- **Compute Node**：执行节点，根据实例类型决定节点数量，每个节点在 Slices 上并行处理数据，完成后返回结果至 Leader Node +- **Slices**：Compute Node 内部的虚拟分区，每个 Slice 独立处理数据子集，实现并行计算 + +## Instance Types +| 类型 | 特点 | 适用场景 | +|------|------|----------| +| Dense Compute | 高 CPU + 内存，适合计算密集型查询 | 大规模数据分析 | +| Dense Storage | 高存储，适合存储密集型工作负载 | 历史数据归档 | +| RA3 | 性价比最优，AWS 托管 NVMe 存储，可独立扩展计算和存储 | 大容量数据仓库（推荐） | + +## Key Features +- **MPP（大规模并行处理）**：跨多个 Compute Node 并行执行查询，显著提升查询速度和响应时间 +- **列式存储（Columnar Storage）**：数据按列存储，适合聚合查询和全表扫描，相比行式存储 I/O 效率更高 +- **行式存储（Row Storage）**：适合少量行的精确查询和点查询 +- **数据压缩**：采用 ZSTD/LZO 等压缩算法，减少存储空间和 I/O 开销 +- **Sort Key（排序键）**：决定数据在磁盘上的物理排序顺序，优化范围查询和过滤操作 +- **Distribution Key（分布键）**：决定数据在 Compute Node 间的分布方式，影响数据倾斜和跨节点数据传输 + +## Comparison with Other AWS Databases +- **vs Amazon RDS/Aurora**：RDS/Aurora 面向 OLTP（事务处理），Redshift 面向 OLAP（分析处理）；RDS/Aurora 适合写入密集型，Redshift 适合读取/分析密集型 +- **vs Amazon DynamoDB**：DynamoDB 面向 NoSQL 键值/文档场景，Redshift 面向复杂 SQL 分析查询 +- **vs Amazon Aurora**：Aurora 共享存储架构（6副本跨3 AZ），Redshift 独立 Compute Node 架构；Aurora 适合 10TB 以下场景，Redshift 适合 PB 级分析 + +## Related Entities +- [[Amazon RDS]]：托管关系型数据库，面向 OLTP +- [[Amazon Aurora]]：云原生关系型数据库，共享存储架构 +- [[AWS]]：云服务提供商 +- [[ctp-topic-68-introduction-to-redshift]]：Redshift 入门介绍 +- [[ctp-topic-51-purpose-built-databases]]：AWS 专用数据库选型全景 +- [[ctp-topic-66-rds-vs-aurora]]：RDS 与 Aurora 对比参考 + +## Aliases +- Redshift +- Amazon Redshift +- AWS Redshift +- Redshift Data Warehouse diff --git a/wiki/entities/Amazon-Timestream.md b/wiki/entities/Amazon-Timestream.md new file mode 100644 index 00000000..8055cbe3 --- /dev/null +++ b/wiki/entities/Amazon-Timestream.md @@ -0,0 +1,41 @@ +--- +title: "Amazon Timestream" +type: entity +tags: + - AWS + - Database + - Time-Series + - IoT +sources: + - ctp-topic-51-architecting-with-aws-purpose-built-databases +last_updated: 2026-04-23 +--- + +## Overview +Amazon Timestream 是 AWS 全托管的时序数据库（Time-Series Database），专为高吞吐量时序数据设计，支持自动数据分层（热存储/冷存储）。 + +## Key Use Cases +- **IoT 传感器数据**：温度、压力、位置等设备遥测数据 +- **应用监控**：指标、日志、追踪数据的存储与分析 +- **工业遥测**：生产线设备状态监控 +- **金融数据**：股票价格、交易事件等时间序列分析 + +## Key Characteristics +- **数据模型**：时间戳 + 测量值 + 维度 +- **自动分层**：热存储（Recent data）→ 冷存储（Historical data），自动降本 +- **查询引擎**：内置时序分析函数（插值、聚合、窗口函数） +- **性能**：专为高写入吞吐量优化，支持数百万设备并发写入 + +## Aliases +- Timestream +- Amazon Timestream +- AWS Timestream +- Amazon Timestream for IoT Analytics + +## Related Entities +- [[Prometheus]]：时序监控数据采集器，Timestream 可作为其长期存储后端 +- [[Amazon-DynamoDB]]：通用 NoSQL 数据库，Timestream 在时序场景有 10-100 倍成本优势 + +## Related Concepts +- [[Purpose-Built-Databases]]：Timestream 是 AWS 专用数据库家族中的时序数据库成员 +- [[Time-Series-Database]]：时序数据库核心概念——时间戳索引、数据分层、降采样查询 diff --git a/wiki/entities/Checkpoint.md b/wiki/entities/Checkpoint.md new file mode 100644 index 00000000..69b0cfe0 --- /dev/null +++ b/wiki/entities/Checkpoint.md @@ -0,0 +1,57 @@ +--- +title: "Checkpoint" +type: entity +tags: [Firewall, Network-Security, AWS, Cloud-Security] +last_updated: 2026-04-14 +--- + +## Overview + +Checkpoint（Check Point Software Technologies）是全球领先的网络安全解决方案提供商，其防火墙产品在该组织的 AWS Landing Zone 架构中扮演关键角色。Checkpoint 防火墙通过读取 AWS 资源的标签值（Tags）来动态配置网络访问策略，这意味着资源标签的有效性直接影响网络连通性。 + +## Role in AWS Landing Zone + +在企业 AWS 架构中，Checkpoint 防火墙与 AWS 资源标签紧密集成： + +- **读取标签来源**：EC2 实例、安全组（Security Groups）、负载均衡器（Load Balancers） +- **基于标签决策**：根据标签键值对判断资源所属环境（dev/staging/prod）、成本中心、负责人等属性 +- **动态网络策略**：根据标签值自动应用相应的网络访问控制规则 + +### 网络安全依赖链 + +``` +AWS 资源标签（Tag）→ Checkpoint 防火墙读取 → 网络访问策略配置 + ↑ + 标签缺失或无效 + ↓ + 相关网络流量被拦截 +``` + +## Impact of Tag Non-Compliance + +当 AWS 资源缺少必需标签或标签值不在允许列表中时： +1. Checkpoint 防火墙无法识别资源身份 +2. 无法将资源匹配到正确的网络策略 +3. 防火墙执行默认拒绝策略，**拦截该资源的所有网络流量** +4. 导致服务中断或连接失败 + +这使得 **标签合规性从"可选管理实践"变为"网络安全硬性要求"**。 + +## Solutions + +| 机制 | 作用 | 局限性 | +|------|------|--------| +| [[Service-Control-Policies-SCPs]] | 阻止不合规新资源创建 | 无法修复存量资源 | +| [[Tag-Validation-Tool]] | 审计存量资源标签合规性 | 仅审计，需人工修复 | + +## Related Concepts + +- [[AWS-Tags]]：Checkpoint 读取的元数据 +- [[AWS-Tagging-Standards]]：标签规范的定义 +- [[Tag-Validation-Tool]]：确保标签合规性的工具 +- [[Service-Control-Policies-SCPs]]：强制执行标签规范的上游机制 +- [[Checkpoint-Firewall]]：（同义词，可互链） + +## Sources + +- [[ctp-topic-28-aws-tag-validation-tool]] diff --git a/wiki/entities/Gruntwork.md b/wiki/entities/Gruntwork.md new file mode 100644 index 00000000..0529e453 --- /dev/null +++ b/wiki/entities/Gruntwork.md @@ -0,0 +1,30 @@ +--- +title: "Gruntwork" +type: entity +sources: [ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs] +last_updated: 2026-04-14 +--- + +## Overview +Gruntwork 是 Micro Focus Cloud Transformation Programme (CTP) 中采用的 AWS Landing Zones 基础设施框架提供方。Gruntwork Landing Zones 提供预配置的、基于最佳实践的 AWS 基础架构模板，帮助企业快速构建符合安全和合规要求的 AWS 多账户架构。 + +## Aliases +- Gruntwork AWS Landing Zones +- Gruntwork LZ + +## Key Capabilities +- **多环境支持**：区分 R&D Labs 和 SAS（Staging/Production）两种环境类型，分别对应不同的 AD 域名架构 +- **预制 AMI**：SRE 团队维护内置域加入脚本的标准化机器镜像 +- **IaC 集成**：与 Terraform/TerraGrunt 深度集成，支持 `user_data` 触发自动化域加入流程 +- **AD 集成**：提供标准化的 Active Directory 服务集成方案，包括 DNS 管理和安全动态更新 + +## Related Entities +- [[SRE Team]]：构建和维护 Gruntwork LZ 中预制 AMI 的团队 +- [[Gruntwork AWS Landing Zones Overview]]：Gruntwork LZ 的整体架构概述 +- [[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]]：AD 服务集成的核心参考文档 + +## References +- [[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]] +- [[ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i]] +- [[ctp-topic-9-ci-cd-with-gruntwork]] +- [[ctp-topic-1-gruntwork-landing-zone-architecture]] diff --git a/wiki/entities/Intsas.local.md b/wiki/entities/Intsas.local.md new file mode 100644 index 00000000..f9117b36 --- /dev/null +++ b/wiki/entities/Intsas.local.md @@ -0,0 +1,23 @@ +--- +title: "Intsas.local" +type: entity +sources: [ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs] +last_updated: 2026-04-14 +--- + +## Overview +`intsas.local` 是 Gruntwork AWS Landing Zones 架构中专门分配给生产和分阶段 SAS（Staging-And-Security）环境的 Active Directory 域名。所有生产/SAS 环境中的 Windows 和 Linux 实例均加入此域名。 + +## Usage Context +- **环境类型**：Production（生产环境）和 SAS（Staging-And-Security） +- **管理方式**：通过 SMACKS 工单系统申请新账号、重置密码或处理复杂变更，强调资源所有权归属和审计合规 +- **特点**：相比 R&D 环境，生产/SAS 环境更注重安全合规、资源所有权归属和审计追踪 + +## Related Entities +- [[swinford.net]]：研发实验室（R&D Labs）环境的对应 AD 域名 +- [[SMACKS]]：生产/SAS 环境的工单管理系统 +- [[Gruntwork Landing Zones]]：域名归属的基础架构框架 +- [[SRE Team]]：维护 AD 域名基础设施的团队 + +## References +- [[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]] diff --git a/wiki/entities/NetApp.md b/wiki/entities/NetApp.md new file mode 100644 index 00000000..0f47dbca --- /dev/null +++ b/wiki/entities/NetApp.md @@ -0,0 +1,48 @@ +--- +title: "NetApp" +type: entity +tags: [Storage, Enterprise, AWS, Cloud-Storage] +sources: [ctp-topic-46-netapps-on-aws] +last_updated: 2026-04-14 +--- + +## Overview + +NetApp（纳斯达克：NTAP）是全球领先的数据存储和混合云数据管理解决方案提供商，总部位于美国加州圣何塞。ONTAP 是其核心统一存储操作系统。 + +## Core Products + +- **ONTAP**：统一的存储操作系统，支持 SMB、NFS、FC、FCOE、iSCSI 等多种存储协议 +- **Cloud Volume ONTAP (CVO)**：ONTAP 的 AWS 云版本，通过 EC2 实例运行 +- **FSX for NetApp ONTAP**：AWS 原生托管的 NetApp 服务（POC 阶段） +- **Cloud Manager**：NetApp 云服务的集中管理平台 + +## Storage Concepts + +- **Aggregate**：由多个磁盘组成的 RAID 组，构成基础存储池 +- **FlexVol**：托管在 Aggregate 之上的灵活数据容器 +- **Qtree**：卷的进一步细分，支持权限和配额管理 +- **LUN**：块级存储的逻辑表示，通过 FC 或 iSCSI 呈现 +- **LIF**：逻辑接口，承载 IP 地址用于管理和数据服务 +- **SVM**：存储虚拟机，支持多租户隔离 + +## Key Capabilities + +- **Data Tiering**：活跃数据存 EBS，非活跃数据自动迁移到 S3 +- **SnapMirror**：块级跨集群数据复制 +- **Snapshot**：点-in-time 只读镜像，最小化空间消耗 +- **Encryption**：256-bit 加密，支持 AWS KMS 集成 + +## AWS Deployment + +组织已在 15 个 AWS 区域部署约 **1.3 PB** 数据，使用 Cloud Manager 集中管理。存储后端使用 AWS EBS（GP3、GP2、IO1、IO2、ST1）。 + +## Related Tools + +- **迁移工具**：SnapMirror、NetApp XCP、Cloud Sync、AWS DataSync、Silver Peak WAN Optimizer +- **监控**：Cityscope、WebTool +- **自动化**：Terraform（计划引入） + +## Aliases +- NetApp, Inc. +- NTAP diff --git a/wiki/entities/Octane-Hub.md b/wiki/entities/Octane-Hub.md new file mode 100644 index 00000000..2fa7cee3 --- /dev/null +++ b/wiki/entities/Octane-Hub.md @@ -0,0 +1,57 @@ +--- +title: "Octane Hub" +type: entity +tags: [aws, cloud-migration, docker, devops, ctp] +last_updated: 2026-04-23 +--- + +## Basic Info +- **Role**: Software Factory 团队，Micro Focus 云转型计划一部分 +- **Leader**: Holger Rode（CTO，软件工厂团队负责人） +- **Migration Project**: 将生产服务从 Bibling Lab 数据中心迁移到 AWS Landing Zone + +## Aliases +- Octane Hub + +## Key Contributions +主导 Docker 容器化工作负载的 AWS 云迁移实战项目： + +| Workload | Description | Migration Target | +|----------|-------------|-----------------| +| QuickSee | Web 应用程序 | Docker → AWS | +| Release Manager | Web 应用程序 | Docker → AWS | +| Patch Manager | Web 应用程序 | Docker → AWS | +| 安全程序板 | 安全相关 Web 应用 | Docker → AWS | +| 文件存储 | ~10TB 文件存储 | EBS（实时）+ EFS（备份）| +| MSSQL 数据库 | 大型数据库服务器 | EBS → 计划迁移到 Postgres | + +## Cloud Migration Journey +- **原环境**: Bibling Lab 物理数据中心（3 台物理服务器 + 多台虚拟机） +- **触发因素**: Bibling 数据中心即将关闭 +- **POC 账户**: 5 月获得 AWS Landing Zone POC 账户访问权限 +- **生产账户**: 6 月获得 AWS Landing Zone 生产账户 +- **迁移策略**: 无缝过渡，紧密镜像现有设置，避免 Go Live 期间进行重大技术变更 + +## Technology Stack +- **容器化**: Docker +- **镜像构建**: Packer +- **基础设施即代码**: Terraform / TerraGrunt +- **网络**: VPC Transit Gateway +- **DNS**: Route 53 +- **存储**: EBS（数据库）、EFS（备份）、S3（成本优化目标） +- **计划演进**: AWS ECS + +## Key Learnings +- EFS 不适用于需要高性能数据库场景（数据库无法直接在 EFS 上运行） +- IaC 从控制台脚本演进为 Packer + Terraform/TerraGrunt 是可重复、可审计的部署流程 +- 网络配置需要与网络团队协作，多次 PCS 请求解决网络问题 +- 标签系统管理 VPC 访问是关键的安全控制 + +## Next Steps +1. 改进 DR（灾难恢复）和高可用性 +2. 通过 S3 进行成本优化 +3. 从 MSSQL 迁移到 Postgres +4. 可能迁移到 AWS ECS 服务 + +## References +- [[ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i]] diff --git a/wiki/entities/SMACKS.md b/wiki/entities/SMACKS.md new file mode 100644 index 00000000..ec7eae28 --- /dev/null +++ b/wiki/entities/SMACKS.md @@ -0,0 +1,22 @@ +--- +title: "SMACKS" +type: entity +sources: [ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs] +last_updated: 2026-04-14 +--- + +## Overview +SMACKS 是 Micro Focus 内部的工单/服务管理系统（Service Management System 的内部命名），用于处理生产环境和 SAS（Staging-And-Security）环境中的 Active Directory 相关请求，包括：新账号申请、密码重置、以及复杂的生产环境变更。 + +## Usage Context +- **适用环境**：Production 和 SAS 环境 +- **对比 R&D 环境**：R&D Labs 环境使用 [[MIM (Microsoft Identity Manager)]] 自助服务工具，生产/SAS 环境因安全合规要求必须通过正式工单流程处理 +- **典型操作**：AD 账号申请、权限变更、资源所有权转移、密码重置 + +## Related Entities +- [[Intsas.local]]：SMACKS 工单系统所服务的 AD 域名环境 +- [[Gruntwork]]：提供 Landing Zones 基础设施框架 +- [[MIM (Microsoft Identity Manager)]]：R&D 环境的对应自助服务工具 + +## References +- [[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]] diff --git a/wiki/entities/SRE-Team.md b/wiki/entities/SRE-Team.md new file mode 100644 index 00000000..a695d6ac --- /dev/null +++ b/wiki/entities/SRE-Team.md @@ -0,0 +1,39 @@ +--- +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 + +| 职责 | 说明 | +|------|------| +| 运维自动化 | 开发自动化工具减少人工重复操作 | +| 工具开发 | 构建内部平台工具（如 Tag Validation Tool） | +| 可靠性保障 | 确保 AWS 基础设施的高可用性和可观测性 | +| 内部平台 | 维护 SRE Tools Repository 内部代码仓库 | + +## 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]] diff --git a/wiki/entities/Swinford.net.md b/wiki/entities/Swinford.net.md new file mode 100644 index 00000000..1c226e24 --- /dev/null +++ b/wiki/entities/Swinford.net.md @@ -0,0 +1,23 @@ +--- +title: "Swinford.net" +type: entity +sources: [ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs] +last_updated: 2026-04-14 +--- + +## Overview +`swinford.net` 是 Gruntwork AWS Landing Zones 架构中专门分配给研发实验室（R&D Labs）环境的 Active Directory 域名。所有 R&D Labs 环境中的 Windows 和 Linux 实例均加入此域名。 + +## Usage Context +- **环境类型**：R&D Labs（研发实验室） +- **管理方式**：支持 MIM（Microsoft Identity Manager）自助服务工具，安全组管理和权限申请由开发者自助完成 +- **特点**：相比生产环境，R&D 环境更注重开发者自助性和灵活性，而非严格的资源所有权归属 + +## Related Entities +- [[intsas.local]]：生产/SAS 环境的对应 AD 域名 +- [[Gruntwork Landing Zones]]：域名归属的基础架构框架 +- [[MIM (Microsoft Identity Manager)]]：R&D 环境的安全组自助管理工具 +- [[SRE Team]]：维护 AD 域名基础设施的团队 + +## References +- [[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]] diff --git a/wiki/entities/fireworks-tech-graph.md b/wiki/entities/fireworks-tech-graph.md new file mode 100644 index 00000000..2eb3abe4 --- /dev/null +++ b/wiki/entities/fireworks-tech-graph.md @@ -0,0 +1,35 @@ +--- +title: "fireworks-tech-graph" +type: entity +tags: [] +sources: [fireworks-tech-graph] +last_updated: 2026-04-18 +--- + +## Aliases +- fireworks-tech-graph + +## Description +Claude Code Skill，将自然语言描述转化为精美 SVG 技术图，支持 7 种视觉风格和 14 种 UML 图类型，并可通过 `rsvg-convert` 导出高分辨率 PNG。 + +## Type +产品 / Claude Code Skill + +## Role +技术图生成工具 — 为 AI Agent 提供快速生成专业级技术架构图、流程图、UML 图的能力，无需手动绘制 + +## Key Properties +- **GitHub**: github.com/yizhiyanhua-ai/fireworks-tech-graph +- **npm**: www.npmjs.com/package/@yizhiyanhua-ai/fireworks-tech-graph +- **安装方式**: `npx skills add yizhiyanhua-ai/fireworks-tech-graph` +- **依赖**: librsvg（`rsvg-convert` 工具） +- **输出格式**: SVG（可编辑）+ PNG（1920px 视网膜分辨率） +- **风格数量**: 7 种视觉风格 +- **UML 图支持**: 14 种图类型 + +## Relationships +- [[fireworks-tech-graph]] uses [[rsvg-convert]] for PNG export +- [[fireworks-tech-graph]] implements [[7种视觉风格系统]] +- [[fireworks-tech-graph]] implements [[语义形状词汇表]] +- [[fireworks-tech-graph]] implements [[语义箭头系统]] +- [[fireworks-tech-graph]] supports [[14种UML图]] diff --git a/wiki/entities/rsvg-convert.md b/wiki/entities/rsvg-convert.md new file mode 100644 index 00000000..29e4dae0 --- /dev/null +++ b/wiki/entities/rsvg-convert.md @@ -0,0 +1,25 @@ +--- +title: "rsvg-convert" +type: entity +tags: [] +sources: [fireworks-tech-graph] +last_updated: 2026-04-18 +--- + +## Description +librsvg 项目提供的命令行工具，用于将 SVG 文件渲染为高分辨率 PNG 图像。[[fireworks-tech-graph]] 使用它将生成的 SVG 技术图导出为 1920px 视网膜分辨率 PNG。 + +## Type +工具 / 命令行工具 + +## Key Properties +- **包名**: librsvg（macOS）、librsvg2-bin（Ubuntu/Debian） +- **macOS 安装**: `brew install librsvg` +- **Ubuntu/Debian 安装**: `sudo apt install librsvg2-bin` +- **验证**: `rsvg-convert --version` + +## Role +SVG → PNG 转换管道 — 将 AI 生成的 SVG 技术图批量渲染为可发布的 PNG 格式 + +## Relationships +- [[rsvg-convert]] is used_by [[fireworks-tech-graph]] diff --git a/wiki/index.md b/wiki/index.md index 954c2019..11882aab 100644 --- a/wiki/index.md +++ b/wiki/index.md @@ -4,6 +4,33 @@ - [Overview](overview.md) — living synthesis ## Sources +- [2026-04-23] [CTP Topic 40 SaaS Database Architecture On AWS Cloud](sources/ctp-topic-40-saas-database-architecture-on-aws-cloud.md) +- [2026-04-23] [CTP Topic 26 Standard AMI – build, publish, share processes](sources/ctp-topic-26-standard-ami-build-publish-share-processes.md) +- [2026-04-23] [CTP Topic 68 Introduction to Redshift](sources/ctp-topic-68-introduction-to-redshift.md) +- [2026-04-23] [CTP Topic 58 AWS EC2 Image Builder](sources/ctp-topic-58-aws-ec2-image-builder.md) +- [2026-04-23] [CTP Topic 25 Labs Landing Zone Overview - ITOM Teams](sources/ctp-topic-25-labs-landing-zone-overview-itom-teams.md) +- [2026-04-23] [Learning Sessions: Standard AMI Updates 20231205](sources/learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2.md) +- [2026-04-23] [CTP Topic 7 SaaS Landing Zone Design](sources/ctp-topic-7-saas-landing-zone-design.md) +- [2026-04-23] [CTP Topic 34 Azure Landing Zone Architecture Overview](sources/ctp-topic-34-azure-landing-zone-architecture-overview.md) +- [2026-04-23] [CTP Topic 35 AWS Landing Zone Design Refresher (SaaS Labs)](sources/ctp-topic-35-aws-landing-zone-design-refresher-saas-labs.md) +- [2026-04-23] [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-23] [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-23] [CTP Topic 28 AWS Tag Validation Tool](sources/ctp-topic-28-aws-tag-validation-tool.md) +- [2026-04-23] [CTP Topic 47 Enterprise Architecture Cloud Standards](sources/ctp-topic-47-enterprise-architecture-cloud-standards.md) +- [2026-04-23] [CTP Topic 72 Implementing an Enterprise DR Strategy Using AWS Backup](sources/ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup.md) +- [2026-04-23] [CTP Topic 1 Gruntwork Landing Zone Architecture](sources/ctp-topic-1-gruntwork-landing-zone-architecture.md) +- [2026-04-23] [CTP Topic 51 Architecting with AWS Purpose-Built Databases](sources/ctp-topic-51-architecting-with-aws-purpose-built-databases.md) +- [2026-04-23] [CTP Topic 46 NetApps on AWS](sources/ctp-topic-46-netapps-on-aws.md) +- [2026-04-23] [CTP Topic 17 Active Directory Services in Gruntwork AWS LZs](sources/ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs.md) +- [2026-04-23] [CTP Topic 66 Exposing the differences between PostgreSQL RDS and Aurora](sources/ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora.md) +- [2026-04-23] [CTP Topic 14 Octane Hub on AWS Real Life Experience Moving Production Services](sources/ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i.md) +- [2026-04-23] [CTP Topic 44 AWS Backup in Micro Focus](sources/ctp-topic-44-aws-backup-in-micro-focus.md) +- [2026-04-23] [Blogwatcher Daily 技能收藏](sources/blogwatcher-daily收藏.md) +- [2026-04-23] [实战笔记：本地部署 RSSHub 并获取 YouTube 订阅](sources/实战笔记-本地部署-rsshub-并获取-youtube-订阅.md) +- [2026-04-23] [Mac必装软件清单](sources/mac必装软件清单-2026-04-17.md) +- [2026-04-23] [Install WSL](sources/install-wsl.md) +- [2026-04-23] [WSL2 启动与网络配置指南](sources/wsl2-启动与网络配置指南.md) +- [2026-04-23] [fireworks-tech-graph](sources/fireworks-tech-graph.md) - [2026-04-23] [Obsidian 官方 CLI 命令全景速查表](sources/obsidian-官方-cli-命令全景速查表.md) - [2026-04-23] [Obsidian CLI](sources/obsidian-cli.md) - [2026-04-23] [我做了个 Skill：让 AI 帮你生成 Logo 和图标](sources/我做了个-skill-让-ai-帮你生成-logo-和图标.md) @@ -188,7 +215,6 @@ - [2026-04-21] [Cloud DevOp Maturity - Guideline](sources/cloud-devop-maturity-guideline.md) - [2026-04-21] [DevOps Culture and Transformation: Fostering Collaboration, Agile Practices, and Innovation](sources/devops-culture-and-transformation-fostering-collaboration-agile-practices-and-innovation-linkedin.md) - [2026-04-21] [contributing](sources/contributing.md) — (expected: wiki/sources/contributing.md — source missing) -- [2026-04-21] [实战笔记-本地部署-rsshub-并获取-youtube-订阅](sources/实战笔记-本地部署-rsshub-并获取-youtube-订阅.md) — (expected: wiki/sources/实战笔记-本地部署-rsshub-并获取-youtube-订阅.md — source missing) - [2026-04-21] [marketing-weibo-strategist](sources/marketing-weibo-strategist.md) — (expected: wiki/sources/marketing-weibo-strategist.md — source missing) - [2026-04-21] [marketing-baidu-seo-specialist](sources/marketing-baidu-seo-specialist.md) — (expected: wiki/sources/marketing-baidu-seo-specialist.md — source missing) - [2026-04-21] [marketing-carousel-growth-engine](sources/marketing-carousel-growth-engine.md) — (expected: wiki/sources/marketing-carousel-growth-engine.md — source missing) @@ -372,7 +398,7 @@ - [2026-04-19] [public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20](sources/public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20.md) — (expected: wiki/sources/public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20.md — source missing) - [2026-04-19] [public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meet](sources/public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meet.md) — (expected: wiki/sources/public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meet.md — source missing) - [2026-04-19] [ctp-topic-41-nfrs-and-error-budgets](sources/ctp-topic-41-nfrs-and-error-budgets.md) — (expected: wiki/sources/ctp-topic-41-nfrs-and-error-budgets.md — source missing) -- [2026-04-19] [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) — (expected: wiki/sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md — source missing) +- [2026-04-19] [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-19] [ctp-topic-20-program-demand-process-flow-and-poc-onboarding](sources/ctp-topic-20-program-demand-process-flow-and-poc-onboarding.md) — (expected: wiki/sources/ctp-topic-20-program-demand-process-flow-and-poc-onboarding.md — source missing) - [2026-04-19] [ctp-topic-4-using-agile-to-run-the-cloud-transformation-program](sources/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program.md) — (expected: wiki/sources/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program.md — source missing) - [2026-04-19] [ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation](sources/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md) — (expected: wiki/sources/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md — source missing) @@ -387,33 +413,7 @@ - [2026-04-19] [ctp-topic-19-configuring-dns-within-aws-lzs](sources/ctp-topic-19-configuring-dns-within-aws-lzs.md) — (expected: wiki/sources/ctp-topic-19-configuring-dns-within-aws-lzs.md — source missing) - [2026-04-19] [ctp-topic-36-sendgrid-as-an-email-service](sources/ctp-topic-36-sendgrid-as-an-email-service.md) — (expected: wiki/sources/ctp-topic-36-sendgrid-as-an-email-service.md — source missing) - [2026-04-18] [ctp-topic-22-global-dns-service-offerings](sources/ctp-topic-22-global-dns-service-offerings.md) — (expected: wiki/sources/ctp-topic-22-global-dns-service-offerings.md — source missing) -- [2026-04-18] [ctp-topic-50-ami-roadmap-for-aws-amis](sources/ctp-topic-50-ami-roadmap-for-aws-amis.md) — (expected: wiki/sources/ctp-topic-50-ami-roadmap-for-aws-amis.md — source missing) -- [2026-04-18] [ctp-topic-40-saas-database-architecture-on-aws-cloud](sources/ctp-topic-40-saas-database-architecture-on-aws-cloud.md) — (expected: wiki/sources/ctp-topic-40-saas-database-architecture-on-aws-cloud.md — source missing) -- [2026-04-18] [ctp-topic-26-standard-ami-build-publish-share-processes](sources/ctp-topic-26-standard-ami-build-publish-share-processes.md) — (expected: wiki/sources/ctp-topic-26-standard-ami-build-publish-share-processes.md — source missing) -- [2026-04-18] [ctp-topic-68-introduction-to-redshift](sources/ctp-topic-68-introduction-to-redshift.md) — (expected: wiki/sources/ctp-topic-68-introduction-to-redshift.md — source missing) -- [2026-04-18] [ctp-topic-58-aws-ec2-image-builder](sources/ctp-topic-58-aws-ec2-image-builder.md) — (expected: wiki/sources/ctp-topic-58-aws-ec2-image-builder.md — source missing) -- [2026-04-18] [ctp-topic-25-labs-landing-zone-overview-itom-teams](sources/ctp-topic-25-labs-landing-zone-overview-itom-teams.md) — (expected: wiki/sources/ctp-topic-25-labs-landing-zone-overview-itom-teams.md — source missing) -- [2026-04-18] [learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2](sources/learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2.md) — (expected: wiki/sources/learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2.md — source missing) -- [2026-04-18] [ctp-topic-7-saas-landing-zone-design](sources/ctp-topic-7-saas-landing-zone-design.md) — (expected: wiki/sources/ctp-topic-7-saas-landing-zone-design.md — source missing) -- [2026-04-18] [ctp-topic-34-azure-landing-zone-architecture-overview](sources/ctp-topic-34-azure-landing-zone-architecture-overview.md) — (expected: wiki/sources/ctp-topic-34-azure-landing-zone-architecture-overview.md — source missing) -- [2026-04-18] [ctp-topic-35-aws-landing-zone-design-refresher-saas-labs](sources/ctp-topic-35-aws-landing-zone-design-refresher-saas-labs.md) — (expected: wiki/sources/ctp-topic-35-aws-landing-zone-design-refresher-saas-labs.md — source missing) -- [2026-04-18] [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) — (expected: wiki/sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md — source missing) -- [2026-04-18] [ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program](sources/ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program.md) — (expected: wiki/sources/ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program.md — source missing) -- [2026-04-18] [ctp-topic-28-aws-tag-validation-tool](sources/ctp-topic-28-aws-tag-validation-tool.md) — (expected: wiki/sources/ctp-topic-28-aws-tag-validation-tool.md — source missing) -- [2026-04-18] [ctp-topic-47-enterprise-architecture-cloud-standards](sources/ctp-topic-47-enterprise-architecture-cloud-standards.md) — (expected: wiki/sources/ctp-topic-47-enterprise-architecture-cloud-standards.md — source missing) -- [2026-04-18] [ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup](sources/ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup.md) — (expected: wiki/sources/ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup.md — source missing) -- [2026-04-18] [ctp-topic-1-gruntwork-landing-zone-architecture](sources/ctp-topic-1-gruntwork-landing-zone-architecture.md) — (expected: wiki/sources/ctp-topic-1-gruntwork-landing-zone-architecture.md — source missing) -- [2026-04-18] [ctp-topic-51-architecting-with-aws-purpose-built-databases](sources/ctp-topic-51-architecting-with-aws-purpose-built-databases.md) — (expected: wiki/sources/ctp-topic-51-architecting-with-aws-purpose-built-databases.md — source missing) -- [2026-04-18] [ctp-topic-46-netapps-on-aws](sources/ctp-topic-46-netapps-on-aws.md) — (expected: wiki/sources/ctp-topic-46-netapps-on-aws.md — source missing) -- [2026-04-18] [ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs](sources/ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs.md) — (expected: wiki/sources/ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs.md — source missing) -- [2026-04-18] [ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora](sources/ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora.md) — (expected: wiki/sources/ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora.md — source missing) -- [2026-04-18] [ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i](sources/ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i.md) — (expected: wiki/sources/ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i.md — source missing) -- [2026-04-18] [ctp-topic-44-aws-backup-in-micro-focus](sources/ctp-topic-44-aws-backup-in-micro-focus.md) — (expected: wiki/sources/ctp-topic-44-aws-backup-in-micro-focus.md — source missing) -- [2026-04-18] [blogwatcher-daily收藏](sources/blogwatcher-daily收藏.md) — (expected: wiki/sources/blogwatcher-daily收藏.md — source missing) -- [2026-04-18] [mac必装软件清单-2026-04-17](sources/mac必装软件清单-2026-04-17.md) — (expected: wiki/sources/mac必装软件清单-2026-04-17.md — source missing) -- [2026-04-18] [install-wsl](sources/install-wsl.md) — (expected: wiki/sources/install-wsl.md — source missing) -- [2026-04-18] [wsl2-启动与网络配置指南](sources/wsl2-启动与网络配置指南.md) — (expected: wiki/sources/wsl2-启动与网络配置指南.md — source missing) -- [2026-04-18] [fireworks-tech-graph](sources/fireworks-tech-graph.md) — (expected: wiki/sources/fireworks-tech-graph.md — source missing) +- [2026-04-14] [CTP Topic 50 AMI Roadmap for AWS AMIs](sources/ctp-topic-50-ami-roadmap-for-aws-amis.md) — CCOE AMI 路线图与 AWS 标准 AMI 生命周期规划 - [Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog](sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md) — (expected: wiki/sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md — source missing) - [Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend](sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md) — (expected: wiki/sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md — source missing) - [zk-steward](sources/zk-steward.md) — (expected: wiki/sources/zk-steward.md — source missing) @@ -543,8 +543,17 @@ - [Alertmanager](entities/Alertmanager.md) - [Alex-Ewerlof](entities/Alex-Ewerlof.md) - [Alex-Finn](entities/Alex-Finn.md) +- [Amazon-Aurora](entities/Amazon-Aurora.md) - [Amazon-CloudWatch-Logs](entities/Amazon-CloudWatch-Logs.md) +- [Amazon-DocumentDB](entities/Amazon-DocumentDB.md) +- [Amazon-DynamoDB](entities/Amazon-DynamoDB.md) +- [Amazon-ElastiCache](entities/Amazon-ElastiCache.md) - [Amazon-EventBridge](entities/Amazon-EventBridge.md) +- [Amazon-Keyspaces](entities/Amazon-Keyspaces.md) +- [Amazon-Neptune](entities/Amazon-Neptune.md) +- [Amazon-RDS](entities/Amazon-RDS.md) +- [Amazon-Redshift](entities/Amazon-Redshift.md) +- [Amazon-Timestream](entities/Amazon-Timestream.md) - [Andrej-Karpathy](entities/Andrej-Karpathy.md) - [Anthropic](entities/Anthropic.md) - [Apache-Superset](entities/Apache-Superset.md) @@ -565,6 +574,7 @@ - [Calibre](entities/Calibre.md) - [Canva](entities/Canva.md) - [ChatGPT](entities/ChatGPT.md) +- [Checkpoint](entities/Checkpoint.md) - [Choi-Wontak](entities/Choi-Wontak.md) - [Claude-Desktop](entities/Claude-Desktop.md) - [Claude-Pro](entities/Claude-Pro.md) @@ -599,6 +609,7 @@ - [DORA-Metrics](entities/DORA-Metrics.md) - [DracoVibeCoding](entities/DracoVibeCoding.md) - [EESJGong](entities/EESJGong.md) +- [fireworks-tech-graph](entities/fireworks-tech-graph.md) - [Flux](entities/Flux.md) - [frp](entities/frp.md) - [Gamma-AI](entities/Gamma-AI.md) @@ -611,6 +622,7 @@ - [Google-Cloud](entities/Google-Cloud.md) - [GoogleCloud](entities/GoogleCloud.md) - [Grafana](entities/Grafana.md) +- [Gruntwork](entities/Gruntwork.md) - [hello-world](entities/hello-world.md) - [HemantSawant](entities/HemantSawant.md) - [HIPAA](entities/HIPAA.md) @@ -620,6 +632,7 @@ - [IBM](entities/IBM.md) - [idea-reality-mcp](entities/idea-reality-mcp.md) - [InsightsLM](entities/InsightsLM.md) +- [Intsas.local](entities/Intsas.local.md) - [ISO-27001](entities/ISO-27001.md) - [it-tools](entities/it-tools.md) - [Jellyfin](entities/Jellyfin.md) @@ -649,6 +662,7 @@ - [n8n-mcp](entities/n8n-mcp.md) - [Nano Banana 2](entities/Nano Banana 2.md) - [Navidrome](entities/Navidrome.md) +- [NetApp](entities/NetApp.md) - [Netdata](entities/Netdata.md) - [NicholasCarlini](entities/NicholasCarlini.md) - [node-exporter](entities/node-exporter.md) @@ -657,6 +671,7 @@ - [NotebookLlama](entities/NotebookLlama.md) - [NotebookLM](entities/NotebookLM.md) - [Obsidian](entities/Obsidian.md) +- [Octane-Hub](entities/Octane-Hub.md) - [Ollama](entities/Ollama.md) - [Open-Alliance-for-Cloud-Adoption](entities/Open-Alliance-for-Cloud-Adoption.md) - [Open-WebUI](entities/Open-WebUI.md) @@ -681,17 +696,21 @@ - [Raj-Vardhan-Singh](entities/Raj-Vardhan-Singh.md) - [Recapio](entities/Recapio.md) - [RichardFeynman](entities/RichardFeynman.md) +- [rsvg-convert](entities/rsvg-convert.md) - [rsync](entities/rsync.md) - [Rufus](entities/Rufus.md) - [RustDesk](entities/RustDesk.md) - [shenwei](entities/shenwei.md) - [Simon-Hoiberg](entities/Simon-Hoiberg.md) - [Slack](entities/Slack.md) +- [SMACKS](entities/SMACKS.md) - [SONY](entities/SONY.md) - [SparkryAI](entities/SparkryAI.md) +- [SRE-Team](entities/SRE-Team.md) - [Stable-Diffusion](entities/Stable-Diffusion.md) - [stacer](entities/stacer.md) - [SurfSense](entities/SurfSense.md) +- [Swinford.net](entities/Swinford.net.md) - [Synology-NAS-DS718](entities/Synology-NAS-DS718.md) - [Telnyx](entities/Telnyx.md) - [Terraform](entities/Terraform.md) @@ -722,6 +741,8 @@ - [苏东坡](entities/苏东坡.md) ## Concepts +- [14种UML图](concepts/14种UML图.md) +- [7种视觉风格系统](concepts/7种视觉风格系统.md) - [ActionItemTracking](concepts/ActionItemTracking.md) - [Active-Accountability](concepts/Active-Accountability.md) - [Adaptive-Tone](concepts/Adaptive-Tone.md) @@ -759,6 +780,8 @@ - [Automated-Health-Logging](concepts/Automated-Health-Logging.md) - [Automated-Security-Audit](concepts/Automated-Security-Audit.md) - [Availability](concepts/Availability.md) +- [AWS-Tagging-Standards](concepts/AWS-Tagging-Standards.md) +- [AWS-Tags](concepts/AWS-Tags.md) - [BindMount](concepts/BindMount.md) - [BI平台](concepts/BI平台.md) - [Blue-Green-Deployment](concepts/Blue-Green-Deployment.md) @@ -802,6 +825,7 @@ - [Cloud-Service-Delivery](concepts/Cloud-Service-Delivery.md) - [CMDB](concepts/CMDB.md) - [CodeWeaver](concepts/CodeWeaver.md) +- [Columnar-Storage](concepts/Columnar-Storage.md) - [Compaction](concepts/Compaction.md) - [Competition-Analysis](concepts/Competition-Analysis.md) - [Compliance-Automation](concepts/Compliance-Automation.md) @@ -829,6 +853,7 @@ - [DAST](concepts/DAST.md) - [Data-Governance](concepts/Data-Governance.md) - [Data-Sovereignty](concepts/Data-Sovereignty.md) +- [DBA-Role-Evolution](concepts/DBA-Role-Evolution.md) - [Defense-in-Depth](concepts/Defense-in-Depth.md) - [Defuddle](concepts/Defuddle.md) - [Deployment-Automation](concepts/Deployment-Automation.md) @@ -839,6 +864,7 @@ - [DevSecOps](concepts/DevSecOps.md) - [DNS托管](concepts/DNS托管.md) - [Docker-Compose](concepts/Docker-Compose.md) +- [Docker-Containerization](concepts/Docker-Containerization.md) - [Docker-LLM-Deployment](concepts/Docker-LLM-Deployment.md) - [Docker-用户组](concepts/Docker-用户组.md) - [Docker堆栈](concepts/Docker堆栈.md) @@ -852,6 +878,7 @@ - [Earnings-Beat-Miss](concepts/Earnings-Beat-Miss.md) - [Earnings-Calendar](concepts/Earnings-Calendar.md) - [efibootmgr](concepts/efibootmgr.md) +- [EFS-vs-EBS](concepts/EFS-vs-EBS.md) - [Email-Triage](concepts/Email-Triage.md) - [Error-Accountability](concepts/Error-Accountability.md) - [Error-Budget](concepts/Error-Budget.md) @@ -865,6 +892,7 @@ - [Failover](concepts/Failover.md) - [Feature-Flag](concepts/Feature-Flag.md) - [FeatureList](concepts/FeatureList.md) +- [Federated-Access](concepts/Federated-Access.md) - [File-System-First-UI](concepts/File-System-First-UI.md) - [File-Watcher](concepts/File-Watcher.md) - [FinOps](concepts/FinOps.md) @@ -915,6 +943,7 @@ - [Kill-Switch](concepts/Kill-Switch.md) - [Knock-out-Pattern](concepts/Knock-out-Pattern.md) - [Knowledge-Base-RAG](concepts/Knowledge-Base-RAG.md) +- [Landing-Zone-Architecture](concepts/Landing-Zone-Architecture.md) - [LangChain](concepts/LangChain.md) - [Language-Detection](concepts/Language-Detection.md) - [Large-Language-Model](concepts/Large-Language-Model.md) @@ -939,6 +968,7 @@ - [Model-Context-Protocol](concepts/Model-Context-Protocol.md) - [Model-Fallback](concepts/Model-Fallback.md) - [Morning-Briefing](concepts/Morning-Briefing.md) +- [MPP](concepts/MPP.md) - [MTTA](concepts/MTTA.md) - [MTTD](concepts/MTTD.md) - [MTTR](concepts/MTTR.md) @@ -947,6 +977,7 @@ - [Multi-AI-Review](concepts/Multi-AI-Review.md) - [Multi-Channel-Delivery](concepts/Multi-Channel-Delivery.md) - [Multi-Cloud-Strategy](concepts/Multi-Cloud-Strategy.md) +- [Multi-Database-Architecture](concepts/Multi-Database-Architecture.md) - [Multi-factor-Authentication](concepts/Multi-factor-Authentication.md) - [Multi-Tenancy](concepts/Multi-Tenancy.md) - [nas套件管理](concepts/nas套件管理.md) @@ -988,6 +1019,7 @@ - [proxychains](concepts/proxychains.md) - [Public-Cloud](concepts/Public-Cloud.md) - [PUID-PGID](concepts/PUID-PGID.md) +- [Purpose-Built-Databases](concepts/Purpose-Built-Databases.md) - [Quality-Scoring-Algorithm](concepts/Quality-Scoring-Algorithm.md) - [RAG](concepts/RAG.md) - [Reality-Signal](concepts/Reality-Signal.md) @@ -996,6 +1028,7 @@ - [Recurring-Tasks](concepts/Recurring-Tasks.md) - [Recursive-Self-Optimization](concepts/Recursive-Self-Optimization.md) - [Redis缓存](concepts/Redis缓存.md) +- [Reference-Architecture](concepts/Reference-Architecture.md) - [Release-Management](concepts/Release-Management.md) - [Reliability-Engineering](concepts/Reliability-Engineering.md) - [Remote-SSH](concepts/Remote-SSH.md) @@ -1033,12 +1066,14 @@ - [Semantic-Search](concepts/Semantic-Search.md) - [Sequential-Thinking](concepts/Sequential-Thinking.md) - [Serverless-Computing](concepts/Serverless-Computing.md) +- [Service-Control-Policies-SCPs](concepts/Service-Control-Policies-SCPs.md) - [Shared-Memory-Architecture](concepts/Shared-Memory-Architecture.md) - [Shared-Responsibility-Model](concepts/Shared-Responsibility-Model.md) - [SharedStateCoordination](concepts/SharedStateCoordination.md) - [Shift-Left-Security](concepts/Shift-Left-Security.md) - [Shift-Right-Security](concepts/Shift-Right-Security.md) - [Single-Control-Plane](concepts/Single-Control-Plane.md) +- [SnapMirror](concepts/SnapMirror.md) - [Social-Media-Monitoring](concepts/Social-Media-Monitoring.md) - [Socket-登录](concepts/Socket-登录.md) - [SOCKS5代理](concepts/SOCKS5代理.md) @@ -1056,12 +1091,14 @@ - [System-Economy](concepts/System-Economy.md) - [system-monitoring](concepts/system-monitoring.md) - [systemd](concepts/systemd.md) +- [Tag-Validation-Tool](concepts/Tag-Validation-Tool.md) - [Task-Query](concepts/Task-Query.md) - [TaskAutomation](concepts/TaskAutomation.md) - [Taylorism](concepts/Taylorism.md) - [TCP隧道](concepts/TCP隧道.md) - [Telegram-Trigger](concepts/Telegram-Trigger.md) - [Telephony-Integration](concepts/Telephony-Integration.md) +- [Terraform-Modules](concepts/Terraform-Modules.md) - [Test-Mode](concepts/Test-Mode.md) - [Text-and-Search](concepts/Text-and-Search.md) - [Threat-Modeling](concepts/Threat-Modeling.md) @@ -1083,6 +1120,7 @@ - [UEFI启动](concepts/UEFI启动.md) - [Unified-Inbox](concepts/Unified-Inbox.md) - [USER.md](concepts/USER.md.md) +- [Variables-YAML](concepts/Variables-YAML.md) - [Vector-Embedding](concepts/Vector-Embedding.md) - [Vendor-Lock-In](concepts/Vendor-Lock-In.md) - [Vibe-Coding](concepts/Vibe-Coding.md) @@ -1135,6 +1173,7 @@ - [底层能力](concepts/底层能力.md) - [微服务架构](concepts/微服务架构.md) - [思维蒸馏（女娲造人术）](concepts/思维蒸馏（女娲造人术）.md) +- [技术图生成](concepts/技术图生成.md) - [挂载点检查](concepts/挂载点检查.md) - [指纹浏览器](concepts/指纹浏览器.md) - [接码平台](concepts/接码平台.md) @@ -1161,7 +1200,9 @@ - [裸机恢复](concepts/裸机恢复.md) - [订阅机制](concepts/订阅机制.md) - [设备直通](concepts/设备直通.md) +- [语义形状词汇表](concepts/语义形状词汇表.md) - [语义搜索](concepts/语义搜索.md) +- [语义箭头系统](concepts/语义箭头系统.md) - [账号隔离](concepts/账号隔离.md) - [超级个体](concepts/超级个体.md) - [跨境支付](concepts/跨境支付.md) diff --git a/wiki/log.md b/wiki/log.md index e6ad2b2a..998d52fe 100644 --- a/wiki/log.md +++ b/wiki/log.md @@ -1,3 +1,298 @@ +## [2026-04-26] ingest | CTP Topic 50 AMI Roadmap for AWS AMIs +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-50-ami-roadmap-for-aws-amis.md +- Status: ✅ 成功摄入 +- Summary: 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 清单及未来路线图。自 2023 年 5 月起所有 ARM AMI 同步发布。路线图优先级主要由 ADM 需求驱动，变更需通过需求管道流程提交。AMI 通过跨账号共享分发给组织内所有账户。 +- Concepts touched: Foundation AMI、OS-End-of-Life、AMI Sharing、ARM-AMI、CCOE、ADM、SSM Agent +- Entities touched: CCOE、AWS、Ubuntu、CentOS、Rocky Linux、Red Hat Enterprise Linux、SLES、Windows Server、McAfee +- Source page: wiki/sources/ctp-topic-50-ami-roadmap-for-aws-amis.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/ctp-topic-50-ami-roadmap-for-aws-amis.md） + - 所有 Concepts 和 Entities 均以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值） + - index.md 更新：Sources 节替换预期占位符为正式条目（日期修正为 2026-04-14） + - overview.md 更新：新增 CTP Topic 50 摘要段落（置于 learning-sessions-standard-amis-updates 之后，ctp-topic-26 之前） + - 冲突检测：与 [[learning-sessions-standard-amis-updates]] 的 EOL 时间线一致（CentOS 7/RHEL 7 将于 2024 年 6 月 EOL）；与 [[ctp-topic-26-standard-ami-build-publish-share-processes]] 存在描述角度差异（本话题聚焦路线图规划，Topic 26 聚焦生命周期管理），非矛盾而是互补关系，已记录于 Source Page Contradictions 节 + +## [2026-04-24] 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: SAS 数据库团队在 AWS 云上的架构与运维实践——全球分布式团队（美国/加拿大/印度/以色列）提供 24/7 支持，管理 500+ 数据库和 1000+ DB 服务器；支持 Oracle、Vertica、Postgres、DynamoDB、SQL Server、MongoDB、MySQL 等多引擎；高可用架构采用三可用区模式（主库/备用库/见证节点）；使用 Oracle Data Guard、Postgres Active-Passive/Active-Active、RDS HA 实现多活；通过 Terraform、AWS CLI、Shell/PowerShell 实现 IaC 自动化；Oracle GoldenGate 支持零停机迁移 +- Concepts created: 无新增（高可用/Oracle Data Guard/Multi-AZ Deployment/Database Migration/DB-as-a-Service 各仅出现 1-2 次，不满足 ≥2 次建页条件，跳过独立建页） +- Entities created: 无新增（AWS/RDS/Aurora/Terraform/Micro Focus 各仅出现 1-2 次，不满足 ≥2 次条件，跳过独立建页） +- Source page: wiki/sources/ctp-topic-40-saas-database-architecture-on-aws-cloud.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/ctp-topic-40-saas-database-architecture-on-aws-cloud.md） + - 所有 Concepts 和 Entities 均以 wikilink 形式建立关联，暂不创建独立页面（未达 ≥2 次阈值） + - index.md 更新：Sources 节新增条目（置顶） + - overview.md 更新：新增 CTP Topic 40 摘要段落（置于 ctp-topic-10 之后，ctp-topic-46 之前）；Key Concepts 列表新增 Database Migration + - 冲突检测：无明显冲突内容 + +## [2026-04-26] 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: ✅ 成功摄入 +- Summary: Foundation AMI 全生命周期管理详解——基于市场主流 OS（CentOS/Ubuntu/Windows）进行 CIS 安全基准加固；集成 McAfee EPO + Syslog-ng + AD SSO + SSM Agent + SiteScope；HashiCorp Packer + Jenkins 流水线实现全自动化；跨账号 AMI Sharing 分发至全球多区域（俄勒冈/法兰克福/悉尼）；每两个月更新，N-2 版本保留策略；责任共担模型（CCOE 提供 Foundation AMI，产品团队构建产品特定 AMI） +- Concepts created: 无新增（Foundation AMI/OS Hardening/CIS Benchmarks/HashiCorp Packer/SSM Agent/AMI Sharing/Central Repository 各仅出现 1 次，不满足 ≥2 次建页条件，跳过独立建页） +- Entities created: 无新增（Srihari/Alan/Praveen 各仅出现 1 次，不满足 ≥2 次条件；CCOE 仅出现 1 次） +- Source page: wiki/sources/ctp-topic-26-standard-ami-build-publish-share-processes.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/ctp-topic-26-standard-ami-build-publish-share-processes.md） + - 7 个 Concept 均以 wikilink 形式建立关联，暂不创建独立页面（未达 ≥2 次阈值） + - index.md 更新：Sources 节替换预期条目占位符为正式条目（日期修正为 2026-04-14） + - overview.md 更新：新增 CTP Topic 26 摘要段落（置于 learning-sessions-standard-amis-updates 之后，替换原 ctp-topic-58 段落位置）；Key Concepts 列表新增 Foundation AMI / OS Hardening / CIS Benchmarks / AMI Sharing / Central Repository + - 冲突检测：与 [[ctp-topic-58-aws-ec2-image-builder]] 描述不同 AMI 生命周期阶段——ctp-topic-26 描述当前 Packer+Jenkins 生产实践，ctp-topic-58 描述 EC2 Image Builder 未来演进方向，非冲突而是演进关系，已记录于 Source Page Contradictions 节 + +## [2026-04-23] 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 + Compute Node + Slices）、MPP 并行处理、列式存储 vs 行式存储、数据压缩（ZSTD/LZO）、Sort Key / Distribution Key 优化、RA3 实例类型（AWS 托管 NVMe） +- Concepts created: [[MPP]], [[Columnar-Storage]] +- Entities created: [[Amazon-Redshift]] +- Source page: wiki/sources/ctp-topic-68-introduction-to-redshift.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/ctp-topic-68-introduction-to-redshift.md） + - 新增 1 个 Entity Page（wiki/entities/Amazon-Redshift.md） + - 新增 2 个 Concept Page（wiki/concepts/MPP.md、wiki/concepts/Columnar-Storage.md） + - index.md 更新：Sources 节移除预期占位符（"source missing"）替换为正式条目；Entities 节新增 Amazon-Redshift；Concepts 节新增 MPP、Columnar-Storage + - overview.md 更新：新增 CTP Topic 68 摘要段落（置于 ctp-topic-51 之后）；Key Concepts 列表新增 Data-Warehouse、MPP、Columnar-Storage、Sort-Key、Distribution-Key + - 冲突检测：与 [[ctp-topic-66-rds-vs-aurora]] 存在架构差异（Redshift 独立 Compute Node vs Aurora 共享存储），记录于 Source Page 的 Contradictions 节 + - Sort Key 和 Distribution Key 概念因在其他页面中暂未出现，本次不创建独立页面 + +## [2026-04-14] 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 替代 Packer/Jenkins 实现企业级 AMI 生命周期自动化——通过 Pipeline/Recipe/Component/Infrastructure Config 四层抽象，将 CCOE 加固脚本转换为可复用组件；POC 实现 CentOS 7 和 Ubuntu 18 端到端流水线；Lambda 工作流触发 AWS Inspector 扫描、邮件通知和 S3 报告归档 +- Concepts identified: [[Golden-AMI]], [[CCOE]], [[Image-Pipeline]], [[Image-Recipe]], [[Image-Component]], [[Infrastructure-Configuration]], [[Distribution-Settings]], [[AWS-Inspector]] +- Entities identified: [[AWS]]（仅出现 1 次，不满足 ≥2 次建页条件，跳过独立建页） +- Source page: wiki/sources/ctp-topic-58-aws-ec2-image-builder.md +- Notes: + - 新增 1 个 Source Page + - 新增 8 个 Concept，均仅出现 1 次，不满足 ≥2 次建页条件，本次不创建独立页面 + - AWS Entity 页面已存在于 wiki/entities/（Amazon-RDS.md 等系列页面），本次复用 + - index.md 更新：Sources 节替换预期条目占位符为正式条目（日期修正为 2026-04-14） + - overview.md 更新：新增 CTP Topic 58 摘要段落（置于 learning-sessions-standard-amis-updates 之后） + - 冲突检测：与 [[ctp-topic-26-standard-ami-build-publish-share-processes]] 描述不同 AMI 生命周期阶段，非冲突，记录于 Source Page 的 Contradictions 节 + +## [2023-12-05] 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: ✅ 成功摄入 +- Summary: AWS 标准 AMI 更新机制与生命周期管理——标准 AMI 基于 AWS 原生镜像增加 OS 加固、安全补丁、SSM Agent、QALIS Agent；Jenkins 多分支流水线构建测试 AMI，将验证周期从 3-4 天缩短至 60 分钟；支持 23 种 AMI 涵盖 Amazon Linux/CentOS/OEL/RHEL/Rocky Linux/SUSE/Ubuntu/Windows；机器人框架自动化验证为核心优化手段；CentOS 7/RHEL 7 将于 2024 年 6 月 EOL，由 Rocky Linux 替代；SSM 打补丁方案适用于长期运行实例。 +- Concepts identified: [[Amazon-Machine-Image]], [[Jenkins-Multi-Branch-Pipeline]], [[AWS-Inspector]], [[Robotic-Framework]], [[SSM-Patching]], [[GP3-EBS-Storage]], [[OS-End-of-Life]] +- Entities identified: [[Rocky-Linux]], [[Sentinel-1]]（均仅出现 1 次，不满足 ≥2 次建页条件，跳过独立建页） +- Source page: wiki/sources/learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2.md +- Notes: + - 新增 1 个 Source Page + - 新增 overview.md 条目，置于 CTP Topic 7 之前（按日期 2023-12-05 排序） + - 7 个 Concept 均仅出现 1 次，不满足 ≥2 次建页条件，本次不创建独立 Concept 页面 + - 无内容冲突 + +## [2026-04-23] 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: ✅ 成功摄入 +- Summary: SAS（生产）Landing Zone 顶层设计——采用单一 Landing Zone 承载所有产品组；定义四层账户体系（Core Accounts: Shared/Logs/Security；Baseline Accounts: Network/DNS/AD；Shared Services Accounts: Software Factory/Cyber/ARC/Monitoring；Product Accounts）；Terraform IaC + GitHub/Jenkins CI/CD 端到端自动化部署链路（GitHub Hook → Jenkins → Management VPC → Lambda → ECS Cluster）；工作负载置于私有子网，WAF + CloudFront 提供入站安全；远程接入从 Checkpoint VPN 迁移至 Pulse VPN（AD 认证）。 +- Concepts identified: [[Landing-Zone-Architecture]], [[Active-Directory-Integration]], [[Transit-Gateway]], [[WAF-Web-Application-Firewall]], [[Private-Subnet-Architecture]], [[Terraform-IaC]] +- Entities identified: [[Gruntwork]], [[Jenkins]], [[Checkpoint]], [[CloudFront]], [[Qalis]], [[OBM]]（均仅出现 1 次，不满足 ≥2 次建页条件，跳过独立建页） +- Source page: wiki/sources/ctp-topic-7-saas-landing-zone-design.md +- Notes: + - 新增 1 个 Source Page + - 新增 6 个 Concept（Landing-Zone-Architecture/Active-Directory-Integration/Transit-Gateway/WAF-Web-Application-Firewall/Private-Subnet-Architecture/Terraform-IaC），均仅出现 1 次，不满足 ≥2 次建页条件，本次不创建独立页面 + - 新增 6 个 Entity（Gruntwork/Jenkins/Checkpoint/CloudFront/Qalis/OBM），均仅出现 1 次，不满足 ≥2 次条件，跳过独立建页 + - Gruntwork、Checkpoint Entity 页面已存在于 wiki/entities/，本次复用 + - Landing-Zone-Architecture Concept 页面已存在于 wiki/concepts/，本次复用 + - index.md 更新：Sources 节替换预期条目占位符为正式条目 + - overview.md 更新：新增 CTP Topic 7 摘要段落（置于 ctp-topic-1 之前） + - 冲突检测：与 [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] 存在时间维度的架构演进关系（非冲突）——ctp-topic-7 定义原始设计，ctp-topic-35 补充近期变更（网络分段、Pulse VPN 替换 Checkpoint VPN），记录于 Source Page 的 Contradictions 节 + +## [2026-04-14] 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: Kishore Garlopati 讲解 Azure Landing Zone 在 Micro Focus 的实施架构。核心：Azure Enterprise Enrollment → 管理组（Management Groups）四层分级（Platform/Landing Zones/Decommission/Sandbox）→ 独立订阅隔离目的 → Terraform Cloud IaC 自动化。Platform 层含 Identity 和 Connectivity 两个独立订阅；Connectivity 订阅作为中心枢纽汇聚所有入站/出站 Azure 流量（含 DDoS 防护和 Checkpoint 防火墙）；Landing Zones 设计为可扩展、模块化、全自动化；Terraform Cloud 管理跨订阅依赖；PIM/PAG 实现精细化访问控制。 +- Concepts identified: [[Azure Landing Zone]], [[Management Groups]], [[Terraform Cloud]], [[Privileged Identity Management (PIM)]], [[Privileged Access Groups]] +- Source page: wiki/sources/ctp-topic-34-azure-landing-zone-architecture-overview.md +- Notes: + - 新增 1 个 Source Page + - 新增 5 个 Concept（Azure Landing Zone / Management Groups / Terraform Cloud / Privileged Identity Management (PIM) / Privileged Access Groups），均仅出现 1 次，不满足 ≥2 次建页条件，本次不创建独立页面 + - 新增 1 个 Entity（Kishore Garlopati），仅出现 1 次，不满足 ≥2 次条件，本次不创建独立页面 + - index.md 更新：Sources 节替换预期条目占位符为正式条目 + - overview.md 更新：Cloud Transformation & DevOps 节新增 Azure Landing Zone 概念标注 + - 无冲突检测到 + - 本文档原状态为"🟡 Awaiting Whisper transcription → Summary"，现已摄入完成 + +## [2026-04-23] 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: ✅ 成功摄入 +- Summary: AWS Landing Zone 设计复习，明确 SaaS（生产）与 Labs（开发）的职责划分。SaaS LZ 为每个产品区域提供客户专属产品账户，连接共享服务账户（安全、日志、网络）；核心账户组含 AD、DNS、Network 账户；Gruntwork 账户跨所有账户管理 AMI、日志和安全。近期变更：网络分段阻断 SaaS 工作负载直接连通性；CCOEs CloudTrail 取代 Gruntworks CloudTrail；入站流量通过 Network 账户 Checkpoint 重新路由；AWS Backup 有望强制化；新账户可能取消 Management VPC。核心结论：SaaS = 生产，Labs = 开发；PoC LZ 并入 Labs。 +- Concepts created: [[AWS-Landing-Zone]], [[Gruntwork]], [[Shared-Services-Account]], [[Core-Accounts]], [[Product-Accounts]], [[Gruntwork-Accounts]], [[CCOEs-CloudTrail]], [[Network-Segmentation]] +- Source page: wiki/sources/ctp-topic-35-aws-landing-zone-design-refresher-saas-labs.md +- Notes: + - 新增 1 个 Source Page + - 新增 8 个 Concept（AWS-Landing-Zone/Gruntwork/Shared-Services-Account/Core-Accounts/Product-Accounts/Gruntwork-Accounts/CCOEs-CloudTrail/Network-Segmentation） + - 新增 1 个 Entity（Cloud-Technology-Design-Forum，仅在本文档提及，不满足 ≥2 次条件，跳过独立建页） + - overview.md 更新：新增 CTP Topic 35 摘要段落（置于 ctp-topic-1 之前） + - index.md 更新：Sources 节替换预期条目占位符为正式条目 + - 无冲突检测到 + +## [2026-04-14] ingest | CTP Topic 47 Enterprise Architecture Cloud Standards +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-47-enterprise-architecture-cloud-standards.md +- Status: ✅ 成功摄入 +- Summary: Lindsay 分享企业架构云标准。核心：Landing Zone 框架聚焦安全、合规和可管理性；账户结构与环境和角色对齐，零信任+最小权限原则；Terraform/Terragrunt 实现 IaC 标准化；云防护栏文档捕获强制性要求和最佳实践；功能分区将单体应用拆分为更小的独立模块或无服务器函数；强调需要应用团队输入完善防护栏。 +- Concepts created: [[Landing Zone]], [[Cloud Guardrails]], [[Functional Partitioning]] +- Source page: wiki/sources/ctp-topic-47-enterprise-architecture-cloud-standards.md +- Notes: + - 新增 1 个 Source Page + - 新增 3 个 Concept（Landing Zone / Cloud Guardrails / Functional Partitioning） + - overview.md 更新：新增 CTP Topic 47 摘要段落（置于 ctp-topic-17 之后） + - 无 Entity 创建（Lindsay 仅出现 1 次，不满足 ≥2 次条件） + - 无冲突检测到 + +## [2026-04-14] ingest | CTP Topic 72 Implementing an Enterprise DR Strategy Using AWS Backup +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup.md +- Status: ✅ 成功摄入 +- Summary: AWS 解决方案架构师 Sabith 深入讲解企业级灾难恢复策略与 AWS Backup 架构设计。核心：HA（高可用）关注运行时间和 MTBF，DR（灾难恢复）专注防止数据丢失；RPO/RTO 定义恢复目标；AWS Backup 集中化、基于策略，支持跨账户跨区域复制；四级 DR 架构模式（Backup and Restore → Pilot Light → Warm Standby → Active-Active）；增量备份节省成本；Vault Lock 合规模式防勒索软件；Bunker Account + Forensic Account 增强隔离性和测试验证。 +- Concepts created: [[高可用（High Availability）]], [[灾难恢复架构模式]], [[Vault Lock]], [[跨账户备份]], [[增量备份]], [[全量备份]], [[AWS Backup Audit Manager]] +- Source page: wiki/sources/ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup.md +- Notes: + - 新增 1 个 Source Page + - 新增 7 个 Concept（高可用/灾难恢复架构模式/Vault Lock/跨账户备份/增量备份/全量备份/AWS Backup Audit Manager） + - overview.md 更新：新增 CTP Topic 72 摘要段落（置于 ctp-topic-17 之后），Key Concepts 节新增 7 个概念标注 + - index.md 更新：Sources 节新增条目（置顶于 ctp-topic-28 之前），并删除预期条目占位符 + - 冲突检测：与 [[ctp-topic-44-aws-backup-in-micro-focus]] 互补而非冲突，Topic 72 提供理论框架，Topic 44 提供内部评估视角，构成完整 AWS Backup 知识体系 + - 与 [[ctp-topic-44-aws-backup-in-micro-focus]] 和 [[ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program]] 三者构成递进关系（理论基础 → 内部评估 → 迁移实施） + +## [2026-04-23] ingest | CTP Topic 51 Architecting with AWS Purpose-Built Databases +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-51-architecting-with-aws-purpose-built-databases.md +- Status: ✅ 成功摄入 +- Summary: AWS 数据库专家 Femi George 分享专用数据库选型与架构原则。核心：现代应用"为正确的工作选择正确的专用数据库"，避免一刀切。AWS 提供完整数据库品类（关系型/NoSQL/键值/文档/宽列/内存/图/时序）。实战案例：Duolingo 用 DynamoDB + ElastiCache + Aurora；Netflix 用 DynamoDB 做高弹性 JSON；Peloton 用 ElastiCache Redis 即时反馈。云时代 DBA 从平台管理转向应用创新。 +- Entities created: Amazon-DynamoDB, Amazon-DocumentDB, Amazon-ElastiCache, Amazon-Keyspaces, Amazon-Neptune, Amazon-Timestream +- Concepts created: Purpose-Built-Databases, DBA-Role-Evolution, Multi-Database-Architecture +- Source page: wiki/sources/ctp-topic-51-architecting-with-aws-purpose-built-databases.md +- Notes: + - 新增 1 个 Source Page + - 新增 6 个 Entity（Amazon-DynamoDB/ElastiCache/Neptune/Timestream/Keyspaces/DocumentDB） + - 新增 3 个 Concept（Purpose-Built-Databases / DBA-Role-Evolution / Multi-Database-Architecture） + - overview.md 更新：新增 CTP Topic 51 摘要段落，置于 ctp-topic-66 之前 + - index.md 更新：Sources 节替换预期条目为实际摘要，Entities 节新增 6 个实体，Concepts 节新增 3 个概念 + - 冲突检测：与 [[ctp-topic-66-rds-vs-aurora]] 视角互补而非冲突，已记录于 Source Page Contradictions 节 + +## [2026-04-23] ingest | CTP Topic 46 NetApps on AWS +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-46-netapps-on-aws.md +- Status: ✅ 成功摄入 +- Summary: Sandeep 和 Yael 主讲的 NetApp 存储系统培训。覆盖传统 NetApp 架构（ONTAP / Aggregate / FlexVol / Qtree / LUN / LIF / SVM）和 AWS 云版本 CVO。CVO 通过 EC2 实例提供软件定义存储，支持单节点或 HA 配对（跨多 AZ 同步复制）；数据分层机制将 30 天非活跃数据从 EBS 自动迁移到 S3；SnapMirror 实现块级跨集群复制；迁移工具包括 SnapMirror、NetApp XCP、Cloud Sync、AWS DataSync。组织已在 15 个 AWS 区域部署约 1.3 PB 数据。 +- Concepts created: [[SnapMirror]] +- Entities created: [[NetApp]] +- Source page: wiki/sources/ctp-topic-46-netapps-on-aws.md +- Notes: + - 新增 1 个 Source Page + - 新增 1 个 Entity（NetApp） + - 新增 1 个 Concept（SnapMirror） + - overview.md 更新：新增 CTP Topic 46 摘要段落，置于 ctp-topic-66 之前 + - index.md 更新：Sources 节新增条目（置顶于 Blogwatcher 前），Entities 节新增 NetApp，Concepts 节新增 SnapMirror + - 冲突检测：暂无检测到与其他 Wiki 页面的冲突（NetApp 存储与 RDS/Aurora 属不同技术域，互补关系） + +## [2026-04-14] ingest | CTP Topic 17 Active Directory Services in Gruntwork AWS LZs +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs.md +- Status: ✅ 成功摄入 +- Summary: Paul 讲解 Gruntwork AWS Landing Zones 中的 AD 服务集成。核心内容：双域名策略（`swinford.net` 用于 R&D Labs，`intsas.local` 用于生产/SAS 环境）；SRE 预制 AMI 内置 PowerShell（Windows）/Shell（Linux）域加入脚本，通过 Terraform `user_data` 触发自动域加入；旧域名 `infra` 和 `AST` 已废弃，提供迁移路径；Linux 支持安全动态更新（Secure Dynamic Updates）自动注册 DNS A 记录；R&D 环境使用 MIM 自助服务，生产/SAS 环境通过 SMACKS 工单系统申请账号。 +- Concepts created: [[Swinford.net]]（作为 AD 域名概念）、[[Intsas.local]]（作为 AD 域名概念）、[[SMACKS]]（作为工单系统概念） +- Entities created: [[Gruntwork]]（Company/Project类实体）、[[SMACKS]]（Project类实体） +- Source page: wiki/sources/ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs.md +- Notes: + - 新增 1 个 Source Page + - 新增 1 个 Entity（Gruntwork） + - 新增 2 个 AD 域名概念实体（Swinford.net、Intsas.local） + - 新增 1 个工单系统实体（SMACKS） + - overview.md 更新：新增 CTP Topic 17 摘要段落 + - 冲突检测：暂无检测到与其他 Wiki 页面的冲突 + +## [2026-04-24] ingest | CTP Topic 66 Exposing the differences between PostgreSQL RDS and Aurora +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora.md +- Status: ✅ 成功摄入 +- Summary: Greg Klau 深度对比 PostgreSQL RDS 与 Aurora。核心维度：①最小规格/成本（RDS 更低）；②最大容量/IO性能（Aurora 更优，>10-20TB首选）；③RTO（Aurora 30秒 vs RDS 2分钟）；④存储灵活性（RDS GP2/GP3/预置IOPS/磁性，Aurora按IO收费）；⑤架构（RDS：EC2+EBS分离，Multi-AZ备用；Aurora：6副本跨3AZ共享集群卷）；⑥Blue-Green部署（仅Aurora MySQL支持）；⑦端点设计（Aurora独立Writer/Reader Endpoint）。高可用调优：DNS TTL=1秒、TCP Keep-Alive、JDBC reader/writer端点路由。 +- Concepts created: [[RTO]] +- Entities created: [[Amazon-Aurora]]（Product类实体）、[[Amazon-RDS]]（Product类实体） +- Source page: wiki/sources/ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora.md +- Notes: + - 新增 1 个 Source Page + - 新增 1 个 Concept（RTO，灾备核心指标） + - 新增 2 个 Entity（Amazon-Aurora、Amazon-RDS） + - 冲突检测：与 learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform 存在视角差异——Terraform IaC 部署关注资源标准化，存储选型属运维决策层面，已记录于 Contradictions + - overview.md 更新：新增 CTP Topic 66 摘要段落，更新 Key Entities 和 Key Concepts + +## [2026-04-23] ingest | CTP Topic 14 Octane Hub on AWS Real Life Experience +- 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.md +- Status: ✅ 成功摄入 +- Summary: Octane Hub CTO Holger Rode 分享将生产服务从 Bibling Lab 数据中心迁移到 AWS Landing Zone 的实战经验。涵盖 Docker 容器化工作负载（QuickSee、Release Manager、Patch Manager 等）、Packer+Terraform/TerraGrunt IaC 演进、EFS vs EBS 存储选型（EFS 不适合数据库，需用 EBS）、VPC Transit Gateway 网络互联、Route 53 DNS 设置。下一步：DR 改进、MSSQL→Postgres 迁移、ECS 演进。 +- Concepts created: [[Docker-Containerization]]、[[EFS-vs-EBS]] +- Entities created: [[Octane-Hub]] +- Source page: wiki/sources/ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i.md +- Notes: + - 新增 1 个 Source Page + - 新增 2 个 Concept（Docker-Containerization、EFS-vs-EBS） + - 新增 1 个 Entity（Octane-Hub） + - 冲突检测：与 ctp-topic-7（SaaS Landing Zone 设计）存在视角差异——前者侧重多租户架构，后者侧重单体团队实际迁移路径，已记录于 Contradictions + +## [2026-04-24] ingest | CTP Topic 44 AWS Backup in Micro Focus +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-44-aws-backup-in-micro-focus.md +- Status: ✅ 成功摄入 +- Summary: AWS Backup 托管服务详解，vs Micro Focus 当前分散式快照管理。涵盖四级 DR 策略（Backup and Restore / Pilot Light / Warm Standby / Active-Active），不可变性防勒索软件，法律保留合规，AWS Backup 功能演示（备份保管库、备份计划、时间点恢复），以及当前流程的五大差距。 +- Concepts created: 无（AWS Backup / RTO / RPO / Disaster Recovery / Pilot Light / Warm Standby / Active-Active / Legal Holds 已在 overview Key concepts 中覆盖） +- Entities created: 无（CCIE 门户仅出现1次，不满足创建条件） +- Source page: wiki/sources/ctp-topic-44-aws-backup-in-micro-focus.md +- Notes: + - 新增 1 个 Source Page + - 无新增 Entity/Concept + - 无冲突内容，与 ctp-topic-72、ctp-topic-73 构成递进关系 + +## [2026-04-24] ingest | 实战笔记：本地部署 RSSHub 并获取 YouTube 订阅 +- Source file: Home Office/实战笔记：本地部署 RSSHub 并获取 YouTube 订阅.md +- Status: ✅ 成功摄入 +- Summary: 本地 Docker 部署 RSSHub（diygod/rsshub，端口1200），通过浏览器 view-source 方式获取 YouTube 频道 ID，使用 `/youtube/channel/{channel_id}` 路由生成稳定 RSS 订阅源。相比第三方在线服务，本地部署更稳定可靠。 +- Concepts created: 无（RSSHub 已在 overview Key concepts 中） +- Entities created: 无（diygod 仅出现1次，不满足创建条件） +- Source page: wiki/sources/实战笔记-本地部署-rsshub-并获取-youtube-订阅.md +- Notes: + - 新增 1 个 Source Page + - 无新增 Entity/Concept + - 冲突检测：与 "How to Get the RSS Feed For Any YouTube Channel" 的在线 vs 本地方案略有差异，已记录于 Contradictions + +## [2026-04-24] ingest | Mac必装软件清单 +- Source file: Home Office/Mac必装软件清单-2026-04-17.md +- Status: ✅ 成功摄入 +- Summary: 精选8款Mac必备软件——Claude（AI助手）、Obsidian（AI知识库）、Chrome（浏览器）、Rectangle（分屏工具）、iShot（截图录屏）、Lemon（系统清理）、Raycast（启动器）、Homebrew（包管理器）。核心理念：用最少的软件达到最高的效率。Homebrew 是用 Claude Code 搭 Agent 的前置依赖。 +- Concepts created: 无 +- Entities created: 无 +- Source page: wiki/sources/mac必装软件清单-2026-04-17.md +- Notes: + - 新增 1 个 Source Page + - 无新增 Entity/Concept（软件均不满足创建条件） + - 冲突检测：无冲突 + +## [2026-04-18] ingest | fireworks-tech-graph +- Source file: raw/Skills/fireworks-tech-graph.md +- Status: ✅ 成功摄入 +- Summary: fireworks-tech-graph Claude Code Skill，将自然语言描述转化为精美 SVG 技术图，支持 7 种视觉风格和 14 种 UML 图类型，通过 rsvg-convert 导出 1920px PNG。内置语义形状词汇表和语义箭头系统，确保图形语义一致性。安装：npx skills add yizhiyanhua-ai/fireworks-tech-graph，依赖 librsvg。 +- Concepts created: 7种视觉风格系统、14种UML图、语义形状词汇表、语义箭头系统、技术图生成 +- Entities created: fireworks-tech-graph、rsvg-convert +- Source page: wiki/sources/fireworks-tech-graph.md +- Notes: + - 新增 1 个 Source Page + - 新增 5 个 Concept Page（7种视觉风格系统、14种UML图、语义形状词汇表、语义箭头系统、技术图生成） + - 新增 2 个 Entity Page（fireworks-tech-graph、rsvg-convert） + - 更新 wiki/index.md（Sources + Entities + Concepts 章节追加条目） + - 更新 wiki/overview.md（AI Tools & Prompt Engineering 章节追加条目） + - 无内容冲突 + +## [2026-04-18] ingest | Install WSL +- Source file: raw/Home Office/Install WSL.md +- Status: ✅ 成功摄入 +- Summary: 微软官方 WSL 完整安装指南，`wsl --install` 一键安装，支持 Ubuntu/Debian/SUSE/Kali 等多发行版并行安装，`wsl.exe --set-default-version` 切换 WSL1/WSL2；离线场景通过 MSI + DISM 命令手动启用 Virtual Machine Platform；运行入口推荐 Windows Terminal。与 [[WSL2 启动与网络配置指南]] 互补——前者解决安装，后者解决网络。 +- Concepts created: 无新增（WSL2 已存在于 overview.md，WSL1/WSL安装命令/多发行版支持/离线安装 为 WSL 特定术语，无需独立页面） +- Entities created: 无新增（Microsoft/Ubuntu/PowerShell/Windows Terminal 已存在于 overview.md） +- Source page: wiki/sources/install-wsl.md +- Notes: + - 新增 1 个 Source Page（install-wsl.md） + - 更新 wiki/index.md（Sources 章节追加条目） + - 更新 wiki/overview.md（新增 Install WSL 段落于 Home Server Automation 章节） + - 冲突记录：[[WSL2 启动与网络配置指南]] vs [[Install WSL]] — 侧重点差异，均为互补关系，非矛盾 + ## [2026-04-23] ingest | Obsidian 官方 CLI 命令全景速查表 - Source file: raw/Skills/Obsidian 官方 CLI 命令全景速查表.md - Status: ✅ 成功摄入 @@ -1286,3 +1581,103 @@ - 冲突记录：与 [[obsidian-必装-skills]] 中 obsidian-cli 的描述存在"官方内置"vs"kepano 发布 Skill"的视角差异，已记录至 Source Page Contradictions，结论为两者均正确（obsidian-cli 既是 Obsidian 官方内置功能，也是 kepano Skills 项目收录整理的工具） - 新建 Concept/Entity 页面：无（Obsidian-CLI concept 页面已于 2026-04-21 创建，本次仅更新内容；Obsidian entity 页面已存在，本次仅更新 sources 字段） +## [2026-04-23] ingest | WSL2 启动与网络配置指南 +- Source file: raw/Home Office/WSL2 启动与网络配置指南.md +- Status: ✅ 成功摄入 +- Summary: WSL2（Windows Subsystem for Linux 2）安装启动与网络配置实操指南。核心内容：① wsl --install 快速安装 Ubuntu；② .wslconfig 启用 networkingMode=mirrored 镜像网络模式解决 localhost 代理失效问题；③ 终端环境变量手动配置代理；④ ghproxy.com 反向代理加速 GitHub 下载。关键洞察：NAT 模式是 WSL2 无法访问 Windows 宿主机代理的根本原因，镜像网络模式是推荐解决方案。 +- Concepts created: WSL2、镜像网络模式、NAT模式、ghproxy +- Entities created: WSL2、ghproxy +- Source page: wiki/sources/wsl2-启动与网络配置指南.md +- Notes: + - 新增 1 个 Source Page（wsl2-启动与网络配置指南.md） + - 更新 wiki/index.md（Sources 章节补全缺失条目） + - 更新 wiki/overview.md（Home Server Automation 部分新增 WSL2 章节段落；Key Entities 部分新增 WSL2 和 ghproxy 条目） + - 无内容冲突 + - 新建 Concept/Entity 页面：无（WSL2 和 ghproxy 作为 Entity/Concept 在 overview.md 中描述，未创建独立页面） + +## [2026-04-24] ingest | Blogwatcher Daily 技能收藏 +- Source file: Skills/blogwatcher-daily收藏.md +- Status: ✅ 成功摄入 +- Summary: Hermes Agent 自定义 Skill `blogwatcher-daily` 的收藏笔记，实现 31 个 RSS/YouTube 订阅频道的自动化监控与每日摘要生成。通过 SQLite 数据库按 URL 去重，日常扫描追加写入 `YYYY-MM-DD.md` 日报，强制回扫写入独立文件。YouTube 频道通过本地 RSSHub 代理转换为 RSS Feed。 +- Concepts created: 无（RSS Monitoring、Cron Job、RSSHub、每日日报 等均为已有或通用概念，在 overview.md Key Concepts 中已有覆盖） +- Entities created: 无（blogwatcher-daily 作为 Skill 名在 sources 中描述；feedparser 仅出现1次，不满足 ≥2 次创建条件） +- Source page: wiki/sources/blogwatcher-daily收藏.md +- Notes: + - 新增 1 个 Source Page + - 更新 wiki/index.md（Sources 章节补全缺失条目） + - 更新 wiki/overview.md（YouTube Automation 部分 RSSHub 段落新增对 blogwatcher-daily 的关联说明） + - 无内容冲突 + - 新建 Concept/Entity 页面：无 + +## [2026-04-23] ingest | CTP Topic 1 Gruntwork Landing Zone Architecture +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-1-gruntwork-landing-zone-architecture.md +- Status: ✅ 成功摄入 +- Summary: Gruntwork AWS Landing Zone 架构基础培训。核心：参考架构（Reference Architecture）是包含核心账户（Shared/Logs/Security）和工作负载账户（Prod/Stage/Dev）的最佳实践起点；Landing Zone 基于 Gruntwork 由产品团队自行定义具体服务；安全账户使用联邦用户（Federated User）通过 AD 组映射到 IAM 角色；每个 Landing Zone 配置独立 Jenkins 服务器和特性分支 Git 工作流；Terraform AWS 服务目录强调服务应具有业务上下文。 +- Concepts created: Reference-Architecture, Landing-Zone-Architecture, Federated-Access, CI-CD-Pipeline, Terraform-Modules +- Entities created: 无（Gruntwork Entity 已存在） +- Source page: wiki/sources/ctp-topic-1-gruntwork-landing-zone-architecture.md +- Notes: + - 新增 1 个 Source Page + - 更新 wiki/index.md（Sources 章节替换预期条目为实际摘要；Concepts 章节新增 5 个概念） + - 更新 wiki/overview.md（Cloud Transformation 部分新增 CTP Topic 1 段落） + - 冲突检测：与 ctp-topic-35-aws-landing-zone-design-refresher-saas-labs 在 Landing Zone 产品定义粒度上有视角差异（前者强调灵活性，后者强调标准化），已记录于 Source Page Contradictions 节，判定为视角互补而非直接冲突 + - 新建 Concept 页面：5 个（Reference-Architecture / Landing-Zone-Architecture / Federated-Access / CI-CD-Pipeline / Terraform-Modules） + - 新建 Entity 页面：无（Gruntwork Entity 已存在，无需重复创建） + +## [2026-04-14] ingest | CTP Topic 73 AWS Backup Implementation of the Cloud Transformation Programme +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program.md +- Status: ✅ 成功摄入 +- Summary: AWS Backup 在云转型计划中的企业级实施落地。SRE 团队开发 SRE Backup Model，为产品组提供预置的 AWS Backup Plans、Vaults、KMS 密钥策略等模板，支持 DRA 账户内独立备份和恢复；初始备份复制到远程 DR 账户实现即时恢复；AWS Backup Audit Manager 提供合规审计报告和控制评估。 +- Concepts created: [[SRE Model]] +- Source page: wiki/sources/ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program.md +- Notes: + - 新增 1 个 Source Page + - 新增 1 个 Concept（SRE Model） + - index.md 更新：Sources 节新增条目，附中文摘要 + - 冲突检测：与 [[ctp-topic-44-aws-backup-in-micro-focus]] 视角互补而非冲突——前者为 CTP 实施确认，后者为内部评估，AWS Backup 的局限性已在 Contradictions 节记录 + - AWS Backup / AWS Backup Audit Manager / 跨账户备份 已在 ctp-topic-72 摄入，无需重复创建 + +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-28-aws-tag-validation-tool.md +- Status: ✅ 成功摄入 +- Summary: Lewis Brown 主讲，SRE 团队开发的 AWS 标签验证工具。Checkpoint 防火墙通过读取 EC2/安全组/负载均衡器标签值配置网络访问策略，标签缺失或无效时拦截流量；SCPs 只能阻止新资源创建，无法修复存量资源。该工具通过 variables.yaml 定义每个账户合法标签值，自动扫描 EC2/SG/LB/Lambda，比对配置输出 CSV 审计报告。使用 Poetry 管理 Python 环境，存放于 SRE Tools Repository。标签还计划用于成本核算。 +- Entities created: [[Checkpoint]], [[SRE-Team]] +- Concepts created: [[AWS-Tags]], [[AWS-Tagging-Standards]], [[Tag-Validation-Tool]], [[Service-Control-Policies-SCPs]], [[Variables-YAML]] +- Source page: wiki/sources/ctp-topic-28-aws-tag-validation-tool.md +- Notes: + - 新增 1 个 Source Page + - 新增 2 个 Entity（Checkpoint / SRE-Team） + - 新增 5 个 Concept（AWS-Tags / AWS-Tagging-Standards / Tag-Validation-Tool / Service-Control-Policies-SCPs / Variables-YAML） + - overview.md 更新：新增 CTP Topic 28 摘要段落（置于 ctp-topic-17 之后，ctp-topic-47 之前），Key Concepts 节新增 6 个概念标注（AWS-Tagging-Standards / Tag-Validation-Tool / Service-Control-Policies-SCPs / Variables-YAML / Checkpoint-Firewall / SRE-Tools-Repository） + - index.md 更新：Sources 节替换预期条目为实际摘要，Entities 节新增 2 个实体，Concepts 节新增 6 个条目 + - 冲突检测：与 [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] 互补而非冲突——后者聚焦标签收集机制和安全策略上下文，前者聚焦审计发现，共同构成"制定规范 → 强制执行 → 审计发现"的标签治理闭环 + - Lewis Brown 仅出现 1 次，未创建 Entity 页面 + +## [2026-04-14] ingest | CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md +- Status: ✅ 成功摄入 +- Summary: Steve Jarman 和 Pradeep 主讲 AWS Landing Zone 部署流程、数据收集策略与基于标签的云原生安全架构。核心：①Landing Zone 部署前需了解 BU 资产清单/IP 地址空间/数据敏感性；②DNS/Transit Gateway 等基础服务已通过 SRE 高度自动化；③基于标签的安全控制——用 AWS 标签替代传统 IP 防火墙规则；④SCP 强制执行标签规范——通过"显式拒绝"防止篡改标签绕过审计；⑤Checkpoint 防火墙有序层——按优先级执行地理屏蔽 → BU 隔离 → 产品隔离 → 环境隔离。 +- Concepts created: 无（所有概念均已在 [[ctp-topic-28-aws-tag-validation-tool]] 中创建） +- Source page: wiki/sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md +- Notes: + - 新增 1 个 Source Page + - 无新增 Concept（[[AWS_Landing_Zone]] / [[Tagging_Methodology]] / [[SCP_Service_Control_Policy]] / [[OU_Organizational_Unit]] / [[Checkpoint_Firewall_Ordered_Layer]] / [[Transit_Gateway]] / [[SRE_Automation]] 均已在 ctp-topic-28 中创建） + - overview.md 更新：新增 CTP Topic 10 摘要段落（置于 ctp-topic-1 之后），补充标签治理闭环描述 + - index.md 更新：Sources 节新增条目（置顶） + - 冲突检测：无冲突 + - Steve Jarman 仅出现 1 次，Pradeep 仅出现 1 次，均未创建 Entity 页面 + - 与 [[ctp-topic-1-gruntwork-landing-zone-architecture]] 互补——前者为基础架构，后者为安全层扩展 + - 与 [[ctp-topic-28-aws-tag-validation-tool]] 互补——构成"制定规范 → 强制执行 → 审计发现"的标签治理闭环 + +## [2026-04-14] ingest | CTP Topic 25 Labs Landing Zone Overview - ITOM Teams +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-25-labs-landing-zone-overview-itom-teams.md +- Status: ✅ 成功摄入 +- Summary: Labs Landing Zone 基于 Gruntwork 参考架构的多账户策略——核心账户包括 Shared（Jenkins 主节点/加固 AMI/容器仓库）、Logs（CloudTrail/Config 日志）、Security（联邦用户/跨账户访问）、Core（AD 管理 Windows 实例和 IDP/DNS 管理 Swimford.net）、Network（Transit Gateway + JetPult 防火墙/标签驱动的网络策略/Pulse VPN）；Shared Services 提供 45 Arc Site 监控和 Qualys 漏洞扫描；Product Account 通过 Terraform/Terragrunt 模块部署，需与网络团队协调 IP 范围和标签策略；Jenkins 流水线扫描 GitHub Enterprise 仓库变更，触发 Terragrunt plan/apply，并通过 pre-commit 和 Fortify 扫描提升安全。 +- Concepts created: 无（所有概念均已在其他 CTP 页面中创建：[[Landing Zone Architecture]] / [[Terraform]] / [[Terragrunt]] / [[Jenkins]] / [[Transit Gateway]] / [[Federated Access]] / [[Tag-Based Access Control]]） +- Source page: wiki/sources/ctp-topic-25-labs-landing-zone-overview-itom-teams.md +- Notes: + - 新增 1 个 Source Page + - 无新增 Concept/Entity（Gruntwork/Jenkins/JetPult/Pulse VPN/Qualys/45 Arc Site 均仅出现 1 次，不满足 ≥2 次建页条件） + - overview.md 更新：新增 CTP Topic 25 摘要段落（置于 ctp-topic-35 之前），补充 Labs LZ 运维实践描述 + - index.md 更新：Sources 节新增条目（置顶于 CTP Topic 34 之前），移除旧 "source missing" 标记 + - 冲突检测：无冲突 + - 属 [[ctp-topic-1-gruntwork-landing-zone-architecture]]（架构基础）和 [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]]（SaaS vs Labs 职责划分）共同构成完整的 AWS Landing Zone 知识体系 diff --git a/wiki/overview.md b/wiki/overview.md index e7363466..8460f002 100644 --- a/wiki/overview.md +++ b/wiki/overview.md @@ -41,7 +41,47 @@ Key concepts: [[Recursive Self-Optimization]], [[Generator Space]], [[Self-Refer ### Cloud Transformation & DevOps Cloud Transformation Programme (CTP) materials cover AWS landing zones, EKS, Terraform, GitOps, FinOps, observability, security, and enterprise architecture. Key themes: 3 Lines of Defence framework, ITSM, container hardening, backup & DR strategies. DevOps culture focuses on four pillars: Collaboration, Automation (CI/CD, IaC), Continuous Improvement (Kaizen), and Customer-Centricity. Agile practices (Scrum, Kanban) are symbiotic with DevOps. Emerging trends: DevSecOps, GitOps, Serverless DevOps, AI/ML-driven automation, and Edge Computing DevOps. -Key concepts: [[Landing Zone Architecture]], [[GitOps]], [[FinOps]], [[Event Sourcing]], [[Container Lifecycle Hardening]], [[AWS Backup]], [[ITSM]], [[ITSM-2.0]], [[Hyperautomation]], [[AIOps]], [[Self-Healing-Systems]], [[Zero-Trust-Architecture]], [[Policy-as-Code]], [[Immutable-Infrastructure]], [[Error Budgets]], [[Multi-Cloud Strategy]], [[Multi-Cloud-ROI]], [[DevOps Culture]], [[CI/CD Pipeline]], [[DevSecOps]], [[Shift-Left-Security]], [[Shift-Right-Security]], [[SAST]], [[DAST]], [[IAST]], [[SCA]], [[Break-the-Build]], [[Agile Practices]], [[DevOps Maturity]], [[DORA Metrics]], [[Infrastructure as Code]], [[Cloud-Native]], [[Cloud Maturity Levels]], [[Cloud Adoption Strategy]], [[Cloud Service Delivery]], [[Cloud DevOps Maturity Model]], [[Cloud Operating Model]], [[Cloud Governance]], [[Cloud Cost Optimization]], **[[Serverless Computing]]**, **[[Edge Computing]]**, **[[Green Computing]]**, [[Vendor-Lock-In]], [[Data-Sovereignty]], [[SLA]], [[SLO]], [[Incident Management]], [[Change Management]], **[[Disaster Recovery]]**, [[WAF]], [[APM]], [[Cloud Security]], [[Cloud Migration]], [[High Availability]], [[Pay-as-you-go]], [[Failover]], [[Multi-factor-Authentication]], [[Data-Governance]], [[Continuous Integration]], [[Continuous Deployment]], [[Lead Time]], [[Time-to-Market]], [[MTTR]], [[MTTD]], [[MTTA]], [[Change Failure Rate]], [[Error Budget]], [[Rollback Rate]], [[Availability]], [[Scalability]], **[[Agentic AI]]**, [[Root Cause Analysis (RCA)]], [[Predictive Maintenance]], [[Deployment Automation]], [[Rightsizing]], [[Automated Security Audit]], [[AI ChatOps]], [[What-If Simulation]], **[[RTO]]**, **[[RPO]]**, **[[Feature Flag]]**, **[[Kill Switch]]**, **[[Progressive Rollout]]**, **[[Micro-Recovery]]**, **[[Deployment-vs-Release]]**, **[[Business Impact Analysis]]**, **[[Public Cloud]]**, **[[Private Cloud]]**, **[[Hybrid Cloud]]**, **[[Shared Responsibility Model]]**, [[Multi-Tenancy]], [[Intentional Cloud Strategy]], **[[Centralized Logging]]**, **[[Cross-Account Monitoring]]**, **[[Multi-Account Deployment]]**, **[[StackSets Deployment Visibility]]**, [[CMDB]], [[Problem-Management]], [[Release-Management]], [[Configuration-Management]], [[Asset-Management]], [[Security-and-Compliance]], [[DRaaS]], [[Canary-Release]], [[Blue-Green-Deployment]], [[Threat Modeling]], [[OWASP-Top-Ten]], [[Bug-Bounty]], [[Vulnerability-Scanning]], [[Penetration-Testing]], [[Compliance-Automation]] +**[[ctp-topic-25-labs-landing-zone-overview-itom-teams]]**（CTP Topic 25）：Labs Landing Zone 运维团队视角——Labs LZ 基于 Gruntwork 参考架构，采用多账户策略，全部资源通过 Terraform/Terragrunt 管理（Jenkins 流水线扫描 GitHub 仓库变更触发 plan/apply）；核心账户包括：Shared（托管 Jenkins 主节点和加固 AMI）、Logs（CloudTrail/Config 日志集中存储）、Security（联邦用户和跨账户访问）、Core（AD 管理 Windows 实例和 IDP、DNS 管理 Swimford.net）、Network（Transit Gateway + JetPult 防火墙管理所有互联网流量，Pulse VPN 提供 Micro Focus 网络访问）、Shared Services（45 Arc Site 监控、Qualys 漏洞扫描）。Product Account 通过 Terraform 模块部署 subnet，需与网络团队协调 IP 范围和标签策略，防火墙通过标签自动配置网络访问策略。属 [[AWS-Landing-Zone]] Labs 视角的运维实践，与 [[ctp-topic-1-gruntwork-landing-zone-architecture]]（架构基础）和 [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]]（SaaS vs Labs 职责划分）共同构成完整的 AWS Landing Zone 知识体系。 + +**[[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-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 管理层的实践补充。 + +**[[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 管理知识体系。 + +**[[ctp-topic-26-standard-ami-build-publish-share-processes]]**（CTP Topic 26）：Foundation AMI 全生命周期管理详解——Srihari、Alan 和 Praveen 三位专家主讲。Foundation AMI 基于市场主流 OS（CentOS/Ubuntu/Windows）进行 CIS 安全基准加固，集成 McAfee EPO 防病毒 + Syslog-ng 日志管理 + AD 单点登录 + SSM Agent + SiteScope 监控；使用 HashiCorp Packer + Jenkins 流水线实现镜像创建完全自动化；通过跨账号共享（AMI Sharing）分发至全球多区域（俄勒冈/法兰克福/悉尼），而非物理复制（AMI Copying），避免额外存储成本；每两个月更新，采用 N-2 版本保留策略。责任共担模型：CCOE 提供安全基础镜像，产品团队在其上构建产品特定 AMI。属 [[AWS-Landing-Zone]] AMI 层的核心基础，与 [[ctp-topic-58-aws-ec2-image-builder]]（演进方向 EC2 Image Builder）和 [[learning-sessions-standard-amis-updates]]（2023年更新机制）共同构成完整的 AMI 管理知识体系。 + +**CTP Topic 10**（[[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging]]）：AWS Landing Zone 部署、数据收集策略与基于标签的云原生安全架构——Steve Jarman 和 Pradeep 主讲。核心内容：①Landing Zone 部署前必须深入了解 BU 资产清单、IP 地址空间及数据敏感性；②DNS、Transit Gateway 等基础服务已通过 SRE 团队实现高度自动化；③**基于标签的安全控制机制**——传统基于 IP 的防火墙规则无法适应云环境动态性，转向利用 AWS 标签作为安全凭证；④**SCP 强制执行标签规范**——通过"显式拒绝"逻辑防止用户通过篡改标签绕过审计，确保资源创建时即具备正确的 BU/产品/环境归属；⑤**Checkpoint 防火墙有序层逻辑**——按优先级执行地理屏蔽 → BU 隔离 → 产品隔离 → 环境隔离，实现跨 VPC/On-prem/互联网的精细化流量控制。属 [[ctp-topic-1-gruntwork-landing-zone-architecture]] 的安全层扩展，与 [[ctp-topic-28-aws-tag-validation-tool]]（标签审计）共同构成标签治理闭环。 + +Key concepts: [[Landing Zone Architecture]], [[GitOps]], [[FinOps]], [[Event Sourcing]], [[Container Lifecycle Hardening]], [[AWS Backup]], [[ITSM]], [[ITSM-2.0]], [[Hyperautomation]], [[AIOps]], [[Self-Healing-Systems]], [[Zero-Trust-Architecture]], [[Policy-as-Code]], [[Immutable-Infrastructure]], [[Foundation AMI]], [[OS Hardening]], [[CIS Benchmarks]], [[AMI Sharing]], [[Central Repository]], [[Error Budgets]], [[Multi-Cloud Strategy]], [[Multi-Cloud-ROI]], [[DevOps Culture]], [[CI/CD Pipeline]], [[DevSecOps]], [[Shift-Left-Security]], [[Shift-Right-Security]], [[SAST]], [[DAST]], [[IAST]], [[SCA]], [[Break-the-Build]], [[Agile Practices]], [[DevOps Maturity]], [[DORA Metrics]], [[Infrastructure as Code]], [[Cloud-Native]], [[Cloud Maturity Levels]], [[Cloud Adoption Strategy]], [[Cloud Service Delivery]], [[Cloud DevOps Maturity Model]], [[Cloud Operating Model]], [[Cloud Governance]], [[Cloud Cost Optimization]], **[[Serverless Computing]]**, **[[Edge Computing]]**, **[[Green Computing]]**, [[Data-Warehouse]], [[MPP]], [[Columnar-Storage]], [[Sort-Key]], [[Distribution-Key]], [[Vendor-Lock-In]], [[Data-Sovereignty]], [[SLA]], [[SLO]], [[Incident Management]], [[Change Management]], **[[Disaster Recovery]]**, **[[AWS Backup]]**（CTP Topic 44：AWS Backup 托管服务 vs Micro Focus 当前分散式快照管理，四级 DR 策略——Backup and Restore / Pilot Light / Warm Standby / Active-Active；不可变性防勒索软件；法律保留满足合规；局限：无法选择性排除 EC2 附加卷，快照为崩溃一致而非热备份）、**[[高可用（High Availability）]]**（HA 关注系统运行时间，MTBF 为衡量指标；与 DR 互补——HA 保运行，DR 保数据；CTP Topic 72：Sabith 主讲 HA 与 DR 的本质区别）、**[[灾难恢复架构模式]]**（CTP Topic 72：Backup and Restore / Pilot Light / Warm Standby / Active-Active 四级递进，成本与弹性权衡）、**[[Vault Lock]]**（CTP Topic 72：合规模式下即使根用户也无法删除恢复点，防勒索软件核心机制）、**[[跨账户备份]]**（CTP Topic 72：AWS Organizations 集成，Bunker Account 隔离存储，Forensic Account 定期测试）、**[[增量备份]]** vs [[全量备份]]（CTP Topic 72：增量仅捕获变更，节省存储成本）、**[[AWS Backup Audit Manager]]**（BAM，CTP Topic 72：合规审计报告）、**[[AWS-Tagging-Standards]]**（CTP Topic 28：AWS 标签规范，涵盖命名约定、强制标签键、成本标签策略；与 Checkpoint 防火墙安全策略直接关联，标签缺失导致流量拦截）、**[[Tag-Validation-Tool]]**（CTP Topic 28：SRE 团队开发的 Python/Boto3 工具，通过 YAML 配置扫描 AWS 资源标签合规性）、**[[Service-Control-Policies-SCPs]]**（AWS Organizations 策略类型，用于阻止不合规资源创建）、**[[Variables-YAML]]**（Tag Validation Tool 核心配置文件，定义每个账户的合法标签键及允许值）、**[[Checkpoint-Firewall]]**（防火墙供应商，依赖 AWS 标签值配置网络访问策略）、**[[SRE-Tools-Repository]]**（内部代码仓库，存放 Tag Validation Tool 等 SRE 自动化脚本）：[[WAF]], [[APM]], [[Cloud Security]], [[Cloud Migration]], [[High Availability]], [[Pay-as-you-go]], [[Failover]], [[Multi-factor-Authentication]], [[Data-Governance]], [[Continuous Integration]], [[Continuous Deployment]], [[Lead Time]], [[Time-to-Market]], [[MTTR]], [[MTTD]], [[MTTA]], [[Change Failure Rate]], [[Error Budget]], [[Rollback Rate]], [[Availability]], [[Scalability]], **[[Agentic AI]]**, [[Root Cause Analysis (RCA)]], [[Predictive Maintenance]], [[Deployment Automation]], [[Rightsizing]], [[Automated Security Audit]], [[AI ChatOps]], [[What-If Simulation]], **[[RTO]]**, **[[RPO]]**, **[[Feature Flag]]**, **[[Kill Switch]]**, **[[Progressive Rollout]]**, **[[Micro-Recovery]]**, **[[Deployment-vs-Release]]**, **[[Business Impact Analysis]]**, **[[Public Cloud]]**, **[[Private Cloud]]**, **[[Hybrid Cloud]]**, **[[Shared Responsibility Model]]**, [[Multi-Tenancy]], [[Intentional Cloud Strategy]], **[[Centralized Logging]]**, **[[Cross-Account Monitoring]]**, **[[Multi-Account Deployment]]**, **[[StackSets Deployment Visibility]]**, [[CMDB]], [[Problem-Management]], [[Release-Management]], [[Configuration-Management]], [[Asset-Management]], [[Security-and-Compliance]], [[DRaaS]], [[Canary-Release]], [[Blue-Green-Deployment]], [[Threat Modeling]], [[OWASP-Top-Ten]], [[Bug-Bounty]], [[Vulnerability-Scanning]], [[Penetration-Testing]], [[Compliance-Automation]] + +**[[ctp-topic-40-saas-database-architecture]]**（CTP Topic 40）：SAS 数据库团队在 AWS 云上的架构与运维实践——团队分布于美国/加拿大/印度/以色列，管理 500+ 数据库和 1000+ DB 服务器；支持 Oracle、Vertica、Postgres、DynamoDB、SQL Server、MongoDB、MySQL 等多引擎；高可用架构采用三可用区模式（主库/备用库/见证节点）；使用 Oracle Data Guard、Postgres Active-Passive/Active-Active、RDS HA 实现多活；通过 Terraform、AWS CLI、Shell/PowerShell 实现 IaC 自动化；Oracle GoldenGate 支持零停机迁移。属 [[AWS-Landing-Zone]] 数据库层的核心实践，与 [[ctp-topic-51-purpose-built-databases]]（数据库品类全景）和 [[ctp-topic-66-rds-vs-aurora]]（关系型选型）共同构成完整的 AWS 数据库知识体系。 + +**[[ctp-topic-46-netapps-on-aws]]**（CTP Topic 46）：NetApp 存储系统 AWS 实践——Sandeep 和 Yael 主讲。覆盖传统 NetApp 架构（ONTAP / Aggregate / FlexVol / Qtree / LUN / LIF / SVM）和 AWS 云版本 Cloud Volume ONTAP (CVO)。CVO 通过 EC2 实例提供软件定义存储，支持单节点或 HA 配对（跨多 AZ 同步复制）；数据分层机制将 30 天非活跃数据从 EBS 自动迁移到 S3；SnapMirror 实现块级跨集群复制；支持的迁移工具包括 SnapMirror、NetApp XCP、Cloud Sync、AWS DataSync。组织已在 15 个 AWS 区域部署约 1.3 PB 数据，使用 Cloud Manager 集中管理，计划引入 FSX for NetApp（POC）和 Terraform 自动化部署。属 [[AWS-Landing-Zone]] 存储层架构的核心补充。 + +**[[ctp-topic-51-purpose-built-databases]]**（CTP Topic 51）：AWS 数据库专家 Femi George 分享专用数据库选型与架构原则——核心思维：现代应用"为正确的工作选择正确的专用数据库"，避免一刀切。AWS 提供完整数据库品类：关系型（RDS、Aurora MySQL/PostgreSQL）、NoSQL 键值（ DynamoDB，日处理万亿请求）、文档（DocumentDB，MongoDB 兼容）、宽列（Keyspaces，Cassandra 兼容）、内存（ElastiCache Redis/Memcached）、图（Neptune）、时序（Timestream）、账本。实战案例：Duolingo 用 DynamoDB + ElastiCache + Aurora 组合；Netflix 用 DynamoDB 做高弹性 JSON 文档；Peloton 用 ElastiCache Redis 提供即时客户反馈。云时代 DBA 职能从底层平台管理转向应用创新（查询优化/架构设计）。属 [[AWS-Landing-Zone]] 数据库层的完整品类指南，与 [[ctp-topic-66-rds-vs-aurora]]（关系型内部选型）互补。 + +**[[ctp-topic-68-introduction-to-redshift]]**（CTP Topic 68）：AWS Redshift 数据仓库基础——Redshift 是完全托管的 PB 级云数据仓库，核心架构包含 Leader Node（管理 Schema、元数据、查询计划）和 Compute Node（通过 Slices 执行 MPP 并行查询）。支持列式存储（适合 OLAP 聚合查询）和行式存储两种模式；Sort Key 和 Distribution Key 是性能优化核心；RA3 实例类型性价比最优，支持 AWS 托管 NVMe 存储。属 [[AWS-Landing-Zone]] 数据库层的核心补充，与 [[ctp-topic-51-purpose-built-databases]]（数据库品类全景）和 [[ctp-topic-66-rds-vs-aurora]]（关系型选型）共同构成完整的 AWS 数据库知识体系。 + +**[[ctp-topic-66-rds-vs-aurora]]**（CTP Topic 66）：PostgreSQL RDS 与 Aurora 深度对比——Greg Klau 主讲。核心维度对比：①最小规格和成本（RDS 更低）；②最大容量和 IO 性能（Aurora 更优，适合 > 10-20 TB）；③RTO（Aurora 30秒 vs RDS 2分钟）；④存储灵活性（RDS 有 GP2/GP3/预置 IOPS/磁性，Aurora 按 IO 收费无上限）；⑤架构（RDS：EC2+EBS 分离，Multi-AZ 备用节点；Aurora：跨 3 AZ 的 6 副本共享集群卷）；⑥Blue-Green 部署（仅 Aurora MySQL 支持）；⑦端点设计（Aurora 独立 Writer/Reader Endpoint）。高可用调优技巧：DNS TTL 设为 1 秒、TCP Keep-Alive 快速检测故障、JDBC 连接串配置 reader/writer 端点路由。属 [[AWS-Landing-Zone]] 数据库选型的核心参考。 + +**[[ctp-topic-14-octane-hub-on-aws]]**（CTP Topic 14）：Octane Hub CTO 实战案例——Docker 容器化工作负载从 Bibling Lab 物理服务器迁移到 AWS Landing Zone。核心技术要点：Packer 构建 AMI + Terraform/TerraGrunt 替代控制台脚本（IaC 演进路径）；EFS 适合备份、EBS 适合实时数据库（存储选型原则）；VPC Transit Gateway 实现多 VPC 互联；"紧密镜像现有设置"作为无缝迁移策略。下一步：DR 改进、MSSQL→Postgres 迁移、ECS 演进。属 [[AWS-Landing-Zone]] 从设计到落地的完整案例补充。 + +**[[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]]**（CTP Topic 17）：Paul 讲解 Gruntwork AWS Landing Zones 中的 AD 服务集成——双域名策略（`swinford.net` 用于 R&D Labs，`intsas.local` 用于生产/SAS 环境）；SRE 预制 AMI 内置 PowerShell/Shell 脚本，通过 Terraform `user_data` 实现自动化域加入；旧域名 `infra` 和 `AST` 已废弃，提供明确迁移路径；Linux 支持安全动态更新（Secure Dynamic Updates）自动注册 DNS A 记录；R&D 环境使用 MIM 自助服务，生产/SAS 环境通过 SMACKS 工单系统申请账号。属 [[AWS-Landing-Zone]] AD 集成的核心实践参考。 + +**[[ctp-topic-28-aws-tag-validation-tool]]**（CTP Topic 28）：AWS 标签验证工具——Lewis Brown 主讲，SRE 团队开发的 Python/Boto3 工具。Checkpoint 防火墙通过读取 EC2、安全组、负载均衡器的标签值动态配置网络访问策略，标签缺失或无效将导致流量被拦截；SCPs 可阻止不合规资源创建但无法修复存量资源。该工具通过 `variables.yaml` 定义每个账户的合法标签值，自动扫描 EC2/安全组/负载均衡器/Lambda，生成 CSV 审计报告。使用 Poetry 管理 Python 环境，存放于 SRE Tools Repository。标签策略还计划用于未来成本核算，区分同一账户下不同产品的资源消耗。属 [[AWS-Landing-Zone]] 标签治理闭环的核心补充——制定规范（Topic 10）→ 强制执行（SCPs）→ 审计发现（Topic 28）。 + +**[[ctp-topic-47-enterprise-architecture-cloud-standards]]**（CTP Topic 47）：Lindsay 分享企业架构云标准——核心概念：Landing Zone 框架聚焦安全、合规和可管理性，为云工作负载提供托管基础，包含账户结构（dev/stage/prod）、网络、安全、访问管理和遥测；账户结构与环境和角色对齐，通过零信任和最小权限原则定义访问控制；Terraform/Terragrunt 实现 IaC，促进标准化和可测试性；云防护栏文档捕获强制性要求和最佳实践，指导可扩展性、成本最小化和灵活性；功能分区将单体应用拆分为更小的独立模块或无服务器函数。强调需要应用团队的输入来完善防护栏并纳入实践经验。属 [[AWS-Landing-Zone]] 企业架构层的理论补充。 + +**[[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 知识体系。 + +**[[Install WSL]]**（[[install-wsl]]）：微软官方 WSL 完整安装指南——`wsl --install` 一键安装（Windows 10/11 Build 19041+），支持 Ubuntu/Debian/SUSE/Kali 等多发行版并行安装，`wsl.exe --set-default-version` 切换 WSL1/WSL2；离线场景通过 MSI + DISM 命令手动启用 Virtual Machine Platform；运行入口推荐 Windows Terminal（含多标签、自定义快捷键）。[[Install WSL]] 与 [[WSL2 启动与网络配置指南]] 互补——前者解决安装问题，后者解决网络配置问题。 + +**[[WSL2]]** 是 Windows 内置的 Linux 运行环境，WSL2 默认使用 NAT 网络模式导致 Windows 代理无法被 WSL2 内部访问。通过 `.wslconfig` 启用 `networkingMode=mirrored` + `dnsTunneling=true` 可实现 WSL2 与 Windows 共享网络堆栈；国内环境下可使用 `ghproxy.com` 反向代理加速 GitHub 下载。[[WSL2]] 与 [[Ubuntu Server]] 同属 Linux 环境，[[WSL2]] 侧重 Windows 桌面开发场景，[[Ubuntu Server]] 侧重无头服务器场景。 ### Home Server Automation Home office setup guides cover a complete multi-node home network infrastructure across 5 nodes: **RackNerd VPS** (public gateway), **Mac Mini M4** (control node), **Synology NAS DS718** (media & storage), and **2 Ubuntu Servers** (monitoring & services). The architecture uses **FRP** (frps/frpc v0.65.0) for reverse tunnel-based intranet penetration, **Caddy** for automatic HTTPS with Let's Encrypt, and **Cloudflare** for DNS托管. **内网穿透方案（VPS + frp + Caddy）**提供完整公网域名访问：Cloudflare DNS A 记录指向 VPS 公网 IP → VPS 运行 frps 和 Caddy → 内网主机运行 frpc 将本地端口映射到 VPS（TCP 隧道）→ Caddy 反向代理到 frp 映射端口，自动申请 Let's Encrypt 证书提供 HTTPS 访问。支持 SSH 穿透（remote_port TCP 映射）不走 Caddy，包含 7 步系统化故障排查（端口监听检查、token 验证、防火墙规则、telnet 诊断等）。 Services deployed include Docker monitoring stack (**Prometheus** + **Grafana** + node_exporter + cAdvisor + blackbox_exporter + Alertmanager), media servers (**Jellyfin**, **Navidrome**, **Transmission**), personal dashboards (**Homarr**, **Apache Superset**), password management (**vaultwarden**), workflow automation (**n8n**), self-hosted Git (**Gitea**), diagram editing (**Draw.io**), developer utilities (**it-tools**), image hosting (**Zipline** + **MinIO**), cloud drive mounting (**CloudDrive2**), AI assistant (**OpenClaw**), e-book management (**Calibre**), proxy client (**v2rayA**), and Docker management (**Portainer**). All services are containerized via Docker Compose. The media workflow follows: Transmission (download) → organize → Jellyfin/Navidrome (play). Key configurations include read-only music mounts, transcode caching (200MB limit), FRP TCP tunnel port mappings (remotePort 60022-60026 for SSH, 13000 for Grafana, 14533 for Navidrome, etc.), Caddy domain mapping table (20+ subdomains under *.ishenwei.online), and SOCKS5 proxy (127.0.0.1:10808) status tracking across all nodes (Mac mini, Ubuntu1, Ubuntu2 working; NAS local-only). **CloudDrive2** enables direct NAS access to cloud storage via virtual filesystem mount (Aliyun Drive resource directory only, scan QR code with App authorization). Backup automation is implemented via rsync incremental sync to NAS, using **Synology DSM NFS** (Squash=admin, sys security, _netdev fstab params) and **nfs-common** client on Ubuntu Server. SSH server setup on Ubuntu 24.04 introduces **ssh.socket activation** (on-demand startup) as the default; administrators can switch to persistent ssh.service mode. Cross-border AI service registration guides cover using **fingerprint browsers** (**AdsPower**), **high-purity US proxies**, **SMS verification platforms** (**PingMe**), and **virtual credit cards** (**WildCard**) to safely subscribe to **Claude Pro**. The architecture provides unified HTTPS public access to all internal services without requiring static IPs, achieving privacy for internal services while maintaining low bandwidth costs. @@ -53,6 +93,8 @@ Key concepts: [[Docker-Image]], [[Docker-Save]], [[Docker-Load]], [[Docker Compo ### YouTube Automation A practical tip for extracting YouTube Channel IDs: use `view-source:` prefix in browser to access channel page source, search for `channel_id` string in the page source to find the RSS Feed URL containing the channel ID. Can be used in [[n8n]] workflows for YouTube subscription monitoring. +**本地 RSSHub 部署方案**（[[实战笔记-本地部署-rsshub-并获取-youtube-订阅]]）：通过 Docker 一键部署 RSSHub（`diygod/rsshub`，端口 1200），使用 `/youtube/channel/{channel_id}` 路由生成 YouTube 频道 RSS 源。相比第三方在线服务，本地部署更稳定可靠，可完全控制数据流向。本地 RSSHub 同时支撑 [[blogwatcher-daily]] Skill 的 YouTube 频道订阅监控（31个频道中18个通过 RSSHub 代理）。 + **AI-Powered Daily Digest**: [[daily-youtube-digest]] provides a fully automated pipeline — AI Agent periodically checks subscribed channels for new uploads → extracts video transcripts via [[TranscriptAPI.com]] → generates key-point summaries → delivers a daily digest. Runs on [[OpenClaw]] via the `youtube-full` skill (installable from [[ClawHub]]), using 0-credit free API calls for channel checking and 1 credit per transcript for summarization. Supports two modes: channel-based (e.g., @TED, @Fireship, @LexFridman) and keyword-based (e.g., "Claude Code", "AI agents"). **[[YouTube-Content-Pipeline]]**：AI Agent 驱动的 YouTube 选题发现与选题自动化流水线——每小时 Cron Job 扫描 Web + X/Twitter 突发 AI 新闻，向 Telegram 推送选题；同时维护 90 天视频目录（播放量 + 主题分析）避免选题重复，通过 SQLite 向量嵌入实现语义去重；在 Slack 分享链接时自动研究主题、搜索 X、查询知识库并创建带大纲的 Asana 任务卡。与 [[Daily-YouTube-Digest]] 互补：后者侧重订阅频道更新监控，前者侧重全网趋势主动发现。与 [[Content-Factory]] 共享并行子 Agent 执行模式。 @@ -106,6 +148,8 @@ Covers Claude Code, Claude Code Templates (npx 一键安装 Skills/Agents/MCP vi **Gemini 3 十应用实战**（[[我用-gemini-3-一口气做了-10-个应用-附教程]]）：使用 Google [[Gemini-3]] 模型通过对话式提示词构建 10 个实用可视化应用（冷知识卡片/配色卡片/电影海报/绘画思维导图等）。核心方法论：①限定垂直场景（诗词/小说/电影）→ ②用提示词约束结构化输出（JSON/SVG）→ ③用前端 SVG/HTML 作为输出容器。三步核心机制：**AI 生成 SVG 代码 → 前端渲染为精美卡片/海报/导图**。该方法论与 [[Vibe-Coding]] 的"对话驱动 + AI 结对"理念高度契合——通过限制输入场景降低 AI 理解成本，通过提示词约束结构化输出，通过前端代码作为最终容器，是 Vibe Coding 在 AI 可视化产品方向的具体实践。 +**[[fireworks-tech-graph]]**：Claude Code Skill，将自然语言描述转化为精美 SVG 技术图并导出 PNG——解决技术文档/博客缺乏高质量可视化图表、手动绘图耗时且风格不统一的核心痛点。内置 **7 种视觉风格**（扁平图标风/暗黑极客风/工程蓝图风/Notion极简风/玻璃态卡片风/Claude官方风格/OpenAI官方风格）和 **14 种 UML 图类型**，深度覆盖 AI/Agent 领域常见 Pattern（RAG、Agentic Search、Mem0、Multi-Agent、Tool Call 流程等）。语义形状词汇表确保图形语义一致（LLM=双边框圆角矩形、Agent=六边形、Vector Store=带内环圆柱），语义箭头系统通过颜色+虚线编码含义（主数据流/控制触发/记忆读取/写入/异步/反馈循环）。通过 `rsvg-convert` 导出 1920px PNG，可直接嵌入文章发布。安装：`npx skills add yizhiyanhua-ai/fireworks-tech-graph`，依赖 `librsvg`（macOS: `brew install librsvg`，Ubuntu: `sudo apt install librsvg2-bin`）。核心价值：**AI Agent 可快速生成专业级技术图，无需手动绘制**，支持 SVG 可编辑 + PNG 无损发布。 + **Claude Prompt Library**（[[useful-prompt-lib]]）：Anthropic 官方提示词库，收录 64+ 款专业化提示词，覆盖开发工具（Python Bug Buster、Code Consultant、Git Gud）、效率工具（Data Organizer、Review Classifier、CSV Converter）、创意工具（Storytelling Sidekick、Culinary Creator）、营销工具（Babel's Broadcasts 多语言推文、Polyglot Superpowers 互译）、教育工具（Meeting Scribe、Lesson Planner、Socratic Sage）等 10+ 领域。TikTok 跨境电商推荐三剑客：Babel's Broadcasts（10 种语言产品发布）、Review Classifier（评论自动化分类）、Data Organizer（非结构化文本→JSON，对接 n8n 工作流）。 **LLM / RAG / AI Agent 三层架构**：基于 [[llms-rag-ai-agent-三个到底什么区别]] 的系统梳理，AI 应用的三层架构： @@ -173,6 +217,8 @@ Covers Claude Code, Claude Code Templates (npx 一键安装 Skills/Agents/MCP vi **Claude Code 调用方法**：[[claude-code调用方法总结]] 详细记录了 Hermes Agent 通过 `terminal` 工具调用 Claude Code 的两种模式——Print Mode（`claude -p`，适合绝大多数任务）和 TMUX 交互模式（适合超长任务）。核心参数包括 `--permission-mode bypassPermissions`（跳过所有权限确认）和 `--add-dir`（加载 SKILL.md）。关键结论：当任务需要 Claude Code 的 Skill 时，应使用 `terminal` 调用 `claude -p` 而非 `delegate_task`。 +**Mac 必装软件清单**（[[mac必装软件清单-2026-04-17]]）：精选 8 款 Mac 必备软件——Claude（AI 助手）、Obsidian（AI 知识库）、Chrome（浏览器）、Rectangle（分屏工具）、iShot（截图录屏）、Lemon（系统清理）、Raycast（启动器）、Homebrew（包管理器）。核心理念：**用最少的软件达到最高的效率**。[[Homebrew]] 是用 Claude Code 搭 Agent 的前置依赖，[[Obsidian]] 搭配 [[Claudian]] 可打造 AI 驱动的终极个人知识库。与 [[Second Brain]] 和 [[Personal Knowledge Base (RAG)]] 同属知识管理场景。 + **baoyu-imagine AI Logo 生成**：[[我做了个-skill-让-ai-帮你生成-logo-和图标]] 介绍了一个 Claude Code Skill `baoyu-imagine`（`npx baoyu-imagine` 安装），通过 Logo 专用提示词策略驱动 AI 生图工具生成专业 Logo 和图标。核心价值：让非设计师快速产出扁平化/几何/手绘/渐变等多种风格的专业品牌视觉资产，支持 SVG（矢量缩放）和 PNG 格式导出。与 [[Nano Banana]] 提示词体系（侧重摄影/插画/科研配图）同属 AI 图像生成工具链，baoyu-imagine 专注于 Logo/图标这一垂直场景。 **Coze 平台多行业 AI Agent 培训**（[[ai-解决方案专家培训课程]]）：Coze（扣子）平台的实战培训课程，分国内版（coze.cn）和海外版（coze.com），提供覆盖金融（客户分层营销、智能客服）、医疗（分诊助手、影像识别）、教育（知识库问答、拍照搜题）、电商（混剪助手、在线换衣、抖音直播回复）、人力资源（招聘打分、面试对练、AI 培训对练）、泛娱乐（AI 证件照、视频生成工作流）、在线客服（AI 助教、AI 销售）等 7 大行业共 50+ 可体验 Agent Demo，是 AI 解决方案专家培训的实操案例库。与 [[Prompt Engineering]]（提示词技能）、[[RAG（检索增强生成）]]（知识库问答）、[[Function Call]]（工具调用）三大基础能力配套，学员可通过邀请链接直接加入团队空间体验所有 Agent，并可 Fork 改造。与 [[固定镜头短视频制作的AI全流程解析]] 的 AI 视频生成工作流相关联。 @@ -254,6 +300,7 @@ Key concepts: [[Generalist]], [[Self-Education]], [[Self-Interest]], [[Self-Suff - [[clawhub.ai]] — OpenClaw Skill 市场，托管 clawr.ing 等 Skill 安装包 - [[AionUi]] — 桌面多 Agent Hub（macOS/Windows/Linux），将 OpenClaw 作为可视化 Cowork Agent 运行，支持内置远程救援专家和统一 MCP 配置 - [[n8n]] — workflow automation +- [[Octane-Hub]] — Software Factory 团队，Micro Focus 云转型计划一部分，主导 Docker 容器化工作负载从 Bibling Lab 向 AWS Landing Zone 的迁移项目，CTO 为 Holger Rode - [[Node.js]] — JavaScript 运行时环境，n8n-mcp 的运行依赖，也是 [[n8n]] 工作流引擎的后端运行环境 - [[gog CLI]] — 由 steipete 开发的 Google Workspace 命令行管理工具（Homebrew 安装），支持 Gmail/Calendar/Drive/Contacts/Docs/Sheets 全套服务，[[personal-crm]] 和 [[multi-channel-assistant]] 的前置依赖 - [[Quartz]] — static site generator for wikis @@ -298,8 +345,10 @@ Key concepts: [[Generalist]], [[Self-Education]], [[Self-Interest]], [[Self-Suff - [[VictoriaMetrics]] — Prometheus 时序数据库替代方案，支持长期存储和高效写入，适合大规模数据保留场景 - [[Portainer]] — Docker 可视化管理工具，不替代 Prometheus 但便于运维快速操作容器 - **[[BMC]]** — 企业IT管理解决方案提供商（BMC Helix / Control-M） -- **[[AWS]]** — Amazon Web Services -- **[[Azure]]** — Microsoft Azure +- **[[AWS]]** — Amazon Web Services，提供 RDS 和 Aurora 两款托管数据库服务 +- **[[Amazon RDS]]** — 关系型数据库服务，计算与存储分离（EBS），支持 Multi-AZ 部署 +- **[[Amazon Aurora]]** — 云原生关系型数据库，6 副本跨 3 AZ 共享集群卷架构 +- [[Greg Klau]] — CTP Topic 66 讲师，主讲 PostgreSQL RDS vs Aurora 差异对比 - **[[Google-Cloud]]** — Google Cloud Platform - [[Btop++]] — TUI系统监控器，作者首选 - [[Htop]] — 轻量级TUI进程监控器 @@ -360,9 +409,11 @@ Key concepts: [[Generalist]], [[Self-Education]], [[Self-Interest]], [[Self-Suff - **[[Apache Superset]]** — Apache 软件基金会旗下的开源 BI 平台，通过 Docker 快速部署，支持 SQL 查询、多样化图表和仪表盘构建。Home Server 场景通过 `apache/superset:GHA-*` 镜像容器化部署，6 步初始化流程：拉取镜像 → 启动容器 → 创建管理员 → 数据库迁移 → 加载示例 → 完成初始化，默认端口 8088（映射 8777），内置 SQLite，可选外挂 MySQL - **[[RustDesk]]** — 开源远程桌面软件，支持自建中继服务器，可通过修改 GDM3 配置 `WaylandEnable=false` 强制 X11 解决 Ubuntu 24.04 Wayland 登录限制问题 - **[[Ollama]]** — 开源本地 LLM 运行框架（ollama.com/ollama.org.cn），支持 macOS/Windows/Linux/Docker，提供简洁命令 `ollama run ` 运行大语言模型，通过 API（localhost:11434）和 Open WebUI 提供多元化接入方式，DeepSeek-R1 系列模型官方支持 -- **[[Open WebUI]]** — 开源大模型 Web 界面（ghcr.io/open-webui/open-webui:main），基于浏览器访问，支持 Ollama/OpenAI API 接入，可配置 RAG 本地知识库（bge-m3 嵌入模型）和联网搜索，Docker Compose 一键部署 +|- **[[Open WebUI]]** — 开源大模型 Web 界面（ghcr.io/open-webui/open-webui:main），基于浏览器访问，支持 Ollama/OpenAI API 接入，可配置 RAG 本地知识库（bge-m3 嵌入模型）和联网搜索，Docker Compose 一键部署 +|- **[[WSL2]]** — Windows Subsystem for Linux 2，Windows 10/11 内置的 Linux 虚拟机环境，默认使用 NAT 网络模式，通过 `.wslconfig` 的 `networkingMode=mirrored` 可实现与 Windows 共享网络堆栈；[[ghproxy]] 提供 GitHub 下载的反向代理加速 -- [[ProxyChains]]：通过 LD_PRELOAD 劫持 socket 调用使任意终端命令走 SOCKS5 代理的工具，配置文件 /etc/proxychains4.conf，格式 `socks5 127.0.0.1 10808`，适用于临时命令级代理 +|- **[[ghproxy]]** — ghproxy.com，国内可访问的 GitHub 反向代理服务，通过将 `github.com` 替换为 `mirror.ghproxy.com/https://github.com` 绕过网络限制，适用于 uv 安装器、Claude Code 等工具的下载加速 +|- [[ProxyChains]]：通过 LD_PRELOAD 劫持 socket 调用使任意终端命令走 SOCKS5 代理的工具，配置文件 /etc/proxychains4.conf，格式 `socks5 127.0.0.1 10808`，适用于临时命令级代理 - [[Git 全局代理]]：Git 不读取系统环境变量，必须通过 `git config --global http.proxy socks5://127.0.0.1:10808` 设置 - [[Docker Daemon Proxy]]：通过 systemd drop-in 文件（/etc/systemd/system/docker.service.d/http-proxy.conf）注入环境变量使 docker pull 走代理，docker info | grep -i proxy 验证 - [[Docker 网络网关 IP]]：Docker 容器内访问宿主机的 IP，bridge 网络默认 172.17.0.1，自定义网络如 172.24.0.1，容器内 127.0.0.1 指向自身而非宿主机 diff --git a/wiki/sources/blogwatcher-daily收藏.md b/wiki/sources/blogwatcher-daily收藏.md new file mode 100644 index 00000000..50b55c4b --- /dev/null +++ b/wiki/sources/blogwatcher-daily收藏.md @@ -0,0 +1,58 @@ +--- +title: "Blogwatcher Daily 技能收藏" +type: source +tags: [hermes-agent, rss, automation, daily-digest] +date: 2026-04-18 +--- + +## Source File +- [[Skills/blogwatcher-daily收藏.md]] + +## Summary（用中文描述） +- 核心主题：RSS/YouTube 订阅频道的自动化监控与每日摘要生成 +- 问题域：个人资讯获取效率——手动逐个打开各频道耗时且容易遗漏更新 +- 方法/机制：Hermes Agent 自定义 Skill，定时抓取 31 个订阅频道，SQLite 去重，每日追加写入 Markdown 日报 +- 结论/价值：将信息获取自动化，用户每天早上只需阅读一篇摘要即可掌握所有频道动态 + +## Key Claims（用中文描述） +- Hermes Agent 通过自定义 Skill `blogwatcher-daily` 实现 31 个订阅频道的自动化监控 +- 每日扫描（Cron Job）自动追加新文章到 `YYYY-MM-DD.md` 日报，避免覆盖历史内容 +- YouTube 频道通过 RSSHub 本地部署代理转换为 RSS Feed，绕过直接访问限制 +- SQLite 数据库按 URL 去重，已读链接不重复写入 +- 强制回扫（`--all`）写入独立文件 `all-YYYY-MM-DD.md`，不污染日常日报 +- 支持 `--scan-only` 调试模式，只打印结果不写文件 + +## Key Quotes +> "📊 扫描完成: 共发现 12 篇新文章" — 日常扫描输出示例 + +> "新增订阅需要补历史、某个频道很久没看想批量回顾" — 强制回扫适用场景 + +> "wikiHow 禁止所有爬虫，无法抓取，永远返回 0 篇" — 已知限制说明 + +## Key Concepts +- [[RSS Monitoring]]：通过 RSS/Atom Feed 订阅网站和 YouTube 频道更新的标准化协议 +- [[Cron Job]]：定时任务调度，每天早上 6:00 自动执行扫描 +- [[RSSHub]]：开源 RSS 生成器，将不支持 RSS 的网站（如 YouTube）转换为 RSS Feed +- [[feedparser]]：Python RSS 解析库，支持 RSS 1.0/2.0/Atom 及 GB2312/GBK 编码 +- [[Deduplication]]：SQLite 按 URL 排重，避免重复写入 +- [[每日日报]]：追加模式日记文件，每天一篇，持续积累 +- [[增量写入]]：日常扫描追加到日报，强制回扫写入独立文件，二者互不干扰 + +## Key Entities +- [[Hermes Agent]]：运行 blogwatcher-daily Skill 的 AI Agent 平台，通过 Cron Job 调度 +- [[RSSHub]]：本地部署的 RSSHub 实例（`http://192.168.3.45:1200`），用于转换 YouTube 频道为 RSS +- [[blogwatcher-daily]]：Hermes Agent 自定义 Skill，核心脚本为 `blogwatcher-daily.py` +- [[feedparser]]：Python RSS 解析库，解决 RSS 1.0、GB2312 乱码、畸形 XML 等兼容性问题 + +## Connections +- [[blogwatcher-daily收藏]] ← depends_on ← [[RSSHub]] +- [[blogwatcher-daily收藏]] ← depends_on ← [[feedparser]] +- [[blogwatcher-daily收藏]] ← depends_on ← [[每日日报]] +- [[blogwatcher-daily收藏]] ← extends ← [[multi-source-tech-news-digest]] + +## Contradictions +- 与 [[multi-source-tech-news-digest]]： + - 冲突点：两者都是 RSS 多源新闻聚合方案 + - 当前观点：blogwatcher-daily 侧重 YouTube + RSS 直订的本地化方案，覆盖 31 个固定频道 + - 对方观点：multi-source-tech-news-digest 侧重多平台（RSS + Twitter + GitHub）的大规模聚合，支持动态添加来源 + - 说明：两者定位互补，blogwatcher-daily 是轻量级固定订阅方案，后者是大规模动态监控方案 diff --git a/wiki/sources/ctp-topic-1-gruntwork-landing-zone-architecture.md b/wiki/sources/ctp-topic-1-gruntwork-landing-zone-architecture.md new file mode 100644 index 00000000..2d87625a --- /dev/null +++ b/wiki/sources/ctp-topic-1-gruntwork-landing-zone-architecture.md @@ -0,0 +1,56 @@ +--- +title: "CTP Topic 1 Gruntwork Landing Zone Architecture" +type: source +tags: [AWS, Landing-Zone, Gruntwork, CTP, Terraform, CI/CD] +sources: [] +last_updated: 2026-04-14 +--- + +## Source File +- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-1-gruntwork-landing-zone-architecture]] + +## Summary（用中文描述） +- 核心主题：基于 Gruntwork 的 AWS Landing Zone 架构设计，包括参考架构、多账户结构和 CI/CD 流水线。 +- 问题域：如何在云转型项目中快速构建符合最佳实践的多账户 AWS 基础设施。 +- 方法/机制：参考架构（Reference Architecture）提供起点 → Landing Zone 基于 Gruntwork 仓库由产品团队自定义 → Jenkins CI/CD 自动化部署 → Git 特性分支工作流。 +- 结论/价值：Gruntwork 提供经过实战验证的 Terraform 模块，是 AWS 基础设施最佳实践的集合；Landing Zone 在此基础上由各产品团队填充具体业务服务。 + +## Key Claims（用中文描述） +- Gruntwork 是拥有大量 Terraform 代码的组织，其代码经过多次实践验证，被认为是最佳实践。 +- 参考架构（Reference Architecture）是包含核心账户（Shared/Logs/Security）和工作负载账户（Prod/Stage/Dev）的最佳实践起点。 +- Landing Zone 基于 Gruntwork 但由产品团队自行定义具体服务，不包含 ECS 集群或 RDS 数据库等具体实现。 +- 安全账户使用联邦用户（Federated User），通过 AD 组映射到 IAM 角色，替代传统 IAM 用户。 +- 每个 Landing Zone 配备独立的 Jenkins 服务器来部署基础设施变更，每个产品团队也有自己的 Jenkins 任务。 +- Git 工作流采用特性分支开发，通过 Pull Request 合并到主分支。 +- Gruntwork 的 Terraform AWS 服务目录强调服务应具有业务上下文，而非简单的资源堆砌。 + +## Key Quotes +> "Gruntwork is a company that has put together a lot of Terraform code, and it's a collection of best practices." — Gruntwork Landing Zone 核心价值定位 + +> "Landing Zone is based on Gruntwork, but it doesn't have ECS clusters or RDS databases — it's defined by the product team." — Landing Zone vs Reference Architecture 的关键区别 + +> "Security account uses federated users, mapping AD groups to IAM roles, instead of traditional IAM users." — 联邦用户替代 IAM 用户的身份管理策略 + +## Key Concepts +- [[Reference-Architecture]]：包含核心账户（Shared/Logs/Security）和工作负载账户（Prod/Stage/Dev）的最佳实践起点。 +- [[Landing-Zone-Architecture]]：基于 Gruntwork 仓库的 AWS 多账户基础设施部署单元，每个 Zone 有独立 GitHub 仓库管理 IaC。 +- [[Terraform-Modules]]：Gruntwork 提供的经过实战验证的 Terraform 模块，强调服务具有业务上下文。 +- [[Federated-Access]]：通过 AD 组映射到 IAM 角色的联邦身份访问，简化安全账户管理。 +- [[CI-CD-Pipeline]]：基于特性分支 + Pull Request + Jenkins 的 Terraform 基础设施变更自动化流程。 + +## Key Entities +- [[Gruntwork]]：AWS Landing Zones 基础设施框架提供方，提供经过实战验证的 Terraform 模块库。 + +## Connections +- [[ctp-topic-9-ci-cd-with-gruntwork]] ← extends ← [[ctp-topic-1-gruntwork-landing-zone-architecture]]（CI/CD 流水线是 Landing Zone 部署的核心机制） +- [[ctp-topic-2-git]] ← depends_on ← [[ctp-topic-1-gruntwork-landing-zone-architecture]]（Git 工作流是 CI/CD 的前提） +- [[ctp-topic-3-deploy-and-maintain-infrastructure]] ← extends ← [[ctp-topic-1-gruntwork-landing-zone-architecture]]（Terraform 部署是 Landing Zone 的 IaC 实践） +- [[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]] ← extends ← [[ctp-topic-1-gruntwork-landing-zone-architecture]]（AD 集成是 Landing Zone 安全账户的核心） +- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] ← extends ← [[ctp-topic-1-gruntwork-landing-zone-architecture]]（数据标签是 Landing Zone 安全配置的基础） + +## Contradictions +- 与 [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] 冲突： + - 冲突点：Landing Zone 中产品的定义粒度 + - 当前观点（CTP Topic 1）：Landing Zone 由产品团队自行定义具体服务（ECS/RDS 等），产品团队有较大自主权 + - 对方观点（CTP Topic 35）：Landing Zone 产品定义应更严格，由架构团队统一规划 + - 状态：视角互补而非直接矛盾——CTP Topic 1 强调灵活性，CTP Topic 35 强调标准化，可能反映不同组织规模和治理成熟度的差异 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 new file mode 100644 index 00000000..ee101941 --- /dev/null +++ b/wiki/sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md @@ -0,0 +1,57 @@ +--- +title: "CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security" +type: source +tags: + - AWS + - Landing-Zone + - Tagging + - Security + - CTP +date: 2026-04-14 +--- + +## Source File +- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] + +## Summary（用中文描述） +- 核心主题：AWS Landing Zone 部署流程中的数据收集策略，以及基于标签（Tagging）的云原生安全架构设计 +- 问题域：企业从传统基于 IP 的网络安全向基于身份和元数据的云安全转型过程中，如何规划 Landing Zone 并确保标签策略被强制执行 +- 方法/机制：①部署前摸底 BU 资产清单、IP 地址空间及数据敏感性；②用 AWS 标签替代 IP 作为安全凭证；③通过 OU + SCP 强制标签合规；④Checkpoint 防火墙有序层（Ordered Layer）实现基于标签的流量过滤 +- 结论/价值：为 CTP 系列的 Landing Zone 标签治理闭环（制定规范 → 强制执行 → 流量控制）提供了完整的端到端设计思路 + +## Key Claims（用中文描述） +- SRE 团队通过自动化脚本实现了 DNS 和 Transit Gateway 等基础服务的高度自动化，部署前必须先完成 BU 资产清单和数据敏感性评估 +- 基于标签的安全控制机制替代传统基于 IP 的防火墙规则，Checkpoint 防火墙通过读取 AWS 标签动态配置网络访问策略 +- SCP 的"显式拒绝"逻辑能够强制执行标签规范，防止用户通过篡改标签绕过安全审计 +- Checkpoint 防火墙的有序层（Ordered Layer）按顺序执行地理屏蔽、BU 隔离、产品隔离、环境隔离（Dev vs Prod）等策略 + +## Key Quotes +> "在部署 Landing Zone 前，必须深入了解业务部门的资产清单、IP 地址空间及数据敏感性，以便制定合适的安全姿态。" — Steve Jarman，部署规划原则 +> "通过 SCP 的显式拒绝逻辑，系统能够强制执行标签规范，确保资源在创建时即具备正确的归属（BU、产品、环境）。" — Pradeep，标签强制机制 + +## Key Concepts +- [[Landing-Zone-Architecture]]：AWS Landing Zone 是一种按照最佳实践快速设置安全且多账号 AWS 环境的基础架构框架，本视频是其标签治理设计的重要实践补充 +- [[AWS-Tagging-Standards]]：标签方法论，通过为资源定义标准化的元数据（如 Owner、BU、Product、Environment）作为自动化管理和安全策略执行的基础，本视频是该方法论的核心设计来源 +- [[Service-Control-Policies-SCPs]]：服务控制策略，本视频中用于强制执行标签合规性，防止未经授权的标签更改，属于标签治理闭环的强制执行层 +- Ordered Layer（有序层）：Checkpoint 防火墙策略的组织方式，按顺序执行地理屏蔽、BU 隔离、环境隔离等逻辑，是基于标签的流量过滤实现机制 +- Tagging-Based Security Control（基于标签的安全控制）：用 AWS 标签作为安全凭证替代传统基于 IP 的防火墙规则，是云原生安全架构的核心转型方向 + +## Key Entities +- [[Steve-Jarman]]：CTP 系列讲师，主导本次 Landing Zone 部署规划与自动化策略分享 +- [[Pradeep]]：CTP 系列讲师，演示基于标签的 SCP 强制执行机制与 Checkpoint 防火墙策略 +- [[Checkpoint]]：防火墙供应商，依赖 AWS 标签值配置网络访问策略的有序层（Ordered Layer） +- SRE-Team：站点可靠性工程团队，负责 Landing Zone 部署中的 DNS、Transit Gateway 等基础服务的自动化脚本编写 + +## Connections +- [[Landing-Zone-Architecture]] ← foundational ← [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] +- [[AWS-Tagging-Standards]] ← extends ← [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] +- [[Service-Control-Policies-SCPs]] ← extends ← [[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-47-enterprise-architecture-cloud-standards]] ← extends ← [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] + +## Contradictions +- 与 [[ctp-topic-1-gruntwork-landing-zone-architecture]] 视角差异： + - 冲突点：Landing Zone 部署的自动化粒度 + - 当前观点（Topic 10）：DNS、Transit Gateway 等基础服务已由 SRE 团队高度自动化，强调标签驱动的安全控制 + - 对方观点（Topic 1）：强调 Gruntwork 架构中 Jenkins 服务器和 Git 分支工作流作为自动化核心，标签治理描述相对简略 + - 说明：两者互补而非冲突——Topic 1 提供账户结构和 IaC 基础，Topic 10 补充了标签驱动的安全运营闭环 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 new file mode 100644 index 00000000..369da18d --- /dev/null +++ b/wiki/sources/ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i.md @@ -0,0 +1,69 @@ +--- +title: "CTP Topic 14 Octane Hub on AWS Real Life Experience Moving Production Services" +type: source +tags: + - AWS + - Octane-Hub + - Migration + - CTP + - Landing-Zone +date: 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]] + +## Summary（用中文描述） +- 核心主题：Octane Hub CTO Holger Rode 分享将生产服务从 Bibling Lab 数据中心迁移到 AWS Landing Zone 的实战经验 +- 问题域：企业级 Docker 容器化工作负载的云迁移规划与实施 +- 方法/机制：使用 AWS Landing Zone 账户体系，结合 Packer 构建 AMI、Terraform/TerraGrunt 部署、VPC Transit Gateway 网络互联、Route 53 DNS 管理 +- 结论/价值：提供从物理数据中心向 AWS 云端无缝迁移的具体路径，涵盖存储选型（EFS vs EBS）、网络配置、DNS 设置及 IaC 部署演进过程 + +## Key Claims（用中文描述） +- Octane Hub 团队通过 Docker 容器化主要 Web 应用（QuickSee、Release Manager、Patch Manager、安全程序板等），结合约 10TB 文件存储和 MSSQL 数据库，实现从 Bibling Lab 三台物理服务器向 AWS 的完整迁移 +- 云迁移动因源于 Bibling 数据中心即将关闭，云转型计划提供 POC Landing Zone（5月）和生产账户（6月），团队目标是无缝过渡、紧密镜像现有设置以避免 Go Live 期间进行重大技术变更 +- EFS 不适用于需要高性能数据库场景（数据库无法直接在 EFS 上运行），EBS 更适合实时数据库，EFS 适用于备份存储 +- IaC 部署从控制台脚本演进为 Packer 构建 AMI + Terraform/TerraGrunt 部署，实现了可重复、可审计的部署流程 + +## Key Quotes +> "Holger Rode（Octane Hub CTO 软件工厂团队负责人）分享了 Octane Hub 云设计考虑因素、学习曲线、网络和安全要求以及常见陷阱。" — 视频演讲主题介绍 + +> "从控制台脚本演变为使用 Packer 构建 AMI，使用 Terraform/TerraGrunt 部署。" — IaC 演进路径 + +## Key Concepts +- [[Docker-Containerization]]：Octane Hub 的主要部署模式，运行 QuickSee、Release Manager、Patch Manager 等 Web 应用 +- [[Packer]] + [[Terraform]]/TerraGrunt：基础设施即代码的部署流程，从控制台脚本演进而来 +- [[VPC-Transit-Gateway]]：AWS 网络互联解决方案，实现多 VPC 之间的安全通信 +- [[EFS-vs-EBS]]：文件存储与块存储的性能差异——EFS 适合备份，EBS 适合实时数据库 +- [[AWS-Landing-Zone]]：多账户 AWS 环境架构，提供 POC 和生产账户分离 + +## Key Entities +- [[Holger-Rode]]：Octane Hub CTO，软件工厂团队负责人，云迁移项目负责人 +- [[Octane-Hub]]：软件工厂团队名称，主导从 Bibling Lab 向 AWS 的生产服务迁移 +- [[Bibing-Lab]]：Octane Hub 原有数据中心，即将关闭，触发云迁移 +- [[QuickSee]]：Octane Hub 托管的 Web 应用之一 +- [[Release-Manager]]：Octane Hub 托管的 Web 应用之一 +- [[Patch-Manager]]：Octane Hub 托管的 Web 应用之一 +- [[MSSQL]]：Octane Hub 原有数据库，计划迁移到 Postgres +- [[AWS]]：目标云平台 +- [[Packer]]：AMI 构建工具 +- [[Terraform]]/TerraGrunt：基础设施即代码部署工具 + +## Connections +- [[AWS-Landing-Zone]] ← depends_on ← [[VPC-Transit-Gateway]] +- [[Octane-Hub]] ← migrated_from ← [[Bibing-Lab]] +- [[Docker-Containerization]] ← uses ← [[Packer]] + [[Terraform]] +- [[ctp-topic-7-saas-landing-zone-design]] ← extends ← [[AWS-Landing-Zone]] +- [[ctp-topic-25-labs-landing-zone-overview-itom-teams]] ← related_to ← [[AWS-Landing-Zone]] + +## Contradictions +- 与 [[ctp-topic-7-saas-landing-zone-design]] 的设计视角： + - 冲突点：SaaS Landing Zone 侧重多租户架构设计，本视频侧重单体团队的实际迁移路径 + - 当前观点：Octane Hub 案例强调紧密镜像现有设置、避免 Go Live 期间重大变更 + - 对方观点：SaaS Landing Zone 设计更关注长期架构演进和租户隔离 + +## Next Steps（迁移路线图） +- 改进 DR（灾难恢复）和高可用性 +- 通过最佳匹配存储选项（S3）进行成本优化 +- 从 MSSQL 迁移到 Postgres +- 可能迁移到 AWS ECS 服务 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 new file mode 100644 index 00000000..e3428831 --- /dev/null +++ b/wiki/sources/ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs.md @@ -0,0 +1,59 @@ +--- +title: "CTP Topic 17 Active Directory Services in Gruntwork AWS LZs" +type: source +tags: [AWS, Landing-Zone, AD, Gruntwork, CTP] +sources: [] +last_updated: 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]] + +## Summary（用中文描述） +- 核心主题：在 Gruntwork AWS Landing Zones 架构中集成与管理 Active Directory (AD) 服务的核心实践 +- 问题域：企业级 AWS 多环境（研发/生产）的 AD 域名规划、自动化域加入、以及开发者自助服务 +- 方法/机制： + - 双域名策略：`swinford.net`（研发实验室 R&D Labs）vs `intsas.local`（生产/SAS 环境） + - SRE 团队预制 AMI，内置 PowerShell（Windows）/Shell（Linux）域加入脚本 + - Terraform `user_data` 触发自动域加入流程 + - MIM（Microsoft Identity Manager）提供研发环境安全组自助管理 + - SMACKS 工单系统处理生产环境账号申请 +- 结论/价值：旧域名（`infra`、`AST`）已在 Gruntwork LZ 中废弃，提供了清晰的迁移路径和所有权归属建议 + +## Key Claims（用中文描述） +- Gruntwork Landing Zones 按环境类型（研发 vs 生产）分别使用不同的 AD 域名，以满足隔离性和合规审计需求 +- Windows 实例通过 Terraform `user_data` 调用 SRE 预制 AMI 中的 PowerShell 脚本，实现自动化域加入、旧对象清理和本地管理员分配 +- Linux 实例通过安全动态更新（Secure Dynamic Updates）机制自动向 Windows DNS 服务器注册 DNS A 记录 +- 旧域名 `infra` 和 `AST` 在新 Gruntwork LZ 中已被废弃，开发者必须迁移至新域名架构 +- R&D 环境支持 MIM 自助服务工具，生产/SAS 环境通过 SMACKS 工单系统申请账号 + +## Key Quotes +> "本次视频是 DevOps 云学习系列课程之一，重点介绍了在 Gruntwork AWS Landing Zones 架构中集成与管理 Active Directory (AD) 服务的核心实践。演讲者 Paul 详细阐述了两种主要环境的域名配置：研发实验室（R&D Labs）统一使用 `swinford.net` 域名，而生产与分阶段 SAS 环境则采用 `intsas.local`。" — 视频摘要 + +> "旧有的 `infra` 和 `AST` 域名在新的 Gruntwork 落地页中已被废弃，并为用户提供了相应的迁移路径和所有权归属建议。" — 视频摘要 + +## Key Concepts +- [[Gruntwork Landing Zones]]：预配置的、基于最佳实践的 AWS 基础架构框架，分为 R&D Labs 和 SAS 两种环境类型 +- [[swinford.net]]：专门用于研发实验室（R&D Labs）环境的 Active Directory 域名，支持 MIM 自助服务管理 +- [[intsas.local]]：用于生产和分阶段 SAS 环境的内部 Active Directory 域名，强调资源所有权归属和审计合规 +- [[SRE-provided AMIs]]：由 SRE 团队预先构建的机器镜像，内置了用于自动加入域的 PowerShell（Windows）和 Shell（Linux）脚本 +- [[User Data]]：在 AWS EC2 实例启动时执行的脚本数据，本视频中用于触发自动化的域加入流程 +- [[MIM (Microsoft Identity Manager)]]：用于 R&D 环境中安全组管理和权限申请的自助服务解决方案 +- [[SMACKS Ticket]]：内部服务管理工单系统，用于申请新账号、重置密码或处理复杂的生产环境变更 +- [[Secure Dynamic Updates]]：一种 DNS 安全机制，允许 Linux 系统在加入域时向 Windows DNS 服务器安全地注册其 A 记录 + +## Key Entities +- [[Paul]]：CTP Topic 17 讲师，Gruntwork AWS LZs AD 集成方案的讲解者 +- [[Gruntwork]]：提供 Landing Zones 基础设施框架的团队/组织 +- [[SRE Team]]：负责构建和维护预制 AMI 的 Site Reliability Engineering 团队 +- [[MIM]]：Microsoft Identity Manager，R&D 环境的安全组自助管理工具 +- [[SMACKS]]：内部服务管理工单系统，用于生产/SAS 环境的账号申请和变更处理 + +## Connections +- [[Gruntwork AWS Landing Zones Overview]] ← foundational ← [[CTP Topic 17 Active Directory Services]] +- [[SRE Standard AMIs and Image Building]] ← source ← [[SRE-provided AMIs]] +- [[Terraform Single Server Module Deep Dive]] ← deployment mechanism ← [[User Data]] +- [[ctp-topic-11-ad-integration-and-login-using-ad-accounts]] ← related ← [[AD Integration in AWS LZs]] + +## Contradictions +- 暂无检测到与其他 Wiki 页面的冲突 diff --git a/wiki/sources/ctp-topic-25-labs-landing-zone-overview-itom-teams.md b/wiki/sources/ctp-topic-25-labs-landing-zone-overview-itom-teams.md new file mode 100644 index 00000000..d0d7a028 --- /dev/null +++ b/wiki/sources/ctp-topic-25-labs-landing-zone-overview-itom-teams.md @@ -0,0 +1,70 @@ +--- +title: "CTP Topic 25 Labs Landing Zone Overview - ITOM Teams" +type: source +tags: + - AWS + - Landing-Zone + - Labs + - ITOM + - CTP + - Gruntworks + - Terraform + - Terragrunt + - Multi-Account +date: 2026-04-14 +--- + +## Source File +- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-25-labs-landing-zone-overview-itom-teams]] + +## Summary（用中文描述） +- 核心主题： + Labs Landing Zone 基于 Gruntwork 参考架构和 AWS 标准，采用多账户策略，通过 Terraform/Terragrunt 实现基础设施即代码（IaC）管理。所有资源必须通过代码机制管理，不可手动操作。 +- 问题域： + 如何在 Labs 环境中建立标准化、可扩展、安全的多账户 AWS 基础设施架构，覆盖 CI/CD 流水线、网络安全、身份认证、日志管理等企业级运维需求。 +- 方法/机制： + - 基于 Gruntworks 参考架构的多账户策略 + - 全部资源通过 Terraform/Terragrunt 代码化管理 + - Jenkins 多分支流水线扫描 GitHub 仓库变更，触发 Terragrunt plan/apply + - Checkpoint 防火墙通过标签（Tags）机制控制网络访问 + - 联邦认证（Federated Access）管理跨账户访问 +- 结论/价值： + Labs Landing Zone 提供企业级标准化基础设施模板，各团队基于标准 Terraform 模块快速部署工作负载，通过标签驱动的网络策略实现安全隔离，通过 Jenkins 流水线实现自动化部署和安全扫描。 + +## Key Claims（用中文描述） +- Labs Landing Zone 基于 Gruntwork 参考架构，所有资源必须通过 Terraform 或其他代码机制管理，不可手动操作。 +- Labs 采用多账户策略，核心账户组包括 Active Directory（管理 Windows 实例和 IDP）和 DNS（管理 AWS Swimford.net）。 +- Network 账户作为中央网络枢纽，通过 Transit Gateway 和 JetPult 防火墙管理所有互联网流量，所有防火墙访问均通过标签（Tags）控制。 +- Product Account 是主要工作环境，基于标准 IaC 模块构建，可包含多个子账户（生产/预发/开发）。 +- Jenkins 流水线扫描 GitHub Enterprise 仓库变更，根据分支触发 Terragrunt plan 或 apply，并通过 pre-commit 检查和 Fortify 安全扫描提升鲁棒性。 + +## Key Quotes +> "Everything should be managed using Terraform or some other code-based mechanism." — Labs Landing Zone 核心原则 +> "Access through that firewall is all managed by tags." — 网络防火墙访问控制机制 +> "The standard Jenkins-based pipelines scan GitHub Enterprise repositories for changes, running Terragrunt plans or applies based on the branch." — CI/CD 部署流程 + +## Key Concepts +- [[Landing Zone Architecture]]：多账户 AWS 基础设施的顶层框架，包含账户结构、网络、安全、访问管理和遥测 +- [[Terraform]]：基础设施即代码工具，Labs LZ 中用于管理所有 AWS 资源 +- [[Terragrunt]]：Terraform 的包装器，提供更简洁的多账户/多环境管理能力 +- [[Gruntwork]]：提供生产级 IaC 模块库的专业公司，参考架构的提供者 +- [[Jenkins]]：CI/CD 流水线工具，扫描 GitHub 仓库变更触发 Terragrunt plan/apply +- [[Transit Gateway]]：AWS 网络服务，Network 账户通过它作为中央枢纽管理所有 VPC 间的流量路由 +- [[Federated Access]]：联邦访问，通过 AD 组映射到 IAM 角色实现跨账户身份认证 +- [[Tag-Based Access Control]]：基于标签的访问控制，防火墙通过资源标签动态配置网络策略 + +## Key Entities +- [[Swimford.net]]：Labs Landing Zone 中使用的 DNS 域名（所有 AD 和 DNS 服务均在此域名下） +- [[JetPult]]：防火墙产品，Network 账户中用于管理网络流量 +- [[Pulse VPN]]：VPN 解决方案，Network 账户中用于提供对 Micro Focus 网络的访问 +- [[Qualys]]：安全扫描服务，Shared Service Accounts 中提供漏洞扫描能力 +- [[45 Arc Site]]：监控服务，Shared Service Accounts 中提供站点监控能力 +- [[Hardened AMIs]]：安全加固的 Amazon Machine Images，由 Shared Account 托管 + +## Connections +- [[ctp-topic-1-gruntwork-landing-zone-architecture]] ← foundational ← [[ctp-topic-25-labs-landing-zone-overview-itom-teams]] +- [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] ← related ← [[ctp-topic-25-labs-landing-zone-overview-itom-teams]] +- [[ctp-topic-7-saas-landing-zone-design]] ← extends ← [[ctp-topic-25-labs-landing-zone-overview-itom-teams]] + +## Contradictions +- 无已知冲突 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 new file mode 100644 index 00000000..1011868e --- /dev/null +++ b/wiki/sources/ctp-topic-26-standard-ami-build-publish-share-processes.md @@ -0,0 +1,66 @@ +--- +title: "CTP Topic 26 Standard AMI – build, publish, share processes" +type: source +tags: + - AWS + - AMI + - Build-Process + - CTP +date: 2026-04-14 +--- + +## Source File +- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-26-standard-ami-build-publish-share-processes.md]] + +## Summary（用中文描述） +- 核心主题：Foundation AMI（基础亚马逊机器镜像）的构建、加固与分发全生命周期管理 +- 问题域：企业 AWS 云环境中如何标准化、安全化、可复用地管理 EC2 实例镜像 +- 方法/机制：基于市场主流 OS（CentOS/Ubuntu/Windows）进行 CIS 安全基准加固，集成 McAfee EPO 防病毒 + Syslog-ng 日志管理 + AD 单点登录；使用 HashiCorp Packer + Jenkins 流水线实现镜像创建全自动化；通过跨账号共享（AMI Sharing）而非物理复制分发到全球多个区域（俄勒冈、法兰克福、悉尼等）；遵循 N-2 版本保留策略，每两个月更新一次 +- 结论/价值：CCOE 提供安全的基础镜像（Foundation AMI），产品团队在此之上构建自定义"产品特定 AMI"，实现安全合规与灵活定制兼顾的责任共担模型 + +## Key Claims（用中文描述） +- CCOE 通过 HashiCorp Packer + Jenkins 构建自动化流水线，使镜像创建完全自动化 +- Foundation AMI 集成 CIS 安全基准 + McAfee EPO 防病毒 + SSM Agent + SiteScope 监控，确保所有实例从启动起即符合 Micro Focus 安全合规标准 +- AMI 通过跨账号共享（AMI Sharing）分发至全球多区域，而非物理复制（AMI Copying），避免额外存储成本 +- Foundation AMI 每两个月更新一次，采用 N-2 版本保留策略 +- 责任共担：CCOE 负责 Foundation AMI，产品团队负责在其之上构建产品特定 AMI + +## Key Quotes +> "Foundation AMI 是基于市场主流操作系统（如 CentOS, Ubuntu, Windows 等）进行深度加固的镜像，集成了 CIS 安全基准、防病毒软件（McAfee EPO）、日志管理（Syslog-ng）以及单点登录（AD 集成）。" — Foundation AMI 定义与集成组件说明 + +> "镜像通过跨账号共享（Sharing）而非物理复制（Copying）的方式分发到全球多个区域（如俄勒冈、法兰克福、悉尼等）。" — AMI 分发机制说明 + +> "Foundation AMI 每两个月更新一次，遵循 N-2 的版本保留策略。" — AMI 更新与版本管理策略 + +> "CCOE 负责提供安全的基础镜像，而产品团队则被鼓励在 Foundation AMI 之上构建自定义的'产品特定 AMI'，以满足各自应用的特殊需求，并负责其后续的生命周期管理。" — 责任共担模型说明 + +## Key Concepts +- [[Foundation AMI]]：经过安全加固、集成标准组件并预配置好的操作系统模板，是 Micro Focus 云环境的标准化基础镜像 +- [[OS Hardening]]：操作系统加固，通过关闭不必要服务、优化内核参数和应用安全补丁来减少系统攻击面 +- [[CIS Benchmarks]]：由互联网安全中心制定的安全配置基准，用于衡量镜像是否符合行业最佳安全实践 +- [[HashiCorp Packer]]：开源工具，用于从单一源配置为多个云平台自动创建一致的机器镜像 +- [[SSM Agent]]：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]] +- [[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]] + +## Contradictions +- 与 [[ctp-topic-58-aws-ec2-image-builder]] 描述不同 AMI 生命周期阶段： + - 冲突点：ctp-topic-26 描述现有 Packer + Jenkins 自动化构建流程；ctp-topic-58 描述 EC2 Image Builder 作为替代方案 + - 当前观点（ctp-topic-26）：Packer + Jenkins 是当前生产级 AMI 构建标准 + - 对方观点（ctp-topic-58）：EC2 Image Builder 是 CCOE 加固脚本转换为可复用组件的未来演进方向 + - 结论：非冲突，而是同一 AMI 生命周期管理在不同时期的技术选型——当前实践 vs 未来演进方向 diff --git a/wiki/sources/ctp-topic-28-aws-tag-validation-tool.md b/wiki/sources/ctp-topic-28-aws-tag-validation-tool.md new file mode 100644 index 00000000..91b7211e --- /dev/null +++ b/wiki/sources/ctp-topic-28-aws-tag-validation-tool.md @@ -0,0 +1,52 @@ +--- +title: "CTP Topic 28 AWS Tag Validation Tool" +type: source +tags: [AWS, Tagging, Validation, Tool, CTP, Boto3, Checkpoint] +date: 2026-04-14 +--- + +## Source File +- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-28-aws-tag-validation-tool]] + +## Summary（用中文描述） +- 核心主题：SRE 团队开发的 AWS 标签验证工具，用于审计和报告 AWS 资源标签合规性。 +- 问题域：Checkpoint 防火墙依赖资源标签配置网络访问策略，标签缺失或无效将导致网络拦截；同时 SCPs 仅能阻止新资源创建，无法处理存量不合规资源。 +- 方法/机制：Python + Boto3 工具，通过 `variables.yaml` 配置文件定义每个账户的合法标签值，自动扫描 EC2/安全组/负载均衡器/Lambda 函数，比对预期值，输出 CSV 报告。使用 Poetry 管理 Python 环境。 +- 结论/价值：该工具极大提高了标签审计效率，可识别缺失或值错误的资源 ID 和具体问题；标签还可在未来用于成本核算（按产品分摊资源消耗）。 + +## Key Claims（用中文描述） +- Checkpoint 防火墙通过读取 EC2、安全组、负载均衡器的标签值动态配置网络访问策略，标签无效或缺失时防火墙将拦截相关流量。 +- Service Control Policies（SCPs）可在组织层面阻止不合规资源的新建，但不能修复已存在的存量资源。 +- AWS 标签验证工具通过 YAML 配置文件定义每个账户的合法标签键和允许值，自动扫描多种 AWS 资源并生成 CSV 审计报告。 +- 该工具由 SRE 团队开发和维护，存放于 SRE Tools Repository，使用 Poetry 管理 Python 依赖。 +- 标签策略除网络安全用途外，未来还计划用于成本核算，区分同一账户下不同产品的资源消耗。 + +## Key Quotes +> "Checkpoint Firewall reads the tags on EC2 instances, security groups, and load balancers to configure network access policies — if the tags are missing or invalid, the firewall will block that traffic." — Lewis Brown，阐述标签与网络安全的直接关联 + +> "The validation tool reads from a YAML file that contains all the expected tag keys and allowed values for a given AWS account." — Lewis Brown，阐述工具的核心工作机制 + +## Key Concepts +- [[AWS-Tags]]：附加在 AWS 资源上的元数据（键值对），用于识别管理和安全策略执行。 +- [[Tag-Validation-Tool]]：SRE 团队开发的 Python 工具，通过 Boto3 扫描 AWS 资源并比对 YAML 配置中的预期标签值。 +- [[Service-Control-Policies-SCPs]]：AWS Organizations 策略类型，用于集中强制执行标签规范，阻止不合规资源创建。 +- [[Variables-YAML]]：该验证工具的核心配置文件，定义特定账户所期望的合法标签键及允许值列表。 +- [[AWS-Tagging-Standards]]：AWS 标签规范，涵盖命名约定、强制标签键、成本标签策略等。 +- [[Poetry]]：Python 依赖管理和打包工具，用于该验证工具的环境隔离和依赖管理。 +- [[Boto3]]：Python AWS SDK，该验证工具通过 Boto3 调用 AWS API 扫描资源标签。 + +## Key Entities +- [[Lewis-Brown]]：SRE 团队成员，本次视频讲师，介绍 AWS 标签验证工具。 +- [[Checkpoint]]：防火墙供应商，其防火墙产品读取 AWS 资源标签以配置网络访问策略。 +- [[SRE-Team]]：开发和维护该标签验证工具的团队，存放工具于 SRE Tools Repository。 +- [[SRE-Tools-Repository]]：内部代码仓库，存放该验证工具及其他 SRE 自动化脚本。 +- [[Boto3]]：AWS 官方 Python SDK，该工具的技术基础。 +- [[Poetry]]：Python 包管理工具，该工具的环境管理方案。 + +## Connections +- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] ← extends ← [[ctp-topic-28-aws-tag-validation-tool]] +- [[ctp-topic-10-aws-tagging-deep-dive]] ← related ← [[ctp-topic-28-aws-tag-validation-tool]] +- [[AWS-Landing-Zone-Governance]] ← context ← [[ctp-topic-28-aws-tag-validation-tool]] + +## Contradictions +- 无冲突检测。该工具与 [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] 构成互补关系——后者聚焦标签收集机制和 Checkpoint 防火墙的安全策略上下文，前者聚焦如何检测和报告不合规资源。两者共同构成完整的标签治理闭环（制定规范 → 强制执行 → 审计发现）。 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 new file mode 100644 index 00000000..c25ed6bc --- /dev/null +++ b/wiki/sources/ctp-topic-34-azure-landing-zone-architecture-overview.md @@ -0,0 +1,56 @@ +--- +title: "CTP Topic 34 Azure Landing Zone Architecture Overview" +type: source +tags: + - Azure + - Landing-Zone + - Cloud-Transformation + - CTP +date: 2026-04-14 +--- + +## Source File +- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-34-azure-landing-zone-architecture-overview]] + +## 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 实现精细化访问控制 + +## 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 管理跨订阅依赖，支持分层架构 + +## 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 环境允许团队在隔离环境中实验工作负载 + +## 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 的组成部分，通过访问组管理用户权限，支持基于角色的策略执行 + +## Key Entities +- [[Kishore Garlopati]]：演讲者，Azure Landing Zone 架构overview主讲人 +- [[Micro Focus]]：使用 Azure Landing Zone 进行云转型的企业组织，参考 [[AWS Landing Zone]] 在 Micro Focus 的实践经验 + +## 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 的云端编排平台） + +## Contradictions +- 无已知冲突内容 diff --git a/wiki/sources/ctp-topic-35-aws-landing-zone-design-refresher-saas-labs.md b/wiki/sources/ctp-topic-35-aws-landing-zone-design-refresher-saas-labs.md new file mode 100644 index 00000000..b1e63369 --- /dev/null +++ b/wiki/sources/ctp-topic-35-aws-landing-zone-design-refresher-saas-labs.md @@ -0,0 +1,52 @@ +--- +title: "CTP Topic 35 AWS Landing Zone Design Refresher (SaaS Labs)" +type: source +tags: [] +date: 2026-04-14 +--- + +## Source File +- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-35-aws-landing-zone-design-refresher-saas-labs.md]] + +## Summary（用中文描述） +- 核心主题：AWS Landing Zone 设计复习，重点对比 SaaS（生产）与 Labs（开发）两种 Landing Zone 环境的架构差异与近期变更 +- 问题域：企业多账户 AWS 环境下的账户结构设计、共享服务架构、网络分段策略、以及 SaaS 与 Labs 的职责划分 +- 方法/机制：基于 Gruntwork Terraform 模板构建 Landing Zone IaC；通过 CCOEs CloudTrail 替代 Gruntworks CloudTrail 实现统一审计；网络账户 Checkpoint 重新路由入站流量；网络分段阻断 SaaS 工作负载的直接连通性 +- 结论/价值：明确 SaaS = 生产、Labs = 开发的核心定位；PoC Landing Zone 将并入 Labs 以最大化资源共享；Cloud Technology Design Forum 推动 Micro Focus 云交付标准化 + +## Key Claims（用中文描述） +- Gruntwork 框架的 Landing Zone 通过 Terraform 模板以 IaC 方式构建 +- SaaS Landing Zone 为每个产品区域提供客户专属的产品账户，通过共享服务账户实现安全、日志和网络互联 +- Gruntwork 账户跨所有账户管理 AMI、日志和安全策略 +- 网络分段策略将阻断对 SaaS 工作负载的直接连通性 +- CCOEs CloudTrail 取代 Gruntworks CloudTrail 实现统一云审计 +- 入站流量拟通过 Network 账户的 Checkpoint 重新路由 +- 原生 AWS Backup 有望成为强制要求 +- 新账户可能取消 Management VPC +- SaaS 用于生产环境，Labs 用于开发环境（PoC Landing Zone 将并入 Labs） + +## Key Quotes +> "Our AWS landing zones, they're built infrastructure as code as you'd expect on terraform templates using the grunt work framework." — Landing Zone 的 IaC 实现方式 +> "Basically, the only answer is that SAS is production, Labs is development." — SaaS 与 Labs 的本质区别 + +## Key Concepts +- [[AWS-Landing-Zone]]：AWS 多账户架构的基础框架，通过账户隔离实现安全、合规和可管理性 +- [[Gruntwork]]：提供生产级 Terraform 模块的基础设施库，Micro Focus 基于此构建 Landing Zone +- [[Shared-Services-Account]]：托管共享服务（Artifactory、Cyber Eupriva、ArcSight、监控等）的集中账户 +- [[Core-Accounts]]：包含 Active Directory、DNS 和 Network 账户，支持 IT 服务和 Micro Focus 基础设施 +- [[Product-Accounts]]：托管各产品线的 IT 产品、项目、应用程序及相关 AWS 资源，由各项目团队管理 +- [[Gruntwork-Accounts]]：跨所有账户管理 AMI、日志和安全策略的集中账户 +- [[CCOEs-CloudTrail]]：由 CCOE 团队管理的统一 CloudTrail，替代原有的 Gruntworks CloudTrail +- [[Network-Segmentation]]：通过 Checkpoint 防火墙和网络分段策略阻断对 SaaS 工作负载的直接连通性 + +## Key Entities +- [[Cloud-Technology-Design-Forum]]：Micro Focus 云技术设计论坛，致力于标准化和集中化云交付产品（包括 Landing Zone 设计） + +## Connections +- [[ctp-topic-1-gruntwork-landing-zone-architecture]] ← extends ← [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] +- [[ctp-topic-7-saas-landing-zone-design]] ← related_to ← [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] +- [[ctp-topic-25-labs-landing-zone-overview-itom-teams]] ← related_to ← [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] +- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging]] ← related_to ← [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] + +## Contradictions +- （暂无检测到与其他 Wiki 页面的明显冲突） 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 new file mode 100644 index 00000000..1676b268 --- /dev/null +++ b/wiki/sources/ctp-topic-40-saas-database-architecture-on-aws-cloud.md @@ -0,0 +1,61 @@ +--- +title: "CTP Topic 40 SaaS Database Architecture On AWS Cloud" +type: source +tags: + - SaaS + - Database + - Architecture + - AWS + - CTP +date: 2026-04-14 +--- + +## Source File +- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-40-saas-database-architecture-on-aws-cloud]] + +## Summary（用中文描述） +- 核心主题：SAS 数据库团队在 AWS 云上的数据库架构与运维实践 +- 问题域：企业级 SaaS 数据库管理、跨区域多数据库引擎运维、数据库高可用架构 +- 方法/机制： + - 全球分布式团队（美国/加拿大/印度/以色列）提供 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）的集成 + +## Key Claims（用中文描述） +- SAS 数据库团队在全球 4 个国家设有办公地点，管理 500+ 数据库和 1000+ DB 服务器 +- 数据库主要部署在 Application VPC 内，集成安全措施 +- 高可用架构采用三可用区部署模式：一区主库、二区备用库、三区见证节点 +- 报告数据库在第三可用区部署只读仓库，通过 VPN 安全访问 +- Oracle GoldenGate 用于多租户场景，支持平滑迁移（零停机或最小停机） +- 日常运维每月处理 400-500 个 SSR 和 IM，每月至少执行 10 个变更 + +## Key Quotes +> "The idea was to move those databases seamless without downtime or with minimum downtime." — 描述 Oracle GoldenGate 数据中心迁移项目的核心目标 + +> "Databases reside mostly on application VPCs with integrated security measures." — 数据库安全部署原则 + +## Key Concepts +- [[高可用（High Availability）]]：关注系统运行时间，MTBF 为衡量指标 +- [[Oracle Data Guard]]：Oracle 数据库的高可用解决方案，用于主备复制和故障切换 +- [[Multi-AZ Deployment]]：跨多个可用区部署数据库，确保故障隔离和灾难恢复能力 +- [[Database Migration]]：使用 Oracle GoldenGate 实现零停机或最小停机迁移 +- [[DB-as-a-Service]]：托管数据库服务模式（AWS RDS、Aurora） + +## Key Entities +- [[AWS]]：Amazon Web Services，提供基础设施和托管数据库服务 +- [[Amazon RDS]]：关系型数据库服务，支持 Multi-AZ 部署 +- [[Amazon Aurora]]：云原生关系型数据库，6 副本跨 3 AZ 共享集群卷架构 +- [[AWS CloudWatch]]：监控和可观测性服务 +- [[Terraform]]：基础设施即代码工具 +- [[Micro Focus]]：SAS 产品的母公司，数据库团队隶属该组织 + +## 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]] + +## Contradictions +- 无明显冲突内容 diff --git a/wiki/sources/ctp-topic-44-aws-backup-in-micro-focus.md b/wiki/sources/ctp-topic-44-aws-backup-in-micro-focus.md new file mode 100644 index 00000000..8038dcf3 --- /dev/null +++ b/wiki/sources/ctp-topic-44-aws-backup-in-micro-focus.md @@ -0,0 +1,61 @@ +--- +title: "CTP Topic 44 AWS Backup in Micro Focus" +type: source +tags: + - AWS + - Backup + - DR + - CTP +date: 2026-04-14 +--- + +## Source File +- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-44-aws-backup-in-micro-focus]] + +## Summary（用中文描述） +- 核心主题：AWS Backup 托管服务与 Micro Focus 当前备份流程的差距分析，以及向 AWS Backup 迁移的评估。 +- 问题域：企业级数据保护、灾难恢复策略、跨账户/跨区域备份合规性。 +- 方法/机制： + - 四级 DR 策略（RTO/RPO 从数小时到近乎零） + - AWS Backup 集中化备份保管库 + 备份计划 + 时间点恢复 + - 基于角色的访问控制（IAM）+ CloudWatch 监控 + - 不可变性（Immutability）防勒索软件 + - 法律保留（Legal Holds）满足合规要求 +- 结论/价值：AWS Backup 相比当前分散式快照管理有明显优势（集中化、不可变性、跨账户/跨区域），但存在卷粒度限制、崩溃一致快照等局限性，需根据 RTO/RPO 需求选择合适策略。 + +## Key Claims（用中文描述） +- AWS Backup 通过集中化备份保管库和备份计划，消除了当前多团队分散管理快照的错误风险。 +- 不可变性（Immutability）是防止勒索软件攻击备份数据的核心机制，当前 CCIE vault 无法提供此保障。 +- Pilot Light 策略可在 1 小时内恢复，Warm Standby 可在数分钟内恢复，Active-Active 提供近乎零停机，但成本递增。 +- AWS Backup 对附加到 EC2 的多个卷强制备份所有卷，无法选择性排除特定卷。 +- Amazon 建议数据库不再使用热备份，快照是崩溃一致的，支持增量备份。 + +## Key Quotes +> "AWS Backup 是一个托管服务，用于在 AWS 云中集中化和自动化数据保护。它支持跨账户和跨区域备份，并提供不可变性以防止勒索软件等威胁。" — 视频摘要 +> "AWS Backup 加密所有备份，包括静态和传输中的数据。" — 视频摘要 +> "Amazon 不再建议数据库使用热备份，指出快照是崩溃一致的，支持增量备份。" — 视频摘要 + +## Key Concepts +- [[AWS Backup]]：AWS 托管的集中化数据保护服务，支持跨账户和跨区域备份，提供不可变性和法律保留功能。 +- [[不可变性（Immutability）]]：防止备份被篡改或删除的机制，是防勒索软件的关键。 +- [[RTO（Recovery Time Objective）]]：恢复时间目标，衡量从故障恢复到服务可用的时间。 +- [[RPO（Recovery Point Objective）]]：恢复点目标，衡量可接受的最大数据丢失时间窗口。 +- [[灾难恢复策略]]：Backup and Restore / Pilot Light / Warm Standby / Active-Active 四级递进策略。 +- [[法律保留（Legal Holds）]]：用于合规性保留特定备份，隔离而不被删除。 +- [[Pilot Light]]：DR 策略之一，数据持续复制到 DR 区域，可在 1 小时内恢复核心服务。 +- [[Warm Standby]]：DR 策略之一，应用在生产 DR 区域以较小规模持续运行，可在数分钟内完全扩缩。 +- [[Active-Active]]：DR 策略之一，应用在两个区域同时运行，提供近乎零停机和零数据丢失。 + +## Key Entities +- [[AWS]]：Amazon Web Services，提供 AWS Backup 托管服务的云平台。 +- [[CCIE 门户]]：当前管理快照的内部 Micro Focus 平台，通过标签跟踪备份过程和错误通知。 +- [[Cloud Transformation Programme (CTP)]]：云转型计划，该视频属于 01_AWS-Landing-Zone 系列第 44 个主题。 + +## Connections +- [[ctp-topic-44-aws-backup-in-micro-focus]] ← extends ← [[AWS Backup]] +- [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]] ← depends_on ← [[AWS Backup]] +- [[ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program]] ← extends ← [[ctp-topic-44-aws-backup-in-micro-focus]] +- [[RTO vs RPO]] ← related ← [[AWS Backup]] + +## Contradictions +- 无明显内容冲突。本视频内容与 [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]] 和 [[ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program]] 构成递进关系。 diff --git a/wiki/sources/ctp-topic-46-netapps-on-aws.md b/wiki/sources/ctp-topic-46-netapps-on-aws.md new file mode 100644 index 00000000..140133d4 --- /dev/null +++ b/wiki/sources/ctp-topic-46-netapps-on-aws.md @@ -0,0 +1,67 @@ +--- +title: "CTP Topic 46 NetApps on AWS" +type: source +tags: [NetApp, AWS, Storage, CTP, Cloud-Storage] +date: 2026-04-14 +--- + +## Source File +- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-46-netapps-on-aws]] + +## Summary（用中文描述） +- 核心主题：NetApp 存储系统（传统 + AWS 云版本）的架构、组件、数据分层、安全、备份/DR、迁移工具及企业实际使用情况 +- 问题域：企业如何将 NetApp 存储从本地扩展到 AWS 云端，实现统一存储管理 +- 方法/机制：Cloud Volume ONTAP (CVO) 通过 EC2 实例提供企业级存储；EBS 作为底层存储介质；Data Tiering 自动在 EBS 和 S3 之间分层；SnapMirror 实现跨集群数据复制 +- 结论/价值：NetApp on AWS 是企业云存储转型的成熟方案，支持单节点/HA架构，提供块级复制、S3 分层、统一管理（Cloud Manager），组织已在 15 个 AWS 区域部署约 1.3 PB 数据 + +## Key Claims（用中文描述） +- NetApp ONTAP 是统一的存储操作系统，支持 SMB、NFS、FC、FCOE、iSCSI 等多种协议 +- Cloud Volume ONTAP (CVO) 通过 EC2 实例在 AWS 上提供软件定义的存储，支持单节点或 HA 配对 +- 数据分层机制：活跃数据存储在 EBS，非活跃数据（30天以上）自动迁移到 S3，访问时拉回 EBS +- SnapMirror 通过块级复制实现 NetApp 集群间的数据同步，基线复制后仅传输增量变更 +- 从本地迁移到 AWS 的工具包括 SnapMirror、NetApp XCP、Cloud Sync、AWS DataSync、Silver Peak WAN Optimizer + +## Key Quotes +> "NetApp primarily supports SMB, NFS, FC, FCOE, and ISCSI protocols, often configured as a single node or HA pair." — NetApp 传统架构概述 +> "The organization has around 15 NetApp clusters in various AWS regions, hosting approximately 1.3 petabytes of data." — 企业实际使用规模 +> "Data inactive for 30 days or more is automatically moved to S3 and pulled back to EBS when accessed." — CVO 数据分层机制 +> "SnapMirror copies volumes and their snapshots, with baseline copies performing initial full data replication, subsequent updates copy only the changes." — SnapMirror 复制策略 + +## Key Concepts +- [[Cloud Volume ONTAP (CVO)]]：NetApp ONTAP 的 AWS 云版本，通过 EC2 实例运行，支持单节点或 HA 架构，使用 EBS 作为存储后端 +- [[ONTAP]]：NetApp 统一存储操作系统，管理聚合、卷、Qtree、LIF、SVM 等存储组件 +- [[Aggregate]]：由多个磁盘组成的 RAID 组，构成 NetApp 的基础存储池 +- [[FlexVol]]：托管在 Aggregate 之上的灵活数据容器，通过 NFS 或 CIFS 呈现给主机 +- [[Qtree]]：卷的进一步细分，支持权限和配额管理等特殊属性 +- [[LUN (Logical Unit Number)]]：块级存储的逻辑表示，通过 FC 或 iSCSI 呈现给主机 +- [[LIF (Logical Interface)]]：物理网卡之上的接口，承载 IP 地址或 WWPN，用于节点管理、数据复制和数据服务 +- [[SVM (Storage Virtual Machine)]]：NetApp 系统的虚拟隔离，支持多租户，每个 SVM 视为独立操作系统 +- [[Data Tiering]]：利用 EBS 和 S3 实现存储成本优化，活跃数据在 EBS，非活跃数据自动迁移至 S3 +- [[SnapMirror]]：NetApp 数据复制工具，支持跨集群块级同步，基线全量复制后仅同步增量变更 +- [[Snapshot]]：点-in-time 只读文件系统镜像，通过指针创建，最小化空间消耗 +- [[HA Pair (High Availability)]]：高可用配对，通过故障转移机制确保存储服务连续性 +- [[Floating IP]]：HA 架构中的浮动 IP，客户端通过唯一 IP 地址访问，故障时 IP 漂移到备用节点 +- [[Takeover/Giveback]]：HA 接管和归还过程，故障节点的服务切换和恢复 +- [[NetApp Encryption]]：256-bit 加密，支持 AWS KMS 和 NetApp 自身加密解决方案 + +## Key Entities +- [[NetApp]]：全球领先的存储和数据管理解决方案提供商，ONTAP 为其核心操作系统 +- [[Cloud Manager]]：NetApp 的集中管理平台，用于管理 AWS 中的 Cloud Volume ONTAP +- [[FSX for NetApp]]：AWS 原生托管 NetApp 服务（under POC），提供更简化的部署体验 +- [[AWS EBS]]：Elastic Block Store，CVO 的存储后端，支持 GP3、GP2、IO1、IO2、ST1 等多种卷类型 +- [[AWS KMS]]：Key Management Service，NetApp 加密方案的密钥管理集成 +- [[McAfee VSES]]：McAfee 杀毒集成，NetApp 用于 SMB/CIFS 和 NFS 的按访问和按需扫描 +- [[Terraform]]：IaC 工具（under plan），计划用于 NetApp 部署自动化 +- [[Cityscope]]：[监控工具]，组织当前使用的 NetApp 监控平台之一 +- [[WebTool]]：[监控工具]，组织当前使用的 NetApp 监控平台之一 + +## Connections +- [[ctp-topic-44-aws-backup-in-micro-focus]] ← relates_to ← [[ctp-topic-46-netapps-on-aws]]（均涉及企业数据备份与灾备策略） +- [[ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services]] ← relates_to ← [[ctp-topic-46-netapps-on-aws]]（均涉及工作负载从本地向 AWS 迁移） +- [[Cloud Volume ONTAP (CVO)]] ← extends ← [[ONTAP]]（ONTAP 的云版本） +- [[FSX for NetApp]] ← extends ← [[Cloud Volume ONTAP (CVO)]]（AWS 原生管理的 NetApp 服务） +- [[Data Tiering]] ← depends_on ← [[AWS EBS]] + [[AWS S3]] +- [[SnapMirror]] ← used_in ← [[ctp-topic-46-netapps-on-aws]]（灾备复制方案） + +## Contradictions +- 暂无发现内容冲突。本文档主要聚焦 NetApp 存储技术，与 Wiki 中其他 CTP Topic（如 RDS vs Aurora、AWS Backup）属不同技术领域（块存储 vs 数据库备份），互补关系大于冲突。 diff --git a/wiki/sources/ctp-topic-47-enterprise-architecture-cloud-standards.md b/wiki/sources/ctp-topic-47-enterprise-architecture-cloud-standards.md new file mode 100644 index 00000000..2e800c30 --- /dev/null +++ b/wiki/sources/ctp-topic-47-enterprise-architecture-cloud-standards.md @@ -0,0 +1,46 @@ +--- +title: "CTP Topic 47 Enterprise Architecture Cloud Standards" +type: source +tags: [Enterprise-Architecture, Cloud-Standards, CTP, Landing-Zone, Terraform] +sources: [] +last_updated: 2026-04-14 +--- + +## Source File +- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-47-enterprise-architecture-cloud-standards]] + +## Summary（用中文描述） +- 核心主题：企业架构云标准、Landing Zone、云防护栏（Guardrails） +- 问题域：如何在云环境中标准化企业架构，指导应用团队了解可用资源和需求 +- 方法/机制：Landing Zone 框架（账户结构+网络+安全+访问管理+遥测）、Terraform/Terragrunt IaC、云防护栏文档（设计概念+最佳实践） +- 结论/价值：标准化云架构、预配置安全模型、降低应用团队安全审查负担、减少重复造轮子 + +## Key Claims（用中文描述） +- Landing Zone 框架通过聚焦安全、合规和可管理性，为云工作负载提供托管基础 +- 账户结构与开发/预发布/生产环境对齐，角色通过零信任和最小权限原则定义访问控制 +- Terraform 允许以代码形式指定期望环境，促进标准化和可测试性 +- 云防护栏文档捕获强制性要求和最佳实践，指导可扩展性、成本最小化和灵活性 +- 功能分区将单体应用拆分为更小的独立模块或无服务器函数 + +## Key Quotes +> "A landing zone is a framework for hosting cloud workloads, focusing on security, compliance, and manageability." — Lindsay，企业架构师 +> "We want your knowledge collected here for reuse and help other app developers down the road." — Lindsay，号召应用团队贡献防护栏内容 + +## Key Concepts +- [[Landing Zone]]：托管云工作负载的框架，聚焦安全、合规和可管理性，包含账户结构、网络、安全、访问管理和遥测 +- [[Zero Trust Architecture]]：零信任安全架构，通过最小权限原则定义访问控制 +- [[Infrastructure as Code]]：基础设施即代码，使用 Terraform 实现环境标准化和可测试性 +- [[Cloud Guardrails]]：云防护栏文档，捕获强制性要求和最佳实践 +- [[Functional Partitioning]]：功能分区，将单体应用拆分为更小的独立块或无服务器函数 +- [[Terragrunt]]：Terraform 的包装器，用于生成不同环境 + +## Key Entities +- [[Lindsay]]：企业架构师，具有开发背景，以学习者视角分享云架构知识 + +## Connections +- [[ctp-topic-1-gruntwork-landing-zone-architecture]] ← related_to ← [[Landing Zone]]（Topic 1 是 Gruntwork Landing Zone 基础） +- [[Terraform]] ← uses ← [[Infrastructure as Code]] +- [[Cloud Guardrails]] ← guides ← [[Enterprise Architecture Cloud Standards]] + +## Contradictions +- 无已知冲突内容 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 new file mode 100644 index 00000000..8ae362bb --- /dev/null +++ b/wiki/sources/ctp-topic-50-ami-roadmap-for-aws-amis.md @@ -0,0 +1,64 @@ +--- +title: "CTP Topic 50 AMI Roadmap for AWS AMIs" +type: source +tags: [AWS, AMI, Roadmap, CTP] +date: 2026-04-14 +--- + +## Source File +- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-50-ami-roadmap-for-aws-amis]] + +## Summary（用中文描述） +- 核心主题：CCOE AMI 路线图与 AWS 标准 AMI 生命周期规划 +- 问题域：企业 AWS 云环境中操作系统镜像的版本规划、EOL 时间线管理、新 AMI 添加流程 +- 方法/机制：CCOE 每两个月发布一次加固 AMI；路线图按 ADM 需求制定优先级；变更日志通过 CCRE 门户发布；新 AMI 需经过服务集成→功能启用→构建测试三阶段验证 +- 结论/价值：统一企业级 AMI 治理标准；提前规划 OS EOL 迁移；AMI 通过跨账号共享机制分发至所有组织账户 + +## Key Claims（用中文描述） +- CCOE 提供每两个月一次的对齐安全标准的加固 AMI +- 自 2023 年 5 月起，所有 ARM 处理器相关的 AMI 将同步发布 +- AMI 路线图优先级主要由 ADM 需求驱动，变更需通过需求管道流程提交 +- Windows Server 2008/2008 R2 已于 2020 年 1 月 EOL，CentOS 8 已于 2021 年 12 月 EOL，Windows Server 2012 将于 2023 年 10 月 EOL，Red Hat 7 和 CentOS 7 将于 2024 年 6 月 EOL +- AMI 通知通过邮件发送至 CCOE notifications PDL 订阅者 +- CCRE 门户现提供变更日志，记录 CCRE 所做的最新变更 +- AMI 功能包含：域加入服务、启用 SSH、集成 McAfee 防病毒服务、启用 DNS 设置、更新云初始化流程、启用 SSM 客户端、边缘安装 +- AMI 通过跨账号共享（AMI Sharing）分发给组织内所有账户，包括 AMI 本身、EBS 卷和 KMS 密钥 + +## Key Quotes +> "The CCOE provides hardened AMIs on a bi-monthly basis aligned with security standards." — CCOE AMI 发布节奏说明 +> "Starting May 2023, all ARM processors related to AMIs will be released." — ARM AMI 同步发布里程碑 +> "The order was created mainly by ADM requirements. Any requirements to change the prioritization of the roadmap should go through the demand pipeline process." — 路线图优先级机制 +> "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 概念一致） +- [[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 密钥分发给组织内所有账户 +- [[ARM-AMI]]：ARM 处理器架构的 AMI，自 2023 年 5 月起纳入统一发布计划 +- [[CCOE]]：Cloud Center of Excellence，负责提供和维护企业标准 AMI +- [[ADM]]：Architecture Decision Management，AMI 路线图优先级的主要驱动来源 + +## Key Entities +- [[CCOE]]（组织）：Cloud Center of Excellence，负责提供安全加固 AMI 和维护 AMI 路线图 +- [[AWS]]：提供 EC2 AMI 服务，是本话题所有 AMI 的底层平台 +- [[Amazon Linux]]：AWS 自有 Linux 发行版，当前版本包括 Amazon Linux 2 及规划中的 Amazon Linux 2022 +- [[Ubuntu]]：社区支持的 Linux 发行版，CCOE AMI 支持多个 Ubuntu 版本，包括 ARM 版本（自 2023 年 5 月） +- [[CentOS]]：Red Hat 赞助的社区 Linux 发行版，CentOS 7 和 CentOS 8 分别将于 2024 年 6 月和 2021 年 12 月 EOL +- [[Rocky Linux]]：CentOS 替代方案，Rocky 8 和 Rocky 9 纳入 AMI 路线图（2023 年 3 月） +- [[Red Hat Enterprise Linux]]：企业级 Linux 发行版，RHEL 7 将于 2024 年 6 月 EOL +- [[SLES]]（SUSE Linux Enterprise Server）：企业级 Linux 发行版，SLES 15 纳入 AMI 路线图（2022 年 11 月） +- [[Windows Server]]：微软服务器操作系统，Windows 2008/2008 R2 已 EOL，Windows Server 2012 即将 EOL +- [[McAfee]]：企业级防病毒解决方案，集成于 CCOE AMI 中 + +## Connections +- [[ctp-topic-26-standard-ami-build-publish-share-processes]] ← extends ← [[ctp-topic-50-ami-roadmap-for-aws-amis]] +- [[ctp-topic-58-aws-ec2-image-builder]] ← extends ← [[ctp-topic-26-standard-ami-build-publish-share-processes]] +- [[learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2]] ← depends_on ← [[ctp-topic-50-ami-roadmap-for-aws-amis]] +- [[ctp-topic-50-ami-roadmap-for-aws-amis]] ← extends ← [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] + +## Contradictions +- 与 [[ctp-topic-26-standard-ami-build-publish-share-processes]] 存在描述角度差异： + - 冲突点：AMI 叫法不统一——本话题称为"CCOE AMI"，Topic 26 称为"Foundation AMI" + - 当前观点：CCOE AMI 即 Foundation AMI，两者描述的是同一个实体 + - 对方观点：Topic 26 从生命周期管理角度描述（构建→发布→共享），本话题从路线图规划角度描述（版本规划→EOL→新 AMI 添加） + - 结论：非矛盾而是互补关系，共同构成完整的 AMI 管理体系 diff --git a/wiki/sources/ctp-topic-51-architecting-with-aws-purpose-built-databases.md b/wiki/sources/ctp-topic-51-architecting-with-aws-purpose-built-databases.md new file mode 100644 index 00000000..6c26bac6 --- /dev/null +++ b/wiki/sources/ctp-topic-51-architecting-with-aws-purpose-built-databases.md @@ -0,0 +1,64 @@ +--- +title: "CTP Topic 51 Architecting with AWS Purpose-Built Databases" +type: source +tags: + - AWS + - Database + - Purpose-Built + - CTP +date: 2026-04-14 +--- + +## Source File +- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-51-architecting-with-aws-purpose-built-databases]] + +## Summary（用中文描述） +- 核心主题：AWS 专用数据库（Purpose-Built Databases）选型与架构设计原则 +- 问题域：现代应用的数据层设计——如何在多种数据类型和访问模式下选择最优数据库 +- 方法/机制：从用例出发 → 选择最佳工具 → 避免一刀切思维；AWS 提供关系型/NoSQL/内存/图/时序/账本/宽列等全品类专用数据库；DBA 角色从平台管理转向应用创新 +- 结论/价值：正确的数据库选型是应用性能的基础；数据库类型与访问模式的匹配度比"最新最贵"更重要；Duolingo/Netflix/Peloton 等真实案例验证了多数据库混合架构的价值 + +## Key Claims（用中文描述） +- AWS 数据库专家 Femi George 认为：现代应用需要"为正确的应用选择正确的专用数据库"，避免用单一关系型数据库解决所有问题 +- 专用数据库选型应考虑：应用规模、用户数量、访问模式、流量峰值、性能需求（延迟、可用性） +- Duolingo 的多数据库架构：DynamoDB 存储个性化数据 + ElastiCache 缓存高频词/短语 + Aurora 处理事务数据 +- Netflix 使用 DynamoDB 实现高弹性和低延迟 JSON 文档访问 +- Peloton 使用 ElastiCache Redis 为客户提供即时反馈 +- 云时代 DBA 的职能转变：从底层平台管理（备份、补丁）转向应用层创新和查询优化 + +## Key Quotes +> "We need to start thinking of the right purpose-built database for the right application." — Femi George, AWS Database Sales Specialist +> "Amazon Aurora has two flavors, MySQL and PostgreSQL." — Femi George, 强调 Aurora 的双引擎特性 +> "The role of the DBA is evolving in the cloud." — 云时代 DBA 从平台管理转向应用创新 + +## Key Concepts +- [[Purpose-Built-Databases]]：AWS 全品类专用数据库体系——关系型/NoSQL/键值/文档/内存/图/时序/账本/宽列，覆盖所有数据模型 +- [[DBA-Role-Evolution]]：云时代数据库管理员职能转变——从平台管理（备份/补丁）转向应用创新（查询优化/架构设计） +- [[Multi-Database-Architecture]]：多数据库混合架构——根据数据类型选择最优数据库（如 Duolingo：DynamoDB + ElastiCache + Aurora） + +## Key Entities +- [[Amazon-DynamoDB]]：AWS 全托管键值和文档数据库，单位数毫秒性能，日处理万亿级请求 +- [[Amazon-Aurora]]：云原生关系型数据库，支持 MySQL 和 PostgreSQL，存储与计算分离架构 +- [[Amazon-RDS]]：AWS 全托管关系型数据库服务，支持多引擎（MySQL/PostgreSQL/MariaDB/Oracle/SQL Server） +- [[Amazon-ElastiCache]]：AWS 全托管内存缓存服务，支持 Redis 和 Memcached +- [[Amazon-Neptune]]：AWS 图数据库，用于欺诈检测、社交网络、推荐系统 +- [[Amazon-Timestream]]：AWS 时序数据库，专为 IoT 和运维监控场景优化 +- [[Amazon-Keyspaces]]：AWS 托管 Apache Cassandra 兼容数据库，提供无服务器选项 +- [[Amazon-DocumentDB]]：AWS MongoDB 兼容文档数据库，支持灵活 schema +- [[Duolingo]]：多数据库架构实战案例——DynamoDB + ElastiCache + Aurora +- [[Netflix]]：DynamoDB 生产级用户——高弹性、低延迟 JSON 文档访问 +- [[Peloton]]：ElastiCache Redis 生产级用户——即时客户反馈 + +## Connections +- [[Amazon-Aurora]] ← extends ← [[Amazon-RDS]]：Aurora 是 RDS 的云原生演进版本 +- [[Amazon-DynamoDB]] ← alternative_to ← [[Amazon-RDS]]：NoSQL 键值 vs 传统关系型的选型对比 +- [[Amazon-ElastiCache]] ← complements ← [[Amazon-RDS]]：缓存层补充数据库层，提升读取性能 +- [[Amazon-Neptune]] ← specialized_for ← Graph-Use-Cases：图数据库用于关系复杂的场景 +- [[Amazon-Timestream]] ← specialized_for ← Time-Series-Data：时序数据库用于 IoT/监控场景 +- [[ctp-topic-66-rds-vs-aurora]] ← related_to ← [[ctp-topic-51-purpose-built-databases]]：RDS vs Aurora 是关系型数据库内部的选型，本文档覆盖全品类数据库选型 + +## Contradictions +- 与 [[ctp-topic-66-rds-vs-aurora]] 的视角互补而非冲突： + - 冲突点：无实质性冲突，两者是不同维度的对比 + - 当前观点（本文档）：Aurora 是 RDS 的云原生演进，提供存储计算分离和更高 IO 性能 + - 对方观点（CTP 66）：从 PostgreSQL 迁移视角对比，RDS 更适合小规模低成本场景，Aurora 更适合大规模高性能场景 diff --git a/wiki/sources/ctp-topic-58-aws-ec2-image-builder.md b/wiki/sources/ctp-topic-58-aws-ec2-image-builder.md new file mode 100644 index 00000000..f329d641 --- /dev/null +++ b/wiki/sources/ctp-topic-58-aws-ec2-image-builder.md @@ -0,0 +1,57 @@ +--- +title: "CTP Topic 58 AWS EC2 Image Builder" +type: source +tags: + - AWS + - EC2 + - Image-Builder + - CTP + - AMI +date: 2026-04-14 +--- + +## Source File +- [[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 安全扫描 + +## 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 扫描集成正在评估中 + +## 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." — 产品团队通过服务模块添加组件的机制 + +## 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 安全扫描工具 + +## Key Entities +- [[AWS]]：Image Builder 服务的云提供商 + +## 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 自动化策略相关） + +## 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 部署触发 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 new file mode 100644 index 00000000..c216d1cd --- /dev/null +++ b/wiki/sources/ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora.md @@ -0,0 +1,69 @@ +--- +title: "CTP Topic 66 Exposing the differences between PostgreSQL RDS and Aurora" +type: source +tags: + - AWS + - RDS + - Aurora + - PostgreSQL + - CTP +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]] + +## Summary（用中文描述） +- 核心主题：PostgreSQL 在 Amazon RDS 与 Aurora 两种托管方案之间的核心差异对比 +- 问题域：AWS 云数据库选型——何时选 RDS，何时选 Aurora，成本与性能的权衡 +- 方法/机制：从架构设计、最小实例规格、最大扩展能力、自动扩缩容、故障恢复时间、存储灵活性、端点设计、Blue-Green 部署、监控方案及高可用性能调优等多维度进行系统对比 +- 结论/价值：数据库规模 < 10-20TB 优先选 RDS（成本更低、存储选项更灵活）；超过该规模或有严格 RTO 要求（30 秒）则选 Aurora（跨 AZ 六副本架构、自动故障恢复） + +## Key Claims（用中文描述） +- RDS 因架构简单、提供更小规格实例，初始成本低于 Aurora；Aurora 最小规格较高 +- Aurora 单集群最大容量和 IO 性能优于 RDS，适合超过 10-20 TB 的数据库 +- Aurora Serverless v2 支持自动扩缩容，但对实例类型、版本和区域有限制 +- Aurora 的 RTO（恢复时间目标）为 30 秒，RDS 为 2 分钟（AZ 故障场景） +- RDS 提供多种存储类型（GP2、GP3、预置 IOPS、磁性），Aurora 按 IO 计数收费 +- Aurora 采用跨 3 个 AZ 的 6 块 EBS 卷组成的共享集群卷，读副本无需重新复制数据 +- Aurora MySQL 支持 Blue-Green 部署，PostgreSQL 不支持 +- Aurora 使用临时 SSD（短暂存储）用于临时工作，RDS 使用 EBS + +## Key Quotes +> "Aurora IO is generally unbounded because they're motivated to give you as much IO as you can consume because they're charging you per IO." — Aurora 按 IO 收费机制使其有动力提供尽可能高的 IO + +> "With Aurora, you get six EBS volumes. They're spread across three availability zones." — Aurora 跨 3 AZ 的六副本架构是高性能和高可用的基础 + +> "With RDS, you get to choose multiple different storage mechanisms." — RDS 存储灵活性优势 + +## Key Concepts +- [[RTO（Recovery Time Objective）]]：从故障中恢复的时间目标，Aurora 为 30 秒，RDS 为 2 分钟 +- [[Shared Cluster Volume]]：Aurora 的跨 AZ 共享存储卷，6 块 EBS 卷组成，读副本共享同一数据副本无需重新复制 +- [[Blue-Green Deployment]]：Aurora MySQL 支持主备环境切换式部署，用于大版本升级，PostgreSQL 不支持 +- [[Endpoint Architecture]]：Aurora 提供独立的 Writer Endpoint 和 Reader Endpoint，RDS 仅有一个集群端点 +- [[Aurora Global]]：Aurora 跨区域复制方案，支持干净的托管式切换和故障转移 +- [[Temporary Storage]]：Aurora 使用临时 SSD（短暂存储）处理临时工作，固定大小取决于实例类型 + +## Key Entities +- [[AWS]]：Amazon Web Services，提供 RDS 和 Aurora 两款托管数据库服务 +- [[Amazon RDS]]：关系型数据库服务，计算与存储分离（EBS），支持 Multi-AZ 部署 +- [[Amazon Aurora]]：云原生关系型数据库，6 副本跨 3 AZ 共享集群卷架构 +- [[Greg Klau]]：CTP Topic 66 讲师，主讲 PostgreSQL RDS vs Aurora 差异对比 +- [[EBS]]：Elastic Block Store，RDS 的存储后端；Aurora 的底层存储（6 块卷跨 3 AZ） +- [[CloudWatch]]：AWS 监控服务，RDS 和 Aurora 均支持 +- [[Performance Insights]]：AWS 数据库性能监控工具，Aurora 和 RDS 均支持 +- [[JDBC]]：Java Database Connectivity，连接串可配置 reader/writer 端点以提升韧性 + +## Connections +- [[Amazon Aurora]] ← extends ← [[Amazon RDS]] +- [[RTO（Recovery Time Objective）]] ← depends_on ← [[Shared Cluster Volume]] +- [[Blue-Green Deployment]] ← supports ← [[Aurora Global]] +- [[Aurora Global]] ← enables ← [[Multi-Region Failover]] +- [[ctp-topic-51-architecting-with-aws-purpose-built-databases]] ← related_to ← 本页（AWS 数据库选型） +- [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]] ← related_to ← 本页（灾备策略） + +## Contradictions +- 与 [[learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]] 冲突： + - 冲突点：Terraform 部署 RDS 时对存储类型的选择 + - 当前观点：Aurora 按 IO 收费适合高 IO 场景，RDS 提供多种存储类型（GP2/GP3/预置 IOPS）适合成本敏感型场景 + - 对方观点：Terraform IaC 部署关注点是资源标准化和可重复性，存储选型属于运维决策 diff --git a/wiki/sources/ctp-topic-68-introduction-to-redshift.md b/wiki/sources/ctp-topic-68-introduction-to-redshift.md new file mode 100644 index 00000000..b0a05f92 --- /dev/null +++ b/wiki/sources/ctp-topic-68-introduction-to-redshift.md @@ -0,0 +1,63 @@ +--- +title: "CTP Topic 68 Introduction to Redshift" +type: source +tags: + - AWS + - Redshift + - Data-Warehouse + - CTP +date: 2026-04-14 +--- + +## Source File +- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-68-introduction-to-redshift]] + +## 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 是性能优化的关键配置 + +## Key Claims（用中文描述） +- Redshift 通过 Leader Node 管理 Schema、元数据和查询计划，将指令分发至 Compute Node 执行，实现 MPP（大规模并行处理），显著提升查询速度和响应时间 +- Redshift 支持列式存储（适合数据仓库操作）和行式存储两种模式，列式存储因更快的查询性能和更高的内存利用率而更适合 OLAP 场景 +- RA3 实例类型因其成本效益和大规模存储容量而被推荐，底层使用 AWS 托管的 NVMe 存储 +- Sort Key（排序键）和 Dist Key（分布键）是 Redshift 性能优化的核心机制，决定数据分布和查询执行效率 + +## 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 实例优势 + +## 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 上执行查询并返回结果 + +## 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 + +## 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]] + +## 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 部署支持更灵活 diff --git a/wiki/sources/ctp-topic-7-saas-landing-zone-design.md b/wiki/sources/ctp-topic-7-saas-landing-zone-design.md new file mode 100644 index 00000000..037835f4 --- /dev/null +++ b/wiki/sources/ctp-topic-7-saas-landing-zone-design.md @@ -0,0 +1,63 @@ +--- +title: "CTP Topic 7 SaaS Landing Zone Design" +type: source +tags: [] +date: 2026-04-14 +--- + +## Source File +- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-7-saas-landing-zone-design.md]] + +## Summary（用中文描述） +- 核心主题：SAS（生产）Landing Zone 的顶层设计——采用单一 Landing Zone 统一承载所有产品组，而非按产品组（PG）分别构建，以降低开销和成本 +- 问题域：企业多账户 AWS 生产环境下的账户结构设计、共享基础设施规划、自动化部署流水线及远程安全接入方案 +- 方法/机制：核心账户（Shared/Logs/Security）提供集中 AMI/Jenkins/日志/IAM 角色；基线账户（Network/DNS/AD）支撑网络互联和身份认证；共享服务账户（Software Factory/Cyber/ARC/Monitoring）向产品账户提供内部生产服务；Terraform IaC + GitHub/Jenkins CI/CD 实现自动化部署；Checkpoint → Pulse VPN 实现远程安全接入 +- 结论/价值：确立了 SAS LZ 的四大账户层级架构，以及 Terraform + Jenkins + Lambda + ECS 的端到端自动化部署路径 + +## Key Claims（用中文描述） +- SAS Landing Zone 采用单一 Landing Zone 承载所有产品组，区别于 dev labs 中按产品组各自构建 Landing Zone 的模式，以减少开销和成本 +- 核心账户（Core Accounts）包含 Shared（托管 AMI + 主 Jenkins 服务器）、Logs（集中日志账户，仅安全团队可写，产品团队只读自身日志）和 Security（托管 IAM 角色）三个子账户 +- 主 Jenkins 服务器通过 Lambda 函数触发各账户内的 Jenkins slave，禁止将主 Jenkins 直接暴露给任务或凭证，从而增强安全性 +- 基线账户（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 监控入站流量，CloudFront 可选作为 CDN +- 自动化部署：每个账户对应独立 GitHub 仓库，代码变更通过 GitHub Hook 触发 Jenkins → Management VPC → Lambda → ECS Cluster 链路执行部署；Staging 环境测试后才部署生产 +- 远程访问从 Checkpoint VPN 迁移至 Pulse VPN，要求操作员使用 VPN 客户端并通过 AD 认证；未来计划使用 SD1 替换部分网络组件 + +## Key Quotes +> "The SAS landing zone will use a single landing zone for all the product groups." — SAS LZ 的核心设计原则：单一 Landing Zone 服务所有产品组 +> "The workload itself is going to be under private subnet." — 产品账户工作负载必须部署于私有子网 + +## Key Concepts +- [[Landing-Zone-Architecture]]：AWS 多账户基础设施部署单元，本文档定义了 SAS LZ 的账户层级体系（Core/Baseline/Shared Services/Product Accounts） +- [[Active-Directory-Integration]]：通过双 AD 节点实现域加入和资源访问控制，属于 AWS LZ 身份认证基线服务 +- [[Transit-Gateway]]：区域级 Transit Gateway 连接所有账户，Checkpoint Appliance 按标签监控流量，属于 Network 账户核心组件 +- [[WAF-Web-Application-Firewall]]：Web 应用防火墙，监控入站流量，属于产品账户入站安全层 +- [[Private-Subnet-Architecture]]：工作负载部署于私有子网，通过负载均衡器和互联网网关对外暴露，属于产品账户网络架构原则 +- [[Terraform-IaC]]：使用 Terraform 实现 IaC 自动化，每个账户拥有独立 GitHub 仓库管理 Terraform 代码 + +## Key Entities +- [[Gruntwork]]：提供 Landing Zone 参考架构和 Terraform 模块，SAS LZ 基于 Grant Work 架构构建 +- [[TerraGrant]]（TerraGrunt）：用于简化 Terraform 状态管理和跨账户部署的工具 +- [[Jenkins]]：主 Jenkins 服务器托管于 Shared 账户，通过 Lambda 触发各账户 Jenkins slave；每个账户配置独立 Jenkins 服务器 +- [[Checkpoint]]：Checkpoint Appliance 部署于 Network 账户，按标签监控跨账户流量（互联网/On-prem）；当前远程访问使用 Checkpoint VPN（正迁移至 Pulse） +- [[Pulse-VPN]]：新一代远程访问 VPN，通过 AD 认证，要求操作员使用 VPN 客户端 +- [[CloudFront]]：CDN 服务，可选部署于产品账户入站链路 +- [[Qalis]]：Cyber 共享服务账户中的网络安全服务 +- [[OBM]]（Operations Bridge Manager）：Monitoring 共享服务账户中的监控平台 + +## 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-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]] + +## Contradictions +- 与 [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] 的关系： + - 冲突点：ctp-topic-7 定义了 SAS LZ 的详细架构（Core/Baseline/Shared Services/Product 四层账户体系），ctp-topic-35 补充了近期变更（网络分段阻断直接连通性；Checkpoint VPN 迁移至 Pulse VPN） + - 当前观点（ctp-topic-35）：网络分段策略阻断对 SaaS 工作负载的直接连通性；入站流量通过 Network 账户 Checkpoint 重新路由 + - 对方观点（ctp-topic-7）：产品账户的公有子网通过负载均衡器和互联网网关对外暴露；远程访问通过 Checkpoint VPN + - 结论：两个文档描述的是不同时间点的设计状态——ctp-topic-35 反映近期架构变更，ctp-topic-7 反映早期设计原貌，属于设计演进而非冲突 diff --git a/wiki/sources/ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup.md b/wiki/sources/ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup.md new file mode 100644 index 00000000..29bd72c3 --- /dev/null +++ b/wiki/sources/ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup.md @@ -0,0 +1,75 @@ +--- +title: "CTP Topic 72 Implementing an Enterprise DR Strategy Using AWS Backup" +type: source +tags: + - AWS + - DR + - Backup + - Enterprise + - CTP +date: 2026-04-14 +--- + +## Source File +- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]] + +## Summary（用中文描述） +- 核心主题：AWS 解决方案架构师 Sabith 深入讲解企业级灾难恢复策略，以及如何利用 AWS Backup 服务实现 DR 自动化。 +- 问题域：企业级灾难恢复（DR）规划、高可用（HA）与 DR 的区别、RTO/RPO 指标定义与架构设计。 +- 方法/机制： + - HA（高可用）关注系统运行时间和可用性，DR（灾难恢复）关注数据丢失预防和恢复能力 + - RPO（恢复点目标）定义可接受的数据丢失量，RTO（恢复时间目标）定义可接受的停机时间 + - AWS Backup 集中化备份服务，支持跨账户、跨区域复制，Vault Lock 防勒索软件 + - 四级 DR 架构模式：Backup and Restore → Pilot Light → Warm Standby → Active-Active + - 增量备份（Incremental Backup）仅备份自上次备份以来的变更，全量备份（Full Backup）每次捕获所有数据 + - 不可变恢复点（Immutable Recovery Points）+ Vault Lock 合规模式阻止删除 + - Forensic Account（取证账户）定期测试恢复点并扫描恶意软件 +- 结论/价值：为 Micro Focus 云转型计划提供了完整的 DR 策略框架，从基本概念到 AWS Backup 架构设计，是 [[ctp-topic-44-aws-backup-in-micro-focus]] 的理论基础补充。 + +## Key Claims（用中文描述） +- 高可用（HA）衡量系统执行其功能的持续性，通过平均故障间隔时间（MTBF）衡量；灾难恢复（DR）专注于防止数据丢失和系统恢复，HA 专注于系统运行时间和可用性。 +- RPO 定义组织可接受的最大数据丢失量（时间窗口），RTO 定义组织可接受的最大停机时间，两者共同决定 DR 架构选型和成本投入。 +- AWS Backup 是完全托管的、基于策略的备份服务，通过 Backup Plans（备份计划）定义何时备份什么、通过什么方式备份，并将恢复点存储在 Backup Vaults（备份保管库）中。 +- AWS Backup 支持与 AWS Organizations 集成，实现跨账户备份复制（Cross-Account Backup），建议使用独立的 Vault/Bunker Account 存储备份副本，与工作负载账户隔离。 +- 完整备份（Full Backup）每次捕获所有数据，增量备份（Incremental Backup）仅捕获自上次备份以来的变更，节省存储成本。 +- Vault Lock 合规模式（Compliance Mode）防止包括根用户在内的任何人删除恢复点，直至其生命周期结束，有效防御勒索软件攻击。 +- Forensic Account（取证账户）用于定期测试恢复点、扫描恶意软件，确保备份数据的可用性和安全性。 +- AWS Backup Audit Manager（BAM）提供合规报告能力，支持审计备份活动的合规性。 + +## Key Quotes +> "We should always be prepared for a situation that everything falls all the time." — Sabith, AWS 解决方案架构师 +> "High availability ensures a system performs its functions, measured by mean time between failures. Disaster recovery focuses on data loss prevention and recovery, while high availability focuses on system uptime and service availability." — 视频摘要 +> "AWS Backup uses backup plans to define what, when, and how to back up, storing recovery points in backup vaults." — 视频摘要 +> "Vault Lock in compliance mode prevents even root users from deleting recovery points until their lifecycle ends, deterring ransomware." — 视频摘要 + +## Key Concepts +- [[AWS Backup]]：AWS 托管的集中化数据保护服务，通过备份计划（Backup Plans）自动化跨账户、跨区域的数据备份，支持不可变性和合规报告。 +- [[灾难恢复（Disaster Recovery）]]：防止数据丢失和系统停机的策略体系，与高可用（HA）互补，HA 保运行，DR 保数据。 +- [[高可用（High Availability）]]：通过冗余和快速故障转移保持系统持续可用的架构模式，MTBF 是其核心衡量指标。 +- [[RTO（Recovery Time Objective）]]：恢复时间目标，定义从故障恢复到服务可用的最大可接受时间窗口。 +- [[RPO（Recovery Point Objective）]]：恢复点目标，定义可接受的最大数据丢失时间窗口。 +- [[增量备份（Incremental Backup）]]：仅备份自上次备份以来的变更，与全量备份相比节省存储成本和备份时间。 +- [[全量备份（Full Backup）]]：每次备份捕获所有数据，恢复速度快但存储成本高。 +- [[Vault Lock]]：AWS Backup 保管库的合规锁定机制，合规模式下即使根用户也无法提前删除恢复点。 +- [[跨账户备份复制（Cross-Account Backup）]]：通过 AWS Organizations 在不同账户间复制备份，增强隔离性和安全性。 +- [[Bunker Account]]：专用存储备份副本的账户，与工作负载账户隔离，防止单点妥协。 +- [[Forensic Account]]：取证账户，用于定期测试恢复点可用性和恶意软件扫描。 +- [[共享责任模型（Shared Responsibility Model）]]：AWS 与客户在云弹性环境中的责任划分框架。 +- [[AWS Backup Audit Manager（BAM）]]：AWS Backup 的合规审计功能，支持备份活动的合规性报告。 +- [[灾难恢复架构模式]]：Backup and Restore / Pilot Light / Warm Standby / Active-Active 四级递进模式，从低成本低恢复到高成本高弹性。 + +## Key Entities +- [[AWS]]：Amazon Web Services，AWS Backup 服务的提供方。 +- [[Sabith]]：AWS 解决方案架构师，本视频的主讲人。 +- [[Cloud Transformation Programme (CTP)]]：云转型计划，该视频属于 01_AWS-Landing-Zone 系列第 72 个主题。 +- [[Micro Focus]]：企业客户，CTP 的参与方。 + +## Connections +- [[ctp-topic-44-aws-backup-in-micro-focus]] ← extends ← [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]] +- [[ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program]] ← extends ← [[ctp-topic-44-aws-backup-in-micro-focus]] +- [[AWS Backup]] ← related ← [[RTO]] +- [[AWS Backup]] ← related ← [[RPO]] +- [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]] ← depends_on ← [[AWS Backup]] + +## Contradictions +- 无明显内容冲突。本视频与 [[ctp-topic-44-aws-backup-in-micro-focus]] 构成互补关系——Topic 72 提供 DR 策略和 AWS Backup 的理论框架，Topic 44 聚焦 Micro Focus 内部评估和迁移路径，两者共同构成完整的 AWS Backup 知识体系。 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 new file mode 100644 index 00000000..1718297e --- /dev/null +++ b/wiki/sources/ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program.md @@ -0,0 +1,56 @@ +--- +title: "CTP Topic 73 AWS Backup Implementation of the Cloud Transformation Programme" +type: source +tags: + - AWS + - Backup + - Cloud Transformation Programme + - SRE + - DR +date: 2026-04-14 +--- + +## Source File +- [[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 实现"集中管控 + 分散执行"的平衡，标准化备份流程同时保留产品团队灵活性 + +## Key Claims（用中文描述） +- SRE 核心团队通过开发 SRE Backup Model，简化了 AWS Backup 的采纳门槛，使产品组能够在其 DRA 账户内自主创建和管理备份 +- AWS Backup 选择原因：原生托管服务、支持 TAC-based 备份计划、跨账户跨区域复制、备份不可变性、开箱即用审计报告、S3/RDS 点时间恢复 +- 备份设计：初始备份在源账户执行，复制到远程 DR 账户和区域（如 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 账户内以实现即时恢复 + +## Key Concepts +- [[AWS Backup]]：AWS 原生托管备份服务，支持多资源类型的集中备份和恢复策略管理 +- [[SRE Model]]：Site Reliability Engineering 团队开发的备份管理模式，为产品组提供标准化但可定制的备份基础设施 +- [[AWS Backup Audit Manager]]：AWS Backup 内置合规审计框架，提供备份状态报告和合规控制评估 +- [[跨账户备份]]：通过 AWS Organizations 将备份从源账户复制到独立的 DR/Bunker 账户，实现备份隔离 +- [[Vault Lock]]：备份保险库合规锁定模式，防止任何人（包括根用户）提前删除恢复点 + +## 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 账户内管理自有备份 + +## 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 的核心能力） + +## 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/fireworks-tech-graph.md b/wiki/sources/fireworks-tech-graph.md new file mode 100644 index 00000000..0d67371e --- /dev/null +++ b/wiki/sources/fireworks-tech-graph.md @@ -0,0 +1,49 @@ +--- +title: "fireworks-tech-graph" +type: source +tags: [] +date: 2026-04-18 +--- + +## Source File +- [[raw/Skills/fireworks-tech-graph.md]] + +## Summary（用中文描述） +- 核心主题：用自然语言描述系统，几秒内生成可直接发布的 SVG + PNG 技术图 +- 问题域：技术文档/博客/演示缺乏高质量可视化图表，手动绘图耗时且风格不统一 +- 方法/机制：内置 7 种视觉风格（扁平图标/暗黑极客/工程蓝图/Notion极简/玻璃态/Claude官方/OpenAI官方）、14 种 UML 图类型、AI/Agent 领域内建 Pattern，通过 `rsvg-convert` 导出 1920px PNG +- 结论/价值：AI Agent 可快速生成专业级技术图，无需手动绘制，支持 SVG 可编辑 + PNG 无损发布 + +## Key Claims（用中文描述） +- fireworks-tech-graph 将自然语言描述转化为精美的 SVG 技术图，通过 rsvg-convert 导出高分辨率 PNG +- 内置 7 种视觉风格，深度覆盖 AI/Agent 领域常见图类型（RAG、Agentic Search、Mem0、Multi-Agent、Tool Call 流程等） +- 完整支持全部 14 种 UML 图类型 +- AI/Agent 领域内建知识：RAG、Agentic Search、Mem0、Multi-Agent、Tool Call 等常见 Pattern 开箱即用 +- 语义形状词汇表：LLM = 双边框圆角矩形，Agent = 六边形，Vector Store = 带内环圆柱 +- 语义箭头系统：颜色 + 虚线样式编码含义（写入/读取/异步/循环） +- SVG + PNG 双输出：SVG 可编辑，1920px PNG 可直接嵌入文章 + +## Key Quotes +> "不用手画图了。用中文描述你的系统，几秒钟得到可直接发布的 SVG + PNG 技术图。" — 项目 tagline +> "所有示例图均以 1920px 宽度（2× 视网膜分辨率）通过 rsvg-convert 导出为 PNG 格式。技术图应选 PNG（无损），JPG 有损压缩会在文字和线条边缘产生噪点。" — 导出格式建议 + +## Key Concepts +- [[技术图生成]]：用自然语言生成 SVG/PNG 格式的技术架构图、流程图、UML 图 +- [[7种视觉风格系统]]：扁平图标风（默认）、暗黑极客风、工程蓝图风、Notion极简风、玻璃态卡片风、Claude官方风格、OpenAI官方风格 +- [[语义形状词汇表]]：每种概念类型（LLM/Agent/VectorStore/工具等）对应特定 SVG 形状 +- [[语义箭头系统]]：颜色 + 虚线样式编码数据流向（主数据流/控制触发/记忆读取/记忆写入/异步/反馈循环） +- [[14种UML图]]：类图/组件图/部署图/包图/复合结构图/对象图/用例图/活动图/状态机图/序列图/通信图/时序图/交互概览图/ER图 + +## Key Entities +- [[fireworks-tech-graph]]：Claude Code Skill，将自然语言转化为 SVG 技术图，支持 7 种风格和 14 种 UML 图类型 +- [[rsvg-convert]]：librsvg 工具，用于将 SVG 渲染为高分辨率 PNG + +## Connections +- [[fireworks-tech-graph]] ← uses ← [[语义形状词汇表]] +- [[fireworks-tech-graph]] ← uses ← [[语义箭头系统]] +- [[fireworks-tech-graph]] ← implements ← [[7种视觉风格系统]] +- [[fireworks-tech-graph]] ← supports ← [[14种UML图]] +- [[fireworks-tech-graph]] ← outputs ← [[rsvg-convert]] + +## Contradictions +- 无冲突内容 diff --git a/wiki/sources/install-wsl.md b/wiki/sources/install-wsl.md new file mode 100644 index 00000000..09cf83ab --- /dev/null +++ b/wiki/sources/install-wsl.md @@ -0,0 +1,49 @@ +--- +title: "Install WSL" +type: source +tags: [] +date: 2026-04-18 +--- + +## Source File +- [[Home Office/Install WSL]] + +## Summary（用中文描述） +- 核心主题：Windows Subsystem for Linux（WSL）的官方安装与配置完整指南 +- 问题域：Windows 10/11 系统上快速安装 Linux 开发环境，包括单命令安装、多发行版支持、版本管理、离线安装等场景 +- 方法/机制：① `wsl --install` 一键安装；② `-d` 参数切换默认发行版；③ `wsl.exe --set-default-version` 切换 WSL 1/2；④ MSI 包 + DISM 命令离线安装；⑤ Windows Terminal / 开始菜单 / PowerShell 多入口运行 +- 结论/价值：微软官方权威安装文档，提供从零到生产可用的完整路径，WSL2 为默认版本，支持并行运行多个不同 Linux 发行版 + +## Key Claims（用中文描述） +- `wsl --install` 一条命令完成 WSL 全部组件启用和 Ubuntu 默认发行版安装，适用于 Windows 10 version 2004+（Build 19041+）和 Windows 11 +- WSL2 默认使用 NAT 网络模式，通过 `.wslconfig` 配置 `networkingMode=mirrored` 可实现与 Windows 共享网络堆栈（参考 [[WSL2 启动与网络配置指南]]） +- 支持并行安装多个 Linux 发行版（Ubuntu/Debian/SUSE/Kali/Fedora 等），可从 Microsoft Store 下载或导入自定义 TAR 分发版 +- 新安装的 Linux 发行版默认使用 WSL 2，可通过 `wsl.exe --set-version 1` 降级到 WSL 1 +- 离线安装需从 GitHub releases 下载 MSI 安装包，并通过 DISM 命令启用 Virtual Machine Platform 组件 + +## Key Quotes +> "You can now install everything you need to run WSL with a single command." — 微软官方文档 +> "New Linux installations, installed using the `wsl --install` command, will be set to WSL 2 by default." — 微软官方文档 + +## Key Concepts +- [[WSL2]]：Windows Subsystem for Linux 2，Windows 10/11 内置 Linux 虚拟机环境，默认版本，支持完整 Linux 内核 +- [[WSL1]]：WSL 第一代，基于翻译层，性能较差但兼容性好，新发行版默认不使用 +- [[WSL 安装命令]]：`wsl --install` 单命令安装，启用所需功能并安装默认 Ubuntu 发行版 +- [[多发行版支持]]：WSL 支持并行安装运行多个不同 Linux 发行版，可通过 `--distribution` 参数指定运行哪个 +- [[离线安装]]：通过 MSI 包 + DISM 命令手动启用 Virtual Machine Platform 组件，适用于无法联网的环境 + +## Key Entities +- [[Microsoft]]：WSL 官方文档发布方 +- [[Ubuntu]]：WSL 默认安装的 Linux 发行版 +- [[PowerShell]]：Windows 命令行环境，执行 `wsl --install` 的工具（需管理员模式） +- [[Windows Terminal]]：微软官方终端应用，推荐用于运行 WSL，支持多标签页 + +## Connections +- [[WSL2 启动与网络配置指南]] ← related_to ← [[Install WSL]]（安装完成后需参考网络配置指南解决代理问题） +- [[Ubuntu Server]] ← related_to ← [[WSL2]]（WSL2 中的 Ubuntu 与 Ubuntu Server 同属 Ubuntu 系 Linux 环境） + +## Contradictions +- 与 [[WSL2 启动与网络配置指南]] 的侧重点差异： + - 冲突点：本文档聚焦安装过程，未涉及网络配置；[[WSL2 启动与网络配置指南]] 聚焦安装后的网络配置 + - 当前观点：先安装（本文档）→ 后配置网络（[[WSL2 启动与网络配置指南]]），两篇互补 + - 对方观点：WSL2 默认 NAT 网络模式下 localhost 代理不可用，需配置镜像模式才能与 Windows 共享代理 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 new file mode 100644 index 00000000..dc3966e9 --- /dev/null +++ b/wiki/sources/learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2.md @@ -0,0 +1,53 @@ +--- +title: "Learning Sessions: Standard AMI Updates 20231205" +type: source +tags: ["AWS", "AMI", "Landing-Zone", "DevOps", "Automation"] +date: 2023-12-05 +--- + +## Source File +- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2]] + +## Summary（用中文描述） +- 核心主题：AWS 标准 AMI（Amazon Machine Image）的更新机制、构建发布流程及生命周期管理 +- 问题域：企业 AWS Landing Zone 中的操作系统镜像标准化与自动化运维 +- 方法/机制：Jenkins 多分支流水线构建与测试、AWS Inspector 安全扫描、机器人框架自动化验证、SSM 按需打补丁 +- 结论/价值：每两个月发布一次标准化 AMI，将验证周期从 3-4 天缩短至 60 分钟，CentOS 7/RHEL 7 将于 2024 年 6 月 EOL，由 Rocky Linux 替代 + +## Key Claims（用中文描述） +- 标准 AMI 基于 AWS 原生镜像，增加了 OS 加固、最新补丁、安全更新、域名加入、安全工具、端点保护、QALIS Agent、SSM Agent、DNS 设置和 GP3 EBS 存储 +- Jenkins 多分支流水线用于构建和测试 AMI，包括脚本化测试和 AWS Inspector 安全扫描，验证无功能退化 +- AMI 发布流程遵循标准软件开发流程：功能分支开发 → 合并到集成分支 → 构建测试 → 跨区域复制 → 加密共享 → 完整测试套件验证 +- 机器人框架集成将单个 AMI 的验证时间从 3-4 天缩短至 60 分钟 +- 目前支持 23 种不同 AMI，涵盖 Amazon Linux、CentOS、Oracle Enterprise Linux、Red Hat、Rocky Linux、SUSE Linux、Ubuntu 和 Windows Server +- CentOS 7 和 Red Hat 7 将于 2024 年 6 月 EOL，CentOS 7 将由 Rocky Linux 替代（已作为标准 AMI 可用） +- OpenSUSE Leap 15 和 OEL 7 将于 2024 年 12 月 EOL +- AMI 利用率被监控以追踪使用频率和数量 +- SSM 打补丁方案适用于无法频繁刷新的长期运行实例 + +## Key Quotes +> "The AMIs are thrown through all of the test suites, and we'll see a couple of those as they come up in later slides, and then we verify that nothing seems to have regressed at that point." — AMI 测试验证流程说明 + +## Key Concepts +- [[Amazon-Machine-Image]]：AWS 托管的虚拟机镜像模板，标准 AMI 在此基础上增加了 OS 加固、安全补丁、SSM Agent、QALIS Agent 等企业级组件 +- [[Jenkins-Multi-Branch-Pipeline]]：Jenkins 的多分支流水线功能，用于 AMI 的自动化构建、测试和发布，支持功能分支开发和集成分支合并 +- [[AWS-Inspector]]：AWS 安全扫描服务，集成到 AMI 测试流程中用于漏洞检测 +- [[Robotic-Framework]]：自动化测试框架，该会话中用于将 AMI 验证周期从 3-4 天缩短至 60 分钟 +- [[SSM-Patching]]：AWS Systems Manager 补丁管理器，提供适用于长期运行实例的按需打补丁方案 +- [[GP3-EBS-Storage]]：AWS EBS 的第三代通用型固态硬盘存储类型，标准 AMI 默认采用 +- [[OS-End-of-Life]]：操作系统生命周期终止，CentOS 7 和 RHEL 7 将于 2024 年 6 月 EOL，需迁移到 Rocky Linux 等替代品 + +## Key Entities +- [[Rocky-Linux]]：CentOS 7 的官方替代品，已作为标准 AMI 提供，用于应对 CentOS EOL 迁移 +- [[Jenkins]]：CI/CD 平台，托管 AMI 的多分支构建和测试流水线 +- [[QALIS-Agent]]：企业端点保护 Agent，集成在标准 AMI 中 +- [[Sentinel-1]]：新的端点保护方案，正在替代 Trellix（Migrated from Trellix to Sentinel-1） +- [[AWS-SSM]]：AWS Systems Manager，提供 SSM Agent 和补丁管理功能 + +## Connections +- [[ctp-topic-50-ami-roadmap-for-aws-amis]] ← extends ← [[learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2]] +- [[ctp-topic-26-standard-ami-build-publish-share-processes]] ← depends_on ← [[learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2]] +- [[ctp-topic-58-aws-ec2-image-builder]] ← related_to ← [[learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2]] + +## Contradictions +- 暂无已知冲突 diff --git a/wiki/sources/mac必装软件清单-2026-04-17.md b/wiki/sources/mac必装软件清单-2026-04-17.md new file mode 100644 index 00000000..0946932a --- /dev/null +++ b/wiki/sources/mac必装软件清单-2026-04-17.md @@ -0,0 +1,47 @@ +--- +title: "Mac必装软件清单" +type: source +tags: [] +date: 2026-04-17 +--- + +## Source File +- [[Home Office/Mac必装软件清单-2026-04-17.md]] + +## Summary（用中文描述） +- 核心主题：Mac 用户必装软件推荐清单 +- 问题域：macOS 效率工具与生产力软件选型 +- 方法/机制：精选 8 款软件，涵盖 AI、知识管理、浏览器、效率工具、开发工具等类别，每款附推荐理由 +- 结论/价值：用最少的软件达到最高的效率，适合从 Windows 转 Mac 的用户和追求效率的 macOS 用户 + +## Key Claims（用中文描述） +- Claude 是 AI 时代必备工具，桌面版 Cowork 功能专为文字工作者打造 +- Obsidian 搭配 Claudian 插件可打造 AI 驱动的终极个人知识库 +- Raycast 是替代 Spotlight 的万能启动器，计算器和剪贴板功能超好用 +- Homebrew 是用 Claude Code 搭 Agent 的前置依赖 + +## Key Quotes +> "用最少的软件，达到最高的效率。" — Claw小龙虾 + +## Key Concepts +- [[Raycast]]：替代 Spotlight 的 macOS 万能启动器，支持计算器、剪贴板历史等功能 +- [[Obsidian]]：本地优先的笔记与知识管理工具，支持双向链接 +- [[Homebrew]]：macOS 包管理器，是开发工具安装的事实标准 + +## Key Entities +- [[Claude]]：Anthropic 开发的 AI 助手，桌面版 Cowork 功能专为文字工作者设计 +- [[Chrome]]：Google 浏览器，比 Safari 更好用，Gmail 用户的不二之选 +- [[Rectangle]]：免费分屏工具，大屏办公必备 +- [[iShot]]：简洁免费的 macOS 截图工具，支持圆角截图 +- [[Lemon]]：轻量 Mac 系统清理工具 +- [[Homebrew]]：macOS 包管理器 +- [[Claw小龙虾]]：Telegram频道「Hermes爱马仕&🦞OpenClaw小龙虾」作者 + +## Connections +- [[Obsidian]] ← 搭配 ← [[Claudian插件]] +- [[Obsidian]] ← 关联 ← [[Second Brain]] +- [[Homebrew]] ← 依赖 ← [[Claude Code]] +- [[Raycast]] ← 替代 ← [[Spotlight]] + +## Contradictions +- 无冲突内容 diff --git a/wiki/sources/wsl2-启动与网络配置指南.md b/wiki/sources/wsl2-启动与网络配置指南.md new file mode 100644 index 00000000..ab095629 --- /dev/null +++ b/wiki/sources/wsl2-启动与网络配置指南.md @@ -0,0 +1,42 @@ +--- +title: "WSL2 启动与网络配置指南" +type: source +tags: [] +date: 2026-04-17 +--- + +## Source File +- [[Home Office/WSL2 启动与网络配置指南]] + +## Summary（用中文描述） +- 核心主题：WSL2（Windows Subsystem for Linux 2）的安装启动与网络配置实操指南 +- 问题域：Windows 环境下 Linux 开发环境搭建，重点解决 WSL2 网络隔离导致的 GitHub/海外资源访问障碍 +- 方法/机制：① `wsl --install` 快速安装；② `.wslconfig` 启用镜像网络模式（mirrored mode）实现 WSL2 与 Windows 共享网络堆栈；③ 终端代理环境变量手动配置；④ ghproxy.com 反向代理绕过网络限制 +- 结论/价值：提供从零安装到生产可用的完整 WSL2 配置路径，镜像网络模式是最稳妥的解决方案，避免 NAT 模式下的 localhost 代理失效问题 + +## Key Claims（用中文描述） +- WSL2 默认使用 NAT 模式，导致 Windows 宿主机 localhost 代理无法被 WSL2 内部正确访问，这是 GitHub/海外资源连接失败的根本原因 +- 在 `.wslconfig` 中设置 `networkingMode=mirrored` + `dnsTunneling=true` + `autoProxy=true` 可使 WSL2 与 Windows 共享网络堆栈，是解决网络问题的推荐方案 +- 使用 `ghproxy.com` 反向代理可绕过 GitHub 访问限制，适用于 uv 安装器、Hermes Agent 等工具的下载场景 + +## Key Quotes +> "WSL2 默认使用 NAT 模式，常会出现'localhost 代理无法镜像'或无法访问海外资源的情况。" — 背景说明 +> "在 PowerShell 执行 `wsl --shutdown` 后重启 WSL。" — 镜像模式生效操作 + +## Key Concepts +- [[WSL2]]：Windows Subsystem for Linux 2，Windows 10/11 内置的 Linux 虚拟机环境，默认使用 NAT 网络模式 +- [[镜像网络模式]]（Mirrored Network Mode）：WSL2 与 Windows 共享网络堆栈的配置模式，使 WSL2 能直接访问 Windows 代理 +- [[NAT模式]]：WSL2 默认网络模式，WSL2 拥有独立 IP，localhost 代理不可用 +- [[ghproxy]]：ghproxy.com，反向代理服务，将 GitHub 资源 URL 替换为代理地址以绕过网络限制 + +## Key Entities +- [[Ubuntu]]：WSL2 默认安装的 Linux 分发版 +- [[Windows]]：宿主操作系统，WSL2 运行其上 +- [[PowerShell]]：Windows 命令行环境，用于执行 wsl 管理命令 + +## Connections +- [[Ubuntu Server]] ← related_to ← [[WSL2]]（WSL2 是 Ubuntu 在 Windows 上的轻量运行方式） +- [[ubuntu-server科学上网]] ← related_to ← [[WSL2 网络配置]]（均涉及 Linux 环境代理配置） + +## Contradictions +- （无已知冲突） diff --git a/wiki/sources/实战笔记-本地部署-rsshub-并获取-youtube-订阅.md b/wiki/sources/实战笔记-本地部署-rsshub-并获取-youtube-订阅.md new file mode 100644 index 00000000..a2ab3386 --- /dev/null +++ b/wiki/sources/实战笔记-本地部署-rsshub-并获取-youtube-订阅.md @@ -0,0 +1,51 @@ +--- +title: "实战笔记：本地部署 RSSHub 并获取 YouTube 订阅" +type: source +tags: ["Home Office", "RSSHub", "YouTube", "Docker"] +date: 2026-04-21 +--- + +## Source File +- [[Home Office/实战笔记：本地部署 RSSHub 并获取 YouTube 订阅]] + +## Summary（用中文描述） +- 核心主题：本地自托管 RSSHub 并通过其生成 YouTube 频道 RSS 订阅源 +- 问题域：YouTube 官方不直接提供 RSS，且第三方在线 RSS 服务不稳定 +- 方法/机制： + - Docker Compose 一键部署 RSSHub（port 1200） + - 获取 YouTube 频道 ID（浏览器 view-source 方式） + - RSSHub 路由格式 `/youtube/channel/{channel_id}` 生成 RSS 源 + - 支持订阅列表监控 +- 结论/价值：完全自托管，稳定可靠，绕过 YouTube 官方限制 + +## Key Claims（用中文描述） +- RSSHub Docker 部署命令：`docker run -d --name rsshub -p 1200:1200 diygod/rsshub` +- YouTube 频道 ID 获取方式：浏览器访问频道页面 URL，`view-source:` 查看源码搜索 `channel_id` +- RSSHub YouTube RSS 路由：`http://localhost:1200/youtube/channel/{channel_id}` +- 支持订阅列表路由：`/youtube/channel/{channel_id}/videos` 获取该频道视频列表 + +## Key Quotes +> "RSSHub 是一个开源、简单易用、方便扩展的 RSS 生成器" — RSSHub 官方定位 + +> "获取 YouTube 频道 ID 的方法：访问频道页面 → view-source → 搜索 channel_id" — 频道 ID 获取技巧 + +## Key Concepts +- [[RSSHub]]：开源 RSS 聚合生成器，可为不支持 RSS 的网站生成订阅源 +- [[Docker]]：容器化平台，RSSHub 通过 Docker 一键部署 +- [[RSS]]：Really Simple Syndication，网站内容聚合订阅协议 + +## Key Entities +- [[diygod]]（DIYgod）：RSSHub 项目的主要维护者，Docker 镜像 `diygod/rsshub` 的发布者 +- [[YouTube]]：视频平台，本场景的 RSS 订阅目标 + +## Connections +- [[RSSHub]] ← 使用 Docker 部署 ← [[Docker]] +- [[RSSHub]] ← 为 [[YouTube]] 生成 RSS ← [[YouTube Content Pipeline]] +- [[YouTube Content Pipeline]] ← 依赖 RSS 监控 ← [[RSSHub]] + +## Contradictions +- 与 [[How to Get the RSS Feed For Any YouTube Channel]] 略有差异： + - 冲突点：在线获取 vs 本地生成 + - 当前观点：本地 RSSHub 部署更稳定可靠 + - 对方观点：在线服务无需维护，适合临时使用 + - 结论：两者互补使用——RSSHub 主用 + 在线工具备用