基础设施即工作流：超越静态 Terraform

SchemaBridge Team · 2026-01-18 · IaC, DevOps, Cloud Automation

管理第二天（Day 2）的云运维。将基础设施视为有状态的长时间运行业务流程。

“基础设施即代码”的局限：第一天 vs. 第二天

我们热爱 Terraform（IaC）。它解决了“第一天”配置的问题。你描述期望的状态（10 台 EC2 实例、1 个 RDS、1 个 VPC），运行 terraform apply，云提供商就会把它变为现实。这对静态资源来说堪称完美。它是声明式的、幂等的、可版本控制的。它是现代 DevOps 的基石。

但云运维的现实是，复杂性存在于第二天。第一天是婚礼；第二天才是婚姻生活。第二天关乎的是流程，而不仅仅是资源。它关乎系统随时间推移不断变化的、鲜活的生命周期。

以一次关键的数据库升级的生命周期为例。这不是一个静态事件；这是一个工作流：

1. 准备：为安全起见，将主数据库快照到 S3。

2. 等待：你必须等待快照完成。对于一个多 TB 级的大型数据库，这可能需要 30 到 45 分钟。

3. 配置：使用新的引擎版本，从快照创建一个新的数据库实例。

4. 等待：等待新实例变为“可用”且“健康”状态。

5. 迁移：连接到新实例并运行一个模式迁移脚本（Flyway 或 Liquibase）。这可能需要 1 个小时。

6. 验证：对新数据库运行一组冒烟测试以确保数据完整性。

7. 切换：如果成功，更新 DNS CNAME 使其指向新数据库。

8. 回滚：如果任何一步失败，你必须还原 DNS 并销毁损坏的实例。

Terraform 无法表达这一切。它是声明式的，而非命令式的。它不知道如何“等待 30 分钟”或“运行一个 SQL 脚本并检查退出码”。为了处理这个问题，团队通常会将 Terraform 包裹在 Jenkins 流水线、CircleCI 任务或 Python 脚本中。我们又回到了“胶水代码危机”（第一部分），只不过这次针对的是基础设施。这些脚本很脆弱、无状态，而且一旦在一次长达 4 小时的操作中途失败，就几乎无法调试。

将运维操作视为持久化工作流

在 SchemaBridge，我们认为基础设施运维操作本质上就是业务工作流。它们与支付处理流程具有相同的需求：可靠性、可审计性、状态管理和错误恢复能力。

通过将你的第二天运维操作迁移到 SchemaBridge，你将获得一个用于管理云的持久化编排器：

“控制平面”模式：与 AWS、K8s 和 Terraform 集成

SchemaBridge 并不是要取代 Terraform；它是在编排 Terraform。我们使用控制平面模式来统一静态与动态两个世界。

1. 触发：开发者提交代码，或从内部开发者门户（Backstage）手动触发一个“配置开发环境”工作流。

2. 配置：SchemaBridge 调用 Terraform Cloud API（或在安全的工作节点中运行 terraform apply）来创建物理资源。

3. 等待：工作流会轮询 Terraform API，直到该次运行安全地被“应用”。它会处理云的异步特性。

4. 配置后处理（“逻辑层”）：一旦基础设施就绪，SchemaBridge 就会连接到新的 Kubernetes 集群，运行数据库迁移，填充测试数据，并运行验收测试。

这种模式让你可以继续用 HCL（HashiCorp 配置语言）定义资源，同时用可视化图表来定义运维逻辑。

临时环境：开发者效率的圣杯

每个现代工程团队都渴望拥有临时环境——为每个 Pull Request（PR）提供一份完整的生产环境副本。这实现了真正的隔离，能在代码合并到主干之前就发现漏洞。

传统方法之所以失败，是因为它们难以清理。你为 PR-123 启动了资源，但开发者忘记关闭 PR，或者清理脚本失败了。你的云账单会因为“僵尸 RDS 实例”和“孤立的负载均衡器”而暴涨。

使用 SchemaBridge，一个环境就是具有明确定义生命周期的工作流。

1. 启动：启动资源（RDS、Redis、ECS 服务）。

2. 等待：工作流进入等待状态。它等待 PR 被合并，或等待预定义的 TTL（例如 24 小时）到期。

3. 清理：当信号到达或计时器到期时，工作流会自动唤醒并运行 terraform destroy。

因为清理逻辑与创建逻辑是同一个持久化工作流实例的一部分，所以它不可能被遗忘。即使整个 SchemaBridge 集群重启，它也会记得需要在下午 5 点销毁 PR-123 的环境。这就是“云端的垃圾回收”。

