AI 学习笔记（三十二）：LLM 例外债预算闸门、整改 SLA 与治理 ROI 最小实践

上一篇我们把例外债评分卡、续期阈值和季度评审跑通了。

但光有评分，治理还是很容易卡在半路。

真实团队后面会马上碰到三个更硬的问题：

1. 分数越来越高，到底什么时候该收紧审批
2. 例外跨了一个季度还没还，谁来追整改 SLA
3. 平台团队花这么多人力管例外，这笔投入到底有没有回报

如果这三件事没接上，评分卡很快就会退化成一张“看起来很专业”的表。

这篇就往前再补一步，把例外债真正接进管理动作：

1. 用预算闸门限制例外债继续膨胀
2. 用跨季度整改 SLA 追 owner 和里程碑
3. 用治理 ROI 指标证明这套机制不是纯 paperwork

1. 为什么评分卡不够

评分卡解决的是“怎么量化”。

预算闸门解决的是“什么时候该停”。

整改 SLA 解决的是“谁来还债、多久还掉”。

ROI 解决的是“这套治理到底值不值得继续投人”。

这三层少一层，治理都会失真：

1. 没预算，orange/red 只会越堆越多
2. 没 SLA，高分债项会跨季度滞留
3. 没 ROI，治理团队很难在季度评审里守住资源

我的经验是，例外治理一旦进入“债务期”，讨论重点就不该只停在审批规则，而应该变成：

每个团队这一季还能再欠多少债，已经欠下的债多久要还，治理动作到底换回了什么。

2. 先把“预算”定义成可执行对象

这里的预算，不是财务预算。

它更像一个治理容量上限：
允许某个团队、某条业务线、某个环境，在一个统计周期里承受多少例外债。

预算最好同时看三个维度：

1. 债项数量：有多少条活跃例外
2. 债务点数：风险分值累加后有多重
3. 高危债占比：orange/red 占了多少

只看数量会低估高风险大坑。
只看总分又会忽略“一个团队是不是已经到处都在借例外”。

第一版建议先用最朴素的组合：

1. active_items_limit
2. debt_points_limit
3. high_risk_items_limit

有了这三个阈值，平台就能回答：

1. 这个团队还能不能继续批新的例外
2. 这次续期会不会把组合风险推过线
3. 哪些团队已经应该进入“减债优先”模式

3. 一个够用的预算模型

预算别一上来按公司统一数值发。

更稳的做法是按业务关键度和环境分层：

1. 低风险内部工具：预算宽一点
2. 核心生产链路：预算紧一点
3. 涉及支付、权限、合规链路：预算最紧

可以先把评分卡结果转成债务点，再做组合判断：

type RiskBand = 'green' | 'yellow' | 'orange' | 'red';
type Criticality = 'low' | 'medium' | 'high';

interface DebtItem {
  id: string;
  team: string;
  band: RiskBand;
  score: number;
  carriedOverQuarters: number;
}

interface TeamBudgetPolicy {
  criticality: Criticality;
  activeItemsLimit: number;
  debtPointsLimit: number;
  highRiskItemsLimit: number;
}

interface BudgetStatus {
  mode: 'healthy' | 'warning' | 'frozen';
  debtPoints: number;
  activeItems: number;
  highRiskItems: number;
  reasons: string[];
}

function debtPointsOf(item: DebtItem): number {
  const carryMultiplier = 1 + item.carriedOverQuarters * 0.25;
  return Math.round(item.score * carryMultiplier);
}

function evaluateBudget(items: DebtItem[], policy: TeamBudgetPolicy): BudgetStatus {
  const activeItems = items.length;
  const highRiskItems = items.filter((item) => item.band === 'orange' || item.band === 'red').length;
  const debtPoints = items.reduce((sum, item) => sum + debtPointsOf(item), 0);
  const reasons: string[] = [];

  if (activeItems > policy.activeItemsLimit) reasons.push('active-items-over-limit');
  if (highRiskItems > policy.highRiskItemsLimit) reasons.push('high-risk-items-over-limit');
  if (debtPoints > policy.debtPointsLimit) reasons.push('debt-points-over-limit');

  if (reasons.length >= 2 || highRiskItems > policy.highRiskItemsLimit + 1) {
    return { mode: 'frozen', debtPoints, activeItems, highRiskItems, reasons };
  }

  if (reasons.length === 1) {
    return { mode: 'warning', debtPoints, activeItems, highRiskItems, reasons };
  }

  return { mode: 'healthy', debtPoints, activeItems, highRiskItems, reasons };
}

这段逻辑的重点不在数学有多复杂，而在于它能直接驱动动作。

4. 预算超线后，审批口要怎么收

预算线如果只是告警，不会真的改变行为。

我一般会把预算状态直接映射成审批模式：

1. healthy
   正常走续期和新增审批
2. warning
   允许续期，但新增例外默认需要升级审批
3. frozen
   停止普通新增，只允许 P0 / 紧急变更豁免

再往前一步，可以把超线后的动作固定下来：

1. 平台 owner 每周 review 一次超线团队
2. 团队负责人必须给出前 3 大债项的回收计划
3. 下一轮续期必须附整改进展，不再接受“先续一下再说”

