SLA 影响对内说明

这个技能解决什么问题

当 SLA 或可用性受到影响时，团队常陷入一种两难：技术同学忙于排查故障，业务和客户成功团队却急需一份说明「影响面多大、现在恢复没有、补偿怎么谈」的材料。直接转发技术状态短讯不够用——通报里全是 5xx 错误率 和堆栈日志，业务方读不懂；临场手写说明又容易踩坑：要么把「约 5% 用户受影响」这个总量直接套到所有产品线，要么在补偿方案未批准时就写成「将赔付 X 元」。

这个技能的目标是产出一份对内说明草稿：结构固定、口径谨慎，专门给业务与客成同步用。它不替代技术事中通报，也不代发客户消息。

核心能力与关键步骤

一句口语化描述就能启动，比如「SLA 可能破了，写个对内说明」。生成前会要求确认四类信息：

• 影响时间窗
• 受影响用户或订单的量级
• 当前是否已恢复
• 是否已有批准的补偿政策

拿到输入后按五步生成草稿：

1. 摘要：发生了什么、是否仍在影响
2. 影响：谁受影响、范围多大、何种业务后果，能量化则量化
3. 现状与下一步：只写已确认的事实
4. 补偿口径：仅写 待批 或 按既有政策，无批准绝不写具体金额
5. 待确认清单：留给后续补充的缺口项

多产品线时强制分列是它最硬的规则：按产品线/模块、客户层级、地域/时段三个维度分别写影响，未受影响的产品线也要出现在表里并标注「未受影响」。没有分线数据时，明确写「分产品线影响待确认」，绝不按整体占比反推各线影响。

适用边界与注意点

明确的「不做」清单：

• 不做事中技术状态短讯——那是监控告警和故障通报的职责
• 不写对外公关定稿
• 不代发客户消息
• 无书面批准前，草稿中禁止出现任何具体赔付金额

已知限制：不连接监控或工单系统，分线数据完全依赖用户提供；中文交互，不依赖海外 API。若某产品线涉及合同 SLA 条款，其补偿口径必须单独表述，不与其他线合并，否则有条款约束的一方口径会失真。