2026 代码搜索服务器租用配置攻略：Sourcegraph 索引仓库数与内存盘怎么估 + 上线避坑手册

2026 代码搜索服务器租用配置攻略：Sourcegraph 索引仓库数与内存盘怎么估 + 上线避坑手册

代码搜索服务器选型前先厘清：索引构建与在线检索是两条完全不同的资源曲线

给代码搜索选服务器，最常见的翻车姿势是把它当成一台普通的 Web 应用服务器来估配置：按并发人数估 CPU、按页面大小估带宽、按数据行数估磁盘，结果上线第一天跑全量索引就把机器压趴。代码搜索这类系统的资源消耗，本质上是两条曲线叠在一起的。第一条是索引构建曲线，周期性、突发、吃满 CPU 与磁盘写入；第二条是在线检索曲线，全天候、单次请求小但延迟敏感、吃内存常驻与磁盘随机读。这两条曲线的峰值并不重合，形状也完全不同，你拿其中任何一条单独去估配置，最后买回来的一定不是这台机器真正需要的规格。

这两年接触到代码搜索选型咨询的团队，大致可以归成三类。第一类是几十人的研发团队，人数不多但语言杂，Java、Go、TypeScript、Python 混在一个组织里，日常诉求很朴素——能不能一次性搜出某个函数在所有服务里的调用点，他们的痛点不在并发，而在索引覆盖是否完整、查询是否要等。第二类是两三百人规模、多语言仓库的组织，代码总量和提交频率都上来了，白天检索压力大，夜里还要跑增量索引和仓库同步，两条曲线的峰谷互相挤压，配置只要卡紧一点，就会以"搜一下要好几秒"这种体感方式告警出来。第三类是做跨仓库重构与合规审计的平台工程组，用户数未必多，仓库数却极多，单次查询的跨仓库范围极大，属于典型的"仓库数决定档位"而不是"人数决定档位"。

所以本文的落点很直接：不讨论代码搜索好不好用，只讨论这台机器该怎么选。我们把 Sourcegraph 官方公开的自托管规格表逐行读清楚，把"用户数 + 仓库数"两个维度的定档规则拆开，把索引究竟吃哪三样资源讲明白，再把单节点脚本部署要求的两块盘、Kubernetes 部署的节点建议、升级换机器的官方流程、443 与 22 端口的网络前提这些上线前必踩的坑一次排完。凡是有官方口径支撑的地方我直接给数字，官方没给的地方我会明确标注这是基于假设的推导，别把推算当成承诺。

按 Sourcegraph 官方规格表定档：用户数与仓库数两个维度怎么读，落在两档之间取大者

Sourcegraph 官方自托管规格表是按"用户数 + 仓库数"两个维度来定档的，一共五档，从 XS 到 XL。用户数上限依次是 500 / 1,000 / 5,000 / 10,000 / 20,000；仓库数上限依次是 5,000 / 10,000 / 50,000 / 100,000 / 250,000；对应的 vCPU 是 8 / 16 / 32 / 48 / 96；对应的内存是 32GB / 64GB / 128GB / 192GB / 384GB；磁盘方面五档全部要求 SSD，这一条是硬性要求而非建议项。把这几行数字并排放在一起看，会发现一个值得注意的规律：规格表的资源投入节奏更贴近仓库数那条线，而不是贴近人数那条线，vCPU 与内存基本上是随档位整体抬升的，并没有为"人多仓库少"的场景留出便宜的口子。

真正决定你要掏多少预算的，是官方的选档规则：落在两档之间时取大者。这句话要拆成两步来执行才不会算错。第一步拿你的用户数去对照用户数上限，看它落在哪一档；第二步拿你的仓库数去对照仓库数上限，看它落在哪一档；两个结果取较大的那一档，就是你要买的规格。注意这里既不是取平均，也不是看哪个更接近边界，而是无条件取大者。官方给出的两个示例把这条规则的后果说得很清楚：8,000 用户 + 80,000 仓库按 L 档；而 1,000 用户 + 80,000 仓库，官方口径同样取 L 档，理由就是仓库数落进了 L 档。哪怕用户数只有前一个示例的一小部分，只要仓库数进 L，机器就得按 L 档买。

