Drupal 技術支援：維護合約該涵蓋什麼

多數在找 Drupal 技術支援的人，手上已經有那個網站了。它可能是從一家早已轉身離開的接案公司接過來的，也可能是從一位離職的開發者那裡繼承下來的，而現在更新已經逾期，某個表單不再寄信，或者一份安全公告落了下來，卻沒有人說得清它是否適用於自己。他們要的不是一頁銷售文案，而是一份範圍文件：工作到底是什麼、一份公平的合約該怎麼寫，以及它應該值多少錢。

這篇文章就是那份文件。它列出一個 Drupal 網站每個月真正需要的工作、決定一份維護合約值不值錢的營運事實，以及英國實際的價格區間。請把廠商的提案攤在旁邊一起讀，因為真正有用的部分，是發現那份提案沒有回答哪些問題。

有兩件事讓 Drupal 不同於一般的網站維護。它的安全公告依照公開的時間表發布，所以你的暴露時間是可以量化的，也可以寫進合約。另一件是，一個 Drupal 網站是一堆由各自獨立維護者照顧的貢獻模組拼起來的，所以必須有人替你盯住一個不斷移動的升級目標。

一份 Drupal 維護合約該涵蓋什麼？ 針對你這套模組清單的安全公告監控、依既定週期經由測試環境套用的核心與貢獻模組更新、驗證備份確實還原得回來、運作狀態與應用程式錯誤監控，以及一筆寫明的小異動預算。在英國，這大約從單純形象網站的每月 250 英鎊起，到複雜網站的 2,000 英鎊以上。低於這個區間，你買到的是監控，不是支援。

Drupal 技術支援每個月究竟在做什麼

找三家廠商報價，你會收到三份分別叫做基本版、商務版與企業版的方案，每一份都是一串名詞。名詞不是工作。工作是一組週期性任務，它們要嘛依照排程發生，要嘛根本不發生；有用的做法，是讓廠商把每一項都描述成一個活動，並帶上負責角色與頻率。

這樣的活動一共八項。安全公告的監控與修補。核心與貢獻模組的更新。相依套件與平台版本的升級。備份驗證與還原演練。運作狀態與應用程式錯誤監控。效能退化檢查。內容與編輯支援。以及為那些總會出現的瑣碎工作準備的異動預算。

寫滿八項的合約未必就好，但只寫四項的合約一定不完整，而被砍掉的那四項幾乎總是同樣幾項：還原演練、效能退化、平台升級與異動預算。它們都是花錢的那幾項，所以它們消失了。

方案名稱如何藏起真正的工作

「無限支援單」沒有說明，每月第三個星期三由誰替核心套用安全修補程式。「主動監控」沒有說明，凌晨兩點是有人讀那則警示，還是它一路排到星期一。「盡力而為」什麼也沒說明。

把每一個詞組換成三個事實：活動、頻率，以及執行它的那個有名字的角色。多數方案頁面經不起這樣處理，而撐下來的那幾家，才是值得談下去的廠商。

修補的時間窗就是產品本身

Drupal 依時間表發布安全版本，這很少見，也極為有用。核心安全版本落在每月第三個星期三 的時段，從 America/New York 時間 1200 開始，視季節相當於 1600 或 1700 UTC。貢獻專案則有每週三的安全發布時段 ，因此貢獻專案的公告比核心公告頻繁得多，而且成批抵達。

由此可知，漏洞本身不是風險。所有在跑 Drupal 的人在同一刻收到同一個漏洞，而且是公開發布的。風險在於公告上線到修補程式進入你正式站台之間的那段空檔，因為在那段時間裡，這個缺陷已被記錄、被索引，並且正被那些讀公告比你的廠商更快的人掃描。

和那段空檔的小時數相比，支援合約裡其餘所有條款都是裝飾。所以問一家潛在廠商的第一個問題是算術題，不是哲學題。下個月第三個星期三，幾點會有人讀到那份公告，修補程式又會在什麼時候上線？「在我們的標準 SLA 之內」並不能回答這個問題。

Drupal 如何為風險評分，以及這該對你的合約做什麼

每一份 Drupal 公告都帶著一個數字，而這個數字是這個平台上最被浪費的寫條款工具。Drupal 以 NIST 的通用誤用評分系統，也就是 NISTIR 7864 為漏洞評分，從六項指標得出 0 到 25 分：攻擊複雜度、認證需求、機密性影響、完整性影響、可利用程度，以及目標分布。

