阿里云
腾讯云
华为云
仙宫云 
OneThingAI 
优刻得9.9元/7天企业上云失败，很少是因为选错了云厂商，多数是因为没有验收标准：迁移算不算成功、可用性够不够、钱花得值不值，全凭感觉。本文按四个阶段给出每个阶段的产出物和验收指标，可以直接拿去对齐目标。
阶段一：评估（2–4 周）
产出物：一份资产清单 + 一份依赖关系图。
- 盘清存量：机器数量、规格、CPU/内存实际峰值利用率、磁盘 IOPS、出网带宽
- 标注依赖：哪些系统必须同内网、哪些有硬编码 IP、哪些依赖本地硬件（加密狗、专线）
- 记录合规要求：是否需要等保、数据能否出境、是否有行业备案
验收标准：能回答"关掉这台机器，会影响谁"。
这一步做不扎实，后面必然返工。实践中被低估最多的就是出网带宽——很多本地机房的带宽账单和云上按流量计费完全不是一个量级。
阶段二：设计（3–6 周）
产出物：目标架构图 + 迁移批次表 + 成本估算。
架构决策对照
| 决策点 | 保守选择 | 激进选择 | 判断依据 |
|---|---|---|---|
| 计算形态 | IaaS 自建 | 容器 / Serverless | 团队是否有 K8s 运维能力 |
| 应用形态 | 单体 | 微服务 | 团队规模 < 10 人时单体通常更划算 |
| 数据库 | 托管 RDS | 自建主从 | 是否有专职 DBA；托管溢价约 20%–50% |
| 可用性 | 单可用区 | 同城双可用区 | 年停机容忍度是否低于 4 小时 |
| 容灾 | 备份 | 两地三中心 | RTO 要求是否低于 30 分钟 |
迁移策略：6R
| 策略 | 含义 | 工作量 | 适用场景 |
|---|---|---|---|
| Rehost | 原样搬迁（lift & shift） | 低 | 先上云再优化，赶时间 |
| Replatform | 换托管服务（自建 MySQL → RDS） | 中 | 想减少运维但不想改代码 |
| Refactor | 重构为云原生 | 高 | 有明确性能/弹性诉求 |
| Repurchase | 换 SaaS 产品 | 中 | 自研系统维护成本过高 |
| Retire | 直接下线 | 低 | 常年无人使用的系统 |
| Retain | 暂不迁移 | — | 强依赖本地硬件或合规限制 |
经验上，先 Rehost 再逐步 Replatform 的成功率明显高于一次性 Refactor。
阶段三：迁移（按批次，通常 2–6 个月）
- 先迁无状态、低风险的系统（静态站、内部工具），积累流程
- 有状态系统采用双跑 + 只读切流，确认数据一致后再切写
- 数据库迁移必须准备回滚方案，且回滚窗口要写进变更单
- 每批次迁移后立刻做一次成本核对，避免"迁完才发现账单翻倍"
验收标准：业务无感，监控无新增告警级别，账单在预算区间内。
阶段四：运营（长期）
这是最容易被跳过、也最影响长期成本的阶段。
| 指标 | 目标量级 | 采集方式 |
|---|---|---|
| 可用性 | 99.9%（年停机 ≈ 8.8 小时） | 拨测 + 业务日志 |
| MTTR | < 30 分钟 | 告警到恢复的时间戳 |
| 资源利用率 | CPU 均值 20%–60% | 云监控 30 天均值 |
| 单位成本 | 每万次请求成本，逐月对比 | 账单 + 业务指标 |
| 闲置资源占比 | < 10% | 未挂载云盘、无流量 EIP |
利用率长期低于 10% 的机器应考虑降配或合并；长期高于 80% 则要评估扩容弹性。
成本控制的三个有效手段
- 包年包月 vs 按量：稳态负载用包年包月，通常比按量便宜 40%–60%；波动负载用按量或抢占式
- 存储分层：冷数据转低频/归档存储，单 GB 成本可降到标准存储的 1/3 以下
- 清理长尾：未挂载云盘、闲置 EIP、过期快照，通常是账单里最容易忽略的 5%–10%
什么时候不适合上这套流程
10 人以下的团队、单一业务、无合规要求时，评估和设计阶段可以压缩到一周：选好机型、做好备份、配好监控即可上线。流程的价值在于规模，规模不到时流程本身就是成本。
