DevOps 中的往返工程:Tornado 框架解析
1. 背景与动机
在 DevOps 持续开发过程中,目前大多侧重于正向流程(Dev → Ops),而反向流程(Dev ← Ops)缺乏标准且受技术支持的流程。许多组织采用仅正向的开发策略,通过基础设施即代码(IaC)确保运行系统与设计和配置(D&C)规范的一致性,但 DevOps 工程师和操作员仍依赖手动的错误发现和探索性实验过程来修复故障。若不及时更新 D&C 规范,会导致配置漂移、雪花配置、环境侵蚀和其他技术债务。因此,需要一种方法来保持 D&C 规范的同步。
自动往返工程(RTE)可自动维护 D&C 规范与运行系统之间的一致性。为实现这一目标,我们引入了 Tornado 框架,它将持续集成(CI)的概念从传统应用扩展到将运维工作集成到开发中,实现了双向可追溯性。
1.1 实验与规范更新
在类生产环境中进行实验时,DevOps 工程师和操作员会进行临时修改以开发新功能和修复故障,相应的 D&C 规范(如 Terraform 模板)需要更新。这些更新包括低级配置(如打开防火墙端口、升级或降级软件包)和结构更改(如复制服务或修改虚拟资源的扩展策略)。若不适当传播这些更改,会导致配置不一致。
1.2 D&C 测试现状
目前 D&C 测试基于静态分析和功能测试。静态分析可快速反馈小的编程错误,功能测试则需部署基础设施并执行单元、集成和系统测试。但部署和重新部署系统及基础设施到沙箱环境既耗费资源又耗时,且修改一个规范可能会对其他规范产生不利影响。运行时建模似乎是一种可行的替代方案,可在部署前捕获符号的领域逻辑并