标签：频率   通过   概念   适用于   云盘   解答   直接   管理   成长   

该用户据全年跟进情况，目前该客户距正式启用我们公司云服务（运维服务）的日子已经有半年有余了，目前整体趋于稳定，故将目前用户进行深度复盘剖析，让各位伙伴更好的从该客户案例中提取一些有用的“武器”、“售前技巧”。

云产商：阿里云

企业背景—日企上来的终极三问~

1. > 为什么选择我们做云服务商？
   PS：此云服务并非指的是阿里云、腾讯云、华为云、亚马逊，而是云运维管理服务（MSP）
2. > 用户为何会引进云运维管理服务商？
3. > 怎么妥善处理应用问题引发的“扯皮”问题？

这些问题，其实也是目前所有做售前相关工作的99%会遇到的？

有很多不一样的应对姿势，这个因人而异。这也是我今天主要分享的内容，我是如何应该此类用户，并且“拿下”用户的“认可”和“信任”

分享目标，今天强调下，学习要有目标

以前一直没有讲分享目标，这一次啰嗦下（或我们会有后期学习目标的考核）：
1、 从该案例中，sales能获得“打单”部分经验
2、 找到如何做服务输出的思路和打法
3、 了解到我们公司是一家服务输出型公司，而并非一家资源转售型的代理商
4、 用户营业模式的初步认知以及产品策略

因为信息敏感问题，最终用户以“用户”简称、自己的公司以“公司”简称。如果您是我文章中提到公司的管理者，且认为文章表达措辞不当，请及时联系我进行删除或者修改

邮件联系方式：allen_junjun@hotmail.com

客户来源：

线上主动电话咨询过来的，后面由上海总部本地独立进行跟进：

同行竞争分析：

• 宝宝树
• 歪歪兔

客户诉求来源背景：

客户自身没有相关云计算的IT团队，加上公司部门“墙”和独立结算的问题，两边团队的IT资源不共享，总结的说：一边是IT基础架构部门（独立公司）、一边是APP应用部门（独立公司），但两边同属一家母公司。
客户想找到一个做“IT外包服务”的公司，帮助内部解决一些基础性的技术问题，弥补内部团队技能的缺失导致的低效的问题。

客户企业营业模式判断

属于传统零售行业，通过线上的官网、天猫等虚拟店铺提供在线预订早教材料和周边玩具。结合线下实体店（多以×××店扩展，但苏州有自己直营店）进行面对面的互动体验，通俗的讲就是“陪孩子们”完，大多在沪的家长都会在周末和孩子一起过去玩，也有的放在那边“托管”。：），既而产生支付行为。

用户商业模式分析、产品构成体系、企业backgroud这里统统省略，我们直接开始售前阶段的拜访主线讲述。

第一次"售前"拜访

Sales安排了当面拜访，我记得当天行程安排还是很紧密的。一点都不能耽误（一场接着一场，总共四场一天）。

我和sales到客户现场后，我确认是我们的老客户，但是另外的独立的部门。
会议室清一色的“仙女”坐在对面，进去后很快的发现对接的部门是一个单独应用部门，且目前负责的人员属于偏管理职能，非相关IT专职人员兼顾管理云上的资源和应用服务。

Sales提醒我，我也立刻意识到要换一种通俗化的沟通方式，快速的讲解了我们的业务形式（包含公司企业价值观，工程师文化，发展经历）。

~~这里有个小插曲，过去之前，sales已经进行过一次服务内容报价的整理了，所以是第二次片细节内容的汇报~

很快简短汇报完后，客户的部长紧接着就直接聊到了目前的问题，整理如下：

即刻需要解决的痛点：
1） 用户在更新APP内容时候，经常出现秒下载等访问不到的问题，既而导致用户投诉，app体验糟糕，平均每月预估有30起以上的使用投诉（而客户的处理办法也就是送些玩具和订购优惠）
2） 软件开发商遇到很多技术问题无法妥善的传递给我们，我们也无法正确的识别到一些技术风险，导致用户无法正常控制项目中潜在的技术问题既而产生的风险，当出现应用问题后，软件商经常的推诿，消极对待，责任担当意识不够。
3） 目前阿里云云上的安全（数据）问题无从得知，担心出现严重的信息安全问题影响公司形象。
4） 用户组织结构需要学习阿里云相关知识，并对目前业务运行的情况有一个“透彻”的自主掌握

