# 基础设施即代码：为业务应用自动化服务器与云环境

> 面向企业的 IaC 指南：可复现环境的好处、声明式方法、常见工具、状态与机密风险、漂移、何时值得使用以及分阶段采用计划。

Source: https://www.agsora.tech/zh/blog/infrastructure-as-code-dan-otomatisasi-lingkungan-untuk-aplikasi-bisnis
Category: 技术 · Published: 2026-11-05 · Updated: 2026-11-05 · By PT Agsora Teknologi Indonesia

在许多公司里，服务器和云服务是以传统盖房子的方式搭建的：有人在控制台点几个菜单、敲几条命令、从旧笔记里抄一些设置，然后一切就运转起来了。只要那个人还在、记忆良好，就没有问题。但当他休假、跳槽，或服务器在事故后必须重建时，没有人确切知道那个环境当初是怎么搭起来的。测试环境悄悄地与生产环境不同，“在我电脑上是好的”成了熟悉的借口。

基础设施即代码（Infrastructure as Code，IaC）就是解决之道：基础设施被描述为存放在代码仓库中的文本文件，像应用代码一样被评审、测试，并由自动化工具执行。本文面向企业主和技术经理介绍这一概念：它的好处、何时值得使用、常见工具与实践、风险，以及如何在不干扰运营的前提下逐步开始。我们并不建议所有人都使用 IaC；对某些小企业来说，更简单的做法就足够了。

## 摘要

- IaC 把服务器、网络、数据库和云服务定义在可读、可评审、可重复运行的文件中
- 主要好处：环境可复现、变更有记录、恢复更快，以及开发、测试和生产之间的一致性
- 常见工具包括 Terraform 或 OpenTofu、Pulumi、云厂商原生模板，以及用于服务器配置的 Ansible
- 风险：学习曲线、可能批量删除资源的错误，以及机密泄露到代码仓库
- 从小处着手：一个环境、一个仓库、变更评审和安全的状态存储
- 对于托管平台上的简单网站，完整的 IaC 往往是过度投入

*写成代码的基础设施可以像软件一样被评审和追踪*

## IaC 解决的问题

看看手动搭建基础设施时经常出现的症状：

- **雪花服务器**：由于累积的手动修改，每台服务器都是独一无二的，没人敢碰它或重建它
- **环境差异**：测试环境与生产环境不同，所以缺陷只在发布后才出现
- **知识只存在于一个人的脑中**：文档过时或根本不存在
- **变更无迹可寻**：谁修改了防火墙规则，何时，为什么？
- **恢复缓慢**：事故或数据中心故障后，重建需要数天
- **游离的成本**：为试验创建的资源被遗忘，持续产生费用

IaC 不会自动解决所有问题，但它提供了以软件开发同样的纪律来解决问题的基础。

## 两种方式：声明式与命令式

- **声明式**：你写下期望的最终状态（“有一个符合这些规格的数据库和一个带有这些规则的网络”），由工具计算达成该状态的步骤。Terraform、OpenTofu 和云厂商原生模板都是这样工作的。优点是重复运行同一文件会得到相同的状态（幂等）
- **命令式**：你写下要执行的命令序列。Shell 脚本属于此类。灵活，但更容易发生偏差，也更难保证每次结果相同

有些工具，如 Pulumi，使用通用编程语言来编写声明式定义。工具的选择应当基于团队技能，而不是潮流。

## 常见工具及其作用

### 资源供应：构建资源

