用戶管理手冊

系統術語

用戶

系統的使用者一般稱爲用戶，用戶登陸後，系統經過各類標識賦予用戶操做和查看權限。數據庫

後臺須要對用戶帳戶、操做權限和數據權限等進行管理。用戶管理貫穿業務各個環節，是支撐業務運營的核心部分。小程序

系統用戶通常分爲內部用戶和外部用戶。這種區分是從平臺運維角度出發，平臺運維公司的員工稱爲內部用戶，其餘用戶稱爲外部用戶。後端

外部用戶

外部用戶隸屬關係比較複雜，有的掛靠在某公司之下，無需註冊，由系統管理員分配帳戶。安全
有的則以獨立個體存在，例如：釘釘，以獨立個體註冊，公司邀請員工，員工贊成後纔有了歸屬。微信
第三種狀況是用戶以獨立個體註冊時選擇所屬公司，這種方式存在兩個問題：網絡

用戶隨意選擇企業，不能保證準確性；架構
是否要在後臺維護企業基礎數據，不維護的話，沒法統一數據源，維護的話，不能覆蓋所有註冊用戶的企業。運維

選擇哪一種方式，須要根據實際業務狀況進行設計。工具

例如

目前平臺的服務對象是門店銷售員，因爲業務衝突，平臺沒法得到企業級的合做，前兩種狀況須要隸屬公司在平臺上進行操做，只能選擇第三種方式，用戶以獨立個體註冊平臺，並填寫所屬企業。學習

爲避免第三種方式存在的問題，作以下處理：

用戶註冊填寫企業，無需選擇基礎數據；
後臺維護企業基礎數據；
用戶審覈時，有平臺客服人員選擇企業基礎數據。

這樣既減小了用戶操做的繁瑣，平臺又能得到精準的數據。

內部用戶

內部用戶也有歸屬，舊有的平臺添加員工時選擇歸屬，在員工管理菜單下展現爲員工列表，這樣作須要提早維護組織機構，頻繁切換菜單。

像釘釘、企業微信等，在維護員工時，按照公司的組織架構進行維護，在同一頁面完成部門和員工的添加，層級關係清晰（見下圖）：

內部用戶通常無需註冊，由系統管理員分配。分配的帳戶能夠是字符串，也能夠是員工的手機號碼。

角色與權限

每一個帳號，都被賦予了特定的角色；而每一個角色的背後，都有其對應的權限信息。

經過RBAC權限管理模型，用戶可按照實際業務的須要分配不一樣的角色和權限，在共享一個軟件平臺的基礎上，實現不一樣用戶的不一樣功能。

權限的賦予分爲自動賦權和手動賦權兩種。

外部用戶的自動賦權通常是帳戶有默認的基礎權限，要想得到更多的權限須要另外開通；內部用戶的自動賦權，通常是把角色與行政關係下的部門創建綁定關係，用戶進入到該部門後，帳戶自動被加入到對應的角色中，而且擁有該角色全部的權限。

手動賦權沒法經過用戶行政關係自動綁定來實現，須要手動創建角色賦予給帳戶。

例如：要求客服專員只能看分到本身名下的客戶，上級領導看所有下級的客戶，經過兩種方式實現：

一是經過組織機構的上下級歸屬自動賦予數據權限；
另一種用數據角色，實現跨部門查看數據。

另外，角色能夠繼承，子帳戶繼承父系角色的權限。例如：賦予某企業級外部用戶admin某些權限，該企業下的其餘子帳戶只能從admin權限中選擇可用權限。

權限依據屬性可分爲操做權限和數據權限。

操做權限會從功能菜單、功能操做兩方面考慮，角色勾選上菜單和功能，擁有該角色的帳戶便可操做相應的菜單和菜單下的操做（例如新、增、改、查），分配操做權限頁面見下圖：

數據權限會從菜單、列表及數據字段三個顆粒度考慮：

