记某次APM项目的售前支持

由于此项目是一个集成项目，相当于将之前的若干个网站的首页面统一到一个页面来登录。客户方各个技术负责人不同，所用到的开发技术也不一样，当集成到一起之后，发现首页加载过慢，同时登录过慢的现像。之前单一网站登录需要4～5秒即可。而在集成之后，却需要30～50秒才可以登录。在网络并发数量较大的时候，登录更慢。针对此种现像，开始了本次的售前调研与咨询。

1，了解架构

现在网站大部分是采用LAMP与LNMP两种架构，前端，中台，后台的语言是否一致，线程，进程的配比，代码偏移量这些内容都是需要在前期进行相关的调研的。在与研发沟通的过程中，以上的方面都要以问题的形式精确的描述，才能够得到我们想要的答案，才可以更好的调用我们后方的研发资源。

有的时候，客户方的技术人员与我方技术人员的代码语言不同，相应的逻辑就会有很大的差别。在与对方沟通的过程中，要做到相关的内容最好有截图，文字记录。方便到时与后方研发人员的交流及支持。

2，深入分析

一般在网站登录缓慢，可以通过一些运维工具，或一些抓包工具，分析相关的网络时长或HTTP建链时长。这些的排查方法，一般是先外界，后内部，先循环，后逻辑。总之，就是先易后难。当我们通过抓取全链路时间后分析，发现网络层的时长只有3～4秒，大部分的时间消耗是在代码处理，以及线程处理上。我们就把分析更细化至代码偏移量（不同代码段的运行时长）。

当我们开始进程分析之时，前端需要配合我们做相关操作，当出现登录慢时，我们捕捉到相应的线程，在其后台找相关中间件的消息。突然发现中间件显示有线程锁的标志。后来抓取了相关截图发至后端研发，在研发定位后，才明白，原来所集成后的统一登录网站是属于.net开发，线程锁默认为0.5秒。而这种情况相当于代码在进Session时是要有这一项限制。

3，解决问题

在找到问题之后，剩下的就是解决的方面了。客户方也派来了开发人员，在明确了本项目问题之后，将之前的代码加载机制进行重新改写。直接在前端TCP进程建立之时就开始加载。最终，在进程分析之时，实现了更快加载。实际上这种问题，在我们日常的上网中也很常见，现在的技术一般是用GO语言这种分布式并发加载来解决，或者是本地推送的方式来解决，单一的远端加载模式越来越少。

在解决好本问题之后，再通过前端操作进行全链路追踪，发现全链路加载时长变短。让客户进行相关体验。客户反馈网页反应速度比之前快了许多。至此，故障解决。

4，服务合作

在帮助客户解决完这个问题之后，客户方要求出一个PPT来详细向领导讲解此问题的解决过程。后来在与客户研发接口之后，输出相关解决方案PPT。在获得客户侧研发的赞扬之后，发现客户侧只是生产单位，研发能力有限，而研发负责人也在解决问题的过程中逐步对我方建立了信任。

深度了解客户的组织结构之后，在向客户领导侧汇报完相关解决方案后，顺带提服务合作的意向。最终在客户侧研发主管的支持下，获得了领导口头的承诺。后将这一信息反馈到销售，继续跟进此项合作。最终，此项目由最初的解决登录慢的问题，最终落地成为一单服务合同。

5，项目复盘

回想这个项目，可以说是由一个点引发的一个整体的解决方案。有的时候，售前卖的不单单是一个产品，有的时候也是一种服务。客户的需求有很多，先要抓住客户当下最重点的问题，帮助解决。后边再谈相关回报。技术在这个项目中起到了很关键的作用，但也只有在沟通过程中，才能了解到客户的架构，以及未来对一些新技术的考虑。

这个项目，没有像之前的售前打法，先上来讲一通我们自己的技术方案，而是从客户侧的实际问题出发，帮助客户定位。与客户侧研发一起去解决问题。建立合作关系，最终我们能解决，一方面感谢客户的信任，另外一方面，也是公司后台研发同事的支持。因为在一些代码原理的实现方面，一家公司也是需要有相应积累的，尤其是要有相关的成功案例。

互联网行业的项目，一般来说都相对复杂。而当用互联网的一些方法技术去解决传统IT问题（从ToC到ToB）的时候，又需要多倾听客户侧的声音，让一线的人能调动更多的资源。而且，慢慢发现，自己在跟一个懂技术的客户聊天时，会非常轻松。而从技术的角度去推导客户侧的应用实现及并发解决时，总也可以预测到合适的点，从而可以更提前的与销售配合好，也为销售找到相关的拜访理由。

售前就是一个不断学习的过程，重点越来越感觉不是学相关的技术，而是从客户的角度去思考技术的实现，业务的驱动。