行业动态01
一位工程师在文章里讲了一次真实故障：一次普通的 TLS 1.3 升级，悄悄把 Route 53 的健康检查弄坏了，结果 CDN 不再把流量送到其实正常运转的区域，而内部监控看板却显示一切正常。作者 Alexey Golev 想说明的是，「高可用」和「韧性」是两回事——高可用指系统平时不容易坏，韧性指真出事时能不能扛住并恢复；云服务里很多关键功能依赖看不见的控制面，一旦出问题很难被发现；如果没人明确负责，恢复能力会慢慢退化。读者能借此检查自家系统是否也有这种「看板正常但其实已挂」的隐患。至于具体怎么修、有没有配套工具，原文未说明。
行业动态02
这篇文章讲的是：员工离职或调岗后，云资源上的“负责人”标签常常没人更新，导致过了很久还有人审批自己早就不管的系统。作者提出用三步解决：先用 SQL 查询把资源负责人和云平台的登录记录对上，找出超过 90 天没登录的“沉默负责人”（AWS 和 Entra ID 有现成记录，GCP 只能查 Google Workspace 的登录时间）；再把所有权写成 IAM 角色绑定而不是普通标签，配合 Rego 策略，让移除负责人时没有接手人就自动报错；最后在离职/转岗流程里加上“这个人还管着哪些资源”这一步。这样能在下次安全审查之前就发现问题，而不是等八个月后一个陌生审批请求出现在前同事的队列里。
文中可用工具
- aws_iam_user_last_accessed_detailsAWS 的 IAM 表，记录每个账号凭证最后一次被使用的时间，用于查出长期不登录的负责人
- Entra ID微软的身份系统，保留用户的登录记录，可直接把资源的负责人标签和登录账号对应起来
- Google Workspace谷歌的办公套件，其用户登录时间是 GCP 上判断负责人是否还活跃的替代信号
- Rego一种策略语言，文中用它写了“资源不能没有负责人”的检查规则
- OPAOpen Policy Agent，一个策略引擎，文章中用它来执行 Rego 检查，需要自己部署到 CI 流程里
- Terraform基础设施即代码工具，文中提到自建的 Terraform 流水线需要额外接上 OPA 和角色存储
- env zero一个平台，自带跨组织、项目、环境的角色体系，可省去自己搭建 OPA 和角色存储的步骤