互联网公司工作一年心得体会

2019独角兽企业重金招聘Python工程师标准>>>

     时间过的很快，从一个小公司跳槽的58同城已经一年啦（去年5月26日正式入职）。虽然58同城比起一线互联网企业还是有着差距，但是对于从小公司出来的我，受益还是匪浅的，自己不论技术还是眼界都有了很大提升 ，加上做的项目是从0到1的内部创新项目，感悟会更为多一,下面整理下这一年来的相关收获和相关落地方案。(文笔不好，想到哪里就说到哪里)

 

1.数据驱动

        相信每个互联网公司都会非常重视这一块儿，都有自己的数据可视化平台，可以查到每个业务线的详细数据。这些是业务数据，可以提供相关参考，做相关业务调整和战略发展。除了公司层面的数据平台，各个业务线也有自己关心的数据指标，一切用数据说话。大的方面不用强调，这里就从一些小的方面说一些数据驱动。根据业务建立相关数据指标，形成数据漏斗，产品和研发，可以看到漏斗每一层的相关数据和转化率，才能围绕漏斗提升做相关改进，业务推展才能有序推展。所以程序员们要有数据意识，多关注数据变化，用数据驱动业务发展。

比如我们的新项目，从一开始就建立了相关数据指标，数据报表每天邮箱会收到10几个

包括：用户行为数据，整体数据，A/B测数据，埋点统计，渠道来源数据，增长数据，流量数据，具体业务的漏斗数据，人效数据，具体业务的统计数据，项目执行进度，核心数据的变更记录等。

2.监控/报警/脚本       

        随着业务的不断发展，站点和服务越来越多，互相之间的依赖也比较多。出了问题程序员要第一时间感知到，因此监控和报警是非常重要的。公司层面肯定有相关的监控和报警方案，比如58的先知系统，可以设置http请求的超时阀值报警。服务平台管理也可以设置分布式服务的访问量，抛弃量，异常量的报警。架构部的平台也可以看到整个系统，从上到下的请求链，每个方法的请求时间，以及各个服务的访问量，访问时间，异常量等等。

        自己的业务线也可以围绕着服务是否可用，做以下的监控，脚本都比较简单，参考网上的一些例子应该就可以很快实现。

站点存活的心跳检测，比如某个服务挂了，导致站点不可用

硬盘的监控，经常会出现一些程序打日志，把硬盘给快跑满了。

数据库的相关检测，比如检测请求量，数据库连接。

缓存服务检测，比如缓存服务的内存使用情况，连接情况。

数据库检测，比如查看是否有脏数据。

实时任务的检测，比如监听消息总线，是否有消息堵塞，日志是否滚动。

服务的日志检测，比如查看相关站点的日志，看里面是否有程序异常，发送相关报警

...

        其实监控程序也不复杂，基本上都是一些简单的shell命令通过crontab，连接相关服务，查看数据是否异常，发送短信报警（把发短信功能做成一个http请求，通过crul 或者wget 调用接口传参短信报警）。

        另外一个需要强调的服务性能监控，也是程序员需要注意的地方。

        比如，我们对公司的分布式服务做了一个监控插件，里面有一个全局过滤器，每个请求都会进行统计，定时发送到另外一个服务中进行计算和报警。每天会有报表，统计各个服务的请求次数和每个接口的请求时长，以及超时接口排名。很多问题都可以通过这个监控得以发现，比如某个服务或者某个接口的平均访问时间过长，就需要进行优化。有段时间老大每天都会订着报表看，我们就需要想着办法进行优化。只有对服务的性能有清楚的认识，才能保证系统的可用性。

        另外要对各个站点和服务，进行日志采集和监控，以报表的形式反馈出来，是程序员就会出bug，我们也不能一天到晚订着日志。所以通过这些监控，我们可以看到服务的相关问题，进行解决。

    

 

3.会用linux，懂shell

        58核心业务不清楚，反正自己的业务线，程序员(RD)和测试（QA）都可以拿到服务器的相关权限，58这边由QA负责部署上线，但是RD有时候也需要自己动手。包括部署站点，部署服务，杀进程，启服务，写脚本，运行脚本，查看日志，异常定位分析，所以程序员们要懂linux的常用命令，另外java相关的监控命令也要知道

 

