SPT-003_服务台运营规范

1. 概述

本文档定义了我们服务台的运营规范,包括支持案例的优先级分类、严重性定义、处理流程和服务标准。本规范与SPT-001《基础服务等级协议》和SPT-002《客户服务可用性》共同构成完整的客户支持体系,确保为客户提供专业、高效、一致的技术支持服务。

2. 支持案例优先级定义

我们根据业务影响范围和紧急程度将支持案例分为五个优先级别。这些优先级定义与SPT-001中的SLA标准直接对应,确保不同级别的问题得到适当的响应和处理。

3. 优先级判定标准

3.1 业务影响评估

在确定案例优先级时,我们主要考虑以下因素:

• 业务连续性: 问题是否导致业务中断或无法正常运营

• 用户影响范围: 受影响的用户数量和类型

• 数据完整性: 是否涉及数据丢失、损坏或安全风险

• 财务影响: 是否直接影响收入或造成经济损失

• 合规要求: 是否涉及法律法规或合规性问题

• 时间敏感性: 问题的紧急程度和可容忍的延迟时间

3.2 优先级判定流程

客户提交工单时,系统会根据以下流程自动判定或由工程师手动确认优先级:

• 客户选择: 客户在提交工单时选择问题类型和影响范围

• 关键词识别: 系统自动识别描述中的关键词(如"宕机"、"无法访问"等)

• 历史数据: 参考客户历史工单的优先级模式

• 工程师确认: 值班工程师在响应时确认或调整优先级

• 升级机制: 如果问题严重性被低估,可随时升级优先级

4. 服务要求

4.1 如何选择正确的优先级

为帮助客户准确判断问题的优先级，我们提供以下快速判断指南。

选择 P0（紧急）如果您遇到： - ❌ 生产系统完全无法访问 - ❌ 数据丢失或严重损坏 - ❌ 发生安全事件或数据泄露 - ❌ 所有用户无法使用服务 - ⏰ 每分钟都在造成重大业务损失

您将获得的服务： - ✅ 15分钟内收到我们的响应 - ✅ 5-10分钟内资深工程师/架构师接管您的案例 - ✅ 组建专属紧急响应小组 - ✅ 每15分钟收到进展更新 - ✅ 2小时内恢复服务（目标） - ✅ 24小时内收到详细的事件报告和根因分析

选择 P1（高）如果您遇到： - ⚠️ 核心功能严重受损但系统仍可部分访问 - ⚠️ 关键业务功能不可用（如支付、登录） - ⚠️ 大部分用户受到影响 - ⚠️ 性能严重下降（响应时间超过正常10倍） - ⏰ 业务受到严重影响但未完全中断

您将获得的服务： - ✅ 30分钟内收到我们的响应 - ✅ 如问题复杂，30分钟内转交资深工程师 - ✅ 每30分钟收到进展更新 - ✅ 4小时内解决问题（目标） - ✅ 48小时内收到问题总结报告

选择 P2（中）如果您遇到： - ⚡ 部分功能异常 - ⚡ 部分用户受到影响 - ⚡ 有临时解决方案可用 - ⚡ 非关键功能受损 - ⏰ 业务可以继续但存在不便

您将获得的服务： - ✅ 2小时内收到我们的响应 - ✅ 值班工程师处理 - ✅ 每2小时收到进展更新 - ✅ 8小时内解决问题（目标）

选择 P3（低）如果您遇到： - 💡 非关键功能问题 - 💡 影响少数用户 - 💡 UI显示问题 - 💡 小范围性能问题 - ⏰ 业务影响较小

您将获得的服务： - ✅ 4小时内收到我们的响应 - ✅ 每4小时收到进展更新 - ✅ 24小时内解决问题（目标）

选择 P4（一般）如果您需要： - 📚 功能咨询 - 📚 使用指导 - 📚 最佳实践建议 - 📚 功能增强请求 - ⏰ 无紧急时间要求

您将获得的服务： - ✅ 8小时内收到我们的响应 - ✅ 技术顾问提供专业建议 - ✅ 每日更新一次 - ✅ 48小时内提供完整答复（目标）

服务级别对比

*注：P1级别复杂问题会在30分钟内转交资深工程师

优先级选择建议

