接手了沒有原始碼也沒有規格書的系統 ── 不停機維運的實務步驟

「開發的公司已經不存在了」「當初製作的負責人已離職，聯絡不上」「伺服器裡雖然有執行檔和資料庫，卻找不到原始碼，也找不到規格書」── 這是中小企業業務系統諮詢中，絕不罕見的狀況。即便如此，系統今天依然在運作，業務也仍然依賴著它。

在這種狀態下，最糟糕的選擇就是因為「不太清楚」而開始摸索式的改版，或憑想法擅自變更環境。沒有原始碼的系統，一旦壞掉，並不保證能夠修好。另一方面，一開始就斷言「什麼都做不了，只能全面重建」，也是操之過急。即使沒有規格書，也有復原規格的方法；即使沒有原始碼，也有可能讀懂內容。本文將依實務上的先後順序，整理從一無所有的狀態到成立維運・維護的整套步驟。

1. 先講結論

• 最先該做的不是改版，而是「現狀的保全」。正在運作的正式環境本身就是最重要的資產。取得磁碟映像備份（例如以 Disk2vhd 進行虛擬機器化）與資料庫備份，並確認到能夠復原為止，才進入下一步。¹
• 即使沒有規格書，規格也能夠復原。主要的材料是對業務使用者的訪談、畫面・報表、資料庫結構描述、日誌，以及透過 Process Monitor 觀察的實際行為。²
• 原始碼的可復原程度，會因技術堆疊而大不相同。若是 .NET 製作，用 ILSpy 等反編譯器可以讀懂相當多的內容；另一方面，VB6 或 C++ 等原生程式碼，現實中並不能期待能夠復原。³⁴
• 反編譯存在法律上的爭議點。根據著作權法第30條之4，以調查解析為目的的利用原則上被視為允許，但仍必須確認合約（使用授權條款）。⁵
• 不要等到「完全理解之後」才行動。優先掌握「一旦停止就會使業務停擺」的部分，以及「近期就需要變更」的部分，變更則以小步且可回復的方式，一項一項地進行。
• 維護合約以準委任為基本原則。對於內容不明的系統進行調查，無法承諾完成責任（承攬）。應將調查階段與改版階段分開簽約。

本文依照實務上的執行順序構成。整體樣貌如下所示。

flowchart TD
    A["第3章 保全<br/>凍結變更・磁碟映像<br/>資料庫備份與復原確認"] --> B["第3章 盤點<br/>執行檔・自動啟動・工作<br/>設定・對接對象・帳號"]
    B --> C["第4章 規格復原<br/>訪談・畫面與報表<br/>資料庫結構描述・實際行為觀測"]
    C --> D["第5章 技術可行性<br/>技術堆疊評估<br/>反編譯與法律確認"]
    D --> E["第6章 方針決定<br/>延命・包裝・部分重建・全面重建"]
    E --> F["第7章 維運轉移<br/>驗證環境・變更台帳・監控・合約"]
    C -.->|"復原後的規格台帳<br/>無論選擇哪種方針都會成為資產"| E

圖1：交接的整體流程與對應章節

各工程所需的時間，會因系統規模（畫面・報表・批次處理的數量）、技術堆疊、業務端能撥出多少時間接受訪談，以及「了解到什麼程度才算足夠」的目標設定而有很大差異，因此在著手前無法設定統一的估算標準。提高估算精確度的唯一捷徑，就是先完成第3章的盤點、數出對象的數量。在數量出爐之前，無法估算規格復原所需的期間。反過來說，盤點是應該在短期間內結束的工程，若在此拖延，之後的所有計畫都將無從擬定。

2. 為何會產生「一無所有」的狀態

在思考對策之前，先確認自家公司屬於哪一種模式，有助於推測還留有哪些線索。

最後這種模式容易被忽略，但實質上必須以與「沒有原始碼」相同的方式來處理。以舊原始碼為準進行改版，結果發現正式環境的執行檔其實已被加入了數年份的修改，這是典型的失敗案例。即便找到了原始碼，在建置並與正式環境的執行檔比對確認之前，也請不要輕易信任它。

無論是哪一種模式，先尋找合約書・交付單・驗收單都是有價值的。若上面寫明了著作權的歸屬或原始碼的交付義務，就能成為之後交涉與法律整理的基礎。

3. 最初一週該做的事 ── 現狀的保全與盤點

3.1 凍結變更

