Pulumi 漂移检测与协调器

要解决的具体问题

基础设施即代码（IaC）落地后，最常见的隐患不是模板写错，而是 状态漂移：有人绕过 Pulumi 直接在控制台改了安全组规则、调了实例规格，或者删除了资源又手工重建。此时 pulumi.stack.output 与真实环境逐渐背离，后续任何 pulumi up 都可能引入意料之外的破坏性变更，而团队往往直到事故复盘才发现漂移早已发生。

该技能要解决的就是这类“没人声明、没人审查、却真实存在”的差异：把漂移检测变成常态化机制，而不是依赖上线前的一次性人工比对。

技能如何工作

核心流程分为三步：

• 定期检测：按计划对目标 stack 执行 pulumi refresh，将云上真实状态与 Pulumi state 做差异比对；
• 分级归类：对检测到的漂移按严重程度分类，区分出非破坏性漂移（如标签、副本数等可安全覆盖的差异）与破坏性漂移（如资源被删除、关键属性被改写等可能导致服务中断的变更）；
• 分流处理：破坏性漂移自动创建 Jira 工单，交由人工评审确认后再决定恢复动作；非破坏性漂移则直接执行 pulumi up --target <resource>，只针对漂移的具体资源做协调，避免整栈 apply 引入无关变更。

这样的设计把“检测”与“处置”拆开：低风险差异自动收敛，高风险差异强制走人审，而不是一股脑重新 apply。

适用边界与注意点

• 协调操作最终依赖 pulumi up --target，该参数仅在指定资源范围内生效，不会自动处理依赖链之外的其他漂移，长期运行仍需配合整体对账；
• Jira 工单的创建依赖外部系统的访问凭据与项目配置，未配置时破坏性变更不会被记录；
• 执行账户必须具备目标云厂商的相应权限，尤其是 refresh 与资源写操作权限；
• 技能本身只负责检测与分流，不改变 Pulumi 的状态管理语义，state 损坏或栈结构重构仍需人工介入。