name: 支持升级 description: 为工程、产品或领导团队结构化包装支持升级，提供完整上下文、重现步骤和业务影响。
支持升级
确定何时以及如何升级支持问题。结构化升级简报，使接收团队拥有快速行动所需的一切，并跟踪升级至解决。
何时升级
- 技术性: 确认需要代码修复、基础设施调查、数据损坏的bug。
- 复杂性: 超出支持团队诊断能力，需要支持团队没有的访问权限。
- 影响: 多个客户受影响，生产系统宕机，安全问题。
- 业务性: 高价值客户面临风险，SLA即将违约，高层介入。
- 时间: 问题开放时间超出SLA，客户等待时间不合理。
- 模式: 相同问题被3个以上客户报告。
升级层级
- 支持升级 (L1 -> L2): 用于深入调查或高级故障排除。
- 工程升级: 用于已确认的bug、基础设施问题、代码更改。
- 产品升级: 用于功能差距、设计决策、优先级排序。
- 安全升级: 用于潜在数据暴露、漏洞、合规性问题（立即升级）。
- 领导升级: 用于高流失风险、SLA违约、跨功能决策。
结构化升级格式
每个升级都应遵循以下结构:
升级: [一行总结]
严重性: [严重 / 高 / 中]
目标: [工程 / 产品 / 安全 / 领导]
影响
- 受影响客户: [数量和名称如相关]
- 工作流影响: [对他们来说什么坏了]
- 风险收入: [如适用]
- SLA状态: [在SLA内 / 有风险 / 违约]
问题描述
[3-5句: 发生了什么，何时开始，如何表现，影响范围]
重现步骤 (针对bug)
1. [步骤]
2. [步骤]
3. [步骤]
预期: [X]
实际: [Y]
环境: [详情]
已尝试措施
1. [行动] -> [结果]
2. [行动] -> [结果]
3. [行动] -> [结果]
客户沟通
- 最后更新: [日期 — 说了什么]
- 客户期望: [他们期望什么以及何时]
- 升级风险: [他们会进一步升级吗？]
所需内容
- [具体要求: 调查、修复、决定、批准]
- 截止时间: [日期/时间]