102 lines
5.8 KiB
Markdown
102 lines
5.8 KiB
Markdown
---
|
||
title: "CTP Topic 30 Managing change"
|
||
type: cloud-learning
|
||
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: "/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 (Gemini 摘要)
|
||
---
|
||
|
||
# CTP Topic 30 Managing change
|
||
|
||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 30_ Managing change.mp4`
|
||
|
||
**Type:** VIDEO | **Category:** 10_OpenText-Series
|
||
|
||
**Status:** ✅ 已完成（Gemini 摘要）
|
||
|
||
**讲者:** Brendan Starnig (SRE Function Lead, Platform Engineering)
|
||
|
||
---
|
||
|
||
## 摘要
|
||
|
||
本次会议由 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)**: 用软件工程思维解决运维问题，追求可靠性、可测试性、可重复性，核心是打破运维与产品的壁垒
|
||
- **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-15*
|