5 篇博文 含有标签「文件管理」

随着悦库向大客户服务发展，在多年技术积累和产品良好口碑基础上，我们陆续为多家大客户实现了组织内的文件管理解决方案，这些大客户包括国家电网、军方、省级电信、文物保护机构等。

通过对比大客户和中小客户的需求差异，我们发现大客户会首先关注悦库企业网盘的海量存储、数据安全、高并发、高负载等系统能力，而中小客户更关注悦库能满足自身需求的具体业务功能。

国家电网​

在国家电网客户应用场景中，现场工作人员用无人机对电网设施进行运维巡检，拍摄大量高清照片，上传到悦库网盘中存储和管理：

在今年早些时候，国家电网将自己的原有的OA系统和悦库进行对接共享文件数据，实现了更高效便捷的的文件访问能力：

在这个案例中，国家电网更侧重文件数据的海量存储，目前数据容量已经超过200TB，图片文件数量接近1000万个，我们的研发工程师为其做了大量技术支持和性能优化工作。

军方组织​

目前悦库已经为多个军方客户提供文件管理能力，由于军方拥有严格的保密制度，我们无法了解客户的具体应用场景。最近其中一个大型军方客户将悦库企业网盘迁移到国产Linux系统平台中，该系统硬件强大，拥有128核ARM CPU+128GB内存。

成功迁移后，上千人同时使用，并发量很大，遇到连接卡顿问题，由于我们无法直接查看军方服务器，只能与技术接口人沟通问题现象，经过一周多时间断断续续的艰难排查，终于确认是Apache服务在Linux下的高并发问题。

在这个军方用户案例中，我们花费了大量精力用脚本模拟和重现了高并发场景中的问题，并在自己内部I5-9600K CPU +16G内存， Linux系统环境中，实现了1200个并发访问的测试验证。最终我们成功为客户解决问题。

一些总结​

在大客户组织中，对系统主要需求特点是：访问人数多、存储数据量大。

访问人数多，则要求系统拥有高并发、高负载、高可用能力，支撑业务正常运行。

数据量大，则数据整体损失成本非常高，因此很看重数据安全性，对数据安全方案很重视。

悦库企业网盘提供了大量特性来支持这些场景：

大型组织机构通常由多个相对独立的下属组织单位组成，每个下属单位都有自己的职责和目标，本文探讨如何实现对大型组织机构的文件管理。

1. 组织​

组织由总部、单位、部门、人员四个组织层级组成：

总部是一个组织的最顶级单位，例如集团名称、大学名称等，系统中有且只有一个总部。总部下包含多个层级的单位，而单位中也包含多个部门，形成一个树形组织结构。总部本身也是一个特殊的单位，遵守单位相关规则。

单位，是一种隶属于总部的组织逻辑类型，通常用于建立一个相对独立的人员管理逻辑范围，具有独立的组织结构和文件访问安全边界。例如集团子公司、大学学院、集团医院分院等。单位中可以包含多个子单位或部门，可以在总部或其他单位之下，但不能在部门下。

部门 是一个独立组织下的分支机构。可以直接隶属于总部，或某一个单位，可以在总部、单位、其他部门之下。

人员是隶属于组织中的个人，人员可以直接隶属于总部，也可以同时隶属于多个部门或单位中。

简化的树形组织结构示例：

1.1 组织关系​

总部关系

1. 总部下可以有0或多个单位，单位有且只有1个总部。
2. 总部下可以有0或多个部门，部门有且只有1个总部。
3. 总部下可以有0或多个人员，人员必须隶属于1个总部。

单位关系

1. 单位可以有0或多个子单位，子单位有且只有1个上级单位。
2. 单位可以有0或多个部门，部门有且只有1个上级单位。
3. 单位可以有0或多个人员，人员可以隶属于0个或多个上级单位。

部门关系

1. 部门可以有0或多个子部门，子部门有且只有1个上级部门。
2. 部门可以有0或多个人员，人员可以隶属于0个或多个上级部门。

人员关系

1. 人员可以直接隶属于总部/单位/部门之下。
2. 人员必须隶属于1个总部，但可以同时隶属于多个单位或部门之下。

1.2 组织隔离​

单位 是一个相对独立的组织，拥有单位范围的安全边界。各单位之间在组织访问、文件访问、角色设置等操作中相互隔离，默认不能互通。

