云成本管理 FinOps 与云迁移

• 账号组织（多账号/OU/SCP）
• VPC 规划（CIDR、子网、多 AZ）
• 安全组与本地防火墙差异

云上目标架构设计与本地差异主要在"资源隔离、网络、安全模型"三方面。账号组织：用多账号/OU/SCP 把不同环境、业务、安全边界隔离（如 AWS Organizations、Azure 管理组、GCP 组织），与本地"一台机器跑多环境"不同，云上用账号做资源与权限边界。VPC 规划：设计 CIDR 分配（避免重叠、预留扩展）、子网划分（公网/私网、多 AZ 高可用）、路由与 NAT/网关，规划跨环境/跨账号网络（VPC Peering/Transit Gateway）。安全组：云上安全组是"有状态、按网段/资源粒度的虚拟防火墙"，与本地边界防火墙不同，需按"资源"而非"物理位置"设计规则（最小开放、按服务分组），配合 NACL 做无状态层。差异应对：云上把"网络边界"转化为"账号/安全组/网络策略"，把"物理隔离"转化为"逻辑隔离"，需重新设计安全模型与网络拓扑，而非直接平移本地架构。落地：先规划账号与 VPC 蓝图，再设计安全组与网络策略，最后用 IaC 落地。

云上架构的核心是"用逻辑隔离替代物理隔离"。账号分边界、VPC 分网络、安全组分服务，三者配合实现不同于本地的安全与网络模型。迁移时避免"照搬本地拓扑"，要按云范式重新设计。

• rightsizing 的流程与数据采集
• 基于监控数据的规格建议
• 实施风险与回滚

rightsizing（正确规格调整）是识别并调整"超配/欠配"的实例规格以降低成本。流程：采集监控数据（CloudWatch 的 CPU/内存/网络/IO 指标，AWS 的 Compute Optimizer、Azure 的 Advisor、GCP 的 Recommender）→ 分析实例利用率（CPU 使用率、峰值、时长）→ 识别超配实例（长期低利用率）→ 建议降配规格 → 实施 → 验证。实施建议：基于长时间（如 14-30 天）的利用率与峰值趋势，而非单次采样；考虑工作负载特性（CPU 密集/内存密集/突发）。实施风险：降配可能导致性能不足（如 CPU 峰值时受限）、内存不足、IO 下降，影响业务；对无状态/可重启应用可直接调整，对数据库/有状态应用需谨慎评估停机与性能影响。风险管理：先在小流量/低峰窗口调整，监控调整后性能与告警，设置回滚（规格可快速调回），记录变更。落地：把 rightsizing 做成"监控→建议→审批→实施→验证"的闭环，配合 Savings Plan/预留实例进一步降本。

rightsizing 的核心是"用数据说话、谨慎实施"。先采数据识别超配，再按工作负载特性建议，最后小规模试点 + 监控 + 回滚。风险在于"降配导致性能退化"，所以要有验证与回退机制。

• 共享成本（网络、监控、安全）的识别
• 分摊方法（按使用量/按收入/按人头/按固定）
• 各方法适用场景

共享成本（网络带宽、监控平台、安全工具、公共资源）无法直接归属到某个业务，需用分摊方法分配到各成本中心。分摊方法：按使用量分摊（按各业务的实际用量，如流量、存储、调用量，按比例分摊）——适合用量可度量、与业务相关的共享资源（如网络流量、对象存储）；按收入分摊（按各业务收入占比分摊）——适合收益导向、难以用技术用量衡量的共享成本；按人头分摊（按各团队人数/工作量占比）——适合工具类、人力相关的共享成本（如监控平台、安全工具）；按固定比例/固定分配——简单但不够精确。适用场景：以"公平、可解释、可激励"为原则。按使用量最公平但需数据，按收入适合业务导向，按人头适合团队工具。落地：先识别共享成本项，再按"哪种分摊最贴近真因"选择方法，定期复查调整，避免分摊失真。

共享成本分摊的核心是"公平与可解释"。"按使用量"最贴近实际但需用量数据，"按收入/按人头"更简单但可能失真。选择取决于成本性质与可用数据，目标是被分摊团队认可、可驱动优化。

