唯一的 IT 管理員離職：一份交接計劃

一句話回答： 風險不在於崗位空了，而在於一整套沒有文檔的 IT 資產，裝在一個人的腦子裡走出了辦公室。在一個月通知期裡，先拿訪問權，再拿清單，最後拿只有他知道的那些事——順序就是這樣，因為前兩樣在他帳號被停用的那一刻就拿不到了。

香港一家五十人測量師行的管理合夥人，用一句話向我們描述過這件事：「他週一遞了辭呈，到週三我才意識到，公司裡沒有第二個人知道任何一個系統的密碼。」

那家公司再典型不過。三十到八十人之間，專業服務，一位在職五到八年的 IT 同事，一套圍繞這個人而不是圍繞任何成文設計長出來的 IT 環境。儲藏室裡有一台服務器，沒人打開過那個櫃門。域名註冊商的帳號掛在他的私人郵箱下。會計系統有一個變通做法是有原因的，而只有他記得那個原因。有一家硬件供應商只接他的手機，不接公司總機。

這些都不是失職。當一個有能力的人獨自撐起一家「增長速度快過其文檔」的公司的 IT 時，就會長成這樣——而這描述了香港相當大比例的專業服務公司。

下面講的是：你手上那四個星期該怎麼用。

為什麼這在香港這個規模段的公司裡如此常見

在這個特定區間裡，有三件事疊加在一起。

規模段很尷尬。 三十人以下，公司通常會外包 IT，或者靠消費級工具湊合。一百人以上，公司會有一支至少兩個人的 IT 團隊。夾在中間，一個人既養得起、又夠用，而且——所有人都假設——沒問題。這個區間裡沒有人為冗餘做過預算，因為在辭職信到達之前，表面上什麼都沒出錯。

香港的專業服務公司用一支很薄的團隊撐著一套很寬的環境。 一家五十人的測量、會計或諮詢行，通常會有一個域名、一個 Microsoft 365 或 Google Workspace 租戶、一台文件服務器或 NAS、給外勤同事用的 VPN、一套項目管理或成本核算系統、一套帶保留義務的文檔管理系統、幾個各自帶授權服務器的行業專用應用、若干供應商門戶，以及貫穿這一切的 PDPO 風險敞口。這不是一套小環境，它只是一套從來沒有被寫下來的環境。

通知期短，市場流動性高。 香港非管理崗的標準通知期是一個月。一位讀寫中英文的資深基礎架構通才，不會長期待業。所以這個窗口是固定的、是短的，而且在他簽了下家之後，不會因為人情而延長。

結果是一場可預測的危機，而公司裡沒有任何人演練過。

「只有他知道」到底指什麼

值得說具體一點，因為這個問題的抽象版本——「我們需要更好的文檔」——會導出一份誰都不滿意的文檔。

走出去的知識有四類，而它們的行為方式很不一樣。

憑據。 管理員帳號、註冊商登入、防火牆的 enable 密碼、備份控制檯、NAS 的 root 帳號、供應商門戶，以及那些登記在他個人名下或個人郵箱下的帳號。這一類是二元的：要麼你在他最後一天就拿到了，要麼你開始一個可能耗時數週、有時還需要公證公司文件的找回流程。
清單。 有什麼、在哪裡、什麼授權、什麼保修、什麼日期續期、用哪張信用卡付。這一類沒有他也能恢復，只是很慢，而且會有缺口。
依賴關係。 關掉儲藏室那台機器會壞掉什麼。哪份報表依賴哪個計劃任務。VPN 上那條看起來不對勁的靜態路由為什麼存在。這一層是第二個月裡製造不愉快驚喜的那一層。
隱性知識。 那個變通做法為什麼存在、哪家供應商真的會接電話、2023 年試過什麼並且失敗了、哪個用戶絕對不能被踢出哪個系統——理由是政治性的而不是技術性的。這是唯一一層真正無法重建的知識，也是大多數人留到最後才處理的那一層。

按這份清單來安排你的四個星期，而不是按一份通用檢查表。另外要注意，這個順序不是按重要性排的——隱性知識大概才是最值錢的——而是按失效時間排的。憑據和清單在帳號被停用時就不再可得；隱性知識衰減得慢一些，而且必要時，如果關係還在，還可以通過一份付費顧問安排部分找回。

第一週：訪問權與身份

先做這件事，在其他任何事情之前，並且不要讓它被當下運營上著火的任何事情擠到後面。

枚舉每一個帶管理權限的帳號，橫跨身份租戶、防火牆、交換機、NAS、虛擬化平台、備份系統、終端管理控制檯、防病毒租戶，以及公司付費的每一個 SaaS 應用。不是「他常用的那些」——是全部，包括服務帳號和應急帳號。

