軟體軟體永續：為什麼維護週期
二、軟體為什麼會「老化」：維護週期的真正壓力來源
軟體不會生鏽，但它會老化。老化的原因不是時間本身，而是環境變了、需求變了、人變了，而軟體沒有跟著變。維護週期之所以重要，是因為它是對抗老化的唯一機制。以下三個壓力來源，是幾乎所有軟體都會面臨的結構性問題。
技術債會複利，不會自然消失
技術債（technical debt）這個比喻很傳神：為了趕上線而做出的妥協，就像借錢；利息就是未來每次修改都要多花的成本。問題在於，技術債的利息是複利的。一個沒有寫測試的模組，第一次修改可能只多花半天；兩年後同一個模組被十個功能依賴，修改成本可能變成兩週，而且沒人敢動。當技術債累積到某個程度，維護團隊會進入「只能救火、無法改善」的模式，維護週期於是被動地越拉越長。
健康的維護週期，本質上就是持續償還技術債的節奏。這不代表每次更新都要大翻修，而是要有計畫地把「未來會爆炸的東西」提前處理：補測試、拆模組、淘汰舊相依、更新文件。這些工作不會出現在功能列表上，卻是軟體能不能活過下一個十年的分水嶺。
依賴鏈與生態系的隱形風險
現代軟體很少是孤島。一套工具可能依賴數十個開源套件、雲端服務、憑證機構與作業系統 API。這些相依元件各自有維護週期，任何一個環節停止更新，都可能把風險傳導到最終產品。近年層出不窮的供應鏈攻擊，正是利用這種「維護落差」：攻擊者針對已經停止維護、卻仍被大量引用的套件下手。
因此，評估一套軟體的維護週期時，不能只看它自己的更新頻率，還要看它對相依元件的管理態度。有沒有軟體物料清單（SBOM）？有沒有定期掃描已知漏洞？重大相依升級是否會主動公告？這些問題聽起來很技術，但它們決定了你使用的軟體會不會在某天突然被一個你從沒聽過的套件拖下水。
人員流動與知識斷層
軟體是人寫的，也是人維護的。專案經理換人、核心工程師離職、原廠被收購，這些組織變動對維護週期的衝擊往往比技術問題更大。很多產品不是「做不下去」，而是「沒人記得為什麼這樣做」。當知識只存在少數人腦中，維護就變成高風險行為：沒人敢改、沒人敢升級、沒人敢承諾時程。
這也解釋了為什麼有些產品在推出時聲勢浩大，兩三年後卻更新遲緩。與其說是技術衰退，不如說是知識沒有被制度化的保存。對使用者而言，這是一個很難從外部觀察、卻極度重要的風險因子。評測時若能留意原廠團隊的穩定性、文件完整度與社群活躍度，就能提前看到這個風險。
三、維護週期的四種型態：從救火到演進
維護週期不是單一數字，而是一組節奏的組合。不同類型的維護工作，對應不同的觸發條件與時間尺度。理解這些型態，有助於我們判斷一套軟體的維護是「有計畫的演進」還是「被動的救火」。
反應式維護：出事了才處理的代價
反應式維護（corrective maintenance）是指問題發生後才進行的修補，包括 bug 修正、當機排除、安全漏洞應急處理。這是所有軟體都無法避免的一環，但如果一套軟體的維護幾乎只有反應式，那就是警訊。反應式維護的成本最高、可預測性最低，而且容易打亂團隊節奏。更糟的是，長期救火會擠壓改善與預防的時間，讓技術債繼續累積，形成閉環。
評測時可以觀察：更新日誌是否只在出事後才發布？重大漏洞的平均修補時間是幾天、幾週還是幾個月？有沒有事後檢討報告（postmortem）？這些訊號能反映一套產品的維護是「有餘裕」還是「永遠在補破網」。
預防式與適應式維護：把問題擋在門外
預防式維護（preventive maintenance）是主動降低未來故障機率，例如重構、補測試、更新文件、淘汰老舊相依。適應式維護（adaptive maintenance）則是因應環境變化所做的調整，例如支援新版作業系統、配合法規調整資料處理流程、因應雲端平台 API 變更。這兩類維護不會產生新功能，卻是大規模系統能長期運作的關鍵。
健康的維護週期通常會把這兩類工作排進固定節奏：每季一次相依更新、每半年一次安全性檢視、每年一次架構回顧。這些安排不一定會公告給使用者，但會反映在產品「遇到環境變化時的反應速度」上。當作業系統改版，一套軟體是兩週內推出相容更新，還是三個月後才叫使用者「先不要升級」，就是預防式維護做得好不好的直接證據。
長期支援（LTS）與版本節奏的設計
長期支援（Long Term Support，LTS）是近年軟體永續的重要機制。它的概念是：在固定期間內，針對特定版本提供安全更新與重大修正，讓使用者不必頻繁升級也能維持安全。LTS 的價值在於把「維護」從不確定的承諾，變成可預期的週期。對企業與公部門來說，這種可預期性甚至比功能更重要，因為它直接影響預算編列與稽核準備。
不過，LTS 也有陷阱。有些廠商把 LTS 當成行銷詞彙，實際上只提供極有限的修補；有些產品雖然標榜 LTS，卻沒有公開的支援終止日期（EOL date），讓使用者無法規劃退場。評測時應確認：LTS 的支援年限是幾年？涵蓋哪些類型的更新？終止支援前是否有提前公告與遷移指引？這些細節比「有 LTS」三個字更有意義。
四、維護週期為何總被忽略：預算、文化與評測盲點
既然維護週期這麼重要，為什麼市場上還是普遍重功能、輕維護？這不是單一因素造成的，而是預算結構、組織文化與評測慣性共同作用的結果。
成本錯覺：維護費看起來像「沒有產出」
維護工作的特性是「沒出事就看不見」。功能開發有明確交付物，維護則是把「本來可能發生的災難」擋掉，兩者在預算會議上的說服力天差地遠。這導致一個普遍現象：維護預算被視為可壓縮的間接成本，直到某次重大事故發生，才臨時追加預算救火。長期下來，組織陷入「省小錢、賠大錢」的循環。
對軟體評測而言，這種成本錯覺也會傳染。我們容易比較「授權費誰便宜」、「功能誰多」，卻很少把「未來三年的維護成本」與「停止維護後的遷移成本」放進同一張表。如果評測只反映採購當下的價格，就會系統性地鼓勵廠商把資源投向功能，而非維護。
功能優先的開發文化
多數產品團隊的績效指標與功能上線掛鉤，維護工作則難以量化。這種誘因結構會讓維護被排到「有空再做」的位置，而「有空」通常永遠不會來。當功能優先成為常態，維護週期就會被動拉長，技術債持續累積，最終反映在產品品質與更新頻率上。
值得注意的是，這不是個別團隊的紀律問題，而是制度設計問題。有些成熟廠商會把維護指標納入工程團隊的考核，例如漏洞修補時間、相依更新頻率、測試覆蓋率，讓維護從「良心工作」變成「被管理的流程」。這類制度設計，往往比口號更能預測產品長期的維護表現。
評測只看當下，不看未來
最後一個盲點在評測本身。多數評測在產品發布後數週內完成，關注的是當下功能與效能，較少追蹤一年後的更新狀況。這使得「維護週期」成為評測報告中缺席的一欄。讀者於是在資訊不對稱的情況下做決策，廠商也缺乏改進維護的市場壓力。
要改變這個結構，評測者可以做的其實不少：在報告中揭露產品的更新節奏、EOL 政策、漏洞回應紀錄；對停止維護的產品標示風險；定期回訪舊評測，更新產品的維護狀態。這些動作不需要昂貴的實驗室，只需要把「時間」納入評測維度。
五、怎麼判斷一套軟體的維護週期健不健康
談了這麼多風險，接下來要回答實務問題：作為使用者或評測者，我們要怎麼判斷一套軟體的維護週期是否健康？以下提供一組可觀察指標與提問清單，可以直接套用在任何軟體評測流程中。
十個可觀察指標
文件更新同步性：文件是否隨版本更新？是否標示適用版本？
產品藍圖透明度：是否公開未來發展方向？是否回應社群需求？
遷移與退場支援：是否提供資料匯出、格式轉換、替代方案建議？
評測時必問的七個問題
如果你正在為團隊選一套長期使用的軟體，以下七個問題建議直接寫進評估表，並要求廠商或社群提供具體答案，而不是模糊承諾。
這套產品的官方支援期還有多久？下一個 EOL 日期是什麼時候？
過去十二個月內，重大安全漏洞的平均修補時間是多久？
如果我兩年後才要升級到下一個 major 版本，升級路徑與文件是否已經存在？
產品依賴哪些關鍵第三方元件？這些元件的維護狀態如何？
如果原廠停止維護，我能否自行維護？原始碼、文件與社群資源是否足夠？
維護授權或訂閱費用未來三年的預估漲幅是多少？終止合約後資料能否完整匯出？
這套產品過去三年是否曾經更換維護團隊、被併購或改變授權模式？
這七個問題不需要工程背景就能問，卻能篩掉大量「功能漂亮但壽命短」的選項。對評測者而言，把這些問題的答案整理成表，本身就是一篇有價值的維護週期評測。
六、把維護週期變成競爭力：實務策略與治理
理解問題之後，下一步是行動。無論你是軟體的使用者、採購者，還是產品團隊的一員，都可以透過以下策略，把維護週期從「被動的風險」轉變成「主動的競爭力」。
建立維護基線、SLA 與版本政策
對使用方來說，第一步是把維護要求寫進採購與合約。具體做法包括：要求廠商提供維護基線（例如每季安全更新、每年一次 major 版本）、簽訂服務等級協議（SLA）明定安全修補的回應與解決時間、要求公開 EOL 政策與提前公告期。這些條款會讓維護從「廠商的善意」變成「可課責的承諾」。
對產品團隊來說，則應建立內部的版本政策：哪些版本進入 LTS、哪些版本只做安全修補、每個版本的支援年限多長、相依元件的更新節奏為何。政策不需要複雜，但必須書面化、公開化，並在每次版本發布時同步更新。這不只是對外承諾，也是對內部的紀律約束。
文件化、測試與知識傳承
知識永續是維護週期最容易斷裂的一環。實務上可以從三件事做起：第一，把「文件與測試」視為交付定義的一部分，沒有文件與測試的功能不算完成；第二，建立交接機制，要求核心模組至少兩人熟悉，避免單點知識；第三，定期進行架構回顧與技術債盤點，把改善工作排進正式排程，而不是留給「有空再說」。
這些做法聽起來老派，卻是最有效的抗老化手段。一套軟體能否在人員流動後仍維持維護節奏，幾乎完全取決於知識是否被制度化。對評測者而言，也可以把「文件品質」與「測試公開程度」列為維護週期的觀察指標，因為它們直接影響未來的維護成本。
退場規劃：好的維護也包含好好結束
永續不代表性質上永遠不放棄。有時候，最負責任的維護決策是「規劃退場」。一套產品若已無法跟上環境、維護成本高於遷移成本，與其勉強續命，不如提早公告、提供資料匯出工具、協助使用者遷移。這種「善終」能力，其實是軟體永續成熟度的最高展現。
評測時可以觀察廠商是否有退場政策：終止支援前是否提前十二個月公告？是否提供遷移指南或替代方案？是否保證資料可完整匯出？這些問題在產品如日中天時很少人問，卻決定了使用者最脆弱時刻的保障。把退場規劃納入評測，等於是把「維護週期」的視角延伸到產品生命週期的兩端。
七、結語：維護週期，是軟體評測裡最被低估的那一欄
回到本文的主題：軟體永續，為什麼維護週期。答案其實很直接：因為軟體的價值不是在上線那天決定的，而是在往後每一年「還能不能被安全地使用、被合理地修改、被順利地交接」中累積出來的。維護週期就是這三件事的節奏，它決定了技術債是複利還是清偿、決定了依賴鏈是助力還是風險、決定了知識是資產還是斷層。
對「雅寶社區 · 頂客論壇」的讀者而言，這意味著下一次評測一套軟體時，除了問「它有什麼功能」，也要問「它多久更新一次」、「它的支援期還有多久」、「如果明天原廠消失，我還能不能用」。這些問題不會讓評測變得更炫，卻會讓判斷變得更準。當市場開始重視維護週期，廠商才會把資源從「發售日的煙火」轉向「十年後的餘溫」。
軟體永續不是一個口號，而是一組可以被觀察、被要求、被管理的節奏。維護週期就是那個節奏的拍子。拍子穩了，軟體才走得遠；拍子亂了，再華麗的功能也只是曇花一現。下一次你打開一套軟體的「關於」頁面，不妨多看一眼它的版本日期與更新紀錄——那裡藏著的，往往比功能列表更能告訴你，它值不值得你投入接下來這幾年。