Microsoft Fabric 采用路线图：用户支持

注意

本文是 Microsoft Fabric 采用路线图系列文章的一部分。 有关该系列文章的概述，请参阅 Microsoft Fabric 采用路线图。

本文介绍用户支持方面的内容， 主要侧重于问题的解决方法。

本文的前面部分重点讨论你可在组织内部进行控制的用户支持方面。 最后的主题重点介绍可用的外部资源。

如需相关主题的说明，包括为内部 Fabric 用户社区提供的技能启导、培训、文档以及合作开发帮助，请参阅启导和用户支持一文。 这些活动的有效性可显著减少正式用户支持请求量，并改进整体用户体验。

用户支持的类型

如果用户遇到问题，该用户是否了解可供自己选择的问题解决方案？

下图展示了一些组织成功采用的常见用户支持类型：

上图所示六种类型的用户支持包括：

类型	描述
	团队内支持（内部）是非常不正式的支持类型。 当团队成员在自然的工作过程中互相学习时，就会产生此类支持。
	社区内部支持（内部）的组织方式可以是非正式、正式或两者兼有的方式。 当同事们通过内部社区渠道相互交流时，就会产生此类支持。
	帮助中心支持（内部）将处理正式支持问题和请求。
	外延支持（内部）涉及技术支持上报的复杂问题的处理。
	Microsoft 支持（外部）包括对许可用户和 Fabric 管理员的支持。 其中还包括综合文档。
	社区支持（外部）包括全球范围的专家社区、Microsoft 最具价值专家 (MVP) 以及参与论坛和发布内容的积极分子。

在某些组织中，团队内支持和内部社区支持与自助式数据和商业智能 (BI) 的关系最密切（内容由分散式业务部门中的创建者和所有者拥有和管理）。 相反，技术支持和外延支持会预留给技术问题和企业数据和 BI（内容由集中式的 BI 团队或卓越中心拥有和管理）。 在某些组织中，所有这四种类型的支持都可能与任何类型的内容相关。

提示

有关商业主导的自助式、托管的自助式和企业数据和 BI 概念的详细信息，请参阅内容所有权和管理一文。

本文进一步详细介绍上面所列六种类型的用户支持。

团队内支持

团队内支持是指团队成员在日常工作中相互学习和帮助。 作为你的支持者的自助式内容创建者往往自愿承担这种类型的非正式支持角色，因为他们发自内心地乐意提供帮助。 虽然这是一种非正式支持模式，但不应该轻视。 一些估计结果表明，工作中的学习中有很大一部分是同伴学习，这对创建特定领域分析解决方案的分析人员特别有帮助。

注意

如果某部门中只有一位数据分析师，则团队内支持对其效果不佳。 对于组织中并没有很多人脉的人员而言，这也不是很有效。 在无法依靠任何关系密切的同事时，本文中所述其他类型的支持将变得更加重要。

内部社区支持

此类支持指来自社区伙伴成员的帮助，通常以消息的形式出现在专门为实践社区设置的讨论渠道或论坛中。 例如，有人发布一条消息，称自己在让 DAX 计算正常运作时遇到了问题，或是找不到要导入的正确 Python 模块。 然后该发布者就会收到组织中其他人的答复，答复中提供了建议或链接。

提示

建立内部 Fabric 社区的目标是让大家自己解决内部问题，从而减少正式支持需求和成本。 与单纯的集中式内容创作方法相比，这还有助于在更广范围内推进托管自助式的使用。 但是内部社区始终具有进行监视、管理和培养的需求。 下面是两条具体提示：

• 请务必在更困难的主题（例如 T-SQL、Python、数据分析表达式 (DAX) 和 Power Query M 公式语言）方面培养多位专家。 社区成员成为公认的专家后，有可能会因申请帮助的情况过多而负担过重。
• 很多社区成员也许能轻松回答某些类型的问题（例如报告可视化），而较少的成员会回答其他类型的问题（例如复杂的 T-SQL 或 DAX）。 COE 务必要让社区成员在有机会做出响应的同时愿意及时处理未回答的问题。 如果用户反复提问且得不到答案，社区发展将严重受阻。 在这种情况下，如果用户未收到任何问题的答案，用户便可能离开社区并再也不回来。

内部社区讨论渠道通常设置为 Teams 渠道或 Yammer 组。 所选技术应反映用户已在工作的位置，以便活动按其自然工作流发生。

