企业软件开发服务：你到底买到了什么

企业软件开发服务这个说法，按大多数开发公司网站上的用法，指的就是同样的活儿贴上一个更大的数字。团队一样，流程一样，提案里多了一面客户标志墙，价格翻了三倍。买方心里清楚，所以采购部门早就学会忽略这个词，直接去读合同附件。

底下确实有一个真实的区分，而且它和公司规模无关。一家 40 人的保险公司可以跑一个货真价实的企业级项目，一家 12,000 人的零售商也可能只是订了一个网站。区分它们的是这套系统给建造方带来的义务：它必须和多少别的系统对话，允许停多久，谁能否决一次发布，哪个监管机构对它有兴趣，以及供应商撒手不干时会发生什么。

下面用这些义务来定义这个类别，好让买方分得清谁能扛得住，谁只是给一个普通项目加了张企业级的封面。

到底什么让一个软件项目成为企业级？ 不是买方的规模。一个项目成为企业级，是因为它背着普通项目没有的约束：宽阔的集成面、合同上的可用性与恢复义务、监管暴露、几个各自都能拦下发布的干系人群体、会压垮朴素设计的数据量，以及必须与如今无人理解的系统共存。决定架构和大部分成本的是这些约束，不是功能清单。

什么让一个项目成为企业级

有用的判断标准是一份约束清单，一个项目背上其中大多数而不是某一条时才算数。诚实地套用它，会把很多号称企业级的东西排除掉，同时把那些当成小项目来卖、也因此按小项目估算而失败的活儿包括进来。

集成面

数一数你的新软件必须和多少系统交换数据，再数一数拥有这些系统的团队和厂商有多少个。能预测成本的是第二个数字。由一个内部团队拥有的三条集成是两周的活。由三家厂商各自拥有的三条集成，每家都有自己的变更窗口、沙箱可用时间和支持台，那是一个季度的活。

每个所有方都会带来一份你控制不了的日程。一家每月刷新沙箱的厂商决定了你的测试节奏，一家认证要六周的支付服务商决定了你的上线日期。当对手方超过十家，集成日历就成了项目计划本身，开发只能塞进缝隙里。

可用性义务

普通软件被期待能用。企业软件的这份期待后面跟着一个数字，通常写在一份带服务赔偿的合同里。这个数字首先改变的是架构，因为单实例部署无论代码多好都守不住它。

从一个容忍维护窗口的目标，跨到一个不容忍的目标，是多数企业预算里最贵的一行，而且经常由从没见过这个价钱的人拍板。我们关于有实质意义的可用性 SLA 的文章讲了这些数字是怎么写的，以及它们如何被常态性地写砸。

有否决权的干系人

普通项目有一个产品负责人。企业项目有产品负责人、信息安全部门、数据保护官、采购负责人、拥有网络的基础设施团队、将来要接下支持工作的服务台，还常常有临床、法务或合规的审查人。

他们中任何一个都能拦下一次发布，而且没有一个人向出钱的人汇报。于是决策要花掉与难度无关的日历时间，没把这一点写进计划的供应商，从第二个月起会错过每一个日期。

已经没人再理解的系统

每个企业环境里至少有一个系统，它的行为只有输出可以佐证。写它的人已经走了，规格文档就算还在，描述的也是更早的版本。它能跑，它承重，而且大家认为改它不明智。

新软件必须与它共存，所以得先有人搞清楚它实际在做什么。那是考古，不是开发：读生产数据、跟踪调用、对副本做受控实验、把代码隐含的规则写下来。在大环境里这是几周的工作量，也因为产不出可见的功能，成为谈判时最常被删掉的条目。

删掉它只是把活儿挪到集成测试，让已经在修缺陷的人在时间压力下发现它。一个把探查单独报价并且守得住这笔钱的供应商，是在告诉你一件关于这类项目如何失败的真话。我们关于遗留系统现代化，重写还是重构 的笔记讲了这场考古会挖出什么。

采购占掉一半工作量

多数技术人员把这部分低估了三倍。在一个真正企业级的合作里，从第一次谈话到第一行代码之间的工作比第一个交付增量还长，而且消耗双方的资深人力。

自 2025 年 2 月 24 日起，英国公共部门按 Procurement Act 2023 运作，投标公共合同的供应商必须在扩展后的 Find a Tender 服务里注册到中央数字平台上。私营部门的采购没有对等的统一入口，这反而让它更慢，因为每个买方都自己发明了一套。