現在就建立第二個管理員，不要留到以後。 建好它，用另一台機器獨立登入測試一遍，然後把憑據存進一個公司控制的密碼管理器裡，管理合夥人或財務總監也要有訪問權。測試這一步很要緊：一個存在但從沒登入過的管理員帳號不是一道控制，是一個願望。

找出所有掛在他個人名下的東西。 這是最常被跳過的一步，也是最經常演變成真正危機的一步。域名註冊商帳號、SSL 證書帳號、移動運營商帳號、供應商支援門戶、一張登記到他郵箱的公司卡、應用商店開發者帳號，以及任何以他個人手機為種子的雙因素認證。每一項都需要在他還願意幫忙的時候，轉移到一個公司擁有的身份下——一個共享郵箱或一個角色帳號。在他最後一天之後，其中好幾項要走供應商的帳號找回流程，而有些流程確實很難走。

在他最後一天該改的就要改，並且事先知道哪些改動有爆炸半徑。在不知道什麼在用它的情況下輪換一個服務帳號的密碼，是讓公司在他離職後的第一個週一全面下線的好辦法。

把續期日曆寫下來。 域名到期、SSL 到期、授權週年、支援合同結束日、線路合同結束日。離職四個月後域名續費失效，是一種常見且完全可以避免的事故。

第二週：清單與依賴

訪問權拿穩之後，把「你到底擁有什麼」這幅圖畫出來。

不但要在邏輯上走一遍，也要在物理上走一遍。應該有人和他一起打開弱電櫃，把裡面的東西拍下來，然後寫清楚每一樣是幹什麼的——包括那個沒貼標籤、從 2019 年起一直在給某個重要東西供電的盒子。第二個辦公室或工地臨時房裡的設備，同樣處理。

對每一台設備和每一個系統記錄：它是什麼、在哪裡、幹什麼、誰依賴它、成本多少、支援或保修何時結束，以及它停了會發生什麼。最後那一欄，才是把一份資產清單變成有用東西的那一欄。

然後對非物理的部分做同樣的事：訂閱、授權、線路、移動套餐、雲租戶，以及任何對你係統擁有常設訪問權的第三方。帶遠程訪問權的供應商經常是個意外——比如那家自 2021 年實施以來一直有 VPN 帳號的項目管理系統供應商，這既是一項運營依賴，也是一個值得問一問的 PDPO 問題。

最後：測試備份。 不是「確認備份任務報告成功」——是真的還原一樣東西，還原到另一個位置，然後打開它看看。一位即將離職的獨立 IT 管理員留下來的最常見的東西，就是一套多年來一直報綠、卻從來沒有被還原過的備份機制。你希望在他還在職的時候發現這件事。

第三週：隱性那一層

這是大多數交接會跳過的一週，也是為什麼那麼多交接明明產出了一份很厚的文檔卻依然失敗。

一個人獨自寫出來的文檔，是一份樂觀寫成的文檔。讓一位即將離職的工程師獨自去寫，他會把架構記成當初設計的樣子而不是漂移之後的樣子；會略掉那個變通做法，因為它有點難堪；還會忘記那些對他來說太理所當然、以至於根本不被識別為「知識」的東西。

替代做法是：和他一起走一遍這套環境，並把過程錄下來。坐在他旁邊，挑一個系統，讓他講：這是什麼、為什麼這麼配、什麼會弄壞它、壞了之後你怎麼做、你打給誰。把這次會話錄下來——音頻就可以，螢幕錄製更好。然後讓另一個人照著這段講解去做一件例行任務。缺口會立刻現形。

優先級按這個順序排：今天就會讓公司停擺的東西；帶合規或客戶保密維度的東西；那些一年才發生一次、失敗之前沒人看得見的事件，比如年結流程或授權續期；最後才是「知道了更好」的部分。

也要直接問那份讓人不舒服的清單。你最擔心哪個系統？你一直想修但沒修的是什麼？有什麼是靠某種你不會寫進文檔的辦法撐著的？如果這是以同行禮貌而不是審計的方式問出口，大多數即將離職的工程師會誠實作答。

第四周：用做來驗證，而不是用讀來驗證

一次交接不會因為存在一份文檔就算完成。它是在「除了那位離職者以外的某個人真的把活幹了一遍」時才算完成。

在最後一週，讓接替者——內部的、臨時的，或者即將接手的服務商——在他還在場可以糾正的時候，真的執行一遍例行操作：

