---
title: "上线翻车怎么收：按 Google SRE「事故管理」拆指挥与复盘 - Angryecho"
description: "生产事故一旦蔓延，常见翻车姿势是：值班的人埋头改配置，老板追 ETA，有人半夜「顺手」推了一版自以为的优化——结果雪上加霜。Google SRE 手册第 14 章 Managing Incidents 把对策写得很具体：先定角色，再抢修；先止血，再根因。下面把可执行部分抽成清单，原文公开可核对。["
canonical_url: "https://www.angryecho.com/c/shang_xian_fan_che/p/P2TBC3WtCbhVwP9ei6onK"
meta:
  "og:description": "生产事故一旦蔓延，常见翻车姿势是：值班的人埋头改配置，老板追 ETA，有人半夜「顺手」推了一版自以为的优化——结果雪上加霜。Google SRE 手册第 14 章 Managing Incidents 把对策写得很具体：先定角色，再抢修；先止血，再根因。下面把可执行部分抽成清单，原文公开可核对。["
  "og:image": "https://www.angryecho.com/_og/d/c_Post%2Ctitle_~5ZCQ5qe9572R%2Cdescription_~5ZCQ5qe95LiA5LiL77yM5bCx5LiK5ZCQ5qe9572R44CC%2CpostId_P2TBC3WtCbhVwP9ei6onK%2Crevision_~MjAyNi0xMS0wM1QwMjo1NTo1Ni4wMDQ2NzRa%2Cp_Ii9jL3NoYW5nX3hpYW5fZmFuX2NoZS9wL1AyVEJDM1d0Q2JoVndQOWVpNm9uSyI%2Cs_W12hRjXCyq78Om5M.png"
  "og:image:height": "630"
  "og:image:type": image/png
  "og:image:width": "1200"
  "og:title": "上线翻车怎么收：按 Google SRE「事故管理」拆指挥与复盘"
---

