網站維運資產如何建冊？記錄網域、DNS、備份與負責人

建立網站維運資產索引，分清網域註冊、DNS 管理、備份位置、續費責任與維運窗口，並以提醒和定期核對維持資料可交接。

網站維運資產不只是一張網域清單。真正要交接時，團隊還得知道誰能登入哪個供應商、DNS 由誰管理、備份放在哪裡，以及事情出錯時要通知誰。把這些資料放進一份有負責人、有更新規則的索引，能減少依賴單一同事記憶，也讓交接或故障處理有明確起點。本文提供可自行套用的建冊方法，服務名稱、帳號與保存位置請依你實際使用的供應商填寫。

記錄網域與供應商

先逐一列出公司正在使用的網域，包括主要官網、活動頁、登入入口，以及仍在使用的舊網址；若有測試環境，註明用途與是否對外開放，避免把測試網域誤認成正式站。每筆紀錄至少包含完整網域、註冊商、目前管理帳號的辨識方式、登記人或付款主體、到期日、續費方式、內部負責人與代理人。網域註冊商、DNS 代管商、網站主機可能是不同公司，應分欄記錄，不能只填「網站廠商」。帳號欄寫公司信箱或密碼庫中的項目名稱，不要把密碼、驗證碼、復原碼直接放進多人可讀的試算表。也要登記供應商支援入口、合約或帳單的存放位置，方便核對服務仍有效。舉例來說，「示意網域 A」可標成正式官網，註明註冊商帳號由資訊窗口管理、付款由財務核帳，續費通知寄到共用信箱；若供應商或付款人改變，更新同一筆紀錄並留下日期與變更人。正式、測試、停用三種狀態要清楚，停用項目先確認沒有郵件、轉址或子網域依賴，再標記處理狀態。如此盤點才不會只列名稱，卻沒人能判斷它是否仍有用途。管理上也可另設一張供應商表，以供應商代碼連回網域列，避免同一家廠商有多個帳號時混在一起。若一個網域有多位管理人，寫清楚日常維護者與核准高風險變更者的差別。對於已停止使用但尚未到期的網域，標出預計保留或取消的決策人和檢查日期；不要為了讓表格簡短，刪掉仍可能影響郵件轉址或品牌入口的紀錄。資料來源欄也要區分管理介面查得與同事轉述，交接時先核對後者。另外指定索引的固定保管位置。

登記 DNS 和續費責任

DNS 紀錄會把網域指向網站、郵件或其他服務，因此索引應分清「網域在哪裡註冊」與「DNS 設定在哪裡維護」。記下 DNS 代管商、管理帳號辨識方式、負責人、代理人、目前生效的名稱伺服器，以及修改前應參照的設定紀錄位置；不必把每筆紀錄的敏感值複製到公開文件。若有多個子網域，補上用途與使用團隊，例如官網、客服入口或行銷活動頁，並指出對應主機或服務的內部名稱。續費責任要落到人：誰收通知、誰確認是否續用、誰核准付款、誰在完成後回填日期。可用下表作為虛構範例，實際值請以供應商帳務頁面及公司流程核對。

表格裡的「甲」「乙」只是示意名稱，不代表特定廠商；它呈現的是分工方式，不是建議採用哪一家。把 DNS 權限變更視為有紀錄的維運操作：修改前保存必要設定，記錄提出人、核准人、變更內容、時間及回復方式；若需要緊急修改，也在事後補齊紀錄。續費日期可由帳單或管理介面交叉確認，避免沿用過期的內部備註。若網域由外部廠商代管，至少確認公司內有可聯絡的窗口和可用的復原途徑，不要只留下業務聯絡人的姓名。還可記錄修改 DNS 的窗口時間和內部審核方式，讓急件不必臨時尋找核准人。對每個重要子網域標記負責系統及停用確認人；無人認領的紀錄先詢問相關團隊，再決定保留或移除。並記錄每次異動的核准人。

建立環境備份索引

備份索引要回答的不是「有沒有備份」，而是需要復原時，該找哪一份、由誰取用、能還原到哪個環境。先列出正式與測試環境各自包含的網站程式、資料庫、上傳檔案、網域設定、部署設定和必要的第三方匯出資料，標明哪些項目由供應商備份、哪些由團隊自行保存。每一類資料寫上備份方式或工作名稱、最近一次成功紀錄的位置、保存位置的權限負責人、保留政策、加密或存取限制，以及最後一次還原驗證的日期與結果。不要把「有備份」等同「可還原」；如果只保存資料庫，圖片或設定檔仍可能缺漏。位置欄要能讓授權人員找到檔案，例如公司密碼庫內的雲端資料夾名稱或備份系統項目，而不是含糊寫「雲端」。實際範例可這樣記：正式站程式碼由版本庫保存，資料庫備份由維運程序產生，媒體檔存於受控儲存空間；索引各列保存位置、負責角色和還原說明文件。若某項備份由供應商處理，記下可查詢的支援路徑與服務範圍，仍要確認團隊能取得所需資料。還原驗證應在適當的隔離環境進行，避免覆寫正式資料；記錄測試使用的備份、驗證項目、發現的缺漏與後續負責人。當保留政策或保存位置改變時，同步更新索引，舊位置不再有效就標示替代位置，不要留下容易誤取的過時連結。清單應區分備份產生時間與檔案實際保存時間，並指出誰有權限刪除或下載。交接時可請代理人依程序定位一份測試備份，確認索引足以找到它。若媒體與資料庫分開保存，分別記錄並確認時間點能互相對應。同時保留最近驗證結果的位置。