内部讨论渠道的一个优势是：回复可能来自原始请求者以前从未见过的人。 在较大型的组织中，实践社区将兴趣相投的人聚在一起。 它通常可提供多种视角来获得帮助和学习。

使用内部社区讨论渠道可让卓越中心 (COE) 监视人们提出的问题类型。 这是 COE 了解用户要面临的问题的一种方式（通常与内容创建相关，但也可能与使用内容相关）。

监视讨论渠道还可以发现 COE 以前不知道的其他分析专家和潜在支持者。

重要

最佳做法是持续发掘新出现的 Power BI 支持者，并让他们参与进来，确保他们具备条件，可为其同事提供支持。 如实践社区一文中所述，COE 应主动监视讨论渠道，了解积极提供帮助的人员。 COE 应特意鼓励和支持社区成员。 如果合适，请邀请他们加入拥护者网络。

讨论渠道的另一种关键优势是：可搜索性，这使其他人能够发掘信息。 这实则是一种习惯上的转变，人们不再通过私人消息或电子邮件提问，而是在开放的论坛中提问。 请注意，有些人并不习惯以这种公开方式提问。 它会公开自己的“无知”，这可能会让他们感到尴尬。 通过推广颇有帮助的友好型、鼓励型讨论渠道，这种不情愿可能会随时间冲淡。

提示

你可能忍不住想要创建机器人来处理社区中一些最常见、最简单直接的问题。 机器人可以处理一些简单的问题，例如“我如何申请许可证？”或“我如何申请工作区？”在采用这种方法之前，请考虑是否有足够的常规和可预测的问题，思考这些问题是否能使用户体验更好而不是更差。 通常，精心设置的 FAQ（常见问题解答）效果更好，并且开发速度更快，更易于维护。

技术支持

技术支持通常由 IT 部门以共享服务的形式运营。 可能依赖于更正式的支持渠道的用户包括：

• 不太有经验的用户。
• 不熟悉组织的人员。
• 不情缘在内部讨论社区发布消息的人员。
• 在公司内部缺乏人脉和共事者的人员。

还有某些技术问题无法在没有 IT 人员参与的情况下完全解决，例如由 IT 部门管理的计算机需要软件安装和升级请求。

繁忙的技术支持人员通常致力于支持多种技术。 因此，最容易支持的问题类型是有明确解决方案并能记录到知识库中的问题。 例如，获取许可证的软件安装先决条件或要求。

某些组织给技术支持的任务只是处理非常简单的故障维修服务问题。 其他组织则让技术支持处理任何可重复的工作，例如新工作区请求、管理网关数据源或请求新的容量。

重要

Fabric 治理决策将直接影响技术支持请求量。 例如，如果选择限制租户设置中的工作区创建权限，则会导致用户提交技术支持票证。 虽然这是一项合理的决策，但你必须为快速满足请求做好准备。 如果可能，请在 1-4 小时内响应此类请求。 如果延迟时间过长，用户将使用他们已有的内容，或者使用某种方法来解决你的要求。 这可能不是理想的方案。 对于某些技术支持请求而言，及时性非常重要。 请考虑使用 Power Apps 和 Power Automate 实现自动化，这有助于提高某些流程的效率。 有关详细信息，请参阅租户级工作区规划。

随着时间的推移，故障排除和问题解决技能变得更加有效，因为技术支持人员拓展了其知识库和 Fabric 支持经验。 最优秀的技术支持人员都了解用户需要达成什么目标。

提示

纯粹的技术问题，例如数据刷新失败或需要将新用户添加到网关数据源，通常涉及与服务水平协议 (SLA) 相关的直接响应。 例如，可能有 SLA 需要在一小时内对阻塞性问题进行响应，并在八小时内解决此类问题。 一般而言，定义用于问题故障排除（例如数据差异）的 SLA 会更困难。

外延支持

由于 COE 可深入了解 Fabric 在整个组织中的使用方式，因此在出现复杂问题时，他们是外延支持的理想选择。 应当按照上报路径让 COE 参与到支持过程中。

将请求作为来自技术支持的上报路径进行管理很难强制实施，因为业务用户通常都对 COE 成员非常熟悉。 为鼓励大家养成通过适当渠道解决问题的习惯，COE 成员应引导用户改为提交技术支持票证。 这样做还将提高技术支持请求分析的数据质量。

Microsoft 支持

除了本文讨论的内部用户支持方法之外，还有一些用户和管理员可直接使用的重要外部支持选项，这些选项不应忽视。

Microsoft 文档