安全问卷

你会收到一个表格文件。它会问你的开发生命周期、访问控制、打补丁的节奏、分包商、数据驻留地、事件响应时间和背景调查。较大的买方会发来几百个问题，一家银行或一个 NHS 信托会发得更多。

问题本身不难，但只有在答案已经以制度形式存在时才答得上来。一个在投标过程中才第一次拼凑这些答案的供应商要花四到六周，而且会答错几个。做过一次的供应商，从一份持续维护的答案库里几天就答完了。这是偏向他们的正当理由。

供应商准入、保险与财务审查

准入与投标是两回事，而且常常并行。你会被要求出示买方指定额度的职业赔偿险和网络责任险、雇主责任险，有时还有产品责任险。企业买方常要求小咨询公司默认没有的赔偿限额，而在投标中途提高保额是要时间的。

接着是财务审查。买方会调取已报送的财报，跑一次信用评分，在更大的合同上还会要月度管理账目或母公司担保。资产负债表撑不起合同金额的供应商，不论技术上多优秀都会被排除，这就是有能力的小公司为什么会输掉本来适合它们的标。

销售周期为什么比第一个增量还长

把两条时间线并排放，问题的形状就清楚了。资格确认、需求、安全审查、法务谈判、保险举证和准入手续，在一份价值数十万 GBP 的合同上通常要占掉四到九个月。而开工之后第一个有用的软件增量，可能十周就出来了。

在这个周期开头写下的估算，到签约时已经过期，一个在这段空档里坚持固定价格的供应商，要么加了很厚的水分，要么打算以后就范围吵一架。技术假设同样会老：投标时还是当前版本的东西，到启动时可能已经不再受支持。

给每一份估算标上日期，写清它的前提，并在签约时约定一次重新基线，而不是假装那个数字活了下来。坚持原始数字有效的买方，买到的是一条变更申请流水线。我们关于怎么写一份能拿到有用报价的软件 RFP 的指南讲了这份文件里该有什么。

真正的交付物是非功能需求

功能清单容易写，也很少决定什么。决定架构、基础设施账单、团队规模和测试周期长度的是非功能需求，而在多数企业项目里，它们在一份功能清单长达四十页的文档中只有两段。

这种失衡是最可靠的超支预兆。一个把第一次工作坊全部花在可用性、恢复、延迟、吞吐、可审计性和留存期上的供应商不是在拖延：这六个数字会砍掉大部分架构选项，而晚了再定就意味着重建。

把它们写成带数字和条件的可测试陈述。“系统必须高可用"不是需求。“订单服务必须在负载均衡器处测得的月度可用性上维持 99.9%，提前五个工作日通知的两小时窗口除外"才是，因为测试可以判它不合格。

用大白话讲恢复点和恢复时间

这些数字里有两个比任何功能都更能推高成本，而且经常被把含义弄反的人挂在嘴边。恢复点目标 (RPO) 是你愿意丢多少数据：RPO 一小时意味着你接受灾难之后最多丢掉一小时的交易，而你的备份或复制方案必须保证不会比这更差。恢复时间目标 (RTO) 是你愿意停多久，所以 RTO 四小时意味着服务要在事故开始后四小时内重新处理流量。

两个数字都直接翻译成架构。AWS 在它的灾难恢复指南里列出四种大方向：备份与还原、试点灯、温备，以及多站点双活。它们从便宜且慢排到昂贵且几乎瞬时，而一旦这两个目标定下来，选择就替你做好了。

不要因为听起来负责任就答应激进的数字。RPO 为零加上分钟级的 RTO，意味着持续复制和第二套在线环境，基础设施账单大致翻倍。我们关于小型软件团队的灾难恢复 的文章展示了更便宜的档次买到的是什么。

可用性算术，以及一份 SLA 实际买到了什么

可用性百分比把含义藏在小数点后面。在一个 30 天的月份里，99.9% 允许大约 43 分钟的停机，99.95% 允许大约 22 分钟，99.99% 允许大约 4 分钟。这是整个月的全部预算，包括部署、证书续期，还有那次比预想更久的数据库切换。

