互联网入门三套车

话说央妈都开始推互联网了,于是资本,人员等各种资源开始疯狂的涌入。但从一个技术民工的角度来看,涌入进来的弄局者,讨论到最后的结果基本都是,我们只差一个码农写码了。但是真正的互联网是怎么玩儿的,局外人们也只是看着互联网企业的惊人成长速度而管窥狸豹而已。其实真正能认识,并且相信套体系的boss应该没几个,尤其是想转型的传统企业,尤为困难,并不是简单的买一堆服务器,养几个死贵的码农那么简单的事情。于是有着各种大互联网公司的从业人员们一时洛阳纸贵。原来的各种行业的人才也开始涌入这个领域开始折腾,于是各种bat的墙角变成了市场上的香饽饽。阿猫阿狗齐上阵的时代开始到来。
互联网企业,所依赖的快速迭代,快速响应,一切以用户需求为主旨的背后,不可离开的线上三大体系,目前的巨头们,基本都是体系成熟,并且开始玩四个体系的细分领域和外延部分了。
1,运维监控体系
2,内容运营体系
3,数据化营销体系
4,持续迭代发布体系
所以衡量一个互联网公司估值价值的指标,从技术数据层面,依赖于这三个体系的正常运转,不过许多大boss可能第一次见投资人还基本对一些衡量的指标保持懵逼的状态。或者说保持一个不关注的状态,不过不同的领域也许依赖和衡量的指标貌似不尽相同,从技术角度来说,基本如下:
1,日活,用户量
2,次日留存,月留存
3,qps,tps
4,交易量,流水量
那对于各个体系,是如何去影响这些指标和辅助强化这些指标的呢?大致粗浅的理解如下:
运维监控体系:这个体系实际上是从前到后的一套完整的对线上服务器硬件,以及业务关键程序运行的健康度的监控,所以说得从两个维度来看这个东西。
系统角度:对于每天看着服务器的运维工程师来说,大规模的集群,基本上都采用了统一化的管理,linux上面对于集成部署和监控,有很多开源的组件,目前我们用的比较多的是salt和ansible,基本可以conver大部分的集成化运作指令,设想,一百台级别的服务器,需要随时发布,更新,以及监控各个服务器的cpu,内存,硬盘的占用情况。shell利器不可不用。现在云化的时代,对服务器的cpu,等硬件设备的监控大多云平台都带,几乎也都好使,不够的可以用云平台的接口做一个嘛。
业务程序角度:对于业务这块的运维监控,会比系统的要复杂得多,各个服务集群之间,所关注的业务点都不一样,为服务器化的集群,最主要的还是看http的响应数量和响应时间,这块我们大致会采用开源falcon来进行定制,分服务,分api,分页面来进行关键性的监控。例如,我们比较关注用户的注册量或者报名量,那么我们必然监控注册和报名的页面或者api的的请求量。单独出一个较为独立的图表。
内容运营体系:这个体系实际上决定了很多大多数终端用户看到的东西,比如说今天做个活动,明天做个活动,今天花式发个卷什么的,所以大多的内容运营平台几乎也都是按照系统的场景来定制化开发的,内容需要能够每天秒更新自己的活动和创意,而系统也必须秒支持。我记得有个典故,我们pm说这是一个cms,然后又加需求说这个东西其实是一个带crm的cms,然后这又是一个运维管理后台还要有审核等流程的机制,然后开发组就狂暴了,你们要的到底是尖椒炒肉,还是鱼香肉丝。所以从一个侧面说明这块东西的复杂程度。
数据化营销体系:这就是大家传说中的大数据了,不过大多数公司的数据都不能称为大数据吧,不过这块由于数据量巨大,还是需要一些大数据的基础基础来支持的。很多时候pm上了一个新feature,市场做了一个新活动,想要知道效果,比如和交易量相关的指标上升了,pm也得说出个理由来。或者说,用来说服码农全天秒出新feature的理由,也是由这些数据来支撑的。
例如,pm和dev leader死磕,说这个东西上了没什么卵用,于是乎pm说到时候我拿数据和你说话,dev leader于是带着项目组周日加班干出来这个新feature,上线了,然后跑了一个星期,然后告诉开发组,你看,我们的这个新feature导致我们的app访问时常增长了10%,dev于是哑口无言,开发们也乐得屁颠屁颠的,俺们写的东西终于是有用的啊,于是乎下一个feature继续接踵而至。当然,也有pm被打脸的时候,基本上就是pm买瓜子买水,捏背,请吃饭的节奏。
这些报表的基础数据,就来源于数据化营销的基础平台数据。初期落地到系统当中的大多就是日志和关键点的埋点数据。重要页面的action几乎都需要埋点,日志请求基本也都是全记录的。一天动辄上几十个个T的数据,大多都用hadoop家族系列产品。到了后期的数据分析组,技术就会用得比较复杂,大多都是混合型的技术架构,而且还有复杂的数据专家坐镇,直接影响领导层的战略调整。记得有个女同学做这个的叫什么来着,大家都叫她“统计学之母”。
持续迭代体系:很多人一看这个就会说,不就是一个jenkins和gitlab-ci这样一些产品嘛,但是貌似具体落地起来并不是一个持续化集成体系能搞定的事情,快速的迭代,需要PM(项目经理和产品经理目前互联网公司是复合型的,如果在你的公司的这两个角色不是复合型的,那么只能呵呵了)非常清晰的了解每个阶段需要快速实现的功能,不要问为疯狂的pm为啥老加班,他们需要控制整个产品的内容,feature上线的时间,开发资源的调配,市场的反馈,数据分析模型的建立,以达到最快的速度响应客户的需求,做到快速的调整。这个内容之所以是一套系统,在于它就是一个企业快速更新的基础。几乎涉及到整条业务线的调整优化。所以牛x的pm一个迭代周期基本是1-2周,而落地到具体的内容,就是码农的代码写完,测试,发布到线上,并且周知相关的各种人员。jenkins在具体的落地的过程当中可以扮演很多关键的角色,如包的自动化测试,编译,灰度的发布。极大的简化运维人员的工作负担。但是对于超大的交叉型互相依赖的线上项目,一个jk估计就没法满足需求了,具体的可以看下阿里发布的云端持续化发布平台,感觉屌屌的,几乎也是一套复合型的框架,不过不一定能够满足你们公司的场景。
以上就是把原来一些粗浅的理解和内容写个心得记录下来,仔细琢磨其实很多点如果深入进去去研究,估计都可以写成一小本小册子了,配点图在配点实战的操作步骤,几乎就可以出一本书了。不过大部分的文字,几乎很难传达个人理解的真实的内容,因为每个人的理解可能都是不一样的,因为大脑的思维方式不一样,不一定能get到你的点。所以相对而言,还是落地的代码和搭建好的系统相对便于容易沟通一些。
是马是骡子,自己搭建一套跑起来,并且让大家都用起来,应该就知道了。