跑一次還原。 端到端，還原到可用狀態，從真正的備份系統還原。
跑一次入職。 建帳號、分配授權、配置設備、授予應用訪問權，並確認這位新用戶能把自己的工作做起來。
跑一次離職。 停用、回收、轉交郵箱、收回設備，並確認沒有遺漏。這同時是一項與 PDPO 相關的控制，也是交接工作與離職權限回收紀律自然交匯的地方——那篇講的是回收一位普通用戶的訪問權；你這裡做的是獲取一位管理員沒有寫下來的知識，那才是更難的那一半。
跑一次變更。 推一個補丁、重啓點什麼、按文檔走一遍回滾。
觸發一次升級。 用你記錄下來的帳號信息打給供應商，確認在他不在場的情況下，供應商認可你有開單的權限。

任何一件照著文檔做不出來的事，就是一個缺口——而你還有幾天時間把它補上。

通知期結束之前必須做的那個決定

其實只有兩條路，而「推遲選擇」本身就是一種選擇——它會把你預設推進第一條路的糟糕執行版本。

換一個人。 再招一位獨立 IT 管理員。這是熟悉的選項，保留了組織的形狀。它同時也原樣複製了你此刻所處的位置：一位新的同事，會在接下來五年裡積累出他自己那套沒有文檔的環境；而且從他最後一天到新人到崗之間的那段空窗，你沒有任何人頂著。

換一個模式。 轉向託管服務，讓文檔、監控、補丁和服務檯成為一套系統而不是某個人的記憶，並且讓任何一位工程師在設計上就是可替換的。

老實說，兩條路都站得住。環境的規模、公司對「辦公室裡要有一位有名有姓的人」的偏好，以及那位離職者究竟是在做基礎架構工作還是主要在做服務檯工作，都應該影響這個判斷——我們那篇香港中小企：託管 IT 與自建團隊之比較把這筆帳算得比較完整。站不住的是靠慣性做決定：啓動一個招聘流程，四周之內沒招到，然後用一位合夥人的助理和一張舊發票上找到的救火電話來填那個空窗。

對比：面對獨立 IT 離職的三種處理方式

直接招一個替代者

能給你：模式的連續性、辦公室裡有名有姓的一個人、對優先級的完全控制。
代價：一個你多半無法在通知期內走完的招聘週期、一段沒有覆蓋的空窗，以及從零開始重建的同一個單點故障位置。
適合：這個崗位確實寬泛且帶戰略性，公司本來也在向第二個 IT 編製成長，並且有一位資深的人能在技術上監督這次交接。

請一位臨時合同工頂住空窗

能給你：很快到位的人手，以及一位在交接失效之前能接住它的人。
代價：一個日費率，以及知識轉移要發生兩次——一次給合同工，一次給之後的人——每一跳都會損耗。
適合：永久性的決定確實無法在四周內做出，而你需要先把時鐘按停。

轉向託管服務並走一次結構化接管

能給你：作為交付物而不是人情的、歸你所有的文檔；不依賴任何人記憶的監控與補丁；有排班的服務檯；以及到場者背後的升級深度。
代價：一筆按人計的月費，以及一個要真正做好就超過四周的過渡項目。
適合：環境是標準的而不是奇異的，離職者的時間大部分花在支援而不是工程上，並且公司寧願買一套系統而不是買一個人。

一次結構化接管實際長什麼樣

如果你選第三條路，那麼在任何服務商的方案裡要檢驗的，是這次過渡究竟有沒有一個明確的形狀，還是隻是一張入職表格。

Brocent 自己的 IT 過渡與上線服務是一次為期三個月的結構化接管，值得把它描述出來，因為重點在於那個形狀而不是那個招牌：

第 1–2 周，勘察與審計。 現場走訪、IT 資產盤點、設備審計、網絡拓撲、數據分級與備份/還原策略複核，外加一項明確動作：識別出排名前三的基礎架構薄弱點。最後這一項在本場景裡格外要緊：離職者的那套環境，幾乎總有三件他知道不對、卻一直沒時間修的事。
第 2–4 周，知識轉移。 工程師跟著離職者見習或研讀其文檔，在管理平台上建起 CMDB，把所有資產、配置和授權編目，併為每一項重複性任務定義標準作業程序。
第 3–6 周，見習與再見習。 接手的工程師在被觀察的狀態下跑支援流程，直到達到「無需監督即可獨立操作」的基準；同時處理已識別的三個薄弱點，並做安全加固。
第 3 個月起，服務上線。 完整移交、帶 SLA 的服務檯（P1 首次響應 15 分鐘）、7×24 監控、月度報告，以及一份成文的升級矩陣——之後還有一次正式的上線後 30 天覆核，專門用來捕捉那些只有在真正運營之後才會浮現的知識缺口。

