一位架构师用服务打动客户的故事之五

有接近小四个月没更新客户案例的分析了，脱更一直挺严重了，讲真“自己也挺无奈的”，这一次带来一个传统IDC机房整体迁移上云（AWS）的案例的剖析。

---

有很多读者也是刚刚从后端“运维、售后”转到前端“售前、销售”的，所以我也很希望我的经历能帮助到你们一些。

我是一直很相信“沟通”+“技术”是可以很好结合在一起的，在行业内，我们称之为“技术顾问式销售”、“销售工程师”等。因为如果你有很牛的技术底蕴，却没有team的文化，良好的沟通能力，你没办法把自己、自己的公司很好的表达出来。或许除了研发是一个很好“归宿”之外，其他我实在想不到了。

---

别的感情啊啥的就不废话了，直接上菜。：）

客户背景：
用户的IDC服务器资源在DC运行平均超过五年，面临重新采购新服务器的“巨额”一次性成本投入。

去年几次重大的事件的列出：
1）某月存储AC主控制器出现异常，业务暂没受到影响，但存储完全“脱管”，后经产商千万DC修复后完成。期间遇到两次业务的“新增”被搁置。
2）因软件商误操作，执行了一段删除主数据中一张XX表。后经确认数据没有备份，而没有执行备份策略的原因是因为磁盘空间不足
3）oracle数据库硬件服务器出现硬件故障，主节点离线。
4）金蝶财务软件系统出现故障，中断12小时以上

架构师旁白：
虽然过程较为波折，但想想还是比较后怕的~~~~

补充下，我们每年都会有非常详细的变更事件记录（这应该是做云计算服务公司的基本素质），类似如下这种（IDC）：

---

写在前面

---

因为该客户一直是我们的用户，我们在续约前两个月的回访中，除了交流全年的变更事件外，我们也准备了关于混合云的架构的topic与客户探讨下云计算的内容。

架构师旁白：
有时候老客户反而不好伺候，为什么？因为留给时间来证明的内容，就是你之前承诺的内容。如果有遗漏或者故障事件发生，这个对于刚步入售前的工程师来讲多少有些棘手。
这一次的汇报，对于续约来讲是成功的，对于上云来讲是失败的。客户对于云的理解和认可度并不高，认为还是物理机简单。并抛出了好几个问题：
1） 上云，我oracle的license会不会需要单独新购
2） 业务系统使用的是比较老的版本，上云后会不会不兼容等问题
3） 云上的每年成本预估大概有多少
4） 云上的数据备份、安全等是怎么设计的。
5） 。。。。

---

对于个人来讲这些话题基本每个用户都会提到，所以还是相对笃定，可能有些成本数字，产商的对比还是要拿出来整理成PPT来面向用户汇报。

---

偶尔看过我博客的读者都应该比较了解，我所在的公司是什么公有云都服务和支持的。因为是家中立的云服务商（MSP）。

这一次，因为客户的背景是外企性质，在交谈中用户有意倾向于AWS（亚马逊），所以我们就以AWS的技术方案为前提提交了技术方案（包含迁移、云上架构、安全架构、持续运维服务构成）

AWS的服务是相当全的（虽然在国内产品寥寥无几），对于熟悉了国内公有云的工程师来讲，自己需要做的转变还是比较大的。~因为思考方式，要变一变，国内的公有云好在符合国人的思路和更加服务化的console界面，但是aws就另说了，完全是工程师的公有云，而且有更新的概念“基础架构即代码”，这个留在以后分享。可谓是学习成本、技术门槛都比较高。

这一次的客户案例中，我们的整体PPT风格使用了AWS的风格，类似如下：

---

---

真是有种天生骄傲的感觉，毕竟全球公有云领跑者，在国内的公有云的产品中多少有一些AWS的影子。
这里必须支持下阿里云和腾讯云、华为云，一直在稳稳的追赶中。文章是在国庆期间写的，所以这个普天同庆的日子里。贴一张上海南京西路，军人的无私付出：

---

第二次上门拜访记录

