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

自上次更新博客有些日子了，近期一直在忙碌着，所谓一天做技术，无时无刻都在做技术。可能现在更多在往前靠了，越来越多的接近”前方”业务。把原来的偏技术的重心放在了如何搞定客户上。。。。若大家不喜欢笔者风格，就当个文明的过客。谢啦！！

 

前阵子老板还有些担心，我会不会想转销售，，这个嘛，，萝卜白菜各有所。。。不过可能未来的某一天我会站在业务的角度，摇身一变成为真正的拥有很强技术能力的”销售”。呵!

 

老板也说看看能否把以前的兄弟再叫回来，说到底这些确实就是我们这里成长起来的，他懂得付出，也懂得抗压更懂得服务这件事情到底怎么做!！！我随后电话拨打了以前以前战斗在前线的兄弟，寒暄几句后，发现他们在现在的位置比以前开心且更专注的做自己认可的事情.然后最后再次寒暄几句后挂断了。”祝福兄弟在现在位置上愈发强大”！！！

 

这好比男人和女人之间的奇妙情愫一样。当年在一起很努力很拼命受尽了苦难，但结果却并不怎么美好。但当他们换了对象换了环境，却一切都在往好的方向发展，他(她)享受着正在发生的一切事情.所以除了祝福没有其他了。

 

好了,,,,,每次写个博客都非要讲两句感情的心灵路程。是回忆也是坚持更是初心。

 

 

上菜上菜上菜!!!!

今天给大家分享下近期在项目中如何进一步突破客户的案例。并且如何让客户相信你，相信你的公司，为你的服务合同买单!!

 

--------------五个重点--------------

(PS:上次三个重点,这一次补充一条,但绝对不可重复)

第一、以客户和客户的实际业务为中心思考

第二、先发动一切可以调动的资源解决目前客户遇到的问题,不要提问和把流程复杂化

第三、做一个技术权威,不要让自己看起来很”弱”

第四、和sales要配合好,让客户在内部自上而下的推进

第五、把客户的工作当成自己的工作.

 

关键词:运维流程+技术专家+开拓视野+团队构成+业务健康+发现问题+在一起

 

这里仍然唠叨一句，为了保护好客户的权益，文章中会有相应的和谐。

 

背景介绍:

项目为某线下支付的新兴项目

目前项目状态：已经启动且在运营当中

项目契机：在2017年7月底，该客户出现一次严重的业务故障,造成的直接损失达到七位数。也就是这个时间节点我们的sales和我进去了。

 

第一个重点探讨的话题：救火队员,不仅仅只是救火这么简单--------------

读过我前面的一些分享的一些案例后，应该都很明白我属于偏业务和全局掌控的架构者。所有的事情应该不会离我所设想的目标差得很过分，因为我在上面注入了大量的精力和心血。

 

场景一：

当天，客户出现问题了，我们的售后专家团队也称云服务团队即刻参与到了紧急处理当中，过程中和客户出现了一些意见不一致的”冲突”。但好在故障问题控制住了，随后云服务团队的经理-Sunny call我。。。。并告知次日建议去拜访的想法，我们很快达成了一致。并在当晚再次复盘整起故障的root cause和处理过程。

接着，我于当晚准备了一些材料，大家可以理解为show肌肉的ppt还有故障处理的关键过程的记录。

 

场景二：

次日我与sales早早到达客户的楼下，找到客户公司,也没多客气寒暄几句。直接就进入正题---开会!!!

议题1：根本原因是什么，接下来怎么预防此类故障？

议题2：未来的建设上的一些想法

议题3：另外一个项目系统的上线前的想法

介绍下，当天在场的人员：

    客户老板、客户研发老大、客户运维、还有几名研发人员在场,然后我和我们的sales。

大家应该能猜到，会议室怎么进行的。我在控制着全场的情况，围绕着三个议题展开了俩个小时左右的讨论。这里主要说下议题1和2。

 

目前客户的逻辑拓扑结构:

典型的“能用一台机器搞定的绝不用两台机器搞定”思路。切记这个思路在云计算中是非常致命的，因为迟早有一天当资源不够引发的一系列的宕机问题。这就是这个思路导致的最大祸首。

用量解决/业务模块剥离独立等,这些后面引申出来的一个术语”微服务”，有兴趣大家去查资料。打碎风险，系统之间完全独立运行，内部灾难发生互不影响。整个业务系统全局使用API做服务寻址。各个模块在组织上有着独立的组织小组维护。这样就做到了业务逻辑结构，团队组建的风险控制。

