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

Microsoft 排查你的案例所需的具体信息由你遇到的问题决定。 关于收集支持请求的必要信息,本文提供了提示和最佳做法。 请注意,所有这些并非适用于所有情况

向 Microsoft 提供的信息

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

  1. 遇到问题的浏览器页面的 URL。 通过该 URL 可了解你遇到问题的位置(工作区)以及项或功能类型或 ID。

  2. 问题的位置(Power BI Desktop 和/或 Power BI 服务)。此信息始终与服务请求相关。 如果进程在 Power BI 服务上失败,但在 Desktop 上成功(或者是相反的情况),这将向 Microsoft 提供有关问题可能原因的有用信息。 另一个示例是,相同的 M 代码在数据集中工作,但在数据流中失败。 除了这两个示例外,还有很多情况可通过准确确定发生问题的位置和没有发生问题的位置来排查问题。

  3. 错误代码

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

    提示

    使用“复制”按钮来检索代码。 不要发送屏幕截图。 错误代码很长(通常有 30 个字符),手动抄写屏幕截图中的内容会增加出错的可能性。

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

    使用不同的存储模式时,Power BI 的行为也会有所不同。 三个主要的存储模式选项是:

    还有两种特殊情况:

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

    提示

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

  5. 容量 ID

    容量 ID 可让 Microsoft 知道正在使用的容量类型(例如 Premium)。 只有容量管理员可以查找容量 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。

    export json

其他注意事项

除了上述标准信息外,以下信息(如果可用)也可帮助支持工程师排查问题。

此问题是否仅在特定容量中发生?

切换到其他容量或共享容量是否解决了此问题? 有时,仅在某些环境中发生此问题。

此问题会影响所有用户吗?

此问题是公司范围的问题,仅影响一定数量的人员,还是仅影响一个人?

这是之前在处理的内容出现的新问题吗?

此错误是在用户端未进行任何更改的情况下开始出现的,还是由某种更改或新实现触发的? 确定断点有助于缩小潜在根本原因的范围。

问题的范围比最初遇到的更窄还是更宽?

问题是影响所有内容、一些内容还是仅影响一项内容? 例如,如果问题与 API 相关,其他 API 是否正常工作? 如果是导出问题,所有报表是否都受到影响? 如果是容量问题,所有容量的行为是否都一样? 如果报表未刷新且包含多个数据源,每个源是否都分别经过了测试?

是否尝试过任何故障排除步骤?

这可避免重复操作来加快问题的解决速度。 但是,在某些情况下,支持工程师可能仍希望重复你已经执行过的步骤。

是否可以一种更简单的形式重现问题?

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