钱买不到的只有一样：延迟
一句话总结
在云环境中，**唯一无法用钱购买的是延迟。**其他一切都可以买到，因此也都可以通过计算作出决定。
为什么必须用数字决定
云架构决策常常演变成偏好之争。“是不是首尔区域更好”“托管服务太贵”“先迁到云上再说”——因为没有依据，声音最大的一方会获胜；半年后，却没有人能解释当初为什么这样决定。
但下面四项决策都有可以计算的依据。
| 决策 | 根据什么决定 |
|---|---|
| 区域应该放在哪里 | 距离造成的物理极限 |
| 是否跨 AZ 部署 | 付出 1ms 换取什么 |
| 是否使用托管服务 | 计入人员时间后的比较 |
| 哪些部分由自己保护 | 自己是否可以配置 |
把数字写下来，就能进行验证或反驳，讨论也会从此向前推进。下面逐一计算这四项。
无法超越光速
从首尔到弗吉尼亚约 11,000km。光在光纤中的速度约为 200,000km/s（真空光速的 2/3，这是折射率 1.5 导致的）。
편도 55ms · 왕복 110ms
**这是物理极限。**扩大实例、增加预算、铺设专线都无法消除它。实际路径并非直线，还会经过多台设备，因此延迟通常约为 180ms。
它的重要性在于：**一个页面调用 API 5 次，就需要 5 次往返。**110ms × 5 = 550ms，而这段时间里系统什么也没有做。
因此，区域选择不是偏好，而是一道计算题。减少往返次数的设计（批量请求、缓存、边缘节点），通常比扩大实例有效得多。
AZ 用相近的成本购买不同能力
| 距离 | 往返延迟 | 能承受什么故障 | |
|---|---|---|---|
| 同一 AZ | 同一建筑 | < 0.5ms | 单台服务器故障 |
| AZ 之间 | 同一城市圈 | 约 1ms | 建筑、电力、冷却故障 |
| 区域之间 | 跨大陆 | 数十至数百 ms | 城市级灾难 |
**跨 AZ 部署几乎可以免费获得抵御整栋建筑故障的能力。**代价只是增加约 1ms 延迟。因此，几乎总应采用跨 AZ 部署，而跨区域部署只在确有需要时采用。
共同责任——不了解边界，双方都不会保护
判断标准只有一个。
凡是我能够配置的，就是我的责任。
| 我的责任 | 云服务商的责任 |
|---|---|
| 存储桶公开设置 | 虚拟机监控器补丁 |
| IAM 密钥管理 | 物理访问控制 |
| 操作系统安全更新 | 电力与冷却 |
| 应用程序漏洞 | 托管数据库的小版本补丁 |
| 备份配置 | 硬件更换 |
有一个位置容易混淆：AZ 断电导致实例停止是云服务商的责任，但只部署在这个 AZ 是我们的责任。服务商从一开始就说明 AZ 可能故障，并建议使用多个 AZ。
事故几乎总发生在双方都认为不属于自己职责的位置。
为什么托管服务看起来更贵
因为人们只比较基础设施费用。
직접 운영 인프라 400$ + 사람 20시간 × 60$ = 1,600$
관리형 900$
不计人员时间时，托管服务看起来贵了一倍；计入后反而便宜 700$。
人员时间不会直接出现在账单上。员工已经领取月薪，因此这段时间看起来像是“免费”的。但这些时间往往发生在夜间和事故发生时，而且相关人员无法同时处理其他工作。
盈亏平衡点可以这样计算。
(900 - 400) / 60 = 8.3시간
每月投入少于 8 小时时，自行运维更便宜。但备份检查、补丁、监控、容量检查，再加上一次故障响应，真的能在 8 小时内完成吗？通常不能。
云不是答案的场景
正确的说法不是“云更便宜”，而是**“云更灵活”。**如果不需要灵活性，就没有理由为它付费。
- 负载稳定、计划使用 3 年以上的大规模计算——自动扩缩容没有用武之地
- 需要大量向外传输数据的工作负载——出口流量费用会占据主导
- 数据驻留法规——没有合适区域时就无法使用
- 特殊硬件——云上不提供时就无法使用
反过来，如果负载波动很大、尚不清楚最终需要多少资源，或者必须快速启动，云几乎总是更好的选择。此时购买的不是计算资源，而是推迟作出选择的权利。
生产现场中的表现
- 因为总部位于美国，就把区域设置在弗吉尼亚，导致韩国用户的页面加载时间增加近 1 秒——一个页面调用了五次 API。
- 只部署在单个 AZ，发生 AZ 故障后复盘以归咎服务商结束；下个季度相同事故再次发生。
- 认为托管服务太贵而选择自行运维，此后每月却要投入二十小时处理补丁、备份检查和夜间故障。这些时间没有出现在任何账目中。
- 把存储桶公开配置导致的泄露报告为服务商安全事故，事后才确认配置主体其实是我们自己。