例如在集团医院中，如果将市北分院和崂山分院定义为单位，则默认市北分院的人员无法访问崂山分院的文件，同时也看不到崂山分院的组织结构。市北分院中创建和设置的自定义角色在崂山分院中不可见。

1.3 组织协作​

在相互隔离的单位之间建立协作关系，是企业中常见的应用场景。

单个人员可以通过设置和授权方式实现对其他单位的组织或文件的访问。

例如：

1. 通过将市北分院的用户小明，设置可见西海岸分院，小明就可以访问西海岸分院的组织结构。
2. 通过将市北分院的用户小明，设置可下载西海岸分院的 技术资料空间，小明就可以访问西海岸分院的文件。

作为一个独立单位或部门，也可以设置可见组织，实现两个单位或部门之间的组织互通。组织互通后，就可以根据授权访问对方单位的文件。

2. 角色​

在企业中访问控制的范围取决于员工所扮演的角色，角色中包含已确认的访问权限和职责，悦库系统中的角色包括文件管理员、人事管理员等，每一种角色根据其包含的职责有不同的访问权限。

例如单位人事主管角色用于管理单位内部的人员，拥有对人员/部门的创建、编辑和删除等人事相关操作权限。

在组织中只有人员可以拥有角色，一个人员可以同时拥有多个角色：

2.1 角色级别​

角色按权力级别分为：管理员角色、主管角色、普通角色。管理人员不能创建高于自身角色级别的新角色，当为其他人指派角色时，被指派角色行为集必须是当前管理者自身角色的行为集的子集，这样可以防止角色恶意提权问题。

由系统创建的默认角色，其中1、2级为管理角色，3级为普通角色：

1级管理员角色

1级管理员角色只能隶属于总部之下，按职责分为文件/人事管理员，管理员角色可以查看整个组织。

文件管理员，可以管理系统中的所有文件，可以查看系统中的所有单位、部门和人员。

人事管理员，可以管理系统中所有下属单位以及下属单位中的部门和人员、管理本单位角色和公共角色，拥有人事管理最高权利，但只拥有人事权利，无管理文件权利。

2级主管角色

2级主管角色，管理的具体组织范围，根据指派角色时为其绑定的单位/部门而定。

文件主管，可以管理单位/部门中的所有文件，可以查看当前单位中的所有部门和人员。

人事主管，可以管理单位/部门中的所有部门和人员、管理角色，无管理文件权限。

运维主管，对系统进行运行管理维护，无其他管理权限。

3级普通角色

普通员工，可以在授权范围内对文件进行操作，默认仅可以访问本单位内组织，经过授权可以访问其它单位组织。

2.2 职责分离​

职责分离是确保单个人员不具备完成恶意行为的所有必要权限的一种策略。

最常见的⽰例是：财务工作中的发起⽀付和授权⽀付操作，任何⼀个⼈员都不应该能够同时拥有这两种权限。

在文件管理领域中以FTP服务器为例：运维人员的职责是系统运行维护，却可以超出自身职责，直接查看FTP服务器上的所有企业文件(本应属于文件管理职责)，运维人员的职责不明确，将为企业文件增加泄露风险。

管理角色按职责分为职能管理和文件(业务)管理。人事管理和运维管理属于职能管理，人事管理角色只负责管理组织和人员，运维管理角色则只负责管理系统运维相关工作，职能管理角色不参与对文件访问权限的管理。文件管理角色专门负责组织内的文件(业务)管理，不参与组织的职能管理。

3. 资源​

3.1 概念​

资源主要是指空间、文件夹、文件。

空间是指文件的逻辑存储容器，类似于硬盘的分区，用于对文件进行逻辑分隔管理。考虑到组织安全访问的必要性，组织结构在此场景中也被定义为一种资源，例如用于限制人员查看其他子组织，实现组织隔离。

具有层级关系的资源称为结构化资源，空间、文件夹、组织结构都是结构化资源。

4. 访问安全​

4.1 策略​

策略(policy)是鉴权机制用于验证人员对资源操作行为合法性的基本依据，由主体、资源、行为三个要素组成，主体是：单位/部门/人员，资源是：空间/文件夹/文件，访问行为是：查看/下载/上传/删除等。

主体路径是指从组织根节点到当前主体的组织父节点所经过的所有节点的组合。资源路径是指从资源根节点到当前资源父节点所经过的所有节点的组合。