列維運窗口與程序

資產清單需要對應到實際的人與處理方法。每項資產設定一位主責和一位代理，記錄職務或團隊、公司聯絡方式、負責範圍，以及可做的操作；不要只寫「工程師」或個人私人電話，否則人員異動後難以接手。再列出供應商聯絡窗口或支援入口、內部案件編號欄位、合約／帳單位置和回報時應提供的非機密資訊。遇到網域到期、網站無法開啟、DNS 設定錯誤或備份失敗時，依序說明如何確認影響範圍、通知誰、由誰判斷是否需聯絡供應商、處理完成後由誰記錄結果。這不是要把所有技術步驟塞進索引；索引只需連到維運手冊、復原程序或供應商操作文件的受控位置。舉例而言，官網無法開啟時，代理人先記錄發現時間、受影響網址與可見錯誤，通知主責；主責確認主機和 DNS 的管理窗口後，再開啟供應商案件並回填處理編號。若主責請假，代理人應知道取得授權存取的正式方式，而非向離職同事索取密碼。對外溝通由指定窗口統一整理已知狀況、正在查證的部分和下一次更新時間，避免不同人提供矛盾說法。程序也要寫明什麼情況可直接執行既定回復步驟、什麼情況須先取得核准，並留下變更記錄。窗口離職、改組或供應商換約時，更新責任分配與文件權限，確認代理人能實際找到手冊和聯絡入口，再結束交接。每個程序也應標示適用環境、前置條件、完成判準和回復入口；過時步驟由文件負責人確認後標註失效並提供新版本位置。代理人交接時應實際演練查找，不只確認收到通知。並列出可用替代聯絡管道。

設定資料更新提醒

索引最容易失效的原因，是資料建立後沒有人負責更新。不要只安排固定日期檢查，也要把更新觸發點綁到日常變動：新增或移除網域、DNS 代管商更換、主機遷移、備份工作調整、權限窗口異動、付款主體變更，以及還原驗證結果出現缺漏。每項觸發點都指定執行人和回填期限；例如提出變更的人在操作完成後當日更新資產列，主責於下一個工作日核對，這只是可自行調整的流程範例。到期提醒則應同時送給續費承辦人與代理人，並把「通知已送達」和「已確認續用」分開記錄，避免把提醒當成付款完成。若要設多階段提醒，可以依公司核准流程設定較早的檢視點和接近到期的再次確認；具體天數應按採購、付款與供應商流程決定，不要把某個固定間隔當成所有組織都適用的標準。提醒內容包含資產名稱、到期日、負責角色、待辦事項和回填欄位，避免寄出密碼或復原資訊。若使用行事曆或任務工具，指定清單的唯一連結，讓承辦人從通知進入正本更新，避免多份副本各自變動。人員調動時，由原主責、接任者和代理人共同確認待辦提醒已轉交；若提醒失敗或信箱停用，也要有替代聯絡方式和補登責任。變更完成後記錄確認來源，例如供應商頁面、帳單或交接文件的名稱和查核日期，讓下一位檢查者知道資料從何而來。變更單尚未結案時，提醒仍指向原負責人；只有接任者確認收到後才移交。多個工具並用時，保留唯一清單與通知紀錄的對照，避免漏掉後續更新。並留下失敗時的替代通知人。

按期核對資產清單

定期核對時，先選定一個範圍，例如正式網站相關網域、DNS、主機和備份，再用供應商帳單、管理介面、內部付款紀錄與實際網站用途交叉比對。每筆清單確認資產仍在使用、負責人和代理人仍有效、續費狀態有依據、DNS 管理位置可登入或可聯絡、備份位置仍可由授權人員取得，並檢查連到的程序文件是否有效。發現差異不要直接覆蓋舊值；先標記「待確認」、指定查證人與期限，查明後記下採用的來源及更新內容。若清單有十項而有兩項尚未確認，回報應明確列出兩項及其負責人，不把整份清單稱為已完成。核對完成後保留檢查日期、參與角色、差異、處理狀態和下次檢查的觸發條件。頻率可依資產變動、付款流程及團隊交接風險設定；網域多、窗口常變的團隊可以安排更密集的核對，穩定環境也要在重大變更或人員交接後立即複查。第一次建冊時，先挑一個正式網域走完「註冊商—DNS—網站環境—備份—主責與代理」這條鏈，確認每個欄位都有可查證來源，再把格式複製到其他資產。接著選定清單保管人，排入下一次核對並指定代理，今天即可從仍在使用的官網開始填第一列。並保留未結案差異的後續日期。若你也在整理網站與工作流程的下一步，可前往 ZhenheAI 首頁 了解相關資訊。