这条"取大者"规则背后的逻辑其实不难理解。人数影响的主要是并发检索请求和界面响应，是弹性的压力，可以被排队、被缓存、被错峰吸收；而仓库数影响的是索引体量、索引常驻内存占用，以及磁盘随机读的覆盖范围，是刚性的、躲不掉的常驻成本。一个二十人的小组如果管着几万个仓库，它在索引这个维度上的机器开销，和一个两千人的组织管同样多仓库时的开销，几乎是在同一量级上。所以别拿"我们人少"当砍配置的理由，官方规格表已经替你把这条后路堵死了；反过来也一样，别拿"我们人多"去要求更大的机器，如果仓库数没上去，规格表同样不会因为你人多就往上跳档。

档位定下来之后，落到公有云上还有一层现成的对应关系。官方给出的机型建议是：AWS 对应 m6a.2xlarge / m6a.4xlarge / m6a.8xlarge / m6a.12xlarge / m6a.24xlarge；Azure 对应 D8_v3 / D16_v3 / D32_v3 / D48_v3 / D64_v3；GCP 对应 n2-standard-8 / n2-standard-16 / n2-standard-32 / n2-standard-48 / n2-standard-96，五个档位一一对应。这三组机型的命名规律也印证了前面的判断：规格表本质上描述的是一台"CPU 与内存等比放大、磁盘必须为 SSD"的通用计算型机器，不涉及 GPU、不涉及特殊加速卡、也不依赖某种 exotic 的本地盘。对于自建机房或者租用物理机的团队来说，这是个好消息——你不需要为了代码搜索去采购任何特殊硬件，按这个 vCPU 与内存的比例关系配一台 SSD 机器即可，选型自由度比想象中高得多。

从 8,000 用户 + 80,000 仓库到 400 人小队：三个自算示例看「取大者」怎么改写预算

第一个示例直接用官方口径：8,000 用户 + 80,000 仓库。用户数 8,000 落在 L 档（上限 10,000），仓库数 80,000 同样落在 L 档（上限 100,000），两个维度同档，结果毫无悬念是 L：48 vCPU、192GB 内存、SSD 必备。这是最省心的一类情况，两个维度同步增长，选档不需要任何纠结，你要做的只是确认仓库数在未来半年内会不会冲破 100,000——一旦冲过去就得进 XL，那是一次从 48 vCPU 到 96 vCPU、从 192GB 到 384GB 的整机跳升，预算曲线在这里会陡一下，值得提前跟财务打招呼。

第二个示例是官方特意给出的反直觉场景：1,000 用户 + 80,000 仓库。用户数 1,000 落在 S 档（上限 1,000），仓库数 80,000 落在 L 档，取大者之后结果是 L。也就是说，这家组织只有前一个示例八分之一的用户规模，却要买和前者一模一样的机器。这个结果在做预算评审时最容易被挑战："我们人就这么多，为什么机器要那么大？"——答案就写在规格表里：决定索引常驻成本和检索扫描范围的是仓库数，不是人数。如果你的组织正好是这种形态（少数人管海量仓库，比如平台工程组、代码托管平台的内部检索、安全审计团队），请把这一段连同官方的两个示例一起贴进预算申请里，比你自己解释一百遍都管用。

第三个示例是我们自己按规则推的，用来说明反向情况同样成立，前提是完全套用官方的取大者规则：假设一家公司 3,000 用户 + 6,000 仓库。用户数 3,000 落在 M 档（上限 5,000），仓库数 6,000 落在 S 档（上限 10,000），取大者之后结果是 M，也就是 32 vCPU、128GB 内存。看清楚了吗——这家公司仓库才六千个，却因为有三千人要用，被推到了中档。这正好说明"取大者"是一把双向的尺子：它既保护了人少仓库多的团队不被低估，也要求人多仓库少的团队为并发检索买单。所以真正省钱的思路不是去钻规则的空子，而是把两个数字都估准，尤其是仓库数，最好按未来一段时间的规划值而不是今天的统计值来填。

索引真正吃的是三样：CPU 并行度、内存常驻、SSD 随机读