> Index of every page on this site: [llms.txt](https://www.angryecho.com/llms.txt)

# **上线翻车怎么收：按 Google SRE「事故管理」拆指挥与复盘**

生产事故一旦蔓延，常见翻车姿势是：值班的人埋头改配置，老板追 ETA，有人半夜「顺手」推了一版自以为的优化——结果雪上加霜。Google SRE 手册第 14 章 *Managing Incidents* 把对策写得很具体：先定角色，再抢修；先止血，再根因。下面把可执行部分抽成清单，原文公开可核对。\[1]

## 准备工作

- 团队先书面约定：什么情况要正式宣布 Incident（见下文三条阈值）。
- 准备好「事故状态文档」模板（可多人同时编辑的文档即可）、固定通知频道（邮件列表 / IRC / 等价即时通道）、指挥交接话术。
- 原则性框架，不是你们公司的制度或法律意见；落地时改成自己的 on-call 手册。

## 操作步骤

### 1、尽早宣布事故，而不是熬到崩盘

原文建议：宁可早宣布、很快关闭，也不要问题烧了几小时才搭指挥架。可参考阈值（满足任一条就宣布）：

1. 修复需要拉第二个团队进来；
2. 故障已对用户可见；
3. 集中分析一小时仍没有头绪。

**为什么：** 晚宣布时，技术债和沟通债会叠在一起。  
**如何确认成功：** 邮件/频道里出现明确的「Incident 已开启」记录，并指定临时指挥官。

### 2、按职责拆角色，禁止「所有人一起改系统」

手册强调 *Recursive Separation of Responsibilities*，至少分清：

| 角色 | 做什么 |
| --- | --- |
| Incident Commander（事故指挥） | 盯全局状态、分派职责、清路障；未委派的职位默认自己扛 |
| Ops / Operational Work | **唯一**被授权改生产的小组，用运维手段止血 |
| Communication | 对外和对内发周期性进展，维护事故文档准确性 |
| Planning | 帮 Ops 处理长线杂务：开 bug、订餐、交接、记录系统相对常态偏移了多少以便事后回滚 |

**为什么：** 技术高手若同时搞定沟通和改配置，很容易「视野变窄」；旁人未经协调的 freelancing 会直接把剩余容量打穿。  
**如何确认成功：** 频道里能指出谁是指挥、谁可以动生产；其他人只做被指派的任务并回传结果。

### 3、维持「指挥所 + 活文档 + 清楚交接」

- **指挥所：** 实体 War Room，或全员在同一 IRC/聊天频道盯更新；Google 提到 IRC 便于留日志、挂 bot 记告警。
- **Live incident document：** 指挥最重要的活计之一——顶部放影响面、当前假设、已尝试动作、下一步；事故结束后留作复盘材料。
- **交接：** 换班时电话/视频同步后，离任者必须明确说「You’re now the incident commander」并得到对方确认，再通知全员指挥已更换。

**如何确认成功：** 任意中途加入的人只靠文档 + 频道就能接上，而不必私聊五个人。

### 4、止血优先级写进口头禅

章末 Best Practices 可直接当检查单：

1. **Prioritize：** 先停血、恢复服务，同时保全根因证据；
2. **Prepare：** 流程事前写好并和参与者对齐；
3. **Trust：** 角色内给足自主权；
4. **Introspect：** 慌了就加人，别硬撑；
5. **Consider alternatives：** 定期停下来问「还要不要继续当前战术」；
6. **Practice：** 日常变更、异地协作、灾备演练里就用这套，别等真炸才第一次摸；
7. **Change it around：** 轮换指挥/沟通/Ops，避免只有一个人会当指挥。

## 注意事项

- Ops 以外的人即使「有把握」，也不要擅自改生产。
- 事故文档可以乱，但不能缺关键时间线；依赖正在抢救的同一套 SaaS 当唯一文档平台，有风险。
- 复盘（postmortem）是下一章主题，本章要求先把证据和动作留下。

> 以上为 Google SRE Book 公开章节的实践摘要，用于工程复盘框架；具体升级、处罚与对外口径以所在组织制度为准。

## 来源

> \[1] [Google SRE Book：Managing Incidents](https://sre.google/sre-book/managing-incidents/)，Andrew Stribblehill / Kavita Guliani。

#SRE #事故响应 #IncidentManagement #上线 #复盘

排序方式 :

### **成为第一条评论！**

Nobody's responded to this post yet. Add your thoughts and get the conversation going.

```json
{"@context":"https://schema.org","@graph":[{"@id":"https://www.angryecho.com/c/shang_xian_fan_che/p/P2TBC3WtCbhVwP9ei6onK#post","@type":"DiscussionForumPosting","commentCount":0,"dateModified":"2026-11-03T02:55:56.004Z","datePublished":"2026-01-01T04:00:00.000Z","description":"生产事故一旦蔓延，常见翻车姿势是：值班的人埋头改配置，老板追 ETA，有人半夜「顺手」推了一版自以为的优化——结果雪上加霜。Google SRE 手册第 14 章 Managing Incidents 把对策写得很具体：先定角色，再抢修；先止血，再根因。下面把可执行部分抽成清单，原文公开可核对。[","headline":"上线翻车怎么收：按 Google SRE「事故管理」拆指挥与复盘","isPartOf":"https://www.angryecho.com/c/shang_xian_fan_che","mainEntityOfPage":"https://www.angryecho.com/c/shang_xian_fan_che/p/P2TBC3WtCbhVwP9ei6onK","text":"生产事故一旦蔓延，常见翻车姿势是：值班的人埋头改配置，老板追 ETA，有人半夜「顺手」推了一版自以为的优化——结果雪上加霜。Google SRE 手册第 14 章 Managing Incidents 把对策写得很具体：先定角色，再抢修；先止血，再根因。下面把可执行部分抽成清单，原文公开可核对。[1]\n\n准备工作\n\n\n\n\n\n团队先书面约定：什么情况要正式宣布 Incident（见下文三条阈值）。\n\n\n\n准备好「事故状态文档」模板（可多人同时编辑的文档即可）、固定通知频道（邮件列表 / IRC / 等价即时通道）、指挥交接话术。\n\n\n\n原则性框架，不是你们公司的制度或法律意见；落地时改成自己的 on-call 手册。\n\n操作步骤\n\n1、尽早宣布事故，而不是熬到崩盘\n\n原文建议：宁可早宣布、很快关闭，也不要问题烧了几小时才搭指挥架。可参考阈值（满足任一条就宣布）：\n\n\n\n\n\n修复需要拉第二个团队进来；\n\n\n\n故障已对用户可见；\n\n\n\n集中分析一小时仍没有头绪。\n\n为什么： 晚宣布时，技术债和沟通债会叠在一起。\n如何确认成功： 邮件/频道里出现明确的「Incident 已开启」记录，并指定临时指挥官。\n\n2、按职责拆角色，禁止「所有人一起改系统」\n\n手册强调 Recursive Separation of Responsibilities，至少分清：\n\n\n\n\n\n\n\n角色\n\n\n\n做什么\n\n\n\n\n\nIncident Commander（事故指挥）\n\n\n\n盯全局状态、分派职责、清路障；未委派的职位默认自己扛\n\n\n\n\n\nOps / Operational Work\n\n\n\n唯一被授权改生产的小组，用运维手段止血\n\n\n\n\n\nCommunication\n\n\n\n对外和对内发周期性进展，维护事故文档准确性\n\n\n\n\n\nPlanning\n\n\n\n帮 Ops 处理长线杂务：开 bug、订餐、交接、记录系统相对常态偏移了多少以便事后回滚\n\n为什么： 技术高手若同时搞定沟通和改配置，很容易「视野变窄」；旁人未经协调的 freelancing 会直接把剩余容量打穿。\n如何确认成功： 频道里能指出谁是指挥、谁可以动生产；其他人只做被指派的任务并回传结果。\n\n3、维持「指挥所 + 活文档 + 清楚交接」\n\n\n\n\n\n指挥所： 实体 War Room，或全员在同一 IRC/聊天频道盯更新；Google 提到 IRC 便于留日志、挂 bot 记告警。\n\n\n\nLive incident document： 指挥最重要的活计之一——顶部放影响面、当前假设、已尝试动作、下一步；事故结束后留作复盘材料。\n\n\n\n交接： 换班时电话/视频同步后，离任者必须明确说「You’re now the incident commander」并得到对方确认，再通知全员指挥已更换。\n\n如何确认成功： 任意中途加入的人只靠文档 + 频道就能接上，而不必私聊五个人。\n\n4、止血优先级写进口头禅\n\n章末 Best Practices 可直接当检查单：\n\n\n\n\n\nPrioritize： 先停血、恢复服务，同时保全根因证据；\n\n\n\nPrepare： 流程事前写好并和参与者对齐；\n\n\n\nTrust： 角色内给足自主权；\n\n\n\nIntrospect： 慌了就加人，别硬撑；\n\n\n\nConsider alternatives： 定期停下来问「还要不要继续当前战术」；\n\n\n\nPractice： 日常变更、异地协作、灾备演练里就用这套，别等真炸才第一次摸；\n\n\n\nChange it around： 轮换指挥/沟通/Ops，避免只有一个人会当指挥。\n\n注意事项\n\n\n\n\n\nOps 以外的人即使「有把握」，也不要擅自改生产。\n\n\n\n事故文档可以乱，但不能缺关键时间线；依赖正在抢救的同一套 SaaS 当唯一文档平台，有风险。\n\n\n\n复盘（postmortem）是下一章主题，本章要求先把证据和动作留下。\n\n\n\n以上为 Google SRE Book 公开章节的实践摘要，用于工程复盘框架；具体升级、处罚与对外口径以所在组织制度为准。\n\n来源\n\n\n\n[1] Google SRE Book：Managing Incidents，Andrew Stribblehill / Kavita Guliani。\n\n#SRE #事故响应 #IncidentManagement #上线 #复盘","url":"https://www.angryecho.com/c/shang_xian_fan_che/p/P2TBC3WtCbhVwP9ei6onK","author":{"@type":"Person","name":"用户846117","url":"https://www.angryecho.com/u/yong_hu_846117"},"interactionStatistic":[{"@type":"InteractionCounter","interactionType":"https://schema.org/LikeAction","userInteractionCount":0},{"@type":"InteractionCounter","interactionType":"https://schema.org/DislikeAction","userInteractionCount":0},{"@type":"InteractionCounter","interactionType":"https://schema.org/ViewAction","userInteractionCount":0},{"@type":"InteractionCounter","interactionType":"https://schema.org/ShareAction","userInteractionCount":0}]}]}
```

## Sitemap

See the full [sitemap](https://www.angryecho.com/sitemap.md) for all pages.