在調查結束之前，原則上不對目標伺服器・終端進行任何動作。「先更新一下作業系統吧」「整理一下看起來沒在用的檔案吧」這類舉動可能會是致命傷。因為既然沒有原始碼，一旦壞掉就沒有「修好」這個選項。也應考慮將更新的套用時機納入管理，以避免自動更新（Windows Update、防毒軟體的行為變更）擅自改變環境。

3.2 備份 ── 將環境本身複製為資產

光靠檔案層級的備份並不足夠。這類系統的作業系統設定・登錄檔・執行環境・部署位置，全部都有可能是「能夠運作的理由」的一部分，因此要保全整個磁碟映像。

實務上常用的是 Sysinternals 的Disk2vhd。它可以讓運作中的系統保持連線狀態，透過 Windows 的磁碟區快照功能（VSS：Volume Shadow Copy Service，磁碟區陰影複製服務）轉換成某一時間點具有一致性的 VHD/VHDX，成為在 Hyper-V 上以虛擬機器啟動之驗證環境的基礎。¹ 好處是能夠同時推進實體伺服器的老舊化對策與驗證環境的確保（另外，OEM 授權的 Windows 有時在授權上不允許遷移至虛擬環境，因此需要確認授權形式¹）。

Disk2vhd 是只有一個畫面的簡單工具，但一旦選錯，就會做出「無法啟動的映像」。請依下列順序進行。¹

1. 準備輸出目的地。VHD/VHDX 雖然也能建立在轉換對象的磁碟區上，但官方文件也明確指出，輸出到與對象不同的磁碟（外接硬碟或 NAS 等）性能較好。可用容量請預留至少等同於所選磁碟區已使用空間總和的大小。
2. 確認 BitLocker。Disk2vhd 不支援轉換已啟用 BitLocker 的磁碟區。若為此情況，需事先解除 BitLocker，等待解密完成後再執行。
3. 選擇要納入的磁碟區。在系統保持啟動的狀態下執行工具，會顯示該系統的磁碟區清單。此處所選磁碟區所在的每一個磁碟都會產生一個 VHD，分割區結構會被保留，但只有所選磁碟區的內容會被複製。因此，若想要能夠驗證啟動，就必須同時選擇 Windows 所在的磁碟區（通常是 C:），以及啟動所需的系統分割區（系統保留區／EFI 系統分割區）。若排除純資料用的磁碟區，就能節省相應的容量與時間。
4. 視需要以命令列執行。若想在夜間執行，可以用 disk2vhd <磁碟機:> [磁碟機:] ... <輸出檔案> 的形式寫成腳本。若要以全部磁碟區為對象，則像 disk2vhd * e:\backup\snapshot.vhdx 這樣指定 *。
5. 驗證啟動請在 Hyper-V 上進行。在 Hyper-V 管理員中建立虛擬機器，將產生的 VHD 以 IDE 磁碟的形式加入組態。首次啟動時，Windows 會偵測虛擬機器的硬體，若映像內含有驅動程式便會自動安裝；若沒有，則安裝 Hyper-V 的整合元件。
6. 不要掛載在建立來源的機器上啟動。若在同一系統上掛載 VHD，Windows 為避免與原始磁碟的簽章衝突，會為該 VHD 指派新的磁碟簽章。由於啟動組態資料（BCD）是以磁碟簽章來參照磁碟，在這種狀態下啟動虛擬機器，會因找不到啟動磁碟而失敗。驗證啟動請務必在另一台機器（Hyper-V 主機）上進行。

同時，資料庫請以 DBMS 標準的方式取得備份。而最重要的一點是，要實際從備份復原並確認能夠啟動。沒有做過復原測試的備份，只不過是一份自以為存在的保險。不過，復原後的映像中仍原封不動地保留著正式環境的連線設定與排程工作，因此啟動確認務必在與網路隔離的狀態下進行（詳見第7章）。若不小心在保持連線的狀態下啟動，原本打算用來驗證的環境就會更新到正式環境的資料庫或對接對象。

3.3 盤點 ── 將正在運作的內容製成清單

接著，機械式地列出系統的構成要素。這項工作靠的不是敏銳度，而是全面性。

若「不知道設定檔或輸出目的地在哪裡」，用 Process Monitor 觀測處理序的檔案・登錄檔存取是最快的方法。應用程式實際讀寫的路徑會直接呈現為清單。²

4. 即使沒有規格書，規格也能夠復原

透過盤點了解「有什麼」之後，接下來就是復原「在做什麼」。材料已經齊全。

