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

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

有些日子没有整理案例了，回顾了下上次案例分享的日子，已经有将近四个月了。。

~~~~~~~

从开始在51CTO上写架构师服务这个系列后，因为留了联系方式后，有不少志同道合的的朋友留言、加好友对一些特定的场景进行交流，其中个人收获并纠正了不少错误的观点。无论如何还是要谢谢有这么个地方，让我去记录并分享个人的一些经验和心得。

~~~

又脱更这么久了，抱歉抱歉~~~（读者：“信不信我把你按着地上摩擦~~！！”）

最近确实忙着很多连续性的工作，但都不是具体配啥了，让各位失望了~~~：），如我前面几篇文章提到的，确实当“技术方案”推进到一定的阶段后，有很多时候并不会让你接着像以前本地接console、远程SSH去调试了。。（当然你读者要是纯支撑运维部门的一员的话，直接忽略我的观点，：）），那多出来的时间都去干嘛了呢？

很显然是，“设计方案、规划实施交付过程、学习业务、业务运行逻辑、开发调用过程~~”

这不，有一个好的机会遇到了一个全球运动品牌的Top5企业。这个项目由比较幸运的我来配合做了。摆在眼前的挑战是“完全新的公有云环境、新的PAAS特性、新的Docker运行环境、新的交付逻辑以及全英文的沟通环境”。着实让人兴奋~~~，我在官网找个案例讲讲这个项目大概痛点在哪里？如下图所示；

图（一）

如上图所示：

在最右边图上有个不起眼的地方标注了：“OLAY专柜及天猫旗舰店积分权益共享”。现在越来越多的传统零售企业，选择在国内一线TO C/B的电商平台上注册并运营自己的店铺。因为类似阿里巴巴（天猫）这样的平台，已经成为了“国人”不可或缺的购物平台选择，业务上天猫能带来非常多的流量，例如：六一八、双十一、双十二，这也是后面我会谈到的“流量红利”。

类似天猫平台的还有很多，比如苏宁、京东等。而且京东云的也已经在零售行业开始发力。

PS：找个时间我会单独写一篇文章带各位认识下京东的“零售能力”。

但如果我们的零售企业只关注扩大获客渠道，也不是特别妥善的增收的办法。现在的获客成本逐年在增加，企业的获客能力却甚至在倒退，有质量的付费用户群体越来越容易被撬动，这对较传统的企业的冲击是非常强的。        举个具体的例子，比如；我就是一个网购爱好者，我喜欢在网上买东西，但也热爱去实体店体验试穿并购买。以前没有注意“线上和线下的体验”，但后面因线下有库存，线上没有的原因关注到了，我在天猫官方旗舰店铺是已经是V3会员了，但在线上的实体店里，我个人的属性仍然是普通用户。体验特别不好，‘至少我也是V3的会员啊’，怎么一点都不重视我呢？，所以就是哪怕实体店看好了，都不会在实体店下单，会优先考虑在天猫上同款下单~~~

产生这些消费观念的根本原因：

1.天猫有优惠券，买得多优惠的更多。

2.我也不差这么几天，什么时候寄到什么时候穿，时间不是痛点

3.确实和实体店的质量是一样一样的

图（二）

那么说到这里，那么问题&挑战来了！对于已经构建了自己的官方APP、官网的企业这也就会直接导致以下几个问题出来：

1.主站流量被“分割”

quj：客户不在企业官方通道下单，直接在天猫、京东以及苏宁下单。

2.应用去“中心化”严重，全渠道管理难上加难

Allen：企业自身维护的订单系统、分销系统、库存系统、物流配送系统多而管理成本高，再通俗一点，用户数据库就有好几个（比如自己官方一个、天猫一个）。这就是TO C/B其他电商渠道平台带来的平台“数据扭转割裂”的问题

3.管理成本“几何级”上升

Allen：第二点的补充，有部分传统行业是这样应对的。比如用户天猫上下单，确实使用了天猫平台的订单和库存还有会员系统，运行和表现都不错。但是我们的库存订单和物流中心的系统都是在线下，且独立运行的（又或者说是独立的团队支撑），所以这个时候就需要把天猫的订单重新在自己的系统里面再次录入一次。那么怎么解？这里“那就再顾个客服”做这个事情吧。

