您撰写的支持案例越详细，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 或 Cloud 控制台网址（或屏幕截图）。对于 API，您可以链接到文档页面，该页面的网址中包含产品名称。
此外，请告诉我们您发起请求的机制（例如 REST API、gcloud 工具、Cloud Console，或者 Deployment Manager 等工具）。如果涉及到多个产品，请注明每个产品的名称。
示例：
- “Google 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 的系统无关（例如，它是不是您的家用互联网、VPN 端点或外部监控系统的地址）。
示例：
- “在项目 robot-name-165473 或 my-project-id 中…”
- “在多个项目中（包括 my-project-id）…”
- “从我们公司网关 56.56.56.56 连接到 GCP 外部 IP 218.239.8.9…”
以下一般性陈述过于宽泛，无助于问题诊断：
- “我们无法访问某个实例…”
- “我们无法通过互联网连接到…”
有用的文件
向我们提供与问题相关的文件可帮助我们准确了解您遇到的问题，从而加快问题排查。
例如：
- 使用屏幕截图显示您所看到的具体问题。
- 对于网页界面，请提供 .HAR (Http ARchive) 文件。HAR 分析器 提供了针对三款主要浏览器的说明。
- 将 tcpdump 输出、日志片段、示例堆栈轨迹添加为附件。
问题类型：
间歇性：间歇性问题随机发生，没有有规律的故障模式。间歇性问题很难进行排查，因为它们没有规律，导致难以在故障期间收集数据。在这种情况下，您应尝试找出架构中的瓶颈，并检查您的资源是否达到其最大阈值用量。您还可以使用自动化在预定作业中频繁执行检查，如果检查失败，则在失败期间收集调试信息。此类故障的示例包括 DNS 解析失败和丢包。
瞬时性：瞬时性问题暂时存在，或仅存在很短时间。如果您遇到的问题只发生一秒钟或者几微秒，您可以检查是否有短暂的流量或资源使用峰值。在大多数情况下，如果瞬时性问题不经常发生，且您的服务设计为可以容忍瞬时故障，则可以忽略。此类故障的示例包括仅出现几微秒的网络延迟高峰，以及导致超时的少量丢包。请注意，传输控制协议 (TCP) 的设计考虑了诸如少量丢包和延迟高峰等故障，除非您的应用对延迟敏感，否则它可以有效地处理这些问题。
持续性：持续性问题指导致全面故障的问题，例如网站停机。持续性问题相对比较容易排查，因为它们可以重现。这种情况下，请告诉我们重现问题的步骤，以便我们的支持工程师能够复制该环境并为您排查问题。
设置和提升优先级
优先级可帮助我们了解该问题对您业务的影响，并且会影响我们解决问题的响应速度。优先级的定义见下表。您可以在 Cloud 支持流程 中找到更多信息。
| 优先级定义 | 示例情境 |
|---|---|
| P1：重大影响 - 生产环境中的服务无法使用 | 生产环境中的应用或基础架构无法使用，向用户显示大量错误。对业务的影响重大（收入损失、潜在数据完整性问题等）。 |
| P2：高度影响 - 服务受到很大影响 | 基础架构在生产环境中性能降级，向用户显示较多错误，或者难以启动新的生产系统。对业务的影响中等（存在收入损失的风险、工作效率降低等）。 |
| P3：中度影响 - 服务受到部分影响 | 问题影响的范围和/或严重性有限。问题不会带来用户可见的影响。对业务的影响小（例如，为业务造成不便，业务流程受到微小影响等）。 |
| P4：低影响 - 服务完全能够使用 | 对业务或技术几乎没有或根本没有影响。建议通过咨询工单解决，这一途径会更多地进行深入分析、问题排查或者咨询，而不是更频繁的沟通。 |
何时设置最高优先级
如果您遇到的问题会影响关键业务服务并且需要 Google 立即加以关注，请选择“P1”优先级。请向我们详细解释您选择 P1 的原因，简要说明该问题对您的业务产生的影响。例如，如果开发版本的某个问题妨碍了重要的安全修复，即使没有直接影响到任何最终用户，也建议您将该问题划分为 P1。
当案例设置为 P1 时，值班的支持团队成员会立即收到通知，以寻找合适的专家专门处理该问题。您将会收到快速初始回复。此后，您会收到定期更新。
感谢您对所选优先级的详细评论，因为这有助于我们做出适当的回复。
响应时间
如 Google Cloud Platform 技术支持服务准则所定义，各个问题优先级具有预定义的响应时间。如果您需要在特定时间之前收到回复，请在报告说明中告诉我们。如果需要我们不分时段即刻处理 P1 问题，您可以申请 “全天候” 服务。我们会每天多次将这些案例分配给当班的支持工程师。
升级
当情况变化时，您可能需要提高问题的优先级，以便其更快获得关注。提升优先级的合理理由包括：
- 对业务的影响加剧。
- 需要更快地解决问题。
- 经过几个回合的沟通后，问题仍然“停滞不前”，毫无进展。
如需了解如何上报案例以及上报案例时会发生什么情况，请参阅上报案例。
如果您不确定上报是否是适当的措施，请花几分钟时间观看我们关于什么时候应进行上报的视频剪辑。
将请求转到所需时区
由于 Customer Care 可用性所基于的因素，您的支持请求可能会被分配给工作时间与您不同的支持工程师。您也可能希望在某个特定时区的工作时间与 Customer Care 团队联系。在这些情况下，我们建议您要求 Customer Care 将支持请求转到适合该请求的时区。您可以在请求说明或回复中添加此要求。例如 Please route this
case to the Pacific timezone (GMT-8)。P1 请求会移交给下一个区域 Customer Care，因为它是全天候服务，而其他请求仍由当前的请求负责人在次日继续处理。
通过 CES 调查问卷提供反馈
您的问题得到解决后，我们会通过电子邮件向您发送客户费力度 (CES) 调查问卷，以了解您对互动过程的意见。我们邀请您花几分钟时间填写这份调查问卷，帮助我们了解哪些方面做得较好，哪些方面有待改进。
客户体验团队会人工审核每个反馈表单，并采取相应的措施来改善您未来的体验。调查问卷为 5 分制。3 分或以下表示客户认为互动过程比较麻烦，我们将跟进这些回复。4 分或以上表示客户认为互动过程简单（轻松），因此被视为积极体验。
如需了解详情，请参阅如何使用 CES 提交 GCP 服务反馈。
长期存在或难以解决的问题
需要很长时间才能解决的问题可能会变得信息陈旧且令人费解。要防止发生这种情况，最好的方法是使用我们的长期问题模板收集信息，将最新状态信息汇总在顶部。
要使用该模板，请打开上文中的链接并复制一份副本。请提供指向所有相关案例和内部跟踪错误条目的链接。将此文档提供给您的客户支持团队，并请他们将其转交给特定的支持工程师。
该文档包括以下内容：
- 当前状态摘要（位于顶部）。
- 可能成立的假设的列表。
- 您打算用于测试每个假设的测试或工具。
尽量在每个案例中只提出一个问题，并避免通过重开案例来提出新问题。
报告生产环境服务中断
如果问题导致您的应用停止向用户传送流量，或者产生类似的关键业务影响，这可能属于生产环境服务中断问题。我们希望尽快获知此类问题。与此相对，仅对少数开发者造成影响的问题不是我们所说的生产环境服务中断问题。
收到生产环境服务中断报告后，我们会通过以下方式对情况进行快速分类：
- 立即检查是否有影响 GCP 基础架构的已知问题。
- 确认问题的性质。
- 建立沟通渠道。
您会收到一条简短回复，其中将包含以下信息：
- 影响多个客户的任何相关已知问题。
- 确认我们能观察到您所报告的问题，或者请您提供更多详细信息。
- 我们打算如何传达。
因此，请务必快速创建包含时间、产品、标识符和位置信息的案例，然后开始更深入地排查问题。您的组织可能有规定的突发事件管理流程，此步骤应在该流程中尽早执行。
Google 的突发事件管理流程定义了一个关键角色：突发事件指挥官。 此人会负责联络适当人员加入进来、持续收集最新状态、定期汇总问题的状态， 以及委派其他人进行问题排查并执行更改。通过这种委派，我们可以并行调查多个假设。我们建议您在组织内部也建立类似的流程。创建案例的人员通常是突发事件指挥官的最佳人选，因为他们最了解情况。
报告网络问题
Google 网络规模大、复杂性高，致使人们难以分辨出了问题应找哪个团队负责。要诊断网络问题，我们需要找出非常具体的根本原因。由于网络错误消息通常十分笼统（如“无法连接到服务器”），因此我们需要收集详细的诊断信息，以缩小可能的假设范围。
数据包流程图为问题报告提供了良好的参考结构。这些图表说明了数据包在从来源到目标的路径中经过的重要跃点，以及过程中的任何重大转换。
首先通过互联网 IP 地址或者通过 RFC 1918 专用地址及网络标识符来识别受影响的网络端点。例如，2.3.4.5 或 Compute Engine 项目的默认网络上的 10.2.3.4。
请注意与端点有关的任何有意义的信息，如：
- 谁控制着它们。
- 它们是否与 DNS 主机名关联。
- 任何中间封装和/或间接连接，如 VPN 隧道、代理和 NAT 网关。
- 任何中间过滤，如防火墙或 CDN 或 WAF。
表现为高延迟或间歇性丢包的许多问题需要进行路径分析和/或数据包捕获，以便执行诊断。
- 路径分析是数据包遍历的所有跃点的列表，也就是通常所知的“traceroute”。我们经常使用 MTR 和/或 tcptraceroute，因为它们的诊断能力更好，因此请熟悉这些工具。
- 数据包捕获（又称为“pcap”，得名于库“libpcap”）是对实际网络流量的观察。必需同时对两个端点进行数据包捕获，此过程可能很复杂。建议使用必要的工具（如 tcpdump 或 Wireshark）进行练习，并尽早安装以备不时之需。
示例案例
示例 1
作业名称：
A_ATL_BIG1toBQ_big_04)201704202
00045_491
来源：
S3_avl-transfer
目的地：
CloudStorage：avl-transfer
开始时间（ISO 8601 格式）：2017-04-20 20:14:43 PDT
结束时间（ISO 8601 格式）：2017-04-21 10:03:44 PDT
我在 2017-04-20 20:14:43 PDT 开始使用 Transfer API 传输文件。该作业通常只需 10 分钟即可完成，但这一次，当我在次日 (2017-04-21 10:03:44 PDT) 取消作业时，作业仍在运行。这并不是一次孤立事件；涉及该 API 的多个其他作业均出现了间歇性重大延迟。
请调查延迟的原因，并告知我们可以实施的任何最佳做法，以防止未来再出现此问题。
示例 2
开始时间（ISO 8601 格式）：2017-05-12 11:03:43
结束时间（ISO 8601 格式）：截至本报告提交之时，问题仍然存在。
问题摘要：
使用 App Engine Task Queue API 的 /cron/payments-service/sync-v2-batch cron 作业自 2017-05-12 11:03:43 起停止运行。我们依赖该作业正确处理付款。
我们看到数据存储区和队列错误，然后此 Cron 作业就停止了运行。我们尝试通过重新上传 cron.xml 来修复问题，但未能成功。错误跟踪记录如下所示：
[error trace]
请说明问题在于 API 还是在于我们的实现方式，并告知应采取什么后续步骤。