重写配置队列

五年来，在这里购买一台服务器的中位时间从结算 webhook 到收件箱中的凭据为三分二十秒。没有人抱怨。这比大多数行业都要快，也远比任何需要人工批准的方式要快。

这也是四个串行步骤，它们本不应该是串行的，一旦你注意到这一点，就无法忽视。重写于三月上线，现在中位数为四十七秒，九十五分位数略低于四分钟。

旧系统做了什么

四个步骤，一个全局工作池，以及一个地址池锁，同一站点内每个订单都必须排队等待。在安静的周二没有问题。在促销活动期间，或者在大客户脚本化创建四十台实例后的一小时内，中位数翻倍，尾部超过十二分钟。

我们改变了什么

镜像预置，而非复制。 每个节点都持有目录中每个镜像的薄克隆基础，每晚刷新。现在创建卷是对本地 Gen4 NVMe 镜像的写时复制克隆，而不是网络拉取。这一步骤从八十四秒减少到不到两秒。

地址预先保留。 每个站点保留一个预分配地址的热池，反向 DNS 已写好，大小约为该站点六小时的流量需求。现在分配是从预先构建的池中弹出，而不是锁定、扫描和 DNS 写入。四十六秒变为约四百毫秒。

队列按站点隔离。 法兰克福的繁忙不再减慢圣保罗的创建速度，这听起来显而易见，但并非原始设计，因为原始设计只有四个站点和一名工程师。

工作进程幂等且可恢复。 每一步都有键控，因此工作进程中途死亡会留下可恢复的作业，而不是半构建的实例和支持工单。创建失败需要人工干预的比率从约四百分之一降至九千分之一。

结果

过程中出现的问题

三月，有十一个小时，四个站点的薄克隆基础夜间刷新悄然失败，预置的 Debian 镜像提供了陈旧九天的点版本。约九十台实例从中构建。没有一个以任何有趣的方式损坏，因为陈旧的点版本只是一个软件包更新即可到达当前版本，但购买服务器的用户不应需要检查。

我们根据请求重建了受影响的实例，无论是否请求都给全部九十封邮件通知，并添加了一项检查，在任何节点允许提供创建之前，将基础镜像哈希与目录进行比较。夜间作业中的静默失败是最无聊的可能原因，正因为无聊才值得写下来。

仍然慢的部分

• 自定义 ISO 安装。 仍然手动，仍然需要几十分钟，通常在一小时内完成。瓶颈是人工确认镜像是否完成上传者所声称的功能。
• Windows。 许可证激活增加两到三分钟，且不在我们控制范围内。
• 裸金属。 当天而不是即时。物理机器有物理重建，我们宁可坦诚报价，也不愿启动一个无法胜出的时钟。
• IPv6 /48 委派。 在三个站点手动进行，那里网络配置较旧。正在修复中，但进展缓慢。

为什么我们停在这里

我们可以通过保持实例预启动并在支付后将其中一个交给您，将中位数降到约二十秒。这意味着持有空闲容量，意味着为无人使用的核心付费，意味着向每个人多收一点费，以便新订单感到快十一秒。

四十七秒已经足够短，现在的瓶颈是链确认您的付款，而不是我们做的任何事。优化到客户注意不到的点之后是爱好，而不是工程。