@lijiansheng
2016-09-12T18:12:59.000000Z
字数 5777
阅读 1765
我已经忘记了我的职业生涯中是否有过到潜在客户哪里去做PoC测试的经验，但是近期三周梦魇般的遭遇，使我不得不深刻思考这样一个问题。为了以后避免发生卖力不讨好、被动、无趣、消耗大量公司资源这样事情的发生。固有此文。
本文只谈改进，绝无吐槽之意。
近来“黑” OpenStack 的文章颇多，比如 Mirantis 自己就发布了两篇关于 OpenStack 的悲观论调：基础设施软件已死、OpenStack 失败的六个原因，其实，综合起来讲，并不是说 OpenStack 本身不能解决实际问题，而是人们对待它的方式有许多的误区。那么本文就是来正名其中的一个问题的，那就是该如何做好 OpenStack PoC的工作。
PoC 是英文：Proof of concept 的缩写，即概念验证的意思。从维基百科的解释来说：“是一种验证想法和思路是否可行的方法，或者在原则上就是一个示范，其目的是为了验证某些概念或理论有使用的潜力。概念验证通常很小，可能会也可能不会完成。”
但是，针对本土特色，这个PoC有些太多变化。来自百度百科的解释是：“是业界流行的针对客户具体应用的验证性测试，即根据用户对采用系统提出的性能要求和扩展需求的指标，在选用服务器上进行真实数据的运行，对承载用户数据量和运行时间进行实际测算，并根据用户未来业务扩展的需求加大数据量以验证系统和平台的承载能力和性能变化。”
针对 OpenStack，基础设施软件的典型代表，PoC 在本土的含义就是：“免费部署一套环境，并为潜在的客户作详尽的演示，培训潜在的客户技术人员，然后可能会在沟通中潜在的用户暴露出自己的需求和想法，并会被和各个友商作对比，找出各家的弱点和强项，并在权力寻租的招标中找到各种技术与非技术的坑。”
按照正常的逻辑，是这样子的：
业务需求压力 -> 灵活、快速的基础设施 -> 开源方案 -> OpenStack -> Mirantis OS
可是国内的多数的逻辑是这样子的（区分为三种情形）：
互联网公司
业务需求压力 -> 灵活、快速的基础设施 -> 开源方案 -> OpenStack -> 招聘，自搞
体制内
有预算没花完 -> 听说云计算很火／政策导向 -> 和VMware很相似 -> OpenStack -> 要求各家 OpenStack 厂商更改为和VMware 类似
意识到开源，但转型困难
业务需求压力 -> 灵活、快速的基础设施 -> 开源方案 -> OpenStack -> Mirantis help -> 自研
无论哪个流程，用户都会面临选型，希望自己的诉求能够得到满足，那么在选择的时候，就需要对 OpenStack 的功能进行验证、以及根据自己的物理环境（硬件配置、带宽、存储）尽可能的模拟一些满足性能需求的场景。
概念验证的测试，势在必行。否则就无法作出科学的决策。
当然，除上述3种之外，更多的“中国式”的没有任何规则出牌的情形是难以找寻到规律的，比如个人有次遭遇的就是某银行的系统管理员要证明 OpenStack 不行！嗯，没错，OpenStack 又不是万能钥匙，在很多方面它都不在行，比如为实例分配固定的IP地址，不要NAT转换。还有只是为了迎合国家单位的招标流程，所谓的陪标而已。还有的就是某些系统管理员，见惯了乙方媚俗的嘴脸，想学习一下较新的技术，编个理由来培训而已......正如很多本土特色的事情，是难以寻找出规律可言的，面对制度腐败与依附主义，掺合着人性、文化、历史遗留等，总而言之，是除规则以外，任何事情都可能发生。
所以，能够正确识别出PoC的目的，是一名销售人员初级的功力！至于为什么会做？这里只能列出稍具正常的情形，无数不正常的就限于笔者的能力和经验，无法一一提供。
云计算，尤其是针对基础设施软件，首先 PoC 工程师花心思去理解这样一个概念，不仅仅能够从纯技术的角度去阐释，还能够以通识的方式来诠释。比如和水、电一样、数字基础设施、类似道路和桥梁等等，从资源的角度来看待。
能够为潜在的顾客，讲述清楚云计算，是一件颇为不易的事情。但理念很重要，若是理念都错了，比如常见的“新瓶装旧酒”、“一个名词罢了”等，是必须要澄清的事情的，这个时候，还得看你讲话的艺术和沟通的能力。
最为至简的一句话，OpenStack 适合于横向扩展的应用。横向扩展的应用是那些无状态的、也可称之为云原生应用。也可以满足一部分所谓的纵向扩展的应用，当然用户要手动介入的也比较多。
根据OpenStack 官方所给出的企业洞见，给出了这几年来，OpenStack 在各个行业的应用：
| 行业分类 | 案例 | 优点 |
|---|---|---|
| 企业应用的敏捷平台 | Comcast | 快速上市 |
| 大数据 | 广州国家超算中心 | Rapid and dynamic provisioning of a cluster to provide researchers |
| 数字媒体工作流 | DigitalFilm Tree | Instant-on capacity |
| 电子商务 | 沃尔玛 | Enable developers to rapidly build new applications that adapt to ever changing needs through self-service exible infrastructure |
| 高性能计算 | CERN | Grow IT resources within a xed budget |
| IT as a service | Adobe | Use existing traditional app technology and bene t from cloud methodologies at the same time |
| R&D | NeCTAR | Allows researchers to rapidly deploy and share innovative new applications with their colleagues |
| 网络部署 | Telstra’s Pacnet Enabled Network (PEN) | Network provisioning time reduced from weeks to minutes through self-service |
| web service | Time Warner | Fast and agile infrastructure reduces time-to-deployment |
其实，在本土遇到的情况大多是将 OpenStack 理解为虚拟化管理平台，尤其是VMware Vsphere 有很大的用户群体，有一些诸如灵活的虚拟机参数定义（串口、声卡、网卡类型）、高可用等等，大多以为 OpenStack 可以以低廉的价格替代昂贵的 VMware 产品。这是最大的误区。
另外，Garnter的基础设施魔力象限有更加明确的定义：基础设施即服务云平台魔力象限，全球视野，作为基础设施的云平台——OpenStack 亦是在这个范畴下发展的。在章节“什么样的工作负载可被放置在IaaS云中？”一章中有明确的描述，我这里就转述一下：
在IaaS云中有四大类客户：
数字业务需要在IaaS云中处理大量等业务，而且，数字业务也不局限于技术公司，几乎所有的企业都受到了数字业务的影响，而且很多企业都内部启动了数字业务的“创业”或者成立了数字业务事业部，数字业务的用例非常的广泛，包括数字市场，电子商务，电子客户关系管理，SaaS以及数据服务等。这些通常都是用户的生产环境的应用，IaaS云通常用于整个应用程序的生命周期。许多客户都有非常关键的任务需求。
在数字业务的项目中，另外还有一些说明，很多组织在大量的IT项目中实行敏捷。如快速应用开发，原型设计，实验环境以及其它IT项目均需要敏捷，灵活，这样IaaS云会被频繁的执行，以尽可能快的方式满足急迫的需求。尽管多数是模式2的企业，但是敏捷的IT项目在企业的整个投资组合中并非核心，但是其有高度的可见度和高度的影响力。
在很多组织中，IaaS云逐渐的取代或补充着传统的数据中心基础设施，它通常的应用场景非常类似于企业内部的虚拟化环境。企业组织通常开始在开发环境或者是不是很关键的业务应用中使用，然后逐渐扩大到将关键业务放入IaaS云中。模式1的用户，即传统的IT企业是典型的在寻找IaaS云能够节省其成本，也会对长期的IT转型表现出极大的兴趣。
最后一种情况比较少见，拥有最少多通用需求，但对于这个少数市场来说，还可给一些小型的供应商带来很不错的收入，这就是批处理计算。对于这些用户来说，IaaS云仅是原来的HPC和网格计算的替代，用户需要它们来进行翻译，视频编码，基因测序，建模，仿真，数值分析，数据分析等，这些用户需要以较低对价格访问大量的通用计算服务，而很少去关注其稳定性如何。其中一些HPC的用例需要特定的诸如图形处理单元(GPU)或高速的内部通信等特殊的硬件。
IaaS云现在可以运行大多数的负载了，尽管不是所有的供应商都能够运行所有类型的负载。服务提供商正在朝着可以提供物理（非虚拟化）和虚拟资源的基础设施平台发展，根据该客户所选择的可用性，性能，安全性和隔离性来定价。这就让用户在头脑中考虑云的事务处理原则来架构为云而生的应用，而不是不经任何改变的将内部数据中心的跑在虚拟化服务器中的应用直接迁移到云中。IaaS云是实现新的IT能力的最佳选择，它已经是在一个内部数据中心的合理选择。
其实，从项目签单的角度来讲，或者从纯粹的技术挑战来讲，如果用户能够认真的讲自己的业务需求和应用的话，项目已经成功了一半了。以开源的灵活性，解决实际问题本身只是一个时间和接受度的问题。
所谓之，知己知彼，百战不殆。 竞争对手的产品，是必须有专门的团队去了解的。我列个表格来看看以 OpenStack 为原型做商业产品和服务的公司：
| 产品 | 公司 |
|---|---|
| Mirantis OS | 优铭云 |
| RHOP | 红帽 |
| AWCloud | 海云捷讯 |
| EasyStack | EasyStack |
| 有云 | UStack |
| 99Cloud | 九州云 |
| T2Cloud | 云途腾 |
关于能否基于成功的开源项目，做一家成功的发行版公司，我有专文进行过论述，详见拙文为什么基于成功的开源项目的商业产品会失败？
但是，其中有一条就是小心所谓的“深度定制、自主开发”。如果哪家公司敢于做出如此的承诺，那么就得考察其是否具备发展分支的能力和实力以及长期的投入。
这一点尤其重要，这里就我个人的经验来归为如下几类：
（这个时候，一个顾客能否转化为客户，其实差不多已经很明了了。毕竟这是一个万事以经济驱动的社会，若是产品上线不能满足需求，或频繁出问题，是谁也不会堵上自己的仕途或职业生涯。）
上述的这些归类，最后总结起来，是决定了我们最后的服务方式的。但是多数情况下，是可以筛选出是否可能是潜在客户的。这里举个例子：
6 -> 4 -> 4 -> 4
那么我要做的事情，就是给用户布道开源方面的，比如开源的社区文化、社区政治法则、社区开发流程、社区激励机制、团队建设、内部和社区接入、以及最后交付、反馈流程等等，有问题共同想办法解决。那么PoC就是一次沟通、交流过程。
其实，要和客户确认如下的 CheckList：
具体请参考 OpenStack 官方的《架构设计指南》。或者是拙著《云落谁家》。
具体执行的工作，其实是考量实施工程师的熟练程度和解决问题的能力的。OpenStack 是个非常庞大的系统工程项目，对于知识的要求非常的高，以Mirantis OpenStack 为例，所涉及到的项目（注意，这里指的的是实际项目，而不是计算机某些细分领域的知识。）
OpenStack 知识图谱 试图阐述的就是这个，不过此工程正在进一步的发展当中，现在所列出来的，如下图所示：
鉴于 OpenStack 所涉及到的开源项目，以及相关的计算机知识庞杂繁多，也就是说你需要一个团队来解决实际中可能会遇到的问题。（如果OpenStack足够成熟的话，这话我就不说了。）
报告，有的时候可以弥补PoC过程中遇到的不足。所以，要在开始之前就要有记录所有过程的意识。一份不算严谨的科学记录应该有如下一些项：
这里不是技术上的，而是可能会误导你的，可能会让你落入陷阱的提示。