随后我略显着急的讲了一个近期的客户案例——P2P支付客户的案例，详细阐述了我们在其中如何辅助用户积极解决问题、识别问题、代码问题优化建议等。

客户参考客户案例：某P2P支付公司
详细表述，我这里不赘述。大家有空看看文章就明白我的策略了。
（文章分析传送门：http://blog.51cto.com/allen686/1968113）

接着继续正面的探讨（部分摘要）：

我个人针对性的去分析了目前存在的问题几个方面：
1） 第一个问题推断是传统运营商本地DNS劫持导致，建议使用HTTPDNS
2） 第二个问题是否是合同中并没有明细的服务描述以及处罚措施，对第三方供应商管理上存在一些经验性的缺失，既而导致消极对待等。
3） 阿里云安全问题主要是组织结构缺失导致，故建议通过第三方专职人员完成
4） 客观的描述了用户内部缺失专业技能人员或没有学习“土壤”，导致云计算能力成长天花板不高

ISV和公司可以是平行关系也可以是相互依赖关系，但一定不是对立的角色设置。我们和客户内部IT团队（运维）的关系一定是赋能和被赋能的关系，而不是替代和被替代的关系

首次拜访结束后，

首次拜访结束后，我习惯性的记录了会议纪要并发布出去“调研”文档等等，沉寂了一个半礼拜后，事情出现了一些新的转机。~我和sales都异常兴奋~

【客户让我们去现场交流运维交接的细节问题】，我和销售心照不宣，这件事情成了，后面就是稳稳的推进即可。

我们给出第一份调研表（显示如下）：

最终，如我所料想的一样，软件商（ISV）选择了无视，给了一份自己的文档，接着我们进行很久的过滤和提炼。这才最终确认全都是配置详细的中间件的配置文件，以及简要的一些拓扑图和业务逻辑图。

关于脚本放置的位置、运行频率等重要信息都没提，关于特殊需要注意的地方没提，所以这仍然具有很大的挑战。事后是我们的工程师进行了一台一台的看配置确认了一些关键的内容，这才梳理出来的，确实花了不少精力~！！

这里可能会有疑问，用户找我们来做什么？额外造成一些沟通成本和费用支出值得吗？我后面循序渐进的描述后就会有所体会，我们这个角色（MSP）这个行业的生意是如何构建的！

积极的态度，能解决不少问题

在以上描述的过程中是客户对我们认可的一个阶段过程，软件商（ISV）不知是因为不够开发，还是没有精力积极的应答我们，反而倒是这种对比，也是带来直接服务感知差距的来源

这里省略一万个字的流水账

随后的一个月中，

我从权限治理再到基础的监控和数据安全管理，再到很多内部IT管理上的干预工作。逐渐培养出了客户对这件事的高度认知以及充分认识到过往工作的一系列的缺失项。如某月计划推进的详细工作清单：

中间因为北京有一些任务，需要出差去北京。有一次会议是在回来上海的动车上进行的，我记忆还挺深刻，那天北京大雪。北京当日因很多动车、高铁、复兴号全部取消导致大量的人员滞留，我拖着行李在北京南站用“热点”抢到了一张票，在徐州后一路站到上海（也开会开到了上海）

架构师（售前）旁白：
整个云运维接管的过程中，以信息安全为中心一点一点开展。
期间我能准确的感受到，客户（以女神为主），都没有计算机基础，对于很多应该注意的地方都没有办法关注到。如果以一个老师的身份把这件事情讲清楚，极为重要

作为架构师除了要有极好的耐心、细心，更要用通俗化的语言解释一些技术专业术语，巧妙而有技巧的传递信息

这一点也一直是我在努力的地方（帮助客户成功），所以相对进行的很顺利

客户业务部门的组织关系构成，这里省略

