1. 企业模块平台需求分析

在动手写第一行 Terraform 模块代码之前，真正决定平台成败的往往不是技术选型，而是需求是否被准确识别。企业模块平台不是"把公共模块放到一个 Git 仓库"这么简单，它要同时服务多个团队、多套环境、多类合规要求和成本约束。如果需求边界模糊，平台很容易演变成两种失败形态：一种是过度设计，做了大量没人用的抽象层；另一种是过度简陋，各团队继续复制粘贴，平台形同虚设。本章的目标是把"多团队协作、环境隔离、合规审计、成本管控"这四类核心诉求，转化为可定义、可度量、可验收的平台功能边界与成功指标。

一、先识别四类核心诉求的真实来源

需求分析的第一步不是列功能，而是找到诉求背后的角色和场景。企业里通常存在四类直接利益相关者：平台团队（模块的提供方与维护方）、业务研发团队（模块的消费方）、安全与合规团队（审计方）、财务或云成本负责人（成本方）。他们的诉求经常互相冲突，例如研发希望"改一个变量就能上线"，合规希望"任何变更都可追溯且不可绕过"，成本方希望"资源规格被强制约束"。平台的价值恰恰在于把这些冲突在模块接口层面提前化解。

多团队协作的核心痛点不是"没有模块"，而是"模块版本漂移"。A 团队用 v1.2 的 VPC 模块，B 团队用 v1.5，两者对子网 CIDR 的默认行为不同，导致网络规划对不上。因此协作诉求应转化为：模块必须有语义化版本、有明确的输入输出契约、有变更日志，且消费方通过版本约束引用，而不是引用分支或本地路径。

环境隔离的痛点在于"同一份代码在不同环境产生不同副作用"。开发环境允许公网访问、允许小规格实例，生产环境必须私网、必须多可用区、必须开启删除保护。隔离诉求应转化为：模块通过变量暴露环境差异点，但把不可协商的安全基线（如生产禁止 0.0.0.0/0 入站）固化为模块内部逻辑，消费方无法通过变量关闭。

合规审计的痛点在于"事后才发现违规"。审计诉求应转化为：模块内置策略校验（如强制标签、强制加密、强制日志），并在 CI 阶段用策略即代码工具拦截，而不是等到云上资源被扫描出来才整改。

成本管控的痛点在于"账单出来才知道超支"。成本诉求应转化为：模块对实例规格、存储类型、副本数设置可选范围，并在 plan 阶段输出预估成本增量，让消费方在合并前看到影响。

二、把诉求写成可验收的功能边界

功能边界的关键是同时写清"做什么"和"不做什么"。以模块注册为例，平台应提供模块仓库、版本标签规范、契约文档模板和消费方引用示例；但不应把某个业务团队的一次性迁移脚本纳入平台模块，否则平台会被业务细节拖垮。再以环境隔离为例，平台应提供环境变量约定（如 env = "prod"）和不可关闭的安全基线；但不应替业务决定"生产到底开几个可用区"，这属于业务参数，应通过变量暴露并给出推荐值。

下面是一份可直接用于需求评审的功能边界清单示例，字段包括诉求、平台职责、明确排除项和验收指标。示例中的数值为合理假设，用于说明指标应如何量化，实际项目需结合自身规模调整。

三、定义成功指标时要避免的陷阱

指标最容易犯的错误是"只统计数量，不统计质量"。例如"模块数量达到 50 个"并不代表平台成功，如果这 50 个模块只有 3 个被引用，反而说明平台在自嗨。更有效的指标应围绕"消费方行为"设计：模块复用率（引用平台模块的资源数 / 总资源数）、版本漂移模块数（引用非最新稳定版的模块数量）、策略拦截前置率（在 CI 阶段被拦截的违规数 / 总违规数）、成本偏差（plan 预估成本与实际账单的差异比例）。这些指标都能从 CI 日志、模块仓库标签和云账单中自动采集，而不是靠人工填报。

四、从需求到平台路线图的落地方式

需求分析完成后，不要立刻铺开做所有功能。建议按"先契约、后校验、再成本"的顺序推进：第一阶段先建立模块仓库和版本规范，让协作有基础；第二阶段加入环境变量约定和安全基线，让隔离可执行；第三阶段接入 CI 策略校验，让合规前置；第四阶段加入成本预估，让成本可见。每个阶段都对应一组可验收指标，上一阶段指标达标后再进入下一阶段，避免平台一次性铺得太大而无人使用。