• 迁移前性能基线采集
• 迁移后性能对比
• DNS 切换的注意点与回退

迁移后性能基线对比与 DNS 切换是迁移验证的关键。性能基线：迁移前在源环境采集性能基线（响应时间、延迟、吞吐、CPU/内存/IO 使用率、错误率），作为对比基准；迁移后在目标环境用同样负载/工具采集，对比是否达标。对比注意点：控制变量（同样的请求量、并发、场景），考虑云上资源规格差异（如 IOPS、网络带宽），对比延迟（P50/P95/P99）、吞吐、资源利用率。DNS 切换注意点：切换前确认目标环境就绪（性能达标、数据就绪、监控就绪）；用低 TTL 或灰度切换（先切部分流量/区域）验证再全量；切换后监控 DNS 解析、错误率、延迟；保留回退能力（DNS 切回源环境）。切换时机选低峰期，避免切换与业务高峰冲突。落地：先基线→再切换→后对比，配合监控与回退，确保迁移后性能不劣化。

性能对比的核心是"同基线、同负载、可控变量"。DNS 切换是"最后一步"，要点是"先就绪、再灰度、后全量、留回退"。迁移后性能不劣化是验收底线，需用数据证明。

• 功能验收项
• 性能验收项
• 安全验收项

迁移验收从功能、性能、安全三维度建立 Checklist。功能验收：核心业务流程可用（注册/登录/下单/查询等）、接口返回正确、数据完整一致（记录数、字段、最近数据）、依赖（数据库/缓存/消息）连通、第三方集成正常、异常/边界场景（超时、重试、并发）符合预期。性能验收：响应时间（P50/P95/P99）达标、吞吐能力达标、峰值负载下资源利用率合理、与迁移前基线对比无劣化、扩展性（水平扩容）正常。安全验收：网络与安全组配置正确（最小开放）、证书与 HTTPS 正常、加密（数据加密、传输加密）符合要求、访问控制与权限（IAM/RBAC）正确、审计日志开启、密钥与敏感信息管理正确、无明文密钥泄露。落地：把 Checklist 固化为验收文档/脚本，按三维度逐项验证并记录结果，作为迁移"放行"凭证；对未通过项制定修复与复验。

验收的核心是"全面且可验证"。功能管"能不能用"，性能管"够不够快"，安全管"安不安全"。三方面缺一不可，用 Checklist 保证迁移可被正式确认，避免"迁移完才发现问题"。

• 闲置资源识别（自动化扫描）
• owner 确认与审批
• 回收流程与安全

闲置/未挂载资源（孤儿 EBS 卷、未绑定弹性 IP、废弃快照、未使用实例）是云成本浪费的主要来源。识别：用自动化扫描（AWS 的 EC2 未挂载卷、未绑定 EIP、旧快照；CloudHealth/云监控扫描；标签与使用率分析）定期发现闲置资源，结合使用率（长时间无活动）判定。owner 确认：扫描结果需归属到 owner（通过标签/资源清单），向 owner 确认该资源是否真的不再需要（避免误删数据），确认后进入回收。回收流程：先"标记待回收"→ owner 确认 → 备份（如需）→ 删除/释放 → 验证。对 EBS 快照可先"归档/降级"再删，对弹性 IP 先看是否绑定。安全与治理：设置回收窗口（如确认后 7 天），重大资源（数据卷）需额外确认与备份，回收记录留痕，配合定期扫描（如每周）与成本报告。落地：自动化扫描 + owner 确认 + 分级回收 + 留痕报销，形成"发现→确认→回收→验证"闭环。

闲置资源回收的核心是"识别准、确认慎、回收稳"。自动化扫描保证发现，owner 确认避免误删数据，回收流程（备份+窗口+留痕）保证安全。这能直接降低云成本且风险低。

• 各云 Budgets 的告警规则
• 异常支出突增检测
• 与监控/通知的集成

