wiki ingest: batch 2 (+2 docs, Claude Skills & NotebookLM)
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 20_ Program demand process flow and PoC onboarding.mp4"
|
||||
audio-source: ""
|
||||
status: raw
|
||||
status: summarized
|
||||
---
|
||||
|
||||
# CTP Topic 20 Program demand process flow and PoC onboarding
|
||||
@@ -26,21 +26,34 @@ status: raw
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
> 本次会议是云转型计划（Cloud Transformation Program）系列学习课的一部分，由专家 Sergio 和 Damian 主讲，核心内容围绕“程序需求流程（Program Demand Process Flow）”以及“概念验证（POC）”的实施路径展开。
|
||||
|
||||
会议首先介绍了从业务需求录入到最终迁移至 Labs 或 SaaS 环境的全生命周期流程。该流程始于业务端的转型需求，经过优先级排序后，团队需决定是否进行 POC。为了确保治理的严谨性，流程中设置了多个关键网关（Gates）：Gate 0 用于评估准入，Gate 1 负责设计权威（Design Authority）审批，Gate 3 则作为启动迁移的最终准入。
|
||||
|
||||
POC 被强调为降低迁移风险的核心环节。其主要目的不仅是验证架构和技术可行性，还包括让团队熟悉基于 Gruntwork 构建的新一代 Landing Zone。与传统的“经典落地分区”不同，新环境强调基础设施即代码（IaC），要求使用 Terraform 和 Terragrunt 进行自动化部署，严禁手动构建。POC 的预期成果包括经过验证的解决方案设计、准备就绪的 IaC 脚本以及明确的迁移时间表。
|
||||
|
||||
在需求管理方面，专家指出需求主要由业务案例（如数据中心关闭）、高层管理人员的战略优先级以及产品组的路线图驱动。会议最后提到，POC 的成功标准应在启动前明确定义，以确保测试活动能够有效证明产品已具备进入生产环境迁移的条件。
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
- **Program Demand Process Flow**: 程序需求处理流程，指从业务需求产生、优先级排序到最终交付迁移的端到端管理路径。
|
||||
- **Proof of Concept (POC)**: 概念验证，在正式迁移前用于证明架构可行性、测试复杂网络需求及验证迁移方法的实验性阶段。
|
||||
- **Landing Zone**: 落地分区，指云端预配置的、符合安全与合规标准的标准化基础架构环境。
|
||||
- **Infrastructure as Code (IaC)**: 基础设施即代码，通过脚本（如 Terraform）而非手动操作来定义和管理云资源的方法。
|
||||
- **Gate Process**: 网关审批流程，用于治理项目进度的关键决策点，例如 Gate 0（评估准入）和 Gate 3（迁移准入）。
|
||||
- **Terraform / Terragrunt**: 视频中提到的核心 IaC 工具，用于编写和管理云基础设施的配置脚本。
|
||||
- **Solution Design**: 解决方案设计，在 POC 阶段需完成并经过设计权威审批的架构文档，确保符合云原生原则。
|
||||
- **PCG Team**: 平台控制组，负责提供云环境支持、安全策略制定及协助产品组进行 POC 的核心技术团队。
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
## 相关视频
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
> [!info]+ 交叉引用
|
||||
> [[Introduction to PCG Team]] — 本视频末尾提到了 PCG 团队的简介，并指出曾有专门的 Session 详细介绍该团队的职责。
|
||||
> [[Cloud Transformation Strategy Overview]] — 视频中 Damian 提到的关于 Matt 讲解的战略优先级和整体愿景的背景参考。
|
||||
|
||||
## 相关视频
|
||||
|
||||
|
||||
@@ -10,7 +10,7 @@ tags:
|
||||
date-added: 2026-04-14
|
||||
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 23_ Introduction to the Technical Architecture team and function.mp4"
|
||||
audio-source: ""
|
||||
status: raw
|
||||
status: summarized
|
||||
---
|
||||
|
||||
# CTP Topic 23 Introduction to the Technical Architecture team and function
|
||||
@@ -25,21 +25,33 @@ status: raw
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
> 本次会议由云转型办公室（Cloud Transformation Office）主办，主讲人 Martin Nash（技术架构经理）详细介绍了技术架构团队的核心职能、组织架构及其在公司云转型进程中的价值。背景在于公司近期将 PSTC 与 IT 部门整合至 CIO 统一领导下，这一变革如同两个大型组织的合并，涉及基础设施、流程与治理模式的深度融合。
|
||||
>
|
||||
> 演讲的核心主题是“从被动响应转向主动规划”。Martin 强调了技术架构团队在维护 AWS Enterprise Landing Zones（企业落地分区）方面的努力，旨在通过标准化和治理确保云环境的安全与高效。团队推行“云优先（Cloud-first）”策略，主张除非因数据主权、合规性或极端成本原因必须保留在本地（On-premises），否则所有新业务应优先上云。
|
||||
>
|
||||
> 此外，Martin 阐述了三种架构职能的分工：企业架构（EA）对接业务战略，方案架构（SA）负责中间件与服务优化，而技术架构（TA）则专注于底层技术实施与基础设施治理。通过将技术划分为不同的“技术领域（Technical Domains）”并由首席架构师负责，团队能够制定 12-24 个月的前瞻性路线图（Roadmaps），从而帮助业务部门规避潜在风险、优化预算并提升交付速度，最终实现从繁杂的基础设施维护中解放出来，专注于为客户创造价值。
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
- **AWS Enterprise Landing Zones**: 一套预配置的、符合最佳实践的 AWS 多账号环境，用于提供统一的治理、安全和网络连接标准。
|
||||
- **Cloud-First Strategy**: 一种架构原则，规定在部署新服务时首选云解决方案，仅在有明确合规或技术限制时才考虑本地部署。
|
||||
- **Technical Domains**: 将公司技术栈划分为特定的领域（如身份认证、网络、Microsoft 堆栈等），每个领域由专人负责其生命周期与路线图。
|
||||
- **Enterprise Architecture (EA)**: 架构体系的高层，主要负责将业务目标转化为技术原则和标准，确保技术投资与商业战略一致。
|
||||
- **Solution Architecture (SA)**: 架构体系的中间层，专注于特定项目或服务的优化实施，确保系统组件间的高效协作。
|
||||
- **Technical Architecture (TA)**: 最贴近技术的架构层，负责具体基础设施的设计、实施治理以及技术路线图的维护。
|
||||
- **Roadmaps**: 针对各技术领域制定的 12-24 个月前瞻性规划，旨在从“救火式”响应转变为预测性规划，辅助预算与决策。
|
||||
- **ITIL Alignment**: 将架构工作与 IT 服务管理框架（如服务战略、设计、持续改进）相结合，确保技术交付的系统性。
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
## 相关视频
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
> [!info]+ 交叉引用
|
||||
> [[AWS Enterprise Landing Zone Deep Dive]] — 关联原因：文中多次提到 Landing Zones 的治理与演进。
|
||||
> [[Cloud Governance and Compliance Standards]] — 关联原因：涉及文中提到的云端操作标准与合规性控制。
|
||||
> [[Infrastructure Rationalization Post-Acquisition]] — 关联原因：Martin 提到了 Project Cornwall 后的环境整合与遗留系统清理。
|
||||
|
||||
## 相关视频
|
||||
|
||||
|
||||
@@ -5,11 +5,13 @@ source-type: video
|
||||
category: "DevOps & SRE/10_OpenText-Series"
|
||||
tags:
|
||||
- Change-Management
|
||||
- SRE
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 30_ Managing change.mp4"
|
||||
audio-source: ""
|
||||
status: raw
|
||||
audio-source: "/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 30_ Managing change.mp3"
|
||||
transcript-source: "/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 30_ Managing change.txt"
|
||||
status: summarized
|
||||
---
|
||||
|
||||
# CTP Topic 30 Managing change
|
||||
@@ -18,32 +20,64 @@ status: raw
|
||||
|
||||
**Type:** VIDEO | **Category:** 10_OpenText-Series
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
**Status:** ✅ 已完成
|
||||
|
||||
**讲者:** Brendan Starnig (SRE Function Lead, Platform Engineering)
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
> 本次分享是 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 与机器学习驱动的监控自动化。
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
- **SRE (Site Reliability Engineering)**: 用软件工程思维解决运维问题，追求可靠性、可测试性、可重复性，核心是打破运维与产品的壁垒
|
||||
- **Standard Change**: 预批准变更，无需 CAB，应完全自动化（IaC + CI/CD Pipeline）
|
||||
- **Normal Change**: 有风险/影响，需 CAB 审批和变更窗口，理想状态是尽可能归入 Standard Change
|
||||
- **Emergency Change**: 需立即执行以缓解 Incident，事后通过 CAPA/Post-mortem 修复根因
|
||||
- **CAPA (Corrective and Preventive Action)**: 即 Post-mortem 回顾，目的是从 Incident 中提取根因并预防同类问题再次发生
|
||||
- **Landing Zone (Gruntwork)**: Micro Focus 新一代云基础设施架构，取代经典 On-premise Data Centers
|
||||
- **SLO/SLR (Service Level Objective/Requirement)**: 服务等级目标和需求，用于定义监控指标并向上汇总至 KPI
|
||||
- **Early Live Support**: Build 与 BAU 之间的过渡阶段，需完成 Go-Live Checklist（监控覆盖、支持模型、事件响应流程）
|
||||
- **SMACs**: 当前使用的 ITSM 工具（Service Management Automation X），用于 Ticket、Incident、Change 管理
|
||||
- **Self-Healing**: 通过机器学习驱动的自动化监控系统，基于告警趋势自动决策和缓解问题（目前处于探索阶段）
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
- [ ] SRE 团队正与产品团队协作定义 SLR/SLO 体系，目标向产品团队做周/双周/月度指标汇报
|
||||
- [ ] 推进 Change Record（CR）自动化，实现通过 CI/CD Pipeline 自动创建和关闭 CR
|
||||
- [ ] 制定统一的账户命名规范（当前 R&D/Labs、Staging、PQM、Production 等命名混乱）
|
||||
- [ ] 完善 On-call Schedule（SRE Support Channel）并与 Service Desk 集成
|
||||
- [ ] 探索 Self-healing 能力：Vinaya 提议各产品组分享现有实践，SRE 将协助在监控产品中落地
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
> [!info]+ 交叉引用
|
||||
> [[ctp-topic-01-gruntwork-landing-zone-architecture.md]] — Gruntwork Landing Zone 基础架构（本次分享的上下文）
|
||||
> [[ctp-topic-19-configuring-dns-within-aws-lzs.md]] — DNS 配置与 SRE 支持模型的关系
|
||||
> [[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs.md]] — AD Services 与 SRE 协作流程
|
||||
> [[ctp-topic-28-aws-tag-validation-tool.md]] — IaC 变更的 Tagging 标准（属于 Standard Change 范畴）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
*最后更新: 2026-04-15*
|
||||
|
||||
Reference in New Issue
Block a user