• 對業務使用者的訪談 ── 最大的規格書，就在每天使用該系統的人的腦中。沿著日常・月度・年度的業務流程，訪談在哪個畫面輸入什麼，會產生什麼結果。特別是年度處理（結算、盤點、年度更新）連負責人自己都可能忘記，是交接後首次執行時最容易出事故的環節。
• 畫面與報表 ── 用截圖與實物樣本，將所有畫面・所有報表製成台帳。光是輸入項目與輸出項目的對應關係，就能相當程度看清處理的骨架。
• 資料庫結構描述與資料 ── 資料表定義、限制、代碼值的實際資料，是業務規則的化石。「這個旗標的值只用到3種」之類的觀察，會告訴你畫面上看不出來的規格。
• 日誌與事件日誌 ── 若有應用程式自有的日誌，可讀出處理流程；從 Windows 事件日誌則能看出過去的錯誤傾向。
• 實際行為的觀測 ── 用 Process Monitor 記錄檔案・登錄檔・網路的存取，就能在沒有原始碼的情況下，佐證「月底這項處理，讀取的是這個共用資料夾裡的 CSV，並與這台資料庫伺服器通訊」這樣的輸入輸出對應關係。² 不過 Process Monitor 只能得知到通訊對象為止，看不出哪個資料表被如何更新。再往下就要靠 DBMS 端的追蹤・稽核功能（如 SQL Server 的擴充事件等），或是在處理前後比對資料庫內容的方式來鎖定。

這裡重要的是，不要企圖均等地將全部功能文件化。目的不是百科全書，而是維運的延續，因此應優先處理「一旦停止業務就會停擺的處理」「發生錯誤的處理」「近期需要變更的部分」，將調查過的範圍逐步累積到台帳中。

訪談的型式 ── 對誰、問什麼、怎麼記錄

「詢問使用者」說起來簡單，但若不先決定好詢問的對象與問題，最後只會變成閒聊。實務上，分成以下3個層級，各自撥出不同的時間，才是確實的做法。

問題每次都沿用相同的項目。以下這10個問題可作為基礎，跨系統也能通用。

1. 在這套系統上，每天一定會執行的操作是什麼？大約在什麼時間、大約幾件？
2. 有沒有只在月度・年度才做的操作（結帳處理、結算、盤點、年度更新等）？上一次是什麼時候、由誰執行的？
3. 輸入所依據的紙本・檔案・郵件是什麼？來自哪裡？
4. 這套系統會輸出的東西（報表、CSV、向外部發送）是什麼？之後會傳到哪裡？
5. 系統一旦停止，業務最多能撐幾個小時？屆時能不能用人工方式代替？
6. 有沒有「唯獨這個操作絕對不能做」的口耳相傳？知道原因嗎？
7. 目前有沒有靠人工彌補的部分（謄寫、用 Excel 重新彙總、目視檢查等）？
8. 最近1年內有沒有發生過錯誤或問題？當時是如何處理的？
9. 有哪些畫面・功能是沒在使用的？從什麼時候開始不用的？
10. 如果可以修改，最傷腦筋的事情是什麼？

記錄方式也要事先決定好。要點在於，將回答與畫面名稱・報表名稱・資料表名稱等專有名詞連結起來留存，若能細化到「從月次銷售彙總畫面（F050）列印銷售月報」這種粒度，而不是只寫「月底彙總」，就能與第3章的盤點表以及之後的資料庫調查相互比對。若可行請進行錄音，現場則專注於記錄專有名詞與操作順序。問題5的回答，會用於第6章的方針判斷；問題6與7的回答，則是隱藏規格所在位置的線索。

5. 沒有原始碼時，技術上能做到什麼

「讀懂內容」能夠期待到什麼程度，幾乎取決於系統是用什麼技術製作的。請先從執行檔的內容屬性或 DLL 組成推測技術堆疊，再設定期待值。

首先，先簡短定義本章會用到的術語。

以一般 IL 格式部署的 .NET 應用程式，情況相當不錯，反編譯得到的 C# 程式碼，對於理解處理內容而言已足夠實用。不過正如官方文件也明確指出的，註解・區域變數名稱・空白等編譯時不需要的資訊會遺失，因此應將其定位為「用來理解動作的資料」，而非原始碼的替代品。³ 但也有例外。若施加了混淆處理（obfuscation），解讀難度會大幅提高；而以 Native AOT 發行的二進位檔案不含 IL，因此「因為是 .NET 製作所以能讀懂」的期待並不成立。Native AOT 是 .NET 7 中導入的發行方式，官方文件也明確寫明「在發行的時間點，事前編譯器就會將 IL 編譯為原生程式碼」「Native AOT 應用程式在執行時不使用 JIT 編譯器」。⁷ 也就是說，反編譯器所要讀取的對象本身並不會保留在成品中。在評估技術堆疊時，請不只確認開發語言，連部署形式也一併確認。