策略按行为类型分为：允许策略和拒绝策略。允许策略用于表达允许谁对哪个资源拥有什么操作行为，拒绝策略用于表达拒绝谁对哪个资源拥有什么操作行为。拒绝策略优先级大于允许策略，即当设置主体对同一资源同时拥有允许和拒绝策略时，鉴权结果为以拒绝策略为准。

以主体的视角来看，策略是主体的访问权限，以资源视角来看策略是资源的访问规则。例如一条策略允许小明对test.txt拥有下载行为，以主体视角是表达小明拥有对test.txt下载的访问权限，是一条允许访问权限，以资源视角是表达test.txt拥有小明对其下载的访问规则，是一条允许访问规则。

4.2 访问权限​

访问权限是指以主体为视角的策略，表达其对资源可执行的行为，可以在主体上进行查看和编辑。

访问权限由私有权限和继承权限组成，私有权限是直接作用于主体的策略，继承权限是根据继承路径逐层递推累加节点权限后得出所有策略，私有权限优先级大于继承权限。

继承​

继承权限可以使主体获取其路径中的所有访问权限，而不需要重复添加，且主体自身可以追加新的私有权限。主体不继承特性则可以使主体屏蔽从路径中继承权限，然后自行定义访问权限，拥有更好的灵活度。

1. 研发一部 的所有访问权限，递推计算过程为：

   • 研发部权限 = 公司(所有权限) + 研发部(私有权限)
   • 研发一部权限 = 研发部(所有权限) + 研发一部(私有权限)

2. 小明 的所有访问权限，递推计算过程为：
   • 研发部权限 = 公司(所有权限) + 研发部(私有权限)
   • 研发一部权限 = 研发部(所有权限) + 研发一部(私有权限)
   • 小明权限 = 研发一部(所有权限) + 小明(私有权限)

在一些特殊场景下，可能不希望继承父组织的访问权限，由子组织自行添加，可以实现更自主可控的访问控制。

小明 是研发部的试用期员工，按公司规定不能访问研发部中的共享资料，需单独为其添加工作范围内的访问权限。

鉴权​

鉴权是通过计算主体和其组织路径对目标资源和其资源路径的访问权限，得出主体对资源的最终访问权限的计算过程。该过程需要考虑主体的角色、继承权限、私有权限、允许/拒绝权限的优先级，目标资源的路径层级等因素。

举个例子，需要对小明下载文件word.zip的操作进行鉴权，过程是：

查看小明及其主体路径节点对word.zip及其资源路径的任意节点层级是否有下载权限。例如研发部对word.zip有下载权限，则小明也就拥有了对word.zip的下载权限，或者小明对应用软件有下载权限，则同时也就拥有了对word.zip的下载权限，计算过程是：

1. 获取公司对word.zip及其资源路径节点的私有权限。
2. 获取研发部对word.zip及其资源路径节点的私有权限，并累计公司的继承权限。
3. 获取研发一部对word.zip及其资源路径节点的私有权限，并累计研发部的继承权限。
4. 获取小明对word.zip及其资源路径节点的私有权限，并累计研发一部的继承权限，得出小明最终对word.zip的访问权限。

权限组​

由用户自定义的一组拥有特定作用的一条或多条访问权限，可用于对单个主体批量添加访问权限。

例如：公司规定试用期员工不能访问本部门所有文件，但可以访问部分和试用期工作相关的文件，以下：

按照常规的赋权步骤，我们需要为试用期员工分别指定每条资源的访问权限，当试用期员工和访问资源都比较多时，显然这种方法费时费力，也很容易出错。

为了提高工作效率，我可以创建一个包含多条访问权限的试用期员工的权限组。当为试用期员工指定访问权限时，先将该员工设置不继承部门权限，然后直接为其添加'试用期员工的权限组，以此简化赋权操作。

4.3 访问规则​

访问规则是指以资源为视角的策略，表达资源可以被主体执行的访问行为，可以在资源上进行查看和编辑。 访问规则和访问权限仅是主语视角不同，访问权限的主语是主体，而访问规则的主语是资源，但产生的作用是一致的，在系统内部实际都会被转换为以主体为主语的策略。

例如，管理员指定资源word.zip的访问规则是：word.zip 可以被小明执行下载行为，则在系统内部转换后对应的策略是：允许小明对word.zip 执行下载行为，这时的主语为小明，鉴权机制以主体作为主语计算最终权限。

