与 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-a…”
  • “我试过区域 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 Cloud Platform 技术支持服务准则所定义,各个问题优先级具有预定义的响应时间。如果您需要在特定时间之前收到回复,请在报告说明中告知我们。如果需要我们不分时段即刻处理 P1 问题,您可以申请全天候服务。这些案例每天会重新分配几次给活跃的客户服务专员。

升级

当情况发生变化时,您可能需要上报问题。上报的合理原因如下:

  • 对业务的影响加剧。
  • 对解决流程的细分。例如,您在约定的时间内未收到更新,或者在交换多条消息后,您的问题处于“停滞不前”的状态。

如果您遇到影响较大的问题,最好的解决方案是在足够的时间内将案例设置为适当的优先级,而不是上报。上报不一定能更快地解决支持请求,在优先级发生变化后立即上报,甚至可能会导致请求解决速度变慢。您可以在何时上报视频中找到更详细的说明。

如需了解如何上报支持请求,请参阅上报支持请求

将支持请求转送到所需时区

鉴于客户服务可用性所依据的因素,您的支持请求可能会分配给在您的工作时间以外工作的客户服务专家。此外,您可能希望在特定时区的工作日与客户服务团队接洽。在这种情况下,我们建议您请求客户服务团队将您的支持请求路由到一个对您的支持请求的时区。您可以在请求说明或回复中添加此要求。例如 Please route this case to the Pacific time zone (GMT-8)。P1 支持请求会移交到下一个区域的客户服务团队,因为它全天候服务,而其他支持请求仍将由当前支持请求所有者继续处理,第二天将继续处理。

通过 CES 调查问卷提供反馈

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

客户体验团队会人工审核每个反馈表单,并采取相应的措施来改善您未来的体验。调查问卷为 5 分制。如果得分不高于 3 分,则客户认为很难,我们会根据这些答复与您联系。另一方面,如果得分为 4 分或更高,则表示互动对客户来说并不难,可以视为一种良好的体验。

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

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

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

如需使用该模板,请打开上述链接并复制一份。请添加指向所有相关支持请求和内部跟踪 bug 的链接。请与您的客户支持团队共享此文档,并请他们与特定的客户服务专家共享。

本文档包含:

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

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

报告生产环境服务中断

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

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

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

您应该会收到一条简短的消息回复,其中包含:

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

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

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

报告网络问题

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

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

首先通过互联网 IP 地址或 RFC 1918 专用地址及网络标识符来识别受影响的网络端点。例如,Compute Engine 项目默认网络上的 2.3.4.5 或 10.2.3.4。

请注意与端点有关的任何有意义的信息,如:

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

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

  • 路径分析是数据包遍历的所有跃点的列表,也就是通常所知的“traceroute”。我们经常使用 MTR 和/或 tcptraceroute,因为它们的诊断能力更强。我们建议您熟悉一下这些工具。
  • 数据包捕获(也称为“pcap”,得名于库“libpcap”)是对实际网络流量的观察。请务必同时对两个端点进行数据包捕获,这可能会很棘手。最好使用必要的工具(例如 tcpdumpWireshark)进行练习,并确保在您需要前安装这些工具。