预算告警与异常支出检测是 FinOps 的实时防线。AWS Budgets：可设置成本预算/使用量预算，按月/季/年，设定阈值（如 80%/100%）触发告警，可依据标签/服务/成员账号分组，支持 SNS 通知、与 EventBridge 集成触发自动化；AWS 还提供 Cost Anomaly Detection（AI 异常检测）识别突增。Azure Budgets：在 Cost Management 中设置预算，按阈值告警，支持 Action Group 通知与自动化（触发成本优化动作）。GCP Budgets：在 Billing 中设置预算，按阈值（如 90%/100%）发送通知到 Pub/Sub/email，可配合 Cloud Monitoring 告警。异常突增检测：用各云的异常检测（AWS Cost Anomaly、Azure Anomaly Detection、GCP 的预算+异常）或统一 FinOps 平台，识别异常支出（如某服务突然暴涨、某标签突增）。集成：预算告警接入通知（邮件/Slack/工单）、自动化（熔断/降级/告警）、与统一成本平台联动。落地：设月度预算 + 分层阈值告警 + 异常检测 + 通知/自动化集成。

预算告警的核心是"阈值 + 通知 + 异常检测"。分层阈值（渐进告警）避免"要么不报要么太晚"，异常检测弥补"固定预算无法发现突增"。与通知/自动化集成，让告警能推动动作。

• 成本可见性仪表盘
• 成本优化 OKR
• 工程师成本意识培训

FinOps 的有效性依赖财务/成本团队与工程团队的协作。成本可见性仪表盘：建立统一成本仪表盘（按团队/服务/环境展示成本、趋势、优化建议），让工程师能看到"自己的变更带来的成本"，把成本可视化到工程日常。成本优化 OKR：把成本优化纳入工程团队目标（如降低某服务成本 X%、提升资源利用率、减少闲置资源），与业务/性能目标平衡，避免"只优化成本牺牲质量"。成本意识培训：对工程师做 FinOps 培训（成本模型、rightsizing、标签规范、预算告警），让工程师在设计与开发时具备成本意识（如选合适规格、用 spot/预留、写标签）。协作模式：FinOps 团队提供"平台与数据"（仪表盘、预算、建议），工程团队负责"行动与决策"（优化资源配置、架构调整），用定期复盘（月度成本回顾）对齐。落地：可观测仪表盘 → 成本 OKR → 培训与文化 → 定期复盘。

FinOps 协作的本质是"让成本责任回到工程"。成本可见性让工程师"看得见"，OKR 让"有目标"，培训让"有意识"，复盘让"有闭环"。FinOps 团队是"赋能者"，工程团队是"执行者"。

• Savings Plans 与 Reserved Instances 的比较
• 灵活性与折扣深度权衡
• Compute SP 与 EC2 RI/Standard RI 的适用场景

Savings Plans（SP）与 Reserved Instances（RI）都是"承诺用量换折扣"的云成本优化手段。折扣深度：RI 通常折扣更深（尤其 EC2 专用 RI），SP 折扣次之；Savings Plans 分 Compute SP（覆盖 EC2 计算，含 Fargate/Lambda 等）、EC2 Instance SP（针对特定实例族）、SageMaker SP。灵活性：SP 的 Compute SP 最灵活（不绑定具体实例类型/区域，可覆盖多种计算服务），EC2 Instance SP 次之（绑定实例族），RI 最不灵活（需绑定实例类型/区域、或 Convertible 型可换）。适用场景：CI 稳定、可预测、长期运行的工作负载用 RI 或 EC2 Instance SP 获取更深度折扣；工作负载多样、类型多变、含 Fargate/Lambda/容器用 Compute SP 更灵活；测试/开发等波动负载不宜承诺（用 On-Demand/Spot）。取舍：稳定负载用折扣深的 RI/SP，弹性负载用灵活的 Compute SP 或 On-Demand，结合 spot 覆盖可中断负载。落地：优先用 Compute SP 覆盖基本盘（灵活统一），对稳定特定实例用 RI 补深度，预留/spot 做弹性。

SP vs RI 的取舍是"折扣深度 vs 灵活性"。稳定负载值得用 RI 换深度折扣，多变/容器负载用 Compute SP 保灵活。没有绝对最优，需按负载特征组合。

• 标签策略与治理流程
• 未标记资源处理
• 标签与成本中心映射