若執行檔旁邊還留有 PDB（符號檔），有時甚至能復原函式名稱，以及（若有內嵌原始碼的話）原始碼本身。其中包含什麼內容、能夠期待什麼，已在「PDB（程式資料庫）是什麼」中整理。

法律上的注意事項 ── 反編譯要「先調查後行動」

技術上做得到的事，與可以做的事是兩回事。包含反編譯在內的逆向工程，存在著作權法上的爭議點，根據平成30年（2018年）修正時新增的著作權法第30條之4（不以享受著作物所表現之思想或感情為目的之利用），以程式的調查解析為目的的重製・改作，在被認定為必要的限度內，原則上被視為允許。不過條文中有「若對著作權人利益造成不當損害，則不在此限」的但書，例如利用解析結果來製作競爭產品的情況，就可能得到不同的評價。⁵

此外，若套裝軟體或交付物的使用授權合約中包含禁止解析的條款，該如何看待其效力，也仍是合約上的爭議點。實施前，請確認對象軟體的授權條款，以及當時的開發委託合約（著作權歸屬條款），若有疑慮，請諮詢律師。若交付物的著作權歸屬於自家公司，這個問題就會大幅簡化。關於合約書的閱讀方式，也可以參考「委託開發‧維運的合約該怎麼簽？」。

法律論述本身屬於專家的領域，但在諮詢之前，公司內部應先蒐集好的材料是固定的。先把以下項目填好，判斷就會更快。

6. 延命、包裝，還是重建

在調查中獲得的理解程度與業務端的情況齊備之後，就要決定方針。這裡同樣不應以「全面重建為前提」或「原封不動放著為前提」，而是用判斷表來整理。

判斷的軸心有4個：剩餘使用年數、變更需求的頻率與偏向、停止時的業務影響，以及調查中所能復原的理解程度。若在理解程度偏低的狀態下就進入全面重建，會遺漏舊系統中「沒有人能說明、但在業務上卻是正確」的行為。即便選擇重建，第4章復原的規格台帳也能直接作為需求定義的基礎，因此對調查的投資不會白費。遷移時，讓新舊系統並行運作一段期間，以機械化的方式比對相同輸入所產生的輸出（報表・彙總・檔案），是標準做法。

另外，VB6 或 Access 等具體技術各自的延命・遷移判斷，已在「VB6 / Access 業務應用程式的延命與遷移」中詳細討論；公司內部 Web 系統對 IE 模式的依賴，則在「擺脫 IE 模式依賴系統的實務指南」中詳細討論。

7. 交接後的維運・維護體制

若方針是「暫時繼續維運」（實際上大多數情況都是如此），遵守以下型式可以減少事故。

• 擁有驗證環境 ── 但首次啟動務必與網路隔離 ── 將3.2製作的磁碟映像作為虛擬機器啟動，就會成為與正式環境相同組態的驗證環境。不過這份映像中原封不動地保留著正式環境的連線字串・驗證資訊・排程工作・自動啟動服務。若在保持連線的狀態下啟動，可能會導致夜間批次重複執行而更新正式資料庫、郵件被重複發送，或呼叫外部 API。首次啟動務必移除虛擬 NIC 或在隔離網路中進行，先停止排程工作與自動啟動服務，將連線目標改寫為驗證用之後，才只允許必要範圍內的連線。
• 變更一次一項，並可回復 ── 無論是設定變更，還是套用 Windows Update，一次只做一項。保留變更前的映像，一旦出現問題就能切回。並將變更了什麼的記錄（變更台帳）一併配套留存。
• 將文件當作「調查所得的副產物」逐步累積 ── 不要另外成立撰寫完美規格書的專案，而是每次故障應對或改版時，將了解到的內容追加到台帳中。只要維運上一年，文件就會依業務上重要程度依序齊備。
• 佈建監控 ── 存活監控、磁碟剩餘空間、錯誤日誌，以及「平常應該輸出的檔案沒有輸出」的偵測。即使看不見黑箱內部，也能監控入口與出口。
• 合約應將調查與改版分開 ── 若委託外部進行維護，由於對內容不明的系統進行調查無法承諾完成責任，因此調查・維護採準委任，規格已確定的個別改版採承攬（或成果完成型準委任），依階段分開簽約才是健全的做法。

