记第一次出差

TL;DR

• 紧急出差，晚上六点突然收到消息
• 第一次坐飞机，九点从北京出发，十点四十到大连
• 了解到了售前和销售的一点区别
• 我完全胜任不了售前的职务
• 生产事故是非常严重的事故，未经测试的代码总是让人惶恐
• 我永远不会去国企上班
• 我希望我技术更强，能应付更复杂的生产环境问题排查

选择困难

当六点四十收到是否愿意出差的询问时，我犹豫了很久，第一个原因就是出现了生产事故且前线同事无法定位到事故发生的位置，并且是我不熟悉的中间件，我害怕我不能胜任。第二个原因则是没有出差经验，心里害怕，像是得走出舒适圈的一种畏惧。挣扎了 20 分钟，最终选择了去出差，去前线调查事故发生原因。主要原因是这是一次难得的机会，新的挑战肯定能收获更多的经验，这篇博客也正是记录这些收获的。

第一次坐飞机

由于情况紧急，老大给我买的机票，我也没有带身份证在身上，我办了一个临时乘车登记，然后就去了入口那儿想进去，她和我说需要一个什么乘机证明，然后我才去找了那个机子，打印了一张，此时我手机大概只有 12% 的电。打印机票的时候好像能选座位，我没有选…

机场安检不像高铁需要我喝水杯里的水，直接把我水倒掉了，说里面能接水。机场进候车区的路上有代步传送带，很好玩，就是扶梯是平的那种。候机区的座位都有 USB 充电口，当时我的电只有 10+ 左右，然后给爸妈通了微信视频，因为是新奇的体验想分享一下，再来也是旅程报一下平安。

不像平时在电视看到的，那种登机有个楼梯慢慢走上去，这边就是用一个通道直接对接了飞机，然后走进去，完全去不了地面，我想是减少事故的发生吧。飞机离起飞点有很长的距离，会在机场转很久，最后启动的时候能感到加速的推背感，然后感受到飞机倾斜开始升空的感觉，飞机一直嗡嗡嗡，耳朵会有点难受，升到 4k 到 6k 的高度的样子，平稳运行的时候倒是没啥事了。飞机时速能到六七百千米每小时的速度，嘎嘎快。

落地后我的手机没电了，在 3 号出口那儿墙边有充电的地方充了二十分钟电（大连周水子机场）。

问题接踵而至

第二天来到机房，上午就找到了关键日志，可能是我们的适配问题导致的，不过为了确定问题的所在，需要用反编译工具查看用户源码，不过由于无法上传工具，此时就特别难受，业务服务器的机房和安全产品部署的机房也不在同一层，排查问题的过程就变成了异常困难，每次切换都需要等人开门，等人来上机，非常缓慢。

不幸的是，排查过程中，客户业务群说又出现了问题。保存一次出现了两条数据，我当时就排查了日志，发现确实有两条 insert 语句，前后间隔 20ms，大概率是业务逻辑的问题，由于也不知道业务 API，所以没法判断是不是用户进行了连点操作（没有防连点的保存按钮太多了，业务开发经常遇到）。所以暂时只是推给了业务系统自身的问题，和我们安全产品的问题不大，甚至没有问题。

又不幸的是，排查过程中，又出现了问题，客户业务这边验签失败了。当时刚好我们的安全产品是开启的状态，我就立马查了业务日志，发现没有打到业务系统的日志，后来去发现就是浏览器证书的问题，导致本地验签失败，请求发不出去，换了 IE 浏览器就好了。

两次问题的出现刚好就在我们安全产品挂载的时候发生的。每次问题的排查我都会以技术的角度给出问题产生的原因以及日志排查的思路，来阐述这个问题与我们没有关系，随着销售和售前的进场，他们让我知道了一个事情的处理每个角色看待问题的方式都不一样。客户方因为我们开启了我们安全产品的缘故，所以一有问题就认为是我们导致的，并且在有了确切证据之后也一样认为我们是有潜在问题的（无法完全信任），所以最后也要求我们如何证明我们的产品是没问题，目前唯一的办法就只能是下一次业务过来，开启我们安全产品的前提下，不出现任何问题，这样才能打消目前的顾虑。