这样预算闸门才不会变成“知道超线，但没人理”。

5. 跨季度整改 SLA，别再只写一个 expires_at

例外债进入跨季度阶段后，expires_at 已经不够用了。

你至少还得追四件事：

1. owner 是不是还在
2. 整改里程碑有没有动
3. 超过 SLA 以后有没有升级
4. 连续跨了几个季度还没收敛

我建议直接把整改 SLA 分成三档：

1. yellow：30 天内补证据、补控制
2. orange：14 天内给出整改里程碑，30 天内验证进展
3. red：7 天内升级到平台/安全负责人，按周跟进直到回收或正式转政策

可以做成一个很简单的判定器：

interface RemediationSla {
  dueInDays: number;
  reviewCadence: 'weekly' | 'biweekly' | 'monthly';
  escalationTargets: string[];
}

function remediationSlaOf(item: DebtItem): RemediationSla {
  if (item.band === 'red') {
    return {
      dueInDays: 7,
      reviewCadence: 'weekly',
      escalationTargets: ['platform_owner', 'security_owner', 'director'],
    };
  }

  if (item.band === 'orange') {
    return {
      dueInDays: 14,
      reviewCadence: 'weekly',
      escalationTargets: ['platform_owner', 'security_owner'],
    };
  }

  return {
    dueInDays: 30,
    reviewCadence: 'monthly',
    escalationTargets: ['team_owner'],
  };
}

有了 SLA，就能把“跨季度还没还”这件事变成明确的运营指标，而不是会议上顺嘴提一句。

6. 治理 ROI 别算得太花，先算三笔账

很多团队一说 ROI，就容易把模型做得很玄。

这里更实用的做法，是先盯三笔保守账：

1. 减债收益：高风险债项环比下降了多少
2. 止损收益：因为预算闸门而被拦下的高风险新增有多少
3. 运维收益：评审、续期、追债的人工耗时下降了多少

第一版我建议别直接宣称“省了多少钱”，先用运营 ROI：

1. over_budget_days
2. orange_red_items_delta
3. expired_items_reclaimed
4. renewal_review_hours_saved
5. incident_count_linked_to_exceptions

如果你非要上财务口径，也最好保守一点：

interface GovernanceRoiInput {
  reviewHoursSaved: number;
  hourlyCost: number;
  avoidedIncidents: number;
  avgIncidentCost: number;
  governanceRunCost: number;
}

function estimateGovernanceRoi(input: GovernanceRoiInput): number {
  const grossBenefit =
    input.reviewHoursSaved * input.hourlyCost +
    input.avoidedIncidents * input.avgIncidentCost;

  return Number(((grossBenefit - input.governanceRunCost) / input.governanceRunCost).toFixed(2));
}

这类模型最大的风险不是算不出来，而是算得太满。

更稳的表达应该是：

1. 先把 ROI 当治理趋势指标
2. 再把重大事故避免收益单独列成案例
3. 不要把所有稳定性提升都硬归功到例外治理

7. 例外债预算、SLA、ROI 怎么串成一条自动化链

一个够用的自动化链路通常长这样：

1. 每日批处理重算评分、债务点和预算状态
2. 预算进入 warning/frozen 时，自动发给 team owner 和平台 owner
3. 每周扫描 SLA 超时项，自动补 comment、建工单、升级审批人
4. 每月生成团队级减债报表
5. 每季度输出 ROI review 包，给治理评审会直接使用

固定产物建议保留这三份：

1. exception_debt_budget_snapshot.json
2. exception_debt_sla_breach.md
3. exception_governance_roi_review.md

这样季度会里讨论的就不再是“有没有问题”，而是“预算超了多少、哪条 SLA 断了、这套治理值不值得继续加码”。

8. 一周最小落地顺序

如果你要把这套机制从零接起来，我建议按下面的顺序做。

1. Day 1
   把评分卡结果映射成债务点，先出团队预算快照
2. Day 2
   给团队配置 active items / debt points / high risk items 三条预算线
3. Day 3
   把 warning/frozen 接进新增例外和续期审批
4. Day 4
   为 orange/red 债项挂整改 SLA 和升级规则
5. Day 5
   自动产出团队超线报告和 SLA breach 清单
6. Day 6-7
   补 ROI 看板，先跑趋势，再补保守收益估算

顺序别反。

先把预算和 SLA 跑通，再谈 ROI，治理团队才不会陷入“指标已经很好看，但动作还没落地”的尴尬局面。

总结

例外债治理继续往后走，重点已经不只是“怎么续期”，而是三件更实在的事：

1. 这季还能不能继续欠
2. 已经欠下的债多久必须还
3. 这套治理投入到底有没有换回结果

把预算闸门、跨季度整改 SLA 和治理 ROI 接起来之后，例外治理才真正从审批流程变成经营动作。

如果你现在只做到了评分卡，我最建议的下一步不是继续加权重，而是先把预算线接进审批入口，再把 SLA 挂到高风险债项上。

本文永久链接: https://www.mulianju.com/learning-notes/ai-learning-notes-llm-exception-debt-budget-sla-roi-minimal-practice/