菜單是最粗顆粒度的數據權限，得到受權便可查看該菜單下的所有數據；
列表是較細顆粒度的權限，不一樣角色的用戶進入同一菜單頁後，查看的列表字段相同，但量級不一樣，例如上面描述的員工看本身的數據，領導看所有員工數據；
數據字段是最細顆粒度的權限，不一樣角色的用戶進入同一菜單頁後，可見的數據字段有差別，這些字段共存在一個菜單頁中，只是受限於不一樣的角色權限。

單點登陸

平臺會涉及多個應用系統，例如：合同管理、資金管理、小程序管理、兌換商城等，可經過單點登陸（SSO）。

在多個應用系統中，實現登陸一次就能夠訪問全部相互信任的應用系統。

應用系統加入了單點登陸協議，管理用戶賬號的負擔就會減輕，實現應用系統的用戶、角色和組織機構統一化管理。

要實現SSO，須要：

統一集中的用戶身份管理系統。全部應用系統共享一個身份認證系統，用戶登陸時，信息和用戶信息庫相比較，對用戶進行登陸認證；認證成功後，認證系統生成統一的認證標誌（ticket），返還給用戶。另外，認證系統還應該對ticket進行效驗，判斷其有效性。
全部應用系統可以識別和提取ticket信息。應用系統對ticket進行識別和提取，經過與認證系統的通信，自動判斷當前用戶是否登陸過，從而完成單點登陸功能。經過基於互聯網協議的單點登陸、登出體系實現用戶不一樣應用系統間身份一致性，實現信息空間身份一致性。

不管是外部用戶，仍是內部用戶管理，都涉及到帳戶、角色和權限的管理。

本文從自身經驗出發，總結了各個環節須要注意的地方，另外單點登陸涉及到用戶管理，貫穿整個平臺，此部分技術人員參與的比較多，本文只作了簡要的總結。

用戶管理系統最難的是後續的維護，系統中每每會出現不少冗餘的角色，這都須要慎重思考，和業務溝通清楚後再作調整。

用戶系統模塊架構

用戶管理模塊架構以下：

整個模塊爲用戶管理，下分三塊分別是：

部門組織架構：

全部部門人員信息的在線展現以及對應的人員列表，此處同步公司域庫數據，附加了當前在線狀態的顯示；
角色權限管理：

此處分爲角色組的創建以及對應權限的把控，角色組以及所屬成員按需建立和添加，建完以後對應作權限的控制，包含功能權限、資源權限、數據權限、集成系統的訪問權限；
權限申請管理：

此處是針對權限管控後，用戶對無權限資源進行的權限申請處理以及對應的權限賦予操做（權限批覆結果會自動生成消息通知，與公告消息相通）。

用戶管理

帳號管理，是管理員最經常使用到的功能。這一模塊，須要設置相應字段，對內部人員的信息進行管理，首先應該具有「新增」、「刪除」、「編輯」這三項基礎的操做功能。另外一方面，考慮到部分企業存在內部獎懲機制，對某項指標不合格或者行爲違規的員工，作出暫停使用帳號的處理結果，所以，在上述三項基礎操做功能以外，能夠再增長「禁用」和「啓用」的功能。

帳號列表

帳號列表應該優先顯示重要的字段，好比ID、用戶名、真實姓名、部門、角色、帳號狀態、註冊時間等。固然，除了這些，後端還須要記錄下用戶的其餘字段，好比最近登陸時間、登陸次數等等操做記錄。以下圖：

添加帳號

當管理員點擊「新增」按鈕時，當前頁面能夠跳轉到填寫帳號信息的頁面，也能夠經過彈窗的方式出現。新增帳號的字段應當儘可能詳細，以便未來對用戶行爲作統計分析。同時在這個階段，咱們能夠經過判斷用戶的身份，來給他賦予相應的角色。在這一步，不須要配置權限，由於角色自己就是帶有權限的。以下圖：

角色管理

