日志
工程日记。事件会有带真实时间戳的事后分析，硬件决策会列出依据的数据，政策变更会说明理由——即使这些理由让我们看起来反应迟缓。这里的每一篇都不是市场部门写的，这一点读一段就能看出来。
这里会收录什么
我们本来就在写这些笔记。总得有人向下一任工程师解释为什么镜像的两半来自不同的配送箱，而一旦写下来，就没有理由把它藏在登录墙后面。
五类内容。伪装成见解的产品公告不在此列。
这里不会出现教程。指南请参阅[指南部分](/guides)，参考资料请参阅[知识库](/docs)。把三者混在一起，会变成无法搜索的博客。当前车队状态请见[状态页面](/status)，该页面会自动更新，无需任何人撰写文稿。
事件
出了问题且客户注意到。十个工作日内发布，时间戳使用 UTC，第一段就写明原因。如果是我们的责任，会首先说明。
硬件
我们买了什么，测了什么，拒绝了什么。代际迁移、硬盘家族，以及偶尔刻意落后一代的配置，因为新部件对工作负载没有帮助。
网络
传输、对等互联、过滤、寻址。这里也会公布其他主机商含糊其辞的数据，首先是“无限流量”的含义，免得有人发邮件问你。
平台
控制面板、配置队列、API、新站点。容量说明也在这里，包括那些不太体面的内容，解释为什么某个城市是限量供应而不是扩建。
Policy
关于我们销售什么、保留什么、拒绝做什么的变更。删除廉价套餐至今仍是本站阅读量最高的文章，即便已发布五年。
事件如何写成文档
文体风格不是审美选择。它防止我们悄悄把糟糕的一周改写成更好看的故事，因为本来应该删除的部分会因缺席而显得显眼。
同样的五个标题，同样的顺序，每次都一样。
- 01
摘要
发生了什么，持续多久，影响了谁，用不到60个字说明。只读这一节，你也能知道是否涉及自己。
- 02
时间线
从首个症状到完全恢复的 UTC 时间戳，包括花在错误方向上的几分钟。这几分钟通常是文档中最有趣的部分。
- 03
根本原因
机制，而不是类别。人为错误不是根本原因。2023年写的一条分类规则允许架构变更跳过了 canary 阶段——这才是根本原因，而且它有责任人。
- 04
我们改变了什么
具体、注明日期、可核查。每一项都是客户可以在电话中要求我们演示的，而且确实有人这样做过两次。
- 05
我们没有改变什么及其原因
大多数公司会省略的章节。有时显而易见的修复所牺牲的隐私比你失去的还多，我们宁愿公开讨论，也不愿悄悄解决。
“现在是凌晨三点，你们的状态页面说站点正常。但站点并不正常。”
事后分析甚至在没人问起、甚至受影响的客户从未注意到时也会发布。其中两篇描述了我们支付的、SLA并未要求我们支付的积分，这种事你只会写一次。
阅读档案
16篇文章，六年半，一个明显的空白。
空白从2019年底延续到2020年10月。我们在上架设备，而不是写作，最终促成文章的是让阿姆斯特丹断网11分钟的攻击。这是这一行常见的模式：文档习惯始于某次代价高昂的错误发生的那天。
旧文章从不就地编辑。如果某个说法后来被证明有误，更正会以自己的日期附在原文下面，原句保持原样。一篇随时间悄悄自我完善的文章，对读者一文不值。
| 时期 | 我们当时在做什么 | 写下了什么 |
|---|---|---|
| 2019 – 2020 | 八周内点亮四个站点，随后在疫情肆虐的一年里再增六个 | 两篇文章。一篇创始说明和一篇道歉。 |
| 2021 – 2022 | 廉价档位被删除，IPv6默认开启，订购Zen 4，雷克雅未克开业 | 四篇文章，包括我们被引用最多的一篇。 |
| 2023 – 2024 | 金丝雀、GPU、Zen 5，以及一批同时故障的硬盘 | 五篇文章，其中一篇道歉附带退款。 |
| 2025 – 2026 | 供应流程重写，苏黎世限流，API开放，约翰内斯堡上架 | 五篇文章加上一篇事后分析。 |
平台
05网络
03事件
03硬件
03关于期刊本身的问题
本页底部有一个Atom订阅源，没有追踪像素，也没有配套的邮件列表。如果你想要通讯，你得去别处想要。
不接受。这里的每篇都出自能被呼叫的人之手，这正是它存在的全部意义。
因为删除它们是不诚实的。更正会以日期标注附在原文下方，让你既看到我们当时的想法，也看到我们何时不再那么想。
可以，包括那些让我们难堪的部分，尤其是那些。注明出处和链接即可；无需许可，也不会比这句话更正式地授予许可。
如果影响的不止一个客户，那它已经到了这里，或者正在起草中。单实例故障在工单里答复，因为一篇关于一块硬盘死掉的事后分析对谁都没用。