wiki ingest: batch 2 (+2 docs, Claude Skills & NotebookLM)

knowledgebase/DevOps & SRE/10_OpenText-Series/ctp-topic-30-managing-change.md

@@ -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*