分數對應五個公開的等級。0 到 4 分是不嚴重，5 到 9 分是輕度嚴重，10 到 14 分是中度嚴重，15 到 19 分是嚴重，20 到 25 分是極其嚴重。這些區間是公開的、穩定的，也不容任何一方自行詮釋。

這就讓它們成了支援 SLA 天然的骨架，可是幾乎沒有人這樣用。與其發明一套廠商日後可以爭辯的私有嚴重度定義，不如把回應承諾直接寫在 Drupal 的分數上：極其嚴重的在寫明的小時數內完成，包含非上班時間；嚴重的在一個工作天內；中度嚴重的進入下一個既定週期；其餘的批次處理。雙方都不能再回頭爭論「緊急」當初是什麼意思，因為已經有第三方替你們定好了。

極其嚴重是另一種營運事件

極其嚴重的核心版本很罕見，Drupal 對它們的處理也不一樣。安全團隊會事先發布一則公共服務預告 ，讓網站擁有者安排人力。PSA-2026-05-18 做的正是這件事，它在 2026 年 5 月 18 日提出警告，說 5 月 20 日星期三將發布一個影響所有受支援分支的極其嚴重核心版本。

那份事先通知，正是你的維護合約應該圍繞著搭建的東西，因為它把一次緊急事件變成了一次預約。星期一就知道有 PSA、而且已經替星期三留好部署時段的廠商，在經營一項支援服務。星期四才知道的廠商，在經營一份郵件清單。

還有一種值得知道的緩解手段。Drupal Steward 是由 Drupal 協會與安全團隊營運的付費全球分散式網頁應用程式防火牆，為極其嚴重的核心漏洞提供網路層的虛擬修補，讓網站在更新還在測試時先受到保護。它的價格以美元公布，並隨流量上升：每月約 100 萬次 HTTP 請求的網站低於 20 美元，超過 1000 萬次則低於 100 美元。它買到的是時間，不是免疫，而一份好的維護合約會寫明這筆錢由誰出。

安全公告政策沒有涵蓋的部分

安全公告流程與權限政策 裡的三項排除，改變了一份維護合約必須做的事，而多數支援合約對這三項都保持沉默。

公告只針對穩定版發布。如果你網站上的某個模組跑的是 alpha、beta、候選版或開發版，就永遠不會有針對它的公告，而沒有消息什麼也證明不了。涵蓋範圍也是逐專案選擇加入的，不是自動的，所以一個未被涵蓋的貢獻模組完全可能帶著已知缺陷，卻沒有任何通知管道。

接著是那個最容易讓人栽跟頭的：外部函式庫不會有任何公告，即使某個貢獻專案要求你安裝它。以相依套件形式被拉進來的 JavaScript 或 PHP 函式庫是你自己的問題，由你自己追蹤，它不會出現在 Drupal 的公告來源裡。

涵蓋範圍也可能被撤銷

安全涵蓋並不是永久的。PSA-2026-07-22 撤銷了 QA Accounts 模組的公告涵蓋，理由是它把易用性放在安全之前，而且只適用於無法從網際網路連到的網站。

風險就是這個形狀。你多年前在涵蓋之下裝上的模組，可能悄悄失去涵蓋，而網站上不會有任何變化來提醒你。為每一個已安裝專案維護一份清冊，記下它目前的涵蓋狀態與版本穩定度，是真實的週期性工作，它應該白紙黑字寫進維護合約。

相依套件與平台升級同樣是支援工作

Drupal 支援合約裡最常被排除的那一項，恰恰是最後決定網站能不能活下來的那一項。Drupal 的平台需求會移動，而且是以需要更換主機、而不是一句 composer update 就能解決的台階方式移動。

在 PHP 上，Drupal 10 至少需要 PHP 8.1 ，而 Drupal 11 從 11.1 起就把 PHP 8.3 當成最低需求。對 PHP 8.5 的支援在 Drupal 11.3 中到來，而 Drupal 12.0 只支援 PHP 8.5。最後這個細節比看起來重要：今天在 PHP 8.1 上跑得很舒服的網站，距離 Drupal 12 還隔著兩次被迫的平台搬遷。