如果您不确定应该选择哪个优先级：

(1). 评估业务影响

a) 问题是否导致业务中断？

b) 有多少用户受到影响？

c) 是否有临时解决方案？

(2). 评估紧急程度

a) 问题是否需要立即解决？

b) 延迟解决会造成什么后果？

c) 是否涉及数据安全？

(3). 联系我们

a) 如仍不确定，请选择较高优先级提交

b) 我们的工程师会在响应时确认或调整优先级

c) 您也可以先通过电话咨询：400-XXX-XXXX

优先级调整

升级优先级： 如果问题的严重性超出预期，您可以随时要求升级优先级： - 在工单系统中点击”请求升级” - 致电技术支持热线说明情况 - 联系您的客户成功经理

我们也会主动升级： - 发现问题影响范围扩大 - 出现数据安全风险 - 预计解决时间超过当前级别SLA

4.2服务等级协议(SLA)

每个优先级对应明确的响应时间和解决时间承诺。这些SLA标准在SPT-001《基础服务等级协议》中详细定义,并在SPT-002《客户服务可用性》中说明了7x24小时的执行机制。

注: 以上时间标准适用于工作时间和非工作时间,详见SPT-002《客户服务可用性》。

5. 案例处理流程

5.1 案例提交

客户通过在线工单系统提交支持案例:

• 在线工单系统: https://ticket.sinnet-cloud.cn (7x24小时可用)

5.2 案例接收与分配

• 自动确认: 系统立即发送工单确认邮件,包含工单编号

• 优先级判定: 系统自动判定或工程师确认优先级

• 智能分配: 根据问题类型、工程师技能和当前负载自动分配

• 通知机制: 根据优先级触发相应的通知流程(短信/电话/邮件)

• 响应确认: 工程师在系统中确认接收并开始处理

5.3 案例处理

5.3.1 标准处理流程

• 问题诊断: 工程师分析问题根因,收集必要的日志和诊断信息

• 解决方案: 提供临时解决方案或永久修复方案

• 客户沟通: 定期更新案例进展,保持与客户的有效沟通

• 文档记录: 详细记录问题分析过程、解决方案和相关配置

• 知识沉淀: 将典型问题和解决方案录入知识库

5.3.2 P0/P1 级别紧急事件响应流程

P0 级别（紧急/Critical）响应机制

P0 级别事件代表业务完全中断、系统不可用的紧急情况，需要立即启动最高级别的响应流程。

P0 事件类型定义：

(1). 系统完全不可用

a) 生产环境数据库完全宕机

b) 核心应用服务器集群全部失效

c) 网络完全中断导致所有服务不可访问

d) 负载均衡器故障导致流量无法分发

(2). 数据安全事件

a) 数据丢失或严重损坏

b) 数据泄露或未授权访问

c) 勒索软件攻击

d) 严重的安全漏洞被利用

(3). 业务完全中断

a) 电商平台无法下单和支付

b) 金融系统无法处理交易

c) 关键业务流程完全停止

d) 影响所有用户的服务中断

P0 响应流程：

事件触发 (0分钟)

   ↓

立即通知 (1-2分钟)

   ├─ 自动触发短信/电话告警

   ├─ 通知值班工程师

   ├─ 通知技术经理

   └─ 通知客户成功经理

   ↓

快速评估 (3-5分钟)

   ├─ 值班工程师快速评估问题严重性

   ├─ 确认是否为真正的P0事件

   └─ 如确认，立即启动P0流程

   ↓

资深工程师接管 (5-10分钟)

   ├─ 直接转交给资深工程师/架构师

   ├─ 组建紧急响应小组

   ├─ 启动战情室（War Room）

   └─ 通知管理层

   ↓

并行处理 (10-15分钟)

   ├─ 技术团队：

   │   ├─ 资深工程师主导问题诊断

   │   ├─ 架构师评估影响范围

   │   ├─ 运维团队准备回滚/恢复方案

   │   └─ 安全团队（如涉及安全）

   │

   └─ 沟通团队：

       ├─ 客户成功经理联系客户

       ├─ 每15分钟更新进展

       └─ 准备客户通告

   ↓