角色管理部分，是用來管理內部用戶的角色信息。角色，是對具備共同特徵的某一類人羣的身份概括，在這個模塊裏，咱們須要設置一些字段來描述角色信息，下降學習成本，讓管理員可以輕鬆識別角色的特質，從而爲不一樣的用戶賦予對應的角色身份。

角色列表

角色列表相似帳號列表，也是將一些重要字段展現出來，讓管理員可以很快的瞭解角色的相應信息，好比角色ID、角色名稱、基本權限、操做權限等。當基本權限和操做權限很是繁雜的時候，能夠只顯示重要的幾類，其餘的詳情，能夠點擊查看。

在角色列表，只需保留「新增」和「刪除」功能，「搜索」功能也能夠不須要，由於角色的種類一般比較少，不然會給管理員增長負擔。以下圖：

新增角色

「新增角色」和「編輯角色」，都是給角色賦予相應的權限。過去我在給角色配置權限的時候，使用過下拉菜單的方式來選擇。但若是碰到權限很是繁雜的狀況，下拉菜單就不太適用了。這個時候，能夠將權限都羅列出來，能夠分組排序，也能夠默認所有選中，而後讓用戶根據需求去勾選掉不須要的權限。以下圖：

權限管理

權限管理這部分，是邏輯性最強的一塊，須要提早準備好一份權限清單，將權限的名稱、描述、性質（基本/操做）等信息梳理清楚。

權限列表

在作權限梳理以前，必定要與開發人員溝通好，肯定哪些權限是同類型的，能夠歸爲一組，而哪些功能又必須是分開設置的。拿我以前作的這個項目爲例，這個產品沒有涉及工做流環節，但Boss想讓不一樣角色的用戶，看到不同的界面，因此除了一般的操做權限劃定以外，還有一些基礎的菜單查看權限，也要細分。固然了，由於權限細分起來很是繁雜，因此權限列表還須要有分頁的功能，也能夠加上搜索功能。以下圖：

新增權限

「新增權限」頁面，是爲開發人員設置的，開發人員能夠在這裏將代碼內容錄入。具體以下圖：

以上介紹的用戶管理三大模塊，是專門針對後臺系統設計的，面向的用戶也是企業內部人員，從產品需求上來講，追求的是規範、標準和流程化。

如何作好角色賦權

自動賦權：用戶自動進入角色

若是角色與行政關係下的組織部門存在綁定關係，那麼若是一個用戶進入到該組織部門後，該用戶會自動被加入到對應的角色中，而且擁有該角色全部的系統權限。如一個財務人員【小張】入職財務部後，那麼該用戶無需進行額外的受權便可在對應財務報表系統查看該部門員工可查看的財務數據報表和對應的操做權限（好比操做財務審批等）；

角色賦權：用戶被添加進角色

業務是不斷創新和發展的，隨着業務的發展，會有愈來愈多的新的角色被設置和建立，好比公司新啓動了一個企業團餐項目，項目部橫向的從各個部門找了多個員工組建項目團隊，而且該項目的業務權限也只是受權給這批員工可查看和操做，那麼，在此項目中，會產生一個新的角色「財務1 」，系統高級管理員會把從財務部門選中的財務【小張】添加到「財務1 」這個角色中，那麼【小張】便可得到查看企業團餐項目業務數據報表和操做的權限。這種權限的授予沒法經過用戶行政關係的自動綁定來實現；

角色繼承：角色權限的繼承

權限能夠是獨有的，也能夠是繼承的。每一個角色都有本身的權限集，角色繼承其實也就是繼承父系角色的權限，通常角色在繼承其父系角色的所有權限的基礎上增長擁有一些本身的權限。而系統角色繼承每每存在於用戶分級管理比較明確的團隊或者公司；

角色互斥：角色包含的權限互斥

