公有云时代的售前打单

Xx金融迁移金融云案例分享（售前支持分享）

                                       

你们好，本次的案例分享，会给你们分享一下踩过的一些坑以及本身的一些心得，但愿能给你们在后续的项目中带来一些帮助，若是有不对的地方，欢迎你们拍砖头，使劲拍~~~

Ps：里面一些涉及客户隐私的部分已经和谐掉了，请见谅~

   使命召唤  临阵磨枪~

在2018年x月x日这一天，我收到了一封邮件，由Allen转发，告知有一个项目须要支持， 打开以后发现是一个金融客户须要从公有云迁移到金融云上，为何要迁移到金融云呢？金融云的好处就不详细展开说明了，总之相较于公有云，不管是安全仍是服务都有显著提高，可是这样一来成本会增长，咱们知道今年对于某些行业是比较特殊的一年，随着《网络安全法》的下发，不少企业受到冲击，金融行业固然也不例外，为了响应政府金融政策以及自身更加的安全考虑，所以客户决定搬迁金融云，固然可能还有另外一层的考虑（仅为我的判断），高投入换来的是高回报，一旦搬迁到金融云以后对用户来讲也是一个安全的保障，所以只要宣传作的好，会所以吸引到大批的用户，并获得用户对提供服务的应用提供商的信任，如今的市场鱼龙混杂。今年国家对“互金”行业的规范政策一直持续着，因此对于那些“不扎实”的企业必定会进行一些措施。好比IAAS基础设施连最基本的“high availability”都没法保证的企业。还有“运维人员权限管理、公司制度不健全”等等。

好比以下截图所示：

客户有需求天然须要沟通，可是因为客户身处杭州，地域关系，所以实施以前的沟通都是以电话和微信沟通为主。

在前期的沟通中，收到邮件以后，发现有一个附件，需求调研表（该附件为销售经理发给客户的），里面记录了客户的需求以及客户的体量，可是在后续沟通的时候发现里面的调研内容不少都是直接在网上复制的，这点做为售前须要注意，由于以前有过这样的案例，就是售前阶段是南，实施阶段是北，最后固然是双方扯皮，彻底说不清，缘由是客户本身对需求都不清楚，这种状况下建议不要去刨根问底，这样可能会获得一份客户本身不成熟的看法。

 

第一次电话沟通------简单了解客户需求

由于这个客户的特殊性，我不可能拿着ppt去给客户讲解，因此第一次的沟通侧重询问客户需求点，以前的《需求调研表》此时能够做为一个切入点，可是注意，通常在沟通一次以后，客户会但愿能有一个方案出来，这时候作出来的方案每每是不够成熟的，由于客户的需求不少尚未了解到（而当时的我并无意识到这一点，因此后续出现了不少问题）， 当时没想太多，下意识拿一份以前的迁移模板进行修改，结合客户目前的状况整理一下，加上报价一块儿发送过去。

 

方案解读：

1.     高安全，架构采用DDOS-WAF-SLB的方式，这样的作的好处，一个是针对异常流量或者×××有了很好的防御，另外源站隐藏在后面减小了源站暴露公网的危险

运维人员经过堡垒机登录，操做皆有记录，且须要受权才能操做。

2.     高可用，应用层的服务由两台相同配置的服务器提供，一台出现故障另一台能够随时顶上，数据库层采用的阿里云成熟产品RDS，底层 是主备架构，多可用区，

3.     高扩展，当业务量增长的时候，能够随时对服务器进行横向扩展而不会影响业务

 

固然没有绝对完美的方案，后面我会对改进版的方案进行说明，并说明目前这个架构存在的缺点（所谓的缺点实际上是相对的，最大符合客户业务需求的方案才是最好的方案，并不必定那些高大上方案必定符合客户的业务需求,切记）~~

 