每月 4 分钟，对一个在工作时间部署、只呼一名工程师的团队来说做不到。它需要每一层的冗余、自动切换、不中断流量的部署，以及凌晨三点还醒着的人。最后这一项通常比基础设施还贵，而且几乎从不在原始预算里。合同里也要把测量点定死，因为在负载均衡器上读到的可用性和从真实用户遥测里读到的可用性，同一次事故可以差一个数量级。

延迟、吞吐，以及那份没人测过的负载

延迟目标需要一个百分位和一个范围，因为平均值会把失败盖住。“结算接口在每秒 400 个请求下第 95 百分位 200 毫秒"这样的目标可测。“快"不可测，平均值也一样，因为平均 200 毫秒完全可以和二十个用户里有一个等四秒并存。

吞吐需要的是峰值，不是均值。零售商按圣诞节前的星期五定容量，薪资系统按当月最后一个工作日，公共服务按信件上写的截止日期。按年度平均值定容量，就是新系统在第一个忙碌小时里垮掉的原因。峰值从现有系统的日志里取，十比一的比例很常见，而这个比例决定了设计里要不要一个队列。

可审计性与留存期

受监管的买方，以及越来越多不受监管的买方，需要在很多年之后回答谁在什么时候改了什么。那是一项设计要求，不是一项日志配置：一个会覆盖行的系统答不出来，而这个答案必须活到留存政策规定的期限。

早点定下三件事。哪些事件要审计，通常是对具有法律或财务意义的记录的状态变更，而不是每一个 HTTP 请求。每一类记录保存多久，这是一个法律问题，还挂着一条数据保护约束，因为把个人数据留得比必要更久本身就是违规。以及谁能读这条痕迹，因为管理员可以改的审计日志什么也证明不了。留存和删除权在这里冲突，而这份张力是在数据模式里解决的，不是在政策里。

买方会要的那些认证

反复出现的有三个，它们不断被混为一谈，而它们证明的是不同的东西。一个说不清区别的供应商并不持有它们。

Cyber Essentials 与 Cyber Essentials Plus

Cyber Essentials 是英国政府支持的基线，由 NCSC 制定，通过其官方交付伙伴 IASME 交付。它覆盖五项技术控制：防火墙、安全配置、安全更新管理、用户访问控制和恶意软件防护。基础级是一份经独立复核的自评问卷，NCSC 列出的价格按组织规模从 GBP 320 外加增值税起。

Cyber Essentials Plus 是同样这五项控制，由独立的技术审核来验证而不是靠声明。评估方会做内部和外部的漏洞扫描，并抽样测试用户设备、互联网网关和面向互联网的服务器。Plus 审核必须在基础认证之后三个月内完成，两张证书的有效期都是十二个月。

这套机制在商业上和技术上一样要紧。自 2025 年 2 月 24 日起对中央政府部门、其下属机构、非部门公共机构和 NHS 机构生效的 PPN 014，要求供应商在处理公民个人信息、政府雇员个人信息，或处理 OFFICIAL 级别数据的 ICT 系统时必须持证。

ISO/IEC 27001

ISO/IEC 27001 是信息安全管理体系的国际标准，由 ISO 和 IEC 发布。当前版本是 ISO/IEC 27001:2022，2024 年的第 1 号修正案按照 ISO 管理体系标准整体的一项变更，在组织环境相关条款里加入了气候行动的措辞。

它是一份管理体系标准，买方误读的正是这一点。它并不规定一套每家获证组织都实施了的固定控制。它要求组织定义自己的范围、评估风险、选择控制，并运行一个有文档的评审与改进循环。证书由获得认可的认证机构在审核之后颁发，不是由 ISO 自己颁发。

所以有用的问题从来不是供应商有没有它，而是证书上的范围声明覆盖了什么。一个只限于总部职能的范围，对那支握着你源代码和生产凭据的团队什么也没说。把证书要过来，读那段范围。

SOC 2

SOC 2 是美国的东西，性质也不同。AICPA 把它定义为"一份关于服务组织中与安全性、可用性、处理完整性、保密性或隐私相关的控制的报告”，依据其信任服务准则执行。它是由注册会计师事务所出具的鉴证报告，不是证书，没有及格线也没有可以挂出来的标志。

