在过去的五年里，在这里购买服务器从结算 webhook 到凭证出现在您的收件箱中，中位数时间为三分二十秒。没有人抱怨过。它比大多数行业都快，而且比任何需要人工审批的流程都要快得多。
这也是四个本不应该是串行的串行步骤，一旦你注意到这一点，你就无法停止注意它。重写版本在三月上线，现在中位数是四十七秒，第95百分位数略低于四分钟。
旧流程的工作方式
| 步骤 | 中位数 | 具体操作 |
|---|---|---|
| 镜像复制 | 84 秒 | 从每站点存储将磁盘镜像拉取到目标节点 |
| 卷创建 | 31 秒 | 分配并格式化 NVMe 卷 |
| 地址分配 | 46 秒 | 锁定站点地址池，选择 IPv4，写入反向 DNS |
| 首次启动和 cloud-init | 39 秒 | 生成密钥，扩展文件系统，发送邮件 |
四个步骤，一个全局工作池，以及一个地址池锁，同一站点的每个订单都必须排队等待。在一个安静的星期二，一切正常。但在促销期间，或者在一个大客户脚本化创建四十个实例后的一小时内，中位数翻倍，尾部延迟超过十二分钟。
我们做了什么改变
镜像预先播种，而不是复制。 每个节点都持有目录中每个镜像的薄克隆基础，每晚刷新。创建卷现在是对本地 Gen4 NVMe 镜像的写时复制克隆，而不是网络拉取。这一步从八十四秒减少到不到两秒。
地址预先保留。 每个站点保持一个预分配的地址暖池，反向 DNS 已写入，大小约为该站点六小时的需求。分配现在是从预建池中弹出，而不是锁定、扫描和 DNS 写入。四十六秒变成了大约四百毫秒。
队列按站点隔离。 法兰克福的拥堵不再减慢圣保罗的创建速度，这听起来很明显，但原始设计并非如此，因为原始设计只有四个站点和一个工程师。
工作进程是幂等且可恢复的。 每个步骤都有键控，因此工作进程中途死亡会留下可恢复的任务，而不是半构建的实例和支持工单。失败创建需要人工干预的比例从大约四百分之一下降到九千分之一。
结果
| 指标 | 之前 | 之后 |
|---|---|---|
| 中位数 | 3 分 20 秒 | 47 秒 |
| 第95百分位 | 12 分 10 秒 | 3 分 56 秒 |
| 第99百分位 | 41 分 | 8 分 20 秒 |
| 需要人工的失败创建 | 1/400 | 1/9,000 |
| 中位数移动前的每站点并发 | 6 | 90 |
过程中出了什么问题
在三月份，有十一个小时，四个站点的薄克隆基础夜间刷新静默失败，预播种的 Debian 镜像提供了晚了九天的点发布。大约有九十个实例是基于它构建的。它们都没有任何有趣的问题，因为过期的点发布只需一次软件包更新就能变成最新的，但购买服务器的人不应该需要检查。
我们按请求重建了受影响的实例，无论他们是否要求，都向所有九十位客户发送了邮件，并增加了一项检查，在任何节点允许服务创建之前，将基础镜像哈希与目录进行比较。夜间任务的静默失败是最无聊的可能原因，但正因为无聊，才值得写下来。
仍然缓慢的部分
- 自定义 ISO 安装。 仍然是手动的，仍然需要数十分钟，通常在一小时内完成。瓶颈是人工确认镜像是否如其上传者所述。
- Windows。 许可证激活增加两到三分钟，且不受我们控制。
- 裸金属。 同日交付而非同分钟。物理机器有物理重建，我们宁愿诚实地报价，也不愿开启一个我们无法超越的时钟。
- IPv6 /48 委派。 在三个站点手动操作，那里的网络配置较旧。正在缓慢修复中。
为什么我们止步于此
我们通过保持实例预启动并在付款时直接交给您，可以将中位数提高到约二十秒。这意味着持有空闲容量，意味着为无人使用的核心付费，这意味着向每个人多收一点费，以便新订单能感觉快十一秒。
四十七秒已足够短，现在的约束是确认您的付款的链条，而不是我们做的任何事情。优化到客户不再注意的程度是爱好，而不是工程。