2024 年 2 月 7 日，大年二十八，早间 10 时许，温煦的阳光挥洒在广袤的苏北平原之上，家家户户烟囱中冒出的烟火气添得年味越发浓烈……就是这样一个闲适祥和的上午，一封似是平常的电子邮件被送入了在下的收件箱，起初，它并没有引起干坐着刷手机的在下的过多注意：邮件的标题只是简单地标着「Your Supabase Instance」字样，并无更多的说明，一眼看上去像是 Supabase 用来推广他们新 features 的广告邮件。不过当在下打开邮件粗粗一看，发现似乎并非如此，再认真看时，方才意识到出现了严重的问题：Supabase 在邮件中提示道，在下用于储存 umami 站点统计信息的数据库，已经有 7 天时间处于非活跃状态，出于对节省资源的考虑，他们将会在几日内暂停这个数据库的运作。
在下先是感到困惑：作为 umami 统计数据的数据库，怎会有整整七天时间都没有活动过呢，虽说敝站的统计数据一直不温不火，但每天的访问人数，怎么说也能有个三四十人，即便 Supabase 对于非活跃的定义再离谱，也不可能无视掉这样一批数据的传入才对。然而，当在下登上 Supabase 一看，迎接在下的，却是平静得翻不起一点波澜的使用量统计数据，空白的折线图犹如心电监护仪，清楚明了地宣告了数据库在这七天的死亡；随后，部署在 Vercel 的 umami 前端为其连接的数据库正式开具了死亡证明。事已至此，可以确定这无疑是一件小型运维事故，只不过糊里糊涂的在下在其发生的第七天方才得知。
在下随即开始排查事故原因，看起来，umami 的前端由于某种原因，在这七天的时间内一直无法连接到 Supabase 的数据库，那这究竟是怎么一绘事呢？经过在下的一番回想，死去的记忆开始渐渐复活，随之开始猛烈地攻击在下：早在几个月前，在下就接收到了 Supabase 发来的邮件提醒，内容大致是由于 AWS 将开始对 IPv4 地址收费，因此他们也将不再提供免费的 IPv4 连接，为了应对这一改变，Supabase 敦促用户更改一下数据库的连接 URL，从直接连接切换到 Supavisor 代理连接，就可以解决 IPv4 网络的连接问题。而在下第一次收到这封提醒邮件时，没有细看，竟把大致内容理解成了：不用做特别的操作，Supabase 会自行改变连接模式解决这一问题，遂放心地删了邮件睡觉去了，从此埋下祸根。之后，Supabase 更是三番五次发邮件来把这件事说了又说，无一例外地被在下塞进了垃圾箱，最后一次提醒是大概在 1 月 19 日，Supabase 建议用户切换到 Supavisor 代理的 DDL 7 天前，躺在巴松措景区民宿床上的在下再次将这一提醒删除，以不作为的姿态亲手造就了事故的发生。
到了 2 月 1 日这天，Supabase 正式将在下的数据库域名解析到了 IPv6 地址，而搞笑的是，由于 Vercel 时至 4202 年，仍然未能支持 IPv6，就导致了部署在此的 umami 前端与数据库的连接中断。更加搞笑的是，在下在此之后竟然对 umami 挂掉浑然不知，直到 7 天后接到 Supabase 的邮件提醒才意识到出了事。
搞笑的事情到这还没完，察觉事故之后在下一心想要赶紧恢复服务，根本没有好好地去看 Supabase 关于弃用 IPv4 的公告，由于之前对于 IPv6 迁移政策的理解错误，一度让在下认为不支持 IPv6 的 Vercel 已经不再适合作为 umami 的前端了，转而去寻找起新的 PaaS 部署平台。此刻正处在苏北过年的在下，电脑未在身边，只能拿手机操作，相当痛苦，七弄八弄，搞得一地鸡毛：先是，打算把前端部署到 fly.io 上，又发现 umami 的 docker 是默认集成 postgres 的，要改远程连接非常麻烦，不知道又要踩多少坑，遂放弃；又尝试了 Netlify，结果不小心挂着代理注册触发了风控，要求传证件，传了证件又显示认证不通过，要用邮件和客服扯皮，又再次放弃；后来又看到 Vercel 能直接用 Integration 和 Supabase 连起来，结果试了以后也不得行……
汗流浃背的在下此时回看 Supabase 的迁移公告才发现，只需要简单地改一下新的数据库连接 URL，就可以解决这个问题，再 Vercel 这也就是改一下 Environment Variables 的事，不出几分钟就能搞定，惹得得知真相的在下当场吐血三升，倒地不起……回归正题，改完环境变量，umami 终于恢复了正常，这场事故也总算谢天谢地得到了解决。顺带着，此处也出现了最后一处笑点：为什么此前用 Vercel 提供的 Integration 直接连接 Supabase 却失败呢？原来是 Intergration 默认填写的 Environment Variables 的 name 为 POSTGRES_URL ，而 umami 的要求却为 DATABASE_URL 。然而此时被自己整得乌烟瘴气、萎靡不振的在下根本无力吐槽这个问题，在这个西风斜阳、暮色苍茫的大年二十八傍晚，一切的折腾终将落幕。
此次事故，因在下的愚蠢，使得其未能被提前预防、及时察觉、高效解决，导致敝站痛失从 2 月 1 日 9 时到 2 月 7 日 15 时，共计 6 天 6 小时的站点统计数据，不慎成就敝站运维事故「零」的突破，实属敝站历史耻辱柱之一甲，遂决定加以述之，立此为后日之鉴。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。