資料庫需求也走了同樣遠。Drupal 11 需要 MySQL 8.0 以上、MariaDB 10.6 以上、PostgreSQL 16 以上，或 SQLite 3.45 以上。Drupal 10 還接受 MySQL 5.7.8、MariaDB 10.3.7 與 PostgreSQL 12。一台仍在提供 MySQL 5.7 的代管主機，是升級路徑上的攔路石而不是細節，我們那篇談什麼才真正跑得動 Drupal 的文章講了該換到哪裡去。

Drupal 10 的生命週期結束已經是維護合約的問題

Drupal 10 將在 2026 年 12 月 9 日結束生命週期 ，而 Drupal 12 在同一週發布，也就是 12 月 7 日那一週。11.3.x 與 10.6.x 分支的安全支援也在那一刻結束。截至 2026 年 9 月，仍在收到安全版本的分支是 11.4.x、11.3.x 與 10.6.x。

對照日曆，那大約還剩三個月。任何一個到 2026 年 9 月還沒有一份帶報價升級計畫的 Drupal 10 網站，都會在 12 月要嘛付一筆急件加價，要嘛在無支援狀態下運作，而後一個選項應該是有人刻意做出的決定，不是隨波逐流的結果。

一份對得起費用的維護合約，此刻應該已經交出四樣東西：一份目前的升級狀態報告、一次針對自訂模組與佈景主題的棄用程式碼掃描、一份逐一檢查每個貢獻模組對 Drupal 11 與 12 就緒程度的結果，以及一份書面估價。如果你的廠商到現在一樣都沒交，那就是結論。我們對Drupal 遷移的成本、選項與期限 的拆解說明了這項工作包含什麼，同樣的規劃也在我們的網站開發 專案裡。

備份在還原被驗證之前一文不值

幾乎每一份 Drupal 支援合約都承諾備份。承諾還原的卻很少，而這個差別就是這一行條款的全部價值。英國國家網路安全中心在給小型組織的指引裡說得很直白：做完備份之後 ，你還需要知道怎麼把它還原回去，並確認它包含了所有重要的東西。

一次 Drupal 還原有三個活動零件，而不完整的備份總是極有規律地在第二個上失手。你需要資料庫、公開與私有檔案目錄，以及設定。一份只抓了資料庫、沒抓檔案目錄的備份，還原出來的是內容完好卻沒有圖片的網站：在監控腳本看來它運作正常，在客戶看來那是一場災難。

要求一次帶日期的還原演練，在一個用完即丟的環境裡進行，並書面記下它花了多久、少了什麼。對多數網站來說，每季一次是合理的頻率。如果廠商從沒做過，他們不知道自己的復原時間，你也不知道。

運作狀態與錯誤監控，以及可用率究竟量到了什麼

伺服器還活著和網站還能用之間有很大的落差，而 Drupal 正好坐在那道落差裡。一個 PHP 致命錯誤、一次耗盡的記憶體上限、一次失敗的資料庫連線，或一次壞掉的快取重建，都會產出一個被粗略探測讀成成功的頁面，或者一個沒有人在盯著的普通 500。

在伺服器層量測的監控告訴你機器有回應。在應用程式層量測的監控會請求一個真實頁面、跟隨轉址，並斷言回應內容裡確實有預期的文字。這是兩種價格不同的產品，而一份只寫「運作狀態監控」卻不說清是哪一種的支援提案，描述的是便宜的那一種。

在這之下還有 Drupal 自己的紀錄。近期紀錄訊息報表與 PHP 錯誤紀錄，正是一次失敗的 cron 執行、一個被棄用的函式，或者一個每次請求都拋出例外的模組，會遠早於訪客抱怨而現形的地方。必須有人依排程去讀它們。我們那篇談有意義的可用率 SLA 的文章講了這些百分比如何換算成容許的分鐘數。

批判地讀一份 Drupal 支援 SLA

多數支援 SLA 是為了被簽下而寫的，不是為了被使用而寫的；它們能被簽下，正是因為它們被讀得很快。承擔了幾乎全部重量的只有三個條款，而認真讀完它們只需要十分鐘。

回應時間不是解決時間

一份承諾兩小時回應的 SLA，通常承諾的是有人會在兩小時內確認這張支援單。它並沒有承諾有人會去看你的網站。認真的廠商會承諾一個解決目標，至少是一個診斷加暫行做法的目標，並把修復時間另外寫明。

如果某項工作確實無法用時間框住，誠實的合約會這麼寫，並改為承諾持續投入直到解決。那是一個真實的承諾。單獨一句「兩小時回應」，承諾的是寄一封電子郵件。