PS:此观点为个人主观观点,大家认可与否都无关系。这个致命思路的分析，我放到下回分享

 

业务逻辑非常复杂(内容和谐过)：

 

所以一眼看过去，纯IAAS的资源配备上明显是有问题的。而且完全依托的是公有云的平台，这里使用的阿里云。

而且犯了一个大错误，在云计算的平台上，追求高配!!!!!(一台解决所有,甚至代码托管都复用了!!!!)

读过我前面文章的都或多或少对云计算有不同程度上的理解。优点缺点都有.但面对很多互联网公司。今天过了明天还在不在都不一定的公司，那一定是选择一个”即开即用”的平台会更好一点。所以公有云平台则是最佳的选择。

 

没有传统IT重资产的风险嘛.这个扯远了,回来接着讲资源配置上的错误.

 

这里举个已经被老大们经常拿来讲的例子.

10000台服务器运行一个小时＝一台服务器运行10000个小时

这个明显是个错误的观点。至于为什么是错误的？我下回详细写篇方法论和大家一起探讨下这个例子。反正记住当下的挑战是”变化莫测的业务需求”就行。

 

追求单台高配机器解决业务的厚重问题，这个在云计算的大势下是极其错误的。因为我们常常说高可用/高可靠/单点故障。

以前我聊单点故障时经常说：”品字型结构部署,所有设备均需要用俩台”。这个观念是目前在很多重大事故当中总结下来的。。(做过银行项目的工程师都应该知道冗余（HA）和切换时长（RTO）的重要性)。单点带来故障完全不可想象。好比如下这种拓扑图一样：

PS:漏洞百出，运营过IDC的大网，做过客户的核心网络组建的人员都会明白，带宽容量扩容平滑度等等。

潜在问题：

------------我要扩容怎么办？

企业IT：找供应商写方案申请预算。

我：起码俩三个月过去了，到那时候项目都不用上了，这趟车赶不上就不要做了！！！

企业IT：现在这么大的结构，各种调试都有风险，我们也不专业,还是让供应商来评估一下最好

我：。。。。。

我：那如果其中一台防火墙出问题，你是不是得把所有的供应商都叫过来，让他们来解决？

企业IT：对呀，就是这么做的。

我：。。。。。

PS：这种显现屡见不鲜，最后我选择了承认和认可。因为有些公司真的就是这样。难怪IT部门一直被压着，沦为成本部门！！！！！给大家一个场景，大家自己去体会吧。

 

回来接着聊~~~~~

在深入的和客户的研发老大探讨后，确认目前业务架构还没到微服务的境地，但已经实现无状态化(restful)。我给出了如下结论：IAAS资源需要立刻进行进行增加调整。

1、SLB的支撑并发量需要提升—规格的调整

2、ECS的数量至少≥4---数量的增加

3、Redis做session share可以考虑需要增加查询缓存在里面

4、文件存储需统一调整为NAS共享文件存储

 

场景三:

此刻客户老板进行了一些对话，也比较客观的讨论了关于运维和研发的分工问题。研发团队在交付产品时仅对功能负责，而运维团队是对稳定负责。中间确实一个可以连接运维和开发的角色。使得目前的产品迭代在一个不稳定的方向上越走越远，而且目前确认下来的信息，安全方面完全没考虑，系统安全的问题形势非常严峻。

随时都可能被黑。再回到故障事件的预判和防范。目前看下来,基本没有任何措施。永远是在业务出现问题才知道怎么出问题了！！所以我给出了如下结论：

1、立刻将监控规则和短信预警等规则梳理并确认在紧急情况下可用

2、安全问题目前必须直面解决，不可心存侥幸

3、系统的可用性,每周的监控数据复盘，业务连续性指标的控制都需要立刻制定规范

4、关于内部人员系统权限问题也需要解决(为什么说这个呢,因为客户公司人员流动性较大，在谈话中得知)

 

随后算是中场休息，我没出去一直在会议室整理今天谈话中的信息。sales出去和客户老板，研发老大抽烟休息。

 

回来后,我们进行了第二层具体做事的沟通。即:接下来该怎么进行?

我分别针对这个议题提出了如下工作开展建议：

1、架构优化改造，当场拿出参考方案进行了一一讲解，这个环节我最擅长了。就不多解释那么多为什么了。

 

2、IAAS资源调整的配置报价方案，因为要加机器，所以要替客户考虑如何花钱。

 

3、各种运维问题的排雷和规范梳理，这个主要是考虑到客户自身对运维没有什么概念，所以要帮助客户在这个层面做一些”赋能”

 