真正要紧的区别是类型。Type 1 报告描述这些控制，并评估它们在某个时点上设计是否恰当。Type 2 报告则测试它们在一段时期内是否有效运行，通常是六个月或十二个月。Type 1 是一张照片，Type 2 是一段影片，把 Type 1 当作等价物接受的买方，收到的东西远比他们以为的少。

读报告，别读封面。审计师记录哪些控制没有按描述运行的例外章节才带着信息，而那正是供应商希望你跳过的部分。

它们都证明不了的事

三者没有一个能证明你的软件是安全的。Cyber Essentials 覆盖的是基础设施卫生的一条基线。ISO 27001 覆盖的是这个组织有没有把安全当作一个过程来管理。SOC 2 覆盖的是声明过的控制在一段时期内是否运行过。三者关心的都是供应商，不是产品。

应用安全是另一门学科，证据也另有一套。要最近一次渗透测试报告及其整改状态，而不是那面证书墙，并且看清是谁做的、针对什么范围做的。这就是我们渗透测试服务背后的实质。

按行业划分的监管暴露

通用的企业级建议在监管这里会变得不安全。下面只列出可核实的义务，不越界到法律意见，那应该由有资质的顾问提供。

几乎适用于所有人的英国 GDPR

如果系统碰到个人数据，英国 GDPR 第 32 条同时适用于控制者和处理者。它要求适当的技术和组织措施，并点名了四项：假名化与加密，处理系统持续的保密性、完整性、可用性和韧性，事故之后及时恢复个人数据的可用性与访问的能力，以及一套定期测试和评估这些措施有效性的流程。

把第三项再读一遍，因为它把灾难恢复变成了一项数据保护义务，而不是运维上的偏好。ICO 的数据安全指引把 Cyber Essentials 指为一条有用的基线，同时明确说它只是一组基础控制，不会覆盖每个组织的处境或每项处理活动的风险。

金融与医疗，简短而谨慎

在金融服务领域，FCA 的运营韧性制度要求在管辖范围内的机构识别重要业务服务，为它们设定影响容忍度，并能在严重但可能发生的中断期间保持在容忍度以内。过渡期已于 2025 年 3 月 31 日结束，所以这项义务是生效的，它决定了这些机构的供应商必须拿出什么证据。

在医疗与照护领域，一套医疗 IT 系统会触及 NHS England 的临床风险管理标准：面向制造方的 DCB0129，以及面向部署方组织的 DCB0160。两者都在国家层面的复审之中，公开咨询从 2026 年 6 月 29 日进行到 2026 年 9 月 11 日，所以在依赖任何摘要（包括这一篇）之前，请先确认当前状态。

如果这里没点到你的行业，就按通用办法处理这项义务：找出监管机构，读它自己公布的要求，并让供应商针对那些要求举证，而不是拿一段泛泛的保证叙事来搪塞。

钱花在集成架构上

企业级成本集中在系统之间的接缝里，不在系统内部。功能通常是清楚的。让六套数据模型不同、对"客户"的理解也不同的系统达成一致，才是日程消失的地方。

点对点还是中间代理

点对点是默认选项，因为第一条集成确实这样更简单。代价是组合式增长：n 个系统直接对话，连接数会朝 n 的平方走，每条都有自己的重试逻辑、凭据和监控。四个系统时没问题，十五个时就维护不动了。

一个代理或事件总线会把这条曲线扭转过来。它增加一个组件、一份运维负担，以及一个需要在设计上绕开的单点故障，通常在第六到第八个参与方时开始回本。错误在两个方向上都会犯：小环境买了它们不需要的集成平台，大环境则一直拖到网状连接已经硬化。

同步还是事件驱动

同步调用容易推理，也会把可用性耦合在一起。如果你的服务内联调用四个系统，而每个都有 99.9% 的在线时间，那么在你写出第一个 bug 之前，你自己的上限大约是 99.6%。每一条同步依赖，都是把你自己可用性的一份交给别人的运维团队。

事件驱动的设计解开了这层耦合，代价是最终一致性和难得多的排障。把同步调用留给用户正在等待、且过期答案不可接受的路径，其余的都搬到事件上。这件事按每次交互来决定，而不是当成一种家规。

幂等、重放与对账

分布式系统会把消息投递不止一次，偶尔还会丢，所以每一条跨边界的写入路径都必须可以安全重复。已经确立的做法是由客户端生成幂等键。Stripe 的实现会保存某个键的第一次请求的状态码和响应体，在重试时返回同样的结果，至少 24 小时后清理键，并在同一个键带着不同参数到来时报错。