架构师旁白：

“2C平台到底自建还是用天猫？”

Allen：其实没有绝对的答案，在这个技术驱动业务的时代，本应该“业务数据流汇聚后，集百家之长。而并非绝对要一定选择一边，抛弃另外一侧”。

大致流程如下所示：（不严谨样例）

图（三）

所以，我个人认为，新零售它带来的除了技术的“革命”，还有更重要的侧重点是“打破数据割裂的格局”，在云端更好更快的处理，既而产生“数据价值”。解决“人、订单、物流(车)、库存、直营门店”的运行效率低下的问题。即“新零售”~~~

图（四）

————————

这里推荐一偏运营的书《从互联网+从IT到DT》——阿里巴巴集团。

PS：讲的不错，有务虚也有务实。我虽然是2017年底开始看的，但是已经确认了拥有数据的公司，才能得以更好的生存的论点。

————————

好，不展开了，我们暂且先忽略提到的几个问题，

毕竟我们讨论的是Best Practice，在分析项目进展的过程中，大家要试着设身处地的思考。我分享的目的也是期望引发大家的思考，而不是告诉大家“以后”就这么做~~~~，毕竟有些说法还是比较局限个人且带有一定的主观意识。

这一次这个大企业所面临的业务问题就是天猫旗舰店的会员如何与自己的线下的旗舰店会员系统打通，所以这个就是前面我铺垫这么久的的总结~~~~~

“读者：“真的啰嗦啊，这人~~”：）”

天猫聚石塔官方是有成熟的解决方案——品牌会员中心，如下图所示：

图（五）

用户的收益：

为满足品牌对会员管理的个性化需求，基于会员中心全渠道会员打通的能力为品牌商实现会员注册、会员绑定、积分累计、会员互动、权益兑换等业务流程，并为品牌会员提供数据分析及精准营销的能力。

名词解释：

入驻天猫，需要“入塔”，什么意思？就是要入驻“聚石塔”，现在改名叫：阿里云-零售云。它与传统的阿里共有云（金融云、蚂蚁金融云）都在物理设施上有着完全物理隔离、数据隔离、网络隔离等区别。完全是独立的运营的，但也有一些联系！就是零售云本质上底层使用的就是目前阿里的公有云的那一套技术环境，所以在操作上并无特别大的区别。

补充说明：

当你经营着天猫的旗舰店，天猫（零售云）的数据是有非常严格的数据进出限制。基本可以理解为：“天猫的用户数据，阿里是绝对不允许你拿走的！”，这涉及相当多的数据安全和管控要求，大部分来自于国家的法律监管。

注释：关于零售云（阿里）平台的介绍不放在这一篇里面赘述，各位读者如果有心想去了解下，可以移步Service Questions》的问卷调查，因为是第一次处理这样的文件，所以多少是有点经验不足和一点小兴奋（全英文环境），被打回两次后，终于通过了客户的要求！！

我截部分脱敏问答给大家分享下。

图（十六）

回到技术方案上，第一期如我和老板所料，被打回了。技术细节要调整。原因是：基础资源架构过于多余和服务昂贵。希望将国内阿里云、国外阿里云删减，并剔除部分服务内容。

图（十七）

花了一天时间，技术框架和报价方案调整完毕，第二期技术方案框架：

核心技术匹配：Docker、Proxy反向代理

基础架构业务流梳理：

Tmall————JST————AWS（US）

2）第二期技术报价明细：

IASS资源：

JST：21.1W

云服务：41W

2.1）第二期方案报价总计：62.1W

2.2）第二期方案三年总计：174.3W

注意~！！！方案调整明细如下：

第二次与客户负责人沟通交流，客户部分工程师再次认为有部分安全资源是多余。

第二次删减内容：Waf、态势感知、服务器数量缩减

经过一天调整后，我们随即再次约到客户进行第三期交流资源配备方案：

第三期沟通后，业务流程如下：

Tmall————JST————AWS（US）

3）第二期技术报价明细：

