站点出故障的原因里，被攻击和被误操作几乎各占一半。前者通常有人盯，后者常常没人管——因为多数团队默认“自己人不会出错”。但现实是，一次手滑删掉栏目、一次改错伪静态规则、一次把测试配置推到线上，都足以让站点半天打不开。这篇文章讲的是怎么把账号和权限理顺，让误操作的概率降下来，并且出事之后能查清楚是谁改了什么。
先把账号清单拉出来
很多团队连“谁有站点后台权限”都说不清。自查第一步不是改配置，而是做一次盘点。把下面这些入口逐个列一遍，写成一张表，记录负责人、当前持有人、是否还在用：
- 网站后台（含超级管理员、编辑、审核等角色）
- 服务器 SSH / 面板账号、数据库账号
- DNS 解析、CDN、对象存储、证书管理后台
- 统计平台、站长工具、推送接口的账号
- 第三方插件、建站系统自带的管理入口
这张表最容易暴露的问题，是离职半年的人还挂在管理员列表里，或者某个测试账号用的是弱口令，长期没人动过。
权限分级，别让所有人都是超管
权限失控的典型表现是“人手一个管理员”。日常写内容的人不需要改主题文件，做设计的人不需要动服务器配置。按职责分三层通常就够：
- 内容层：写稿、编辑、上传图片，只能在自己负责的栏目里操作，没有发布到首页的权限。
- 运营层：可以发布、调整栏目、配置跳转，但看不到密钥类信息，也不能改服务器环境。
- 管理层层：能改配置、装插件、动数据库，人数应当尽量少，且必须能看到完整操作日志。
分完之后再回头对一遍：每个人的权限，是不是恰好等于他现在要做的事？多出来的部分就是风险。
高风险操作，加一道确认
不是所有操作都要审批，但下面这几类值得单独设流程。常见做法是：先备份、再操作、留记录，并且尽量不在流量高峰期做。
- 批量删除内容、批量改 URL、批量替换正文
- 修改伪静态规则、跳转规则、robots 相关配置
- 升级建站系统、更换主题、批量装插件
- 调整 DNS 解析、切换 CDN 配置、更新证书
- 清理缓存、重启服务、变更数据库结构
一个简单的习惯很管用：动手之前，先用一句话写下“我要改什么、预期结果是什么、出问题怎么退回”。写不出来，说明还没想清楚，就别急着点确认。
关键动作要留得下来
出问题时，最耗时间的不是修复，而是排查“到底哪一步改坏了”。所以日志要能回答三个问题：谁、什么时候、改了什么。
- 后台操作日志至少保留最近几个月的记录，不要随手清空。
- 服务器上的配置文件改动，尽量用版本控制或每次改动前留一份带日期的副本。
- DNS、CDN 这类外部平台的变更，记在同一个文档里，别散落在聊天记录中。
- 发布动作带上简短备注，比如“修正栏目描述”，比一串随机字符有用得多。
人员变动时的交接
人员进出是最容易留下隐患的环节。可以固定成几个动作：
- 确认本人名下所有账号，逐一回收或改密，而不是只关掉后台一个。
- 检查共享账号是否还在使用，能用独立账号的尽量改成独立的。
- 把正在进行的改动、待办的配置项写进交接文档。
- 交接完成后，隔一周再核对一次账号列表，避免遗漏。
把自查排进固定节奏
权限和账号的事，改一次能管一阵子，但会随着人员和新系统慢慢漂移。比较省心的做法是每季度过一遍账号清单，每次大改版前再过一遍高风险操作流程。不用做得多复杂，能在出事之前把“谁还能进后台”这个问题答上来，就已经比大多数站点稳了。