——離線掃描器跑完之後，我發現我可能不是在接一套系統，而是在接一個資訊科技地層剖面。
一開始，我以為這是一套老系統。
後來發現這句話不太精確。
比較準確的說法應該是：
這是一群不同年代的系統，剛好都還住在同一個世界裡。
最上面一層，看得到比較新的 Web。
Go。
Angular。
HTTP API。
再往下挖一點，會碰到 VB6。
再往旁邊挖，Delphi 出現了。
接著是 ActiveX。
COM DLL。
Crystal Reports。
各種 32-bit 元件。
然後所有道路最後又很有默契地通往 SQL Server。
這時候我開始理解：
這不是「Legacy System」。
這比較像資訊科技的地質學。
Delphi 在這個世界裡，不只是某個古老畫面。
它曾經負責登入、啟動、更新，以及把使用者帶去不同的子系統。
你登入之後，它會知道：
你是誰。
你可以用什麼。
然後再去啟動另外一支程式。
很合理。
甚至還滿漂亮的。
問題是，被它啟動的程式很多不是 Delphi。
是 VB6。
所以你很快就會看到一個很有年代感、但其實頗有架構概念的模式：
Delphi
↓
登入／系統清單
↓
啟動 VB6 EXE
↓
VB6 自己再去資料庫工作
也就是說，Delphi 像一個老管家。
門還是他開的。
至於房間裡現在住誰，
他其實不太管。
繼續掃下去，你會發現 VB6 的世界非常繁榮。
不是只有一支 EXE。
是很多支。
人事。
課程。
選課。
成績。
教學評量。
教師自評。
學生相關作業。
報表。
列印 Worker。
Web COM 元件。
每一支都有自己的畫面。
自己的邏輯。
自己的 SQL。
自己的歷史。
有些還會共用一批 BAS。
有些則比較有個性：
把共用程式複製一份，帶回自己家養。
於是你會遇到：
同名函式。
不同版本。
相同功能。
略有差異。
某些完全一樣。
某些只差幾十行。
久了之後，問題已經不是：
「這個函式有沒有問題？」
而是：
「正式環境到底吃哪一份？」
這時候掃描工具就非常有用了。
因為靠眼睛找，會先失去人生方向。
時間繼續往前。
大家開始需要 Web。
於是新的產品線出現。
Go。
Angular。
API。
新的登入方式。
新的功能模組。
看起來像是：
「太好了，開始現代化了。」
然後你再往下看。
會發現新的 Go API 很努力地去讀以前的資料。
有些地方甚至直接碰原本 Legacy 系統使用的資料表。
所以這不是：
舊系統
↓
下線
↓
新系統
而比較像：
舊系統 ────────┐
│
├── SQL Server
│
新系統 ────────┘
兩代人住在一起。
有時還會同時改同一批資料。
這時候你就會開始理解：
現代化不一定代表替換。
有時候只是多蓋一層。
再從網站層看。
外面看起來可能只是：
一台 Web Server。
一個 IIS。
幾個站台。
很單純。
但等到開始盤點連線設定，你會發現：
這個應用連這個 DB。
另外一個應用又連另一個 DB。
新的模組再開自己的資料庫。
某些還共用舊資料。
某些則自己建立新的 table。
於是從遠方看：
「我們就是一套校務系統。」
走進機房之後：
「請問哪一套？」
這就像一棟外觀看起來只有一個門牌的公寓。
你進去才發現：
一樓住 Delphi。
二樓住 VB6。
三樓是 Go。
四樓 Angular 雖然不直接住在這裡，但每天都來。
地下室是 SQL Server。
而且地下室裡不是一間房。
是很多間。
每戶都有自己的鑰匙。
有些住戶彼此認識。
有些只知道隔壁「好像有資料可以拿」。
程式碼掃到一個程度之後，你會發現最有趣的地方其實不在程式。
在 SQL Server。
因為不同年代的系統，最後都會留下痕跡：
資料表。
Stored Procedure。
View。
Trigger。
跨資料庫查詢。
不同業務資料庫。
不同身份系統使用的資料域。
某些新的 Web 模組有自己獨立的資料庫。
某些 Legacy 模組繼續使用舊的資料域。
某些地方又跨回核心學生、課程、人事資料。
所以你以為是在盤點「幾套程式」。
後來發現更重要的問題是：
到底有多少資料世界？
這才是離線盤點不能只掃副檔名的原因。
如果工具最後只告訴你：
VB6：600 個檔
Delphi：50 個檔
Go：172 個檔
TypeScript：361 個檔
這只是統計。
很好看。
沒有解決問題。
真正需要的是：
誰連哪個資料庫？
誰讀哪些表？
誰寫哪些表？
誰呼叫哪些 Stored Procedure？
哪幾套系統碰到同一份資料？
哪些只有 EXE 沒有完整 Source？
哪些 Source 找得到，但不知道是不是正式版本？
這才開始叫盤點。
離線掃描器負責把這些東西整理出來。
來源檔。
執行檔。
元件。
設定。
資料庫存取。
SQL。
相依關係。
可能的敏感設定。
缺 Source 的 Binary。
重複版本。
前端。
後端。
資料庫。
再把盤點結果交給 AI 做關係分析、比對和分類。
然後 AI 很熱心。
它會告訴你：
這裡有一個。
那裡也有。
旁邊那個可能同源。
另外五十個看起來像相同問題。
最後假設累積成三千條。
非常壯觀。
這時候第一個真正有治理價值的問題不是：
「三千個怎麼修？」
而是：
這三千個東西，到底分屬哪幾個年代、哪幾套系統、哪幾個資料世界？
因為一個 VB6 檔裡出現的問題，
和正式 Go API 裡正在跑的問題，
意義不一樣。
一個二十年前但仍由正式 EXE 使用的問題，
和一份從未被正式 VBP 引用的歷史 Form，
也不能放在同一格。
SQL Server 裡正在被三套系統共同使用的 Stored Procedure，
和一份古老 SQL 範例，
更不能只因為都叫 .sql 就一起算。
這也是為什麼 AI 可以協助分析，
但不能讓它看見紅字就直接開三千張工單。
最後離線工具真正做的事情，不是找出三千個「漏洞」。
它建立的是：
一張足以讓 AI 和人一起繼續考古的證據地圖。
Delphi 在哪。
VB6 哪幾套。
Go 哪些領域。
Angular 哪些前端。
IIS 承載哪些入口。
SQL Server 底下有哪些資料域。
哪些模組共用資料。
哪些開始自己另外長資料庫。
哪些只剩執行檔。
哪些有 Source。
哪些 Source 還有好幾份。
這張圖出現之後，
「三千個問題」才第一次有上下文。
不然三千只是個很適合放簡報首頁的數字。
所以 AI 說有三千個問題。
很好。
我比較想知道的是：
第一千七百四十二個，是 Delphi 的祖產、VB6 的現役部隊、Go 的新居民，還是 SQL Server 地下街裡一間沒有人承認自己負責的店？
搞清楚這件事情之後，
我們才有資格討論：
然後呢？
這台資訊安全奇聞車，
現在才剛從停車場開出來。
iThome鐵人賽
看影片追技術