swing-mortem

事前验尸分析

一种前瞻性失败分析方法：先假设项目已经失败，再倒推以找出风险、早期预警信号和退路，从而克服乐观偏差。

**基于 Gary Klein 的事前验尸分析技术：**与其问“这会成功吗？”（这会触发乐观偏差），不如通过这项技能强制提出这样的问题：“现在是 6 个月后，一切都彻底失败了。出了什么问题？”

与 swing-review 的主要区别：

• swing-review 检查当前状态——“现在有什么问题？”
• swing-mortem 检查未来——“之后会出什么问题？”
• 对抗式评审旨在发现现存缺陷。事前验尸分析则会预判尚未出现的缺陷。

规则（绝对要求）

1. **绝不提出泛泛的风险。**每个失败情景都必须点明具体技术、数量、时间线或条件。“数据库可能无法扩展”是禁止的。“由于耗时 30 秒以上的长时间分析查询占用连接，导致 PostgreSQL 连接池在并发用户超过 2,000 人时耗尽”是可以接受的。
2. **恰好提出 5 个情景，分别对应 5 个类别。**技术、组织、外部、时间和假设类别各 1 个。不得跳过任何类别，也不得在同一类别中提出多个情景。
3. 领先指标必须可观察、可衡量。“留意问题”是禁止的。每个指标都必须说明要衡量什么、什么阈值表示有危险，以及在哪里观察。
4. 熔断条件必须包含具体的触发条件。“如果出了问题”是禁止的。每个触发条件都必须是带有明确阈值的可衡量条件。
5. **swing-mortem 总结是强制要求。**它是分析的 BLUF。总结必须出现在末尾，并用一段话概括最高风险、其领先指标和退路。
6. **假设彻底失败。**不是部分失败，也不是“表现不佳”。前提是彻底失败。正是这种极端设定能促使人创造性地识别风险——不要弱化它。
7. **具体性优先于覆盖面。**每个类别中，深入分析一个可信的失败情景，胜过浅尝辄止地列出五个。深度胜于广度。

流程

按顺序执行以下 6 个阶段。不得跳过任何阶段。

阶段 1：设定失败框架

在分析之前，明确时间和上下文框架。

FAILURE FRAME
─────────────
Subject: [what is being analyzed — plan, decision, architecture, launch]
Timeframe: [when failure is discovered — default 6 months, adjust to context]
Failure statement: "It is [timeframe] from now. [Subject] has failed completely.
Not partially underperformed — completely failed. The team is conducting a
post-mortem. What went wrong?"

如果主题含糊不清或范围过广，先提出一个澄清问题再继续。“分析我们的项目”太过宽泛。“分析我们将用户服务从 MongoDB 迁移到 PostgreSQL 的计划”则具备可操作性。

生成情景之前，先收集上下文：

• 如果存在代码或架构，阅读相关文件，确保情景贴合实际
• 如果存在项目计划，检查时间线和依赖关系
• 如果记录了以往的决策，审查其依据和限制条件

如果存在具体资料，不要仅凭想象生成情景。

阶段 2：生成失败情景

恰好生成 5 个失败情景，每个类别各 1 个。每个情景都必须是具体、可信的叙述，而非泛泛的风险标签。

类别 1：技术

技术未能达到预期效果。点明具体技术、具体故障模式，以及导致故障的具体条件。

类别 2：组织

团队、流程或沟通出现问题。点明导致失败的具体团队动态、交接环节或流程缺口。

类别 3：外部

市场发生变化、竞争对手采取行动、法规变更，或依赖项出现故障。点明具体的外部因素及其具体影响。

类别 4：时间

时间线判断有误。点明哪些工作耗时更长（或错过了哪个窗口期）、多出了多少时间，以及造成的具体连锁后果。

类别 5：假设

某个核心假设被证明是错误的。点明具体假设、它当时看起来合理的原因，以及现实情况究竟如何。

每个情景的格式如下：

SCENARIO [N]: [Category] — [Title]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

What happened:
[2-4 sentence specific narrative of how this failure unfolded]