解决方案实施 (15分钟-2小时)

   ├─ 实施临时解决方案（优先恢复服务）

   ├─ 持续监控系统状态

   ├─ 记录所有操作步骤

   └─ 准备永久修复方案

   ↓

服务恢复确认 (2小时内)

   ├─ 验证服务完全恢复

   ├─ 确认数据完整性

   ├─ 客户确认业务恢复

   └─ 解除紧急状态

   ↓

事后分析 (24小时内)

   ├─ 编写详细的事件报告

   ├─ 根因分析（RCA）

   ├─ 制定预防措施

   └─ 更新应急预案

P0 响应团队配置：

P0 沟通机制：

• 内部沟通：

– 建立专用沟通频道（企业微信/钉钉群）

– 每15分钟同步一次进展

– 所有关键决策需记录

• 客户沟通：

– 15分钟内首次联系客户

– 每15分钟更新进展

– 提供临时解决方案或缓解措施

– 服务恢复后立即通知

P0 决策权限：

• 资深工程师有权直接实施紧急修复措施

• 技术经理有权调动所有技术资源

• 涉及重大架构变更需架构师批准

• 涉及数据恢复需客户明确授权

P1 级别（高/High）响应机制

P1 级别事件代表核心功能严重受损、业务严重受影响的情况，需要快速响应和处理。

P1 事件类型定义：

(1). 核心功能严重受损

a) 主要服务性能严重下降（响应时间超过正常10倍）

b) 关键API失败率超过50%

c) 数据库主从同步失败

d) 缓存系统失效导致性能严重下降

(2). 关键业务功能不可用

a) 支付功能异常但系统其他功能正常

b) 用户登录功能失败

c) 订单处理系统故障

d) 关键第三方集成失败

(3). 影响大部分用户

a) 特定地区所有用户无法访问

b) 特定客户群体服务中断

c) 移动端应用完全无法使用

d) 关键功能对所有用户不可用

P1 响应流程：

事件触发 (0分钟)

   ↓

快速通知 (2-5分钟)

   ├─ 自动发送邮件和短信告警

   ├─ 通知值班工程师

   └─ 通知技术主管

   ↓

初步评估 (5-15分钟)

   ├─ 值班工程师评估问题

   ├─ 确定影响范围

   ├─ 判断是否需要升级为P0

   └─ 如需要，转交资深工程师

   ↓

问题诊断 (15-30分钟)

   ├─ 如果是常见问题：

   │   └─ 值班工程师按标准流程处理

   │

   └─ 如果是复杂问题：

       ├─ 转交给资深工程师

       ├─ 组建临时技术小组

       └─ 启动专项会议

   ↓

解决方案实施 (30分钟-4小时)

   ├─ 实施解决方案

   ├─ 每30分钟更新客户

   ├─ 监控系统恢复情况

   └─ 准备回滚方案

   ↓

服务恢复 (4小时内)

   ├─ 验证功能恢复

   ├─ 客户确认

   └─ 转入监控阶段

   ↓

总结分析 (48小时内)

   ├─ 编写问题报告

   ├─ 分析根本原因

   └─ 制定改进措施

P1 响应团队配置：

P1 处理决策树：

P1 事件接收

   ↓

是否为已知问题？

   ├─ 是 → 值班工程师按知识库处理

   │        ├─ 30分钟内解决 → 继续监控

   │        └─ 30分钟未解决 → 转交资深工程师

   │

   └─ 否 → 是否涉及核心架构？

            ├─ 是 → 立即转交资深工程师/架构师

            │

            └─ 否 → 值班工程师尝试诊断

                     ├─ 15分钟内定位问题 → 继续处理

                     └─ 15分钟未定位 → 转交资深工程师

P1 升级触发条件：

以下情况应立即将P1升级为P0： - 问题影响范围扩大到所有用户 - 发现数据丢失或安全风险 - 预计恢复时间超过4小时 - 客户业务完全中断 - 出现连锁故障迹象

5.3.3 P2/P3/P4 级别标准处理流程

P2 级别（中/Medium）

• 处理团队：值班工程师

• 响应时间：2小时内

• 处理方式：

– 按标准流程诊断和处理

– 参考知识库和历史案例

– 如遇复杂问题可咨询资深工程师

– 每2小时更新客户

P3 级别（低/Low）