先说 CPU 并行度。索引构建这件事在资源曲线上长得像锯齿：新仓库接入、全量重建、大版本同步时，CPU 会在一段时间内被打满，然后迅速回落到低位的增量维护状态。核数多少决定的不是"能不能跑起来"，而是"这段打满的时间有多长"。8 vCPU 也能跑完索引，只是慢，慢的后果是索引滞后于提交——开发者刚推的代码搜不到，这才是体验崩坏的真实来源。所以 CPU 这根曲线的最佳状态不是峰值有多高，而是构建速度能否稳定追上提交速度，让索引滞后始终保持在一个团队可以接受的范围里。这一点在选档时容易被忽略，因为官方表只给了核数，没给"多少个仓库配多少核才追得上"的答案，这属于需要你自己实测的部分。

再说内存常驻，这是三条曲线里最"硬"的一条。索引一旦建起来就要常驻在内存里，随着仓库数增加呈阶梯式上升，而且几乎不回退——删掉几个仓库才会降，日常运行中它是一条单调不降的台阶线。内存不够的时候系统通常不会直接报错，而是退化成频繁换页和磁盘回源，表现形式是检索延迟抖动、时快时慢。所以内存是这三项里"买少了最难受"的一项：CPU 不够你可以等一等，磁盘不够你可以慢慢扩，内存不够你的每一次查询都在付出代价，而且是全天候付出。这也是为什么 XL 档会一路给到 384GB——不是为了好看，是为了让海量仓库的索引真正待得住。

第三样是 SSD 随机读。在线检索的访问模式是跨文件、跨仓库的随机跳转，一次查询可能要碰成百上千个索引分片，这种访问模式下机械盘的寻道开销会把延迟放大到完全不可接受的程度；索引构建期的写入同样以随机写为主，也不是顺序带宽能救回来的场景。所以官方在规格表里对五档统一写了 SSD（必须），没有任何一档允许例外。这条曲线的形状是持续压力型：它随仓库数与并发检索量抬升，没有特别夸张的尖峰，但也不会自己降下来。把三条曲线叠起来看，你会得到一个很实用的判断——CPU 是"峰值问题"，内存是"容量问题"，SSD 是"介质问题"，三者不能互相替代，加内存救不了机械盘，换更快的 CPU 也救不了内存不足。

根盘 50GB 空闲与独立数据盘 250GB 起：单节点脚本部署为什么坚持要两块盘

如果你打算用官方的单节点脚本部署，磁盘这一关有明确的前提条件，而且是两个必须同时满足的条件。第一条：根盘至少要有 50GB 空闲空间，用来放临时数据。第二条：必须准备第二块独立的数据盘，最小 250GB，而且这块盘必须是与系统盘不同的另一块盘——脚本会把它格式化并挂载到 /mnt/data。官方还明确要求这两块盘背后都应该是 SSD 或者同等性能的存储。请注意这三条里的措辞强度：50GB 是"空闲空间"而不是"总容量"，250GB 是"最小"而不是"推荐"，第二块盘是"必须与系统盘不同"而不是"建议分开"。把它们当成硬性验收项来对待，是最省事的做法。

为什么官方要如此坚持两块盘？答案藏在后面的升级流程里。单节点脚本部署的升级方式是"换机器不换数据盘"：把数据盘从旧实例上卸下来，挂到一台新启动的同规格机器上，再跑一遍安装脚本，服务就恢复了。如果索引和仓库数据与操作系统挤在同一块盘上，这个流程根本无法执行，你只能做整机镜像迁移或者原地重灌，风险和停机时间都会上升。独立数据盘带来的另一个好处是快照可以单独做在 /mnt/data 这一层，粒度更干净，恢复时也只影响数据本身，不会把系统盘一起回滚到旧状态。

那么各类数据到底放在哪？按官方脚本的行为，被格式化挂载到 /mnt/data 的这块盘承载的是代码搜索的持久状态，也就是索引数据、仓库数据以及运行时产生的时态数据这些需要跨重启、跨升级长期保留的部分；根盘那 50GB 空闲更多是给临时数据、安装过程和系统自身留的余量。这里有一个上线前必须反复确认的操作风险：脚本会格式化这块盘。也就是说，如果你在部署时把设备名指错，指向了一块还存着别的数据的盘，那些数据会直接被清掉。这不是理论风险，是脚本设计使然。所以我们的建议是，新机器到手后先列一遍块设备清单，确认哪一块是空的、哪一块是系统盘，只在确认无误后再执行安装脚本，并且在此之前把任何还在犹豫的盘先物理或逻辑上摘掉。