---

一周后，我们带好技术方案、方案资源配置价格，前往客户现场做了第二次汇报。
技术等相关方案核心问题：
1）oracle上云的license问题
2）oralce 上云的高可用保证（原IDC是oracle-rac部署形式）
3）Microsoft sql server 的license问题
4）MS sql的高可用保证（原IDC是单机部署）
5）迁移所带来的停机时间设计
6）云运维服务和IDC运维服务的区别宣讲
7）上云前后的收益对比（主要体现在成本支出上）

今天的分享内容挑其中几个关键的问题做详细汇报（谈不上分享了，技术问题一直是市面上那几种成熟，主要是售前的沟通策略和PPT的内容重心）

---

如果希望能学到一些技术，通过博客内容的话，那可能要等等了，国内因为社区太多，彼此的博客都习惯于各种抄（爬虫），技术博客目前都存在自己的私人电脑中，我会一点一点的同步出来。刚在CTO发的文章，大概一个小时后在其他地方就有完全一样的文章，所以这一次我把笔者的交流方式留在文章中间，至少读到这里的伙伴是真正在看文章的伙伴。

---

QQ:549675970

Wechat：

Johnny_JunJun

E-mail：

      allen_junjun@hotmail.com

人生格言：越努力、越幸运

---

解决方案中的成本部分（核心）

云计算带来最大的转变就是把一次性的投入变成了按需投入，加上客户目前公司整体运营背景，确实在进行“开源节流”、“缩减对应人员职位重叠的编制”、“后端支撑团队进入轻运营”。
当看到这一点，确实跟我之前想的重点不谋而合，故客户在第一次拜访中并没有直接否定云计算的方案，而是持观望态度，所以这第二次的汇报尤为重要。

成本方案测算的过程中：
我与sales计算了一次性投入和纯公有云每年的投入数字，如我所料想，IDC 超出 云计算很多。加上沿用过去的云服务体系（甚至涨价都不存在问题），我这里列出非实际数字，方便大家有个概念：

---

PS：分别为纯IDC方案、AWS方案、混合云架构方案。

---

成本部分的总结：
1）AWS整体上云成本性价比会高于纯物理和混合云。
2）License是否需要额外新购的评估中：确认了oracle、mssql的许可证只要保证版本号一致，我更换运行环境不会产生额外新购的成本（预估在12W左右）
3）Windows操作系统的licnese是否新购：
客户原来的系统都是运行在2003的系统行的，非常老旧。我们也在此次上云方案中提出了升级2008/2012的方案。我料想“客户就会问，系统要正版的，是否要单独购买正版授权”，这一点我也会给客户解释，公有云的OS（windows正版授权），都是包含在单个实例购买的费用里面，并不会需要额外再次购买。开通即正版
另外，我们将部分前端web应用从windows环境改造成了linux的环境。

最终拜访的效果：成本测算客户90%以上已认可，有一些同产商的对比需要补充。

---

客户提问一 ：

这里会有读者问了，

客户虽然倾向AWS但毕竟在国内仍然是阿里云、腾讯云占大头。而且他们的成本相对于AWS来说，具有绝对的碾压优势。技术实力目前看来也不会落后很大一个差别。而且国内的AWS很多安全产品、PAAS产品都没有，阿里云、腾讯云也具备拿下客户的能力！为什么不考虑它们呢？

---

笔者回复~是的，这一点也没错，但是我想说的是，这属于纯内部采购项目，不会有招标一说，加上客户基础在这里，我们可谓几乎没有对手，而且对于我们云服务产商来说“资源对我们来讲本身就接近没有利润”，所以用任何一家我都支持，也不会有引导性的技术方案和沟通策略，客户说什么就是什么，整体 基调“客户说了算”

读者又说，你还是没有正面回答我的问题？