案例研究：高频交易的零接触蓝绿部署

我们曾与一家高频交易公司合作，他们需要在不产生哪怕一微秒停机时间的情况下更新其核心撮合引擎。

挑战

标准的 Kubernetes 滚动更新还不够安全，因为他们需要在切换流量之前，先针对实时数据验证新版本的财务准确性长达 10 分钟。他们需要一种复杂的“影子模式”部署。

SchemaBridge 解决方案

他们在 SchemaBridge 中构建了一个“蓝绿部署工作流”：

1. 部署 Green：在旧版本（Blue）旁边启动新版本的引擎（Green）。

2. 影子流量：配置 API 网关（第九部分），将实时流量的通用副本发送给 Green（发送即忘）。Green 的响应不会发送给用户，但会被捕获记录。

3. 验证：工作流监控 Green 的日志长达 10 分钟。它使用 JSONata 来比较 Green 与 Blue（实时版本）的财务输出。

4. 决策点：

5. 切换：工作流更新负载均衡器，将真实用户流量切换到 Green。

6. 清理：再等待一个小时（以便于回滚），然后销毁 Blue。

结果

他们将部署风险降低到接近于零。SRE 团队可以触发一次部署然后去吃午饭，因为他们知道工作流会自动处理复杂的验证、监控和回滚逻辑。他们的部署频率从每周 1 次提升到每天 10 次。

成本管理：FinOps 的“工作流”

云成本优化（FinOps）常常是一个靠不断催促开发者关闭资源的手动过程。SchemaBridge 让你能够自动化这项治理工作。

“夜间守望者”模式

你可以部署一个“夜间守望者”工作流，每天晚上 8 点运行。

1. 扫描：找出所有带有非生产标签的资源。

2. 检查活动：检查 CloudWatch 指标，看过去一小时内 CPU 使用率是否低于 5%。

3. 关闭：如果空闲，则停止该实例（而非终止）。

4. 通知：向所有者发送一条 Slack 消息：“我们暂停了你的开发机以节省费用。点击这里恢复。”

5. 恢复：当开发者第二天早上点击按钮时，一个信号（第七部分）会唤醒该工作流，重新启动实例。

这个简单的工作流为我们的一位企业客户每月节省了 40,000 美元的 AWS EC2 成本。

对比：Jenkins/GitLab CI vs. SchemaBridge 运维

| 特性 | CI/CD 流水线（Jenkins） | SchemaBridge 运维 |

| :--- | :--- | :--- |

| 状态 | 临时性（重启即丢失） | 持久化（可存续数年） |

| 持续时间 | 分钟/小时级 | 天/周/月级 |

| 逻辑 | 脚本化（Bash/Groovy） | 可视化（图） |

| 审批 | 基础（UI 按钮） | 丰富（Slack/邮件/Webhook/移动端） |

| 恢复 | 从头重试 | 从失败点恢复 |

| 并行性 | 受限于执行器数量 | 无服务器弹性伸缩（第三部分） |

运维自动化专家检查清单

要实现你的运维技术栈的现代化，请遵循以下启发式原则：

1. 不要用脚本写等待逻辑：如果你在 bash 中写 sleep 60 来等待一个 ALB 就绪，那你就做错了。请在持久化工作流中使用轮询循环。

2. 先自动化删除逻辑：在编写创建逻辑之前先编写清理逻辑。确保每一个创建事件都有对应的销毁路径。

3. 使用审批关卡：不要害怕在高风险操作中加入人工审核环节。“暂停以待批准”是一项功能，而不是一个缺陷。

4. 审计操作者：记录谁触发了该环境以及为什么。使用工作流上下文，用请求者的 User_ID 为资源打标签。

5. 将运维视为代码：像对待应用代码一样对你的运维工作流进行版本控制。使用 SchemaBridge 的 Git 集成来审查部署逻辑的变更。

结论：云是一台状态机

你的基础设施不是一堆静态的服务器；它是你业务中一个鲜活的组成部分。通过将其视为状态机，你可以自动化那些如今正在耗尽 SRE 团队精力的复杂多步骤运维流程。你可以从“基于工单的运维”转向“自助式运维”，同时内建安全性与持久性。

在第十二部分，我们将探讨“冷启动神话”，以及如何在无服务器事件架构中实现亚毫秒级延迟，而无需让服务器保持“热身”状态。

深入了解