与 Customer Care 团队打交道时的最佳做法

本指南介绍了撰写有效支持请求的最佳实践。遵循这些最佳实践有助于我们为您解决技术支持问题 提供更快的支持请求

创建支持请求

在创建支持请求之前，请先查看 问题，看看是否存在 已提交过支持请求。

为避免混淆，以便我们在一个位置集中跟踪您的请求， 请为每个问题创建一个支持请求。已创建的所有重复案例 已关闭。

描述您的问题

您撰写的支持案例越详细，Customer Care 团队就越能快速高效地回复您。支持请求的时间 如果缺少关键细节，我们需要您提供更多信息。 。

支持请求应详细而具体。报告应说明发生了什么，以及您原本的预期是什么。在支持请求中描述问题时，请提供以下详细信息：

  • 时间：出现问题的具体时间。
  • 产品：与问题相关的产品和功能。
  • 位置：发生问题的区域。
  • 标识符：项目 ID 或应用 ID 以及其他具体标识符 来帮助我们调查相应问题
  • 有用的文件：您可以提供的有助于我们诊断问题的任何详细信息。
  • 问题类型：问题是间歇性的、暂时性的还是持续性的。

以下各个部分详细介绍了这些概念。

时间

对于日期和时间戳，请采用 ISO 8601 格式，告诉我们您第一次发现该问题的时间，以及问题持续了多久。

示例：

  • 从 2017-09-08T15:13:06+00:00 开始，并在 5 分钟后结束， 观察到...
  • 开始时间不早于 2017-09-10，间歇性观察到 2-5 次…
  • 自 2017-09-08T15:13:06+00:00 起一直持续…
  • 从 2017-09-08T15:13:06+00:00 到 2017-09-08T15:18:16+00:00…

解决问题的客户服务专家不太可能 因此，像下面这样的相对语句会使问题更棘手 诊断：

  • “这个问题从昨天某个时刻开始…”（迫使我们推断具体日期）。
  • “我们在 9/8 注意到这个问题…”（含糊不清，因为有些人可能会理解这一点 日期设为 9 月 8 日，而其他人可能会将其解读为 8 月 9 日）。

产品

虽然基本案例表单要求您注明产品名称，但我们需要关于该产品中的什么功能出现问题的具体信息。 理想情况下，您的报告应包含具体的 API 或 Google Cloud 控制台网址（或屏幕截图）。对于 API，您可以链接到文档页面，该页面的网址中包含产品名称。

此外，请告诉我们您发起请求所用的机制（例如 REST API、Google Cloud CLI、Google Cloud 控制台，或者 Cloud Deployment Manager 等工具）。如果涉及到多个产品，请注明每个产品的名称。

示例：

  • “Compute Engine REST API 返回以下错误...”
  • “console.cloud.google.com 中的 BigQuery 查询界面卡住不动…”

以下陈述不够具体，会令我们在诊断问题时不知道从哪里着手：

  • “无法创建实例…”（我们需要了解您创建实例所用的方法）。
  • “gcloud compute create instances 命令给出错误...”（ 所以我们无法自行运行该命令来重现 错误。此外，我们也不知道您实际看到了什么错误。）

位置

我们需要了解您的数据中心所在的区域和地区，因为我们通常单独向各个区域或地区发布更改。我们可以根据区域和地区间接获知底层的软件版本号。该信息可帮助我们了解特定版本软件的重大更改是否影响了您的系统。

示例：

  • “在 us-east1-b 中 ...”
  • “我试过区域 us-east1 和 us-central1…”

标识符

具体标识符可帮助我们识别您的哪个 Cloud 项目遇到问题。我们始终需要知道字母数字形式的项目或应用 ID。项目名称没有帮助。如果问题影响到多个项目，请纳入所有受影响的 ID。

除了项目或应用 ID 以外，还有几个标识符可帮助我们诊断您的案例：

  • 实例 ID。
  • BigQuery 作业 ID 或表名称。
  • IP 地址。

提供 IP 地址时，请说明其使用情境。对于 例如，指定 IP 是否连接到计算实例、负载均衡器 自定义路由或 API 端点此外，如果该 IP 地址与 Google 的系统无关（例如，该 IP 是您的家用互联网、VPN 端点或外部监控系统的地址），也请告诉我们。

