景铁军歌

建议还是根据应用的重要性和业务处理量，以及数据访问和处理响应时间等关键指标对应用进行统计，合理创建多个资源池，进行资源分配，做好资源调度的平衡，才可以从整体上更接近物理机的应用情况。

虚拟化应用现在不是一台机器的应用，把风险从单台机器的风险分散在不同位置的不同机器，一定程度上会把应用从不稳定或故障状态拉回正常轨道的时间更快捷，从而提供更好的应用服务质量。

进行业务案例分析，做业务重现或模拟业务重现，细化评估的内容和标准要求，根据数据验证结论，这样评估出的差距更有意义。 在不同的业务处理，不同的业务量，不同的处理时效场景下，评估偏差会与预期会比较大，。

I/O下降 会有多方面的因素，优化方向和优惠措施也不一样， 比如磁盘的数据块要和逻辑的数据库相适应，提高数据访问率； 从网络端口将不用业务和应用分离。 不用应用场景和应用案例，除了一些通用的手段，提供不同的瓶颈检测方法

不可预期的增长是无法预料的，只能在适度合理范围内做规划，并实时监控业务增长量并提前预判，及时做相应处理。 对技术部门来讲很难做到长期的精准预判，能在反映处理时间内，提前预判问题 去解决已经很好了。

不仅会有设备性能差异，新设备的稳定性 可靠性也需要一段时间来验证，上线前很有必要使用合适工具就系统 及 业务进行压力测试 和 峰值测试 ，网络测试 数据io测试 数据处理测试等一系列测试 以发现潜在风险， 也支持分梯队更