非计算机转后台开发并入职字节跳动（四）--再回业务后台开发，头条工作体验

比较顺利的通过了头条的社招面试，当时头条筛简历的时候还有个小插曲，因为同时在官网投了两个岗位，开始收到了简历不过的短信，没过多久又收到了面试预约的电话。也就是大厂都是不同部门的同一个岗位要求不一样。同时进行的面试流程只能是一个岗位，但一开始是可以投多个，面试不过还可以接着投。

头条这边的岗位是普通的业务后台开发，以业务逻辑为主。虽然之前做的是机器学习平台，高大上的AI技术，但说实话自己对AI也只是入门，并不深入。也由于另外一些原因，所以舍弃AI再做业务后台开发也还可以接受。毕竟头条是大厂，而且是做纯正的互联网，面向C端的用户，并发量大。

头条入职体验

头条的入职也很简单，上午办理报到手续，同一批的几个人在会议室先看下公司的宣传片，然后交资料签合同。中午就被hr领到各个小组，然后下午熟悉团队和环境。脉脉上有些人说下午就开始干活，可能有些项目紧急的是会有，但我还算比较幸运的。对于我这种水平的人，互联网的很多套路还不会，得先熟悉下。所以mentor扔过来很多资料文档，开始熟悉团队、业务、开发环境和流程，当然这中间leader也会过来找你聊聊，问你有什么感受，有什么想法。

头条研发人手一台mac pro，对于用windows开发的人来说，使用mac 需要多一些时间适应，如果之前用的Ubuntu开发，适应起来又比较快一些。像我这种土包子，之前没用过这么好的电脑，拿到mac pro确实有点小激动。mac起来还是有点门槛，花了好几天时间才适应。适应了之后觉得mac 开发是真的爽，办公开发非常方便，系统稳定流畅，触摸板的体验是真的好，基本可以不用鼠标。

mac是本地开发用的，然后每人还会分配一台虚拟机作为开发机用，类似于阿里云上面的vps。开发机就是服务器环境，用于调试用的。头条的开发机最初是可以访问线上环境的，比如要改今日头条上面某个账户的名称，是可以在开发机上改的。这相当于给了研发太大的权限，比较容易出事。后面慢慢的在考虑网络隔离，将开发环境和线上环境隔离开，不能直接访问，如要访问需要申请权限。

因为仍然是后台开发，入职的前几天基本上就是用python和go各写一个服务上线，体验一下上线的流程。这个过程看个人的基础，基础好的可能很快走完了流程，基础差的可能对于中间碰到的微服务、RPC、thrif、consul、Kite框架等没听过，那么熟悉起来自然就慢了。之前只写过HTTP服务，到这里来了之后还有rpc服务，一时不能理解。后面慢慢的随着对环境熟悉了才理解了微服务。

所参与的业务

所在项目组的业务是负责今日头条app上的一个子栏目。今日头条可能很多人还没用过，没有抖音火。头条上确实内容太杂了，质量也一般，图文、视频、微头条各个体裁都有，版式也比较乱，不像抖音全是视频，看起来更舒服。头条上分了很多栏目，有些栏目是有专门的研发在负责，有些栏目就只有运营。

头条的业务模式其实很简单，就是作者发文章，然后经过审核等一些列处理然后就放出来，用户在APP里面刷的时候推荐引擎就推用户喜欢的。模式就这么简单，但因为用户大，后台需要大量的服务来支撑这样一个APP。虽然头条出来七八年了，但研发和产品仍然有做不完的事情。

头条成功的原因有很多，推荐是最主要的，推荐的好才会留住用户。头条一开始是没有自己的内容源的，是通过爬虫爬微博上的内容发在头条app上，并且当时推荐效果也一般，但比起其他app已经好很多了。
头条算是开启了个性化内容推荐的先河，后面从百度挖了几个推荐的大佬过来，推荐越做越好，dau等数据飙升，从而拉开了与其他产品的距离。现在也是到了瓶颈，dau和用户时长趋于稳定。

头条和抖音发出去的每个作品都需要审核，至于为什么审核应该都能猜到原因，要是不审核的话huangdudu会泛滥。那么审核怎么审？人工。也就是发出去的每篇作品在你看到的时候都会被头条的审核人员审核过，要是审核不过可能直接删除掉是没有机会放出来的。并且不只一轮的审核，会有多轮。头条在审核上投入了大量的人力和物力，包括研发资源。研发不仅要写各种规则来处理审核，人工智能也应用在审核上。比如鉴黄、领导人的识别等，通过人工智能的技术减少需要人工审核的量以及辅助提升审核的效率。人工智能在头条是有很多的应用场景的。前不久AILab马维英的消息确实有点突然，因为头条的AILab绝不是制作理论研究的地方。

项目组负责的哪个栏目就不说了，但无论哪个栏目技术栈都差不多。业务模式也很简单直观，后面会结合业务介绍用到的技术，如果没有用过今日头条的可以下载一个体验一下。我也是入职头条后才开始用的。

头条工作日常

头条这么多年一直在迭代，迭代的原因就是为了获取新的用户以及留住老的用户，一直在为dau和留存做斗争。那么就会时不时的推出一些新功能。这些功能都是产品经历想的，产品经历每天就是分析数据，然后想新功能，再让研发开发新功能上线，上线后再分析数据。数据不好又换其他的方案。互联网就是一直在试，试哪样做能提升用户数，不好的就舍弃掉，做了很多无用功。怎么看新功能好不好，一般是做AB测试。大厂一般有AB测试平台，新功能上线前都做下AB测试，数据好了才上，数据不好不让上。

