后台产品的基石权限管理体系设计

　　文章作者主要讲解了一些关于后台产品权限设计体系，来文中看看
　　什么是后台产品？
　　简而言之，我们日常使用的互联网应用，有一些需要做数据信息的呈现，管理维护这些数据信息的产品，就是后台产品。
　　举个例子：在音乐app中有很多的歌曲、专辑、歌手等的内容，这些内容都需要在曲库后台中进行上传、信息关联等操作，这里的曲库后台就是一个后台产品。
　　后台产品为什么要做权限管理？
　　后台产品中有大量的数据，需要较多的人员来对这些数据进行管理，不同人分别负责管理自己的数据。且不同的人，在整个数据管理流程中，需要进行的操作不同。那么此时，我们就需要对这些人员的权限进行不同的定义，具体人员可以看什么，不可以看什么，从而确保数据的稳定性，降低数据泄露的风险。
　　同样用曲库后台举例子，有的人负责维护华语音乐，有的人负责英语音乐，那么负责话语音乐的人，不可以操作英语音乐的数据。在负责华语音乐的人中，有的人负责上传歌曲源，有的人负责整理音乐，打包成歌单呈现给用户，那么负责上传歌曲源的人，不可以去进行歌单的编辑。
　　权限管理的基础：组织结构
　　人员层级的划分是做权限管理的基础，几乎稍有规模的公司，都会有人员管理层级的划分，我们称之为组织结构，在组织结构中，明确指定人员的汇报关系、负责的业务模块、人员的岗位等等。
　　组织结构的一个简单示意图如下，节点用于对业务模块、工作范畴进行划分。在一个业务模块内，不同职能的人员，用岗位来进行区分，例如研发进行功能的开发，QA进行功能的验证测试。
　　权限管理体系如何搭建
　　权限管理体系可以划分为三个层级：功能权限、数据权限、按钮字段权限。
　　功能权限：定义人员是否可以访问某个页面。例如曲库后台，曲库资源的管理人员，可以访问曲库资源的管理页面，不可以访问歌单资源的管理页面。
　　数据权限：定义人员在页面中，可查看的数据的范围。例如曲库后台，曲库资源的管理人员中，华语音乐管理员可查看华语音乐，不可查看英语音乐。
　　按钮字段权限：定义人员针对查看到的数据，可以进行的操作，或可查看的字段。例如曲库后台有歌曲的上传和删除的操作，曲库资源的管理人员中，上传资源的人员只能看到上传按钮，不可查看歌曲的删除按钮。只可查看歌曲的基础信息，不可查看歌曲的定价信息。
　　从上图和上面的描述举例中，可以看出来，这三层权限控制是逐渐递进的关系，从最基本页面访问，到具体数据信息操作，对于权限的粒度管理越来越细致。
　　那么基于这个理论基础，在设计上如何实现呢？
　　功能权限：页面是具体功能的一个实现，而功能的使用与人员的职能相关，结合我们前面讲的组织结构可以得出，功能权限与岗位密切相关。因此我们做权限配置时，可以考虑将岗位与页面权限绑定，这样在岗位人员更替的过程中，只要岗位职能不变，那么我们对岗位和页面权限的绑定就是无需变更的。例如编辑人员拥有曲库编辑页的权限，运营人员拥有歌单编辑页的权限。
　　数据权限：同岗位的人员负责不同范围的数据，那我们可以通过定义人员可查看自己负责标签范畴内的数据来实现数据权限的管控。如果数据量特别大，同岗位的人员也需拆分给不同的管理人员来管理，甚至管理人员还是多层级的，那么此时就需要借助组织节点一起定义数据权限，最末级节点人员查看自己标签范畴内的数据，上级节点的人员查看自己下级节点人员的数据汇总。
　　按钮字段权限：按钮字段权限本质上还是对一个功能的控制，只是这个功能内嵌于页面内，比页面的颗粒度更细，所以按钮字段权限可以和功能权限一样，与岗位绑定。
　　权限管理体系的丰富拓展
　　上述的三层权限体系可以满足我们基础的权限控制的需求了，但是在一些特殊的情况下，有一些上述体系不能满足需求的情况，该怎么去拓展这个权限控制体系呢？
　　以下列举了一些：
　　场景一：同岗位的员工，进一步进行了工作模块的划分，希望他们可以拥有不同的功能权限
　　对于岗位通用的权限，我们可以用岗位与权限绑定来配置。若同岗位员工的工作模块不同，有一些权限不可直接赋予岗位，而是与具体人员关联时，可以抽象出一层虚拟角色，这些角色集成一个工作模块的特殊权限，然后将角色直接赋予具体的人员。
　　这样可以用虚拟角色来进行权限的规范管理，同时又能满足同岗位人员需要配置特殊权限的情况。
　　场景二：某些员工临时支援他人工作，需要临时拥有一些功能和数据权限，但是组织结构不可调整
　　组织结构中的岗位和节点上下级关系，定义好了人员的全部权限。当对象的组织岗位关系不可调整，但是需要添加对象的各项权限时，我们可以通过加成权限来实现。加成权限就是指人员拥有自身所在组织岗位的权限，同时还可以拥有特殊配置的权限。
　　这个特殊配置的权限怎么配呢？
　　这个配置的基础结构时，配置对象在某些系统中拥有某些节点岗位的全部权限。我们把配置对象、某些系统、某些节点岗位拆开描述如下。
　　配置对象：这个要临时添加权限的对象，可能是员工，可能是某组织节点全部人员，甚至某岗位全部人员，因此这个配置对象可以根据需求去拓展，支持多选。
　　某些系统：一个大的后台中可以进一步拆分系统，如果需要限制是这个加成权限只在部分系统生效，那我们可以增加生效系统的配置。
　　某些节点岗位：这个就是配置对象具体需要什么节点岗位的权限，在某些节点岗位这一环节中配置。
　　场景三：某些非顶级节点的员工，需要拥有全部数据的权限；某些有问题的员工，不可拥有任何数据的权限
　　这个是最简单的，可以通过添加人员的白名单和黑名单来解决。白名单中的员工，默认赋予全部数据的权限。黑名单中的员工，默认不拥有任何数据的权限。
　　白名单和黑名单的赋予，支持给通过节点、岗位、人员来配置，操作更灵活方便。
　　以上是我对后台产品权限设计体系的一些分享，希望对进行后台产品设计的初级同学有一些帮助，欢迎留言一起交流。