查看对所有客户有广泛影响的 Fabric 支持站点高优先级问题。 全局 Microsoft 365 管理员有权访问 Microsoft 365 门户中的其他支持问题详细信息。

请参考全面的 Fabric 文档。 这是一种权威资源，有助于进行故障排除和搜索信息。 可以优先采用文档站点中的结果。 例如，在网络搜索引擎中输入一个以站点为目标的搜索请求，例如 power bi gateway site:learn.microsoft.com。

Power BI Pro 和 Premium Per User 最终用户支持

获得许可的用户可向 Microsoft 记录支持票证。

提示

让内部用户社区清楚了解你是否希望将技术问题报告给内部技术支持。 如果技术支持能够承担这样的工作负荷，请使用集中式内部区域收集用户问题，这样能提供更好的用户体验，而不是让每位用户都试图自己解决问题。 实现可见性并分析支持问题对 COE 也很有帮助。

管理员支持

对于 Fabric 管理员，有多种支持选项可用。

对于拥有 Microsoft 统一支持合同的客户，可以考虑向技术支持和 COE 成员授予对Microsoft 服务中心的访问权限。 Microsoft 服务中心的一个优点是：可以将技术支持和 COE 成员设置为提交并查看支持请求。

全球社区支持

除了本文中所述的内部用户支持方法和之前所述的 Microsoft 支持选项外，还可以利用全球 Fabric 社区。

当一个问题能够让不了解相关领域的人轻松理解且不涉及机密数据或敏感内部流程时，全球社区就发挥了重要作用。

公开可用的社区论坛

公开的社区论坛包含多个，用户可以在这些论坛中发布问题并接收世界范围内任何一位用户的答复。 随时随地从任何人那里获得答案可能非常强大，而且非常有帮助。 但是，与任何公共论坛一样，务必要验证论坛上发布的建议和信息。 Internet 上发布的建议可能不适合你的情况。

公开可用的讨论区域

人们经常在社交媒体平台上发布 Fabric 技术问题。 你将发现讨论并发布公告，用户们会互相帮助。

社区文档

Fabric 全球社区充满活力。 每天都会发布大量 Fabric 博客文章、文章、网络研讨会和视频。 在依赖社区信息进行故障排除时，请留意：

• 信息发布时间。 尝试验证发布或上次更新的时间。
• 在线找到的解决方案对应的情况和背景是否真正符合你面临的情境。
• 所呈现信息的可信度。 依靠信誉良好的博客和网站。

注意事项和主要措施

清单 - 针对用户支持的注意事项和可采取的关键操作。

改进团队内支持：

• 提供认可和鼓励：如实践社区一文所述，为拥护者提供奖励。
• 奖励努力：看到基层做出有意义的努力时，请对其进行认可和赞扬。
• 设立正式职位：如果非正式的团队内支持不够，请考虑将你希望在该领域中设立的职位正式化。 在适当情况下，在 HR 职位描述中包括预期的贡献和职责。

改进内部社区支持：

• 不断鼓励提问：鼓励用户在指定的社区讨论渠道中提问。 习惯会随时间逐渐形成，将社区讨论渠道作为首选也会成为规范化的行为。 随着时间推移，社区将得到发展，变得更能自立。
• 积极监视讨论区域：确保合适的 COE 成员积极监视此讨论渠道。 他们可以在问题一直未得到回答时介入，改进答案或在适当的时候进行校正。 他们还可以发布指向其他信息的链接，以提高现有资源的认知度。 尽管社区的目标是实现自立，但仍需要使用专用资源来对其进行监视和培养。
• 交流可用选项：确保用户群体清楚内部社区支持区域的存在。 它可以包括链接的醒目显示。 可以在与用户社区的常规通信中包含链接。 还可以在 Fabric 门户中自定义帮助菜单链接，引导用户访问内部资源。
• 设置自动化：确保所有拥有许可证的用户都自动获得对社区讨论渠道的访问权限。 可以使用基于组的许可自动设置许可。

改进内部技术支持：

• 确定技术支持人员的职责：确定技术支持人员要处理的 Fabric 支持主题的初始范围。
• 评估就绪级别：确定技术支持人员是否已准备好处理 Fabric 支持。 确定是否有待解决的就绪情况缺口。
• 安排其他培训：开展知识转移课程或培训课程，为技术支持人员做好准备。
• 更新技术支持知识库：在可搜索知识库中包含已知的问题和答案。 确保有人负责定期更新知识库，以反映随时间出现的新功能和增强功能。
• 设置票证跟踪系统：确保有一个良好的系统来跟踪提交到技术支持的请求。
• 确定是否有人随时处理与 Fabric 相关的任何问题：如果合适，请确保全天候支持的预期明确。
• 确定将存在的 SLA：当存在特定的服务级别协议 (SLA) 时，请确保明确记录和传达响应和解决方案的预期。
• 做好快速行动的准备：做好极速解决特定常见问题的准备。 如果响应缓慢，用户将会寻求其他解决方法。

