数据平台服务化建设（二）：把好权限的关

这是《数据平台服务化建设》系列的第 2 篇，预计会写 10 篇左右。通过这个系列，我希望和大家分享下数据平台怎么去做服务化建设。扫描文末二维码，关注公众号，不再错过精彩。也欢迎转发朋友圈分享给更多人。

数据平台包含的模块和组件特别多，相关硬件资源又往往由于共用而显得紧张，再加上数据又是及其重要的资产，必然就会有很多需要申请权限的场合。

草创之初，大家都会直接钉钉/微信找管理员，或者发邮件走走流程。

而具体流程是什么样，即使有文档和规范写清楚，往往也很难执行准确。

再后来，可能随着各个模块逐渐完善，会有自己的权限管理规范和流程引导。

但这些都不够用户友好。

我们的选择是做一个单独的权限申请系统。

域名可以用 apply.dp.company.com，简单好记。

页面也尽量简单，早期我们的系统长这样：

说起来哪哪都简单，但也有几点要注意。

第一，由于工单类型太多，所以有必要做下分类。

比如 Hive 相关的放在一起，HBase 相关的放在一起。

其实上面那个页面那样还不够好，因为分类也太多了。站在用户的角度思考，申请一个权限，需要想下这个权限应该属于那个分类，然后找到这个分类，再点开分类 tab，最后找到正确的工单。

有两个思路可以改进：

• 按照使用的角度而不是技术的角度去分类，比如数据类的权限、系统类的权限、API 类的权限等等；

• 做一些模板流程引导，比如新员工一定会申请的权限打包在一起，比如算法工程师基本权限组合做成快捷方式等。

第二，审批流程要合理，并尽量做到自动化处理 。

自动化处理好理解，工单流程走完后，调用程序直接赋权。

以我所在的公司为例，由于采用了以 Kerberos 和 Ranger 为核心的权限方案，对接 Kerberos 和 Ranger 就成为了主要需要自动化的地方。

流程合理，就相对复杂些。

以申请一张 Hive 表的权限为例，我建议：

• 审批人为表的 owner，因为这个 owner 有权决定这个数据是否要开放给申请人，

• 抄送申请人 leader 和其他相关人，而不把申请人 leader 放入审批流程，因为申请人 leader 往往会无脑全部通过。

具体提醒方式，可以采用邮件+钉钉/企业微信的形式。

第三，做好和其他系统的串连 。

上一篇，我说过要用合适的节奏推进服务化建设，其中很重要的一点就是做串连。这里就是个很好的例子。

我们既然做了专门的权限申请系统，那其他系统就不应该再重复实现，而是应该直接复用。

具体来说，体现在两方面：

• 权限申请系统需要提供 API 供其他系统调用，

• 其他系统在需要申请权限的时候，以链接的形式跳转到权限申请系统，并通过传参自动填写相应字段。

独立的权限系统，是我们思考讨论后的方法，能最大程度的复用功能，并且方便管理。

当然，这种做法也不是必须的，可能有人就觉得一个系统不应该跳到别的系统，才能完成自己也能做的事。

这种用户体验上的事，本就是见仁见智。只是出于复用的考虑，我们倾向于也推荐这样做。

原创不易

关注/分享/赞赏

给我坚持的动力