好久没来了，这段沉浸的时间都在专注学习云计算相关的解决方案和进行实战，这一次更新那当然是有项目在个人的努力下，落地了！！！！


所以过来更新下，我在项目中的各个状态。当然仍然是用第一视角的去解读，这也是一次汇总和回顾，有很多主管的想法在里面，不喜勿喷。


先在“上菜”前，开放的聊聊我个人理解中的云计算是什么样子的？到底什么样的业务部署形式才属于真正的云计算部署？到底我们在云计算这样的趋势下如何合理运用好云计算的特点去提×××适的技术解决方案？


首先，我个人的总结了几点：

1. 改变了传统IT运营交付模式，减少了传统IT对网络高级工程师需求，降低对运维团队的投入。


2. 动态弹性调整，按需使用，按量付费。完全灵活自主，若企业过于庞大，预算控制等相关IT治理流量冗长，对于业务团队开发效率是致命打击。无法很好的控制预算申请额度，还要考虑传统的设备利旧等等问题，接踵而至的管理上的问题，都是传统IT治理中无法避免的。在企业应用上线初期保证业务系统架构和IAAS架构高可用的情况下，可以用最低的资源配置让业务快速上线进行demo的环境的ready，等待业务经过压力评测后，在平滑的进行资源配置提升。在成本控制上也是boss非常乐意看到的。


3.DDOS***的包袱、IT基础资源的硬件维护投入（每年维保服务）、机房的风火水电维护、中国多家运营商之间的异网传输问题，应用和网络安全的的包袱。都可以扔掉，完全交给专业的运营商去解决。
综上，所以云计算带来的“革命”一定是新鲜互联网企业和软件开发商（ISV）的必选。无论是从运营角度还是技术对接难度难度上，云计算均是无懈可击之势，所以搞清楚客户的准备上云的系统应用非常重要，这个可以做为一个突破点，去了解其他的应用。然后慢慢引导上云。一定会双赢


好了，上菜，上菜！！！！！！


项目背景：

简述,客户考虑上一套物联管理系统，涉及消防系统、门禁等传感信号管理，管理员可以通过手机app、客户端管理终端等方式管理   

1. 客户属于国资背景    

2. 企业应用属于物业管理系统性质    

3. 无任何新旧数据过渡的“负重”，完全新的系统上线


项目经过：
大家能明白，做售前或者架构师，一定是销售机会现行，那就一定是sales先接触到最终客户。那这个时候我一般会先找到对应的sales，先聊聊客户的情况，通过什么方式找到的？对方是CIO还是CTO，还是engineer。总结一句话，先弄清自己面对的对象是谁，再去考虑怎么去设计方案和沟通。

进行了一些沟通后，确认了对方角色，公司名称。随后进行了一些百度了解。

这里再唠叨一句，我们有很多冲售后走向售前的工程师，特别容易犯的意识形态错误，会先去想这个技术怎么落地，自己有没能力做？不会去关注即将面对客户是谁？总结一句话，如果你从幕后走向业务前端，一定务必先搞清楚你的客户（博弈的对手）是谁。
我还是像之前的一样，用个人的视角去阐述自己的处理经过，当然中间有很多观点均是个人主观出发，若感觉比较偏激或偏执愿意与笔者交流讨论，留言给我噢，若觉得没有什么必要，直接往下看正文略过即可。


第一次电话沟通-【需求沟通&设计阶段】：
在去客户现场前一天，我通过sales，我与客户进行了基于阿里云的产品第一次沟通，沟通了应用场景、软件情况、高可用等思想。可以说是一聊就明白了，非常顺利。

接着晚上加班整理了架构方案，架构图如下：


方案一


方案二


方案三


这里一共提供了给客户了三种架构构建方案，关于ucloud暂时没有给出，因为发现ucloud的云产品-负载均衡在某些地域没有，这个局限性比较大，就直接忽略了。


PS：因涉及三个产商对标的情况，涉及一些竞争，我这里不透露，大家自己去琢磨吧，哈哈

注意，这里是此篇文章分享的重点，我们在第一次面对沟通中，客户提出了不少技术上的挑战，当然你会想，就这么点产品，哪会有什么挑战？


第二次面对面拜访洽谈-【方案确认&可信性对接】：
这里先说说下前面设计的方案的思想：web无状态，统一存储、数据库分离部署


挑战：
1. 软件商目前告知数据库、文件存储不可拆分部署
2. 软件未在负载均衡环境下测试过，需要测试
3. 腾讯云、阿里云、ucloud的产品优劣势对标


因客户最终比较偏向于阿里云，所以这里给大家稍微提一下阿里云的产品的知识设计出于的考虑。

前端：WAF（应用防火墙）+SLB（负载均衡）+ECS（无状态云服务器）
后端：RDS（云数据库）
文件存储：NAS文件存储
网络：VPC（虚拟私有网络）+NAT网关（解决ECS出局流量）

当我们在部署的SLB后，对于后端私有网络VPC中的ECS，ECS是不具备主动出去访问的能力。