Terraform 和 OpenTofu（开源分支）可跨多个服务商描述云资源。Pulumi 使用 TypeScript 或 Python 等语言。每个云服务商也提供自己的模板。跨服务商工具可以减少（但不能消除）对单一供应商的依赖。该主题在[云与企业软件的供应商锁定：退出策略](https://www.agsora.tech/zh/blog/vendor-lock-in-di-cloud-dan-software-bisnis-strategi-keluar)中有更广泛的讨论。

### 配置管理：准备服务器内容

Ansible 等类似工具负责配置服务器内部的软件：软件包、配置文件、服务。在现代实践中，许多团队改用现成的镜像或容器来取代这一步。

### 容器与编排

容器把应用及其依赖打包在一起，使其在任何地方运行结果一致。IaC 随后构建容器运行的环境。容器何时有用、何时过度，见[企业应用的 Docker 与容器](https://www.agsora.tech/zh/blog/docker-dan-container-untuk-aplikasi-bisnis-kapan-perlu-dan-kapan-berlebihan)。

### 自动化流水线

IaC 的变更通过 CI/CD 流水线运行，流水线展示变更计划、请求批准，然后执行。这一概念与[企业应用的自动化测试与 CI/CD](https://www.agsora.tech/zh/blog/pengujian-otomatis-dan-ci-cd-untuk-aplikasi-bisnis)相一致。

## 可以现实期待的好处

### 可复现的环境

测试和生产由同一份定义构建，差异仅在于规模和数据。你可以创建临时环境来测试发布，然后删除它，从而节省成本。

### 可评审的变更

基础设施变更与代码变更走同样的流程：提出、同行评审、批准，并记录在版本历史中。“谁改了什么”的问题可以从历史中得到答案。

### 更快的恢复

如果环境丢失，只要数据仍可从备份中取得，就可以根据定义重建。IaC 不能替代备份，却是[灾难恢复与业务连续性计划](https://www.agsora.tech/zh/blog/rencana-pemulihan-bencana-dan-kesinambungan-bisnis)和[企业数据备份策略](https://www.agsora.tech/zh/blog/strategi-backup-data-bisnis)的重要补充。

### 成本控制

由于所有资源都列在代码中，很容易找出正在运行的资源及其负责人。自动成本标签有助于报告，与[企业的云成本控制](https://www.agsora.tech/zh/blog/mengendalikan-biaya-cloud-untuk-bisnis)一致。

### 更一致的安全性

网络规则、加密和访问权限只需设定一次并统一应用。扫描工具可以在应用之前检查定义，以发现危险配置，例如向公众开放的数据存储。

## 风险及其管理

### 大规模错误

一行错误的代码就可能删除生产数据库。缓解措施：

- 应用之前务必评审变更计划（plan）
- 对关键资源启用删除保护
- 分离权限：并非每个人都能应用到生产环境
- 先应用到测试环境
- 确保存在数据库备份，并且恢复已被测试过

### 状态文件与机密

声明式工具会保存“状态”，即受管资源的记录，有时包含敏感值。请把状态保存在带有访问控制的加密远程存储中，而不是笔记本上。不要把密码或 API 密钥写进代码文件；使用机密管理服务，见[企业应用中的机密与 API 密钥管理](https://www.agsora.tech/zh/blog/manajemen-secret-dan-kunci-api-di-aplikasi-bisnis)。

### 漂移（drift）

如果有人在代码之外通过控制台修改资源，实际状态就会偏离定义。制定政策：变更只能通过代码进行，并定期运行漂移检查。

### 过度复杂

嵌套的模块和过于聪明的抽象让新成员难以理解。请选择简单性和清晰的文档。

### 对某个人的依赖

如果只有一个人懂 IaC，你只是把老问题挪了位置。通过共同评审和文档来传播知识，与[软件项目的技术文档与交接](https://www.agsora.tech/zh/blog/dokumentasi-teknis-dan-serah-terima-proyek-software)一致。

## 让 IaC 成功的实践

- **一个清晰的仓库**，按环境或按服务划分文件夹结构
- **小型可复用模块**，用于网络或数据库等常见模式，但不要过度
- **锁定工具和服务商版本**，避免结果悄悄改变
- **强制变更评审**，至少由一位同事完成
- **对定义进行自动安全扫描**
- **一致的命名和标签**，涵盖环境、负责人和成本中心
- **定期恢复测试**：真正在沙箱中从零重建环境，以证明定义是完整的
- **记录**应用事件，并配合[可观测性、日志和错误处理](https://www.agsora.tech/zh/blog/observabilitas-log-dan-penanganan-error-aplikasi-bisnis)

## 何时值得使用，何时还不必

### 值得考虑的情形

- 你有不止一个环境（开发、测试、生产）
- 基础设施由许多组件构成：网络、数据库、队列、存储、服务
- 接触基础设施的人多于几个
- 审计或合规要求有变更轨迹
- 你经常创建和删除临时环境
- 事故后的恢复时间必须很短

### 可能暂时不需要的情形

- 网站或应用运行在隐藏了基础设施的托管平台上
- 只有一台简单的服务器，变更很少
- 小团队没有时间学习新工具，风险大于收益

对于第二种情形，只需把服务器搭建步骤整理好并保留一个简单的脚本，这已经是一种进步。关于托管平台和基础设施位置的考量，可阅读[云端还是本地部署](https://www.agsora.tech/zh/blog/cloud-atau-on-premise)。

## 分阶段采用计划

### 第 1 阶段：盘点（1 至 2 周）

- 列出所有现有资源及其负责人
- 标记手动创建且无文档的资源
- 找出风险最高或最常被重建的环境

### 第 2 阶段：小型试点（2 至 4 周）

- 选择一个低风险组件，例如测试环境或存储桶
- 编写其定义，保存在仓库中，并通过流水线应用
- 记录障碍和所需时间

### 第 3 阶段：扩展到网络和数据库

- 谨慎地把现有资源导入代码，且不更改它们
- 启用删除保护和强制评审
- 把机密迁移到机密管理服务

### 第 4 阶段：生产与自动化

- 仅通过流水线应用生产变更
- 添加安全扫描和漂移检查
- 定期演练恢复

每个阶段都有各自的价值，因此如果额外收益不值得付出努力，你可以随时停下。

## 与应用发布的关系

IaC 管辖应用在哪里运行，而应用发布管辖运行什么。二者协同工作：流水线构建、测试并把应用部署到由 IaC 构建的环境中。[功能开关与渐进式发布](https://www.agsora.tech/zh/blog/feature-flag-dan-rilis-bertahap-untuk-aplikasi-bisnis)等技术降低变更风险，而 IaC 确保变更运行的环境一致。

## 成功的衡量标准

- 从零构建新环境的时间（从数天缩短到数小时或数分钟）
- 通过代码管理的生产资源所占百分比
- 经过评审的基础设施变更数量
- 由手动配置引起的事故数量
- 演练得出的恢复时间
- 没有负责人或标签的资源成本

## 常见问题

### IaC 只适合大公司吗？

不是。拥有几个环境的小团队同样可以受益。但学习成本是真实的，所以应按需求选择范围，并从小型试点开始。

### Terraform 还是 OpenTofu，该选哪个？

两者在概念和语法上相似。选择往往取决于许可证、生态系统支持和公司政策。最重要的是团队内保持一致并锁定工具版本。

### IaC 会取代数据备份吗？

不会。IaC 重建的是基础设施，而业务数据只能从备份中恢复。两者都必须存在并经过测试。

### 已经手动创建的资源怎么办？

可以逐步导入代码。要谨慎进行，核实变更计划没有显示不想要的修改，并从低风险组件开始。

### 团队需要多久才能适应？

因团队经验而异。许多团队在几次试点后就相当适应，但模块、测试和安全策略等最佳实践需要数月才能形成。

## 结论

基础设施即代码把基础设施从脆弱的手工活变成可以评审、重复和恢复的流程。对于拥有多个环境、团队在成长或有审计需求的企业，收益最大。从小型试点开始，保护机密和状态，要求评审，并定期演练恢复。

Agsora 帮助企业为业务应用设计架构、发布流水线和环境自动化，从简单的托管平台到更复杂的云基础设施。告诉我们你当前的基础设施情况，我们将帮助确定相称的方案。

**整理你的基础设施与应用发布流程** 告诉我们你目前使用的环境和工具，Agsora 团队将帮助制定相称且安全的自动化计划。 [免费咨询](https://www.agsora.tech/zh/services/custom-software)