XS 到 XL 五档机型对照：用户数与仓库数上限、vCPU 与内存、磁盘要求与团队形态一次对齐

下面这张表把前面分散在各段的数字收拢到一处，方便你在做预算或者跟机房对接时直接照着念。读表的顺序建议固定为：先填最右两列的团队形态与需确认事项，再往左推档位，最后看 vCPU 与内存——因为档位是由用户数和仓库数决定的，不是由你"想要多大内存"决定的，倒着读很容易自欺欺人。

最后那一行是早期版本文档给过的入门口径：至少 2 vCPU 与 7.5GB 内存起步，视团队规模与仓库数增加。它被我们放进表里，不是为了让你照着买，恰恰相反，是为了让你在看到这段老说法时能立刻反应过来——那是给试跑环境用的，正式生产请严格按 XS 到 XL 五档来选。行业里确实有不少团队是先在极小规格上跑通了功能，然后直接把那台机器推上生产，结果索引一建就把内存吃穿，再回头换机器，白白多折腾一轮。这张表的价值就在于让你一次选对，而不是先踩一遍坑再回来补票。

单节点脚本部署还是上 Kubernetes：EKS、GKE、AKS 推荐节点与 Azure CSI 事后补不了的坑

代码搜索并非一定要上 Kubernetes。对于绝大多数团队，单节点脚本部署是更省心的起点：一台符合档位规格的 SSD 机器，两块盘，一个安装脚本，跑起来就能用，运维心智负担极低。什么时候才值得上 Kubernetes？我们的判断标准有三条。第一条是你需要横向扩展而不是纵向换机器——也就是说，业务上已经不允许"关机卸盘再挂回去"这种升级方式，需要滚动更新和无感替换。第二条是你已经有了成熟的集群运维体系，监控、日志、存储类、备份这些基础设施都是现成的，新建一个命名空间的边际成本接近于零。第三条是你的组织里有多套内部研发工具要统一调度资源，代码搜索只是其中一个工作负载。三条里至少要中两条，上 Kubernetes 才划算，否则就是拿运维复杂度换取并不存在的收益。

如果确定要上 Kubernetes，官方给出的推荐节点规格可以直接照抄：EKS 用 m5.4xlarge，GKE 用 n2-standard-16，AKS 用 D16 v3；使用其他环境时，官方建议每节点 16 vCPU、60GiB 内存、启动盘 100GB（SSD 优先）。这组数字和前面五档规格表是什么关系？简单说，Kubernetes 部署里你是通过节点数量去凑出等价的总资源，而不是靠单个超大节点。这意味着节点规格的选择要兼顾"调度粒度"和"资源碎片"：节点太小，索引这类大内存需求的服务可能调度不下；节点太大，又会出现资源碎片和单点故障影响面过大的问题。官方给到每节点 16 vCPU 与 60GiB 这个量级，本身就是在这两者之间取的一个平衡点，没有特殊理由不建议偏离太远。

再讲一个真正会让人翻车的坑：在 Azure 上，必须在创建集群时就让集群支持 CSI 存储驱动，事后是无法开启的。这不是"配置麻烦"，是"做不到"。很多团队在 AKS 上先按默认参数把集群建起来，等部署代码搜索需要持久化卷的时候才发现存储驱动没开，此时唯一的选择是重建集群——把所有工作负载迁走、重建、再迁回来，工期和心情都会受到严重影响。所以只要你在 Azure 上做这件事，请把"创建集群时开启 CSI 存储驱动"写进集群创建清单的第一行，并且在集群建好之后立刻验证一次动态卷供给能不能正常创建出来，不要等到部署当天才第一次试。类似的"一次性决定"在任何云上都存在，只是 Azure 这一条被官方明确点出来了，属于代价最高、最该提前确认的那类。

