用户致容器云厂商：我们期望这样的功能演示方式……
原题：《容器云演示》
本文作者：汪照辉 王作敬 中国银河证券股份有限公司 信息技术部IT研发中心
作为最终用户，容器云功能演示本不是我们应该考虑的问题，但很遗憾的是，也可能是我们接触的都是初创容器云厂商，在我们PoC和交流中，各厂商的演示的技巧、方式和能力一直让我们不甚满意。我们不得不每次告诉他们我们关注的是什么，我们期望的演示方式是什么样的，他们似乎懂了，下次又是几乎重复上次的套路。直到我们看到某厂商的容器云功能演示视频，发现他们的演示和我们的期望基本匹配，虽然说还有一点不是我们期望的，但已经做的非常好了。
可能我们要求有些高，毕竟背景不一样，风格不一样，文化不一样，立场不一样，思维不一样，不在其位，可能难以有所体会。所以这里我们将分享一下作为用户我们关心的容器云问题所在，以及期望的功能演示方式。我想不只是容器云，万变不离其宗，其他产品演示也是一样。
我想我们应该都同意，建设容器云平台并不是仅仅为了一个容器云，容器云只是基础设施平台，如同我们电脑系统的硬件和裸操作系统。要想让它有用有更高价值，需要在其上安装更多的工具软件和中间件，才能用它来管理好资源、应用、服务等。
容器云或者容器云PaaS大致可以划分为容器云基础平台、DevOps流程和工具链、微服务生态（实现服务全生命周期管理）几个部分，要实现PaaS能力，其实还有很重要的中间件能力的支撑才行。
很多容器云厂商非常推崇他们的流水线，不过在我们看来这些东西都是中看不中用，我们实施容器云，是最终要上生产的，不是为了玩过家家。其实我们也说过，流水线设计更多是PoC概念验证，不适合于生产。所以非常不建议拿流水线来演示。
还有就是很多容器厂商人员喜欢拿一些中间件如Tomcat、Nginx来演示部署、弹性伸缩等。这也是我们非常不欣赏的方式。你用懒惰的方式对待客户，客户也会用懒惰的方式对待你，那你就没有机会了。
那选择什么样的场景合适？其实作为客户，我们关心无非就是这几个部分的功能和实现的能力。DevOps可能不太好演示，除非有合适的产品，但我们觉得目前的产品实现可能还比较难，不过也可以考虑分功能点演示，以镜像仓库作为媒介，演示应用生命周期管理中涉及的DevOps能力，比如敏捷开发能力（CI）。
容器云平台我们关心功能比如容器云平台的平台管理和资源管理能力，容器云平台的多租户能力，租户的用户、角色、权限、组织结构、应用、服务的管理能力等，平台的资源调度编排能力，基础设施网络、存储、CPU、内存、主机、集群等的管理能力等。平台的基础组件如日志、监控、告警、安全认证等能力。
最重要的是应用、服务的全生命周期管理。这是我们最关心。容器云只是个部署平台、载体，对于多租户的用户来说，保证资源可用，应用服务正常运营就好，至于平台是什么，不是重点。所以演示的重点应该是应用服务的运营过程中的能力点。这有很多场景可以选择，比如容错、限流、路由、弹性伸缩、灰度发布、负载均衡等等等等。
确定了演示场景，然后需要准备演示示例服务和应用，以及演示环境。
我们前面提到，给客户演示时，一定不要偷懒省事的随便拿个中间件去演示。要使用具体的服务示例demo。选择什么样的演示示例服务或应用，一般取决于要演示什么样的场景。
在演示之前，根据要演示的场景来选择相应的示例服务。这些示例服务需要提前准备。比如要演示支持SpringCloud微服务，那就需要开发一个或者找到一个合适的SpringCloud微服务来。示例服务也不需要太复杂，能把要演示的功能能力展示出来就可以了。
最简单的，用SpringCloud实现一个Hello <user> 微服务，用户提供一个输入user，结果在页面上展示出来或者返回结果。最简单的这个服务可以演示对SpringCloud微服务的支持，服务的部署、路由、服务模板等功能，同时SpringCloud的服务注册发现、网关等组件也可以部署并集成起来，这是简单的演示对SpringCloud微服务的支持。
但要想演示负载均衡、容错、路由、熔断、容器迁移等能力，那可能就需要模拟一个业务应用来展示。比如产品销售系统，可能需要实现客户、产品、订单、支付等服务，这些服务共同构建成一个产品销售服务系统。
另外可能需要准备中间件环境，比如Kafka，在示例应用中可以展示过去一小时每5分钟的客户请求数量，这可以借助Kafka来实现。演示尽可能模拟真实的业务，演示示例（demo）就是简化版的实际业务功能实现。
在开始演示后，首先要综述本次演示的场景和内容。这一点，上文提到的某厂商就做的非常好。不但口头一一用语言介绍本次演示的内容，而且把演示的内容、涉及的微服务组件、各微服务之间的关系图都在屏幕上展示了出来，让我们一目了然的理解了本次演示的主要内容和组件服务之间的关系。
在综述演示内容之后，对于每个演示的功能点也要进行说明，比如熔断，熔断是什么意思？什么情况下会用到熔断这个功能？如何模拟熔断？预期结果是什么？……演示步骤、期望结果、用到的工具等可以先期做个说明。也可以借助于文字、图片、表格等，辅以言语解释和说明，这样对于听众来说，非常清楚本次演示的目的、过程、结果。所能取得效果也会非常好。
我们也是遇到过这样的事情，才把这个提出来。演示时不能着急，就按照平时大家交流的语速讲解演示就可以了，这样也有思考的时间。录屏不要把速度调为2倍播放速度。在演示之前，最好能够想一下每一步怎么做，或者可以预演示一下，整理一个演示大纲，心里有个底。讲解演示时，控制好节奏，不能快，也不能慢，一定要预留给听众理解、思考的时间，让听众能明白讲的内容是不是他们所关心，是不是能满足他们的需求。
演示的目的是为了引导客户，不是为了应付差事。所以你的讲解得能吸引到客户的兴趣，这样客户才能跟着你的思路走，才有兴趣了解产品的详细功能能力，才会考虑在实际业务中能用在什么地方，能带来什么好处。如果你做了很多东西，但就是讲不出来，那就会非常吃亏了。别无他法，换一个能讲清楚的，能控制节奏的吧。
交流过程中，也遇到很多演示过程中鼠标点来点去，屏幕切来切去，看的晕、听着乱的问题。控制好演示速度，还要控制好手和口，协调行进。在给客户演示时，演示操作要随讲解而行，避免出现鼠标在屏幕上点来点去，晃来晃去，那样会分散客户的注意力。讲解到哪个步骤，需要怎么去操作，再详细演示给客户，同时许可情况下可以解释功能设计的特点，取得的效果等。
一个场景可能涉及不同的流程，比如不同的输入条件会有不同的结果。这需要在场景综述中介绍后，分条件来演示场景流程。也会涉及到不同的产品和工具，比如用Jmeter来发送测试请求，然后回到应用查看应用执行情况，再到日志和监控查看日志和监控数据，正常和异常请求结果对比和在不同组件中的差异体现等。条件改变、屏幕切换，要基于讲解的次序。总的来说，功能操作是为了辅助并用来支持解说的依据。
演示过程中切记鼠标不要点来点去，每次操作都要有相应的目的，有相应的语言解释。
演示过程中，我们经常会执行一些操作，或者出现一些意外情况，和预期的结果不一致，在这些操作的过程中，可能就中断了语言介绍，这个其实也是不可取的。语音的停顿可能说明对演示的场景内容不熟悉，或者不够重视，缺少相应的准备，又或是缺少相应的演示技巧。但从客户的感觉来说，都是不流畅。所以一方面要求我们演示之前，必须对演示的内容有充分的理解，演示的步骤和解说有详细的考虑，也可以预演练习，做到熟练操作和言语解释。
我们可以多谈一些相关的事情，多说一些题外话，让屏幕不动（切换）；但不能让屏幕一直在动，却没有语音解释。对于每步操作，说明它的作用和意义。同一界面中不相关的功能项，可以暂时跳过，只说明本次场景本次流程中需要做的事。一个场景可能涉及多个流程、多个产品、多个界面，这些流程、产品、界面等之间的跳转要保持平滑，避免想起什么点什么，来回混乱切换。
每个场景演示的时间要有个预计，一般情况下一个场景演示时间不宜超过15分钟。通常3、5分钟足矣。其实如果留意一些外企做软件产品网站的话，会有很多关于产品特性的介绍视频，每个视频都不大，一般不超过3分钟，很多也就几十秒。当然我们在演示容器云特性的时候，时间太短也无法演示明白，所以还是需要3、5分钟到10来分钟来介绍、操作、解释演示的内容、步骤、结果等。
对于多个场景，最好分开分段演示。预留休息、思考、交流的空间。演示的示例服务可以是同一个。这也要求我们在演示时考虑演示场景的顺序。比如路由、负载均衡、弹性伸缩、熔断这几个场景，首先可以演示路由分发请求的能力；再看一个服务在容器云上部署，是否能通过容器云实现了负载均衡能力；请求多了，负载大了，就要看弹性伸缩的能力了；一旦超过了弹性伸缩的能力，就需要考虑熔断保护了。这样几个场景就可以一起演示，彼此关联，和实际的业务场景需求一致，就能引起客户的兴趣和共鸣。
演示完成之后可以用一两句话简单做个总结。如果能让客户知道演示的场景能力相对于其他厂商的产品有什么优缺点、可取的地方，也是赢得客户信任的方法。
说到底呢，还是需要在演示之前做好准备，演示的时候才不会出现意外。无论从场景选择，案例示例服务准备，还是演示演示内容、演示步骤、演示时间的规划，都需要认真的准备。台上一分钟，台下十年工。要做好，是需要付出很多努力。
最后祝大家一切顺利，皆大欢喜！
更多相关内容，请点击阅读原文
长按二维码关注公众号