与客户的沟通的时候须要有条理性，不是想到哪说到哪，沟通以前建议先本身整理一下将要与客户沟通的内容，另外在有效时间内拿到本身想要的内容而且引发客户的兴趣，这个很考验售前的功底~

 

 

      试想一下（售前常常干的事情，“人格分裂大法”~），假如你是客户，这边有个架构师和你对接，问了一些问题，而这些问题感受都是在念课本同样，你会怎么想~  而在此次沟通完以后不久，发现这个架构师又找你问了一些问题，而这些问题又是毫无逻辑性，感受彻底就是调查户口同样，他来问你来答，这个时候你做为客户又会怎么想~  我想说到这里，

你们应该明白了，交流是相互的，而不是你一我的的独角戏

 

这里贴上一段以前看到的话，这个不管是售前仍是销售均可以看一看，很值得深思，固然想要去真正的实现也很难。

 

“项目分为项目需求和我的需求，我的需求是项目需求的动机，由于人会感到不足，缺失，痛苦，项目需求是我的实现的机会，由于项目的成功会让我的需求获得知足”

 

 而现实每每是，一个小小的事情，都有可能会影响到整个大局的变更，因此捕捉客户需求，并非嘴上说说那么简单的~

 

Technical point：

a)   阿里金融云目前sqlserver没有只读实例，华东1

b)   阿里金融云负载均衡目前仅支持性能共享型，华东1

 

继续~

 

  POC测试阶段---------------温柔的陷阱

 

在通过初步的电话沟通以后，我发送了一个初步的报价和方案，此时的进度还算正常，等待客户反馈，其中在里面我建议先进行测试，即先测试再正式，客户那边也表示认同，此时第一个雷埋好了（布置的好能够给客户一个惊喜，布置的很差会把本身炸的体无完肤），不少人在上云的时候每每喜欢说一句话，先测试一下吧，而这个测试，到底测试的是什么，以及对后续的生产环境会产生了什么影响，这个必定要想清楚，

 

这里我简单总结一下本次测试的目的以及一些测试思路（供参考）

1.     基础架构测试，主要验证架构是否适应客户目前的业务，也能够理解为架构优化，

2.     高可用测试，主要目的是为了验证架构的容错性，以及对业务的影响程度

3.     压测，主要目的是验证目前的架构是否能够达到客户预期的并发指望

 

部分测试文档截图以下

测试的目的主要是为了验证这个架构对客户业务的适应性，以及架构的稳定性，而架构对业务的适应性测试任务主要放于客户侧，由于客户对本身的业务最为熟悉，而正是因为这个决定，使得后续接收到的测试结果反馈信息都来自于客户侧，这个时候实际上是一种危险信号，由于此时的咱们对客户内部的结构以及对接人的状况并非太熟悉，更没有想到接收到的反馈信息并非那么的准确，此时的咱们都沉浸在遐想的世界里，由于客户侧反馈测试正常，一切ok，在后面的实施发现其实并不ok~

   

稍微“走个神”~

形成这个问题的缘由多是多方面，可是若是考虑周全那么风险将会大大的减小，就比如三国赤壁之战，也许曹操注定失败，然而当时若是郭嘉还在，至少不会败得那么惨,因此前期的考虑周全，是能够对后期进行规避一些没必要要的风险~

 

 

 

 

因此说在售前项目把控的时候，必定要注意，全局的把控，流程的规范，必定要作好，不只仅是对客户有个交代，对本身也是提升工做效率。

 

方案优化~

测试过程当中，咱们了解到客户须要和第三方接口对接（银行），须要提供ip地址给第三方，添加白名单，考虑到后续的业务的扩展，所以咱们对目前的架构作了调整。

调整部分以下：

PS：接口调用，由于是从ECS主动发起调用，故须要在银行侧的接口那边把NAT-GW的IP加入到白名单中。

 

方案优化解读：

1. 更安全，初版的架构应用层是虽然是高可用架构，可是两台服务器仍然是放在同一

可用区，

优化方向 将服务器放于不一样可用区（可用区能够理解为拥有不一样物理位置的机房），至关于实现了传统概念中的“同城双活”的设计，固然如今的部分公有云彻底能够经过SLB挂上不一样区域的ECS，实现“异地+同城多活”的设计，前提要设计好用户端本地优先接入的架构，

   2. 更便捷，初版的架构出口流量是从服务器自身出去的，这也就意味着对于第三方白名单来讲是要添加更多的白名单的，前期业务量少的时候还能接受，一旦业务扩展那么添加ip将会是一件很是麻烦的事情，