规则组​

由用户自定义的一组拥有特定作用的一条或多条访问规则，可用于对单个资源批量添加访问规则。

例如：一些分散的技术机密资源(在不同文件夹下)可以被小明、小刚等6人编辑，而小王、小高等10人仅可查看。

按照常规的操作步骤，我们需要为资源分别指定每个人员的访问规则，当资源比较多时，显然这种重复操作费时费力，也很容易出错。

于是作为一名研发部文件主管，我可以创建一个包含多条访问规则的技术机密资源的规则组。当为技术机密资源指定访问规则时，直接为其添加'技术机密资源的规则组，以此简化操作步骤。

附录​

用户故事​

组织​

1. 小明在A单位中，小刚在B单位中，他们相互之间不能看到对方的组织结构，且只能看到自己所在单位的组织结构。

2. 设置A单位的小明可以查看B单位的组织结构。

3. 设置A单位的所有人可以查看B单位的组织结构。

4. 设置A单位拥有B单位指定空间的文件夹的下载权限。

5. 设置A单位的研发部对B单位的测试部下所有文件有下载权限。

6. 小明属于A单位的研发部，同时也属于B单位的测试部，设置小明在A单位中担任研发部文件管理员，在B单位为普通员工。

7. 小明属于A单位的研发部，设置小明不继承上级部门权限。

8. 设置A单位的财务部门的直属员工对市场部"销售数据空间"的"每月报表文件夹"有下载权限。设置A单位的财务部门的所有员工对市场部"销售数据空间"的"每月报表文件夹1"有下载权限。？

9. 设置A单位的所有人可以查看B单位的组织结构，但试用期员工除外。

10. 设置A单位的所有人可以查看B单位的组织结构，但研发部除外。

11. 设置A单位的所有人可以查看B单位的组织结构，有效期1个月。

角色​

1. 小明作为一名单位文件主管，希望将其单位下的研发部中的小刚指派为部门文件主管。
2. 小明作为一名单位文件主管，希望查看其单位中各个部门的文件。
3. 小明作为一名单位文件主管，希望自定义一个部门文件主管角色。
4. 小明作为一名单位文件主管，希望删除过去创建的自定义角色。

资源​

1. 我作为一名单位文件主管，在高级财务和普通财务人员都有对"财务资料/年度报表"文件夹有访问权限的前提下，希望将 "财务资料/年度报表/董事会财报" 文件夹单独设置高级财务人员有访问权限，单位下普通财务人员不可见。

访问安全​

1. 设置小明对”技术资料“空间下的”python“文件夹有下载权限，且只能下载该文件夹的直接子文件(资源不递归)。？
2. 设置小刚对”技术资料“空间下的”python“文件夹有下载权限(资源递归)。？
3. 设置研发部所有人员(主体递归)对”技术资料“空间下的”python“文件夹有下载权限。
4. 设置测试部直接人员(主体不递归)对”技术资料“空间下的”python“文件夹有下载权限。
5. 使用权限组方式设置多名试用期员工不能访问本部门所有文件，仅可下载分散的(不在同一文件夹)试用期员工培训资料。
6. 使用规则组方式设置一些分散的技术机密资源(在不同文件夹下)可以被小明、小刚等6人编辑，而小王、小高等10人仅可查看。

常见的大型组织形式​

大学​

集团公司​

集团医院​

大型组织机构(1000人以上)中，通常由多个相对独立的下属组织单位组成，每个下属单位都有自己的职责和目标，本文探讨如何实现对大型组织机构的文件管理。

1. 组织​

1.1 组织定义​

大型组织由总部、下属单位、部门、人员四个组织层级组成：

总部是一个大型组织的最顶级单位，例如集团名称、大学名称等，悦库系统中有且只有一个总部。总部下包含多个层级的下属单位，而下属单位中也包含多个部门，形成一个树形组织结构。总部本身也是一个特殊的下属单位，遵守下属单位相关规则。

下属单位是一种组织的逻辑类型，通常用于建立一个相对独立的人员管理逻辑范围，具有独立的组织结构和文件访问安全边界。例如集团子公司、大学学院、集团医院分院等。下属单位中可以包含多个子单位或部门，可以在总部或其他下属单位之下，但不能在部门下。

部门 是一个独立组织下的分支机构。可以直接隶属于总部，或某一个下属单位，可以在总部、下属单位、其他部门之下。