4、目前业务系统的后台测试账号，以及目前开发上线后的问题清单。为什么要这个？因为客户目前没有专职做预发布测试的部门和人员。一般是研发老大兼着。所以解决这个问题是站在客户研发老大角度去说的，当然，要想解决这个问题。得先彻底了解客户业务的平台情况，盈利模型，后台设计逻辑。

 

5、Sales在这期间并行准备一份服务合同。在公司层面吧公对公的把所有的咨询/服务等授权走完。

 

*6、替客户写一份招聘JD，这个是研发老大私底下找我说的。至于原因嘛，大家自己去想！！

 

至此，第一次会面顺利结束。对方的研发老大硬留了我们在楼下的餐厅吃了顿午饭才走的。这也是以上第六点的来源。期间客户研发老大聊很多个人的压力，责任，有心无力以及业绩压力。同样问了我很多关于运维的话题`````(这里就省略几万字)。

我就单独强调这一句话:”赶紧把运维全部外包,责任我来帮你扛!”看清楚问题和人员在组织中的站位，这个非常重要！！！若你是正在前往售前的路上，务必要把这个能力建设起来。当然，你面对的用户都是国企，那就当我没说。

 

--------------------

回公司的路上，sales跟我说：”今天状态很对，客户老板非常认可你刚刚说的问题，人员问题，运维风险，业务指标等，接下来的工作会相当顺利”

--------------------

 

我后来发现，我聊起天来，我自己都怕。。真的是太唠叨了。不过还算实在实用不虚，客户认可。

 

如大家所料，后来的一个月里，我几乎每周都有一到两天在半夜和客户一起与故障”斗智斗勇”。不过好在客户信任我，一年差不多10W的服务费用的合同真的是秒签，半年几万块的安全产品在我提出方案之后说买就买了。这里我再唠叨一句，只有和客户一直站在前线,共同面对困难的人，才真的有机会获得客户的信任和支持。否则一切都是”虚”。空有一副强调但不能真正转换价值的，这里的价值我说的是企业盈利的价值。

再到后面被应用层CC***导致的问题，渐渐没了。逐渐浮出水面的问题就是应用自身的问题。比如：

1、DB的性能优化

2、nginx的调优

3、linux的内核优化的问题

这个时候，我很清楚自己肯定能力不行了，所以补充&提升自己，同时还要借助我们团队力量去搞定这些问题，当然不能把自己的事情当成最重要的事情来做，所以务必有计划有条理去推进所有事件。

 

于是我制定了一系列的时间日程，每周有序的进行。在第一周云服务的经理sunny收到协作请求后和我非常效率的制定了关于各个中间件的排查思路。这里晒一下关于linux和nginx的内核调优的列表：

PS：至于是否可以共享，视大家留言情况并征得公司云服务团队统一后方可共享给大家。

 

接下来的故事发展情况，大家应该能想象的到。在客户面前。我(架构师)就是服务的权威、技术的权威、能解决问题的人。任何事情对我都毫无保留，信任的程度完全不下于一个同等级的同事。

这样就让我在项目中如鱼得水，很多工作在客户侧都是非常的顺利开展。

 

本文第一波重点来了,这里再小小的总结下：

做客户，做服务，做乙方，始终都要保持好一下三种心态：

一、解决问题是第一步

二、去经营项目这个思路非常的重要也是最关键的第二步,这个比较个性化一点见仁见智

三、第三步和项目中的客户一起成长

我们现在有很多售前容易潜意识看当前的体量去对客户进行分类，这一点我不认可，因为互联网公司不要去按体量分类，也不要嫌项目体量小，因为在上海这个地方，任何一家小公司都可能在半年后变成一家千万级别的大公司，所以不要去忽略任何一家有潜质的客户(当然,你得有业务的思维和简单的分辨客户业务前景的能力)。

 

如我所料，在我进入后，客户的消费情况直线上升，这就是胜利的第一步。。。

 

补充说明,客户的业务属于爆发式，在某一个特定时间有超大的需求。比如下图：

这个场景，你就可以和双十一、双十二、十一国庆。秒杀活动联系在一起。所以回到云计算的优势，这些场景就是优势，详细的讨论放到另外一篇中讨论。

 

第二个话题:业务系统出现性能故障,该怎么办?

起先我们的云服务团队定位到了问题在数据库层面，说句实在,在第一步胜利后的一个月后，我其实相当崩溃，因为业务系统的接二连三的出现瓶颈问题。我一个架构师。既不懂代码也不太懂系统，在这个期间，我疯狂的找资料学习各种程序设计，业务架构等。。。

 

直到有一天，我参透了!!!!!是不是有点戏剧性，我不是说我都学会了，我突然想起来我们公司有好多研发大神呢，我自己一个人在这里瞎搞什么啊，我把问题收集好，利用前面学习的理解情况和跟客户对话的内容梳理后去找研发帮助我不就行了。。。。我就突然一下找到了我出口，整个人一周都像打了鸡血一样，到处跑，到处学习和请教。

 

(稍微省略了一些问题搜集的过程```````)

 