基于标签的成本分摊是 FinOps 的核心。标签治理流程：定义统一标签规范（成本中心、环境、部门、项目等），用强制/审计策略（AWS Config、Azure Policy、GCP 标签策略）保证资源打标签，把标签规范代码化并纳入 IaC。未标记资源处理：对未打标签的资源，用统一"公共/未归属"桶或按 owner 推断、自动补标（按资源命名/账户/创建者），或要求 owner 认领，避免成本"漏分摊"；治理上设定"未标记资源占比"指标并持续降低。标签与成本中心映射：建立"标签值 → 成本中心"的映射表（如 CostCenter 标签映射到财务成本中心），在成本管理工具（AWS Cost Explorer、Azure Cost Management、GCP Billing）按标签分组做成本分摊与预算，把共享成本也按标签分摊。落地：标签规范 → 强制治理 → 未标记处理 → 成本中心映射 → 分摊与报表。用标签覆盖率与分摊准确率度量治理效果。

标签分摊的关键是"规范 + 治理 + 映射"。标签规范是语言，强制治理保证覆盖率，未标记处理避免漏摊，成本中心映射让成本可归属。三者闭环才能让成本分摊准确、可信任。

• FOCUS 规范
• 各云账单数据源（AWS CUR、Azure、GCP）
• 数据格式统一与聚合

多云成本统一度量的难点是各云账单格式不同，FOCUS（FinOps Open Cost & Usage Specification）是统一成本数据的开放规范。实施：先从各云导出标准化账单数据——AWS 用 Cost and Usage Report（CUR，含完整用量/成本/标签）、Azure 用 Cost Management Exports（到 Storage/ADLS）、GCP 用 BigQuery Billing Export（表格式）。再用 FOCUS 规范把各云数据映射/转换到统一字段（如 billing period、service、resource、cost、usage、tags、currency），生成统一的成本数据模型（FOCUS 数据集）。然后聚合到统一平台（数据湖/BI/FinOps 工具）做跨云展示、分摊、预算与优化。关键：字段映射（各云服务名、资源名、单位、标签对齐）、维度统一（时间、组织、服务分类）、成本/用量归一。落地：各云导出 → FOCUS 转换 → 统一数据湖 → 统一报表/分摊/优化。

FOCUS 的核心是"把各云账单翻译成统一语言"。它解决字段不一致、单位不一致、维度不一致的问题，让跨云成本可比较、可聚合、可分摊。实施重点是数据导出与字段映射的自动化。

• 迁移工具（agent 批量迁移：AWS SMS/Application Migration、Azure Site Recovery、云迁移工具）
• 批量编排与批次
• 验收标准

大规模主机迁移（成千上万台）需用 agent 批量迁移工具并做好编排与验收。工具：AWS Application Migration Service（MGN）、Azure Site Recovery（ASR）、阿里云 SMC、腾讯云在线迁移等，通过安装 agent 复制主机数据到目标云，支持增量同步与切换。编排：分批迁移（按应用/团队/环境分批次），每批设迁移窗口，先铺 Pilot（小批量验证）再放量；用 runbook/自动化编排各批次（复制、同步、切换、验证）；监控复制进度与数据同步。验收：每台主机验收"系统可用（可启动、服务正常）、数据一致（应用数据完整）、网络连通（DNS/端口/安全组）、性能达标（与源对比）、配置正确（规格/磁盘/密钥）"；对批量结果用清单/仪表盘追踪通过率，未通过项修复后复验。落地：工具 + 分批 + 自动化编排 + 逐批验收 + 全量通过才正式切换。

大规模迁移的核心是"分批、自动化、可验收"。agent 工具解决复制，分批控制风险，runbook 编排保证一致，验收标准保证质量。避免"一次性全量迁移"导致故障扩散。

• 迁移方式（DMS/双写/CDC）
• 一致性验证方法
• 割接与验证