角色互斥的業務背景：當一個業務流程因爲風控的緣由，須要將其操做給劃分紅分開的幾個步驟時，須要給這幾個不一樣的步驟受權不一樣的角色，而且這些角色之間須要進行互斥。好比大額財務報銷審批流程，財務人員【小張】擁有了審批人權限後，就沒法將審覈確認的權限再授予小張，以此來規避一我的完成大額報銷而帶來的財務風險；

臨時角色：給特殊客戶臨時身份

臨時角色每每是針對特殊羣體設置的，好比公司有特殊訪問團隊蒞臨，須要給這些特殊的客戶一些臨時身份來體驗某些功能操做。那麼把這些人添加到部門的組織架構中顯然是不合適的，由於這些人只是臨時的擺放者，不是企業員工；其次，這些客戶須要體驗的功能操做每每是橫跨多個業務模塊和產品線的（比較繁雜），通常公司並無現成的固定角色符合擁有客戶所需的所有操做權限，所以須要給這些客戶開設臨時角色，而且支持給臨時角色最大的權限選擇空間；

黑白名單：

如何作好權限系統

上述組織架構和權限申請部分基本很容易理解，邏輯相對複雜一些的當屬角色權限管理這部分，先看一張關係圖：

作好權限管理有如下幾個重點：

1. 人員組成要靈活

這部分的人員組成不必定是按照崗位角色來的，有多是跨部門跨崗位造成的自定義角色組，所以不能直接套用以前的崗位角色，須要能夠建立新的角色組，固然角色組多了還能夠給角色組分大類，以便更清晰一些。

2. 權限覆蓋要全面

權限常規來講能夠分爲功能權限、數據權限、資源權限，固然根據產品不一樣也可能有更多的權限分類。大到每一個頂部導航模塊，小到頁面上每一個功能按鈕，都屬於權限的範圍。與此同時資源內容的全量呈現仍是部分呈現就涉及到資源權限的管控；有的數據我能訪問，你不能訪問，這種權限的區分把控在於數據權限的設置。

在上述案例中，咱們的數據權限採起的是黑名單制，顧名思義就是我選擇誰不能看到哪些數據，默認狀況下是全部人能夠看到全部數據，這個能夠根據具體狀況進行正反向設計。

好比大部分都是可看的，不可看的是少數，那麼就用黑名單方便一些；若是大部分都是不公開的，只有少數是公開的，那麼白名單會更方便一些，因狀況而異。

3. 權限把控要靈活

正常來講角色權限管理對於一個須要此方面把控的產品來講就像空氣同樣不可或缺，雖然咱們不常注意它的存在，可是用的時候必定要確保其規範、安全、可靠。

以前咱們在作的過程當中有過這樣的一次經歷，通常被賦予了某個角色的人員具備把私有錶轉爲公共可見表的權限，而對應的刪除操做，當時開發則作成了誰建的表誰刪除，其他人即便有一樣權限也不能進行刪除這樣的模式。

在一次不經意操做中咱們發現共同擁有這個權限的人刪除不了別人建的公共表，我跑去告訴同事說這張表是他建的，須要他刪除，而後我就去了洗手間，但頓時感受這樣的邏輯存在問題，假使十我的建了十張表而後都轉爲公共表了，那麼若是這十我的離職了，這些表還非這些帳號不能進行刪除操做了嗎？（不包含開發同事從數據庫刪除的狀況，由於咱們設計產品的最終目的就是減小進行數據庫的操做，最大化方便使用而且邏輯合理）

所以意識到這一問題後，咱們小組當即進行了討論而且及時作了更新。雖然這樣也存在不是表的主人刪除他人表的可能性，但一般來講：

第一，這樣的狀況相對較少；第二，對應的解決方案是能夠經過把刪除表的功能只賦予一個最高管理員，其他角色不能隨意操做，這樣來管控。總之要保證權限把控的靈活性，這是第一原則。

