Site Unreliability Engineering

在前几天，Social Layer 使用的邮件发送服务 resend.com 出现了服务故障，长达十几个小时里系统无法发送邮件，影响使用邮箱登录的用户。因为目前没有设置错误收集和报警系统，我一直没发现，后面才在 Twitter 的讨论看到 resend 的故障，很多开发者表示失望和批评。

服务的故障无处不在，硬件老化、磁盘空间用满、网络中断、底层服务故障、软件升级出错、账单付费失败、域名过期，这些事情在我的职业生涯一直发生，也在世界各个地方不断重演。运行中的软件服务就是一个生命体，持续遭受各种冲击和发生故障，为了稳定的运行，需要各种照料和维护。我们多么希望这些服务像时间晶体一样永无止境地运行，有少数的程序可以在某处无声地运行很久，直到某天出错或发生不得已的变更，才会惊觉它们的存在，但这并不常见。

Google 以管理大量服务器闻名，他们专门有一种角色叫做 Site Reliability Engineer (SRE)，负责开发内部工具和服务，维护大规模集群系统的稳定运行。而我们没有，相反我的角色像是一个 Site Unreliability Engineer，因为我总是探索系统架构的演进，不断引入变更，使用更新和更好的服务，重构代码库，也经常迁移数据和物理节点。在系统程序和状态不断更新变革的过程中，总是伴随着不稳定和意外风险，但这是系统进化的一部分，也是我的探索里程的一部分。

软件服务的运行需要照料这一事实，无可避免，也并不减损它的价值，恰恰是它有生命的一部分。一个工作中的软件总是在某个时段某地地方存在着，依赖着物理世界的资源。系统会发生扰动，而我们每次都能发现它的短板并加以修补，系统就会更加健壮可靠，让下一次发生问题的机会指数地减少，我们因而也对系统了解得更多。这是一个有生命的存在必要的辛劳。

Get prepared for uncertainty.