Auto-sync: 2026-04-24 04:02

wiki/sources/ctp-topic-30-managing-change.md

@@ -0,0 +1,62 @@
+---
+title: "CTP Topic 30 Managing Change"
+type: source
+tags:
+  - Change-Management
+  - SRE
+  - ITSM
+  - DevOps
+  - Cloud-Transformation
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-30-managing-change]]
+
+## Summary（用中文描述）
+- 核心主题：云转型项目中的变更管理流程，以及 SRE 团队在不同阶段与产品团队的协作模式
+- 问题域：企业云迁移过程中的变更审批效率、自动化程度不足、SRE 与产品团队协作边界不清
+- 方法/机制：区分标准变更/正常变更/紧急变更三类流程；引入自动化（IaC+CI/CD）将变更转为标准变更；SRE 团队在构建/上线支持/BAU 三阶段提供差异化支持
+- 结论/价值：通过自动化减少人工审批，通过明确流程减少变更风险，SRE 团队是云转型中连接运维与产品的关键桥梁
+
+## Key Claims（用中文描述）
+- SRE 团队通过软件工程思维解决运维问题，核心在于自动化重复性工作，提高系统可靠性和可测试性
+- 标准变更（Standard Change）应实现完全自动化（IaC + CI/CD Pipeline），无需 CAB 审批，是理想状态
+- 正常变更（Normal Change）需 CAB 批准和变更窗口，目标是通过自动化逐步将其归入标准变更
+- 紧急变更（Emergency Change）需立即执行以缓解事故，事后通过 CAPA/Post-mortem 修复根因
+- SRE 团队在三个阶段（构建/早期上线支持/BAU）与产品团队以不同方式协作
+- Self-Healing（基于 ML 的自动化监控系统）是未来演进方向，各产品组分享实践，SRE 协助落地
+
+## Key Quotes
+> "SRE 用软件工程思维解决运维问题，追求可靠性、可测试性、可重复性，核心是打破运维与产品的壁垒。" — Brendan Starnig
+> "Standard Change 应完全自动化（IaC + CI/CD Pipeline），无需 CAB 审批。" — Brendan Starnig
+> "Emergency Change 事后通过 CAPA/Post-mortem 修复根因，而非永久性补丁。" — Brendan Starnig
+
+## Key Concepts
+- [[SRE]]：Site Reliability Engineering，站点可靠性工程，通过软件工程思维解决运维问题
+- [[Standard-Change]]：标准变更，预批准变更，无需 CAB 审批，应完全自动化（IaC + CI/CD Pipeline）
+- [[Normal-Change]]：正常变更，有风险/影响，需 CAB 审批和变更窗口，理想状态是逐步归入 Standard Change
+- [[Emergency-Change]]：紧急变更，为缓解事故需立即执行的变更，事后通过 CAPA/Post-mortem 修复根因
+- [[CAPA]]：Corrective and Preventive Action，即 Post-mortem 回顾，从事故中提取根因并预防同类问题
+- [[SLO]]：Service Level Objective，服务等级目标，用于定义监控指标并向上汇总至 KPI
+- [[SLR]]：Service Level Requirement，服务等级需求，与 SLO 配套使用
+- [[Early-Live-Support]]：Build 与 BAU 之间的过渡阶段，需完成 Go-Live Checklist（监控覆盖、支持模型、事件响应流程）
+- [[Self-Healing]]：通过机器学习驱动的自动化监控系统，基于告警趋势自动决策和缓解问题
+
+## Key Entities
+- [[Brendan-Starnig]]：SRE Function Lead, Platform Engineering，本次会议主讲人
+- [[SMACs]]：Service Management Automation X，当前的 ITSM 工具，用于 Ticket、Incident、Change 管理
+- [[Vinaya]]：内部成员，提议各产品组分享 Self-healing 实践，SRE 将协助落地
+
+## Connections
+- [[ctp-topic-1-gruntwork-landing-zone-architecture]] ← context_for ← [[ctp-topic-30-managing-change]]
+- [[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]] ← related_to ← [[ctp-topic-30-managing-change]]
+- [[ctp-topic-28-aws-tag-validation-tool]] ← extends ← [[ctp-topic-30-managing-change]]（IaC 变更的 Tagging 标准属于 Standard Change 范畴）
+- [[ctp-topic-19-configuring-dns-within-aws-lzs]] ← related_to ← [[ctp-topic-30-managing-change]]
+
+## Contradictions
+- 与 [[ctp-topic-53-why-bother-with-cloud]] 的关系：
+  - 冲突点：是否应迁移至云端
+  - 当前观点（Topic 30）：接受云转型，聚焦如何在转型中有效管理变更
+  - 对方观点（Topic 53）：质疑云转型的必要性
+  - 说明：两者处于不同讨论层面，Topic 53 质疑迁移决策，Topic 30 假设迁移决策已做出，聚焦执行层面的变更管理