升级换机器不换数据盘：官方六步流程与快照节奏该怎么定

官方给出的升级流程非常具体，一共六步，顺序不能乱：先备份卷，然后关闭当前实例，接着卸载数据盘，再用同规格的新机器启动，之后把原来的数据盘挂上去，最后再跑一遍安装脚本。这套流程的设计意图很清晰——把"易变的、可重建的系统层"和"昂贵的、不可重建的数据层"彻底分开，升级时只换前者，后者原样搬过去。理解了这个意图，你就明白为什么前面要强调第二块盘必须是独立盘了：没有独立数据盘，这套流程根本执行不了，你会被迫退化成整机迁移或者原地升级，风险和停机时间都要上一个台阶。

这里要特别提醒两点。第一点，"同规格的新机器"这句话不是说你必须永远用同一个档位，而是说在换机器的那一次操作里，新机器的规格应当能承载原来那块盘上的数据量——如果你正好要借这次机会升档（比如从 M 升到 L），那就在这一步直接启动符合新档位的机器，把盘挂上去再跑脚本，逻辑上完全成立。第二点，"先备份卷"不是可选项，它是整个流程的第一步，也是有先后顺序的原因：后面的每一步都有可能出问题，卸载失败、挂载点识别不到、脚本执行中断，每一种都需要一份还没被动过的备份来兜底。把备份当成流程的装饰品，是这个行业里最常见也最致命的侥幸心理。

在自动快照这件事上，官方的表态是"强烈建议对数据盘做自动定时快照"。至于快照节奏怎么定，官方没给具体时长，我们也不打算编一个数字出来——这个节奏应当完全由你自己的变更频率和恢复目标推导。推导方法很简单：先估算团队可以接受丢失多长时间内的索引与仓库变更（注意这里丢的不是代码本身，代码在托管平台上有，丢的是索引和配置状态），再考虑重建索引需要付出的时间成本，两者权衡之后得到的那个窗口，就是你的快照间隔上限。变更越频繁、重建索引越慢的团队，快照就该越密。定下来之后别只写在文档里，要真的验证一次从快照恢复到可服务的全过程，没验证过的备份和没做备份，在事故当天没有任何区别。

443 出访、22 端口与私有化代码托管：证书、代理和 VPC 边界怎么安排

网络这一层的准备工作，建议在机器交付当天就做完，不要拖到部署当天再临时开端口。官方给出的前提是：443 端口需要出访到代码托管平台，同时也用于遥测；22 端口可以开放，用于通过 git SSH 方式克隆仓库。这两个端口的性质完全不同，处理方式也该分开。443 出访是功能成立的前提，没有它，代码搜索拿不到仓库列表、拉不到代码、也无法上报遥测，属于"不通就完全不能用"的那一类。22 端口则是克隆方式的可选项——如果你的组织统一使用 HTTPS 方式克隆，那 22 端口完全可以不开，少开一个入口就少一分暴露面，这是很朴素的取舍。

生产环境放在哪里，官方的建议也很明确：放在 VPC 或者其他受限网络里，不要裸奔在公网上。代码搜索里装着你整个组织的源代码索引，它的价值远高于一般内部系统，把它直接暴露在公网入口上是任何理由都解释不过去的安排。比较合理的做法是：机器位于私有网络内，通过内部域名或者跳板方式访问，出访到代码托管平台的 443 通过受控的出方向策略放行。这样既满足了"443 要能出去"的功能前提，又把"别人要进来"的路径收窄到可控范围。如果你的团队有跨地域办公的诉求，那就把访问入口和机器本身分开考虑，让入口层去做认证和访问控制，而不是靠把机器暴露出去来解决问题。

如果代码托管平台是私有化部署的，还会多出两个必须提前处理的问题。第一个是证书：私有化托管平台使用的证书是否被代码搜索这侧的运行时信任，需要在部署前确认清楚，自签证书的处理方式因环境而异，但无论如何不要采用"全局关闭证书校验"这种图省事的做法——那等于在你的内网里主动放弃了一层传输保护。第二个是代理：如果出访必须经过代理，那么代理的地址、认证方式、以及对 443 出访目标的可达性，都要在部署前逐项验证。我们的经验是把这类验证做成一个简单的上线前脚本，从目标机器上直接测试到托管平台的连通性，通不过就不往下走，比在部署日志里翻失败原因要高效得多。

