我在 DevOps 和 IaC 这几个仓库里的 Git 操作，九成时间只用三个命令：gfo、grbom、gpf。
不开 feature 分支，不 merge main，也不用想「这次 push 要不要加 force」。所有改动都在一条只有我自己用的长期分支 ym-dev 上，攒到差不多了，在 GitHub 上开一个 ym-dev → main 的 PR。合并之后接着在同一条分支上干活。
这篇把这套做法和背后的几个判断写下来：为什么追 main 用 rebase、为什么永远 force push，以及出岔子的时候怎么收拾。
我们的 ECS 集群都是 EC2 启动类型，任务一律用 awsvpc 网络模式。
刚开始搭 dev 环境的时候就撞过一次墙：机器的 CPU、内存都还有富余，新任务却起不来，原因是 ENI 不够用了。当时的解法是打开 ECS 的 awsvpcTrunking（俗称 VPC trunk / ENI trunking），让一台 EC2 能挂更多的网卡。代价是：这个方案不是每种机型都支持。
半年多过去，环境从 dev 一路扩到 qa、preprod、prod，机型换了好几轮。某天下午我突然想起这件事：现在各个环境的 ECS 集群，还有没有 ENI 不够的隐患？换过的机型，还都支持 trunking 吗？
巧的是，同一天下午 prod 正好有个任务卡在 PROVISIONING 起不来，ENI 也一度被列为头号嫌疑。这篇就把 trunking 的原理、我们怎么落地的、怎么巡检，以及那次”差点冤枉了 ENI”的排查，一起记下来。
上一篇写 GitHub Actions 构建优化的时候，贴过一段服务仓库的 pipeline.yml，里面的 run-name 会把运行分成三类：[PR gate]、[Path-A · dev/qa] 和 [Path-B · prod train]。当时没有展开讲，这篇专门说说这套发布模型。
背景是这样的：我们有十几个 Java 微服务，跑在 ECS 上，环境有 dev、qa、preprod、prod 四个。早期的流程是合并到 main 之后，一路 dev、qa、preprod、prod 串行部署下去。这样做的问题是，任何一次合并都可能一路滚到 prod 门口，”什么时候发版”和”什么时候合代码”绑在了一起。
后来我们用 Release Please 把这两件事拆开：合代码只到 qa，发版是一次单独的、有版本号的动作。
下面以 gateway 服务为例，按 workflow 源码把这套流程过一遍。
我们 prod 的 ECS 集群是 EC2 启动类型，四台节点，跑着十几个 Java 微服务。
某天发现有两个 task 一直起不来，原因是四台机器的 CPU 都被预留满了。为此提了一个 PR，把 prod 所有服务 task definition 里容器的 cpu 减半，已经合进了 DevOps 仓库的 main。
问题是，按我们的流程，task definition 的改动要走 CD 才能生效。而 CD 是从 dev 开始，经过 qa、preprod，最后才到 prod。这次又涉及所有服务，一个个从 dev 推到 prod，太慢了。
于是我的第一反应是：能不能直接用命令行，对 prod 的服务来一次 force-new-deployment？
答案是：命令行可以，但 force-new-deployment 不行。
最近一直在啃 WIZ 扫出来的漏洞，修了有一两个月。今天打开一看：某两台 Amazon Linux 2023 的 EC2，操作系统软件包漏洞突然多了大几十个、上百个。
第一反应不是「又有新 CVE 发布了」，而是：你们不是开了每天自动更新吗？
上去一查，更气。dnf-automatic-install.timer 天天在跑，journal 里全是 Success；再对比同环境另一台机器，那边包版本已经新一截了，这两台还停在旧的。不是 timer 挂了，不是没装 dnf-automatic，也不是没写 releasever=latest——配置「看起来全都对」，预期作用却等于零。
气从何来？因为这不是偶发运维疏忽，而是 默认行为在逻辑上就不该和「每天更新」摆在一起。你以为自己买了份日更保险，其实保单条款里写着：索引最多可以旧两天。
preprod 里有个维护窗口：nusa-preprod-windows-patch，每天凌晨 03:17（Asia/Singapore）跑 AWS-RunPatchBaseline，目标是两台带 PatchGroup=preprod-windows 的 PowerBI Gateway。
某天随手翻了一下执行历史，发现一件不太妙的事：
从 6 月 25 号到 7 月 24 号，最近三十来次执行，全部 Failed。
不是偶发超时，不是某一台掉线，是窗口级天天红。SSM Agent 在线，机器也跑着，任务确实打上去了——然后挂在 Windows 补丁搜索这一步。
错误信息不长，但很「经典」：
1 | An error occurred when attempting to search Windows Update. |
前段时间升级了一下公司的 SonarQube，版本升到了 2026 年 7 月版。
这个 SonarQube 是通过 AWS 的公网 ALB 对外提供服务的。既然放在公网，虽然不是谁都能登录，但让它就这么裸奔着总觉得不太合适，于是我在 ALB 前面加了一层 AWS WAF。
WAF 里启用了几组 AWS Managed Rules，包括：
AWSManagedRulesCommonRuleSetAWSManagedRulesKnownBadInputsRuleSetAWSManagedRulesSQLiRuleSetAWSManagedRulesAmazonIpReputationList另外还加了一个按 IP 限速的规则。
SonarScanner 上传的数据比较大，所以当时还专门对 SizeRestrictions_BODY、CrossSiteScripting_BODY 和 SQLi_BODY 做了放行或者只计数处理。
过了几天，我又给 SonarQube 加了一层 IP 白名单：只有办公室出口 IP 和 GitHub Actions 的公网 IP 才能访问。
为了不影响同一个 ALB 后面将来可能挂的其他服务，这个白名单不是直接加在 ALB 的 Security Group 上，而是在 WAF 里根据 HTTP Host 匹配，只限制 SonarQube 的域名。
看起来考虑得还挺周全。
然后，坑就挖好了。