本页目录
进了云，先接受证据边界变了
第 11 章先解决一个大前提：系统没有变简单，只是被宿主机、hypervisor、cgroup、云盘和虚拟网络重新包装了。
包装一多，很多裸机时代顺手就能下的判断，都会开始失真。
先看哪些判断最容易失真
进云以后，最常失真的通常是这几类：
- CPU 利用率看起来正常，但其实被 quota、throttling 或 steal time 改写了
- 磁盘延迟看起来像本机设备问题，但后面其实还有云盘和远端存储
- 网络抖动看起来像链路问题，但中间还混着虚拟交换和宿主机争用
- 机器内部指标看起来没问题，但真正的问题在你看不见的宿主机那一层
所以第 11 章不是讲“云知识大全”，而是讲“证据被包装后该怎么修正方法”。
别拿裸机直觉直接解释配额、云盘和虚拟网络
最常见的错法有四种：
- 直接把裸机阈值和裸机直觉搬进容器或虚拟机
- 看不到宿主机，就停止分析
- 把共享资源争用误判成应用缺陷
- 把应用缺陷全部甩锅给云平台噪声
这些错法都在做同一件事：把环境包装当成背景噪声，而不是分析对象。
证据不完整时，先靠边界和对照推进
看不见宿主机，不代表没法继续查。第 11 章最值钱的地方，是教你换证据。
先优先保留这些：
- 同类实例对照
- 不同可用区或节点对照
- 版本前后对照
- 配额变化和症状变化对照
- 负载变化和延迟变化对照
环境越黑盒，边界证据越重要。
别被容器里 top 和 iostat 的全局数据骗了：容器常常缺乏完善的统计隔离，很多传统工具在容器内看到的其实是整台宿主机的混合指标。一个本来很空闲的容器，也可能显示出“磁盘正忙得很”，因为它看到的是别的租户和宿主机一起搅出来的总和。
一个最典型的错法：容器里 CPU 不高，就说不是环境问题
现场很常见：容器里看 CPU 还行，于是大家很快就把环境排除了。
但这中间可能还差几步：
- cgroup 配额是不是已经卡住了
- throttling 有没有开始出现
- steal time 有没有把时间偷走
- 每核分布是不是已经严重失衡
如果这些都没补，CPU 判断本身就已经不稳。
先把裸机直觉改成云环境解释
先写一张裸机判断修正表
至少把这几条写下来：
- CPU 高低在容器里要补什么证据
- 磁盘慢在云盘里要补什么证据
- 网络抖在虚拟网络里要补什么证据
- 内存压力在 cgroup 里要补什么证据
看不见宿主机时，优先做对照
以后拿不到底层全量指标，就先做：
- 同类实例对照
- 前后版本对照
- 配额和流量变化对照
先把范围收缩，再决定要不要继续深挖。
把环境包装本身当成分析对象
遇到云环境问题时，别把 hypervisor、quota、云盘、虚拟网络当背景噪声。它们本身就是解释链的一部分。
还要再补一个更硬的边界：像 SR-IOV、Nitro 这类直通硬件技术，会让宿主机层的常规监控直接变瞎。现代云实例的 I/O 可能绕过管理程序，你在宿主机侧敲传统命令，根本抓不到客户机的真实读写；排障要么切入客户机内部，要么借更底层的硬件计数器。
环境修正以后，实验数字才可能可信
第 11 章解决的是“环境变了，判断怎么修正”。第 12 章接着解决“做 benchmark 时，怎么让数字可信”。