数据库迁移常用 DMS（AWS Data Migration Service）、双写、CDC（Change Data Capture）方式，一致性验证是迁移成败的关键。迁移方式：DMS 全量 + 增量复制，双写（应用同时写源与目标），CDC（如 Debezium）持续捕获变更。一致性验证：全量阶段用记录数对比、字段校验（checksum/哈希）、抽样对账；增量阶段监控复制延迟与错误率，用"复制滞后"（lag）评估；切换前做"最终一致性"验证（停止写入后，源与目标数据完全一致）。验证方法：用对比工具（如 AWS DMS 的 Data Validation、pt-table-checksum、自建对账脚本）按表/主键校验记录数、聚合、校验和；验证关键业务表（订单、交易）与关联数据。割接：验证一致后，短暂停写/切换，切换后继续验证（应用读写、数据正确、无丢失）。落地：全量对账 → 增量监控 → 停写终验 → 切换 → 切换后验证。

数据一致性验证的核心是"多阶段对账 + 增量监控 + 终验"。全量查遗漏，增量查滞后，停写终验保证切换瞬间一致，切换后验证保证无丢失。数据库迁移对一致性要求极高，必须严谨。

• 依赖梳理（应用/服务/数据/第三方）
• 网络打通方案
• 依赖与网络对迁移的影响

迁移前的基础设施依赖梳理与网络打通是迁移成功的先决条件。依赖梳理：摸清应用对外的依赖（数据库、缓存、消息、对象存储、第三方 API、DNS、证书）、对内依赖（服务间调用、共享服务）、基础设施依赖（网络、负载均衡、监控、日志），形成依赖图谱（哪些服务依赖哪些资源），避免"迁移了 A 但 B 还在源云导致 A 不可用"。网络打通方案：迁移期间需源云与目标云网络互通，用专线/VPN/云互联打通，保证跨云调用（DNS、端口、安全组）正常；规划目标云 VPC 与源网络连通、内网 DNS 解析、负载均衡与流量路径。设计：先把依赖图谱化，确定"迁移顺序"（先无依赖/无状态的，后核心/有依赖的），再打通网络，保证迁移后应用依赖可用。可考虑混合过渡期（部分在源、部分在目标）的跨云通信。落地：依赖梳理 → 网络打通 → 迁移顺序规划 → 过渡期验证。

迁移的核心是"先理清依赖，再打通网络，最后按依赖顺序迁移"。依赖图谱决定迁移顺序，网络打通保证过渡期与迁移后可用。跳过依赖梳理常导致"迁移后应用不可用"。

• 割接窗口规划
• 回退方案设计
• 回退触发与验证

迁移割接窗口与回退方案是迁移风险控制的关键。割接窗口规划：选择影响最小的窗口（低峰期、业务淡季），评估割接所需时间（数据终验、切换、验证），预留足够缓冲；与业务/运维/变更管理（CAB）对齐，明确窗口起止。回退方案设计：在割接前设计"如果失败如何回退"——回退到源环境或保留源环境可用；回退内容：数据（保留源数据/回滚点）、流量（DNS/负载均衡切回源）、配置（保留源配置）。回退触发条件：明确"什么情况触发回退"（如切换后核心功能不可用、性能严重劣化、数据不一致、超时未通过验证）。回退验证：割接前演练回退流程，确认回退后业务可用；回退后验证数据与功能。落地：窗口规划 + 明确回退条件 + 回退演练 + 回退后验证，并把"回退成功率"作为割接硬指标。

回退方案的核心是"留后路、明条件、有演练"。割接窗口选低峰期，回退方案保证"失败可回"，回退条件明确"何时回"，演练保证"回得动"。回退能力是迁移的安全网。

• 6R 策略（Rehost/Replatform/Refactor/Repurchase/Retire/Retain）
• 迁移评估维度
• 按场景选择策略

6R 是云迁移的六种策略：Rehost（直接迁移，lift-and-shift，最快、改动最小）、Replatform（优化再迁，如改托管数据库、改配置，改动小收益中）、Refactor（重构改造，Rewrite 为云原生，改动大收益大）、Repurchase（替换为 SaaS/托管产品）、Retire（下线废弃）、Retain（保留不动，暂不迁移）。迁移评估维度：业务价值（对业务重要度）、技术复杂度（依赖、定制化、耦合）、成本收益（迁移成本 vs 云收益）、合规/数据（数据主权、合规要求）、风险（停机、数据安全）。选择逻辑：对"低价值高复杂度"Retain，对"无价值"Retire，对"可快速迁"Rehost，对"需优化"Replatform，对"需云原生红利"Refactor，对"有现成 SaaS"Repurchase。落地：先做评估（盘点 VM/应用/依赖），按 6R 分类，制定每类迁移策略与优先级，结合成本与风险推进。