嚴重度定義決定一切

每份 SLA 都有一張嚴重度表，而通常由廠商來判定嚴重度。那就是漏洞所在。如果第一級的定義是「網站無法使用」，那麼對三分之一顧客失敗的結帳流程就是第三級，下週才會有人看。

把定義寫在營運衝擊上，而不是技術狀態上，並把實例寫進合約：一個失敗的付款步驟、一個進不去的後台登入、詢問頁面上一個壞掉的聯絡表單。然後約定由誰判定嚴重度，以及你要如何對一次判定提出異議。

服務時段不等於上班時間

「上班時間」和「服務時段」指的是不同的東西，卻常被混著用。服務時段是計時開始、而且有人有義務採取行動的那段時間。如果服務時段是工作日的 09:00 到 17:30，那麼 12 月某個星期三 1700 UTC 發布的公告，最早也要到隔天早上才會被接手。

具體到 Drupal，請注意核心安全時段是在 1600 或 1700 UTC 打開的。一家服務時段在 17:30 結束的英國廠商，結構上正好卡在那個邊緣，所以針對極其嚴重公告的非上班時間安排，需要單獨寫明並單獨定價。

什麼算事故，什麼被排除在外

排除條款那一節，正是一份維護合約悄悄變得比看起來便宜的地方。常見的排除項單獨看都完全合理，合在一起就不合理了：第三方主機故障、客戶員工造成的問題、不是廠商裝的模組出的毛病、任何與付費佈景主題有關的事，以及任何被廠商歸類為異動而非故障的事情。

最後那一條是鋒利的邊。如果修一個缺陷需要改一處設定，而設定異動是要另外計費的，那麼幾乎任何故障都可以被重新歸到計費那一欄。直接問廠商如何區分故障與異動，並請他們從自己最近的工作裡各舉兩個例子。

也要看清牽涉第三方時會發生什麼。當付款閘道、CRM 連接器或主機才是出問題的一方，廠商是去協調修復，還是把支援單標成不在範圍內直接關掉？協調是真實的工作，值得付錢，但前提是合約裡寫著它會發生。

三種維護合約模式，誠實地比一比

幾乎每一種 Drupal 支援安排都是三種形狀之一，每一種都是針對不同處境的合理答案。錯誤在於買下一種形狀，卻期待另一種形狀的行為。

每月固定工時

你買下一塊工時，例如八小時或十六小時，廠商把它們用在你要求的任何事情上。它透明，報價之間也容易比較，適合那種小異動細水長流、內部又有人能排優先順序的組織。

它的弱點是維護要和新功能搶同一個池子。忙碌的月份裡，安全修補會悄悄輸給行銷活動的到達頁，因為花這些工時的人有截止日，而修補感覺上沒有。如果你買這種模式，就在合約本身裡把一部分工時圈給維護。

無限修復加上另行報價的異動

廠商以每月固定費用吸收維護與小修復，超過約定門檻的部分另行報價。這是多數接案公司主推的模式，對一個穩定的網站和一位容易緊張的擁有者來說，它確實是正確答案，因為它把一份浮動的風險換成預算裡固定的一行。

它的弱點是邊界。「小修復」在有人真的需要之前都是未定義的，而門檻會隨著這個月過得如何而移動。堅持要一份書面定義，最好是一個時間盒，例如三十分鐘以內，再加上一份說明哪些工作被吸收的月報。

純粹按工時計費

沒有維護合約，一個日費率，你開口時才動手。對於一個低風險、擁有者又確實會自己追更新的網站，以及那些內部有能力、只是偶爾需要專家幫忙而不需要待命的組織來說，這是誠實的選擇。

它的弱點是不會有任何主動的事情發生，因為沒有人拿錢去看。按工時計費在排隊上也很吃虧：你在和簽了維護合約的客戶搶同一批工程師，所以在糟糕的日子裡，回應是按週而不是按小時計的。

不計量支援裡的誘因問題

不計量的支援有一個結構性問題，業界沒有人樂意談。如果不論一個網站消耗多少工時，廠商拿到的錢都一樣，那麼花在你網站上的每一個小時都在削減他們的利潤，而商業上理性的行為就是盡量少花。

