几周前，我误操作导致自己的网站停服了大约三十分钟。
我当时正在为 GitHub 网络钩子搭建一个基于队列的流水线。这需要两个 Cloudflare Workers：一个用于捕获网络钩子并将事件放入队列，另一个用于从队列中取出事件并在后台执行耗时操作。GitHub 只给你十秒钟的响应时间，所以你必须快速响应，然后再执行实际的工作。
两个 Worker 意味着两次部署。我将它们链接成了一个命令。
Cloudflare 的构建系统打印了一条警告。它表示正在用绑定到构建项目的名称覆盖我配置中的 Worker 名称。这一行文字夹杂在大量正常的部署输出中间。随后，命令像成功执行时那样以退出码零结束。
这条警告的实际含义是，我的第二个 Worker（仅有 0.39 KiB 大小）刚刚被作为第一个 Worker 的新版本上传，并提升到了生产流量中。那个 Worker 只知道如何从队列中读取数据，完全不知道 HTTP 请求是什么。在我弄清楚发生了什么之前，对网站的每个请求都抛出了异常。
三十分钟的停机时间。总共大约花了两个小时，从错误的部署到重建一个不会再让我遭遇此类问题的设置。
一切看起来都没有问题。配置没问题。命令也没问题。输出的滚动信息看起来和我运行过的其他部署一模一样。那本可以救我一命的一行文字，其格式与周围的文字毫无二致。它没有阻止任何操作，因为它不是一个错误，而是一条信息。
风险一直存在，只是没有任何迹象表明它的存在，直到流量冲击了它。
在物理世界中，情况并非如此。
路过一个建筑工地时，你可以看到风险。四楼上身后没有任何防护的人；在人行道上空摆动负载的起重机；承受着看似超出其负荷能力的横梁。你不需要任何流程或会议就能注意到这些。风险就在你眼前。每个路过的人都会以某种方式评估它，而不仅仅是那些批准计划的人。
软件行业则完全没有这种直观性。没有什么可看的。在你的屏幕上，有风险的变更和安全的变更看起来一模一样。它们都只是文本。
因此，风险只停留在某人的脑海中。从未落在纸面上，也从未记录在任务工单中。
你知道那种感觉。有人在规划会议上描述一个任务工单时，你的直觉告诉你这件事会比听起来更糟糕。也许你会说出来。也许它会导致估算工作量增加一点。但它几乎永远不会作为一个关于工作的事实被记录在任何地方，供你日后查阅。
然而，这种不可见性带来的后果比在发布后隐藏风险更严重。它从根本上改变了你要构建的内容。
让一个团队面对真实的截止日期，看看会被砍掉什么。被砍掉的从来不是功能。功能是可见的东西，是演示中包含的内容。被砍掉的是针对罕见路径的测试、针对第三方调用超时的处理机制，以及关于当流量达到十倍时会发生什么的十分钟思考。这些工作就这样消失了，因为没有人看到它们未被执行。没有人会演示他们处理过的边缘情况。
而“我们将在下一个冲刺周期修复它”这句话，只能涵盖那些你能看到的遗漏。那些危险的遗漏看起来符合质量标准，顺利通过。它们以绿色状态发布。然后，它们会在几周或几个月后，按照自己的时间表作为事故浮现出来。
这意味着，你偷工减料的地方与其引发的事故几乎永远不会出现在同一个冲刺周期中。从内部来看，它们像是两个无关的事件。
那么你究竟该怎么做呢？
使其可见化。这就是全部的工作。
不是引入新的流程或委员会。只是将其从你的脑海中移出，落实到工作本身，在单个变更的层面上
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
