本指南介绍了编写有效支持案例的最佳实践。遵循这些最佳实践有助于我们更快地解决您的技术支持请求。
创建支持请求
在创建支持请求之前，请查看已知问题，了解是否已有人提交过相同请求。
为避免混淆并确保我们可在单个点跟踪您的请求，请为每个问题创建一个支持请求。所有出现重复的情况都会被关闭。
描述您的问题
您撰写的支持案例越详细，Customer Care 团队就越能快速高效地回复您。当您的支持请求缺少关键详情时，我们需要您提供更多信息，这需要额外时间。
最佳支持案例既详细又具体。报告应说明发生了什么，以及您原本的预期是什么。在支持请求中描述问题时，请附上以下详细信息：
- 时间：出现问题的具体时间。
- 产品：与该问题相关的产品和功能。
- 位置：您遇到问题的区域。
- 标识符：项目/应用 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 支持请求会被移交给下一个区域 Customer Care，因为该支持日期当天，而其他支持请求仍由当前支持请求的所有者在第二天继续处理。
通过 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”中）是一种对实际网络流量的观察。因此，请务必同时为这两个端点捕获数据包，这可能会比较复杂。建议使用必要的工具（例如 tcpdump 或 Wireshark）进行练习，确保能在您需要前安装它们。