實際狀況其實更復雜一點，由於咱們還涉及私有表可刪除（全部人都有的功能）、可移動到公共表（部分被賦予權限的人員具備的功能，無權限人員不顯示此操做按鈕）；公有表的查看（全部人都具備的功能）、公有表的刪除（部分被賦予權限的人員具備的功能，無權限人員不顯示此操做按鈕）等，那天原本約了人，但爲了調這個並和開發講清楚，赴約都臨時取消了（捂臉）。

4. 權限申請要智能

權限申請其實和以前的權限把控是對應的，有的權限是把控以後，相應用戶看不見被屏蔽的痕跡，也沒有申請入口，而有的能夠作成暫無權限的提示，同時提供申請入口。

在上述案例中，咱們在部分屏蔽場景中提供了權限申請的入口，當用戶點擊申請後，會自動在後臺接收一條權限申請的消息，上面顯示申請人基本信息、申請源、申請時間以及批覆操做（經過/拒絕），具體的申請處理流程以下圖：

在這塊令我比較欣慰的一點是咱們的技術同事把權限開通作的相對智能化了一些，即在經過權限申請的時候，相繼會產生2條動做：

一個是在上述的角色權限模塊自動開申請用戶開通相應權限（包含功能權限、數據權限和資源權限）；
另外一個則是在開通流程走完以後把申請反饋通知發送到該用戶的消息帳戶，這兩個任務完成後，即權限申請「經過」，整個流程基本在1秒內完成。固然即便開放後的權限將來也有可能被收回，因此這塊的靈活性是毋庸置疑的。

外部用戶管理

用戶信息管理是客戶關係管理的底層基礎。

用戶接觸一款新產品，從開始瞭解，深度使用，最後到流失，整個過程會產生大量的數據信息流動，經過對這些用戶信息的高效管理，能夠指導用戶分羣、個性化消息推送、生命週期管理和關聯推薦等一系列運營策略。用戶信息的最大化的合理利用，可以更精細爲用戶提供服務，有效的達成業務目標。

在用戶信息中包含了用戶從註冊到註銷在平臺產生的數據，包含用戶的基本信息，帳號信息，訂單信息，統計信息，收貨地址信息，等其餘信息。

基本信息：包含用戶的帳號ID，註冊來源，手機號碼，性別，會員級別，城市地區，頭像，暱稱等

基礎信息是描述客戶基本屬性的靜態數據，主要來源於用戶註冊和使用時錄入的信息。用戶基礎信息通常經過電商CRM系統的會員信息庫進行存儲和管理，會員信息庫就比如存放着平臺每一位用戶的名片夾。

用戶的基礎信息字段繁多，大體能夠歸爲六大類：

人口屬性信息：用戶的姓名、性別、年齡、生日、所在省市區街道、婚姻狀況；
平臺屬性信息：暱稱、註冊時間、會員類型、會員等級；
聯繫信息：手機號、郵箱、QQ、微信、微博、其餘第三方關聯帳號；
收貨信息：默認與非默認收貨姓名、收貨地址、收貨電話；
卡與支付信息：會員卡信息、銀行卡信息；
認證信息：在校認證信息、營業執照認證信息、消費貸認證信息等。

帳號信息：帳號信息包含用戶的支付帳號信息若平臺自有支付系統，則能夠展現用戶綁定的銀行卡信息（隱藏部分）

訂單信息：訂單信息包含用戶全部的訂單，好比用戶歷史訂單，待支付訂單等等，在訂單列表中須要將該用戶下的全部拉取出來。

收貨地址信息：收貨地址信息則顯示用戶的收貨地址，收貨人，聯繫方式等。

行爲信息是用戶使用產品時產生的動態數據，主要來源於系統的事件埋點與後臺日誌：

· 事件埋點對用戶的行爲事件進行了全流程的記錄，再經過各類頁面來源（source）進行相互關聯，能夠詳細記錄用戶的行爲路徑。

· 後臺日誌記錄了交易信息，包括訂單id、商品id、貨號、單價、顏色、尺碼等記錄、經過「時間戳」來證實發生時間。

經過用戶完整的行爲信息，咱們能夠還原最完整、真實的交易場景：

