深色模式
云平台运维总览
摘要：上云不等于不用运维，只是把一部分运维责任交给了云厂商。本文先讲清「共享责任模型」这条总纲，再给出云平台的服务分层地图和一套通用的上手路线，帮你建立云上运维的整体框架。
适用环境
bash
# 一台能联网的 Linux / macOS 终端（Windows 用 PowerShell 或 Git Bash）
which ssh curl jq python3
ssh -V
curl --version | head -1
# 以上工具缺失时先安装：sudo apt install -y openssh-client curl jq python31
2
3
4
5
2
3
4
5
操作步骤
一、先把共享责任模型刻在脑子里
云厂商负责「云本身的安全」，你负责「云内部的安全」。责任边界随服务类型变化：
| 服务类型 | 例子 | 厂商负责 | 你负责 |
|---|---|---|---|
| IaaS（裸资源） | 云服务器 ECS | 物理机、虚拟化、宿主机 | 操作系统、补丁、应用、数据、防火墙 |
| PaaS（托管服务） | 托管数据库 RDS | 上述 + 数据库引擎、备份机制 | 账号口令、参数调优、数据内容 |
| SaaS | 云上托管应用 | 几乎全部 | 账号权限、访问审计、自身数据 |
注意
共用责任模型最常见的误解是「用了托管数据库就不用管备份了」。托管服务通常保证备份机制可用，但不会替你决定备份保留多久、多久演练一次恢复。
二、认识云平台的服务分层
无论哪家厂商，核心能力都逃不出这几层：
- 账号与权限：IAM / RAM，是所有云操作的入口开关。
- 网络：VPC、子网、路由表、安全组——决定资源之间能否互通。
- 计算：云服务器、容器服务、函数计算。
- 存储：对象存储（OSS/S3）、块存储（云盘）、文件存储（NAS）。
- 数据库：托管 RDS、缓存 Redis、数据仓库。
- 接入与流量：负载均衡、CDN、DNS。
- 可观测：云监控、日志服务、链路追踪。
- 治理：账单、标签、配额、审计。
三、建立你的云资源清单
上云第一件事是「知道自己有什么」，用 CLI 拉取资源列表：
bash
# 以 AWS CLI 为例，列出全部地域的实例（其它厂商 CLI 用法类似）
aws ec2 describe-regions --query 'Regions[].RegionName' --output text
# 逐地域列出实例 ID / 类型 / 状态
aws ec2 describe-instances \
--query 'Reservations[].Instances[].[InstanceId,InstanceType,State.Name]' \
--output table1
2
3
4
5
6
7
2
3
4
5
6
7
四、制定一份最小运维规范
给团队定三条起步规则，成本极低但收益极大：
bash
# 1) 所有资源强制打标签（owner / env / app），便于分账与定位
# 2) 生产环境禁止使用主账号（root）操作，一律走子账号 + 最小权限
# 3) 任何手工变更，事后必须回填到 IaC 或变更记录1
2
3
2
3
验证
- [ ] 能用自己的话解释「共享责任模型」，并说出 IaaS 与 PaaS 的责任差异
- [ ] 能用云 CLI 拉出当前账号在至少一个地域的全部计算资源清单
- [ ] 团队内已有统一的资源命名与标签规范文档（哪怕只有一页）
常见坑
- 用主账号日常操作：主账号权限无法收敛，一旦泄露就是全量损失，必须只用于创建子账号和付款。
- 资源不打标签：三个月后没人记得某台机器是谁建的，成本无法分摊，也不敢删。
- 把云当物理机用：直接买机器、手动配环境，却不用镜像、弹性伸缩、托管服务，既贵又难恢复。
- 只看单价不看整体：只比较机器单价，忽略公网流量、快照存储、跨地域带宽等隐性费用。