IASS资源：

JST：5.6W

云服务：25W

3.1）第二期方案报价总计：30.6W

3.2）第二期方案三年总计：91.8W

———————————————显然“事不过三”是有道理的，果然到第三期方案的确认，我们达成了共识，并确认技术方案没有其他问题，

整理下这个“一上一下”的落差的过程：

1、第一期方案，我们给出的是最大最理想的方案推荐

2、第二期方案，我们给出了一个合适体量且理想的方案推荐

3、第三期方案，我们给出了最小化上线的方案

注释：

从600W到91.8W这个降幅确实大，但客户说的总归是没错的，所以客户既然这么要求，那作为售前也好、销售也好，满足他，让客户感觉到爽舒服即可。

差不多的进行到这里的时候，客户公司的第四个部门（信息安全）找到我们（前面是基础架构、法务、商务），要求审计我们的信息安全&合规性等情况，第二次审计工作的暴风雨来临了~~

PS：还是一样，我share部分脱敏后的内容。本文旨在分享经验，而不是详细的材料和文档。请各位读者留意，切勿私信找我索要相关文档，因为前面几次的分享出现过很多次这样索要的情况了，很显然这些文档我不能Share的。

1.Have company information security policies been published, approved, communicated and reviewed in the last 12 months?

2.Are passwords for systems containing scoped data hashed or encrypted in storage to protect from unauthorized disclosure?

3.Has the security incident response plan been tested in the last 12 months?

我大概“撸”了一遍后，总结下来问的问题比较通用，我能从文档提交的内容中看出，客户对所有类似我们这类MSP云计算服务提供商都有一套这样的流程去管控，故，我非常放松的去做了这个事情。总计调查130项，每项都需要详细的文档支持。不能简单的回答“yes or no”

这个调查，我看了间接花了我大概12天的时间。最后比较波折的通过了。本来以为结束了，开始部署实施了~~~

结果客户的基础架构架构部门再次找到我们，要我们给客户提供的《XXX-项目零售云平台规划》重新以客户的文档管理结构进行修正，

这是我们提供的文档部分截图如（已和谐）下：

图（十八）

图（十九）

这是客户提供的文档部分格式（已重度和谐）下：

图（二十）

图（二十一）

注释：得到这个消息，我其实是拒绝的。。全新的文档格式、方法论、排版。这一part，我直接跳过过程，总共开销花了5天左右（当然是和其他工作同步进行的）

好了，还有实施进展中的一些技术攻坚，我放到下一次详细分享，这里对今天以上内容总结下架构师在这个项目的核心能力需求：

1.对业务的工作流的了解

2.云平台的实施部署经验、特性和安全合规的理解

3.丰富的文档（表格）制作功底

4.有足够的耐心讲业务实现细节阐述清楚，并形成文档

与甲方用户通过skype开会汇总：            1.技术架构细节：3次（≥60min）

2.堡垒机的使用和灾备方案：2次（≥90min）

3.JST资源配置方案：8次（≥60min）

4.JST资源付款形式：2次（≥30min）

5.信息安全细节：4次（≥60min）

6.JST资源购买方式&付费开通：3次（≥120min）

PS:这些会议都是穿插在整个项目中的，全部由boss、我和我们服务团队共同完成的。

最后补充几个平台监控的知识点：

1.  EWS容器的扩容，只要计算资源（ECS）足够，则可以通过任何ECS去添加到容器中运行，建议启用EWS-LB服务，横向平行添加即可，保证配置文件、版本一致即可。

2.监控对于用户来讲，可能更关心PV、UV等数字。对于运维来讲可能更关心服务运行、ECS的机器运行情况，已经容量等问题。所以运维相对简单（zabbix+wechat）对接即可。或者有自有的其他监控均可，保证响应时效即可。

业务的监控，JST平台已经内置好了，如下图所示：

一个热爱生活的网工努力的故事

——————Allen在路上

QQ:549675970

Wechat：

Johnny_JunJun

QZONE:

http://user.qzone.qq.com/549675970

E-mail：

549675970@qq.com

allen_junjun@hotmail.com

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

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。