示例：

  • “在项目 robot-name-165473 或 my-project-id 中…”
  • “在多个项目中（包括 my-project-id）…”
  • “正在从我们的公司网关 56.56.56.56 连接到 Google Cloud 外部 IP 218.239.8.9…”

以下一般性陈述过于宽泛，无助于问题诊断：

  • “我们无法访问某个实例…”
  • “我们无法通过互联网连接到…”

有用的文件

向我们提供与问题相关的文件可帮助我们准确了解您遇到的问题，从而加快问题排查。

例如：

  • 使用屏幕截图显示您所看到的具体问题。
  • 对于网页界面，请提供 .HAR (Http ARchive) 文件。HAR 分析器提供了针对三款主要浏览器的说明。
  • 将 tcpdump 输出、日志片段、示例堆栈轨迹添加为附件。

问题类型

  • 间歇性：间歇性问题随机发生，没有有规律的故障模式。间歇性问题很难进行排查，因为它们没有规律，导致难以在故障期间收集数据。在这种情况下，您应尝试找出架构中的瓶颈，并检查您的资源是否达到其最大阈值用量。您还可以使用自动化在预定作业中频繁执行检查，如果检查失败，则在失败期间收集调试信息。此类故障的示例包括 DNS 解析失败和丢包。

  • 瞬时性：瞬时性问题暂时存在，或仅存在很短时间。如果您遇到的问题只发生一秒钟或者几微秒，您可以检查是否有短暂的流量或资源使用峰值。在大多数情况下，如果瞬时性问题不经常发生，且您的服务设计为可以容忍瞬时故障，则可以忽略。此类故障的示例包括仅出现几微秒的网络延迟高峰，以及导致超时的少量丢包。传输控制协议 (TCP) 专为应对故障而设计 例如丟包和延迟时间急剧增加， 除非您的应用对延迟较敏感。

  • 持续性：持续性问题指导致全面故障的问题，例如网站停机。持续性问题相对来说比较简单 因为它们可以重现在这种情况下，请告诉我们重现问题的步骤，以便我们的客户服务专家能够复制该环境并为您排查问题。

说明示例

示例 1

JobName:

A_ATL_BIG1toBQ_big_04)201704202

00045_491

Source:

S3_avl-transfer

Destination:

CloudStorage: avl-transfer

Start time (ISO 8601 format): 2017-04-20 20:14:43 PDT

End time (ISO 8601 format): 2017-04-21 at 10:03:44 PDT

I started a file transfer at 2017-04-20 at 20:14:43 PDT using the transfer API.
This job normally takes 10 minutes to complete, but in this case the job was
still running when I canceled it the next day (2017-04-21 at 10:03:44 PDT). This
is not an isolated event; several other jobs involving the transfer API had
intermittent, significant delays.

Please investigate the cause of the delays and advise of any best practices that
we can implement to prevent these issues in the future.

示例 2

Start time (ISO 8601 format): 2017-05-12 at 11:03:43

End time (ISO 8601 format): The issue is still happening as of the time of this
report.

Issue summary:

`/cron/payments-service/sync-v2-batch` cron using the App Engine Task Queue API
has stopped running since 2017-05-12 at 11:03:43. We rely on this job to handle
payments correctly.

We saw datastore and queue errors and then the cron stopped running. We
attempted unsuccessfully to fix the issue by re-uploading cron.xml. Here is the
error trace:

`[error trace]`

Please advise if the issue is with the API or our implementation and let us
know next steps.

设置和提升优先级

优先级可帮助我们了解该问题对您业务的影响，并且会影响我们解决问题的响应速度。优先级的定义见下表。如需了解详情，请参阅支持请求优先级。

优先级定义 示例情境
P1：重大影响 - 生产环境中的服务无法使用 生产环境中的应用或基础架构无法使用，向用户显示大量错误。对业务的影响重大（收入损失、潜在数据完整性问题等）。
P2：高度影响 - 服务受到很大影响 基础架构在生产环境中性能退化，且速度明显 或难以启动新的生产系统。对业务的影响中等（存在收入损失的风险、工作效率降低等）。
P3：中度影响 - 服务受到部分影响 问题影响的范围和/或严重性有限。问题不会带来用户可见的影响。对业务的影响小（例如，为业务造成不便，或业务流程受到微小影响）。
P4：低影响 - 服务完全能够使用 对业务或技术几乎没有或根本没有影响。推荐用于 咨询工单（其中更适合进行深入分析、问题排查或咨询，而不是更频繁的沟通）。