• 处理团队：值班工程师

• 响应时间：4小时内

• 处理方式：

– 正常工作时间处理

– 可安排计划性维护

– 每4小时更新客户

– 可与其他工作并行

P4 级别（一般/General）

• 处理团队：值班工程师或技术顾问

• 响应时间：8小时内

• 处理方式：

– 提供咨询和指导

– 分享最佳实践

– 每日更新一次

– 可通过邮件或文档回复

5.3.4 跨级别转换机制

升级触发： - P4 → P3：发现实际影响比预期大 - P3 → P2：问题影响范围扩大 - P2 → P1：核心功能受影响 - P1 → P0：业务完全中断

降级条件： - 临时解决方案已实施 - 影响范围已控制 - 客户业务已恢复 - 转为长期优化项目

级别调整流程： 1. 工程师评估并提出调整建议 2. 技术主管审批（P0/P1需立即） 3. 通知客户级别变更原因 4. 按新级别SLA执行 5. 记录调整原因和时间

• 初步诊断: 工程师分析问题并收集必要信息

• 问题定位: 使用AWS诊断工具(CloudWatch、X-Ray、CloudTrail等)定位根因

• 解决方案: 提供临时解决方案或永久修复方案

• 客户沟通: 定期更新处理进展,保持透明沟通

• 协作支持: 必要时邀请架构师或升级至AWS Support

• 知识记录: 记录问题和解决方案至知识库

5.4 案例关闭

• 解决确认: 与客户确认问题已解决

• 根因分析: 记录问题根本原因和解决方案

• 预防措施: 提供预防类似问题的建议

• 满意度调查: 自动发送客户满意度调查

• 案例归档: 归档至知识库供未来参考

6. 案例升级机制

6.1 升级触发条件

• SLA超时风险: 即将超过承诺的响应或解决时间

• 技术复杂度: 问题超出当前工程师的技术能力

• 影响扩大: 问题影响范围或严重性增加

• 客户要求: 客户明确要求升级

• 重复问题: 同一问题多次发生未得到根本解决

6.2 升级路径

7. 服务台工具与系统

7.1 工单管理系统

• 统一工单平台: 集中管理所有客户工单

• 自动化工作流: 自动分配、通知、升级和SLA监控

• 客户自助门户: 客户可实时查看工单状态和历史

• 移动端支持: 工程师可通过移动App处理工单

• 报表分析: 自动生成SLA达成率和服务质量报告

7.2 AWS诊断工具

• AWS Diagnostic Tools: 访问AWS专用诊断工具

• CloudWatch: 监控指标、日志和告警

• AWS X-Ray: 分布式追踪和性能分析

• CloudTrail: API调用审计和安全分析

• AWS Health Dashboard: 服务健康状态监控

• Trusted Advisor: 最佳实践检查和优化建议

7.3 知识库系统

• 问题解决方案库: 常见问题和解决方案

• AWS最佳实践: AWS服务使用最佳实践文档

• 故障排查手册: 分服务的故障排查指南

• 案例研究: 典型案例的详细分析

• 搜索功能: 快速查找相关解决方案

8. 服务台人员要求

8.1 技能要求

8.2 培训与发展

• 入职培训: 服务台流程、工具使用、AWS基础知识

• 定期培训: 每季度AWS新服务和最佳实践培训

• 案例分享: 每月典型案例分析和经验分享会

• 认证支持: 支持工程师考取AWS认证

• 技能提升: 鼓励参加AWS re:Invent等技术大会

9. 服务质量监控

9.1 关键指标(KPI)

• SLA达成率: 各优先级响应时间和解决时间达成率

• 首次解决率(FCR): 首次接触即解决问题的比例

• 平均响应时间(ART): 实际平均响应时间

• 平均解决时间(MTTR): 实际平均解决时间

• 客户满意度(CSAT): 客户满意度评分

• 升级率: 需要升级的案例比例

• 重开率: 案例关闭后重新打开的比例

9.2 质量审核

• 每日审核: 审核所有P0/P1案例的处理过程

• 每周审核: 随机抽查10%的P2/P3案例

• 每月审核: 全面审核服务质量和SLA达成情况

• 季度回顾: 分析趋势、识别问题、制定改进计划