人员是隶属于组织中的个人，人员可以直接隶属于总部，也可以同时隶属于多个部门或单位中。

简化的树形组织结构示例：

1.2 组织关系​

总部关系

1. 总部下可以有0或多个下属单位，下属单位有且只有1个总部。
2. 总部下可以有0或多个部门，部门有且只有1个总部。
3. 总部下可以有0或多个人员，人员必须隶属于1个总部。

下属单位关系

1. 下属单位可以有0或多个子下属单位，子下属单位有且只有1个上级单位。
2. 下属单位可以有0或多个部门，部门有且只有1个上级单位。
3. 下属单位可以有0或多个人员，人员可以隶属于0个或多个上级单位。

部门关系

1. 部门可以有0或多个子部门，子部门有且只有1个上级部门。
2. 部门可以有0或多个人员，人员可以隶属于0个或多个上级部门。

人员关系

1. 人员可以直接隶属于总部/下属单位/部门之下。
2. 人员必须隶属于1个总部，但可以同时隶属于多个下属单位或部门之下。

组织中各个层级之间的E-R关系图：

RootOrganization(总部)、SubOrganization(下属单位)、Department(部门)、personnel(人员)。

2. 角色​

2.1 角色定义​

在企业中访问控制的范围取决于员工所扮演的角色，角色中包含企业已确认的职责、责任和资格的规范，例如：悦库系统中的角色包括文件管理员、人事管理员、运维管理员等，每一种角色根据其包含的职责有不同的访问范围。

例如单位人事主管角色用于管理单位内部的人员，拥有对人员/部门的创建、编辑和删除等人事相关权限。

在组织中只有人员可以拥有角色，一个人员可以同时拥有多个角色：

2.2 角色级别​

角色按权力级别分为：管理员角色、单位主管角色、部门主管角色、普通角色。管理人员只能创建比自身角色级别低的新角色，当为其他人指派角色时，被指派角色权限必须小于当前管理者自身角色的权限，这样可以防止角色恶意提权问题。

由系统创建的默认角色，其中1~3级为管理角色，4级为普通角色：

1级管理员角色

文件管理员，可以管理系统中的所有文件，可以查看系统中的所有单位、部门和人员。

人事管理员，可以管理系统中所有下属单位以及下属单位中的部门和人员、管理本单位角色和公共角色，拥有人事管理最高权限，但只拥有人事权限，无管理文件权限。

运维管理员，对系统进行运行维护，无人事和文件管理权限。

2级单位主管角色

单位文件主管，可以管理本单位中的所有文件，可以查看当前单位中的所有部门和人员。

单位人事主管，位于下属单位，可以查看和管理当前单位中的所有部门和人员、管理当前单位角色，无管理文件权限。

3级部门主管角色

部门文件主管，可以管理本部门中的所有文件，可以查看当前单位中的所有部门和人员。

4级普通角色

普通员工，可以在授权范围内对文件进行操作，默认仅可以访问本单位内组织，经过授权可以访问其它单位组织。

2.3 职责分离​

职责分离是确保单个人员不具备完成恶意行为的所有必要权限的一种策略。最常见的⽰例是财务工作中的发起⽀付和授权⽀付操作，任何⼀个⼈员都不应该能够同时拥有这两种权限。在文件管理领域中以FTP服务器为例，运维人员的职责是系统运行维护，却可以超出自身职责，直接查看FTP服务器上的所有企业文件(本应属于文件管理职责)，运维人员的职责不明确，将为企业文件增加泄露风险。

管理角色按职责分为职能管理和文件(业务)管理。人事管理和运维管理属于职能管理，人事管理角色只负责管理组织和人员，运维管理角色则只负责管理系统运维相关工作，职能管理角色不参与对文件访问权限的管理。文件管理角色专门负责组织内的文件(业务)管理，不参与组织的职能管理。

3. 权限​

3.1 单位隔离​

下属单位 是一个相对独立的组织，拥有单位范围的安全边界。各单位之间在组织访问、文件访问、角色设置等操作中相互隔离，默认不能互通。

例如在集团医院中，如果将市北分院和崂山分院定义为下属单位，则默认市北分院的人员无法访问崂山分院的文件，同时也看不到崂山分院的组织结构。市北分院中创建和设置的自定义角色在崂山分院中不可见。

3.2 单位协作​