由于客户的信任我拿到了客户的表结构，sql的语句，每个属性的解释以及sql语句执行后结果返回。

相关的排查截图我这里就省略，我这里用一页PPT解释下目前应用的过程的问题。。

 

类似阿里云-态势感知这样的dashboard的页面一样，他有很多需要实时计算和交互的内容，并且基本上都是查询类的请求在和后台通信。如下图：

 

真实的实际情况的数据压力形成过程的简略图：

注释：

无限的循坏下去，数据一致在被增加查询请求，但之前单一用户的秒并发查询还没完成，接着第二第三接二连三的来了，导致持续上升，查询效率变低。。。。直到数据库被耗死。

 

再加一张图：

 

前方高能注意！！！！本文最重要的重点，请仔细研读！！

在经过与研发同事沟通与分析后，通过执行的语句情况和记录。我们完全的还原了每个用户的使用习惯和场景。

1、打开首页是自动跳转到Dashboard----------压力来源的最大部分

2、每个用户经常查询昨天一阵天的收款情况--------我懂,挣了多少钱嘛,换我也一样

3、频繁查询一周左右的数据和前几周作比较------我懂,因为要做业务分析

4、查总收款-------…..不补充了,大家自己去体会.

PS:这一点真的强，我也是第一次这么亲身感触到,研发思维逻辑的强大之处!!!!

 

最后我也反复对照了历史数据并和客户取得联系，确认很多故障时间都和我判断的上下班拉数据的场景是一模一样的。所以这更加可以确认，我正在走在正确的分析路上。随后我再次与研发的同事花了十分钟左右，分析并给出了应对方法：

1、将每天这样的查询请求，在过了凌晨12点之后，找一个时间点进行”预先计算好”，单独保存在一张表中供客户次日登录调用---------减少语句的条件和峰值，因为是已经提前算好的，所以并没有太多的压力。

2、把结果做到我们整体架构中的缓存中去------预先缓存好，不进数据库，进一步减轻数据每天”早高峰”的查询压力

PS：这里大家一定会问，客户有redis为什么他没做这个事情。回答:redis只做了一个session共享其他的没了。

3、把数据读写分离做了---------都是查询为什么不做?原因很简单，客户就没想到过这个。

 

我随后(大概)快下班时间约了对方的研发老大，开始了一列的探讨.并成功的确认了目前的这个问题。

-----核心问题:用户首页dashboard，没有做缓存，全部为实时动态查询计算设计

(在大概30-45分钟的一系列电话沟通，客户立刻决定今晚做调整)不过随后我又问了，怎之前你没告诉我，代码逻辑是这样的。

客户:”我也不清楚,其实!!还是得靠你们来发现啊”

 

这句话的意思，我稍微带有一点主观骄傲的心态解读下------------

我需要你们这样的公司来帮助我，因为我其实也很难发现自身的问题。前阵子辛苦你了，一直因为这个事情半夜帮忙分析，帮忙搞，毕竟这个圈子很大，我们人员的能力也在爬坡阶段，所以还有很多问题需要你们帮忙担待下。

 

(本文中间省略了很多做客户服务主动性的内容在里面，因为一旦写过程,写个三万字一点都不夸张，所以本文是稍作裁剪后的输出，前面的过程是非常的细节)因为首次印象和工作效率非常重要。

 

最后的结果我就不补充了，不过还是截一张图，在业务优化之后，我们的数据的监控似乎变成了一个”安静的小孩”再也没闹过。至此我再一次成功赢得了客户的认可，也成功引导客户为我们提供的服务买单。

 

最后感觉突然来了，也趁着最近老板传道受业解惑的期间，学习到的新的行业语言。

这段时间，一直在努力学习，同时工作任务也相当多。很难有时间静下来写一点心得和总结，不过每每写一写就发现自己有更多需要补充的知识，大概这就是我坚持学习的源泉和初心。

 

努力，奋斗!!!

                                 ——————来自一个正处于努力路上越走越远的网工Allen

 

QQ:549675970

Wechat：Johnny_JunJun

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

E-mail：

          549675970@qq.com

          allen_junjun@hotmail.com

 

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

 

 

 

 

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