站点出故障的原因里，被攻击和被誤操作几乎各占一半。前者通常有人盯，後者常常没人管——因為多數团队預設“自己人不會出错”。但現實是，一次手滑删掉栏目、一次改错伪静態規則、一次把測試配置推到线上，都足以让站点半天打不開。這篇文章讲的是怎么把帳號和權限理顺，让誤操作的概率降下来，並且出事之後能查清楚是谁改了什么。
先把帳號清單拉出来
很多团队连“谁有站点後台權限”都说不清。自查第一步不是改配置，而是做一次盘点。把下面這些入口逐個列一遍，寫成一張表，记錄负责人、目前持有人、是否還在用：
- 網站後台（含超級管理員、編輯、审核等角色）
- 服務器 SSH / 面板帳號、資料库帳號
- DNS 解析、CDN、對象存储、證书管理後台
- 統計平台、站長工具、推送接口的帳號
- 第三方插件、建站系統自带的管理入口
這張表最容易暴露的問题，是离职半年的人還挂在管理員列表里，或者某個測試帳號用的是弱口令，長期没人動過。
權限分級，別让所有人都是超管
權限失控的典型表現是“人手一個管理員”。日常寫内容的人不需要改主题文件，做设計的人不需要動服務器配置。按职责分三层通常就够：
- 内容层：寫稿、編輯、上传图片，只能在自己负责的栏目里操作，没有發布到首頁的權限。
- 运营层：可以發布、調整栏目、配置跳轉，但看不到密钥類信息，也不能改服務器环境。
- 管理层层：能改配置、装插件、動資料库，人數應当尽量少，且必须能看到完整操作日誌。
分完之後再回头對一遍：每個人的權限，是不是恰好等于他現在要做的事？多出来的部分就是風險。
高風險操作，加一道確認
不是所有操作都要审批，但下面這几類值得單獨设流程。常见做法是：先备份、再操作、留记錄，並且尽量不在流量高峰期做。
- 批量刪除内容、批量改 URL、批量替換正文
- 修改伪静態規則、跳轉規則、robots 相關配置
- 升級建站系統、更換主题、批量装插件
- 調整 DNS 解析、切換 CDN 配置、更新證书
- 清理缓存、重啟服務、變更資料库结构
一個简單的习惯很管用：動手之前，先用一句话寫下“我要改什么、预期结果是什么、出問题怎么退回”。寫不出来，說明還没想清楚，就別急着点確認。
關键動作要留得下来
出問题时，最耗時間的不是修复，而是排查“到底哪一步改坏了”。所以日誌要能回答三個問题：谁、什么时候、改了什么。
- 後台操作日誌至少保留最近几個月的记錄，不要随手清空。
- 服務器上的配置文件改動，尽量用版本控制或每次改動前留一份带日期的副本。
- DNS、CDN 這類外部平台的變更，记在同一個文档里，別散落在聊天记錄中。
- 發布動作带上简短备注，比如“修正栏目描述”，比一串随机字符有用得多。
人員變動时的交接
人員進出是最容易留下隐患的环节。可以固定成几個動作：
- 確認本人名下所有帳號，逐一回收或改密，而不是只關掉後台一個。
- 检查共享帳號是否還在使用，能用獨立帳號的尽量改成獨立的。
- 把正在進行的改動、待办的配置項寫進交接文档。
- 交接完成後，隔一周再核對一次帳號列表，避免遗漏。
把自查排進固定节奏
權限和帳號的事，改一次能管一阵子，但會随着人員和新系統慢慢漂移。比較省心的做法是每季度過一遍帳號清單，每次大改版前再過一遍高風險操作流程。不用做得多复杂，能在出事之前把“谁還能進後台”這個問题答上来，就已经比大多數站点稳了。