三千個問題排好隊之後，誰先去急診？

——Delphi、VB6、Go、Angular 都說別看我，真正需要先看的可能在 SQL Server 地下室。

上一篇我們終於把這個世界稍微畫出來。

Delphi。

VB6。

Go。

Angular。

IIS。

ActiveX。

COM。

SQL Server。

不同年代。

不同程式。

不同資料庫。

不同資料表。

其中一些彼此相依。

另外一些彼此相依到本人都不知道。

然後掃描結果告訴我們：

這裡有很多值得處理的事情。

很好。

下一個問題：

先動哪一個？

如果是單純的新系統，這個問題可能比較簡單。

看風險。

看嚴重度。

看暴露面。

排修。

但是 Legacy 世界不太合作。

因為你可能找到一個很老的 VB6 問題。

表面看來超級古老。

照理說：

先淘汰。

結果一追才發現：

這支 VB6 每天還在改正式資料。

另外一個 Go API 看起來很新。

你以為它一定比較核心。

結果它只是某個特定流程的 Web 入口。

再往下查，真正決定能不能做這件事的規則：

在 SQL Server Stored Procedure 裡。

這時候 CVSS 沒辦法告訴你：

誰才是這個家的家長。

技術年份，不等於處理優先順序

這是一個很容易踩的坑。

看到 Delphi：

老。

看到 VB6：

更想換。

看到 Go：

新。

看到 Angular：

現代。

如果直接照這個順序判斷，很快就會出事。

因為架構裡真正重要的是：

誰產生資料。

誰修改資料。

誰只是顯示。

誰是入口。

誰是規則。

誰是下游。

例如某個 Angular 畫面看起來是「新系統」。

但它只是畫面。

後面呼叫 Go。

Go 再查 SQL Server。

SQL Server 裡的資料，其實還是由 VB6 建立。

那到底哪一套才算主系統？

答案通常不是一個名稱。

而是一條鏈。

所以我們開始看 Producer、Governor、Consumer

這幾個字沒什麼喜感。

但用來救命很好用。

誰產生資料？

Producer。

誰真正治理狀態？

Governor。

誰只是拿來用？

Consumer。

舉個抽象版的例子：

VB6
建立正式資料
↓
SQL Server
保存＋執行規則
↓
Go API
讀取
↓
Angular
顯示

如果只看畫面，

你會以為 Angular 是系統。

如果只看 API，

你會以為 Go 是系統。

如果看業務生命週期，

才會發現真正的核心可能還藏在 VB6＋SQL Server。

這就是系統考古很好玩的地方。

每一層都沒說謊。

只是每一層只知道自己那一段。

然後資料庫開始舉手

程式盤點做到一定程度之後，SQL Server 會慢慢從背景走到舞台正中央。

因為大家都在碰它。

某個系統有自己的 DB。

另外一個 Web 模組又有另一個 DB。

身份相關又是一套資料域。

招生、學生、人事、核心校務各自都有自己的歷史。

甚至同一個 IIS 裡，不同應用程式使用不同資料庫。

外面看：

一個站。

裡面看：

聯邦制。

而且每一州都有自己的法律。

有時還會跨州辦案。

這時候你會發現，真正值得優先處理的，不一定是最多紅字的程式。

可能是：

一個被多套系統共同依賴的資料庫帳號。

一個控制大量資料狀態的 Stored Procedure。

一個所有舊系統都信任的身份入口。

一個只有 Binary、沒有完整 Source，但仍在正式運作的程式。

或者某個大家一直以為只是外掛，實際上每天都在寫正式資料的模組。

這些東西通常不會在「問題數量排行榜」第一名。

但只要它倒，

故事就會突然非常有戲劇性。

AI 在這裡開始比較像助理，不像法官

這時候 AI 最有價值的不是說：

「這裡 High Risk。」

而是幫忙回答：

這個 VB6 模組跟哪幾張表有關？

這個 Go API 是否也碰同一批表？

這個 Delphi 啟動器到底啟動哪些程式？

這幾個同名 BAS 是不是同一版本？

這個 EXE 找不找得到對應 Source？

這些 SQL Server 資料域之間有沒有跨庫存取？

哪些東西其實是同一個風險家族？

它幫忙把證據串起來。

最後排序仍然回到治理。

真正的優先級開始長成另外一種樣子

我們不再只問：

「這問題有多嚴重？」

而是一起問：

「它現在有沒有在用？」

「它碰不碰正式資料？」

「有幾套系統依賴？」

「能不能回復？」

「有沒有替代方案？」

「Source 完不完整？」

「如果現在改，會不會讓另一個年代的系統先倒？」

這時候一個看似普通的問題，

可能突然被往前拉。

另一個看起來很嚇人的問題，

則先留在歷史證據區。

不是忽略。

是知道它現在屬於哪裡。

最後我們不是得到一張修復清單

而是一張處理地圖。

有些直接修。

有些先隔離。

有些先限權。

有些先把 Secret 移出程式。

有些要先取得完整 Source。

有些要先把 SQL Server Schema、Stored Procedure 和依賴補齊。

有些系統準備退場。

有些現在不能退。

有些看起來是 Legacy，

但仍然是正式 Source of Truth 的一部分。

這才叫治理。

治理不是看到老東西就砍。

也不是看到新東西就信。

而是知道：

它現在到底負責什麼。

三千個問題最後並沒有排成三千張工單。

它們開始依照技術、系統、資料域、依賴關係和實際影響重新聚合。

Delphi 的歸 Delphi。

VB6 的歸 VB6。

Go 的歸 Go。

Angular 的歸前端。

SQL Server 的……

不好意思，

SQL Server 說：

「你們很多人的問題最後還是要來找我。」

這大概就是整個考古過程最有趣的地方。

大家以為自己在整理程式。

整理到最後，

發現真正需要整理的是：

四十年來，這些程式彼此相信了什麼。

這台奇聞車今天終於進了急診。

醫生看了一眼病歷，

第一句不是：

「先換引擎。」

而是：

「請問這台車到底有幾任車主？」