成本取舍的明确立场：先按够用选一档预留升级路径，还是一次性上到 L 档

这个问题在预算评审会上一定会被问到，所以我们把立场讲清楚，不含糊。我们的建议是分两段看：如果你按规格表算出来落在 XS 或 S 档，那就老老实实按"够用"选，不要越级；如果你算出来已经是 M 档，或者你清楚地知道仓库数在可预见的规划期内还会继续增长，那就直接上 L 档，别在 M 上将就。这个立场不是拍脑袋，是从规格表的形状和升级流程的代价两个方面推出来的。规格表是阶跃的，不是连续的，M 到 L 之间没有任何中间态可买；升级流程又是"关机、卸盘、换机器、挂盘、跑脚本"这一套，意味着每一次跨档都要付出一次有感的停机与操作风险。两个因素叠在一起，结论就是：要么在小档位上安心待着，要么在有把握的时候一次跳到位，最不划算的就是卡在中间、每隔一段时间被迫跳一次。

支持"直接上 L"的第二个理由是内存的常驻属性。前面讲过，内存这条曲线是单调不降的台阶，买少了不会报错，只会让你的每一次查询都变慢一点、抖一点，而且是全天候的。这类"慢性损耗"最容易被低估——它不会触发告警，不会出现在故障单里，只是让开发者的体感从"秒开"变成"要等一下"，然后慢慢没人愿意用这个系统。反过来看，多买的内存闲置在那里，代价是确定的、可见的预算；少买的内存，代价是不确定的、隐性的效率损失。在一个依赖内部工具采纳率的场景里，我们倾向于把隐性代价看得更重一些，所以宁可在档位上偏保守（偏大）。

当然，这个立场有明确的适用边界，说清楚才算负责任的推荐。如果你的组织规模稳定、仓库数已经不再增长、且这台机器服务的只是某一个团队的局部检索需求，那么按"够用"选一档完全合理，省下来的预算花在更密的自动快照、更好的 SSD 介质、以及一次完整的恢复演练上，收益比堆内存实在得多。还有一种情况要单独拎出来：如果你对仓库数的统计口径都不确定（比如不确定是否要把历史归档库、fork 出来的库算进去），那先别急着定档，把数字统计清楚再来——在数字不确定的情况下，无论你选大选小，都是在赌。

一万网络在代码搜索场景的两个推荐项上怎么摆位

讲了这么多规格和规则，落到"这台机器去哪儿租"，我们只摆两个推荐项，其余的你自己判断。第一个推荐项是数据盘。代码搜索这种索引常驻、随机读密集的场景，磁盘是整个配置里最不该省的部分，而最容易出问题的恰恰是"第二块盘"这个要求——有不少租用方案默认只给一块大盘，系统和数据挤在一起，看起来容量够用，实际上既不满足单节点脚本部署"必须是与系统盘不同的另一块盘"的前提，也让后面"换机器不换数据盘"的升级流程无从执行。所以下单时请把"两块盘、数据盘独立、SSD 或同等性能、250GB 起"作为明确要求提出来，并且要求机房在交付时确认挂载点，不要等到跑脚本时才发现盘不对。

第二个推荐项是档位本身。我们的建议是照着官方规格表选，不要凭经验往小里砍，也不要被"人少"这个直觉带偏——前文第二个示例已经说明了，1,000 用户 + 80,000 仓库照样要按 L 档买。选档这件事上，一万网络能提供的价值更多是把机器的 vCPU、内存、磁盘形态按需配齐，并且在你需要从 M 跳到 L 的那一天，能快速给你一台同形态、可承接原数据盘的新机器，让官方那套升级流程真的跑得通。一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。

Sourcegraph 上线前的服务器验收清单

