先交付一个可以带来关键商业价值的最小价值产品（MVP），后续再进行改进。尽可能利用裸机基础设施，而不仅仅是把私有云当成一个“IT项目”。不要试图在内部构建另一个公有云，那是不可能成功的。你的方案要具备足够的灵活性，为开发人员提供有价值的支持。你要提供新的方案、API、服务，为工程利益相关者带来顺畅的体验。确保你的私有云服务遵循现有的标准，加快开发人员采用私有云的速度，并可以在多个云环境上重用功能。你可能还需要设计SDN并开发出一些服务层，当然，这些要视你的实际情况而定。
保持学习曲线的平滑和敏捷是非常重要的。从简单的开始，标准化开发者的工作流，用好VLAN，部署核心服务（身份识别管理、网络、计算能力、存储），定义好清晰的升级路径。
案例
#1 在TubeMogul，我们通过反复试错来进行技术选型或选择供应商。这当中有些技术可能已经不存在（CloudStack、Eucalyptus等）了，最后我们选择了OpenStack，并结合使用了裸机。我们最初的设计倾向于使用便宜但强大的日常硬件，结合简单的网络，并设计好故障应对措施。我们只用了OpenStack的核心服务，以及Jenkins的基本CI/CD工作流和用于配置裸机的PXE.开发人员也使用了相同的CI/CD管道来管理跨云的canary和生产应用程序部署。多个环境之间需要具有标准的命名约定，我们才能重用现有的工具和服务。
3. 基础设施自动化
私有云部署很关键的一点是如何处理数据中心、网络和采购问题。这里涉及到资产管理和售后，它们很容易成为痛点，并给部署造成麻烦。所以，要想清楚你擅长做什么以及不擅长做什么。根据你的投资目标和团队结构的不同，你可能会承担很多压力，所以不要让那些供应商闲着。我时常提醒我的团队，VAR指的是“Value Added Reseller”，所以不要忘了增值部分。根据参与度模型的不同，你可能需要定义好机架排布、线缆布局、端口映射、电力拉线等等。在极端情况下，你可能要使用以机架为单位的模型（rack-at-a-time）代替以服务器为单位的模型（server-at-a-time），直接将装备好的机架搬进数据中心。你只需要将机架接近核心网络就可以了，不需要自己组装和拉线。
在进行硬件自动化时，要确保你的设计适用于你的数据中心。你希望你的设计是Top-Of-Rack「2」式的吗？或许你对TIA 942-A不甚了解，那么就让供应商提供想法并进行设计评审。这有可能会影响到硬件的选择和冷却通道的位置。这里有许多细节需要考虑。确保你考虑到了数据中心的空间位置和电力供应，知道如何利用现场人员处理售后问题。这些都是成功构建一个私有云的关键因素。
案例
#1 Adobe广告云平台数据中心的最小化部署单位为两个机架。所有机架都由供应商搭建，然后进行自动化的镜像和组件部署。我们使用了Puppet进行配置管理，如果有一个资源处于空闲状态，或者经过售后之后需要进行重新部署，只需要标记一下状态，然后重新触发构建即可。
4. 自己搞定
你需要对自己构建的东西进行反复的测试，需要一个真实的实验室承担测试工作。你要感受到痛点，并把它们解决掉。
在跨过一系列坑之后，你要为利益相关者提供可见的数据，让他们了解整个流程。要敢于把整个私有云的状态和风险点展示出来。你是否做好了计算资源的容量规划？利益相关者是否了解网络的局限以及这将给他们的使用带来的影响？如何提供网络的可见性以便建立良好的信任和信心？是否存在过载的计算资源和超额认购？在进行迭代和增长时，这些问题都是需要解决的。
案例
#1 TubeMogul的第一个OpenStack开发环境在一开始很成功，直到一个礼拜之后Ceph出现了问题，导致整个环境都崩溃了。这个环境是一个共享的环境，既是私有云的测试环境，也是开发环境。所以，我们得到了教训，就是不要将开发环境和利益相关者的环境混在一起。如果有人依赖你的服务，你就要承担起交付高质量服务的责任。
#2 做好容量规划是很难的，你希望了解你的业务，但又不希望业务的增长仅依赖你。知道什么时候提前增加容量至关重要。我们以两个机架作为部署单位，如果一个地方的资源不够用了，我们就增加两个机架。这个时候，设计的灵活性就发挥了它的作用，我们因此可以快速地扩展私有云。