销售和售前的区别

因为觉得都是在客户这边进行工作，所以一直觉得差不多的亚子，所以吃饭的时候就问了问售前

在产品推广中，销售是最先入场的，销售通过和客户领导打交道，获取客户领导的信任，如果有意试用或购买我们的产品，客户领导就有机会能让下面对接我们的产品，此时销售就能退场了（之后如果客户这边出了售前也无法解决的事情可能需要销售甚至是 CEO 来维稳一下客户这边的情绪），需要运维进场为客户对接安装我们的产品，售前来跟进其中出现的产品问题、产品新需求以及各种事故。

此次就是出现了生产事故，售前在客户以及公司的双向压力下（客户需要一个事故的解释，公司需要帮忙排查问题）进行问题的排查以及挨客户的脸色，没能找到问题的所在，因此紧急调用研发的我来帮助排查问题。这样售前就能单独去面对客户这边处理客户的问题，我就负责收集日志反馈给公司，配合排查问题和修复问题。

问题修复

排查出了问题，是我们产品适配的问题，由于初期又恰好这边没测试环境直接生产环境造，所以问题就复杂了许多

排查出问题后，老大他们在公司很快就进行了问题复现和修复，第一天晚上就发来了修复版本的包。

因为不能加重用户怀疑第一天出现的问题就是我们的问题，我们不能直接说我们需要上传我们修复后的版本进行替换来达到解决问题，国企的电脑，U 盘需要使用他们的 U 盘进行操作，售前每次都给了一个合理化的理由让我们有了我们数据传输的机会（每次我都是眼前一亮），或许以后能用到：

• 为了能下载日志 —— 我们需要收集一下我们自己平台的日志
• 为了能上传新的修复版本 —— 我们需要上传一下指标
• 为了重启业务系统 —— 我们重启安装能持久化安装，之前不是，这样能收集更多的日志方便之后问题排查

全程我都是哑口无言，都是售前在和客户交流，然后我直接上机做操作的那个人…售前真是太强了

不过由于是生产环境且没法测试，最终我们还是把我们的产品安全功能给暂时关闭了，毕竟生产事故不是闹着玩的。（在我看来，没有经过测试就上生产环境是极不负责和不专业的行为，完全能找一个有测试环境或开发环境的系统来进行产品试用和体验，不过当时的业务场景我也不太懂，可能公司有自己的考虑吧）

后来吃饭又问了销售这个直接上生产环境的问题，说是最开始一周用了客户官网的测试环境测试了，我说官网基本就是一些静态页面浏览，测试完全覆盖不全面…

国企并不令技术人向往

技术栈落后，外包多，解决问题慢

这次接触的业务系统，没有业务日志记录，配了日志记录文件记录但是没有日志记录，显然业务代码没有一个 log.info 日志输出（不过刚好给了我们打太极的机会）。 处理问题很麻烦，业务部门和安全部门是分开的，第三方厂商干活得两边搞商量。每天工作内容我估计写报告较多吧。

总结和展望

• 技术专业能力的提升能更好地解决问题，临危不乱（技术自信）。相比较两年前刚出来实习就和客户打交道来说，这次底气更足一些，遇到问题，能给客户提供排查问题的方案，不过至于说服客户来配合这件事情还不太会。
• 最近的工作虽然写了几个安全相关的防御 hook，不过离网安入门距离还很远，希望自己有时间多多接触这块，也方便工作上研究对抗相关的提供更多思路（知己知彼，百战不殆），学习多输入也多输出。
• 多站在不同的角度看问题，对于一个技术产品，出现问题，即便技术方能认为自己没有问题，客户也不会这么认为，每个方向解决问题的方法都不同，不要自以为是。
• 感觉自己话还是太少了，在外头难免需要和客户和同事打交道，我基本都是很少说话那种。技能树点少了，希望下次多点几个不同的技能，解决问题的能力加强一点。