~好吧，我将客户原话大致意思复述一遍，让各位更为了解下客户自身所考虑的地方。
~国内的公有云厂商会默认在服务器中内置安全服务的agent的组件，而AWS没有
~阿里云是国内第一个做去IOE（IBM、Oracle、EMC）的产商、腾讯云相对理智一些，至少云产品中有单独的云上oracle一体机解决方案（类似黑石），客户有Oracle的环境，相反AWS（中国）云平台原生支持RDS for oracle，console操作截图如下：

---

~国内的比较大的云都出现过人为误操作导致业务宕机、数据丢失的事情。外企性质客户对此很关注，加上国内的公关都相对比较“避重就轻”，很少愿意主动承认错误并完全透明的复盘整个过程，加上公有云的SLA时间保证没有AWS好，参考如下：

PS：具体的产商名字我先隐去，但是这个都是对外可以查询到的，大家可以放心去查询即可

---

~若真出现平台的故障，用户获得的赔偿在国内基本都是“代金券”、“服务器运行时长”，而国外Azure、Aws是直接赔偿现金，这也许是国外公有云厂商的吸引CIO、CFO、CEO的地方，“契约精神”

---

笔者旁白：
我们确实还离别人还有一段距离，但这不必担心，我一直相信阿里云、腾讯云、华为云、京东云、滴滴云、美团云、网易云、金山云、×××、Ucloud、紫光云这么多云，势必能奋起直追。我们这些做技术的工程师，虽然有能力看到全球顶尖的企业以及他的技术，但如果祖国哪天需要我，我一定会奋不顾身的为自己祖国的技术创新拼搏。

---

我是中国人，我爱我的祖国~：）

---

有点小激动，每次心念祖国的时候

---

技术部分

技术上云方案评估（与云运维团队一起Brianstorm）

1）因为AWS中国云上产品较少并重新check了全年oracle的监控数据（压力极小），故我们在oracle部署上确认使用oracle-DG方式，整体部署难度降低不少，架构图参考如下：

PS：AWS oracle DG 官方参考文档：https://docs.aws.amazon.com/zh_cn/quickstart/latest/oracle-database/data-guard.html

---

2）Mssql的原先是单机，在云上部署always-on即可，算是技术架构上的升级
架构图参考如下：

PS：AWS mssql always-on官方参考文档：https://docs.aws.amazon.com/zh_cn/quickstart/latest/sql/welcome.html

---

3）此次方案设计完全遵循AWS最佳实践（多Az、IAM、数据加密等），文档非常多，学习起来确实很值得。工程师充电必备~~~
https://amazonaws-china.com/cn/architecture/well-architected/
IAAS部分架构图如下所示：

PS：业务架构图就不分享了，需要和谐的内容太多。~偷个懒…

---

上云收益（文档精华内容，请细读）

这部分接上以上两部分展开，相对会比较务虚，但确实很有说服力，我是从这几个话题展开的。
1）将自身系统上云，在公司层面，使用云计算来为自身公司内部提供支撑是一件非常值得兴奋的事情，这个尤其在传统企业正在寻求转型过程中的效果最为明显。
2）不用再为设备物理损坏而担心业务故障，服务可用时间指标可用优化的更好更高
3）资源可用更合理的被“掌控”，通过资源使用情况合理对主机进行季度或半年为周期单位的降配或升配
4）数据备份不用再担心硬件资源不够，避免导致预先制定好的备份策略无法得到执行。
5）对于云服务团队，则可以将重心更好的放在业务架构优化、DB性能优化上，无需再花精力对硬件的故障预判和风险预估。
6）。。。。。等，
PS：围绕比较事务性的传统架构中的问题就行逐一探讨~~~

---

架构师旁白：
因为项目中用户对成本非常关注，所以这里探讨一个关于一次性采购和上云的成本的在五年/十年的分析对比，不论是站在上云的角度，还是驻守传统物理组网的角度，本质上双方并没有直接的冲突，只是在国内因为竞争激烈，引发出了更多平行的产商对比，还有物理和云计算的对比，如大家所料所看，网络上到处弥漫着略带有主观意志的看法。

---

所以，这里我也抒发下个人所谓的“客观”看法，仅供各位参考，不理解也不要紧，毕竟我现在属于云计算的站位，多少会有些“端不平”的情况在，所以看看足矣。