重放是同一个想法的运维另一半。当一个下游系统不可用了六小时之后，得有人把错过的消息推过去，而这只有在消费方是幂等的、并且消息被保留下来时才安全。把保留窗口和重放机制和正常路径一起设计，因为事后补上意味着改动每一个消费方。

对账常被当成事后补丁，它不该是。它是一个定时任务，比较两个本该一致的系统的状态，报告差异，然后要么纠正它们，要么交给人处理。没有它，与财务系统之间一次无声的偏离会在几个月后由审计师发现。把它当作有负责人和告警路径的一级交付物列进预算，而不是最后有人随手写的一个脚本。

与遗留系统共存和绞杀榕

整体替换一套还在跑的系统，是可选项里风险最高的一个，而它被选中的频率远高于应该的次数。渐进式的替代做法由微软记录为绞杀榕模式：在遗留系统前面放一层门面，让请求从它经过，再把功能一块一块搬过去，直到老系统没有流量可接，就可以关掉。

每一个增量都独立有价值，也独立可回退：如果第三块搬砸了，就把它路由回去。微软明确说了它不适用的场合，也就是无法拦截发往后端的请求时、无法修改遗留源码时，或者系统小到直接整体替换更省事时。

有两个细节决定它能不能成。门面绝不能变成瓶颈或单点故障，所以它需要和它背后的服务同样的可用性工程。而过渡期间的跨系统调用需要一层防腐层，好让遗留的语义不渗进新设计。数据比流量更难：把一个领域的表搬出去，意味着一次初始加载、一条变更数据捕获的流、一段两边都写并做比对的验证期，然后才是切换，而且在遗留对象被删除之前都还能回滚。

企业规模上的测试

企业项目的测试与其说是工程问题，不如说同时是后勤问题，也是乐观计划死掉的地方。

环境

你需要的会比预算里的多：开发环境、一个接到对手方沙箱上的集成环境、一个足够贴近生产以至于数字有意义的性能环境、一个稳定到能让忙碌的非技术人员用的验收环境，还有生产环境。每一个都有基础设施成本、一套刷新流程和一位负责人。总是被砍掉的那个是性能环境，而省掉它就意味着在生产上做压力测试。

测试数据与个人数据难题

企业系统需要真实的数据来测试，而真实的数据就是生产数据，里面装着个人信息。把它复制到测试环境属于英国 GDPR 下的处理行为，第 32 条的义务也一路跟过去，包括访问控制和承载它的那个环境的安全性。

站得住脚的答案是匿名化，它必须不可逆才能把数据带出监管范围；或者假名化，它降低风险但仍在范围之内。两者都需要工程工作来保住让这些数据有用的统计形状，还需要一套有文档的流程。把生产数据库还原到一个共享测试环境很常见，在很多配置下并不合法，而且正是一次供应商评估想要暴露出来的事情。

性能测试

性能测试回答的是系统能不能达到之前商定的吞吐和延迟数字，所以只有那些数字被写下来它才可能存在。测峰值形态而不是均值，而且要包含峰值的形状，因为十分钟内爬升和一秒内跳变会触发不同的失败模式。

在生产级数据量上跑。一个在 10,000 行上瞬间返回、在 4,000 万行上完全不可用的查询，是企业软件里最常见的性能缺陷，而它在小数据集上根本看不见。

由另有本职工作的人来做验收测试

验收测试通常被排成两周的窗口，也是最可靠地会超期的阶段，因为测试者就是业务专家，而业务仍然需要他们。他们每周只能给你几个小时，到月末他们的可用时间会归零。

在合同里点名测试者，商定每周的小时数，事先把场景写成脚本而不是请人自由探索，并把缺陷分诊当成一场联合会议来开，而不是一条工单队列。一个报了两周验收测试却说不出参与者名字的供应商，没有真正跑过一次。

交付模式与治理

行得通的团队形态是小而稳定，不是大而轮换：一位为整个项目的架构负责的技术负责人、三到六名工程师、一位处理对手方日历的交付负责人，以及共享的质量工程师和基础设施专家。中途加人可靠地会让项目变慢，因为瓶颈是上下文，不是人手。

