与 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）…”
  • “从我们的公司连接到 Google Cloud 外部 IP 218.239.8.9 网关 56.56.56.56...”

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

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

有用的文件

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

例如：

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

问题类型

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

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

  • 持续性：持续性问题指导致全面故障的问题，例如网站停机。持续性问题相对来说比较简单， 因为它们可以重现在本例中，请告诉我们操作步骤 重现问题，以便我们的 Customer Care 专家 并为您排查问题。

说明示例

示例 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 需要全天候处理，因此您可以请求“遵循 sun" 服务。这些 每天多次将支持请求重新分配给活跃的 Customer Care 团队 专家。我们会对您的 P1 支持请求进行问题排查，但建议您继续 积极回答问题，直至解决，从而提高效率 通信。如果超过 3 小时没有回应，我们可能会降低 将支持请求的优先级更改为 P2，直到您再次互动为止。

升级

当情况发生变化时，您可能需要上报问题。正当理由 包括：

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

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

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

将案例移交至所需时区

由于客户服务团队考虑的因素 可用性取决于 支持请求可能会分配给 。您或许是想吸引 在特定时区的工作日与 Customer Care 团队联系。在 在这种情况下，我们建议您请求客户服务团队将您的 支持请求的时区。您可以在请求说明或回复中添加此要求。例如 Please route this case to the Pacific time zone (GMT-8)。P1 支持请求会移交给下 Customer Care 区域遵循 周日 而其他支持请求则由当前支持请求负责人继续处理 第二天就可以处理此案例

通过 CES 调查问卷提供反馈

您的问题得到解决后，我们会通过电子邮件向您发送客户费力度 (CES) 调查问卷，以了解您对互动过程的意见。我们 如果您能抽出几分钟时间填写这份表单，我们将不胜感激 我们做得好的方面，以及改进这些方面所面临的挑战。

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

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

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

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

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

本文档包含以下内容：

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

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

报告生产环境服务中断

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

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

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

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

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

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

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

报告网络问题

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

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

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

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

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

许多表现为高延迟或间歇性丟包的问题 需要路径分析和/或数据包捕获才能诊断。

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