改进内部 COE 扩展支持：

• 确定升级支持的工作方式：确定在支持人员无法直接处理请求的情况下采用的升级路径。 确保 COE（或同等人员）准备好在需要时介入。 明确定义技术支持人员的职责上限，以及 COE 外延支持的职责下限。
• 鼓励 COE 和系统管理员之间的协作：确保 COE 成员和 Fabric 管理员有直接呈报路径来联系 Microsoft 365 和 Azure 的全局管理员。 当出现超出 Fabric 范围的普遍问题时，拥有通信渠道至关重要。
• 创建从 COE 返回到支持人员的反馈循环：当 COE 得知新信息时，应更新 IT 知识库。 这样做的目标是让主要的技术支持人员得到持续提升，在未来具备更多能力来处理更多问题。
• 创建从支持人员到 COE 的反馈循环：当支持人员察觉到冗余或效率低下的情况时，他们可以将该信息传达给 COE，后者可以选择改进知识库或参与其中（尤其是与治理或安全性有关的情况）。

应考虑的问题

通过类似于以下的问题来评估用户支持。

• 谁负责支持企业数据和 BI 解决方案？ 自助式解决方案呢？
• 如何确定问题的业务影响和紧急性，以有效发现关键问题并确定其轻重缓急？
• 是否有清晰明确的流程可供业务用户报告数数据和 BI 解决方案相关问题？ 企业和自助式解决方案在这方面有什么不同？ 什么是呈报路径？
• 内容创建者和使用者通常会遇到哪类问题？ 例如，他们是否会遇到数据质量问题、性能问题、访问问题等？
• 是否有任何问题在未解决的情况下被关闭？ 当前是否存在有关数据项或报表的“已知问题”？
• 是否有已可供数据资产所有者随时使用的用于将自助式 BI 解决方案相关问题呈报给 COE 等中心团队的流程？
• 数据和现有解决方案出现问题的频率有多高？ 在这些问题对业务最终用户造成影响之前，其中已被发现的问题的占比有多高？
• 解决问题通常需要多长时间？ 此时长是否满足业务用户的需求？
• 有哪些最近出现的问题及其对业务的具体影响的例子？
• 企业团队和内容创建者是否知道如何向 Microsoft 报告 Fabric 问题？ 企业团队能否有效利用社区资源来解决关键问题？

注意

评估用户支持并描述风险或问题时，请注意使用不会让个人或团队感觉受到苛责的中性语言。 确保评估中公平地体现了所有人的观点。 重在反映客观事实，以准确理解和描述上下文。

成熟度级别

以下成熟度级别有助于评估 Power BI 用户支持的当前状态。

Level	用户支持状态
100：起步	• 各业务单位找到相互支持的有效方法。 不过，这些策略是孤立的，并未得到一致应用。 • 提供内部讨论渠道。 但是，它不受密切监视。 因此，用户体验不一致。
200：可重复	• COE 积极鼓励团队内支持和拥护者网络的增长。 • 内部讨论渠道得到关注。 它逐渐成为反映和讨论问题的默认位置。 • 技术支持人员处理少数最常见的技术支持问题。
300：已定义	• 内部讨论渠道变得很受欢迎，且在很大程度上能自立。 COE 积极监视和管理讨论渠道，确保所有问题得到快速且正确的解答。 • 支持人员跟踪系统已到位，用于监视支持频率、响应主题和优先级。 • COE 在需要时提供适当的扩展支持。
400：有能力	• 支持人员经过全面培训，已准备好处理更多已知和预期的技术支持问题。 • 采用 SLA 定义技术支持期望，包括外延支持。 这些期望将被记录和传达，让所有人都清楚这些期望。
500：高效	• 技术支持和 COE 之间存在双向反馈循环。 • 关键绩效指标衡量满意度和支持方法。 • 自动化使支持人员能够更快地做出反应，并减少错误（例如，使用 API 和脚本）。

相关内容

在 Microsoft Fabric 采用路线图系列的下一篇文章中，了解系统监督和管理活动。