那么工作之一就是写api，支持这些新功能，可以抓下app请求的包看会请求哪些挨批，那些请求到toutiao.com域名的都是一个个写出来的。api需要的数据有时是实时的，比如实时的阅读量，有些是离线数据，离线数据就是天级别或者小时级别的。比如你在csdn写文章，那么你文章昨天的阅读量是多少，这个就是离线的，是要到第二天才能算出来。无论实时的还是离线的，当数据规模到达一定程度时都必须得上大数据的技术，传统的直接查mysql解决不了的。大数据就是hdfs,mapreduce,hive,spark,flink这一套。这一套学下来又要花很多精力。但在头条，大部分的后台开发工程师都会接触到hive，因为要处理离线数据。头条提供了一个非常好的离线数据处理平台，使得后台开发工程师只要写SQL就能分析大规模数据。

除了开发这些新功能，还要支持审核的需求，因为审核需求也是一直在变，并且为了提升审核效率，尝试了很多方案。对于审核更多是写脚本，python脚本居多，还会写很多配置文件，配置各种规则。

所在的项目组开发流程是：产品经理想到了新的点子，给到UE/UI进行交互和样式设计，设计完了之后就进行前后端开发。有时产品没有想法，运营也会提需求，运营一般是做数据分析，发现问题所在，然后进行改进。头条的运营工作以垂类运营和审核为主，垂类就是内容都是有人工分类的，比如财经、历史，哪个类别比较受用户喜欢、数据比较好看，都会分析的清清楚楚。然后运营会联系对应类别的优质作者或者想一些激励政策，比如提高分成比例，鼓励多发文。审核数据也是分析的很清楚。

所以在大厂别看APP功能很简单，但需要知道每个环节的数据，以便知道问题在哪怎么改进，这样就多了很多工作。如果只是实现功能，用不了太多人力。

后端开发完就进行自测，当然你不测也没关系，反正后面也没测试把关，然后前后端联调。看功能大小，如果需要app发版的会有QA把关测试，如果不发版可能就没有测试介入。研发自测完就直接上线，所以很容易出bug，出了bug只要影响不大就没啥影响，不影响绩效，直接修复上线就可以。但这样也导致很多时间在修bug,修bug就要复现环境，构造测试数据，也很浪费时间，尤其在修前人留下的bug。总之头条的开发质量和质量意识一般，单兵作战能力确实强，但做了很多无用功，每天都很忙，但产出也就那样。因为上线非常方便，所以适合快速迭代。一天上线n次都可以。那为什么上线这么方便？是因为有一个比较好的基础设施。虽然很多人在脉脉吐槽头条的基础设施不好用，可能比阿里、美团差一些，但在业界也绝对是好于99%的公司了。

研发提交代码到内部的gitlab，然后进行代码review，一般找组内的一两个同事review完之后就merge。merge完就自行发布。服务发布上线是有一个TCE平台，类似阿里云的云效流水线FLOW。研发只要点点就可以了。底层也是docker+jekins+k8s这一套，当然做了二次开发。具体过程仍然也是代码打包，docker镜像构建，服务升级。升级的过程还有一步小流量，小流量的意思就是先升级一个pod的服务，然后把线上很小比例的请求打到这个pod上，观察日志和告警是否异常，如果没有异常再进行全部的升级。这一套比在上家公司用的那套开源框架又提高了很大的效率。

没有项目经理，只有小组长，小组长要统筹全局、做方案设计、分活还要自己写代码，确实也挺累的。活特别多，而且是杂活居多，零散的需求，临时加进来的需求，虽然没有项目经理催你干活，但活摆在那，只能加班搞定，日常加班特别多，不过也存在摸鱼的，看你性格。有些人干活就是不着急，但比较会表达，质量也高，虽然活做的少，但比较受领导喜欢。

大公司业务多，环节多，流程长。有时你的功能很简单，但可能有下游服务依赖你这个功能，你这个功能又依赖上游服务，要是做改动会引起上下游服务异常，那么就要开会讨论了。所以大公司会是真的多很多，白天开会晚上干活。开会一般是需求讨论会、方案评审会、周会、技术分享。如果干的是杂活，那么就是需求讨论会居多，说是讨论，对于研发实际就是接活的，参加一个会，就多一份活。有时不管你现在手头有哪些活，都往你身上派。这个时候还是得为自己考虑下，该拒绝的时候就拒绝，活是干不完的。

在头条开始是熟悉基础设施，熟悉业务，然后开始干活，真的是杂活居多。开发语言是python和go，有内部的开发框架，开发框架分为HTTP框架和rpc框架。日常工作就是写HTTP api, rpc api,改配置文件，写python脚本处理数据。业务的并发量也不算大，底层的基础设施已经足够保证你把业务逻辑理解好，按照套路写就能支持足够的并发。然后有幸了解了下头条的推荐，当然推荐太复杂了，只是了解框架和大概。

在头条业务交接比较频繁，可能你做这个做了半年，就被安排做其他的去了，然后要交给其他的同事。交接时间也比较短，一两个星期就可以搞定。这也体现了在互联网业务后台开发实际门槛并不高，虽然面试难度很大，但工作中大部分业务真的是人人都能做。因为用到的技术就那么些，基础设施又比较完善。

后续会聊的内容

下篇会聊下头条面试评级，结合头条的业务、推荐讲解下具体用到的技术，先了解了工作中用到哪些，再去学习。