6R 的核心是"按应用特征选策略，而非一刀切"。Rehost 快但云端红利少，Refactor 慢但收益大，Replatform 居中。评估看"价值、复杂度、成本、风险"，策略选择要匹配业务与技术现实。

• 双活窗口期的数据路径
• 写冲突控制（单写/双写/顺序）
• 一致性保证

迁移双活窗口期（新旧系统并行运行）的控制写冲突是关键。写冲突来源：新旧系统同时接收写请求，若数据写到不同地方会导致数据不一致。控制策略：其一，单写（single-write）：在双活期只让一个系统（新或旧）接受写，另一个只读，避免双写冲突，最安全；其二，顺序切换（cutover in phases）：先切读、再切写，切换点明确，避免并发写；其三，双写（dual-write）加协调：同时在两系统写，但要处理顺序、失败、幂等与补偿，复杂度高，需配比较验证；其四，加锁/互斥：写操作串行化，避免并发冲突。一致性保证：双写/并行需用唯一标识（幂等键）、顺序控制、冲突解决策略（如时间戳/版本），并用对账校验。落地：优先单写 + 顺序切换，实现简单可靠；确需双写时做幂等、顺序与补偿处理，并频繁对账。目标是在并行期"数据一致、可回退"。

双活写冲突的核心是"避免并发写同一数据"。单写 + 顺序切换最可靠，双写需幂等与补偿。迁移期控制写冲突，能保证"并行期数据一致、可平滑切换或回退"。

• 基于历史使用量的采购决策
• 覆盖率与利用率指标
• 期限与付款选项

预留实例（RI）/Savings Plan（SP）的采购与覆盖率策略是成本优化的重要部分。采购决策：基于历史使用量（如 30-90 天的稳定用量）分析，识别"长期稳定、可预测"的工作负载，据此采购 RI/SP；避免为波动、测试负载采购（浪费承诺）。覆盖率与利用率指标：覆盖率（covered，被 RI/SP 覆盖的用量占比）衡量"够不够"；利用率（utilization，实际使用/承诺量）衡量"准不准"（购买过多导致利用率低、浪费）。目标是在覆盖率与利用率间取平衡（如覆盖率 70-90%、利用率 80-90%）。期限与付款选项：期限（1 年/3 年）越长折扣越深，但锁定越久；付款方式（全预付/部分预付/无预付）预付越多折扣越深，但现金占用高。策略：用稳定负载锁定 3 年/全预付换深折扣，一般负载用 1 年/部分预付，波动负载用 On-Demand/Spot；定期复盘覆盖率与利用率，调整采购。落地：历史用量分析 → 按负载稳定性选 RI/SP 与期限付款 → 监控覆盖率/利用率 → 定期调整。

RI/SP 策略的核心是"用稳定负载换折扣、用指标防浪费"。采购看历史稳定用量，覆盖率与利用率是平衡点（覆盖不足浪费折扣、利用率低浪费承诺），期限与付款是"折扣 vs 锁定/现金"的权衡。需定期复盘。

• 迁移项目角色分工
• CAB 协作与变更审批
• 沟通与风险控制

云迁移项目需要清晰的角色分工与 CAB 协作。角色分工：迁移负责人（项目经理，统筹进度与资源）、架构师（迁移方案与 6R 策略）、运维/平台团队（基础设施、网络、监控）、应用团队（应用迁移与验证）、安全团队（合规与安全）、数据/数据库团队（数据迁移）、财务/FinOps（成本与预算）、变更管理（CAB）。CAB 协作：迁移涉及生产变更，需通过变更管理委员会（CAB）审批——割接窗口、回退方案、变更风险评估在 CAB 评审；CAB 负责审批变更、协调资源、评估影响，迁移团队准备变更请求（Change Request）并提交 CAB。沟通与风险控制：迁移前对齐里程碑与风险，割接前与 CAB/业务确认窗口，割接中协调，割接后向 CAB 汇报结果与回退状态。落地：明确角色与职责（RACI），所有生产变更走 CAB 审批，定期同步进度与风险，确保"变更合规、责任清晰、风险可控"。