這通常不會表現為怠工，而是表現為偏好快的修法而不是對的修法、壓住症狀而不去追根源、推遲那個需要一整天回歸測試的模組升級。在便宜的方案上，它還會反向出現：只有當網站真的從來沒被碰過，那份費用才划算。

平衡它的是一份報告義務。一份列出消耗工時、已套用的更新、已評估的公告與已結案支援單的月報，讓消耗對雙方都看得見，也把一個不賺錢的客戶變成一次對話，而不是一場緩慢的服務下滑。任何對這套模式有信心的廠商都會同意。抗拒的廠商，是在告訴你這套模式真正的用途。

營運上做得好是什麼樣子

有三項技術實務，把一個能安全撐住你網站的 Drupal 廠商，和一個在臨場發揮的廠商區分開來。它們都不稀奇，而且三項都很容易問出口。

要嘛用 Composer，要嘛什麼都別用

Drupal 自己的文件對混用更新方式說得很直接，它警告如果把 Composer 更新和其他做法混在一起，網站可能遇到嚴重的更新問題 ，而且一旦 Composer 開始管理某一個模組，它就必須同時管理核心。一家還在用 FTP 上傳模組資料夾的廠商，早晚會刪掉某個貢獻模組所依賴的 vendor 目錄。

問一問 composer.json 與 composer.lock 是否在版本控制裡，以及 Composer 是在正式環境上執行，還是部署一個建置好的產出。這兩個答案都可能是對的。沒有答案不可能是對的。

一個與正式環境一致的測試環境

一個 PHP 版本不同、資料庫版本不同或模組組合不同的測試站台，什麼有用的東西也驗證不了。測試環境的意義，是讓安全修補在不花錢的地方失敗，而它只有在兩個環境於會出問題的那些面向上一致時才做得到。

問一問測試環境是怎麼從正式環境刷新的、多久刷一次，以及它是否持有真實內容的去識別化副本。一個只有三個測試節點的測試站台，不會暴露出那個會拖垮一個跨越 40,000 列的檢視表的更新。

把設定放進版本控制

Drupal 預設把設定存在資料庫裡 ，而設定管理系統的存在，就是為了把它匯出成可以提交、可以審查、可以匯入另一個環境的檔案。用它的團隊能可重現地還原網站的設定。不用它的團隊，是在正式環境的後台一路點擊並且祈禱。

這是與廠商對話中最清楚的一個訊號。問一問在測試環境上做的一處異動是怎麼抵達正式環境的。如果回答是一段說明而不是一陣停頓，接下來的對話通常就沒問題。

如果他們講不出部署流程，那就是答案

這件事沒有委婉的說法。一家沒辦法在不疾不徐的一分鐘裡講清楚程式碼如何從開發者的機器走到你線上網站的廠商，正在告訴你他們的部署是臨場發揮的。臨場發揮的部署，正是安全修補被拖延的原因：沒有人想在星期三傍晚跑一遍風險很高的手動流程。

沒有人讀的退場條款

總有一天你會換廠商，而管著那一刻的條款，是在所有人還友好的時候寫的，卻在沒有人友好的時候才被讀。它應該把四件事寫得清清楚楚。

程式碼歸誰所有，包含自訂模組與佈景主題工作，依據哪一種授權。程式碼倉庫在哪裡，存取權如何移交。資料庫、檔案與設定的完整匯出會以寫明的格式，在寫明的工作天數內提供。以及 DNS、主機與第三方服務的憑證是交出來的，而不是被扣著的。

失敗的方式通常不是惡意。它是這樣一家廠商：把你的網站跑在他們自己的帳號裡，握著程式碼倉庫的唯一副本，而且因為你不再是付費客戶，回你的信要花六個星期。簽約之前就把退場條款要過來，並把對方的不情願當成資訊。

Drupal 7：生命週期結束、延長支援，以及兩者之間的缺口

Drupal 7 的安全支援已於 2025 年 1 月 5 日結束 。社群停止產出修補程式，那個讓 Drupal 7 變得好用的龐大貢獻模組生態，也隨之不再有人維護。

Drupal 協會營運著一個延長安全支援供應商計畫，HeroDevs 與 Tag1 Consulting 是該計畫下的認證廠商。對於一個今年確實無法遷移的組織，買下這份支援是正當的決定，而且它確實比什麼都沒有要好得多。

