用数字来做上云的决定

如果只把云计算当作概念学习，做决策时就无法使用。本实验将决策所需信息量化为数字。

cp -r /opt/lab/cloudbasics/* .
python3 latency.py 11000 --real 180
python3 tco.py --self 400 --managed 900 --hours 20 --rate 60

距离和费率均为近似值。重要的是数量级——1ms 与 100ms 并不是同一类数字。

无法用钱缩短的东西

计算首尔↔弗吉尼亚（约 11,000km）的最低往返时间，记录到 01-physics.txt。实际测量值约为 180ms——同时记录差值。

python3 latency.py 11000 --real 180

光在真空中的速度为 300,000km/s，但在光纤中约为 200,000km/s（折射率 1.5）。

110ms 是物理极限。升级实例或投入更多资金都无法缩短。这是云中唯一“买不到的东西”，因此必须通过架构解决。

那么 Region 应放在哪里

将用户主要位于韩国的服务应选择哪个 Region 写入 02-region.md，并用数字说明依据。

使用第 1 步的数字。首尔 Region 到用户需要多少 ms，弗吉尼亚需要多少 ms？

还要考虑会发生多少次往返。一个页面调用 API 5 次，就有 5 次往返。110ms × 5 = 550ms，而且这段时间什么也没做。

为什么要划分 AZ

比较 AZ 间延迟与 Region 间延迟的数量级，写入 03-az.md，并说明为什么要跨 AZ 部署。

AZ 是同一城市圈内的不同建筑——距离几十 km，往返约为 1ms。Region 之间则为几十到几百 ms。

**同样的代价可以买到不同的东西。**跨 AZ 后，即使一栋建筑故障也能存活，延迟几乎不增加；跨 Region 后，即使整个城市故障也能存活，但延迟会增加百倍。

谁负责保护什么

为 incidents.txt 中的 10 个事故分别填写 cloud 或 me。格式为 번호|사고|답。

一个判断标准——我能配置的内容就是我的责任。

Bucket 公开设置、IAM 密钥管理、OS 更新都由我完成。Hypervisor 补丁与物理访问控制无法由我操作，因此属于服务商责任。

两个易混淆点：AZ 断电是服务商责任，但只部署在该 AZ 是我的责任。托管 DB 的小版本补丁由服务商完成。

托管服务真的更贵吗

把人工时间计入，比较自行运维与托管服务的月度成本，并记录到 05-tco.txt。

python3 tco.py --self 400 --managed 900 --hours 20 --rate 60

只看基础设施费用时，托管服务似乎贵了一倍多。计入 20 小时人工后，托管服务每月便宜 700$。

**人工时间不会出现在账本上，因此总被当作 0。**而且这些时间通常发生在夜间和事故发生时。

寻找盈亏平衡点

计算自行运维要在每月少于多少小时时才更便宜，并在 06-breakeven.md 中判断这是否现实。

tco.py 会给出盈亏平衡点。上述条件下为 8.3 小时。

每月 8 小时——包括检查备份、打补丁、监控、容量检查以及一次故障响应。现实吗？

而且，投入这些时间的人也会无法完成其他工作（机会成本），这同样不会出现在账本中。

云并非答案的场景

找出至少两种云服务更昂贵或不合适的情况，写入 07-notcloud.md，并说明各自原因。

可考虑：负载稳定、可预测且会使用 3 年以上的大规模计算；需要大量导出数据的工作负载（egress 费用）；数据驻留法规；特殊硬件。

重点不是“云更便宜”，而是“云更灵活”。如果不需要灵活性，就没有理由支付这笔费用。

总结

在 08-notes.md 中至少写三行：无法用钱买到的东西、共同责任的判断标准、查看托管成本时容易遗漏的内容。

正文中必须包含 지연、설정、사람。