存储Thin模式也可能导致的问题案例

【问题描述】
由于开发测试环境存储资源使用状况非常不均衡带来的空间浪费情况太严重，于是对于所有的开发测试环境进行了重组。
第一、虚拟化环境内的所有虚拟机存储采用Thin模式。第二、存储设备上划出的Lun也采用Thin模式。第三、开启虚拟化上存储集群的DRS开关。第四、建立严格的存储空间使用监控机制。
重组问题一个一个来执行，大量的虚机该重建重建，该迁移迁移。整整折腾了好几天。当所有人都在积极忙于监控自动化以及监控策略的时候，问题发生了，开发人员说开发环境有问题，应用发布失败，有的甚至都无法登录系统了。

【过程描述】
起初有点傻了，感觉是之前的重组过程有问题导致的问题。
登上虚拟化环境一看，好多虚拟机处于灰色状态，几乎处于不可操作的状态。
好多开发人员的虚拟机报出磁盘写入错误。

=> 查存储吧。
1.果然，存储告警。怎么可能，留的空间明明不少啊，虽然是Thin模式也不至于两天就满了啊。
2.从虚拟化环境内，查虚拟机的具体占用情况。一查总的占用量，果然超了。
3.查具体的虚拟机，发现有几个虚拟机，占用空间量惊人。两天之内从实际占用空间的100G，直接超过1T。

=> 应用IO，BUG，导致狂占磁盘到最大限度。因为虚拟机一开始分配的时候，由于是Thin模式，几乎所有的虚机都是看似非常大，但是实际占用非常小的模式。因为运维的同事认为他们平均使用空间不可能超过100G空间，而Thin模式的阀值是按照每个机器150G的余量来设计的，所以认为不足为虑。

【问题总结】
对于这个问题本身来讲，其实是一个很简单的问题。但是似乎从运维管理上我们应该有所启示。
1 Thin模式的设计本身来讲，是为了节省资源。实际上也帮我们做到了这一点。理论上只要我们做好监控，及时补充存储空间的不足，那么这个模式应该是个性价比很高的事情。
2 任何事情都会有特殊场合，如果我们对特殊情况没有预想到，那么很可能会走到另一个弊端上。假设我们对Thin模式资源的最大申请比率也有一个控制，比如说最大300G。那么再异常的情况的影响面儿仅限于某个虚拟机。