私有化部署的耗时，一般需要两周左右的时间，给人感觉耗时太长了。但从耗时角度去看的话，一个大单从开始到最终结项，历时半年到一年是很正常的，这样看，两周的部署耗时占比不到 10%，并非项目交付耗时的主要矛盾点。

但如果两周部署耗时的背后，是从研发团队抽调了几十名高级工程师加班加点，夜以继日换来的，可能大家都无法淡定了。假设一次大型央企的异地私有化交付项目，部署耗时 20 天，期间现场累计参与人数超过 60 人，现场峰值人数超过 30 人，30% 的人员是高级工程师，相关人员频繁往返于两地间，粗略估算一下成本，至少 50 万，这样的模式，只能是在起步阶段交点学费吸取点教训。

在部署耗时的优化上，还需要考虑客户所在行业的特殊性，尤其是关系国计民生的领域，互联网的快速迭代，越变越美并不一定适用。我们可以建议在入场前将我们需要的资源准备完毕，但也只能是建议。对于在现场部署过程中，诸如各种审批流程和要求，甲方工作人员每天的工作时长，基于安全因素对数据传输和拷贝的限制等等，都会影响最终的部署耗时。

因此，相比于部署耗时的优化，对部署成本的控制更现实一些。如果部署工作是由外包来进行的，且过程中不需要公有云厂商的技术支持，那么只要部署耗时控制在客户可接受的范围即可，厂商也会因此具备大规模批量实施的能力。

什么叫做质量缺陷呢？简单来说，在你完成一套专有云产品的私有化部署之后，最严重的情况，可能这套系统完全无法使用，大部分时候，都会有一小部分功能无法使用。

质量缺陷的影响是什么？最糟糕的情形莫过于你成功的将你的客户转化成你的测试团队，从你部署的系统中，源源不断的反馈各种问题，进而逐渐失去了客户对你的信任。

既然是在公有云验证过的产品，为什么私有化部署还会出现这么多的功能不可用（或者称之为质量缺陷）？我觉得有如下两点：

复杂度：从厂商角度看，公有云产品由数百个模块构成，对外提供几十种功能，涉及到从网络，硬件，操作系统，程序，配置，上下游依赖关系，数据等方方面面，这样一个在公有云厂商中往往是多个部门上千人耗费数年打造的产品，现在让刚成立的交付团队来搞定一个由上千人参与的复杂系统，其难度可想而知，仅仅是能够熟练使用公有云产品提供的这几十种功能，就需要花费很长时间，更何况还要面对数百个模块，数百种配置文件，数百个模块间的复杂依赖，不同的开发语言，几乎涵盖了业界所有主流的开源软件等，以及为了一个小功能牵一发而动全身的痛苦。

兼容性：从客户角度看，不同行业不同客户，真可谓是千人千面。基础设施的供应商不同，组网协议不同，硬件的品牌型号规格不同，操作系统和内核版本不同，登录和认证方式不同，等保要求不同，资源提供方式不同，还有各种极小众的东西，比如非常生僻的数据库，十几年前的软件，小众的编程语言等等。专有云产品为了兼容这些差异，必然需要临时开发一些定制化功能，这也成了质量缺陷的重灾区。