云资源自助交付平台：把「申请一台机器」做成不用找人的事
做这套东西的动机很直接：「帮我开台机器」这件事，不应该需要找人。
在园区和企业 IT 里，申请一台测试机、临时环境、演示环境，流程通常是发消息给运维 → 运维手工开 → 记在某个表格里 → 用完没人回收 → 三个月后发现一堆僵尸实例在烧钱。这套平台就是把这条链路自动化掉。
做了什么
用户提交申请后，系统自动调用云厂商 API 创建实例，配置完成后把访问信息交付给申请人。之后用户在自助控制台里就能自己完成日常操作：
- 开机 / 关机 / 重启
- 重装系统（重建实例并保留标识）
- 重置访问凭据
- 查看配额与到期时间
另有一套库存池模式：把已有的存量机器提前录入后台调优好，申请到来时从池子里分配一台，而不是每次都新建。适合那些开通慢、或者需要预先做过环境准备的场景。
技术上的几个点
云厂商 API 的差异要吃在适配层里
GCP 和 AWS 在实例生命周期上的模型不一样——创建是同步还是异步、状态机有哪些中间态、删除后资源多久真正释放、镜像和磁盘怎么关联。
所以不能让业务代码直接调 SDK。中间必须有一层适配，把两家（以后可能更多家）收敛成统一的动作集合：create / start / stop / rebuild / destroy / status。业务层只认这套动作。
异步操作必须能对账
调云 API 创建实例是异步的：接口返回成功只代表”请求已受理”，机器可能几十秒后才真正 running，也可能失败。
所以每个操作都要有：
- 本地状态机记录”我以为它在什么状态”
- 轮询或回调去核对”它实际在什么状态”
- 对账任务处理两者不一致的情况
不做对账的自动化平台，跑一段时间之后本地记录和云上实际情况一定会漂移。这和支付系统必须有查单兜底是同一个道理——任何跨系统的异步操作，都不能只依赖对方的成功返回。
凭据不能明文躺着
访问凭据的生成、交付、重置全流程都不能落明文日志。重置操作要走幂等，避免用户连点两次导致机器被改成第二次的密码但界面显示第一次的。
幂等和防重复
「创建实例」这个动作被重复提交的代价是真金白银。所以请求要带幂等键，重复提交返回同一个结果，而不是开出两台机器。
技术栈
TypeScript monorepo，前后端同仓；Docker Compose 部署，不同环境的差异显式写在各自的 compose 文件里，而不是靠某个人记得改哪个环境变量。
为什么一个做网络的人要写这个
因为运维本职里最消耗人的，就是这种”每次都一样、但每次都要人做一遍”的事。
我做了十几年信息化交付，很清楚哪些环节在浪费时间：申请要等审批、开通要等运维、回收永远没人管。这套平台的每一个功能，对应的都是我自己被这些流程卡过的一次经历。
能自己把它写出来，意味着我不用等着别人来解决这类问题——这也是我一直在补开发能力的原因。
文章分享
如果这篇文章对你有帮助，欢迎分享给更多人！