何时设置最高优先级

如果您遇到的问题会影响关键业务服务并且需要 Google 立即加以关注，请选择“P1”优先级。请向我们详细解释您选择 P1 的原因，简要说明该问题对您的业务产生的影响。例如，如果开发版本的某个问题妨碍了重要的安全修复，即使没有直接影响到任何最终用户，也建议您将该问题设置为 P1。

当案例设为 P1 时，系统会立即提醒专家只能工作 问题所在。您会收到快速的初始回复，以便通过 Google Meet 加入实时问题排查通话。如果贵组织无法使用 Google Meet，请添加指向您首选的视频会议软件的链接 让专家加入此后，您将通过 这种情况。

感谢您对所选优先级的详细评论，因为这有助于我们做出适当的回复。

P1 支持请求支持服务的预期

  • 新建 P1 支持请求

    • 支持专家将通过 Google Meet 或您提供的任何其他桥接工具与您互动。我们希望您能在 15-30 分钟内加入通话。如果您无法加入通话，请通知支持专家 原因。
    • 默认情况下，此支持请求会“遵循太阳的轨迹”。这意味着支持专家 全天 24 小时互动，直到支持请求得到缓解或降低优先级为止。如果最好在特定区域内执行支持请求缓解措施，则可以将该支持请求锁定到特定时区。您可以告诉我们您对此效果的偏好。

  • 提高 P1 优先级

    • 如果问题已经开始影响您的生产环境，或者是关于 您或许可以将现有 P2 - P4 支持请求的优先级提高到 P1。
    • 当您将现有支持请求的优先级提高到 P1 后，相关支持请求 可以重新分配，以便空闲的支持专家立即 注意力层。

  • 非生产影响

    为确保在需要时分配适当的资源，支持团队可能会与您联系，重新评估标记为 P1 但未影响生产环境或未造成严重业务影响的支持请求。

响应时间

问题优先级具有预定义的响应时间，如 Google Cloud Platform 技术支持服务准则中所述。如果您需要在特定时间之前收到回复，请在报告说明中告诉我们。如果需要我们不分时段即刻处理 P1 问题，您可以申请全天候服务。我们会每天多次将这些支持请求分配给当班的客户服务专家。我们会对您的 P1 支持请求进行问题排查，但建议您继续 积极回答问题，直到问题解决，从而提高效率 通信。如果超过 3 小时没有回应，我们可能会降低 将支持请求的优先级更改为 P2，直到您再次互动为止。

升级

当情况发生变化时，您可能需要上报问题。提升优先级的合理理由包括：

  • 对业务的影响加剧。
  • 解决问题流程的细分。例如，您没有收到 请在商定的时间内进行更新，否则您的问题就会“卡住”不包含 换几条消息后进展如何

如果您遇到影响较大的问题，最佳解决方案是将支持请求设置为适当的优先级，以便留出足够长的时间，而不是上报。上报问题不一定能更快解决问题 在优先级更改后立即上报，甚至可能导致支持请求解决 慢一点。有关更详细的说明，请参阅您何时应该 上报视频。

要了解如何上报支持请求，请参阅上报 用例。

将请求转到所需时区

由于 Customer Care 可用性所基于的因素，您的支持请求可能会被分配给工作时间与您不同的 Customer Care 专家。您也可能希望在某个特定时区的工作日与 Customer Care 团队联系。在这些情况下，我们建议您要求 Customer Care 将支持请求转到适合该请求的时区。您可以在请求说明或回复中添加此要求。例如 Please route this case to the Pacific time zone (GMT-8)。P1 请求会移交给下一个区域 Customer Care，因为它是全天候服务，而其他请求仍由当前的请求负责人在次日继续处理。

通过 CES 调查问卷提供反馈