在第一个冲刺之前把决策归属写下来。指定一个人可以批准范围变更，一个人可以批准架构取舍，一个人可以验收发布。如果那是三个名字，决策要几天。如果那是三个委员会，决策要几周，而计划是虚构。

指导例会的节奏让一个长项目保持诚实：每两周与工作组做一次交付评审，每月把预算持有人和拥有否决权的人拉进同一个房间做一次指导会，以及一份对照原始基线而不是上个月修订版的书面状态报告。一个状态永远是绿色的供应商不是在管理风险，是在藏风险。

商务模式，以及风险由谁承担

四种模式几乎覆盖了全部，每一种把风险放在不同的地方。问题不是哪一种最好，而是面前这份不确定性由哪一方来扛更合适。

工时计费适合真正不确定的工作：探查、遗留系统考古，或者对着一个文档很差的对手方做集成。买方承担风险并获得完全的灵活性，这需要信任，也需要有人真的盯着消耗速度。

带上限的工时计费加了个天花板，通常是那个明智的折中，我们大多数软件开发服务也是这样组织的。超过上限的部分由供应商吸收，买方在上限以下只为用掉的部分付钱，双方都把范围维持得诚实。上限里应当带上百分之十五到二十五的余量，因为一个按期望成本封顶的供应商，要么算错了，要么正在筹划一份变更申请。

固定价格只有在范围真正固定时才成立，而在企业项目里，这对一个增量成立，对整体不成立。六到十周的固定价格增量，每一个都在上一个落地之后再定范围，能给出预算确定性，又不必假装有人能把十八个月的事提前写清楚。

托管服务是系统上线之后的正确形态：一笔按月的费用，覆盖支持、打补丁、监控和一份定额的变更额度，按建设成本的年度百分比定价，而不是按人头。让服务定义里写明响应时间和升级路径。

企业软件开发服务：什么在推高成本

按影响大小排列的成本驱动因素

这个顺序会让人意外，因为功能排在最后。第一位是集成面，具体说是外部所有方的数量，而不是接口的数量。第二位是非功能目标，因为从一个可以停维护窗口的服务跨到一个不能停的服务，会改变设计的每一层。

第三位是保证与监管负担：投标时间、证据制作、审计支持，以及在整个合同期内都更慢的发布流程。第四位是数据迁移与对账，它被一贯低估，因为难点在旧数据的质量而不是数据量。第五位是干系人群体的数量，它决定决策延迟。第六位是环境数量。功能范围排第七，而它通常是原始预算里唯一的一项。

英国的参考价格区间

下面的区间是我们从英国项目得来的内部估算，按第一年成本表示，含探查、建设、测试和上线，但不含买方自己的人力时间。它们是参考而不是报价，区间之所以宽，是因为上面那些驱动因素会推动它们。

不用表格也能说清：一个有两三条集成、面向内部用户、目标 99.5% 的单一服务，第一年落在 GBP 120,000 到 GBP 250,000 之间。一个有五到八条集成、99.9% 的面向客户的部门级系统，是 GBP 300,000 到 GBP 700,000。一个替换遗留系统、有十到二十条集成、目标 99.95% 的核心平台，是 GBP 900,000 到 GBP 250 万。一个 99.99% 的跨多法人受监管项目，从 GBP 250 万 左右起步，并往上走。

预算里没有的运行成本

在这之上还要加上每年的运行成本，在算进支持、托管、打补丁、安全工作和一份适度的变更额度之后，它落在建设成本每年的百分之十五到二十五之间。一份只给建设出钱、不给运行出钱的预算，产出的是一个在第二年肉眼可见地衰败的系统，我们对软件维护成本的拆解讲了这笔钱都花到哪去了。

退出与延续性

一个你离不开的供应商，是一份坐在你资产负债表上的风险，而且它是最常被留到谈判末尾、没人再留意时才处理的条款。有四件事让退出成为可能。

源代码和它的历史应当放在一个买方拥有、或可凭通知接管的代码仓库里，连同构建流水线和基础设施定义。没有构建流水线的代码是一份档案，不是一项可用资产。

文档应当足以让一个称职的第三方运行这套系统：架构、集成契约、针对真实发生过的故障模式的操作手册，以及凭据清单。我们关于会被人真正读的技术文档 的文章讲了什么能挺过一次交接。