8. 總結

• 接手了沒有原始碼、也沒有規格書的系統時，在改版之前，首先要做的是現狀的保全。取得磁碟映像（Disk2vhd 等）與資料庫的備份，並確認能夠復原。
• 對執行檔・自動啟動・排程工作・設定・對接對象・帳號進行盤點，將系統的整體樣貌製成清單。
• 規格可以從使用者訪談・畫面・報表・資料庫結構描述・日誌・Process Monitor 的實際行為觀測中復原。不是全部功能，而是優先處理業務影響較大的部分。
• 內容的可復原程度取決於技術堆疊。.NET 用反編譯可以讀懂相當多內容，但並非原始碼的替代品。實施前請確認著作權法第30條之4的宗旨，以及授權條款・合約書。
• 方針上，依剩餘使用年數・變更頻率・業務影響・理解程度判斷「延命・包裝・部分重建・全面重建」。調查中復原的規格，無論選擇哪條路都會成為資產。
• 在維運階段，驗證環境・一次一項的變更・變更台帳・入口與出口的監控・以準委任簽約是基本型式。

相關文章

• PDB（程式資料庫）是什麼 ── 理解偵錯資訊、符號與 Source Link
• Process Monitor(ProcMon)實戰指南 ── 在10分鐘內找出「設定未被讀取」「ACCESS DENIED」的原因
• VB6 / Access 業務應用程式的延命與遷移 ── 保留・包裝・取代的判斷表
• 擺脫 IE 模式依賴系統的實務指南
• 委託開發‧維運的合約該怎麼簽？── 從 IPA《模型交易‧合約書》學習準委任與承攬的區分使用
• 委外・委託開發 Windows 應用程式前該整理的事項

相關諮詢領域

合同會社小村軟體承接沒有留下原始碼或規格書之業務系統的現狀調查（執行檔・資料庫・實際行為的解析）、從行為復原規格、延命・遷移方針的整理，以及之後的維運・維護。即使是還處在「不知道該從何處著手」階段的諮詢，也歡迎洽詢。

• 既有資產活用・遷移支援
• 既有 Windows 軟體的改修・維護
• 缺陷調查・原因分析
• 技術諮詢・設計審查
• 聯絡我們

參考連結

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

常見問題

整理諮詢這個主題時常見的問題。

沒有原始碼的系統，也能委託維護或改版嗎？

可以委託。不過進行方式會與一般的維護不同。首先要對現行環境進行保全與備份，接著設置一個調查階段，從畫面・報表・資料庫・日誌・執行檔的解析中復原規格，再依當時所理解的範圍推進改版或周邊功能的開發，這才是務實的做法。由於調查工作在事前無法保證成果，因此一般會以不負擔完成責任的準委任契約來進行，而非承攬契約。

反編譯（逆向工程）執行檔，難道不違法嗎？

並非一律違法。根據平成30年（2018年）修正的著作權法所新增的第30條之4，像程式調查解析這類「不以享受著作物所表現之思想或感情為目的之利用」，在被認定為必要的限度內，原則上被視為允許。不過，「將對著作權人利益造成不當損害之情形」則被排除在外，另外，若使用授權合約中禁止解析，該如何處理也仍是一個爭議點。實際執行前，請先確認授權條款以及當初委託開發時的合約書，若判斷有困難，請諮詢律師等專業人士。

開發公司已倒閉，無法取得原始碼，該怎麼辦？

請先確認過去的合約書與交付物。若開發委託合約中明訂了著作權或原始碼的歸屬・交付方式，這便可作為取得與使用的依據。若還能聯絡上相關人員，也值得嘗試交涉取得的可能性。不過在實務上，重要的是不要停在「終究還是拿不到」這一步，建議在假設無法取得的前提下，同時展開現行環境的保全・備份，以及從行為與資料庫進行的規格復原。

沒有規格書的系統，該從何處著手？

在改版之前，首先要做的是現狀的保全。取得正在運作的正式環境的磁碟映像與資料庫備份，並確認能夠復原。接著對執行檔・自動啟動項目・排程工作・設定・對接對象・帳號進行盤點，將系統的整體樣貌製成清單。在此基礎上，透過對業務使用者的訪談，以及對畫面・報表・資料庫結構描述的觀察，聚焦在業務上重要的部分逐步將規格文件化，這是標準做法。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。