优化方向 使用NAT，统一出口，汇总网内出去的带宽。相似咱们传统架构意义上的“防火墙”的SNAT的功能。为的就是解决主动出去的带宽被统一。

 

会师杭州  风云再起~

 

在原有计划中，正式的切换要在5月份以后，而在4.19号客户侧表示但愿提早迁移，

【这种状况，在金融背景的客户案例中是不多见的，由于金融公司通常对于时间都会超前不少去规划，每一天的安排都是通过很是多的前期准备定义下来的。可是为何会接收到这样的要求呢？~~~1%的特殊而紧急的状况】

这就意味着计划表须要更改，不过因为前面测试基本上代表网站能够在现有架构上正常运行，并且架构也基本知足客户的业务需求，所以提早切换对咱们来讲时间也是够用的，这个时候须要售前进行评估，根据现有客户状况以及多方面综合因素进行考虑，是否能够提早迁移，由于对于客户来讲可能只是一句话，而这一句话所涉及的方面确是甚广~

贴上部分实施计划表截图

计划表解读：计划表是对总体项目进度的一个管理和把握，所以须要考虑全面，另外对每一步所进行的步骤须要作到合理可行，以及后续风险的可控均可以体如今实施计划表中，所以很是考验售前对项目的控场能力的功底和售前对售后技术协调沟通的能力，因此这是个团队的活，并不是一我的强就能够了。任什么时候候都须要团队，这一点在这个项目中体现的特别深入。 

 

迁移前准备与确认

因为咱们是提早赶到客户那边去的，所以在迁移以前大概2个小时左右，我建议将客户与咱们这边的工程再次汇集进行最终细节确认以及分工，主要涉及到的是迁移过程当中每一步的实施人员以及目前的准备程度，这个是很是有必要的，

在迁移工做准备完毕以后，就能够等待正式迁移了~

这里稍微唠叨几句，若是读者参与过“物理机房的迁移、中小企业的网络割接、运营商的网络割接、银行业务的调整等”，那就知道这一步必定要过。由于每一分钟都很是重要。

 

 

迁移过程~

  

1） 中止解析（客户侧）

PS：这一步骤按理来讲不该该中止解析，而是解析到新环境中，这样会出现一个维护界面提示，直接中止会出现访问空白的状况，这样给用户的体验很差。后面的项目你们要留意，这一点你是站在客户的角度去考虑的“自身用户的体验”，因此后面这些习惯能帮助加快客户的“好感”

 

2） 数据同步，DTS（客户为主，咱们为辅）

这个在分工中，客户考虑到数据的安全性，所以不让咱们进行操做，可是咱们建议咱们从旁协助，若是客户操做过程当中有问题，咱们能够进行协助，在接下来的迁移中，咱们也发现了，客户对这个工具使用不熟悉。

Ps：迁移的时候遇到第一个问题，DTS提示权限不够，这个须要注意赋予的权限是否赋予上了，此次出错的缘由是由于多了一个空格致使权限没有赋上去，一直报错。

3） 安所有署（咱们）

这个步骤须要将域名和证书部署到安全产品上，证书咱们放置的位置是WAF上，

      划重点~~~：域名解绑以后，此次迁移发现生效时间居然达到一个小时，即在新环境布置域名，一直提示被占用，这个在以后的迁移中必定要当心，一个小时时间太长，而目前对于生效时间还未想到有效的解决办法，只能提工单，催一下阿里那边。

若是网站中断时间小，仍然是先将域名解析到负载均衡上去，先让网站运行起来，不过此时的访问多是http，而不是https

       

4） 解析切换，环境验证（客户&&乙方（咱们公司））

 

 

至此为止，这个项目算是告一段落了，可是打单之路远远没有结束，这个只是打单路上的一道风景，不过庆幸的是前进路上并不孤单，你们一块儿fighting~~~