这年头写一点项目分享顾首顾尾的，好难！！

技术辅助以及服务输出的关键内容介绍：

––––––––––––Dns劫持之用户APP更新秒下载，无法正常使用的root cause
使用场景：
1、由于通过HTTPDNS进行域名解析获取IP信息后，您需要基于该IP信息进行网络请求，即您需要具备定制网络请求的能力。因此HTTPDNS比较适用于C/S架构的应用场景。

2、浏览器环境下（B/S架构）由于客户端的网络实现对于开发者而言是黑盒过程，无法定制DNS与网络请求的实现，因此不适合在该场景下使用HTTPDNS。
因为首次见面就提出了该方案，客户对我们的专业能力极为认可

––––––––––––堡垒机之第三方运维管理
基于协议正向代理实现，对SSH、Windows远程桌面、SFTP等常见运维协议的 数据流进行全程记录，再通过协议数据流重组的方式进行录像回放，达到运维审计的目的，包括远程授权登录windows主机，通过IE浏览器，进行聚石塔平台相关部署操作，如下图所示：

––––––––––––数据安全管理，数据备份策略管理
重新设计了自动快照策略，定时数据备份策略，通过第一项权限账号的治理来干预数据管理的详细方式和手段。

––––––––––––云上信息化安全持续改造建议计划书
通过安畅的自身最佳实践输出信息化安全实践的流程制度以及it基础架构的改造建议。基于公司内部运行三年的ISO20000/ISO27001的体系，定制化输出：

––––––––––––面对面培训工作的开展
这方面的输出根据实际情况来判断，目前进行了一次。如何支持？参考阿里云线下培训服务内容：

––––––––––––自研分布式的监控月报/周报

––––––––––––详细工作变更日志

云服务成本优化计划书

这一个概念，我在上一篇文章中有详细解读过关于IDC和云计算成本投入的问题，希望各位读者有一些新发现。因为未来IT不再是简简单单的做做技术这么简单，业务IT的概念会越来越strong。IT不再是一个简单且独立的环节。

**最后一项，是客户感知更进一步的地方。因为确实真正的在帮助用户合理的使用云上的资源，相比目前市面上大量的号称“费用使用可视化分析”，虽然我们还没彻底工具化，但是人工的好处就在于是准确并经得起反复推敲的。

最终的结果总结：

1） 最终结果证明，我的第一判断是对的（这一点上，客户对我认可度非常高），因为过来第一次交流就看出根本的问题，事前投诉季度（≥100起）事后投诉在各位以内，但仍然存在少量的情况，（我也知会了用户，用HTTPDNS只是缓解并非根治）
2） 通过我们来扭转部分技术问题，技术与技术的对话更容易产生共振和相互理解（ISV、用户、我们）
3） 安全问题通过我们向用户管理形式上进行赋能，具体的从访问管理、数据备份、审计等方面入手，先对整个云上IT资源的控制进行有目的的“留痕”控制，保证操作可回溯，杜绝操作不留痕迹。再到最后的系统运行中间件的加密与优化调整。
4） 通过F2F的方式进行定期的登门拜访与交流，除解答疑惑之外，并约定定期现场进行一些基础云上的功能讲解和分享上。

该用户在阿里云上的云服务构成如下：

1、 VPC（专用网络）
2、 ECS（云服务器）
3、 SLB（云负载均衡）
4、 Snapshot（快照）
5、 OSS（对象存储）
6、 NAS（文件存储）
7、 Clouddisk（云盘）
8、 Vod（视频点播）
9、 CDN（静态资源加速）
10、 HTTPDNS
11、 Security group（安全组）
12、 RAM（权限控制）
13、堡垒机（安全审计）

QQ: 549675970
Wechat: Johnny_JunJun
E-mail: allen_junjun@hotmail.com

  一位正在转型的网工（Allen）
                      人生格言：越努力、越幸运            

一位云架构师用服务打动客户的故事之六（阿里云上的MSP最佳实践项目分享）

标签：频率   通过   概念   适用于   云盘   解答   直接   管理   成长   

原文地址：http://blog.51cto.com/allen686/2315547