要堅持寫進合同的是交付物：一份帶保修與授權記錄的完整資產清單、一個 CMDB，以及一份覆蓋架構、供應商聯繫人、升級矩陣、授權續期、備份與災備流程和歷史已知問題的技術運維手冊。正是那份手冊，讓下一次離職——無論是服務商那邊的還是你這邊的——從一場危機降級為一個排期問題。

關於時間線有一點值得注意：三個月的接管比一個月的通知期長。這不是矛盾，這恰恰是「第一週就該開始談，而不是第四周」的真正理由。那些必須在離職者還在的時候完成的部分——知識轉移和憑據捕獲——在設計上就被放在了序列的前端。

為什麼「文檔歸你所有」才是整件事的重點

一次獨立 IT 離職更深的教訓，不是「我們當初應該多寫點文檔」，而是：跟著人走的文檔根本不算文檔——而且如果你放任的話，同樣的失敗會在服務商身上重演一遍。

檢驗方法很簡單，值得拿去問每一家你在考慮的服務商：如果我們終止合作，我們能拿到什麼，那是合同上的權利還是一次人情？

Brocent 的答案是：客戶擁有文檔與憑據，是每一檔 Managed IT 套餐裡的包含項——資產記錄、憑據、運維手冊和站點筆記按長期政策歸客戶所有，而不是談判換來的讓步。不管你用哪家服務商，都要把等價的條款寫進合同。一家不肯把這件事寫下來的服務商，正在構建的恰恰是你此刻正在花錢擺脫的那種依賴。

另外有一個合規維度值得提，但不必誇大。在 PDPO 之下，資料使用者對其持有的個人資料負有問責責任，包括由代理人處理的資料。上面描述的那套憑據衛生——不共用個人帳號、管理員密碼不放在個人密碼管理器裡、最後一天乾淨地回收權限、一份成文的「擁有常設訪問權的第三方」清單——首先是好的 IT 實踐，其次才是合規的副產品。它不是你把交接做好的理由，但它是你的審計方遲早會問到的理由。

如果這件事正在發生，從哪裡開始

如果辭職信已經在桌上了：今天下午就開始第一週。枚舉管理員帳號，建立並測試第二個管理員，列出所有登記在他個人名下的東西。這三件事最先失效。

如果你讀到這裡時桌上並沒有辭職信，那麼有用的練習更短。這周就請你的 IT 同事交給你三樣東西：每一個管理憑據的清單、每一個掛在他個人名下的帳號，以及關於這套環境最讓他擔心的三件事。如果這份清單一週之內交不出來，你其實已經知道那次交接會是什麼樣子了。

無論哪種情況，如果你希望這套環境由一套系統而不是某個人的記憶來記錄、監控和支援，那正是按人計費的託管套餐的用途——而如果離職已經迫在眉睫、你想把過渡序列對著你的具體通知期排一遍，聯繫我們。Brocent 自 2016 年起在香港運行這類接管，自 2007 年在北京創立以來一直在做結構化過渡。

常見問題

一次 IT 交接要多久？

捕獲階段——憑據、清單、依賴和隱性知識——只要從第一週就開始、並且按失效時間而不是按重要性排序，是裝得進一個月通知期的。完整遷移到託管服務則更長：Brocent 的結構化接管跑三個月，其中知識轉移被刻意安排在第 2 到第 4 周，好讓它發生在離職者還在的時候。兩者是重疊的，不是先後串行的。

如果人已經走了怎麼辦？

那你處在「恢復」而不是「交接」階段，更慢，但並非沒希望。優先重新取得管理控制權：走供應商的帳號找回流程，這些流程通常需要公司註冊文件和一位董事的授權；做一次完整的發現掃描重建清單；做一次還原測試，弄清楚你的備份是不是真的。為一段「變更能力下降」的時期留出預算——你不應該對一套自己還沒搞懂的系統做有風險的變更。在前僱員願意的情況下，為隱性那一層安排一份短期付費顧問，通常是花得很值的錢。

文檔歸誰所有？

永遠應該歸你，而且合同上應該這麼寫。在 Brocent，客戶擁有文檔與憑據是每一檔 Managed IT 套餐的包含項，而不是談出來的東西。如果一家現有或潛在的服務商把文檔當作自己的財產，那你買到的就是你正想擺脫的那個單點故障，還附帶一張發票。

如果憑據在個人密碼管理器裡怎麼辦？

趁他還在職處理，這是一次轉移作業；拖下去，它就變成對每一家供應商分別走一次帳號找回作業。要一份與工作相關條目的導出，逐條獨立登入驗證，然後存進一個公司控制的保險庫，至少兩個人持有訪問權。往後的規則是：公司憑據住在公司保險庫裡——個人密碼管理器是給個人帳號用的，而這是管理合夥人層面的政策問題，不是技術偏好。