既当产品又当研发，字节大哥手把手带我追求极致

在学校的时候，计算机相关专业的同学应该都或多或少都被“大作业”折磨过，没有为“大作业”熬过夜通过宵的大学生活可以说是不完整的。步入公司后才发现，校园里的“大作业”就像玩具一样，需求明确、解决方案明确、最终产品效果明确、甚至还有前人的作品可以参考，而在公司里要做的东西，上面说的特点至少有一个不具备，甚至通通不具备。

而我在字节实习的过程中，所经手的恰恰就是这么一个需求不明确、解决方案不明确、最终产品效果不明确的项目。整个过程中有过焦头烂额毫无进展的时刻也有过欲哭无泪的时刻，还好有我的mentor带着我一路披荆斩棘、过关斩将。

首先和大家讲一下项目背景，当时我在的组是视频会议移动端，经历了近三年大流感的洗礼，相信大家对于视频会议中可能遇到的各种问题如数家珍，包括但不限于没声了、没音了、没画面了、画面卡顿、画面不清晰、画面和语音不同步、同步屏幕时闪退等等等等。作为一个服务企业级的B端产品，出现以上问题时就可能会投诉，然后经过客户成功部门转手到运营再转手到研发这里，研发就需要判断分析一下究竟是我们产品的原因、还是客户本身设备的问题、或者是第三方环境的因素，当用户的量级上来后，这样的客诉就会很多，会严重占用oncall的研发人员的时间以及精力。

我的mentor，一个专注于解决问题、避免重复劳动的人，一个字节范我觉得有E+的人，一个虽然身处移动端但是前后端甚至网络也都会的人，觉得这样很不OK，应该有个工具，能够自动的分析出来客户究竟遇到了什么问题，分析不出来的再找研发进行排查。没有这个工具也不影响业务开发的进展，所以整个项目并不存在时间上的紧迫性，但是呢，有这个工具做出来后肯定会大大降低研发的开发时间，所以项目的必要性还是有的。于是，我作为刚入职的实习新人，这个项目就交给我来做了。

而我，一个还没有从校园中完全出来的新兵蛋子，说实话面对这样的场面是一脸懵逼的，对于要做啥、要怎么做可以说是一无所知，我的mentor在我入职后，让我先了解了解背景，第一周就带着我oncall了，让我知道都可能有样的客诉，手把手给我演示他们正常的排查问题的方式。先了解客户反馈的情况，然后捞出来客户对应时间的设备信息以及设备日志。

说实话，作为一个新人，或者说我本身对于项目有一种畏难心理，碰到一点难题就总是想着往后拖，或者摆烂先不管然后就搁置在一边不想再问津了，但是我的mentor是一个有着坚定信念的人，差不多就是见山开山，见水架桥这种，遇到问题会主动找到相关人员一起解决，可以说就是有那种主人翁，项目owner的意识。于是，我就跟在他的后面，和整个团队的不同角色沟通他们遇到问题时排查的思路，试图总结出来一种通用的流程。在过程中，难免有许多困难，我的第一反应是退缩，但是导师的第一反应是拉会拉上相关人员一起讨论，看看用什么方式可以解决。比如在如何确定设备日志和故障表现的映射关系时，先后调研了多种方式看看相关团队有没有类似的做法以及他们最后实现的效果，包括大数据机器学习、代码状态流转图、自定义规则引擎等多种方式，最后调研后决定采用自定义规则引擎的方式。在实现需求的时候，需要其他团队协作时，他总是直接向前提出自己的需求，而我向一个陌生人发消息之前总要做一些心理建设，总是在担心些什么、害怕些什么，而事实上大家都是打工人，谁也不比谁厉害多少，对方不配合那就拉+1进群一起看看，解决不了就向上暴露问题。

于是，导师披荆斩棘在前，我在后面跟着实现他的设想。我们很快就做出来了第一个版本。通过Python自动化下载设备日志，然后正则匹配筛选出含有特定标记的日志，并对他们的出现频率次数做出判断。因为Python是解释型的语言，所以可以把规则直接写成python语言，用eval或者exec函数进行执行。第一个版本做出来后，导师又积极的带着我去给其他人宣传我们的这个工具。然后根据他们的反馈继续进行相关改进，最后我离职前实现的效果就是@ 一个群里的机器人，告诉他出现问题的ID，他就能自动化的拉下来日志进行排查，然后告诉你他分析的结果，整个交互非常的方便。

一个成功的项目必须要有一个负责的owner，我的导师就向我展示了一个优秀的owner是如何一步步解决问题、排除项目中的难关，如今我也正式成为一名打工人，希望我也能早日如他一般自如的面对工作。

我是日暮与星辰之间，出道两年半的Java选手，相信时间的力量，