當大家都滿分的時候，你還可以做什麼？

兩個都是滿分的網站

週五下午，兩個購物網站同時上線。兩個都跑過 Lighthouse，效能、SEO、無障礙都是 100 分；兩個都測過結帳，從加入購物車到付款完成一路順暢。如果驗收只看「能不能用、分數滿不滿、訂單下不下得了」，兩個都是滿分。

到了週六晚上，兩個網站用的同一家物流查詢 API 開始逾時。第一個網站只有訂單頁的物流狀態顯示「稍後再試」，其他照常；第二個網站每一頁都在等那個 API，連線一條條卡住，十分鐘後首頁也打不開了。再過一週，第二個網站的一個外掛被公開漏洞，攻擊者從那裡讀到設定檔，裡面那一把資料庫帳號，前台、後台、排程全都在用。

兩個網站在分數上沒有差別，差別只在出事的那一刻才看得到。它有一個名字，叫穩健性（robustness）。這個詞我們十八年前在一篇排程論文裡用過，先從那裡講起。

本篇沒有實際外洩的憑證；下表是開頭第二個網站的示意情境，用來說明一把共用的鑰匙會把影響範圍放多大。

同樣一把被讀走，如果它只屬於排程、只能讀一張表，事情就停在那張表。

一篇 2008 年的排程論文

先交代來源。2008 年 9 月，我們在《輔仁管理評論》第 15 卷第 3 期發表〈考慮資源限制與穩健性之專案排程研究〉（黃榮華、楊長林、劉士豪），本站作者是共同作者之一。這篇不是資安論文，也不是網站論文，研究的是工業工程裡一個很經典的問題：資源受限專案排程（RCPSP，resource-constrained project scheduling problem）。

問題長這樣：一個專案有幾十到上百件作業，有些必須先做完才能做下一件，有些可以同時進行；每件作業要用掉一些資源（人力、機台），而資源總量有上限。目標是排出一份最快完工的計畫。

傳統做法只追求一件事：工期最短。論文要指出的是，這樣排出來的計畫在紙上很漂亮，但現實中作業時間常常因為無法控制的因素而變長，計畫一延誤，承諾的完工日就守不住。所以我們把穩健性放進目標：不只問「最快多久做完」，也問「有作業延誤時，這份計畫還守不守得住」。

寬裕時間要彼此獨立

到這裡，其實已經足夠理解這篇的主張：計畫要比的不只是快，還有耐不耐摔。如果你關心的是怎麼套用到自己的網站，可以直接往「網站也是資源受限的系統」繼續閱讀。下面這一節講論文怎麼做，會稍微技術一些。

論文的核心觀念是寬裕時間（slack），也就是一件作業最多可以晚多久，而不影響整個專案完工。兩份工期相同的計畫，寬裕時間的分布可能完全不同。如果好幾件平行作業共用同一段寬裕，一件延誤吃掉了它，其他作業就沒有寬裕可用；如果每件作業的寬裕各自獨立，一件延誤只會用掉它自己那一份。

所以論文偏好寬裕時間比較獨立的排法。做法上，非平行作業與平行作業分開處理排序，平行作業的先後次序是動態決定的，並評估同一群平行作業裡每件作業的寬裕時間。目標函數同時看兩件事：工期，以及延誤發生時要付出的額外成本。

結果很一致：同時考慮穩健性的方法，在全部 720 組題目上都比只用傳統法則好。不是某幾題好、某幾題差，是全部。

網站也是資源受限的系統

論文研究的是工廠與工程專案，但把名詞換一換，一個網站就是同一個問題。

一個購物網站是一群零件：前台頁面、會員登入、購物車、金流、物流查詢、寄信、管理後台、每晚的排程。它們共用有限的資源：一台主機的 CPU 與記憶體、資料庫的連線數、一把雲端金鑰、一家第三方服務的額度。排程論文裡的「作業時間變長」，在網站上就是第三方服務逾時、流量突然暴增、一個外掛爆出漏洞、一把金鑰外洩。

只追求「能用」的網站，最常見的寫法是讓所有零件共用同一份餘裕：同一個資料庫帳號、同一把金鑰、同一個連線池、沒有逾時設定的第三方呼叫。平常這很省事，分數也不會扣。但它的餘裕是共用的，就像論文裡集中在最後的寬裕時間：一個零件出事吃掉了它，其他零件就跟著沒有退路。

穩健的寫法看起來沒那麼漂亮，驗收清單也比較長：

• 每個服務各自一把金鑰、一組資料庫帳號，權限只給它需要的。一把外洩，損失只有那一個服務。
• 每一個第三方呼叫都設逾時，並想好壞掉時頁面要顯示什麼。物流查詢掛了，結帳照樣能完成。
• AI、簡訊、寄信這類按量計費的金鑰設用量上限。被盜用時，帳單有天花板。
• 前台有快取，源站出問題時還能撐住瀏覽；管理後台和前台分開，後台不對外公開。
• 能接觸正式環境的人不只一位，但每個人只拿到自己那一段的權限。

這些做完，Lighthouse 不會多一分，SEO 也不會多一分。它們改變的是另一個分數：第一個零件壞掉時，壞掉的範圍有多大。

滿分之後，還可以比什麼

回到標題。現在要做出一個「能用、SEO 滿分、訂單下得了」的網站，門檻比十年前低很多：架站平台、範本、AI 寫程式，多數團隊認真做都能拿到滿分。

問題是，當大家都滿分，這個分數就分不出誰比較耐打了。真正能分出高下的，是網站在現實裡第一次被打亂的時候：第三方服務逾時、雙十一流量、外掛被公開漏洞、一把金鑰被貼到公開的地方。那一刻，一個網站是只壞一個功能，還是整站一起倒、所有資料一起被讀走，就是穩健性。

對資安來說，這個差別更大。攻擊者不挑分數最低的網站，他挑一個零件就能牽動全站的網站。功能與分數是讓客人進得來；穩健性是讓一個零件壞掉時，壞的只有那一個零件。

所以我們的建議是在每一次上線驗收時多問一題。不只問「這個功能能不能用」，也問「這個零件壞掉或外洩時，影響的是誰」。寫得出這張表，你就知道網站的脆弱點在哪；寫不出來，代表那個滿分只量到了好天氣。

這篇提到的項目要花多少錢

讓網站變穩健，多數成本是一次性的盤點與拆分人力；能比較的是「沒有隔開時，一個零件出事會拖垮多少東西」。

兩天半的人力，換的是最後一格的範圍從「整個網站」縮成「一個功能」。

你可以學到什麼

站在攻擊者的位置看：一個外掛的漏洞、一把共用的金鑰，在零件彼此綁死的網站上，就是整個網站的鑰匙。他不需要打穿每一道防線，只需要找到那個牽一髮動全身的零件。

下面四步全部唯讀，做完你會有一張「這個零件壞掉影響誰」的表。