第3章现状评估与调研

3、现状评估与调研：如何盘点现有IT资产，应用依赖关系梳理，性能基线采集

说实话，很多金融机构的上云项目，第一步就栽了跟头。

为什么？因为连自己家里到底有多少“家当”都没搞清楚，就急着往云上搬。我见过一个案例，某券商号称“全量盘点”，结果迁移到一半，发现核心交易系统还连着三台早已报废的数据库服务器——这种坑，踩一次就够你喝一壶的。

所以，现状评估与调研，说白了就是给现有IT系统做一次“全身体检”。你得知道：

有多少台服务器、虚拟机、容器？
它们之间怎么通信的？谁依赖谁？
现在的性能水平怎么样？CPU、内存、IOPS、网络延迟，到底是多少？

嗯，这三件事，一件都不能少。下面我一个个拆开讲。

3.1 盘点现有IT资产：别只数服务器

很多人一听到“资产盘点”，第一反应就是“数服务器”。但在我个人习惯里，资产盘点至少分三层：

物理层：服务器型号、CPU核数、内存大小、磁盘类型（SSD/HDD）、网卡速率。
虚拟化层：VMware/OpenStack/KVM版本、虚拟机规格、宿主机资源分配比例。
应用层：中间件（WebLogic、Tomcat、Nginx）、数据库（Oracle、MySQL、Redis）、消息队列（Kafka、RabbitMQ）。

我建议你用一个统一的CMDB（配置管理数据库）来收拢数据。如果没有现成的，那就写个脚本批量采集。下面是我常用的一个采集脚本片段（Python）：

import subprocess
import json

def collect_server_info():
    result = {}
    # 获取CPU信息
    cpu_info = subprocess.check_output("lscpu | grep 'Model name' | awk -F: '{print $2}'", shell=True).strip()
    result['cpu_model'] = cpu_info.decode()
    # 获取内存总量
    mem_info = subprocess.check_output("free -h | grep Mem | awk '{print $2}'", shell=True).strip()
    result['memory'] = mem_info.decode()
    # 获取磁盘信息
    disk_info = subprocess.check_output("lsblk -o NAME,SIZE,TYPE,MOUNTPOINT | grep -v loop", shell=True).decode()
    result['disk'] = disk_info
    return result

if __name__ == '__main__':
    data = collect_server_info()
    print(json.dumps(data, indent=2))

这个脚本很简单，但够用。你可以在每台服务器上跑一遍，把结果汇总到一个CSV文件里。注意，一定要加上时间戳，因为资产状态是动态的。

我的经验： 我曾经帮一家银行做盘点，发现他们有一台“幽灵服务器”——在CMDB里显示已报废，但实际上还在跑着核心业务。这种问题，只有通过逐台登录确认才能发现。别偷懒，该ssh就ssh。

3.2 应用依赖关系梳理：画图比写代码更重要

资产盘点是“点”，依赖关系是“线”。没有线，点就是散的。

应用依赖关系，说白了就是回答三个问题：

这个应用调用了哪些下游服务？
它被哪些上游应用调用？
它依赖哪些数据库、缓存、消息队列？

我常用的方法有两种：

静态分析：读配置文件。比如Spring Boot的application.yml、Nginx的upstream配置、Dubbo的注册中心列表。这些文件里明明白白写着依赖关系。
动态采集：用网络流量分析工具。比如tcpdump抓包，或者用SkyWalking、Pinpoint这类APM工具自动生成调用链。

我个人更推荐动态采集，因为静态配置可能过时。你想想看，一个系统跑了三年，配置文件里可能还留着早已下线的服务地址。

下面是一个用tcpdump抓取应用间通信的简单示例：

# 在应用服务器上抓取所有与数据库相关的流量
tcpdump -i eth0 -nn 'port 3306 or port 5432' -w db_traffic.pcap

# 然后用Wireshark分析，或者用tshark提取IP和端口
tshark -r db_traffic.pcap -T fields -e ip.src -e ip.dst -e tcp.srcport -e tcp.dstport | sort | uniq -c | sort -rn

嗯，这里要注意：生产环境抓包一定要谨慎。我曾经在白天高峰期执行过一次tcpdump，结果导致网卡负载飙升，差点引发事故。建议在业务低峰期操作，或者用端口镜像方式。

  核心产出： 依赖关系图。我习惯用Graphviz的DOT语言来画，清晰且可自动化。下面是一个简单的依赖关系图示例：

digraph G {
    rankdir=LR;
    "前端应用" -> "API网关";
    "API网关" -> "用户服务";
    "API网关" -> "订单服务";
    "用户服务" -> "MySQL";
    "订单服务" -> "MySQL";
    "订单服务" -> "Redis";
}

你可以把这个DOT文件渲染成SVG或PNG，贴在迁移方案里，比写一千字都管用。

3.3 性能基线采集：没有基线，你拿什么对比？

上云之后，系统是变快了还是变慢了？

这个问题，如果没有性能基线，你根本回答不了。性能基线，就是迁移前系统在正常负载下的各项指标。我建议至少采集以下数据：

指标类别	具体指标	采集工具
CPU	使用率、平均负载、上下文切换次数	top, vmstat, sar
内存	使用率、Swap使用量、缓存/缓冲区	free, vmstat
磁盘	IOPS、吞吐量、平均延迟、队列长度	iostat, fio
网络	带宽使用率、丢包率、TCP重传率	sar, iftop, netstat
应用	请求延迟（P50/P95/P99）、错误率、QPS	APM工具（SkyWalking, Pinpoint）

采集周期建议至少一周，覆盖业务高峰和低谷。我习惯用sar来采集系统指标，因为它自带历史数据存储：

# 开启sar数据采集（默认已开启，检查一下）
systemctl status sysstat

# 查看历史数据（以CPU为例）
sar -u -f /var/log/sa/sa$(date +%d --date='1 day ago')

# 输出到CSV文件，方便后续分析
sar -u -f /var/log/sa/sa$(date +%d --date='1 day ago') | tail -n +4 | awk '{print $1","$3","$5","$8}' > cpu_baseline.csv

对于数据库，我建议用慢查询日志和性能视图。比如MySQL的performance_schema：

-- 查看TOP 10慢查询
SELECT 
    DIGEST_TEXT,
    COUNT_STAR,
    AVG_TIMER_WAIT/1000000000 AS avg_latency_ms,
    SUM_TIMER_WAIT/1000000000 AS total_latency_ms
FROM performance_schema.events_statements_summary_by_digest
ORDER BY AVG_TIMER_WAIT DESC
LIMIT 10;

避坑指南： 我曾经采集了一周的基线数据，结果发现业务高峰期恰好是凌晨的批处理任务，而白天交易时段反而负载很低。如果只看白天数据，你会误以为系统很空闲。所以，一定要标注清楚每个时间段的业务类型。

3.4 知识体系总览

下面这张图，是我对本章知识体系的总结。你可以把它当作一个检查清单：

好了，这一章的内容就到这里。记住：评估越细致，迁移越顺利。别急着动手，先把家底摸清楚。

📚 课程目录

3、现状评估与调研：如何盘点现有IT资产，应用依赖关系梳理，性能基线采集

3.1 盘点现有IT资产：别只数服务器

3.2 应用依赖关系梳理：画图比写代码更重要

3.3 性能基线采集：没有基线，你拿什么对比？

3.4 知识体系总览