它做不到的，是讓網站在通常的意義上是安全的。一家商業廠商修的是它自己發現或被告知的漏洞，依它自己的排程，針對它同意涵蓋的那套模組。它不會恢復公開的公告流程，不會涵蓋你剛好裝上的每一個貢獻模組，也不會延伸到那些模組所依賴的外部函式庫。延長支援是一種受控地運作一個無支援平台的方式，而一份支援合約並不是安全的同義詞。

如果你在 2026 年 9 月還在 Drupal 7 上，誠實的建議是把錢花在遷移上，而不是花在租金上。我們的2026 年 Drupal 網站開發指南 談了這個平台目前的樣子，而關於公告流程更深的細節，在我們那篇Drupal 安全、公告與真實風險 裡。

內容支援與異動預算

有兩項內容因為難以劃定邊界而被擠出支援合約，而它們恰恰是客戶真的會感覺到的兩項。

內容與編輯支援，意思是有人能加一個內容類型、修好一個不再正確篩選的檢視表、在人員異動之後重新訓練一位編輯，或者弄清楚為什麼某個圖片樣式把人臉裁掉了。它不戲劇化但頻率很高，一份沒有它的維護合約，會養出一個不再開口、轉而繞開網站做事的客戶。

異動預算是另外一半。每個網站都會累積一列瑣碎工作：表單上加一個欄位、頁面搬家之後的一條轉址、改一改詢問由誰接收。替這條佇列以小時命名一個每月額度，才是阻止它變成一個季度性緊急專案的辦法。小網站每月兩到四小時是實際的數字，繁忙的網站則是八到十六小時。

英國的 Drupal 技術支援要花多少錢

下面這些數字是我們 2026 年的內部估算，依據的是英國接案公司的實際工作而不是一份公開調查，並且假設廠商在做上面描述的八項活動，而不是在賣一個附帶支援信箱的監控訂閱。

用散文說：一個小型形象網站大約在每月 250 至 600 英鎊，這買到公告監控、每月一次的修補週期、備份驗證，以及一兩個小時的異動。一個帶整合的中型網站大約在 700 至 1,800 英鎊，因為每多一個整合，就多一個必須在每次核心更新之後重測的回歸面。一個帶自訂模組的複雜網站或多語系網站，從 2,000 英鎊左右起跳，一路到 6,000 英鎊以上。

只做監控的安排，也就是廠商盯著公告並告訴你哪些與你有關、但不負責部署的那種，位置更低，大約每月 250 至 450 英鎊。把這些區間放在英國接案公司 600 至 900 英鎊的日費率旁邊，一份 1,500 英鎊的維護合約大概能買到接近兩個工程師日。費率的細節在我們那篇Drupal 開發者的費率、技能與篩選 裡，更大的預算圖像則在軟體維護成本 裡。

什麼會把一個網站從一個區間推到下一個

直覺是按流量替支援定價，而流量幾乎無關緊要。一個每月 20 萬次造訪、只有二十個模組、沒有整合的網站，比一個每月 2,000 次造訪、卻帶著 CRM 連接器、付款閘道與一次自訂遷移的網站更便宜。

真正驅動成本的是三件事。模組數量，因為每一個貢獻模組都是一條要盯的公告來源，也是每次核心更新時的一份相容性風險。整合數量，因為每一個都是一份可能在你腳下改變的外部約定，也是一輪必須重跑的回歸測試。以及編輯量，因為一個繁忙的編輯團隊會以穩定的速度產生支援問題、權限調整與內容模型的修改。

自訂程式碼是這三者之上的乘數。一個有 12,000 行自訂模組程式碼的網站，每一個小版本都需要一次棄用掃描與一遍回歸，那是一個純貢獻模組網站不必承擔的一天工作量。最高那個區間正是從這裡來的，也正是我們的軟體開發 專案通常被要求吸收的工作。

該問潛在廠商的問題

六個問題，以及那些該讓你擔心的回答。

我們的網站現在跑在哪個 Drupal 版本與哪個 PHP 版本上，升級路徑是什麼？一個需要他們去查一下的回答沒問題。一個一週之後才到的回答有問題。你們怎麼知道一份安全公告與我們有關？「我們盯著 drupal.org」是個很弱的回答，你想要的答案是一份逐站台整理的模組清冊。

帶我走一遍你們的部署流程。這裡的猶豫，是整場對話裡最強的負面訊號。你們上一次從備份還原這個網站是什麼時候？「我們每天備份」並不是對這個問題的回答。維護合約排除了什麼，你們又怎麼判定某件事是故障還是異動？最後一個：如果我們離開，我們能拿到什麼，多快能拿到。

