象山影视城琅琊榜打卡:虚拟化收益：43天构建一个新的开发环境？

虚拟化收益：43天构建一个新的开发环境？

几个月前，我曾经教授了一堂利用精益原则（lean principles）来提升IT运维水平的课。精益设计的一个基本工具是价值流程图（value stream mapping，VSM），它可以帮助我们进行流程设计，识别并彻底消除各种损耗（重复工作、延误、多余的信息或流程、无谓的审核等等）。

在解释并以实例说明了VSM之后，我让学员们来尝试制定各自遇到最麻烦的流程。其中一个组的IT人员选择了针对软件工程客户的新开发环境构建流程，他们写出了流程中的每个步骤，然后评估了各个步骤本身以及所需的间隔时间。

当流程制定完后，最终发现需要43天来构建一个新的开发环境。

43天？这应该是一个软件项目的生命周期。当这组学员描述了他们制定的流程后，我告诉他们其中有明显的浪费和延误，如果用虚拟化技术来创建开发环境的话就可以大大缩短和简化流程。对此他们感到非常震惊：“Niel，我们就是用了虚拟化啊！”

“已经用虚拟化了？那么你们之前需要用多长时间来构架一个开发环境？”

“哦，差不多43天左右吧。”

这个团队虽然已经实现了服务器和存储的虚拟化，但是在部署新环境时的流程却和原来一样——添置新服务器和存储、获得资金支持、配置和测试——基于这些基础的步骤来进行审批。简单地说，就是虚拟化并没有带来实质性的改变和真正的价值。

通过对这个流程的梳理，我们最终去掉了购置、配置和审批的环节，最终使得原来43天的流程缩短到30分钟左右：这才是真正高效的IT组织。

很多时候我们都是用旧的流程和眼光来看待虚拟化。有一次我遇到过一个IT团队，他们对虚拟化环境的低利用率感到非常苦恼。该团队要不停地响应软件开发和应用支持团队的需求，但是新部署的虚拟化开发和测试环境在一段时间过后就基本不再使用。对此，这个IT运维团队的想法是限制用户的系统需求，因为用户其实已经分配有足够的资源但却闲置不用。

我问他们如果有足够的物理环境，是否会采用这样的方法（限制用户的虚拟资源需求）。

“当然会！”他们回答到。

而当我接着问他们是否认为在虚拟化的环境中这样做也会奏效时，他们就不是那么肯定了。

我继续问到：“首先，低利用率的环境是问题的根源所在吗？这些开发和测试团队是否占用了其他客户的资源？你们是否还有足够的虚拟化服务器和存储来应对更高的用户需求？”

“不，我们还有足够的资源 – 但是这样下去迟早会出现短缺的问题。”

我停了一会接着说到：“如果在系统容量方面没有机会成本，那么闲置的资源不会成为问题。但是为了避免在未来出现瓶颈，可以让开发和测试团队每个月都提交闲置资源的汇报，让他们自己主动指出哪些环境不再需要了。”

他们同意回去试一试。最终，在几个月内这个问题得到了解决。

虚拟化环境中的IT运维不同于以往的物理环境，我们需要控制虚拟资源的蔓生问题。另一方面，我们也希望通过虚拟环境来提升对业务和客户服务的响应度。

几个月前，我曾经教授了一堂利用精益原则（lean principles）来提升IT运维水平的课。精益设计的一个基本工具是价值流程图（value stream mapping，VSM），它可以帮助我们进行流程设计，识别并彻底消除各种损耗（重复工作、延误、多余的信息或流程、无谓的审核等等）。

在解释并以实例说明了VSM之后，我让学员们来尝试制定各自遇到最麻烦的流程。其中一个组的IT人员选择了针对软件工程客户的新开发环境构建流程，他们写出了流程中的每个步骤，然后评估了各个步骤本身以及所需的间隔时间。

当流程制定完后，最终发现需要43天来构建一个新的开发环境。

43天？这应该是一个软件项目的生命周期。当这组学员描述了他们制定的流程后，我告诉他们其中有明显的浪费和延误，如果用虚拟化技术来创建开发环境的话就可以大大缩短和简化流程。对此他们感到非常震惊：“Niel，我们就是用了虚拟化啊！”

“已经用虚拟化了？那么你们之前需要用多长时间来构架一个开发环境？”

“哦，差不多43天左右吧。”

这个团队虽然已经实现了服务器和存储的虚拟化，但是在部署新环境时的流程却和原来一样——添置新服务器和存储、获得资金支持、配置和测试——基于这些基础的步骤来进行审批。简单地说，就是虚拟化并没有带来实质性的改变和真正的价值。

通过对这个流程的梳理，我们最终去掉了购置、配置和审批的环节，最终使得原来43天的流程缩短到30分钟左右：这才是真正高效的IT组织。

很多时候我们都是用旧的流程和眼光来看待虚拟化。有一次我遇到过一个IT团队，他们对虚拟化环境的低利用率感到非常苦恼。该团队要不停地响应软件开发和应用支持团队的需求，但是新部署的虚拟化开发和测试环境在一段时间过后就基本不再使用。对此，这个IT运维团队的想法是限制用户的系统需求，因为用户其实已经分配有足够的资源但却闲置不用。

我问他们如果有足够的物理环境，是否会采用这样的方法（限制用户的虚拟资源需求）。

“当然会！”他们回答到。

而当我接着问他们是否认为在虚拟化的环境中这样做也会奏效时，他们就不是那么肯定了。

我继续问到：“首先，低利用率的环境是问题的根源所在吗？这些开发和测试团队是否占用了其他客户的资源？你们是否还有足够的虚拟化服务器和存储来应对更高的用户需求？”

“不，我们还有足够的资源 – 但是这样下去迟早会出现短缺的问题。”

我停了一会接着说到：“如果在系统容量方面没有机会成本，那么闲置的资源不会成为问题。但是为了避免在未来出现瓶颈，可以让开发和测试团队每个月都提交闲置资源的汇报，让他们自己主动指出哪些环境不再需要了。”

他们同意回去试一试。最终，在几个月内这个问题得到了解决。

虚拟化环境中的IT运维不同于以往的物理环境，我们需要控制虚拟资源的蔓生问题。另一方面，我们也希望通过虚拟环境来提升对业务和客户服务的响应度。