第一部分是档位与算力的验收。请拿出你的用户数与仓库数，分别对照官方上限各自落档，取大者得到最终档位，然后核对机器实际交付的 vCPU 与内存是否与该档位一致（XS 到 XL 依次为 8 vCPU / 32GB、16 vCPU / 64GB、32 vCPU / 128GB、48 vCPU / 192GB、96 vCPU / 384GB）。如果你用的是公有云，顺便核对机型是否落在官方建议的对应关系里：AWS 的 m6a.2xlarge 到 m6a.24xlarge、Azure 的 D8_v3 到 D64_v3、GCP 的 n2-standard-8 到 n2-standard-96。这一步建议留下书面记录，它是后续验收项的基准，也是半年后复盘"当时为什么这么选"的唯一依据。

第二部分是磁盘验收，这是最容易出错也最该较真的一环。逐条确认：根盘是否有至少 50GB 的空闲空间（注意是空闲而非总容量）；是否存在第二块独立的数据盘，容量是否不小于 250GB；这块数据盘是否确实与系统盘是不同的盘，而不是同一个盘上的另一个分区；两块盘背后的介质是否都是 SSD 或者同等性能的存储。然后在执行安装脚本之前，确认脚本将要格式化的设备名指向的是那块空的数据盘——脚本会格式化它，这一步搞错没有后悔药。如果采用 Kubernetes 部署，还要额外确认节点规格达到每节点 16 vCPU、60GiB 内存、启动盘 100GB（SSD 优先），并且在 Azure 上确认集群创建时就已经支持 CSI 存储驱动，因为这一项事后无法开启。

第三部分是网络与数据安全的验收。确认 443 端口能够出访到你的代码托管平台，并且遥测通路可用；确认 22 端口是否按你的克隆方式决定开放与否，若统一使用 HTTPS 克隆则不必开；确认实例位于 VPC 或者其他受限网络内，而不是直接暴露在公网入口上。若代码托管平台为私有化部署，需提前确认证书信任的处理方式已完成，以及代理环境下的出访可达性已在目标机器上实测通过。最后两项是备份与升级：数据盘的自动定时快照是否已配置且做过一次真实的恢复演练；官方那套"备份卷、关实例、卸数据盘、新机启动、挂回数据盘、跑安装脚本"的升级流程，是否在正式上线前完整走过一遍。这五项里任何一项没有打勾，都建议把上线日期往后推，别带着问号开服。

一万网络能给代码搜索这类索引常驻内存场景接什么：下单前要确认的清单

先说能接的部分。代码搜索对硬件的要求其实非常标准化：一台 CPU 与内存等比放大、磁盘必须是 SSD 的通用计算型机器，不需要 GPU、不需要特殊加速卡、不依赖特定的本地盘型号。这类需求对做 IDC 的团队来说是舒适区，按官方档位把 vCPU 与内存配齐，再配上独立的数据盘，机器本身没有难点。真正需要你在下单前确认清楚的，是下面这几条，建议直接抄进需求单里，避免交付后出现"机器到位了但装不了"的尴尬。

第一条，盘的数量与形态：明确要求两块盘，其中一块为系统盘，另一块为独立的数据盘，容量不小于 250GB，介质为 SSD 或同等性能存储，交付时需明确标识设备名，以便安装脚本格式化并挂载到 /mnt/data；根盘需保留至少 50GB 空闲空间。第二条，规格与升级路径：按官方档位确认 vCPU 与内存，并提前询问后续升档时能否提供同形态、可承接原数据盘的新机器，让"换机器不换数据盘"这套流程具备可执行性。第三条，快照能力：确认是否支持对数据盘做自动定时快照，快照保留策略能否自定义，以及从快照恢复一台可用实例的大致流程——具体节奏按你自己的变更频率和恢复目标来定，但能力本身必须先确认存在。

第四条，网络与环境：确认机器可以部署在受限网络内，443 出访策略可以按你的目标地址放行，22 端口按需要开放或关闭；若你的代码托管平台是私有化部署并需要经过代理出访，请提前说明，让网络侧一起参与方案确认。第五条，位置与访问方式：结合团队分布选择节点位置，如果你的同事分布在华南、华东、华北等不同区域，或者有中国香港及海外办公的同事要访问，节点位置和访问入口的安排要一起考虑，别等到上线后才发现一半人访问卡顿。以上几条确认完毕之后，剩下的就是按档位下单和按官方脚本部署了。一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。