沒有維護合約會發生什麼

這與其說是一句警告，不如說是一段順序，而且它在每一個無人支援的 Drupal 網站上，大致以同樣的速度展開。

頭幾個月什麼都不會發生，而這正是問題所在，因為它教會所有人：什麼都不需要發生。在第六個月到第十二個月之間的某處，更新的積壓越過了那個點，更新不再能單獨安全地進行，因為某個模組現在需要更新的核心，核心需要更新的 PHP，而主機不提供它。套用一個修補程式已經變成了一個專案。

再往後，網站徹底漂出平台支援範圍，一次瀏覽器或 PHP 的變更弄壞了某個看得見的東西。修復現在得從一次沒有人編過預算的升級開始，以急件報價，而網站上沒有文件的那些部分會被重做而不是被修好。如果在這個過程中發生了外洩並牽涉個人資料，英國資訊委員辦公室要求在 72 小時內通報 ，前提是該外洩很可能對人們的權利與自由造成風險，而這個期限從你知情起算，靠的是你要嘛有、要嘛沒有的紀錄與備份。

這筆復原的帳單，可靠地是那份本來可以避免它的維護合約的好幾倍，而差別不在人力上。差別在於：計畫中的工作發生在星期二，帶著回復方案；緊急的工作發生在星期天，沒有回復方案。

在簽字之前把範圍定對

這一切的目的不是讓你不信任廠商，而是讓兩份提案之間的比較真的有意義，因為目前多數 Drupal 支援報價從設計上就無法比較：用詞不同、排除項不同，也沒有關於每月工作到底是什麼的共同定義。

把那八項活動、Drupal 的風險等級、三種維護合約模式與六個問題拿出來，逐一對照你桌上那份東西。撐過這一關的，才是一份真正的提案。

Mecanik 把 Drupal 網站的支援，當成我們網站開發 與軟體開發 工作的一部分。第一次合作通常是一次盤點而不是一次修復，因為來到我們這裡的網站，大多說不清自己的模組裡還有哪些仍被安全公告來源 涵蓋。

常見問題

一份 Drupal 維護合約應該包含什麼。 八項活動：針對你這套模組清單的安全公告監控、依既定週期進行的核心與貢獻模組更新、相依套件與 PHP 平台升級、帶還原演練的備份驗證、運作狀態與應用程式錯誤監控、效能退化檢查、編輯支援，以及一筆以小時寫明的異動預算。只寫四項的合約並不完整，通常缺的正是還原演練、效能檢查、平台升級與異動預算。

在英國，Drupal 技術支援每月要花多少錢。 依我們 2026 年的內部估算，一個小型形象網站大約每月 250 至 600 英鎊，一個帶一到兩個整合的中型網站是 700 至 1,800 英鎊，一個帶自訂模組的複雜多語系網站是 2,000 至 6,000 英鎊。只做監控的安排大約在 250 至 450 英鎊。對照英國接案公司 600 至 900 英鎊的日費率，一份 1,500 英鎊的維護合約大約買到兩個工程師日。

Drupal 什麼時候發布安全修補程式。 Drupal 核心安全版本落在每月第三個星期三的時段，從 America/New York 時間 1200 開始，視季節相當於 1600 或 1700 UTC。貢獻專案則有每週三的安全發布時段。極其嚴重的核心版本之前會有一則公共服務預告，好讓網站擁有者提前安排人力。

Drupal 7 的延長支援等於安全嗎。 不等於。Drupal 7 的安全支援已於 2025 年 1 月 5 日結束，Drupal 協會在其延長安全支援供應商計畫下認證了 HeroDevs 與 Tag1 Consulting。這些廠商依自己的排程，針對約定的模組組合修補他們涵蓋的部分。它不會恢復公開的公告流程，不會涵蓋你裝上的每一個貢獻模組，也不會延伸到外部函式庫。

Drupal 10 什麼時候結束生命週期。 Drupal 10 將在 2026 年 12 月 9 日結束生命週期，Drupal 12 在同一週發布，也就是 12 月 7 日那一週。11.3.x 與 10.6.x 分支的安全支援在同一刻結束。Drupal 12 只支援 PHP 8.5，所以還在舊 PHP 版本上的網站需要在升級之前更換主機，而不是之後。