第7章 安全、部署与运维

第 7 章 · 安全、部署与运维

本章要回答的三个问题：谁也不希望录了半年的数据一次断电全毁——防损坏、防误删、防越权，分别该怎么设防？系统做完怎么交到同事手里，前端后端分发到几台电脑，升级时难道挨个重装？日常维护到底要做哪些事，多久做一次？

为什么会有这一章

问一个扎心的问题：Access 项目最常见的死法是什么？不是功能不够、不是性能不行，而是文件坏了没人管、版本乱了没人清、人走了没人会。华彩项目上线半年时我做了一次回访，邻座一家同类公司自己搞的库正躺在冰柜旁边的一个共享目录里——对，字面意义的冰柜上方，唯一备份和本体在同一块移动硬盘上。他们不是不懂技术，是没把运维当回事。

本章的理念可以浓缩成一句话：开发占三分之一，剩下的全是让系统健康活着的手艺。 这门手艺由四件事构成：看清 Access 安全机制的真实边界并补上架构级的板子；用拆分手术把单文件改造成可分发的双层结构；建立备份与维护的机械性日历；以及养成让自己三个月后的迭代依然顺利的工程习惯。这四件事没有一件需要天赋，全靠纪律。

值得提前校准预期的是"安全"二字的分量：Access 提供文件级加密和信任中心防代码，但它不是为对抗蓄意攻击者设计的堡垒——真正的权限分层靠拆分加部署策略实现（谁能拿前端文件，本身就是权限），数据资产再值钱就到了该考虑服务器数据库的时刻。诚实面对工具的边界，也是运维手艺的一部分。

读完能解决什么

• 说清加密、密码、信任中心三层机制各自保护什么、不保护什么；
• 独立完成前后端拆分：链接表管理器一气呵成，多用户各持一份前端互不踩脚；
• 制定一份落地的备份日历（什么频率、存哪里、恢复演练怎么做）；
• 把压缩修复、性能体检变成周例行，懂得看哪些指标；
• 用版本号命名法和变更日志管理迭代，避免"最终版七号真的最终版"惨剧；
• 设计新员工的 fifteen 分钟上手培训路径，让系统不依赖某个人的记忆存活。

各节怎么分工

动工前的两个提醒

其一，这一章的动手量大于阅读量，四个小节各配了一套可以当场执行的清单（上锁十分钟、拆分手术、日历落表、变更仪式），请务必逐条在自己的实验库上演练一遍——运维手艺的全部价值都在肌肉记忆里。其二，顺序不可调换：先拆分再谈备份，先有版本号再谈变更流程；在单文件混沌状态下做的任何运维投入都会随下一次结构改造报废。

本章演练对环境的要求只有三条：前六章的功能开发已完成，至少能完整跑通一轮业务流程；有权限接触局域网共享目录或任意可用作后端宿主的机器；准备好一块独立于日常工作位置的备份去处。工具与权限就绪之后，这一章几乎不再新增任何软件技能，考验的是把既有能力组织成制度的定力。

往下走到哪

这套运维体系能把文件库照料得很好，但每个系统的寿命终有上限。第 8 章讨论长远的两件事：理解引擎的脾气以便延缓衰老，以及在正确的时机规划体面的升级路线。

最后给你一把衡量自己水平的尺子，运维成熟度自评五档：一级靠记忆记备份；二级有了日历但没演练过恢复；三级备份可恢复且坏了知道按什么顺序救；四级变更全走版本流程、错误日志有人看；五级是把这套体系顺利交接给了别人仍然照转。诚实地给自己定个位，本章四个小节正好对应二到四级的晋级台阶。

对照完尺子再出发还有一个心态上的提醒：运维的回报延迟而成本即时，坚持三周看不到"成果"很正常——它的成果以"没发生的灾难"计价，这在任何项目汇报里都不显眼，但客户心里有杆秤。撑过前三个月机械期，日历和清单就会开始替你工作。