---

传统架构通用考虑因素：
数据中心、机柜租用、固定带宽租用、硬件维保服务、一次性硬件投入（含firewall、loading-balancer、switch、server、bastionserver）、驻场运维工程、网络/系统/DBA工程师

云计算通用考虑因素：
计算资源（含安全产品）全部按需购买，网络/系统/DBA工程师

---

成本配置场景一：三级信息等级保护（仅供参考）

---

---

---

我们来以五年为一个周期看看趋势图来直观的看下：

---

有人要讲了，我用3W的waf照样能解决评测的问题。你为何写12多W的产品~~~~
1）这里面，我还没有计算最重的部分——人工（即：各种工程师资源）
2）传统的机柜、带宽等成本“大头”，我也在此场景中也选择忽略了。

结论：至少五年内，云计算在等保三的场景中，成本有具有非常大的成本优势。

~有想了解等保三的内容的，尤其是整体过程细节，我会择日找时间写一篇分享出来~~

---

**敲黑板，划重点~~~

场景二：大型集团应用（门户、电商、支付、交互式购物）等应用上云成本测算【保留部分等保3产品】**

---

---

我们来以趋势图来直观的看下（建议放大看）：

---

---

~我忽略非常多存在歧义的焦点（比如；时间成本、故障处理的成本），所以仅仅在一个静态的情况下，动态去调整了可预见的人员、资源的配置成本。所以这份数据仅供参考，不具备任何实际数据价值。

---

注释：
静态，即指：不考虑业务的增长，完全以第一年的整体项目的配置去评估次年
动态，即指：会考虑业务的增加与缩减，动态去调整人力成本、资源配置成本

---

结论：
在静态数据预测对比情况下，在接近第四年有一次数据交叉和第七年时第二次交叉。
在动态数据预测对比情况下，第接近七年的时候会有一次交叉。

---

若完全忽略业务运营数据、忽略意外硬件故障时间、忽略DDOS***，完全把思考的宽度放在成本投入上去看，长期来看（10年为一个周期）。理论情况前提下，IDC的投入会比云计算的投入来的划算一些。

但我们将十年每年的投入总计进行“横向”汇总如下
数据源：

---

结论：
云计算无论是静态还是动态去测算投入成本，云计算最终的投入都始终会比IDC的投入要低一个数量级。

---

好，回到项目中来，第二次汇报结束。客户追加了几个问题，如下：

1）为什么选择AWS？和其他公有云的对比矩阵图
2）上云前后的物理硬件license的变动（类似软件清单的对比）
3）所有应用迁移的实施的POC方案的“台面交流”
4）迁移实施计划补充
5）报价方案需要再优化下格式、分类以及部分机器的配置增加减。

---

---

架构师旁白：
对于这一次交流，我是很满意的。因为基本已经平稳度过了“售前”阶段的工作了，所以这一次提到的内容，都是一些小补充。后面就靠销售最后的商务能力了。

---

我们两人离开客户公司，销售便告知稳了。不用担心，节后来签单~~~
过节期间，我将补充好的方案与内容发给了用户，全部通过了客户的要求，上班第一天销售就告诉我，签合同了。至此整体这个项目的一些比较关键的经过我分享完毕了。

---

技术方案&报价方案版本记录：

技术方案版本从1.1到1.8
报价方案版本从1.1到2.1
基本九月下半月就琢磨这个项目了，好事多磨~，这里提一句，对初在售前岗位上的架构师也好、工程师也好。“耐力是基本功、多健身练练跑步：）”，文章中我也留着了个人的联系方式，志同道合的朋友欢迎来交流心得，互相学习互相补充。

---

好了，国庆没回家，在家除了理方案外，写个分享祝大家节日快乐，晚了几天发布，迟到的分享，抱歉抱歉~~

                               ——————一个正在努力转型的工程师

欢迎交流，技术圈子本来就不大：）

转载于:https://blog.51cto.com/allen686/2299120