把 Terraform 当作基础设施即代码的执行引擎长期运行之后，团队迟早会撞上一个绕不开的问题：跑 plan 和 apply 的那台机器，究竟该按什么标准来配。它不承接用户请求，不需要对外提供大带宽服务，从资源监控面板上看长期处于低负载状态，看上去只是周期性执行一条命令行。恰恰是这种看起来很轻的错觉，让大量团队在资源规模上来之后付出代价。
本文不讨论 HCL 语法怎么写，也不讨论模块该怎么拆分层级。讨论的是承载这套体系长期运行的执行器：它的 CPU 花在哪些环节，内存为什么和状态文件里的资源条目数强相关，并发度为什么是第一个要调的旋钮，状态锁为什么是整个体系最关键的单点，以及磁盘、网络、API 限流这些看起来次要的环节，是如何在规模上来之后变成主矛盾的。
文中的配置量级、耗时量级、体积量级，除 Terraform 本身的公开工作机制外，均属于工程经验估算，会明确标注预估或行业经验值，实际数值请以各自环境的实测结果为准。
几乎每个团队的曲线都一样。起步阶段几十个资源，任何一台入门配置的机器都能跑，plan 几秒钟结束，apply 也不过一分钟。资源数涨到几百个，plan 开始变慢，从几秒变成一两分钟，团队的第一反应通常是加 CPU。资源数再往上走到一千以上，问题性质就变了：plan 一次跑十几分钟，apply 跑到一半失败，偶尔出现进程被系统直接杀掉。
慢的根源不是机器不行，而是最初的资源模型理解错了。Terraform 的执行器承载的不是单一类型负载，而是三种特性完全不同的负载叠加：图计算、大量等待外部返回的 API 调用、状态文件的完整读写。这三种负载的瓶颈各不相同，图计算吃的是单核性能与内存带宽，API 调用吃的是延迟与并发控制能力，状态读写吃的是小文件顺序读写速度与网络往返时间。
用一句话概括这个负载形态：Terraform 执行器是短时突发加长时等待型负载。CPU 曲线是锯齿状的，峰值很高但持续时间短，中间大量时间空等在 API 返回上。按照这个形态去配，买大了长时间闲置浪费预算，买小了峰值段直接卡死。这也是为什么很多团队在监控上看平均利用率只有百分之十几，却依然频繁遇到超时的原因。
把一次完整的执行拆成三段看，资源画像会清楚很多。第一段是初始化，主要动作是下载 provider 插件、拉取模块、生成锁文件与缓存目录，这一段的瓶颈在磁盘写入与出网质量，CPU 基本不参与。第二段是 plan，先是 refresh，对状态里记录的每一个已存在资源发起一次或多次读取请求，把真实属性同步回来，然后构建依赖图、遍历图、计算差异，这一段 CPU 与内存同时上。
第三段是 apply，按照依赖图的拓扑顺序并发调用写接口，每完成一批就把最新状态写回后端。这一段的主要时间花在等待云厂商返回上，尤其是创建数据库实例、负载均衡、证书签发这类本身就慢的资源，并发度开到多大都不会让它们变快。理解这三段各自吃什么资源，是后面所有配置决策的前提。
还有一个容易被忽略的消耗点：provider 的序列化与反序列化。云厂商接口返回的每一次响应都要在内存里转换成内部数据结构，状态文件是被完整加载进内存的，plan 过程中的中间结果也要常驻。这导致内存占用不是与机器规格相关，而是与管理的对象数量相关。下面这张表把五个维度拆开对照。
| 资源维度 | 真实压力来源 | 规模放大后的典型表现 | 选型时的关注点 | 优先调整方向 |
|---|---|---|---|---|
| CPU | 依赖图构建、差异计算、provider 序列化与反序列化 | 图越大单次 plan 的串行段越长，曲线呈锯齿状 | 单核性能优先于核心数量 | 拆分状态、降低单图规模 |
| 内存 | 状态全量加载、接口响应缓存、plan 中间结果 | 条目数破千后占用明显抬升，极端情况触发 OOM | 按状态条目数估算，而非按命令行经验估算 | 拆分状态、减少单进程管理的对象数 |
| 磁盘 | 插件缓存目录、plan 文件、调试日志与审计日志 | 多项目多 provider 下缓存可达数百 MB 至数 GB（预估） | 容量与随机读写都要给足，优先固态盘 | 复用插件缓存、定期清理历史 plan 文件 |
| 网络 | 多家云开放接口、状态后端、模块仓库、私有模块源 | 延迟放大导致 refresh 耗时成倍增加 | 看延迟与稳定性，不看带宽峰值 | 执行器靠近云接口、后端同地域部署 |
| 并发 | 并发度参数决定的图遍历宽度 | 调大撞限流，调小则线性变慢 | 按最受限那家云的配额反推 | 队列化流水线，控制同时运行的作业数 |
最常见的误判是把执行器当成一台跑命令行的机器。这个判断在几十个资源时完全成立，在上千个资源时彻底失效。原因在于内存占用的三个来源都随对象数量增长：状态文件全量加载进内存，refresh 阶段累积的接口响应需要暂存，plan 产生的中间结果也要常驻到最终写回为止。
第二个来源是 provider 进程本身。Terraform 与 provider 之间是通过本地进程加远程过程调用通信的，每引入一个 provider 就多一个常驻子进程，各自占一份内存。一个同时使用公有云厂商、Kubernetes、Helm、DNS 服务商的组合， provider 子进程加起来就是一笔固定开销，这部分与资源条目数无关，但会抬高基线。
经验上的量级（预估，以实测为准）：数百条资源记录、两三个 provider 的场景下，4G 内存在多数时候勉强够用；条目数上千且 provider 数量超过三四个时，8G 起步会更稳妥，16G 能留出比较从容的余量。这里的关键结论是，内存规划的输入变量不是服务器型号，而是单个状态里的资源条目数乘以 provider 数量。
内存不够的表现不是变慢，而是进程被系统直接终止。这在 apply 场景下尤其危险：状态可能已经写入了前半部分的变更，后半部分没跑完，留下一批处于中间状态的资源，下一次 plan 会看到大量意外差异，人工修复的代价远高于当初多配几 G 内存。
并发度参数控制的是遍历依赖图时同时处理的节点数，它不是线程数，也不是进程数，更不是 CPU 核心数的映射。常见默认值为十这一量级（不同版本的默认值可能调整，以实际使用版本为准），这个默认值是一个兼顾各家云限流能力的折中，不是最优值。
调大的诱惑很直接，apply 耗时看起来会缩短。但它受三重天花板限制：第一是云厂商的接口限流额度，第二是 provider 自身的连接池与重试配置，第三是目标资源本身的创建速度。第三重最常被忽略，创建一个托管数据库实例本身就要几分钟，并发开到五十也不会让它变成几秒，反而会挤占限流额度，让其他资源跟着一起变慢。
调太小则是另一个极端。refresh 阶段需要对大量资源做读取，如果并发度压到很低，这部分就会近似线性地变慢，上千资源的环境里 refresh 独占十几分钟并不罕见。经验区间（行业经验值）是多数团队在十到三十之间试，超过某个点之后耗时曲线就变平甚至开始反弹，那个拐点必须由自己环境的实测来确定。
第一步，把每个 provider 对应的云厂商限流额度列出来。限流的口径各家不同，有的是每分钟请求数，有的是每账号每秒写入数，有的是按地域或者按单个接口单独计数，需要逐条查清楚，不能混着算。
第二步，区分读操作与写操作的额度。refresh 阶段主要是读，apply 阶段主要是写，两者的额度往往相差很大，写操作的额度通常比读低一个量级。多数团队踩坑是因为按读额度去估 apply 的并发，结果写操作先撞墙。
第三步，估算单次变更会产生的写请求数量，大致等于发生变化的资源数乘以每个资源的平均请求次数（行业经验值，含创建后的轮询等待，通常在二到五次之间）。第四步，用可用额度除以同时在跑的流水线数量，再除以一个安全系数，得到的就是并发度的量级参考。安全系数建议留三成左右的余量（行业经验值），用于人工操作、监控系统、告警探测等额外的接口调用。
需要强调的是，这套算法给出的是量级而不是精确值。它的价值在于把凭感觉调参数变成有依据的推算，最终仍然要用真实流水线跑一段时间来校准。
多云编排的场景下，一次 apply 会同时打向多家云的接口。问题在于并发度参数是一个全局单值，无法按 provider 分别设置。于是只能按最受限的那家来定，代价是其他几家被压着跑，明明还有余量却用不上。
各家的限流模型差异很大。有的按账号维度计数，多地域共享一个额度；有的按地域独立计数；有的对读接口和写接口分别设限；还有的对部分高危接口单独设更低的阈值。多云环境下，最受限的那家往往不是你以为的主云，而是某个被顺带管理、配额最小的边缘服务。
根本解法是拆状态。把不同云的资源拆成独立的状态文件，各自拥有独立的并发度、独立的流水线、独立的锁粒度，互不牵制。这同时解决了内存占用过高的问题和锁竞争过久的问题，是一步解决三件事的改动。
另一个可选手段是分阶段执行，用按目标资源过滤的参数把一次大变更切成几段。但这个手段要谨慎，它会留下不一致的中间状态，只建议用于故障恢复和紧急修复，不建议作为日常手段使用。
状态文件是一份账本，记录的是代码描述与现实资源之间的映射关系。理解这一点，就能理解锁为什么必须存在。两个 apply 并发写同一个状态时，后启动的那个是以它启动时读到的旧状态作为基线的，它会判定前一个 apply 刚创建的资源不在代码里，于是发起删除。
这里最危险的地方在于，并发写状态不一定报错。它可能安静地执行了一次误删，也可能把资源属性写回旧值造成配置回滚。报错反而是好事，因为能立刻发现；静默地做错事才是真正的灾难，往往要等到业务侧出现抖动才被察觉。
所以锁的作用非常朴素：同一时刻只允许一个写操作持有状态。本地状态文件不具备锁能力，任何有两人以上协作、或者有 CI 流水线自动执行的场景，都必须使用支持锁的远程后端。这一条没有例外，也不存在用流程约定替代锁的可靠方案。
主流实现形态是对象存储保存状态文件本体，另外用一张锁表或一个锁文件记录锁的持有者。锁记录里通常包含持有者标识、加锁时间戳、操作 ID 这几项信息，用于在冲突时告诉排队的人是谁在占用。
加锁的流程是固定的：写操作开始前尝试写入锁记录，写入成功才继续执行；执行结束或失败退出时删除锁记录。这要求加锁动作本身具备原子性，也就是说两个执行器同时抢锁时，只能有一个写成功，另一个必须明确地失败而不是覆盖。
不同后端的具体实现细节有差异，但原理一致，都是借用存储层的原子写能力来表达互斥。选型时需要注意两点：一是锁存储本身也要高可用，锁存储不可用时整套基础设施即代码体系会直接停摆；二是执行器使用的身份必须对锁存储具备完整的读写权限，很多加锁失败其实是权限问题而不是争用问题。
另外要留意锁超时参数与不使用锁参数。有些操作希望只读不抢锁，有些场景希望等待锁而不是立刻失败，这些都要通过相应参数显式声明，默认行为不一定符合预期。参数名称与默认值请以实际使用的版本文档为准。
遇到加锁失败，第一件事是读出锁记录里的持有者标识和时间戳。如果时间戳是很久以前的，基本可以判断是残留锁；如果是几分钟内的，大概率是有人正在跑。
第二步是确认是不是同事正在操作。这一步靠沟通，不要直接强制解锁。团队规模稍大时，建议在聊天工具里建立执行前的简短公告习惯，成本极低但能避免大部分冲突。第三步是确认是不是流水线并发触发，同一个仓库的两条流水线被同时拉起是最常见的争用来源，尤其是合并请求触发加定时触发叠加的时候。
第四步排查权限。执行器所使用的身份对锁表的读写权限是否齐全，跨账号场景下角色授权是否覆盖了锁存储，这是最常被忽略的一类加锁失败，表现为时好时坏或者换环境就不行。第五步排查网络，到状态后端的延迟过高会让加锁请求超时，表现出来的现象同样是锁打不上或者锁莫名丢失。
把这五步走完再决定要不要动锁。跳过排查直接删锁，短期看解决了问题，长期看等于把并发保护机制废掉了。
残留锁的来源很集中：操作者手动中断、流水线超时被强制终止、执行器宕机、容器被驱逐、网络中断导致解锁请求根本没发出去。这几种情况的共同点是解锁动作没有执行，锁记录留在存储里变成了幽灵锁。
处理流程要严格按顺序走。先确认没有任何正在运行的操作，包括查看执行器上的进程、查看流水线面板、在团队里问一圈。确认之后，使用后端提供的强制解锁能力释放，多数实现都提供了这类命令，需要传入锁 ID，锁 ID 可以从报错信息里拿到，这样即使锁记录损坏也能强制清除。
解锁之后不要直接继续原来的操作，而是立刻跑一次 plan，观察是否出现意外差异。因为上一个操作是在中途被打断的，现实资源与状态记录之间可能存在偏差，这次 plan 的作用就是把这个偏差暴露出来。
预防比处理更重要。流水线作业要设置合理的超时时间与优雅退出窗口，容器执行时要给足终止等待时间，让解锁动作有机会执行完。还有一个值得做的工程投入：给锁加可观测，锁持有时长超过阈值就告警，把幽灵锁发现时间从下次报错提前到几分钟内。
这是一个需要在预算分配上明确下来的判断。执行器坏了换一台就行，状态文件坏了整套基础设施即代码体系就废了，重建映射关系的代价极大，而且在没有状态的情况下，很多资源甚至无法被正确识别归属。
因此状态文件必须做三件事：开启版本控制，让每一次写入都留下可回滚的历史版本；定期备份到另一个独立的存储位置，最好是不同的账号或不同的地域；访问权限最小化，只有执行器身份和少数管理员可读写。
备份必须能恢复，这一点要靠演练来保证。很多团队配置了备份却从未恢复过，直到真正出事才发现备份的是损坏版本或者权限不对。建议每个季度做一次恢复演练，把备份状态恢复到隔离环境里跑一次 plan 验证。
还有一个合规层面的注意点：状态文件里可能包含明文的资源属性，其中不排除敏感信息。因此状态存储的加密与访问审计同样要纳入设计，不能只关注可用性。
状态文件的读写模型是整读整写，不是增量。一次 plan 要完整下载状态文件、完整加载进内存、执行 refresh、生成新的状态、再完整上传回去。状态文件达到几十 MB 量级（预估）之后，这个完整往返就开始有存在感了。
这对执行器提出两个具体要求：一是稳定的网络往返，因为这一来一回不是一次请求而是多次交互，抖动会被放大；二是不错的中小文件顺序读写能力，状态文件解压、序列化、写临时文件都落在本地磁盘上。这两项都不贵，但配错会很明显。
大状态文件还有一个容易被忽视的连锁反应：refresh 耗时长意味着锁持有时间长，锁持有时间长意味着其他人等待时间长，等待时间长意味着出现争用和幽灵锁的概率上升。也就是说，状态变大不只是让单次操作变慢，它会放大整套体系的冲突概率。
因此拆分状态是根本解，而且拆分的维度要选对。按环境拆、按业务域拆、按变更频率拆，都比按团队拆更合理，因为拆分的真正目的是让每次操作的图规模小、锁持有时间短、锁粒度细。
延迟放大是第一层问题。状态读写不是一次请求，而是加锁、读取、写入、解锁这一串动作，每个动作至少一次网络往返，往返时间会被完整地叠加进每次操作。单次往返从二十毫秒涨到一百毫秒，一次 plan 上可能多出可观的时间（预估，按操作步数叠加计算）。
锁超时是第二层问题，也是更致命的。锁等待超时通常是一个有限值（行业经验值，从几十秒到几分钟量级，以实际配置为准），公网链路一旦抖动，一次加锁就可能直接超时导致整个操作失败。这类失败的特点是随机、难复现、重试又好了，很容易被误判为偶发问题而长期搁置。
第三层是一致性风险。长链路更容易出现写成功但返回失败之类的中间态，服务端已经写入而客户端认为失败，紧接着的重试会产生重复写。在状态文件这种场景下，重复写的后果比普通接口严重得多。
正确的做法是让执行器与状态后端尽量处于同一地域或同一内网环境。如果执行器必须部署在本地机房，就要认真评估到后端存储的平均延迟与抖动分布，把评估数据作为选型依据，而不是靠感觉判断网络好不好。
规模化之后最常见的失败是限流，常见表现形式是 429 或者各家自定义的限流错误码。应对的第一层是退避策略，指数退避配合随机抖动是标准做法，抖动的作用是避免多个执行器同步重试形成第二次洪峰，这一点在流水线并发场景下尤其重要。
第二层是 provider 层的重试配置。多数 provider 都提供了最大重试次数、可重试错误数量之类的配置项（具体名称以对应 provider 文档为准），可以在 provider 配置块里显式声明。需要分清的是，Terraform 层与 provider 层各自有重试逻辑，调参时要明确是哪一层在起作用，否则容易调了半天发现改的是无效配置。
第三层是认知层面的：重试是有副作用的。它会掩盖真实问题，把慢变成更慢，还会让失败的表象从限流错误变成超时错误，增加排查难度。所以重试次数不宜开得过大，必须配合告警去观察限流发生的频率。
正确的态度是把限流当作容量信号。限流频繁出现，说明并发度、流水线并发数或者状态拆分方式需要调整，而不是把重试次数往上加。
直觉是并发作业越多吞吐越高，实际结果往往相反。所有作业共享同一个云账号的接口配额，也共享同一个状态文件的锁。作业数翻倍之后，单个作业因为抢不到配额而变慢，限流错误增多触发重试，重试又进一步挤占配额，形成负反馈。
更糟的是锁竞争。排队等锁的作业在等待期间几乎不消耗 CPU，只是在干等。这时监控上看 CPU 利用率很低，很容易得出资源不够需要扩容的错误结论，扩容之后并发进一步增加，情况继续恶化。
正确的做法是限制同时运行的基础设施作业数量。经验值（行业经验值）是先从个位数起步，结合配额实测逐步上调，其余作业排队等待。衡量指标不是峰值最快，而是作业完成时间的分布是否稳定可预测。
换句话说，这里要做的优化是把并发换成节奏。可预测的时长对运维团队的价值，远高于偶尔跑出来的最快纪录。
第一种做法是在流水线平台层面限制并发作业数，或者使用资源组、并发组之类的机制把基础设施作业单独隔离出一个池子，避免被应用构建作业挤占。这是成本最低、见效最快的一步。
第二种做法是按云账号或者按环境分队列。不同账号的配额是独立的，把生产环境与测试环境的作业分到不同账号下，天然就实现了配额隔离。第三种做法是按变更类型拆流水线，把高频的应用配置类变更与低频的网络、数据库变更分开，避免低频的重量级操作拖慢高频的轻量级操作。
第四种做法是错峰。定时执行的漂移检测、成本扫描这类非紧急任务安排在夜间或低峰时段，避开工作时间的人工变更。第五种做法是引入令牌桶思路，给每条流水线一个配额预算，用完就排队，这样即使并发被临时调高，总量依然受控。
这些做法的共同目标是让整套体系的行为可预测。可预测意味着可以给出承诺时间，也意味着出问题时的排查范围可控。
工作目录下会自动生成一个缓存目录，里面存放 provider 插件。插件是按版本解压存放的，同一个 provider 保留多个版本会各占一份空间。项目数量多、provider 种类多的环境下，这个目录的体积达到数百 MB 到数 GB 量级（预估）并不罕见。
第二类占用是 plan 文件。使用输出参数保存的执行计划文件是二进制格式，规模较大的项目单个文件可达数 MB 到数十 MB（预估）。如果流水线习惯性保留历史 plan 文件用于审计，又没有清理策略，这部分会持续累积。
第三类是日志。打开调试日志之后体积增长很快，尤其是最高级别会记录每一次接口请求与响应的完整内容，一次操作产生数百 MB 日志（预估）是可能的。调试日志只应在排障时临时开启，排完立刻关掉。
基于以上三类，执行器磁盘的建议是优先固态盘，容量给到一百 G 起步更从容（预估），项目数量多的话向上调整，并且配套定期清理历史 plan 文件与日志的策略。磁盘是这套体系里最便宜的一环，不值得在这里省。
如果每个作业都从头初始化，每次都要重新下载一遍 provider 插件，浪费的是三重成本：出网带宽、初始化时间、以及高峰期拉取失败的稳定性风险。模块仓库在高峰期拉不动导致流水线大面积失败，是很多团队都经历过的场景。
解法是设置全局插件缓存目录，让多个工作目录共享同一份插件。多数版本支持通过环境变量指定插件缓存目录（具体变量名以对应版本文档为准）。启用之后，初始化时间从分钟级降到秒级（预估），对外部仓库的依赖也大幅下降。
需要注意的是缓存目录的并发写入。多个作业同时写同一份缓存可能冲突，常见做法是先预热一次、之后只读共享，或者每个作业使用独立缓存但由本地镜像源兜底。自建私有模块仓库或本地镜像源是更彻底的方案，适合规模较大的平台。
容器化执行器必须挂持久化卷。否则每次容器启动都是一次完整的重新下载，启动时间被拖长，磁盘写入被放大，高峰期还会因为拉取失败直接起不来。持久化卷应该同时覆盖插件缓存目录和工作目录，让缓存真正跨作业存活。
执行器的出网需求清单其实很长：多家云的开放接口、状态后端、模块仓库、私有模块源、容器镜像源、监控系统上报。这些连接有一个共同特征，单次传输的数据量都不大，但请求次数极多。
因此决定体验的指标是平均往返时间、抖动、丢包率、域名解析稳定性，而不是带宽峰值。一次 refresh 对上千个资源做读取，每个读取至少一次往返，往返时间从二十毫秒涨到一百毫秒，总耗时的变化是按请求条数放大的，这个放大效应比带宽瓶颈明显得多。
丢包的影响更非线性。一次丢包触发重传，可能直接撞上锁超时或 provider 层的超时阈值，把一个本来只是稍慢的操作变成彻底失败。所以评估网络质量时，要测的是分布而不是平均值，取多次采样的高分位值才有意义。
域名解析也值得单独测。部分环境下解析耗时占比不低，尤其是访问境外接口时。执行器上配置稳定的解析服务并保持合理的缓存策略，是成本低收益明确的优化项。
多云场景下的选址目标和单云不同。单云选址很简单，放在主云同地域即可。多云要找的是到各家接口延迟都在合理区间的折中点，优化目标是中位延迟和最差延迟，而不是让某一家最优。
具体做法是先列出执行器需要访问的所有接口端点，然后从候选位置逐个做延迟采样，采样要覆盖工作日的不同时段，取高分位值做比较。中国香港常被作为境内与境外接口访问的折中位置之一（工程上的常见做法），是否适合取决于你的实际端点分布，必须以实测数据判断，不要凭地图估算。
如果涉及中国台湾或者其他地区的节点，判断标准同样是实测延迟与抖动，而不是地理位置上的远近。跨运营商、跨海缆的链路质量差异很大，实测是唯一可靠的依据。
出网质量还包括链路类型。需要表达优质链路时，用优化回程线路、专属带宽、直连链路这类描述即可，关键在于索要实测的延迟与丢包数据。以一万网络（天下数据品牌，深耕 19 年，成立于 2007 年）这类具备多地域节点的服务商为例，选型阶段同样应当要求提供到目标云接口的实测延迟采样，而不是只看带宽标称值。
Terraform 的特征是声明式配置语言、状态驱动、变更前可预览完整差异、provider 生态覆盖面最广、多云体验一致。它的弱点也很明确：状态管理本身带来复杂度，抽象表达能力有限，遇到复杂条件逻辑会写得很别扭。
Ansible 是过程式的、无状态的、通过远程连接驱动的，擅长机器内部的配置动作，比如安装依赖、修改内核参数、下发配置文件、启停服务。它的弱点是没有资源应当存在这个概念，用来创建云资源会遇到幂等难以保证、无法可靠销毁的问题。
Pulumi 用通用编程语言描述基础设施，抽象与复用能力强，同样有状态概念，适合需要大量程序化逻辑的场景。取舍在于团队需要具备相应的编程规范与代码评审能力，否则容易写出难以维护的动态逻辑，它的 provider 生态相对小一些。
CloudFormation 与单一云深度绑定，原生的排队、回滚、漂移检测能力比较完善，模板冗长是主要痛点，跨云场景基本不可用。选择框架时真正要看的是三个问题：主要管理什么资源、是否需要跨云、团队当前的技能结构是什么样的。
真实工程里这两者不是替代关系而是分工关系。Terraform 负责的是资源的存在性：网络、子网、安全组、计算实例、负载均衡、数据库实例、对象存储桶，回答的是该不该有这个东西。Ansible 负责的是资源内部的状态：装什么软件、改什么配置、跑什么服务，回答的是这个东西现在是什么样。
为什么不互相替代。让 Terraform 去管理配置文件内容会很痛苦，模板转义复杂，而且这些内容进状态文件会让状态急剧膨胀。让 Ansible 去创建云资源则缺少状态基线，无法判断该创建还是该跳过，更无法可靠地执行销毁。
衔接方式有两种主流做法。一种是 Terraform 执行完输出机器清单，包含地址、主机名、分组信息，交给 Ansible 作为编排输入消费。另一种是 Terraform 在创建实例时注入一段轻量初始化脚本，完成基础引导后由 Ansible 接管后续配置。
需要特别警惕的是边界重叠。同一个属性如果两边都在管，就会出现互相覆盖的抖动，比如安全组规则 Terraform 写一遍、Ansible 又改一遍。明确划分归属并保持单一来源，是这套组合能长期稳定运行的前提。
适用条件是单个状态的资源条目数在数百以内、provider 数量一到两个、流水线执行频率低。参考配置（预估）：四核八 G 内存、一百 G 固态盘、流水线同时运行的基础设施作业数一到两个。这个档位的瓶颈通常不在硬件，而在状态后端选型是否正确、锁是否启用。
适用条件是资源条目数上千、涉及两到三家云 provider、每天有多次流水线执行。参考配置（预估）：八核十六 G 起步，资源规模偏大或 provider 较多时上到十六核三十二 G，两百 G 固态盘，流水线并发作业三到五个，状态后端与执行器同地域部署，插件缓存使用持久化卷。
适用条件是状态已按域拆分、多团队多租户共用执行器集群、变更频率高。参考配置（预估）：单台十六核三十二 G 以上，但更关键的是横向拆分为多台执行器加统一队列，而不是堆一台大机器，磁盘五百 G 或更多，独立的插件缓存卷，按流水线分配配额预算。
这里有一条比配置数字更重要的原则：横向拆优于纵向堆。因为锁与接口配额是共享瓶颈，一台强大的执行器并不会让共享瓶颈消失，反而可能因为能同时跑更多作业而加剧争用。从成本角度看，建议按参考预算区间评估，把预算优先投向状态后端的高可用与备份体系，其次才是执行器的处理器规格。
验收阶段要测的指标有六项：到各家云接口端点的往返时间与抖动（多次采样取高分位）、到状态后端的延迟、域名解析耗时、磁盘随机读写性能、插件缓存预热后的初始化耗时、典型状态下一次 plan 的耗时与内存峰值。
压测的正确方式是拿生产状态的脱敏副本，在非生产的状态后端上跑完整流程。用模拟数据压测没有意义，因为图的结构、provider 的数量、资源属性的复杂度都直接影响结果。压测要记录四个数据：处理器峰值、内存峰值、限流错误次数、锁等待时长。
租用决策上的建议是先短期租用做压测，拿到真实数据再决定长期规格。基础设施执行器的规格一旦选定通常会稳定用很长时间，前期多花一点验证成本，比后期反复调整要划算。
验收时还要确认一件事：执行器到状态后端的链路是否稳定。这一项的重要性高于处理器规格，但最常被忽略，建议在合同中或交付验收单里明确列出延迟与丢包的验收口径。
第一，把状态文件提交进代码仓库。状态里含敏感信息，而且会与协作者本地状态冲突，一旦提交基本就是事故。
第二，状态存储没有开启版本控制，也没有异地备份。这是整个体系里最严重的单点风险，恢复演练也要同步做起来。
第三，多人协作或流水线自动执行却没有启用锁。本地状态文件没有锁能力，只要有第二个人参与就必须迁到远程后端。
第四，把并发度直接开到五十。多数场景下这会先撞限流，表现为大量错误和重试，实际耗时反而上升，正确做法是按配额反推。
第五，provider 版本没有锁定。不同协作者拉到不同的 provider 版本，会出现 plan 结果与 apply 结果不一致的情况，锁文件必须纳入版本管理。
第六，在生产环境的流水线里使用自动确认参数。少了人工确认这道闸门，一个错误的差异计算会直接落到生产环境。
第七，plan 文件过期之后仍然被执行。生成计划与实际执行之间如果隔了较长时间，期间的资源变化会让计划失效，流水线里应当限制计划文件的有效时间。
第八，模块源完全依赖公网。高峰期拉取失败会让整批流水线一起挂掉，应当配置本地镜像源或私有模块仓库兜底。
第九，没有做漂移检测。线上资源被手动改动之后长期与状态记录背离，等到下次 apply 时会出现大面积意外变更，应当定时执行检测并纳入告警。
第十，把所有环境塞进同一个状态文件。一次误操作的影响范围会覆盖全部环境，拆分是成本最低的风险隔离手段。
第十一，敏感信息以明文形式进入状态文件。应当使用密钥管理服务或变量注入机制，并对状态存储启用加密与访问审计。
第十二，容器化执行器没有挂持久化卷。每次启动都重新下载插件，启动慢、写入放大、高峰期还可能起不来。
第十三，状态后端与执行器跨公网远距离部署。延迟放大叠加锁超时，会制造一批随机失败，排查成本高且容易被长期搁置。
第十四，把强制解锁变成常规操作。一旦成为习惯，锁机制就形同虚设，真正需要它保护的那一次会失效。
这十四条里，前三条属于架构层面的错误，越早修正代价越小；中间几条属于配置与规范层面的问题，靠流水线卡点就能拦住；最后几条是运维习惯问题，需要靠可观测与告警来约束。
回到最初的问题，Terraform 执行器的选型之所以难，是因为它看起来是一台机器，实际上是一套体系的入口。它的性能取决于状态文件的组织方式，它的稳定性取决于锁与后端的设计，它的吞吐取决于接口配额的分配方式，这些都不是靠提升机器规格能解决的。
真正有效的顺序是：先设计状态拆分与后端的高可用，再确定锁策略与并发度，然后按最受限的云推算流水线并发数，最后才是给执行器定规格。按这个顺序走，会发现最终需要的机器规格往往比最初预估的要低，而整套体系的稳定性会高得多。
对于正在搭建这套体系的团队，一个务实的起步建议是：先用最小可用配置把状态后端、锁、备份、版本锁定这四件事做对，跑一段时间收集真实的耗时与内存数据，再据此扩容。数据驱动的第二轮决策，几乎总是比第一轮的凭经验猜测更准确。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