注意看我如下的流量走向示意图，SLB到ECS这段，因为在阿里云内部，我们会选择在SLB上设置后端监听ECS一定是内网IP处于对。这样同时也可以保证安全。





故根据以上的判断如下：

1. 在SLB中的ECS是无法主动对外访问ISP资源，只能通过其他方式去实现。可以这样理解。
2.，SLB只做了DNAT的功能，SNAT的功能他不负责，这个在传统的F5设备上其实是可以做的，这一点要注意。

3. 所以要找到一个可以解决SNAT的产品，NAT网关就是一种，当然也可以利用ECS去自建iptables去解决，只需在VPC内把缺省流量扔到对应的主机上即可。

在得知客户说数据库拆分和文件存储不可拆分时候，我倒是一点都不担心，因为在做过一些系统集成单子的售前都明白，在系统架构中，数据库调用也都是依靠IP地址，文件存储是依靠路径。只是以往我们放在一台设备上，就无需考虑这些事情。

关键点一：

这里是帮助客户说服软件提供商，拆分的事情也可以做的，不是不能做。所以除了你要了解一些系统底层常规的结构之外，还要清楚一些拆分后给软件开发（程序员）带来的问题。

所以我们与对方的程序员工程师进行了一通电话沟通，并进行了详细的“技术实现推演“，在大概30分钟左右的沟通后，显然对方已经败下阵来。认可了我的方案提议。

关键点二：

大家注意，这里我解决的不是这个技术实现问题，是解决了目前这个客户和软件商之间的问题。相当于你可以理解，我是甲方的工程师，我代替甲方去“challenge”软件提供商。那换来的自然是客户的信任和好感。所以大家在后面支持客户上云时候，没条件也要去想办法创造条件去弄清楚客户的整个IT架构中的组织架构。这个对于后期开展工作非常重要！！！注意

比如：有多少个软件供应商、有哪些运维人员、多少人是外包的等等。

关键点三：

解决了技术问题，解决了商务问题，那还有什么可以说的呢。当然有的说，这个时候就要问客户的项目预计上线时间、二期扩容计划、整体项目预算大概在多少数量。——————这一点为什么要问，大家自己体会吧，有时候感觉自己太白话也不好。

然后，因为我个人不抽烟，来客户公司前，看见客户在抽烟。所以就在提议结束的时候，让销售陪客户出去抽抽烟，瞎聊聊。我留下来整理下信息。至此第一次拜访结束。



第三次客户来我们公司洽谈-【方案计划实施阶段】
在第一次会议后，我们将相关资源配置报价方案给到了客户后，客户主动约到我们公司详细谈方案价格方面的事情。


在来了后，我们直接进入到商务合同的确认事宜，所以我给上次拜访下了一个成功的结论。

这里，大家应该很清楚，基本上这个项目已经八九不离十了，所以这里只要保持好标准的推进节奏即可，无需担心丢单的问题了。

不过在这里同样也出现了一些小问题，比如客户对云上的产品不熟悉，就会出现各种部署细节上的一些疑问。所以这里需要扮演原厂的工程师提供一些支持，这个对于售前的能力考验很大，因为售前一般都会比较偏框架的设计，很难有心思去关注到实施细节上。


例如：
1. SLB上的会话保持怎么做？它四层转发和七层转发是否可以共存。
2. ECS部署后，如何快速起一个http服务测试SLB的效果。
3. RDS上如何连接并导入demo-DB进行测试。
4. 对于测试和验证是否有详细的测试报告。
5. 。。。

例如：SLB如何配置，如下图的操作截图。




注意这里！！！！如果一个架构师仅仅是做好技术解决方案一定是不行，要善于发现客户的“痛”！！


其实，当客户问到我这些问题的时候，我第一时间想到的不是如何回答！！！而是立刻想到了一问题，客户可能遭遇到了来自公司高层的一些“challenge”，因为客户对公司IT整体负责，那自然会涉及到像“述标”的情况。我想到是客户遭遇到这些，自己无法很快的顶过去。所以此时我已经做好持久解决和复习学习的心里准备。


    一、是复习自己对产品的认知
    二、是帮助客户在内部站住脚跟
    三、是引导客户在哪里可以找到解决文档方面的工作的案例文档


好了，今天就暂时先分享到这里，因为一篇好的文章，往往几千字是说不完的。所以我后面会继续分享，分成【业务上线的项目管控与跟进】等部分去展开。期待各位读者持续关注本博客。


目前正在进行对一些传统IDC的方案向云计算方面转化，后面会持续分享项目工作心得。感谢各位的细细评味。


我的初心一直是这样，我在尝试着真诚地描述自己遇到的问题和解决经历。若你也是一个在技术路上坚持的人儿，那就一起加油，一起努力。
                                    ———来自一个正在努力读书的网工Allen

QQ:549675970
QZONE:http://user.qzone.qq.com/549675970
E-mail：
          549675970@qq.com
          allen_junjun@hotmail.com
人生格言：越努力、越幸运