在相互隔离的单位之间建立协作关系，是企业中常见的应用场景。

单个人员可以通过设置和授权方式实现对其他单位的组织或文件的访问。例如：通过将市北分院的用户小明，加入到西海岸分院中，实现人员跨单位访问，这样市北分院的小明就可以访问西海岸分院的组织结构和已授权文件。

作为一个独立单位，也可以设置可见单位，实现两个单位之间的组织互通。组织互通后，就可以根据授权访问对方单位的文件。

附录​

常见的大型组织形式：

大学

集团公司

集团医院

管理的本质​

我们把文件作为企业的一种数据资产，那么它应该和传统的资产管理有异曲同工的思想。

比如小明现在是一个工厂的物料仓库管理员，负责对仓库中所有物料资产进行管理，如果他的能力不足，结果可能是：

1. 货物随处乱放，出货很慢。
2. 库存和出货量对不上，因为有些货出了，忘记登记了。
3. 货物即将过保质期而不不知。
4. 夏天多雨多虫，货损严重。
5. 消防意识差，仓库发生火灾，货损严重。
6. 各生产部门对原材料库存量信息不明确，阻碍生产和销售。

于是领导对小明的评价是：“仓库管的乱七八糟，简直是一团乱麻，趁早走人！”

小明反思：“如何管好仓库？不要搞的那么乱？”。

在信息论中有一个概念叫做“熵”，其定义是：“是一个系统内在的混乱程度“。这是应用于热力学、统计物理、信息论中的概念，由德国物理学家克劳修斯于1865年所提出。对于小明来说，要管好仓库，就需要逐渐降低仓库的混乱程度，即“熵减”。因此对于管理的过程是“熵减”的过程。我们针对管理所提出的方法论，其目的都是为熵减。

对于企业中的文件资产管理也是一样，要解决混乱问题，也需要熵减。

建立秩序​

对企业中混乱的文件资产进行“熵减”，需要建立可落地的“秩序”，新秩序要落地，必然需面对阻力。

阻力一：新规则的学习成本和普及度。

阻力二：工作方式的改变，造成不适应。

阻力三：对秩序的最终价值缺乏信心，不认可，抗拒。

不要妄想强制推行管理型工具，如果不理解和接受管理理念，直接使用工具是无法发挥效能的。为企业建立可落地的文件管理新秩序，需要循序渐进，采用 “理念教育+使用培训+工具落地” 的方式。

1. 权限管理​

RBAC(基于角色的权限管理)​

在企业组织内，为各种工作职能创建角色，如“超级管理员”、“系统管理员”、“部门管理员”、“普通员工”，然后将文件操作的权限分配给特定角色，通过这些角色获得执行文件操作所需的权限，这样每个员工都有自己的文件访问范围，不至于越权访问。

三权分立​

查看我们的另一篇文章《文件管理之三权分立》

2. 目录结构的规划​

• 构建良好、和谐、有序的目录结构​

两条重要的基础原则：

1. 通用性：目录结构要符合大众的认知，自己能看懂，别人也要能看懂。

2. 可扩展性：即使是同一个人每个阶段的兴趣爱好、学习计划等等都不尽相同。目录结构必须能够随时扩展，以适应新的需求。

• 使用同一个维度对目录进行分类​

对目录的分类，要先分析分类后归纳概括:

• 分析分类：分析文件属性，确定它们的分类；
• 归纳概括：将属性相同的文件，放入类目目录。

那么，如何分析文件属性，进行分类归纳呢？如果引入MECE分析法就很容易理解了。

MECE 分析法（Mutually Exclusive Collectively Exhaustive），中文意思是「相互独立，完全穷尽」。 也就是对于一个重大的议题，能够做到不重叠、不遗漏的分类，而且能够借此有效把握问题的核心，并解决问题的方法。

「相互独立(ME)」意味着问题的细分是在同一维度上并有明确区分、不可重迭的，「完全穷尽(CE)」 则意味着全面、周密。

图片来源于网络

举例子：

文件按按部门分为市场部、财务部、研发部、运维部，是 MECE 的；

文件按项目分为A项目、B项目、C项目等等，也是 MECE 的；

文件按行业分为制造业、IT业、外贸等等，也是 MECE 的；

但如果将文件分为照片、应用程序、客户资料、财务数据，分类即会有遗漏，也会有重叠，就非 MECE 了，因为有些照片可能是客户资料相关的，也可能有些财务数据和客户资料有关联。

