關于大后臺的權限管理設計
編輯導語:大后臺是多個產品后臺的域名入口,如今很多產品都采用了這種方式進行管理,可以使產品得到各方面的一致性;大后臺的搭建也可以讓產品得到更好、多層次的體驗;本文作者分享了關于大后臺的權限管理設計,我們一起來了解一下。
一、何為大后臺?
本文講述的大后臺是基于作者的實際工作需要而提出的后臺整合型的概念,是內部多個后臺系統的集合。
具體是指,多個產品后臺通過一個域名入口,接入集團通訊中心,實現統一的登錄和權限管理,采用類似的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張表, 可以通過左上角的下拉表 選擇 各個系統的
點贊收藏加關注
這才是真正實戰過產品能寫出來的實戰篇,贊了
想請問下非標準角色有什么好的授權辦法嗎,很多運營同學做的事情比較雜,所需權限各不相同,很難通過一個或幾個角色把所需權限涵蓋住。
曾經做過針對單個用戶單獨授權的方式,但是回收梳理權限就比較困難。
建議將運營的要做的工作進行分類,整合幾個通用的角色,然后進行配置。
我也在做類似的權限系統,目前遇到的問題是,如何判斷一個角色可以管理多個系統比較合適,還是把角色歸屬到系統比較合適?
這個需要看系統之間的業務耦合度,如果很高,那是需要有一種凌駕在系統之上的角色,可以跨系統進行操作,如果耦合度低,那就沒有必要。
目前,我們的系統業務都是分開的,所以,角色的設定都是基于系統的。
那為何不急于崗位上下級來規劃呢。跨區域,跨公司,跨部門,跨系統。
這樣權限只是到菜單欄級,如果想設置功能級權限管理呢?
菜單不等于菜單欄。你做的時候可以顆粒度做到按鈕呀,這種框架很靈活,大部分系統都能用
對的,因為我們目前權限比較初級,還不需要顆粒度太小,最主要的后臺的整合。可以根據業務需要,做到頁面按鈕的增刪改查,還有數據權限、操作權限、閱讀權限等。
這樣權限只是到菜單欄級,如果想設置功能級權限管理呢。嘿嘿