Policygenius是美国领先的在线保险市场。我们的使命是帮助人们在一个地方轻松了解他们的选择、比较报价和购买保单，从而帮助他们获得正确的保险。
背景
在过去四年中，随着业务的增长，Policygenius 数据团队和堆栈发生了很大变化（在此处阅读有关现有架构的更多信息。）回顾早年，我们在短时间内实现了一些工具，没有进行整体思考关于治理，因此，随着数据资产量的巨大增长（并且失控），我们开始感到痛苦。但是，重新审视治理策略永远不会太晚，这就是我们使用 Tableau 的经验。
这篇文章的目的是分享一个为期三个月的旅程和我们的 Tableau 如何从完全分散的无治理状态演变为具有适当治理策略的联合模型的经验。尽管重点关注 Tableau，但学习和一般原则应适用于任何商业智能和数据工具。对于像一年前一样在同一条船上的任何数据管理员，如果您打算彻底改革公司的治理策略，我希望这篇文章可以为您提供一些信心和见解。
大修前
自 2017 年底以来，Tableau 一直是我们的主要商业智能工具。我们在 Google Cloud Platform 上的单节点 Windows 虚拟机上部署了自我管理的服务器版本。我们的用户群从 2017 年 4 月的 15 个增长到 2021 年 6 月的约 100 个，此时有 1300 多个工作簿和 160 个数据源，消耗了大约 700GB 的磁盘空间。在过去的几年里，不断增加的用户群和工作给 VM 增加了很多负载。因此，我们的 Tableau Server 是我们数据架构中最关键且最容易出现故障的组件。以下是我们遇到的问题：
- 服务器膨胀，内容陈旧。由于缺乏审查和审计流程，内容不断堆积，因此数据工程团队不得不多次调整虚拟机的大小以跟上不断增加的磁盘使用量。同时。由于 I/O 操作受到磁盘空间不足的影响，Tableau 视图的呈现速度通常很慢。2021 年 6 月，我们开始看到更频繁的中断，几乎每周一次。
- 缺乏质量和访问控制。出版商可以在没有任何质量控制的情况下创建内容，并且可以根据需要提供访问权限。一些分析用户引用了过时或未经验证的报告，这导致业务团队之间的混乱和失去信任。这也导致了数据团队之间不必要的火灾，因为我们必须追踪不良数据的来源。
- 数据产品消费者的混乱体验。创建了许多命名约定不一致的嵌套项目，这让分析用户感到困惑，因为他们不知道在哪里寻找真相的来源。
大修
我们有几个选项，概述如下，并在考虑到用户现有工作流程的范围和中断程度后决定使用选项一。
选项 1：通过清理和执行适当的治理来彻底检查当前服务器。
好处：
- 对用户工作流程的干扰最小化，修改合同不需要文书工作。
风险：
- 设计治理控制所需的变更管理。
选项 2：迁移到托管版本，即 Tableau Online
好处：
- 对于 Tableau 用户，体验应该基本保持不变。当前工作簿/数据源可以按原样移动到托管版本。
- 以后的维护可以大大减少。
风险：
- Tableau Online 的空间使用硬性限制为 100GB，而我们的内容使用量大约是该限制的四倍。我们需要找到一种方法来大幅减少总内容大小，这需要大量的重构和与业务用户的协调。
- 我们需要将内容和用户从自托管服务器迁移到托管版本。
- 我们需要通过财务部门来修改我们的年度合同。
选项 3：迁移到另一个 BI 解决方案
好处：
- 与 Tableau Online 相比，有些托管 BI 解决方案需要的维护更少，因此从长远来看，它可能会减少维护。
风险：
- 这是最具破坏性的解决方案，因为我们需要将所有工作簿和数据源重新加工为与新工具兼容的格式并培训用户。
- 我们将需要通过财务和法律部门来创建新合同。
一旦承诺选项一，我们就并行启动了以下两个工作流——一次性整理和实施新的治理战略。
Marie-Kondo 风格的整理器
Tableau 将用户在服务器存储库中执行的每个操作记录下来，这使我们能够找出要删除的陈旧资源。我们确定要删除的内容超过 300GB，包括 900 多个过时的工作簿，在 90 天内没有收视率，以及 100 多个数据源没有与活动工作簿的任何连接。然后，我们编写了一个快速脚本以通过REST API进行整体删除。从通知内容所有者到等待确认到批量删除，我们花了大约 2 个冲刺。整个过程非常顺利，用户非常高兴他们有一个更干净的石板可供查看。
新的治理策略
我们提出了一项新的治理战略，并与所有部门负责人和领导层进行了交流，以获得支持。有三个关键组件：
1、联合治理模型
受这篇关于如何选择治理模型的帖子的启发，我们采用了由数据工程师和业务团队的高级用户组成的联合管家模型来监督日常运营并讨论政策和流程：
- 数据工程团队：负责服务器端维护，例如监控作业、设置刷新计划、许可和项目结构。
- 业务管家：每个部门提名一名主要和一名二级管家。一些管家可以被提升为项目负责人，这已经升级了给定项目的权限。由于此权限不可自定义，并且可能包含比我们想要的更多的访问范围，我们将项目负责人可以做什么和不可以做什么写下来，并让管家委员会相互问责。
- 仪式：管家每月开会讨论政策/流程变更的问题和建议。到目前为止，这是一次非常有成效的会议，我们在讨论后对流程进行了多项更改。
2、新的内容管理策略
我们创建了一个新的内容管理模型来明确定义服务器上实体之间的关系，并通过这个模型进行权限管理。
用户：一个用户被分配到一个或多个组。
组：组而不是用户根据不重复自己 (DIY) 原则确定对给定项目的访问范围。每个部门分为三组：
- {Business Team} — 创建者：可以在 {Business Team} 根项目中发布工作簿。{指定团队以外的业务团队}项目中的“无”权限，除非添加到特定业务团队组
- {Business Team} — Explorer：可以查看 {Business Team} 项目中的工作簿并与之交互。{指定团队以外的业务团队}项目中的“无”权限，除非添加到特定业务团队组
- {Business Team} — 查看者：可以查看 {Business Team} 项目中的工作簿。{指定团队以外的业务团队}项目中的“无”权限，除非添加到特定业务团队组。
项目：一个项目代表一组资产。
- 顶级项目：按部门分组，因为它们随着时间的推移保持不变。
- 二级项目：每个顶级项目都有一个用于开发目的的暂存子项目。
- 这适用于除运营之外的所有项目，由于内容的数量，我们将生活和财产与财产分开。
3、定期内容审核流程
使用自动化和半自动化流程，我们创建了一个定期清理例程：
- 删除陈旧的内容：为了继续保持我们的服务器干净和新鲜，并提供最新的内容，我们有一个定期流程来审核基于上述服务器存储库的陈旧资源的使用情况，并在需要时删除。
- 用于自动清理不需要的服务器文件的 Windows 计划作业：这是在大修之前添加的。Tableau 会清除一些但不是全部的临时文件，因此我们需要自己运行维护命令。下面说明了自动清理前可用磁盘空间的趋势。
上图一次性清理与每日自动清理后可用磁盘空间的变化情况
结论
自大修以来，我们收到了很多来自 Tableau 用户和管理员的积极反馈。我们还看到停机事件的发生显着减少 - 自大修以来，由于暂时的网络问题仅发生了一次事故。展望未来，我们正在扩大治理战略以包括上游系统，并继续将 Tableau 与市场上的其他解决方案进行比较，以增强 BI 功能。