· 用戶是誰：目標用戶、用戶畫像、是否源於其餘用戶分享；

· 買了什麼：商品品類、風格、件數、顏色、尺碼、價格、上市時段；

在哪發生：線上的模塊、頁面、路徑；線下的城市、商圈、地址、店名。

行爲信息能夠間接反映用戶的行爲偏好和決策路徑，經過自建數據分析平臺或第三方分析工具進行系統化的管理，能夠爲具體業務方案提供可靠的數據依據，帶來可量化的指導。

基於行爲信息的生命週期管理

基於用戶在平臺的消費記錄，能夠按照用戶是否使用過產品來劃分爲新用戶與老用戶；老用戶還能夠根據用戶使用產品的狀況，按生命週期劃分爲留存用戶、沉默用戶和流失用戶，舉一個簡單劃分方式：

· 未激活新客：註冊了產品以後，尚未正式使用（如電商的首次下單）的用戶；

· 留存用戶：在指定一段時間週期（如30天）內有使用過產品的用戶；

· 沉默用戶：對使用產品的積極性降低，連續一段時間週期（如30~60天）未使用產品的用戶；

· 流失用戶：曾經使用過產品，如今已經連續很長一段時間（如61天以上）沒有再使用過產品的用戶。

會員權益模塊

在會員權益模塊展現了會員權益的獲取與註銷的規則及會員權益規則的修改與新增。由於不一樣業務形態不一樣用戶層因此會員模塊的設計具備較高的靈活性，本文不作展開。

會員權益設置：包含會員級別設置，升級設置，降級設置等等。

會員權益展現：這裏則是設置好的會員權益展現。好比會員升級條件等等。

RBAC權限設計模型

（Role-Based Access Control，基於角色的訪問控制），就是用戶經過角色與權限進行關聯，從而得到某些功能的使用權限。權限被賦予給角色，而不是用戶，可是一個用戶能夠擁有若干個角色，當一個角色被賦予給某一個用戶時，此用戶就擁有了該角色所包含的功能權限。簡單地說，一個用戶擁有若干角色，每個角色擁有若干功能權限。這樣，就構形成「用戶-角色-權限」的受權模型。在這種模型中，用戶與角色之間，角色與權限之間，通常者是多對多的關係。以下圖：

· 用戶：成功認證並登陸系統的操做員（主體：who）

· 權限：訪問資源的許可（how）

· 角色：權限的集合體

· 資源：引入這第四個概念，包括系統菜單、頁面、按鈕等（what）

4A模型

是指：認證Authentication、帳號Account、受權Authorization、審計Audit，中文名稱爲統一安全管理平臺解決方案。即將身份認證、受權、審計和帳號（即不能否認性及數據完整性）定義爲網絡安全的四大組成部分，從而確立了身份認證在整個網絡安全系統中的地位與做用。

附錄

1. 一個用戶擁有多個角色，多角色之間若是存在互斥關係如何處理？

若是一個用戶已經被添加到某一角色範圍下，那麼，當給該用戶添加一個與當前角色存在權限互斥關係的角色時，系統會進行互斥性判斷，後面的角色就沒法給該用戶添加成功；

2. 業務發展過程當中，如何保證不一樣角色之間權限拆分清晰？

隨着業務的快速發展，必定會不斷新增不一樣的角色和更多的功能模塊，並且這些角色和功能權限之間的關係也會日益混亂，這個時候須要產品經理和業務方一塊兒，及時的面對業務的發展變化，及時、快速的梳理業務調整範圍，做出對應的改變；

3. 用戶權限管理系統核心難點是前期的產品設計嗎？

用戶權限管理系統核最難的不是前期的產品設計，而是後續的運營維護，由於權限系統的結構每每不會隨意變動，可是隨着業務發展快速出現的角色和功能模塊，爲了防止角色和功能權限之間的關係變得混亂，在創建新的角色和分配權限的時候須要思路清晰且慎重調整。