4.不仅仅只有web应用

        做后台开发的，不仅仅局限于web开发，除了前面提到的很多shell脚本，平时工作涉及的比如邮件报表，esb消息队列任务，业务定时任务都是独立于web程序的任务。比如用java做一些定时任务，之前业务线基于Quarz封装了一个任务框架，或者自己写java方法，通过contab定时调用。很多java程序员可能脱离了web容器，都没单独写过java应用。

        为什么面试的时候会问jvm的相关问题？ 除了一些框架和服务提供的配置之外， 自己写java应用也是要用到这些的，设置相关jvm参数，加载相关的资源，传参获取环境参数等等。

 

5.不仅仅只有数据库

        假如需要是做一些数据统计，之前可能都会想办法把数据存在数据库中，通过数据库的sql进行统计。比如回复短信的人都会哪些，有多少人参与了这个活动。其实很多数据不是业务相关的，都可以考虑用其他办法。比如记日志，从日志分析获取数据。比如pv,uv,用户行为分析，浏览记录，后台的操作记录等等，都可以通过日志记录下来，通过日志清洗获取相关数据。

        目前58的大数据平台基本上流程就是： 业务线埋点，输出log，flume采集日志到hdfs，通过mr清洗日志到hive。基本上做好数据埋点，很多数据统计都不需要改程序，传递不同参数，通过hive就可以进行数据统计

 

6.都是单表查询

        之前使用oracle，线上使用各种连接查询，聚合函数，存储过程。现在线上要求都是单表查询。允许数据库表冗余，要么单表查询，要么在业务中组装数据。

        如果数据量大就分表 ， 如果数量大且并发大，分库分表。 设置好主键生成策略和路由策略。在数据库上层封装一层查询索引，根据条件索引查询id串，根据id串去各个数据库并行查询。另外数据量到另外一个级别，就可能需要nosql的解决方案了，比如58内部的WTable。

        当然一些统计相关的可以用一些链接查询，但是生产环境不能使用。

7.并发/缓存

        58的用户量还是比较大的，业务中难免会涉及到58的相关业务。比如我们通过esb消息总线拿到数据，一天处理几百万或上千万的数据。或者对大数据平台每天几百T的数据做分析，跑任务。接触到业务逻辑和遇到的问题，也是小公司一般很少遇到的。所以并发相关的问题，多多少少也都会遇到。

        另外做一些活动运营，或者服务接到主站服务中，都需要考虑服务的并发请求量，考虑QPS。目前自己了解的相关指标，web站点达到600QPS，服务达到2000QPS，剩下就可以堆机器了。如果想提升QPS，简答的就是加缓存，但是当然有很多业务场景不是加缓存就可以解决的。

 

8.全栈

        公司比较大，做的业务分的就比较细，比如由美工做设计和页面，由前端负责做页面和js交互，其实后台程序员只用写好服务就行。因此校招的程序员大部分对前端js都不熟悉也很少用到。但是对于写管理系统的，没有前端FE支持，可能就需要前后端通吃了。不过很多人还是很优秀的，很快就可以学习上手的。

 

9.解决方案都有

        毕竟公司不算小，除了公司的核心重量级业务，各业务线都不会遇到太大的技术瓶颈。开发过程中，遇到问题，基本上都可以找到各种办法去解决。所以遇到问题，去聊，去搬。技术上都不是问题，只要有人，很短的时间，pc，m，app三端就出来了。

 

10.开发流程

        58的开发量程还算是比较正规的，一般都会提前要求PM需求，RD体现批注需求，然后进行需求评审，技术评审，RD排期，开发，提测，上线。RD需要对排期负责，保证开发进度。

 

11.技术体系，述职

        58技术体系，走的是T序列（参考百度），校招基本T3， T4就是高级程序员了，T5基本上都是组长了，业务线从T4到T5是一道坎儿。T序列升级需要述职，感觉还是比较有难度的。公司大部分应该是T4的。所以在公司如果混日子，基本上是待不下去的。所以平时在开发中，就需要考虑完整的技术方案，做好相关设计，这样述职的时候才会比较轻松。

        58内部也会有各种技术讲座，也会邀请业内的大牛，整体技术氛围还是不错的。

 

12.公司的发展变化

        虽然来58基本没接触到主站的相关业务，但是也见证了公司的一些变化。比如去年公司所有业务线切换到腾讯云机房，58大数据平台换了两版，越来越高大上。提供了hive的云窗，可以直接开放给pm去查询数据。

架构部的服务平台，提供了先知系统，scf服务管理，wcache，wlist，wtable等自己的服务。前段时间换logo，三端改版。互联网公司确实变化比较快。所以程序员也要不断提高，才可以跟上公司的步伐。

 

转载于:https://my.oschina.net/lujianing/blog/690746