所以，目录，一定要在相同的维度上分类，有时候，我们的分类可能无法做到完全穷尽，也一定要保证做到相互独立。否则，随着时间的推移，你一定会陷入一个文件不知归类到哪个目录合适的窘境。

按照一些文件不同的属性构建不同的目录树​

上文对文件进行的分类，经过分析，会发现每种文件都有自己相对更突出的属性。比如文档、照片、财报，有更强的时间属性，那么我们就可以构建一棵以时间为父目录的目录树，存放这类文件；比如素材、媒体文件，有更强的类目属性，那么我们就可以构建一棵以类目为父目录的目录树，用以存放这类文件。

这样做的好处是，具备比较好的可扩展性。照片、文档我们就按年为单位不断扩展下去，保留最新3年，旧的存档就可以了。素材和媒体文件，则是属于任何时间都可能需要用到，且无所谓创建时间的文件，就按类别不断积累就可以了。

3. 文件的命名​

未经命名的文件毫无意义​

在文件管理体系中，文件命名是十分重要的一个环节。未经命名的文件是没有意义的。就好比天文学中，每一颗被人类发现的天体，都会被命名。那些没被命名的天体都是没有被发现的，对于人类的认知来说，就是不存在和没有意义的。

像 xn_483784@596w_1l.jpg、J0UPIHT2R.doc 这样的文件，在文件管理体系中，就是毫无意义的。因为你即无法通过文件名知道文件的大体内容，也无法通过搜索应用来找到它。所以，文件命名就像是为文件进行编码，用语言、数字和符号，来赋予文件名意义。

所以，对文件命名的指导思想就是：将文件内容反映在文件名上，为文件赋予意义。

文件命名的规范​

• 唯一且格式统一：唯一很好理解，任一文件不应该重名；格式统一则是需要建立一套统一的命名规则。比如，命名规则为：人物-事件-地点-时间-描述-序列号。

  • 人物：就是文件的所属人或描述的主体。
  • 事件：就是文件主体名称，描述文件是什么或者文件记录的是什么。
  • 地点：文件创建的地点或者描述的地点。
  • 时间：文件创建的时间或者描述的时间。
  • 描述：对文件内容的附加描述。
  • 序列号：版本号、序号。

  举例来说，张三_年度_财务报表_1.2.xlsx，2019 是指文件描述的时间；张三是文件的所属人；财务报表是事件，说明文件记录的是什么；年度则是附加描述，说明这是年度报表而不是季度或月报表；1.2 则是文件的序列号，说明这是第三个修改版本。

  再举例来说，张三_厦门_家庭旅游_001.jpg，时间、谁、在哪里、干什么、编号。张三_广告策划_简历.doc，谁、附加描述、是什么。

  上述例子中的下划线，在实际情况下是没有必要的，这里仅做方便说明分隔之用。

4. 参考国家标准​

​ 对于中大型的企业，由于内部的文件数量庞大且流通频繁，则可以参考国家档案局制定的一些标准来对内部文件制定自己的文件管理规则，然后使用文件管理工具进行落地实施。

• GB/T 39784-2021 电子档案管理系统通用功能要求
• GB/T 39362-2020 党政机关电子公文归档规范
• GB/T 9705—-2008 文书档案案卷格式
• GB/T 11821—2002 照片档案管理规范
• GB/T 11822—2008 科学技术档案案卷构成的一般要求
• GB/T 13967—2008 全宗单
• GB/T 15418—2009 档案分类标引规则
• GB/T 17678.1—1999 CAD电子文件光盘存储、归档与档案管理要求 第一部分：电子文件...
• GB/T 18894-2016 电子文件归档与电子档案管理规范
• GB/T 20163-2006 中国档案机读目录格式
• GB/T 26162.1-2010 信息与文献——文件管理第1部分：通则
• GB/T 26163.1-2010 信息与文献——文件管理——文件元数据 第1部分：原则

参考资料​

基于角色的访问控制

国家档案标准库

个人文件管理体系构建思路

文件管理的权利问题​

专业的文件管理系统，在权限控制标准中通常选择基于角色的访问控制 (Role-based access control)，简称RBAC模型，这是一种围绕角色和权限定义的策略中立的访问控制机制，悦库企业网盘的权限管理也是基于这种模型。