Why it was plausible:
[1-2 sentences on why this wasn't obvious beforehand]

Concrete consequence:
[Specific, measurable impact — revenue lost, users affected, time wasted, data compromised]

阶段 3：可能性 × 影响矩阵

为每种情景评分并确定优先级：

RISK MATRIX
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
| # | Category       | Scenario             | Likelihood | Impact       | Priority |
|---|----------------|----------------------|------------|--------------|----------|
| 1 | Technical      | [title]              | H / M / L  | Cat/Sev/Mod  | [rank]   |
| 2 | Organizational | [title]              | H / M / L  | Cat/Sev/Mod  | [rank]   |
| 3 | External       | [title]              | H / M / L  | Cat/Sev/Mod  | [rank]   |
| 4 | Temporal       | [title]              | H / M / L  | Cat/Sev/Mod  | [rank]   |
| 5 | Assumption     | [title]              | H / M / L  | Cat/Sev/Mod  | [rank]   |

可能性： 高（>50%）、中（15-50%）、低（<15%） 影响： 灾难性（项目夭折、不可逆损害）、严重（大幅返工、重大损失）、中等（遭遇挫折，但付出努力后可恢复）

优先级评分：

• 高 + 灾难性 = P1
• 高 + 严重，或中 + 灾难性 = P2
• 中 + 严重，或高 + 中等 = P3
• 其他所有情况 = P4

按优先级选出前 3 项，在阶段 4-5 中进行详细分析。如遇并列，优先选择可能性更高的项。

阶段 4：先行指标

针对前 3 项风险，分别确定 2-3 个预警信号。这些都是可观察、可衡量的情况，表明失效模式开始显现——在为时已晚之前及时发出信号。

LEADING INDICATORS — Scenario [N]: [Title]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Indicator 1: [Name]
  Measure: [What specifically to track]
  Threshold: [At what value does this become a warning]
  Where to observe: [Dashboard, log, metric, report, or manual check]
  Lead time: [How far in advance of failure this signal appears]

Indicator 2: [Name]
  Measure: [What specifically to track]
  Threshold: [At what value does this become a warning]
  Where to observe: [Dashboard, log, metric, report, or manual check]
  Lead time: [How far in advance of failure this signal appears]

每项指标都必须通过**“实习生测试”**：仅凭这段描述，一位新团队成员能否判断是否已越过阈值？如果不能，就把描述写得更具体。

阶段 5：熔断机制

针对前 3 项风险，分别定义何时以及如何改变方向的决策框架。

CIRCUIT BREAKER — Scenario [N]: [Title]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Trigger:
  [Specific measurable condition that activates this circuit breaker.
   Must be a concrete threshold, not "if things go wrong."]

Fallback:
  [The alternative path. What do you switch to? Be specific about
   the replacement approach, not just "find another way."]

Cost of delay:
  [What do you lose by waiting one more week/sprint/month for more
   information before activating the fallback? Quantify if possible.]

Decision owner:
  [Who has authority to pull this trigger? Role, not name.]

阶段 6：事前验尸总结（BLUF）

将整个分析综合成一段话。这是最重要的输出——读者只读这一段，也应能带走关键洞见。

格式：

PRE-MORTEM SUMMARY
━━━━━━━━━━━━━━━━━━

The highest risk to [subject] is [specific scenario from top priority].
You'll know it's happening when [most actionable leading indicator with
threshold]. Your escape hatch is [primary fallback from circuit breaker].
The cost of ignoring this: [concrete consequence]. The cost of acting
too early: [trade-off of the fallback]. Monitor [specific metric] starting
[when] to stay ahead of this risk.

输出格式

## Pre-Mortem: [Subject]

### Failure Frame
> It is [timeframe] from now. [Subject] has failed completely. What went wrong?

### Failure Scenarios

#### Scenario 1: Technical — [Title]
**What happened:** [Narrative]
**Why plausible:** [Reasoning]
**Consequence:** [Specific impact]

#### Scenario 2: Organizational — [Title]
**What happened:** [Narrative]
**Why plausible:** [Reasoning]
**Consequence:** [Specific impact]

#### Scenario 3: External — [Title]
**What happened:** [Narrative]
**Why plausible:** [Reasoning]
**Consequence:** [Specific impact]

#### Scenario 4: Temporal — [Title]
**What happened:** [Narrative]
**Why plausible:** [Reasoning]
**Consequence:** [Specific impact]

#### Scenario 5: Assumption — [Title]
**What happened:** [Narrative]
**Why plausible:** [Reasoning]
**Consequence:** [Specific impact]

### Risk Matrix
| # | Category | Scenario | Likelihood | Impact | Priority |
|---|----------|----------|------------|--------|----------|
| 1 | Technical | ... | ... | ... | ... |
| 2 | Organizational | ... | ... | ... | ... |
| 3 | External | ... | ... | ... | ... |
| 4 | Temporal | ... | ... | ... | ... |
| 5 | Assumption | ... | ... | ... | ... |

### Deep Analysis (Top 3 Risks)

#### Risk [N]: [Title]

**Leading Indicators:**
1. **[Indicator name]** — Measure: [what], Threshold: [value], Where: [location], Lead time: [duration]
2. **[Indicator name]** — Measure: [what], Threshold: [value], Where: [location], Lead time: [duration]

**Circuit Breaker:**
- **Trigger:** [specific measurable condition]
- **Fallback:** [concrete alternative]
- **Cost of delay:** [what you lose by waiting]
- **Decision owner:** [role]

[Repeat for each top risk]

### Pre-Mortem Summary
The highest risk to [subject] is [X]. You'll know it's happening when [Y]. Your escape hatch is [Z]. The cost of ignoring this: [consequence]. The cost of acting too early: [trade-off]. Monitor [metric] starting [when].

质量校准

糟糕的事前验尸（不要这样做）

## Pre-Mortem: New Microservices Migration

### Failure Scenarios

#### Scenario 1: Technical — It didn't scale
**What happened:** The system couldn't handle the load.
**Why plausible:** Scaling is hard.
**Consequence:** Users were unhappy.

#### Scenario 2: Organizational — Communication issues
**What happened:** Teams didn't communicate well.
**Why plausible:** Communication is always a challenge.
**Consequence:** Things were delayed.

#### Scenario 3: External — Market changed
**What happened:** The market shifted.
**Why plausible:** Markets are unpredictable.
**Consequence:** Revenue was impacted.

### Leading Indicators
- Watch out for scaling issues
- Monitor team communication
- Keep an eye on the market

### Circuit Breakers
- If things go wrong, switch to plan B
- If communication breaks down, have more meetings

糟糕的原因：

• 每种情景都很泛泛，几乎适用于任何项目
• 没有提及具体技术、数字或条件
• “无法扩展”不是一种情景，而是一个类别标签
• 先行指标是不可衡量的空话（“注意”“密切关注”）
• 熔断机制没有触发阈值，也没有具体的替代方案
• “多开会”不是熔断机制，而是一种应对方式
• 没有风险矩阵、优先级排序或转向验尸总结

优秀的事前验尸（照这样做）

## Pre-Mortem: Migrating Order Service from Monolith to Event-Driven Microservices

### Failure Frame
> It is 6 months from now. The microservices migration has failed completely.
> The team reverted to the monolith. What went wrong?

### Failure Scenarios

#### Scenario 1: Technical — Kafka consumer lag cascades into order loss
**What happened:** Under Black Friday load (12x normal), Kafka consumer groups
for the order-processing service fell behind by 4+ hours. The dead letter queue
filled its 10GB allocation. 2,340 orders were silently dropped because the
retry policy exhausted its 3 attempts while downstream inventory service was
backpressured. No alert fired because monitoring tracked consumer group status
(STABLE) rather than consumer lag (which had no threshold configured).
**Why plausible:** Load testing only covered 3x normal traffic. The failure
mode — consumer lag + DLQ overflow + silent drop — requires all three conditions
simultaneously, which wasn't in the test matrix.
**Consequence:** $180K in lost orders, 2,340 customer support tickets, and a
forced rollback to the monolith under production load — itself causing a 45-minute
outage during the revert.

#### Scenario 2: Organizational — Domain boundary mismatch between teams
**What happened:** The "order" bounded context was split between Team Alpha
(order creation) and Team Bravo (fulfillment). Both teams independently implemented
inventory reservation — Alpha with optimistic locking, Bravo with pessimistic
locking. The conflict wasn't discovered until integration testing in week 14 of
a 16-week timeline, requiring a 6-week redesign of the inventory domain model.
**Why plausible:** Domain-Driven Design workshops defined bounded contexts on
paper, but the actual code ownership didn't align. No cross-team code review
process existed for shared domain objects.
**Consequence:** 6-week schedule slip, team morale damage from rework, and the
inventory service shipped with a compatibility shim that became permanent
technical debt.

### Risk Matrix
| # | Category | Scenario | Likelihood | Impact | Priority |
|---|----------|----------|------------|--------|----------|
| 1 | Technical | Kafka consumer lag cascade | Medium | Catastrophic | P2 |
| 2 | Organizational | Domain boundary mismatch | High | Severe | P2 |

### Deep Analysis — Risk 1: Kafka Consumer Lag Cascade

**Leading Indicators:**
1. **Consumer lag growth rate** — Measure: max consumer lag across all
   partitions for order-processing group. Threshold: >10,000 messages or
   lag growing >500 msg/sec for 5 consecutive minutes. Where: Kafka
   monitoring dashboard (Burrow or equivalent). Lead time: 2-4 hours
   before DLQ overflow at projected rates.
2. **DLQ fill rate** — Measure: dead letter queue size as percentage of
   allocated storage. Threshold: >30% capacity outside of known incident
   windows. Where: Kafka topic metrics + PagerDuty alert. Lead time:
   1-2 hours before overflow.

**Circuit Breaker:**
- **Trigger:** Consumer lag exceeds 1 hour AND DLQ reaches 50% capacity
  during any traffic event exceeding 5x baseline.
- **Fallback:** Activate synchronous HTTP fallback path for order processing
  (already exists in monolith, needs a feature flag to route traffic).
  Accept the latency penalty (800ms vs 200ms) to guarantee zero order loss.
- **Cost of delay:** Each hour of delay at Black Friday volumes risks ~$30K
  in dropped orders. The fallback path adds 600ms latency but loses zero orders.
- **Decision owner:** On-call SRE lead with VP Engineering escalation.

### Pre-Mortem Summary
The highest risk to the order service migration is Kafka consumer lag cascading
into silent order loss under peak load. You'll know it's happening when consumer
lag exceeds 10,000 messages with a growth rate above 500 msg/sec for 5 minutes.
Your escape hatch is the synchronous HTTP fallback path behind a feature flag.
The cost of ignoring this: thousands of lost orders and a forced rollback under
production pressure. The cost of acting too early: 4x higher latency on order
processing during the traffic spike. Monitor Kafka consumer lag starting 2 weeks
before any projected traffic event exceeding 3x baseline.

优秀的原因：

• 情景中点名具体技术（Kafka、DLQ、乐观锁／悲观锁）
• 数量具体明确（12 倍负载、2,340 笔订单、$180K、10GB、45 分钟）
• 先行指标有精确阈值（>10,000 条消息、>500 条消息/秒、>30% 容量）
• 熔断机制包含可衡量的触发条件、具体的替代方案和量化的权衡
• 事前验尸总结是一份完整独立的简报，高管可以据此采取行动
• 失败叙述呈现因果链条，而非贴标签——逐一说明失败是如何发生的

适用场景

• 确定项目计划或时间表之前
• 做出不可逆的架构决策之前
• 在生产环境中采用新技术之前
• 重大功能发布或产品转向之前
• 进入新市场或新的客户群体之前
• 团队信心十足，且无人提出疑虑时
• 风险很高，且失败成本高于分析成本时
• 有人问“最坏会发生什么？”时

不适用场景

• 针对当前代码中的已有缺陷（使用 swing-review——它会检查当前存在的问题）
• 比较技术选项（使用 swing-research——它会收集事实，而非分析失败情景）
• 生成有创意的替代方案（使用 swing-options——这是不同的思维模式）
• 常规代码审查
• 决策可以轻易撤回时（低风险不足以证明进行分析的必要性）
• 团队需要鼓励而非警示时（先看看现场氛围）

易踩的坑

1. “无法扩展”不是一个场景。 每项失败都必须指出具体技术、具体数量和具体条件。如果替换项目名称后，场景读起来还是一样，那就太笼统了。
2. 领先指标必须通过实习生测试。 新团队成员仅凭你的描述，能否判断是否已超过阈值？“留意问题”不合格。“Burrow 仪表板上的消费者积压超过 10,000 条消息”合格。
3. “如果出了问题”不是断路器。 每个触发条件都必须是带有明确阈值的可测量条件。每个回退方案都必须指出具体替代方案，而不是“另想办法”。
4. 不要弱化失败情境。 前提是彻底失败——而不是“表现不佳”或“面临挑战”。这种极端设定能迫使人们创造性地识别风险。
5. 事前分析摘要不是可选项。 它是 BLUF。高管只读这一段就应该能够采取行动。如果缺少摘要，分析就不完整。

集成说明

• 与 swing-clarify 集成： 对于有歧义的请求，先运行 swing-clarify，再调用此技能。明确范围能带来更好的结果。
• 与 swing-review 集成： 两者互为补充，而非重叠。先运行 swing-mortem 预测未来风险，再对当前实现运行 swing-review，找出现有缺陷。两者结合可覆盖时间维度上的风险：未来（swing-mortem）+ 当前（对抗性审查）。
• 与 swing-research 集成： 如果 swing-mortem 场景依赖不确定的事实（例如“Kafka 能否处理这类负载？”），请调用 swing-research 核实事实依据，再评估可能性。
• 与 swing-options 集成： swing-mortem 揭示高优先级风险后，使用 swing-options 生成能够彻底规避主要失败模式的替代方案。
• 与 orchestrator strategy team 集成： 事前分析的输出会直接交给 strategy team 的 Devil's Advocate Agent，用于进一步对风险评估本身进行压力测试。