团队的基础设施“文档”是张谷歌表格。谁都能编辑，但没人总会去更新。
每新增一台云主机，就得走完一样的五步：登录后台、选镜像和规格、配防火墙规则、设 DNS、更新表格。不出错的话，半小时搞定。没有谁操作过的记录，没有审批环节，也没法追溯是哪次改动、哪个人弄出了一台配错的主机。
明显的解法是写脚本。可一个挂在定时任务里、谁也看不见的脚本，不过是让未被记录的变更来得更快些罢了——你依然不知道什么跑过、何时跑的、为什么坏了。
我真正需要的是审计日志、审批和通知，而且不用为了凑齐这三样去拼接三个毫无关联的工具。
这就是 SuperPlane 给我的东西。
谁改了什么，为什么没法查
每次要拉起一台新主机，流程都一个样：登进 DigitalOcean，选镜像、规格、地域，手动配置防火墙规则，再手动建 DNS 记录，最后把所有内容填进表格里——同时默默祈祷没落下什么。
没有审计追溯，没有审批。谁在什么时间做了改动，完全看不见。
一旦有问题，追查无从下手。如果团队成员未经审批就起了资源，根本不会有任何记录留下。这不只是效率问题，更是风险。那张表格正在变成最关键的基础设施组件，而它只不过是一张任何人都可以随意修改的谷歌表格。
抓狂之后，我搭了一套自动流
我决定用 SuperPlane 搭一条简单的工作流。一开始先创建一个所有者账号，然后把我的 DigitalOcean 工作空间连上去。初始设置页面很直接：建账号、配好工作空间，没有什么复杂选项。
接着我利用内置应用目录创建了一个新应用。SuperPlane 提供了常见流程的起步模板，其中就包含一项预置的“预览环境（GitHub + DigitalOcean）”集成。新建应用界面里有两个与我直接相关的选项：一个是 GitHub 加 DigitalOcean 的预览环境，一个是 GitHub 加 AWS。我走了 DigitalOcean 那条路。
四步让主机自动就绪
我搭建的流程一共四步。
第一步，触发器。当需要新启动一台主机时自动激活。它监听云主机事件，让整条自动化从请求产生的一刻就自行开跑——不用任何人手动去点“开始”。
第二步，创建主机。按照预设规格自动拉起主机：指定镜像、尺寸和地域。团队里再没人需要记住正确的配置组合。
第三步，配置 DNS。主机就绪后立刻自动创建 DNS 记录。这一步以前最容易忘记，而现在再也不会被漏掉。
第四步，通知。一切完成后，向 Slack 发出一条消息。全组都知道环境已经可用了，不用任何人再去反复刷新状态页面。
当一名团队成员申请新环境时，流程自动触发。主机被创建出来，DNS 自己配置好，所有人都收到通知。没有手动步骤，没有迟延，也不会再有人在半夜十一点在 Slack 里问：“谁设的 DNS？设了没？”
不靠三件套拼装，一口吃掉审计和审批
过去我知道，要把审计、审批和通知一起做起来，要么把 CI 里的一个单独仓库里的脚本不断改出新的功能，要么就得把几样 SaaS 服务粘在一起。无论哪种做法，都会多出新的维护面。
SuperPlane 把这三件事嵌在同一条流里。触发动作本身就是一次记录，创建主机的步骤带有明确的操作者身份，Slack 通知被送到频道里，相当于一次轻量的广播审批。事情做完后，谁起先发起的请求、哪个时间、选了怎样的配置，全都在一条流里可查。不是事后猜测，是直接翻记录。
这比“先让脚本跑再补文档”的循环要干净太多。文档不是补的，而是流在执行过程中自然生成的副产品。
困惑之后的发现
这件事的起点其实是一股沮丧：为什么我们已经有了那么多自动化工具，一旦从 CI 流水线跨到云资源的生命周期管理，还是得退回手工操作和口头沟通？CD 管道可以自动部署应用，可承载应用的那台主机，却要手动去控制台点来点去。
SuperPlane 给我的答案是，它不是要做一个更复杂的自动化引擎，而是把审批、可见性和通知这些控制面的事情，做进同一条简单的声明式工作流里。不需要拼接 API，也不需要自己去维护一堆 webhook 和秘钥。我所做的只是描述我想要什么状态，它负责把过程变成可追溯的步骤，然后通知到该知道的人。
这种感觉不像是在写脚本，更像是在说清楚意图，然后等着系统去落实。
热门跟贴