在企业组织内，为各种工作职能创建角色，如“超级管理员”、“系统管理员”、“部门管理员”、“普通员工”，然后将文件操作的权限分配给特定角色，通过这些角色获得执行文件操作所需的权限，这样每个员工都有自己的文件访问范围，看起来井然有序。

但这种权限管理方法，存在一些安全问题：

1. 超级管理员拥有所有权限，是集权者，权利过大，行为不可控。

   “小明是某公司文件管理系统的超级管理员，因为与上司三观不合，提出离职，离职前小明将公司所有文件打包带走，给公司信息安全造成巨大隐患。”

2. 权限分配无人监督，存在越权访问问题。

   “小谢是某公司业务部门经理，拥有部门管理员权限，为了方便和一个重要客户共享资料，直接为该客户在内部文件管理系统中创建了账号并默认指定了可以访问本部门内文件的权限，导致公司重要文件外泄。

3. 系统运维人员，违规访问业务数据。

   “小王是某公司文件管理系统的运维人员，出于好奇，为自己创建了财务部门账号，下载并查看了一些员工的工资报表，然后将账号删除。”

从以上案例我们可以看出，虽然对文件的访问做了权限管理，但依然存在重大数据外泄隐患，其主要原因在于集权访问制度，即员工的操作行为不受他人监督，是否违规全凭自觉。

权利的平衡​

“一切有权力的人都容易滥用权力；要防止滥用权力，就必须以权力约束权力！” --- 法国启蒙思想家 孟德斯鸠

以权力约束权力使其保持平衡，是解决集权问题之道，于是我去寻找构建权利平衡的方法论：

去年到四川某部队出差，与安全部门主管对接文件管理需求时聊到文件管理的权利平衡问题，我们一致认可国家保密标准BMB20-2007《涉及国家秘密的信息系统分级保护管理规范》中提出的“三员”管理概念，三权分立，用监督制约权利。

我查阅资料，有一些心得，下面与您分享。

三权的起源​

三权分立，是西方民主国家的基本政治制度的建制原则。三权分立原则起源于亚里士多德时代，他首次将国家的政权划分为议 事权、行政权和审判权。1680年，英国思想家洛克发表了《政府论》，主张治理权与统治权应当分离。随后，1748年，孟德斯鸠发表了《论法的精神》，其站在新兴资产阶级的立场上，提出了著名的“三权分立”。

三权分立主要阐述政府的立法权、司法权与行政权三权分离，各司其职，三种权力互相制约，防止掌权者权力的滥用。

三员概念​

“三员”，在国家保密标准BMB20-2007《涉及国家秘密的信息系统分级保护管理规范》中提出，要求涉密信息系统应当配备系统管理员、安全保密员和安全审计员三类安全保密管理人员（简称为“三员”)，分别负责系统运行、安全保密管理和安全审计工作。“三员”担负维护系统安全、稳定、可靠运行的重要任务，对涉密信息系统和国家秘密安全具有重要作??。

“三员”在悦库企业网盘中落地​

“三员”并不是对RBAC模型的革新，而是基于RBAC模型之上构建的更为安全的权利管理体系，通过“三员”机制的实施，可以大幅度提高文件安全级别。

在悦库系统中的“三员”模式下，去除了超级管理员角色，为系统创建三种基础角色：“系统管理员”，“安全保密员”，“安全审计员”，如图：

“安全保密员” 负责为员工设置空间、文件夹、文件访问授权，为我的组织内员工变更角色（需低于安全保密员的角色权利值）。推荐由部门或项目组核心员工担任。

“系统管理员” 负责系统日常的运行维护工作，包括系统配置、新员工创建、员工的三员属性变更。可由公司普通运维人员担任。其中三员属性变更操作需安全审计员审核。

“安全审计员” 可接收系统的安全审计报告，审查我的组织中的“安全保密员”提交的文件访问授权，审查“系统管理员”的新建用户和运维报告，审批“系统管理员”提交的三员属性变更授权。推荐由部门主管或项目经理等领导层担任。

其他事项：

三员模型初始化时，需要确认三员属性拥有者，初始化操作有系统管理员触发，仅能触发一次。

任何人不能修改自身角色。

参考资料：

公安部等通知印发《信息安全等级保护管理办法》

基于角色的访问控制 (Role-based access control)

BMB20-2007《涉及国家秘密的信息系统分级保护管理规范》，是国家“秘密级”文件，传播违法。