创建支持票证时的最佳做法

创建有效的 Power BI 或 Fabric 支持票证需要提供特定信息来帮助Microsoft快速解决问题。 本文提供了提交支持请求时要包括的最佳做法和关键信息，可帮助你更快地解决问题。 所需的特定信息取决于你的问题，并非所有提示都适用于每个案例。

要提供给Microsoft的信息

根据具体问题，可能会要求你提供以下信息。

1. 遇到问题的浏览器页面的 URL。 URL 提供了信息，说明您在工作区（即问题发生的位置）遇到问题时所涉及的项或功能的类型和 ID。

2. 问题位置（Power BI Desktop/Power BI 服务/两者）此信息始终与服务请求相关。 如果一个进程在 Power BI 服务上失败，但在桌面上成功，或者反过来也是如此，那么这些信息可以向 Microsoft 提供可能的问题原因的有用信息。 另一个示例是同一 M 代码在数据集中工作，但在数据流中失败。 除了这两个示例之外，还有许多问题的场景可以通过准确确定问题发生的位置和未发生的位置来进行故障排除。

3. 错误代码

   如果在出错时生成错误代码，请复制该错误代码的副本。 Microsoft保存有关所有错误代码的详细信息，并使用此信息诊断问题。 错误代码不太可能自行解决问题，但它大大加快了故障排除过程。

   小窍门

   使用 “复制 ”按钮检索代码。 不要发送屏幕截图。 错误代码长（通常为 30 个字符长），并且手动从屏幕截图中转录会增加出错的可能性。

4. 使用的数据源和存储模式数据源信息始终与服务请求相关。 每个数据源都有一些仅与自身相关的问题。 如果使用多个源，请使用试错法来确定导致问题的源。

   使用不同的存储模式时，Power BI 的行为也不同。 三个主要存储模式选项包括：

   • 进口
   • 直接查询
   • 实时连接

   还有两种特殊情况：

   • 混合模式存储（复合模型）
   • PBI 数据集和 Analysis Services 的直接查询

   若要标识 Power BI Desktop 中使用的数据源，请选择当前文件中的 数据源设置>数据源 。 在 Power BI 服务中，导航到“数据源凭据”下的设置页面或通过血缘视图进入。 可以通过选择“查看世系”或将工作区视图从列表更改为世系来访问此信息。

   小窍门

   若要了解正在使用的存储模式，请联系报表开发人员或查看 PBIX 文件。

5. 容量识别码

   容量 ID 使 Microsoft 了解正在使用的容量类型（例如，高级）。 只有容量管理员才能查找容量 ID。 如果你是容量管理员，请打开管理门户，然后选择 “容量设置>Power BI Premium ”并选择容量的名称。 容量 ID 是 URL 的最后一部分。

   https://app.powerbi.com/admin-portal/capacities/ XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX

   或者，容量管理员可以使用此 REST API 检索容量 ID。

6. 数据集 ID

   如果问题影响数据集，ID 有助于Microsoft标识正确的数据集，然后调查在该数据集上运行的进程。 若要查找数据集 ID，请导航到包含数据集的工作区并打开 数据集设置。 数据集 ID 是 URL 的最后一部分（datasets/dataset-id）。

   https://app.powerbi.com/groups/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/settings/datasets/ XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX

7. PBIX 文件副本（仅限导入查询）

   遇到导入模型问题时，使用 PBIX 文件可帮助支持工程师重现问题并加快故障排除速度。 如果 PBIX 包含机密信息，请务必共享匿名版本。

   重要

   在共享潜在机密信息之前，请务必与组织中的相关方确认。

8. 网关日志

   排查任何网关或网络问题时，需要网关日志。 若要自行分析网关性能，请使用 网关性能监视模板。 有关详细信息，请参阅 支持票证的导出日志。

9. 诊断信息

   按照 Power BI Desktop 诊断集合 中的步骤查看和收集诊断信息。

10. 数据流 JSON

    当数据流正在使用时，此选项非常有用。 若要导出 JSON 并将其与支持工程师共享，请转到工作区，选择数据流项，然后选择 Export.json。

    

常见问题

除了前面所述的标准信息之外，以下信息可帮助支持工程师排查问题。

此问题是否仅在特定容量中出现？

切换到另一个容量或共享容量是否解决了该问题？ 有时，问题特定于某些环境。

此问题是否会影响所有用户？

问题是公司范围内，只影响一组人，还是只影响一个人？

之前正常工作的问题现在出现新问题了吗？

错误是无用户端发生任何更改的情况下开始的，还是因某种更改或新实施而触发的？ 确定断点有助于缩小潜在根本原因的范围。

问题的范围是否比最初遇到的更窄或更广？

问题是否影响所有、部分或仅影响一个“事情”？ 例如，如果问题与 API 相关，其他 API 是否正常工作？ 如果是导出问题，所有报表是否都受到影响？ 如果是容量问题，则所有容量的行为方式是否相同？ 如果报表未刷新并且它包含多个数据源，是否已单独测试每个源？

是否已尝试故障排除步骤？

此信息通过避免重复来加快解决问题的速度。 但是，在某些情况下，支持工程师可能仍希望重复你执行的步骤。

是否可以以更简单的形式复制问题？

有时无法与Microsoft共享机密信息。 尝试使用问题的简化版本来复制问题，并向支持工程师提供可靠的重现步骤。