Auto-sync
This commit is contained in:
@@ -11,7 +11,7 @@ tags:
|
||||
date-added: 2026-04-14
|
||||
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 1_ Gruntwork Landing Zone Architecture.mp4"
|
||||
audio-source: ""
|
||||
status: raw
|
||||
status: summarized
|
||||
---
|
||||
|
||||
# CTP Topic 1 Gruntwork Landing Zone Architecture
|
||||
@@ -20,32 +20,70 @@ status: raw
|
||||
|
||||
**Type:** VIDEO | **Category:** 01_AWS-Landing-Zone
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
**Status:** ✅ 已完成（Gemini 摘要）
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
本次会议主要讨论了基于 Gruntwork 的云平台 Landing Zone 架构，以及如何在云转型项目中应用最佳实践。Gruntwork 是一个拥有大量 Terraform 代码的组织，其代码经过多次实践验证，被认为是最佳实践。会议介绍了参考架构（Reference Architecture）和 Landing Zone 的概念，以及它们在不同环境和账户中的实现方式。参考架构是一个起点，包含共享、日志和安全等核心账户，以及生产、测试和开发等工作负载账户。Landing Zone 基于 Gruntwork，但不包含具体的 ECS 集群或 RDS 数据库，而是由产品团队自行定义。安全账户使用联邦用户，通过 AD 组映射到 IAM 角色。会议还强调了 Jenkins 在 CI/CD 流程中的作用，每个 Landing Zone 都有一个 Jenkins 服务器来部署基础设施变更，每个产品团队也有自己的 Jenkins 任务来部署其负责的基础设施。此外，会议还讨论了 Git 工作流，强调使用特性分支进行开发，并通过 Pull Request 合并到主分支。最后，会议介绍了 Gruntwork 的 Terraform AWS 服务目录，强调服务应具有业务上下文，而非简单的资源。
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
- **参考架构 (Reference Architecture)**: 一套最佳实践的集合，作为云平台部署的起点，包含核心账户和工作负载账户。
|
||||
- **Landing Zone**: 基于 Gruntwork 的云平台环境，包含安全、共享和日志等核心账户，以及由产品团队自定义的工作负载账户。
|
||||
- **联邦用户 (Federated User)**: 通过 AD 组映射到 IAM 角色，用于访问云平台资源，替代了传统的 IAM 用户。
|
||||
- **CI/CD 流程**: 使用 Jenkins 进行持续集成和持续交付，通过特性分支、Pull Request 和审批流程来管理基础设施变更。
|
||||
- **Terraform AWS 服务目录**: Gruntwork 提供的 Terraform 模块集合，用于构建具有业务上下文的云服务。
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
- [ ] 熟悉 Gruntwork 的 Terraform AWS 服务目录，了解可用的模块和服务。
|
||||
- [ ] 遵循 Git 工作流，使用特性分支进行开发，并通过 Pull Request 合并到主分支。
|
||||
- [ ] 了解 Jenkins 在 CI/CD 流程中的作用，以及如何配置 Jenkins 任务来部署基础设施变更。
|
||||
- [ ] 熟悉联邦用户的配置方式，以及如何通过 AD 组映射到 IAM 角色。
|
||||
- [ ] 确定 Active Directory 连接的具体配置，特别是 corp.joml 还是 swing throw。
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
> [!info]+ 交叉引用
|
||||
> [[ctp-topic-XX-git-workflow.md]] — 详细解释了 Git 工作流的最佳实践。
|
||||
|
||||
|
||||
## 关键概念
|
||||
|
||||
- **Reference Architecture**: 包含核心账户（Shared/Logs/Security）和工作负载账户（Prod/Stage/Dev）的最佳实践起点
|
||||
- **Landing Zone**: 基于 Gruntwork 仓库的基础设施部署单元，每个 Zone 有独立 GitHub 仓库管理 IaC
|
||||
- **Federated Access**: 通过 AD 组映射到 IAM 角色的联邦身份访问，简化安全账户管理
|
||||
- **Gruntwork Modules**: 经过实战验证的 Terraform 模块，提供业务上下文和粒度支持
|
||||
- **CI/CD Pipeline**: 基于特性分支 + PR + Jenkins 的基础设施变更自动化流程
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
## 行动项
|
||||
|
||||
- [ ] 熟悉 Gruntwork Terraform AWS Service Catalog，了解可用模块
|
||||
- [ ] 采用特性分支开发流程，通过 PR 合并到主分支
|
||||
- [ ] 配置 Jenkins 流水线，实现 Terraform Plan/Apply 自动化
|
||||
- [ ] 探索 TerraTest 用于基础设施变更的自动化测试
|
||||
- [ ] 确定 Active Directory 联邦访问的具体配置方案
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> [!info]+ 交叉引用
|
||||
> [[ctp-topic-2-git.md]] — Git 版本控制基础（CI/CD 前提）
|
||||
> [[ctp-topic-3-deploy-and-maintain-infrastructure.md]] — Terraform 部署与维护
|
||||
> [[ctp-topic-9-ci-cd-with-gruntwork.md]] — Gruntwork CI/CD 流水线实践
|
||||
> [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md]] — Landing Zone 安全配置
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-15*
|
||||
|
||||
@@ -11,7 +11,7 @@ tags:
|
||||
date-added: 2026-04-14
|
||||
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 63_ Optimise resource cost using automation.mp4"
|
||||
audio-source: ""
|
||||
status: raw
|
||||
status: summarized
|
||||
---
|
||||
|
||||
# CTP Topic 63 Optimise resource cost using automation
|
||||
@@ -26,10 +26,38 @@ status: raw
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
本次云转型学习会议的主题是“使用自动化优化资源成本”。会议重点介绍了如何通过标准化、合理选择实例类型、利用承诺计划以及实施自动化调度等方式来降低云资源成本。首先，强调了使用批准区域的重要性，这有助于提高安全性、标准化管理，并为优化计算和存储提供基础。其次，详细讲解了如何根据工作负载选择合适的实例类型，例如通用型、经济型、计算密集型和内存密集型，并给出了具体的实例家族推荐和成本对比示例。此外，会议还介绍了AWS和Azure等云服务商提供的承诺计划，通过长期承诺可以显著降低成本。最后，重点介绍了通过自动化调度来优化资源使用，尤其是在研发环境中，通过在非工作时间自动停止实例，可以有效降低成本。会议还提及了存储优化，包括使用GP3替代GP2，及时删除未使用的存储卷和快照，以及合理分配存储空间。
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
- **批准区域**: 建议使用的云资源部署区域，有助于提高安全性、标准化管理和优化成本。
|
||||
- **实例类型选择**: 根据工作负载选择合适的实例家族（如M系列、T系列、C系列、R系列），以优化性能和成本。
|
||||
- **承诺计划**: 通过预先承诺使用云资源一段时间（如一年或三年），获得折扣价格。
|
||||
- **自动化调度**: 通过设置定时任务，自动启动和停止云资源，以节省非工作时间的资源成本。
|
||||
- **存储优化**: 通过选择合适的存储类型（如GP3替代GP2），及时清理无用存储，合理分配存储空间来降低存储成本。
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
- [ ] 评估现有云资源的使用情况，确定可以迁移到批准区域的资源。
|
||||
- [ ] 分析不同工作负载的资源需求，选择合适的实例类型，并进行成本效益分析。
|
||||
- [ ] 评估现有云资源的使用率，考虑购买承诺计划以降低成本。
|
||||
- [ ] 在研发环境中实施自动化调度，设置定时任务自动启动和停止实例。
|
||||
- [ ] 定期清理未使用的存储卷和快照，优化存储成本。
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> [!info]+ 交叉引用
|
||||
> [[ctp-topic-XX-instance-types.md]] — 详细介绍不同实例类型的适用场景和成本效益。
|
||||
> [[ctp-topic-XX-ri-savings-plan.md]] — 深入讲解承诺计划的类型和选择策略。
|
||||
> [[ctp-topic-XX-scheduler-demo.md]] — 演示如何使用自动化调度工具来优化资源成本。
|
||||
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
@@ -28,23 +28,41 @@ status: summarized
|
||||
|
||||
## 摘要
|
||||
|
||||
> 本次分享是 SRE 职能负责人 Brendan Starnig 主持的"变更管理"专题，目标是统一 Cloud Transformation Program 中各团队对变更流程的认知，厘清 SRE 与支持团队的协作边界。核心内容包括：
|
||||
>
|
||||
> **SRE 本质**：SRE 是用软件工程思维解决运维问题，任何重复性工作都应自动化，核心职责涵盖可用性、延迟、性能、变更管理、监控、应急响应、容量规划。SRE 与 DevOps 的关系是"SRE 是 DevOps 的特定实现并有所扩展"。
|
||||
>
|
||||
> **变更分类**：Standard Change（预批准、全自动化）、Normal Change（需 CAB 审批、需变更窗口）、Emergency Change（快速响应以缓解 Incident）、CAPA（Post-mortem 回顾）。目标是尽可能将 Normal Change 归入 Standard Change 池。
|
||||
>
|
||||
> **Cloud Transformation 三阶段**：Build & Setup（创建 Landing Zone 账户，最佳实践是 IaC + 不可变基础设施）→ Early Live Support（交接检查清单：SLO/SLR 定义、监控覆盖率、支持模型）→ BAU（进入正式变更管理流程）。
|
||||
>
|
||||
> **事件与 Incident**：通过 SMACs + Teams Channel 接收告警，区分 Informational、Exception、Problem Management、Incident Management 四级响应。Incident 按 Severity 分级：Severity 1/2 为 Major Incident，需紧急协调；Severity 3/4 为 Degraded Service。
|
||||
>
|
||||
> **服务请求**：通过 SMACs Service Request Portal → Public Cloud Operation Services 提交流程（新账户开通、权限申请等）。当前支持渠道：SRE Support Teams Channel 或直接联系 Brendan。
|
||||
>
|
||||
> **下一步重点**：定义 SLR/SLO 体系并向产品团队定期汇报；推进 Change Record 自动化；探索 Self-healing 与机器学习驱动的监控自动化。
|
||||
本次会议由 Brendan Starnig 主讲，主要讨论了在云转型项目中如何管理变更，特别是在与 SRE（站点可靠性工程）团队和其他支持团队的交互方面。会议旨在提高大家对 SRE 角色、服务定义以及变更管理流程的认识，并确保所有参与者对相关流程和工具（如 PPM、SMACs 和 Octane）有统一的理解。
|
||||
|
||||
会议涵盖了 SRE 的核心职责，强调了其在自动化重复性工作、提高系统可靠性和可测试性方面的作用。同时，会议还区分了不同类型的变更（标准变更、正常变更和紧急变更），并阐述了它们各自的处理流程。此外，会议还讨论了事件与事故的区别，以及在 SMACs 中如何区分和处理它们。
|
||||
|
||||
最后，会议强调了在云转型项目中，SRE 团队与产品团队之间的协作，以及在不同阶段（构建和设置、早期上线支持和 BAU）如何与 SRE 团队进行交互。会议旨在确保所有参与者都清楚地了解变更管理流程，以及如何有效地利用 SRE 团队来支持云转型项目。
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
- **SRE (站点可靠性工程)**: 通过软件工程的思维方式解决运维问题，核心在于自动化重复性工作，提高系统可靠性和可测试性。
|
||||
- **标准变更**: 预先批准的变更，不需要变更咨询委员会（CAB）的批准，应尽可能实现完全自动化。
|
||||
- **正常变更**: 包含一定风险或影响的变更，需要 CAB 批准，并可能需要跨团队协调。
|
||||
- **紧急变更**: 为了缓解事故并尽快恢复服务到期望状态而需要立即执行的变更。
|
||||
- **事件 vs. 事故**: 在 SMACs 中，事件是触发警报的低级别事件，而事故是超出计划外的服务中断或服务质量下降，对客户的影响较大。
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
- [ ] 评估现有变更流程，识别可自动化并转化为标准变更的环节。
|
||||
- [ ] 明确各团队与 SRE 团队在不同阶段（构建、上线支持、BAU）的交互方式和责任范围。
|
||||
- [ ] 确保所有团队成员都了解并正确使用 PPM、SMACs 和 Octane 等工具进行变更、事件和任务管理。
|
||||
- [ ] 完善监控覆盖，确保所有关键服务和基础设施都得到充分监控，并定义明确的 SLO 和 SLI。
|
||||
- [ ] 建立清晰的事件响应和升级流程，确保问题能够及时得到解决。
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> [!info]+ 交叉引用
|
||||
> [[ctp-topic-XX-incident-management.md]] — 讨论了事件管理流程，与本次会议中关于事件和事故的区分相关。
|
||||
> [[ctp-topic-XX-sre-practices.md]] — 深入探讨了 SRE 的实践方法，与本次会议中 SRE 的角色和职责相关。
|
||||
|
||||
|
||||
## 关键概念
|
||||
|
||||
- **SRE (Site Reliability Engineering)**: 用软件工程思维解决运维问题，追求可靠性、可测试性、可重复性，核心是打破运维与产品的壁垒
|
||||
|
||||
Reference in New Issue
Block a user