2. 迁移前评估：应用画像与依赖分析、迁移可行性评估与ROI估算
说实话，我见过太多团队一上来就喊“上云”，结果迁移到一半发现应用根本跑不起来。为什么？因为没做迁移前评估。这就像你搬家前不量家具尺寸、不画新家布局图，搬过去才发现沙发进不了门。
所以，这一章我们聊聊迁移前必须做的三件事：应用画像与依赖分析、迁移可行性评估（12-Factor App检查清单）、迁移成本与ROI估算。这三步走扎实了，后面的迁移才能心里有底。
2.1 应用画像：搞清楚你的应用到底是什么
应用画像，说白了就是给你的应用做一次“体检”。你得知道它用了什么技术栈、依赖哪些外部服务、数据怎么存、流量模式什么样。我在项目中遇到过好几次，团队说“这个应用很简单”，结果一分析发现它依赖了一个已经停止维护的旧版数据库，迁移时差点翻车。
我个人习惯从以下几个维度做画像：
- 技术栈：编程语言、框架版本、运行时环境（JVM、Node.js、Python等）
- 依赖关系：数据库、消息队列、缓存、第三方API、内部微服务
- 数据存储：数据库类型、数据量、存储格式、备份策略
- 网络拓扑：端口、协议、防火墙规则、DNS解析
- 流量特征：峰值QPS、请求模式（同步/异步）、读写比例
- 配置管理：环境变量、配置文件、密钥管理方式
重要提醒：应用画像不是一次性的工作。随着迁移推进，你可能会发现新的依赖或隐藏的配置。我建议用自动化工具（比如VMware的Application Discovery或开源项目NetBox）持续扫描，别全靠人工翻代码。
2.2 依赖分析：别让“隐形依赖”坑了你
依赖分析是应用画像的延伸，但值得单独拿出来说。为什么？因为很多依赖是“隐形”的——比如某个应用在代码里硬编码了IP地址，或者依赖了一个只在特定机房才能访问的内部服务。
我曾经接手过一个迁移项目，应用看起来很简单，就是一个Java Web应用。结果迁移到云上后，发现它每隔5分钟会去访问一个内网NFS共享目录，而这个目录在云上根本不存在。嗯，这就是典型的“隐形依赖”。
依赖分析我一般分三步走：
- 静态分析：扫描代码中的import、require、依赖配置文件（pom.xml、package.json、requirements.txt等）
- 动态分析：在测试环境运行应用，抓取网络流量、系统调用、文件访问记录
- 人工访谈：找开发团队聊，问他们“这个应用还依赖什么你们觉得理所当然的东西？”
小技巧：用strace（Linux）或Process Monitor（Windows）抓一下应用启动时的系统调用，你会发现很多意想不到的依赖。比如某个应用启动时会去读/etc/hosts里的一个域名映射，而这个映射在云上可能不存在。
2.3 迁移可行性评估：12-Factor App检查清单
12-Factor App是Heroku提出的云原生应用开发方法论。说白了，它就是一套“上云最佳实践”的检查清单。你的应用符合的因子越多，迁移就越顺利。
我个人习惯用这个清单做快速评估，每个因子打一个分（0-5分），总分低于40分的应用，我建议先做重构再迁移。
| 因子 | 检查项 | 常见问题 |
|---|---|---|
| 1. 基准代码 | 是否使用版本控制？一份代码对应多个部署？ | 代码散落在多个仓库，没有统一管理 |
| 2. 依赖 | 是否显式声明依赖？是否依赖系统级工具？ | 依赖了curl、wget等系统命令，迁移后找不到 |
| 3. 配置 | 配置是否从代码中分离？是否使用环境变量？ | 配置硬编码在代码里，或者写在config文件中 |
| 4. 后端服务 | 数据库、消息队列等是否作为可附加资源？ | 数据库连接字符串写死在代码里 |
| 5. 构建、发布、运行 | 构建和运行是否严格分离？ | 直接在服务器上修改代码，没有构建流程 |
| 6. 进程 | 应用是否无状态？是否支持水平扩展？ | Session存在本地内存里，一扩容就丢 |
| 7. 端口绑定 | 应用是否通过端口提供服务？不依赖外部Web服务器？ | 依赖Apache或Nginx做反向代理 |
| 8. 并发 | 是否通过进程模型实现并发？ | 单进程处理所有请求，无法利用多核 |
| 9. 易处理 | 应用能否快速启动和优雅关闭？ | 启动需要5分钟，关闭时丢数据 |
| 10. 开发/生产环境一致性 | 开发环境和生产环境是否尽可能一致？ | 开发用Windows，生产用Linux |
| 11. 日志 | 是否将日志视为事件流？不写本地文件？ | 日志写到本地磁盘，没有集中收集 |
| 12. 管理进程 | 数据库迁移、批处理等是否作为一次性进程运行？ | 管理任务和主应用混在一起 |
避坑指南：我曾经评估过一个应用，12个因子只符合了3个。团队想直接迁移，我坚持先做重构。结果重构花了2个月，但迁移只用了1周。如果直接迁移，估计要折腾半年。所以，别怕重构，怕的是不重构就硬上。
2.4 迁移成本与ROI估算
迁移成本不只是云服务商的账单。你想想看，还有人力成本、停机损失、数据迁移费用、培训成本等等。ROI估算的核心是回答一个问题：迁移后能省多少钱？或者能多赚多少钱？
我一般把成本分成三类：
- 一次性成本：迁移工具、数据迁移、应用改造、测试验证、人员培训
- 持续性成本：云资源费用、运维人力、监控工具、网络带宽
- 隐性成本：迁移期间的业务中断、学习曲线、可能的性能下降
ROI估算公式其实很简单：
ROI = (迁移后年度收益 - 迁移后年度成本 - 一次性迁移成本) / 一次性迁移成本 × 100%举个例子：
- 一次性迁移成本：50万元（工具+人力+停机损失）
- 迁移后年度成本：30万元（云资源+运维）
- 迁移前年度成本：60万元（机房+硬件+运维）
- 迁移后年度收益：30万元（节省的成本）
那么ROI = (30 - 30 - 50) / 50 × 100% = -100%。第一年其实是亏的。但从第二年开始，每年净赚30万。所以，ROI要看3-5年的周期。
我的经验：别只看数字。有些迁移的ROI是“隐性”的——比如弹性伸缩能力、故障恢复速度、开发效率提升。这些很难量化，但长期来看价值更大。我建议做两个版本的ROI：一个保守版（只算直接成本），一个乐观版（算上隐性收益）。
2.5 小结：评估做得好，迁移没烦恼
迁移前评估，说白了就是“先想清楚再动手”。应用画像帮你了解现状，依赖分析帮你发现隐患，12-Factor检查清单帮你评估可行性，ROI估算帮你算清楚账。
我个人习惯把这四步做成一个Checklist，每次迁移前逐项打勾。别嫌麻烦，这一步省下的时间，后面十倍百倍地还给你。
下一章，我们会聊聊具体的迁移策略——是“大爆炸”式迁移，还是“绞杀者”模式？到时候见。