源码托管应对的是供应商倒下而不是离开，做法是把源码存放在第三方处，在约定的触发条件下放行。当供应商相对合同金额偏小时，它值得有；而且值得仔细读，因为一份未经验证的存放放出来的是编译不了的代码。我们在软件源码托管，到底谁需要它 里讨论过它什么时候站得住脚。

最后，把交接在合同里定好价。一个按商定费率计的、经通知触发的、指定天数的知识转移，把一场争吵变成一张发票。同样的纪律也适用于你的供应商的供应商，我们在关于软件供应链安全的笔记里讲过。

一次会面里判断供应商的企业级底气

五个问题能在一小时里问出大半，而犹豫本身和答案一样说明问题。

问他们交付过哪些可用性和恢复目标，以及可用性是怎么测的。一个扛过 99.95% 义务的供应商，不用提示就会说出测量点和值班安排。没扛过的会泛泛地谈冗余。

要看他们 ISO 27001 证书上的范围声明，或者他们 SOC 2 Type 2 里的例外章节。对持有它们的供应商来说这两件都是寻常请求，对只有一个标志的供应商来说则很尴尬。然后问他们在生产环境里怎么处理过一次对账差异，这是没法从理论上答出来的。

问他们最近三个项目各超支了多少、为什么。所有人都会超支，有信息量的是他们知不知道那个数字。然后问他们的退出流程长什么样，用天数和交付物来说。一个把这件事写下来的供应商，预期自己会因此被评判。

这给买方留下了什么

企业级这个词应当描述义务，而不是一个价格档。一旦集成面、可用性与恢复目标、监管暴露和退出条款都写了下来，候选名单会自己排出来，因为大多数供应商没法针对这四项拿出证据。

Mecanik 通过我们的软件开发服务承接这种形态的合作，保证这一侧则通过渗透测试服务。如果你还在拼装需求而不是拼装候选名单，技术尽职调查清单是个不错的起点，而那些非功能数字值得最先争论。

常见问题

什么算是企业软件开发？ 企业级由约束定义，而不是由买方的规模定义。一个项目符合条件，是因为它有一个由多方拥有的宽阔集成面、一项合同上的可用性与恢复义务、监管暴露、几个各自都能拦下发布的干系人群体、会压垮朴素设计的数据量，以及必须与没人完全理解的遗留系统共存。一家大公司可以订一个普通项目，一家受监管的小公司也可以订一个货真价实的企业级项目。

在英国做一个企业软件开发项目要花多少钱？ 按我们从英国项目得来的内部估算，一个有两三条集成、可用性目标 99.5% 的单一服务，第一年是 GBP 120,000 到 GBP 250,000。一个 99.9% 的面向客户的部门级系统是 GBP 300,000 到 GBP 700,000。一个替换遗留系统的核心平台是 GBP 900,000 到 GBP 250 万。再按建设成本每年加上百分之十五到二十五，用于运行和支持。

企业级供应商需要 ISO 27001、Cyber Essentials 还是 SOC 2？ 它们证明的是不同的东西。Cyber Essentials 是英国政府支持的五项技术控制基线，其 Plus 层级由独立技术审核验证，并被 PPN 014 要求用于许多公共部门合同。ISO/IEC 27001:2022 认证的是一套信息安全管理体系，所以证书上的范围声明比证书本身更要紧。SOC 2 是由注册会计师事务所出具的美国鉴证报告，只有 Type 2 才测试控制在一段时期内是否运行过。

什么是恢复点目标和恢复时间目标？ 恢复点目标 (RPO) 是你接受在灾难之后丢掉多少数据，所以 RPO 一小时意味着最多可能丢掉一小时的交易。恢复时间目标 (RTO) 是你接受服务不可用多久，所以 RTO 四小时意味着服务必须在四小时内重新处理流量。两者比任何功能都更能推动架构和成本，因为它们要在备份与还原、试点灯、温备和多站点双活之间做出选择。

企业软件合同里关于退出应该写什么？ 四件事。对代码仓库、构建流水线和基础设施定义的所有权或可转让的访问权。足以让一个称职的第三方运行这套系统的文档，包括操作手册和凭据清单。在供应商相对合同金额偏小时的源码托管，而且是经过验证的存放而不是未经验证的。以及一条定了价的交接条款，写明知识转移的天数和费率，好让离开成为一张发票而不是一场争议。