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~~~
原文地址：http://blog.51cto.com/11125450/2127748