用云久了，管理往往是最后才被想起的事。前期大家只关心能不能跑起来，等账单涨得让人皱眉、权限越来越乱、某台机器没人说得清归谁管，才发现问题出在管理上。阿里云的 ECS、RDS、OSS、SLB、容器服务彼此关联，资源一多，如果没有一套基本的阿里云管理办法，很快就会变成哪里都在用，哪里都没人管。
账号：先把根账号管住
根账号对所有资源都有最高权限，一旦泄露，影响面最大。所以开通之后，先把根账号的安全基线定下来，再去建资源。
- 给根账号开启多因素认证（MFA），日常操作不要再用它登录；
- 尽量删除根账号的 AccessKey，长期密钥不要写进代码仓库或本地配置文件；
- 人和程序分别使用 RAM 子账号或角色，谁用谁登，出了问题也能查到具体是谁。
常见的问题是多人共用一个带密钥的账号。人员离开后，配置文件还留在别人电脑上，测试环境的 OSS 桶被读取，往往就是这么来的。改成每人一个子账号、服务程序单独挂 RAM 角色之后，责任能对上，密钥泄露的影响也只限于一个角色。
权限：别直接给 AdministratorAccess
RAM 是权限管理的核心。直接给子账号管理员权限图省事，短期方便，长期就是风险。更稳的做法是按职责分用户组，再用自定义策略限定资源范围和操作类型。
- 开发组：只管理测试环境的 ECS，以及对应的日志查询；
- 运维组：可以启停生产实例、配置监控和告警，但不能删数据库；
- 财务组：只读账单和费用明细，不碰资源。
写策略时尽量把资源 ARN 和操作写具体。比如只允许停止带 env=test 标签的 ECS 实例，而不是对所有实例开放停止权限。这样一来，标签本身也成了权限边界的一部分。
标签：让资源能被认出来
资源一多，最常见的问题就是这台机器是谁建的、谁在用、还留不留。创建时不打标签，过一段时间就没人敢删。建议统一规范，至少包含下面四个维度。
- env：prod、test、dev，区分环境；
- project：所属项目或业务线；
- owner：负责人，出了事能找到人；
- cost-center：成本归属，方便拆账。
规范定了还要有人检查。可以每周跑一次扫描，把没有 owner 标签的资源列出来，通知创建人补上或者清理。闲置资源多半是这样一点点清出来的。
成本：从看账单到控成本
账单是最直接的信号，但只看账单，只能事后知道超了。费用中心、账单分析和预算告警可以帮你提前发现，真正省下来还要靠资源侧的调整。
- 设月度预算和阈值，用量到 80% 就通知负责人，不要等月底出账单才看到；
- 按标签拆分账单，看清每个项目实际花了多少，讨论成本时才有依据；
- 非生产环境优先用按量付费，能定时启停就定时启停，夜间和周末关掉不用的实例；
- 稳定运行的核心服务，可以评估包年包月或预留实例券，长期跑的服务通常划算得多。
测试集群长期按满配运行，没人觉得需要改，这种情况很常见。实际调整往往不复杂：夜间自动停掉测试实例，把离线计算挪到抢占式实例上，核心数据库单独评估包年方案。抢占式实例可能被回收，所以迁移前要先确认哪些任务能中断，能中断的才适合放上去。
监控：告警要少而准
CPU、内存、磁盘、网络和数据库连接数，都应该在云监控（CloudMonitor）里设阈值。但告警一多，人就会麻木，真正出事的那一条反而被淹没。关键在于分级。
只有影响业务的指标才走电话或短信，其他的进工单或群消息，由值班人员统一处理。关键服务再配健康检查和自动恢复，能自动处理的就别占用人的时间。
流程：把规则固化下来
工具和配置能搭好框架，但日常能不能守住，主要看流程。有几件事值得固定下来。
- 资源申请走审批，避免有人随手创建一批实例；
- 变更操作保留记录，通过操作审计（ActionTrail）追查关键行为；
- 定期复核权限，离职人员和过期角色及时清理；
- 用 Terraform 等基础设施即代码管理资源，配置有版本记录，出问题能回滚。
团队规模变大以后，光靠自觉不够，可以把这些规则写进资源管理平台或 CI/CD 流程，让合规检查自动执行。
从哪里开始
不必一次搭完整套。如果眼下最紧迫，先做根账号加固和闲置资源清理，这两件事见效快，风险也低。接着再补权限分组、标签规范和预算告警。管理顺了，云的弹性才用得踏实。
