关于大后台的权限管理设计
编辑导语:大后台是多个产品后台的域名入口,如今很多产品都采用了这种方式进行管理,可以使产品得到各方面的一致性;大后台的搭建也可以让产品得到更好、多层次的体验;本文作者分享了关于大后台的权限管理设计,我们一起来了解一下。
一、何为大后台?
本文讲述的大后台是基于作者的实际工作需要而提出的后台整合型的概念,是内部多个后台系统的集合。
具体是指,多个产品后台通过一个域名入口,接入集团通讯中心,实现统一的登录和权限管理,采用类似的UI规范展示;并在这过程中形成统一的产品矩阵,形成技术影响力。
因此,用户可更加便捷访问相关产品,管理员也可以在权限设置上达到事半功倍的效果。
二、为什么要进行大后台的整合?
在两年多的时间内,产品技术部开发了多款不同领域的产品,目前负责开发和运维的产品后台有6个。
早期的产品都是独立域名、独立登录账号系统、独立的UI视觉和交互。后期的几个产品在进化过程中,有部分功能进行了统一,但是并没有达到完全的统一化管理。
不同的后台系统采用不同的登录形式、不同的结构框架。没有统一的入口,没有标准的交互规范,操作日志和权限没有统一管理。
造成了交互体验断层,内部使用效率低、管理混乱的局面。
所以,需要进行大后台的整合,以便达到体验、交互、管理上的一致性。
三、大后台整合的目的是什么?
作为产品开发者和运维者,你需要一个统一的大后台,对所有的产品进行权限管理、角色设置和员工管理,并且统一记录所有的操作日志。
- 统一登录态:一键登录,可访问有权限的所有产品和服务,提升访问和操作效率。
- 权限管理:将各个产品的后台纳入到大后台进行统一的管理,指定管理员,并设置该产品的角色,统计角色数量,可进行自定义的设置。
- 角色管理:可灵活地为多个产品配置不同导航和操作权限,一个角色可设置多个员工账号。
- 员工管理:每个员工账号都通过内部通讯工具实名认证登录,归属于某个(或多个)角色,具有操作某个(或多个)产品相关功能模块的权限。某个员工账号允许绑定多个角色。
- 日志管理:统一记录所有产品、所有角色、所有员工的所有关键操作记录。
除此之外,在产品表现层,还可以尝试做到以下两点,来提升整体的产品调性。
1)打造统一的视觉交互UI,强化产品矩阵
- 设计Logo
- 创造Slogan
- 设计“欢迎页”
- 统一页面框架结构
- 统一UI视觉
- 统一交互体验
- 统一操作逻辑
2)传播团队影响力
- 产品介绍展示
- 操作手册下载
- 团队风采展示
- 技术支持通道
- 需求提报通道
- 意见反馈通道
由此将产研团队的服务更好地传递给用户,同时让用户的心声能更好地反馈到产研团队。积极建立和用户的紧密联系,打通产研团队与用户之间的沟通路径。
我想,这大概就是大后台提供的的超预期的用户体验了。
四、何如进行大后台的规划设计?
本文的权限管理模块,采用RBAC权限模型。
RBAC:即基于角色的访问控制(Role-Based Access Control),主要通过角色和权限建立管理,再赋予用户不同的角色,或者角色下添加不同的用户账号,来实现权限控制的目标。
利用该模型来配置权限,直接优点是角色的数量比用户的数量更少,先把权限赋予角色,即可完成权限的分配。再为用户分配相应的角色,即可直接获得角色拥有的权限。
在本文的大后台产品中,权限颗粒度仅限于菜单维度,只需定义有限的角色拥有哪些菜单权限即可。
大后台的产品构架图如下:
角色权限逻辑:
1. 统一登录态
本文的统一登录态是指登录流程前置,在访问产品前进行登录态的判断。登录后,根据角色定位有权限访问的产品,并给出定制化的产品列表。
触发登录的两种行为:
1)主动触发
用户主动点击【登录】按钮,在未设置角色前提下,所有登录大后台的用户均为“游客”角色,仅有查看首页、相关信息页面的权限,不能进入后台产品。
2)被动触发
用户点击产品入口,先判断登录态,未登录的需跳转到登录页面。
2. 权限管理
本文的权限管理,指多个产品是否纳入了权限管理的范畴,并对已有的产品进行管理。被添加的产品或系统,可被划分权限,设置管理员,下设角色和员工账户。
该模块主要的功能点包括:
- 添加系统
- 配置管理员
- 系统名称
- 系统描述
- 启用/停用状态设置
- 二次编辑
在系统管辖权内统计角色的数量,设置启用和停用的状态,因为目前的产品数量有限,暂时不设置翻页组建和删除功能。
3. 角色管理
角色是具有相同权限的账户的集合体。
该模块主要的功能点包括:
- 添加角色
- 添加员工
- 角色名称
- 角色描述
- 启用/停用状态设置
- 二次编辑
4. 员工管理
员工管理指的是登录系统的独立账号,被赋予一个或多个角色,享有一定的权限,可进行相关的操作。
该模块通过内部IM工具登录之后,自动获取其系统账号、员工姓名、工号、注册时间。
初次登录属于“游客”角色,需要管理员或者超级管理员赋予角色才能执行操作。
员工账号正常使用是属于“已启用”的状态,如果员工离职,账号删除、禁用、或者冻结等情况下,账号切换到“已停用”状态。
对于员工账号支持角色的二次编辑,支持各类条件查询等。
5. 日志中心
日志中心是对所有产品敏感性操作的记录,支持汇总查看、按产品查看、按操作员查看、按操作时间查看等模式。
集中的日志管理,有助于系统管理者快速了解各个产品的使用情况,明确操作员的动态。在遇到问题,发生风险的时候,可以回溯日志,定位操作节点,锁定相关人员。
考虑到服务器储存压力的问题,可设置日志最多储存10000条,或者最多储存3个月内的数据。后续每多出一条数据,循环删除最早的一条数据。
如果条件允许,建议保留所有的历史操作日志。
6. 打造统一的视觉交互UI,强化产品矩阵
大后台的整合不仅仅需要体现在流程和功能上,还需要体现在视觉和交互上。所以,作者提出了打造统一的视觉交互UI,强化产品矩阵的设想。并通过需求方案的输出,帮助设想落地实现。
设计Logo:
为每个产品设计一个独特的、贴合产品调性的Logo,同时还要做到所有产品Logo有机整体的融合,视觉统一。
创造Slogan:
为每个产品创造一条简单易记、体现产品属性和价值的Slogan,助力产品传播和推广。
设计“欢迎页”:
为每个产品设计一款欢“迎页面”,通过具有感染力的画面,提升用户体验,传播产品功能价值。
统一产品各级页面呈现的框架结构、UI视觉、交互体验、操作逻辑等。
- 顶部logo+产品名称+slogan+登录/退出入口
- 左侧导航栏
- 右侧大面积操作区域
- 新建按钮在操作区域的左上角
- 查询功能在列表上方
- 列表采用统一的组建
- 翻页组建统一
- 弹窗交互和样式统一
- 删除等操作二次确认
- 统一toast提示样式和消失时间
- 同一类型按钮采用相同的默认色值、交互色值
- 同一类型的文本采用统一的字体/字号/字色
- 导航栏交互统一
- 说明性文案布局一致、采用统一的字体/字号/字色
- 增删改查的操作保持统一的交互体验
局部UI需求表:
7. 传播团队影响力
产品介绍展示:
- 这个模块是关于产品的介绍,图文结合,主要内容包括:产品的性质、产品的功能、产品的合作伙伴、相关负责人、产品的一些关键数据指标等。
- 该模块主要是静态图文的展示,需要设计师出方案稿。
操作手册下载:
- 提供相关产品的操作手册的查看和下载。
- 文档格式建议PDF。
团队风采展示:
图片、文字、视屏等形式展示团队风采,包括:团队成员、岗位介绍、能力展示、团建活动、团队合影等。
技术支持通道:
在使用产品的过程中,如遇到技术问题,请通过【XX】联系我们的开发工程师。
- 开发工程师1:姓名+工号+联系方式
- 开发工程师2:姓名+工号+联系方式
如发现bug,请通过【XX】联系我们的测试工程师。
- 测试工程师1:姓名+工号+联系方式
- 测试工程师2:姓名+工号+联系方式
需求提报通道:
- 填写《需求提报表》,提供表单链接,支持PC和手机端填写,手机端填写支持扫描二维码打开。
- 将需求描述作为邮件内容,发送给 abcdefg(abcdefg@XX.com)并抄送给 hijklmn(hijklmn@XX.com),以及您需要周知的相关业务老师。
意见反馈:
在使用产品的过程中,如有什么好的建议和想法,欢迎反馈给我们,共同交流探讨。
请通过【XX】联系我们的产品经理。
- 产品经理1:姓名+工号+联系方式
- 产品经理2:姓名+工号+联系方式
五、总结
以上内容是作者搭建大后台的初始版本的产品设计方案,主要聚焦在当前产品需要整合的问题,最主要解决的是产品权限管理的问题。
相信,等整个大后台概念落地,产品上线之后,后续的迭代会让产品的体验更加美好、产品层次更加丰富、也会呈现更加多维度的内容。
Echo小姐,公众号:产品经理的逻辑与审美;擅长电商前后台、知识付费、营销平台,懂用户和运营,产品sense良好、有同理心,拥有B端、C端丰富的产品经历,原创有8万字的《一个产品人的逻辑与审美》作品文字图集。
本文由 @Echo小姐的产品论 原创发布于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于CC0协议
Echo小姐,公众号:产品经理的逻辑与审美;擅长电商前后台、知识付费、营销平台,懂用户和运营,拥有B端、C端丰富的产品经历。
本文由 @Echo小姐的产品论 原创发布于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于CC0协议
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。
学习了,感谢~
请教小姐姐,这种单点登录的大后天的数据权限的管理是由权限管理系统统一处理还是放在业务系统里进行单独处理
干货满满,想请问 一个运维管理后台如何把 公司内部人员 和终端用户 融在一个平台里呢?还要满足 终端用户登录运维平台后 还可以管理终端用户的SaaS平台?
这里的添加系统功能,是如何同时做到数据层面的对接呢
前后端约定1个规则就可以。这篇文章像是通过系统名称
想咨询一下,这个大后台的操作日志是记录了其他所有接入大后台的业务系统的日志信息吗
为什么不分开,各自业务记各自呢
日志数据统一进行数据分析,各个业务系统的日志需要按大后台的用户账号ID上报,方便进行登录数据分析;各自业务记各自的,登录数据账号、身份对应,数据是割裂的
1张表, 可以通过左上角的下拉表 选择 各个系统的
点赞收藏加关注
这才是真正实战过产品能写出来的实战篇,赞了
想请问下非标准角色有什么好的授权办法吗,很多运营同学做的事情比较杂,所需权限各不相同,很难通过一个或几个角色把所需权限涵盖住。
曾经做过针对单个用户单独授权的方式,但是回收梳理权限就比较困难。
建议将运营的要做的工作进行分类,整合几个通用的角色,然后进行配置。
我也在做类似的权限系统,目前遇到的问题是,如何判断一个角色可以管理多个系统比较合适,还是把角色归属到系统比较合适?
这个需要看系统之间的业务耦合度,如果很高,那是需要有一种凌驾在系统之上的角色,可以跨系统进行操作,如果耦合度低,那就没有必要。
目前,我们的系统业务都是分开的,所以,角色的设定都是基于系统的。
那为何不急于岗位上下级来规划呢。跨区域,跨公司,跨部门,跨系统。
这样权限只是到菜单栏级,如果想设置功能级权限管理呢?
菜单不等于菜单栏。你做的时候可以颗粒度做到按钮呀,这种框架很灵活,大部分系统都能用
对的,因为我们目前权限比较初级,还不需要颗粒度太小,最主要的后台的整合。可以根据业务需要,做到页面按钮的增删改查,还有数据权限、操作权限、阅读权限等。
这样权限只是到菜单栏级,如果想设置功能级权限管理呢。嘿嘿