一、"感觉服务器有点卡"是最可怕的话
双十一前一周，小圆跑来找小陈："小陈，客服说最近网店'感觉有点卡'，你看看吧。"
小陈正要拍胸脯说"我去重启一下"，被老周拦住了。
"'感觉卡'是最可怕的需求——没有数据，你根本不知道卡在哪。 是 CPU 不够？内存不足？磁盘慢？网络延迟？数据库慢查询？还是应用代码本身的问题？"老周说，"重启只能解决'玄学卡'，解决不了'真卡'。走，我带你看 vSphere 的性能监控。"
二、性能监控看什么：五大指标
"vCenter 自带性能图表，每个 VM/主机都能看。先记五大指标："老周打开监控界面：
五大性能指标（vSphere Performance）：
① CPU：使用率%、就绪时间（CPU Ready）、争抢
② 内存：使用率%、活跃内存、气球驱动（Ballooning）
③ 磁盘：IOPS（每秒读写次数）、延迟（ms）、吞吐量
④ 网络：吞吐量（Mbps）、丢包、错误
⑤ 应用层（配合 Guest OS 内看）：慢查询、连接数、GC ...
注意：vSphere 里看"就绪时间"（CPU Ready）很关键：
CPU Ready 高 = vCPU 在排队等物理核 = CPU 资源真不够了
"记口诀：CPU 看出就绪，内存看 Balloon，磁盘看延迟，网络看错误。 这四个'异常信号'，是定位性能问题的钥匙。"
三、性能问题定位四步法
"假设现在真卡了，怎么查？四步："老周演示：
第一步：看"受害者"是谁（哪台 VM 卡？）
打开 vCenter 性能图表，看所有 VM 的 CPU/内存/磁盘/网络
→ 定位到"卡的那台"
第二步：看"瓶颈"在哪（四大资源哪个到顶？）
这台 VM 的 CPU 90%+？内存 95%+？磁盘延迟飙到 100ms？
→ 找到"顶到天花板的那个资源"= 瓶颈
第三步：看"为什么"（瓶颈的根源）
CPU 高 → 是应用算法问题？还是 vCPU 太少？还是被别的 VM 抢？
磁盘慢 → 是存储本身慢？还是快照太多？还是 IO 冲突？
网络慢 → 是带宽不够？还是 VLAN 配置问题？
第四步：看"怎么办"（优化方案）
→ 加 vCPU/内存（先确认物理资源有余量）
→ 调整份额/预留（第七章）
→ vMotion 到更闲的主机（DRS 会做，也可手动）
→ 应用层优化（慢查询、缓存、代码）
"记住：先看数据定位，再动手优化。 别一卡就重启、一卡就加资源——那是瞎猫碰死耗子。"
四、容量规划：别等爆了才扩容
"监控不光是'出事了排查'，更重要的是'提前规划'。"老周说：
容量规划（Capacity Planning）：
看趋势，提前准备资源：
① 看历史趋势：过去 3 个月 CPU/内存/磁盘的增长率
② 预测未来：按当前增速，90 天后会到什么水平？
③ 提前扩容：在"还有余量"的时候下单买硬件/加节点
（别等 100% 了才想起来，采购要几周！）
云间书店的容量规则（示例）：
- 集群 CPU 峰值 > 70% 持续 1 周 → 准备扩容
- 数据存储使用率 > 80% → 预警（加盘或清理快照）
- 内存超分比 > 1.5 且出现 Ballooning → 加内存
- 每年双十一前做一次"容量体检"
"容量规划 = 运维的'未雨绸缪'。 好的运维不是'救火队长'，是'天气预报员'——在大雨之前就发预警。"
五、告警（Alerts）：让系统自己"喊救命"
"你不能 7×24 小时盯着图表。所以要让系统自动告警。"老周配置 vCenter 告警：
vCenter 告警配置（示例）：
CPU 使用率 > 90% 持续 10 分钟 → 黄色告警 → 通知
内存使用率 > 95% → 红色告警 → 电话
数据存储剩余空间 < 20% → 黄色告警 → 通知
VM 心跳丢失（VM 无响应） → 红色告警 → 立刻处理
主机进入非连接状态（主机挂了） → 红色告警 → HA 接管
告警通道：
vCenter 邮件通知 → 微信/钉钉/短信（接第三方）
集成：vRealize Operations（vROps，AI 运维，第十一章）
告警原则：
- 宁可"多告警"也别"漏告警"（误报可调，漏报致命）
- 告警要带"可执行的建议"（别只说"CPU 高"，要说"该加 vCPU 了"）
"告警是监控的'最后一公里'——数据看到了、分析完了，还要能'叫醒人'。 半夜 3 点数据库要挂了，系统得自己打电话给你，不能等你早上才发现。"
六、性能优化实战：双十一前夜
小陈按老周的方法，给云间书店做了一次"双十一性能体检"：
体检结果（vCenter 数据）：
① web-01：CPU 峰值 85%（健康线 70%）→ 可疑
查：CPU Ready 高 → vCPU 在排队
因：web 实例只 1 台，流量全压它身上
解：模板克隆再开 2 台 web，前面加负载均衡（LB）
② db-01：磁盘延迟 40ms（健康线 < 20ms）→ 磁盘是瓶颈
查：快照还留着 3 个旧的！（增量的罪魁祸首）
解：删旧快照 → 延迟回到 12ms ✓
③ cache-01：内存使用 98% + 出现 Ballooning
解：Redis 是内存大户，加内存到 4G（物理有余量）
④ 集群整体：CPU 峰值 60%，内存 70% → 容量健康
但双十一流量预估 +200% → 决定临时加 1 台 ESXi
结果：双十一当天，全站 0 故障，订单峰值 3000 单/分钟
——数据说话，防患于未然。
"看到了吗？没有监控，你可能双十一那天才发现 web 扛不住——那已经是灾难了。有了监控+容量规划，灾难变成了'提前几天修好的小事'。"
七、章末：老周的第九层总结
第九层：性能监控与优化
├── 五大指标：CPU/内存/磁盘/网络/应用
├── 异常信号：CPU Ready / Balloon / 磁盘延迟 / 网络错误
├── 定位四步：受害者→瓶颈→根源→方案（先数据后动手）
├── 容量规划：看趋势、预测未来、提前扩容（别等爆了）
├── 告警：让系统自己"喊救命"（阈值+通知+建议）
└── 核心思想：从"感觉卡"到"数据说话"，防患于未然
"小陈，你现在能让系统'跑得快'了。但还有一个问题——跑得快，不代表跑得安全。 你还记得第五章的 VLAN 吗？我们分了网段，但 ESXi 本身、vCenter 本身、谁能操作虚拟机——这些'入口'的安全，你管了吗？"
小陈一拍脑门："对啊！谁都能登录 vCenter 的话，那不是想删谁删谁？"
"下一章——安全与权限。RBAC 权限、加密、加固，让你的虚拟化'既有速度，又有安全带'。"