迪拜企业的每月网站维护清单
迪拜企业每月网站维护清单：更新、备份、正常运行时间、表单、安全、性能，以及网站出问题时该怎么做。
阅读文章迪拜 SharePoint 内网真正擅长的，是带有恰当权限和版本历史的文档库、面向全公司的公告和政策页面，以及能够从一套中心权限规则继承或独立出来的结构化团队站点。对于已经在为 Microsoft 365 付费的迪拜企业来说，这样一套内网通常是把这三者集中到一处最简单的方式，因为平台本身已经获得许可，权限模型也已经搭建好。它力不从心的地方，是任何需要像现代应用程序那样呈现、或是需要公开的内容。
本文将说明迪拜 SharePoint 内网适合迪拜企业的哪些场景，不适合哪些场景，权限和文档控制在底层实际是如何运作的，以及最常把一个全新内网变成上线两个月后就没人再打开的页面的那些错误。
要点速览
- 迪拜 SharePoint 内网最擅长的是拥有真实权限的文档存储、政策与人力资源内容，以及公司公告。
- 它不适合面向公众的网站、高度定制的内部应用程序，或是希望优先使用即时聊天、轻量工具的团队。
- 权限默认从顶层站点向下继承，任何站点所有者都可以在站点、文档库或单个项目级别打破这种继承关系。
- 文档版本历史在每个文档库中默认开启，主要版本与次要版本管理或签出功能可以为需要更严格控制的场景单独开启。
- 大多数失败的 SharePoint 内网，问题出在归属和结构上，而不是出在软件本身。
迪拜 SharePoint 内网对企业能做好哪些事
迪拜 SharePoint 内网最有力的应用场景，是一家已经在使用 Microsoft 365 的企业，需要一个地方存放政策、人力资源表格、部门文档和公司新闻，并配有真正的访问控制，而不是散落在共享盘和邮件附件里。因为大多数使用 Microsoft 365 的迪拜企业已经拥有许可证，搭建一个良好的 SharePoint 内网，边际成本主要在于搭建和结构规划，而不是新软件。
一个通信站点很适合作为门户使用：新闻帖、公司通讯录、指向各部门团队站点的链接，以及一个真正能找到文档、而不只是搜索页面标题的搜索框。在它下面，团队站点为每个部门提供各自的文档库、列表和页面，权限既可以跟随主站点，也可以独立设置。这种结构，很适合拥有多个部门、并确实需要让人力资源、财务和法务文档只对正确的人可见、同时让常规政策对所有人开放的迪拜企业。
迪拜 SharePoint 内网力不从心的地方
SharePoint 内网并不适合用作公开网站。它位于 Microsoft 365 登录之后，其模板是为内部发布设计的，而不是为营销页面或产品目录设计的，在公开搜索结果中也没有实质存在感。面向迪拜受众搭建的 SharePoint 内网，应该保持内部使用，公开网站应该放在专为此设计的平台上处理。
它同样难以替代一个专门搭建的内部应用程序。开箱即用的 SharePoint 提供列表、文档库、页面和少数几个 Web 部件，这能很好地覆盖文档管理和基础工作流，但一项带有复杂逻辑、真实数据库结构、或需要与另一个系统深度集成的业务流程，通常会超出一个 SharePoint 站点在不做自定义开发的情况下能舒服应付的范围。而对于希望使用单一即时聊天工作区、而不是一套结构化页面库的小型、快节奏团队来说，SharePoint 内网可能会显得比他们实际需要的更沉重。
SharePoint 内网的价值体现在文档和权限上。一旦需求变成“帮我们搭一个应用程序”，它就是错误的选择。
SharePoint 内网中权限实际是如何运作的
SharePoint 中的权限从顶层站点开始，向下经过子站点、文档库、文件夹和单个项目逐级继承，除非有人在某个层级刻意打破这种继承关系。根据 微软官方关于 SharePoint 权限级别的说明，一旦站点所有者在某个站点、文档库或项目上设置了独立权限，该对象就会停止从其父级继承，这正是迪拜企业能够在锁定财务文件夹、只对少数人开放的同时，让同一站点内的常规政策库保持公开的方式。
在一个典型团队站点上，三个默认组承担了大部分工作。访客组获得“读取”权限，可以查看和下载但不能编辑。成员组获得“编辑”权限，涵盖添加、更新和删除列表项及文档。所有者组获得“完全控制”权限，是唯一有权自行管理权限和站点结构的组。对于迪拜企业搭建的大多数 SharePoint 内网来说，这三个默认组已经足够，而“参与”“设计”“批准”等更细粒度的级别，则覆盖了“编辑”或“读取”过宽或过窄的特殊情况。
| 组 | 权限级别 | 涵盖内容 |
|---|---|---|
| 访客 | 读取 | 查看和下载项目，不能编辑 |
| 成员 | 编辑 | 添加、更新和删除列表项及文档 |
| 所有者 | 完全控制 | 一切权限，包括管理权限和站点设置 |
一份合理的迪拜企业内网权限方案，应从这三个默认组出发，只有在确有正当理由时才添加独立权限，例如一个人力资源或董事会级别的文档库。在每隔一个文件夹就打破一次继承关系，而不是依赖默认结构，是让权限模型在一年后变得没人能完全理解的最快方式。
文档控制：版本、签出与审批
SharePoint 内网中的每一个文档库都默认开启版本历史，因此当某位同事覆盖了一份文件，或做了不理想的编辑时，可以回滚到之前保存的某个版本，而不是让改动变成永久性的。对于需要更严格流程的文档库，站点所有者可以开启主要版本与次要版本管理，让文档在被发布为所有人可见的当前版本之前先经历若干草稿版本，再配合签出功能防止两人同时编辑同一份文件，以及需要指定审批人在文档对所有具备读取权限的人可见之前签字确认的内容审批流程。
这一点对政策文档、合同以及任何曾因邮件中流传过时版本而引发过真实问题的内容尤其重要。一个配置得当的文档库，几乎能彻底消除“哪个版本才是最新的”这类疑问，因为真正的信息来源是文档库本身，而不是某个人的收件箱。
SharePoint 内网常见的错误
最常见的错误，是在还没人真正梳理清楚企业如今究竟是如何组织文档之前，就先设计好了权限结构和站点层级。这样搭建出来的站点，往往复刻的是一份没人实际遵循的组织架构图，而不是人们实际搜索和分享文件的方式。
第二个错误，是把上线当成终点。一个没有指定所有者、没有保持新闻和政策更新的计划、也没有在六个月后检查未使用站点的 SharePoint 内网，往往会在一年之内逐渐漂回邮件和共享盘，因为这个内网不再是查找当前信息最简便的地方。我们在迪拜企业中足够常见地看到这种模式，因此一份 SharePoint 内网上线计划，应该在搭建第一个站点之前，而不是之后，就先指定一位负责人。
第三个错误，是从一开始就过度设计权限，为了“保险起见”在几十个文件夹上打破继承关系，而不是从三个默认组出发，只在真正存在敏感需求的地方才添加独立权限。每一个被打破的继承点，都是日后有人加入、调岗或离职时，需要额外记得去更新的一件事。
在动手搭建 SharePoint 之前先梳理文档
在打开任何一个站点模板之前，先列出企业实际持有的文档类型、谁需要看到每一类，以及谁需要能够编辑。
从默认组出发
围绕访客、成员和所有者搭建结构，只在有具体、明确理由时才打破继承关系。
按风险大小开启相应的文档控制功能
版本历史已经默认开启。只为确实需要更严格控制的文档库，添加主要与次要版本管理、签出或审批功能。
在上线前指定负责人
需要有人负责在内网上线后持续保持其内容更新，否则同样会重演那种漂回邮件和共享盘的情况。
Digital Marketing Dubai 能提供哪些帮助
我们会围绕迪拜企业实际组织文档的方式来规划 SharePoint 内网结构，而不是套用一份通用模板，我们的SharePoint 开发工作涵盖权限规划、文档库搭建，以及通信站点在超出开箱即用选项之后所需要的自定义 Web 部件。对于在 Microsoft 365 上有更广泛需求的企业，我们的Microsoft 365 开发服务覆盖了更广的平台范围，包括 SharePoint 与 Microsoft 365 其余套件之间的集成。
如果您的企业正在为内部或对外工作在 SharePoint 与其他平台之间做选择，我们关于如何为阿联酋企业选择 CMS的指南，以更宏观的角度梳理了这个决定，我们的月度网站维护检查清单则覆盖了一个线上网站或内网都需要的日常维护工作。
