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 协会与安全团队运营的付费全球分布式 Web 应用防火墙，为极其严重的核心漏洞提供网络层的虚拟补丁，让站点在更新还在测试时先受到保护。它的价格以美元公布，并随流量上升：每月约 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 版本上的站点需要在升级之前更换主机，而不是之后。