您的问题得到解决后，我们会通过电子邮件向您发送客户费力度 (CES) 调查问卷，以了解您对互动过程的意见。我们邀请您花几分钟时间填写这份调查问卷，帮助我们了解哪些方面做得较好，哪些方面有待改进。

客户体验团队会人工审核每个反馈表单，并采取相应的措施来改善您未来的体验。调查问卷为 5 分制。得分为 3 分或低于 3 分的 。另一个 4 分或更多，表示对于客户来说，互动并不困难 并认为这是积极的体验。

如需了解详情，请观看如何使用 CES 提交 Google Cloud 服务反馈视频。

长期存在或难以解决的问题

需要很长时间才能解决的问题可能会变得信息陈旧且令人费解。要防止发生这种情况，最好的方法是使用我们的长期问题模板收集信息，将最新状态信息汇总在顶部。

如需使用该模板，请打开上文中的链接并复制一份副本。包含 指向所有相关支持请求和内部跟踪 bug 的链接。将此文档共享给 您的客户支持团队 Customer Care 专家

本文档包含以下内容：

  • 当前状态摘要（位于顶部）。
  • 可能成立的假设的列表。
  • 您打算用于测试每个假设的测试或工具。

尽量在每个案例中只提出一个问题，并避免通过重开案例来提出新问题。

报告生产环境服务中断

问题导致您的应用停止向用户提供流量，或者 产生类似的关键业务影响，这可能是生产环境服务中断。我们希望尽快获知此类问题。与此相对，仅对少数开发者造成影响的问题不是我们所说的生产环境服务中断问题。

收到生产环境服务中断报告后，我们会通过以下方式对情况进行快速分类：

  • 立即检查是否存在影响 Google Cloud 基础架构的已知问题。
  • 确认问题的性质。
  • 建立沟通渠道。

您会收到一条简短回复，其中包含：

  • 影响多个客户的任何相关已知问题。
  • 确认我们能观察到您所报告的问题，或者请您提供更多详细信息。
  • 我们希望采用的沟通方式。

因此，请务必快速创建包含时间、产品、标识符和位置信息的案例，然后开始更深入地排查问题。您的组织可能有规定的突发事件管理流程，此步骤应在该流程中尽早执行。

Google 的突发事件管理流程定义了一个关键角色：突发事件指挥官。 此人会负责联络适当人员加入进来、持续收集最新状态、定期汇总问题的状态， 以及委派其他人进行问题排查并执行更改。通过这种委派，我们可以并行调查多个假设。我们建议您在组织内部也建立类似的流程。创建案例的人员通常是突发事件指挥官的最佳人选，因为他们最了解情况。

报告网络问题

Google 网络规模大、复杂性高，致使人们难以分辨出了问题应找哪个团队负责。要诊断网络问题，我们需要找出非常具体的根本原因。由于网络错误消息通常十分笼统（如“无法连接到服务器”），因此我们需要收集详细的诊断信息，以缩小可能的假设范围。

数据包流程图为问题报告提供了良好的参考结构。这些图表说明了数据包在从来源到目标的路径中经过的重要跃点，以及过程中的任何重大转换。

首先通过互联网 IP 地址或 RFC 1918 专用地址 Plus 网络的标识符。例如，Compute Engine 项目默认网络上的 2.3.4.5 或 10.2.3.4。

请注意与端点有关的任何有意义的信息，如：

  • 谁控制着它们。
  • 它们是否与 DNS 主机名关联。
  • 任何中间封装或间接连接，如 VPN 隧道、代理和 NAT 网关。
  • 任何中间过滤，如防火墙或 CDN 或 WAF。

表现为高延迟或间歇性丢包的许多问题需要进行路径分析或数据包捕获，或者两者兼有，以便执行诊断。

  • 路径分析是数据包遍历的所有跃点的列表，也就是人们熟知的“traceroute”。我们经常使用 MTR 或 tcptraceroute，或两者兼用，因为它们的诊断能力更好。我们建议您熟悉这些工具。
  • 数据包捕获（也称为“pcap”，得自库名称） “libpcap”）是对实际网络流量的观察。请务必注意 同时为两个端点捕获数据包，可能会很困难。 建议使用必要的工具（如 tcpdump 或 Wireshark）进行练习，并尽早安装以备不时之需。