站点运营做久了，帳號會越攒越多。域名在谁名下、服務器面板用哪個信箱註冊、統計工具的超級管理員是谁、CDN 的帳號還有没有人记得密碼——這些問题平时没人問，一旦有人离职、轉岗，或者只是長期不登入，就會集中爆發。多數站点遇到的麻烦不是被攻击，而是自己人拿不到權限。
帳號散落的几種典型情况
- 域名註冊商帳號用某個同事的個人信箱註冊，人走了信箱也停用。
- 服務器、面板、CDN 各自一套帳號，只有一個人知道密碼，没有任何记錄。
- CMS 後台所有人共用同一個管理員帳號，出問题查不到是谁操作的。
- 統計工具、搜尋资源平台、第三方接口的授權挂在個人帳號下，換人就得重新申請。
- 證书續期、短信、支付等服務的通知信箱指向一個已经没人查看的地址。
這些情况單看都不算故障，叠加起来就變成“站点還能訪問，但没人能改”。
先做一次帳號盘点
建议按“對站点的控制程度”從高到低列一張表，字段至少包括：帳號用途、平台名稱、登入地址、註冊信箱、目前持有人、是否開啟二次驗證、找回方式。下面這些類別通常都要覆盖：
- 域名與解析：註冊商帳號、域名轉移密碼、DNS 服務商。
- 服務器與基础设施：云主机、控制面板、對象存储、CDN、负载均衡。
- 站点程序：CMS 後台、資料库、附件存储、队列或定时任務服務。
- 資料與工具：訪問統計、日誌、监控告警、搜尋资源平台。
- 外部依赖：第三方接口、短信、邮件推送、支付、客服工具。
- 通信渠道：與上述帳號绑定的信箱、手机号、内部群组。
表不用做得漂亮，但每一項都要有人名和日期，空白項就是待處理項。
權限分級比換密碼更重要
很多团队交接时只做一件事：把密碼改掉發到群里。這样做的结果是密碼繼續扩散，几個月後又回到“谁都有、谁都不负责”的狀態。更稳妥的做法是按角色分權限：
- 日常編輯只给内容發布權限，不给主题、插件、用戶管理權限。
- 技術维護给服務器和部署權限，但不一定需要域名轉移權限。
- 域名、DNS、支付這類高影响操作，尽量保留在两到三個固定负责人手里。
- 能開子帳號就不要共用主帳號，能按項目授權就不要给全局權限。
子帳號的好處是人員變動时只需要停用一個人，不用把整套密碼全部重置，也不會影响其他人正常干活。
交接时按顺序做這几步
- 確認帳號归属：優先把註冊信箱、绑定手机換成团队统一管理的信箱和号碼，而不是個人信箱。
- 核對找回渠道：確認重置密碼走的是哪個信箱、哪個手机号，這個渠道必须還在自己手里。
- 改密與換绑：离职人員接触過的帳號全部改密，共享密钥類的接口凭證重新生成。
- 開啟二次驗證：高權限帳號尽量都開，並把恢复碼存進团队可訪問的密碼管理工具。
- 停用而非立刻刪除：先停用离职帳號，观察一段時間確認没有服務依赖它，再考虑刪除。
- 留档與通知：把更新後的清單交接到接手人，並通知相關的外部對接方。
交接完成後要驗證的事
改完密碼不等于交接完成。至少驗證一遍下面這些動作，確認新的持有人真的能獨立操作：
- 用新帳號登入 CMS，發布一條測試内容再刪除。
- 在解析面板新增並刪除一條測試记錄。
- 確認證书、备份、定时任務的通知還能正常送達。
- 確認搜尋资源平台的站点归属没有因為帳號變動而失效。
- 確認监控告警發到了仍在使用的群组或信箱。
交接的目标不是“把密碼给出去”，而是让接手的人在没有前同事帮忙的情况下，也能獨立完成日常维護和應急處理。
把交接做成固定流程
與其每次人員變動时临时翻聊天记錄，不如把它固定成流程：帳號盘点表每季度更新一次，入职、轉岗、离职时各走一遍清單。清單里寫清楚每一步的负责人和完成日期，交接双方確認。成本不高，但能避免很多“找不到入口”的尴尬。
站点运营里，内容、结构、抓取這些事情大多有工具可以量化，唯獨帳號和權限靠的是记錄和习惯。趁人員稳定的时候把清單整理出来，比出事之後再补救要省事得多。