迁移项目的核心是"角色清晰 + 变更受控"。RACI 明确谁负责，CAB 审批保证生产变更合规与风险可控，沟通机制保证对齐。

• 退网条件与验证
• 资产处置流程
• 数据保留与合规

迁移后本地基础设施的退网与资产处置要谨慎，避免"过早退网导致回退困难"或"数据未保留导致合规风险"。退网条件：确认所有业务已稳定运行在云上、无依赖本地资源、通过回退窗口期（如 30-90 天观察期）、无残留流量/任务。资产处置流程：先盘点（本地服务器/存储/网络/负载均衡/防火墙），再按重要性分级处理——保留（作为回退/归档）、停用（置于维护/下线）、淘汰（物理回收）；处置前备份关键数据与配置（防回退或合规）。数据保留与合规：按合规要求保留审计/日志/财务数据（保留期），删除前确认数据已迁移或归档，遵循数据删除/销毁流程（如介质消磁、合规删档）。落地：退网验证（观察期）→ 资产盘点 → 分级处置（保留/停用/淘汰）→ 数据备份与合规保留 → 物理回收 → 记录留痕。整个过程留档以便审计与追溯。

退网的核心是"确认安全后再退、留足回退缓冲、合规处理数据"。过早退网会失去回退能力，数据保留不清会违规。退网应分级、留痕、合规，而非一删了之。

• 回退演练
• 回退时间窗口评估
• 回退触发与验证

迁移失败的回退演练与回退时间窗口评估是迁移风险控制的关键。回退演练：在割接前实际演练"从目标/云回退到源环境"的流程，验证回退步骤可用、数据可恢复、业务可回（回退到源环境仍可用），把演练结果作为回退预案的验证。回退时间窗口评估：评估回退所需时间（数据回滚、DNS 切回、配置恢复、验证），与可用回退窗口（业务允许的停机时间）对比，确保回退能在窗口内完成；若回退时间超窗口，需优化回退流程或调整割接策略。回退触发与验证：明确回退触发条件（如核心功能不可用、数据不一致、性能严重劣化、超时），回退后验证业务功能与数据完整。落地：割接前回退演练 → 评估回退时间/窗口 → 明确触发条件 → 回退后验证，把"回退时间 <= 可用窗口"作为硬指标。

回退的核心是"能回、回得快、回得准"。演练验证"能回"，时间窗口评估保证"回得及"，触发条件保证"该回就回"，验证保证"回得对"。回退能力是迁移的保险。

• 许可证合规（软件许可）
• BYOL（Bring Your Own License）策略
• 云上许可与合规风险

迁移过程的许可证合规与 BYOL 是云迁移的合规要点。许可证合规：迁移涉及软件（OS、数据库、中间件、应用）的许可，需确认许可协议是否允许迁移到云、是否支持虚拟化/云环境（如微软、Oracle 的许可在云上的特殊条款），避免"未授权使用"导致的合规风险。BYOL 策略：BYOL（带自有许可）指把已有许可证带到云上使用（如 AWS 的 BYOL 选项、Azure 的 SUSE/RHEL BYOL、Oracle BYOL），可节省许可成本；需确认云厂商是否支持 BYOL、许可迁移规则（如许可是否可随实例迁移、是否锁定）。云上许可方式：云厂商提供"含许可的镜像"（许可费计入云账单）或 BYOL（用自有许可，云费不含许可）。风险控制：盘点已有许可与覆盖面，评估"云付费许可 vs BYOL"的成本与合规，确认许可协议对多租户/云环境/虚拟化的允许范围，避免许可超量或协议违规。落地：许可盘点 → 评估 BYOL 可行性与成本 → 确认合规条款 → 按策略选择云镜像或 BYOL → 审计留痕。

许可合规的核心是"确认许可协议在云上是否合规、是否可 BYOL"。BYOL 能省成本但需确认厂商支持与迁移规则；云付费许可省心但成本高。合规审计（许可覆盖、超量）是底线。