63 lines
4.3 KiB
Markdown
63 lines
4.3 KiB
Markdown
---
|
||
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 假设迁移决策已做出，聚焦执行层面的变更管理
|