我在秒拍这六年

今年因为发生了太多的事情,一直没有时间更新博文,没想现在已经是从公司离职近两个月了。时间一长,竟不知该从何说起了,而且还是这么“深情且悠长的一个话题”。以前听一个朋友说,写文章不用讲究什么技巧,你平时说话什么样,文章就写成什么样,深以为然,现在我也在更多尝试用这种风格来记录自己的成长经历。今天,我就从我自身成长的角度来讲讲陪伴公司走过的这六年吧。

我是13年实习的时候加入了我们公司一下科技(主要产品秒拍、一直播、小咖秀),刚来北京,没见过什么世面,觉得公司的办公环境非常高大上,所以就义无反顾的加入了,主要负责秒拍的后端业务研发,工号0028。那时候公司刚刚拿到B轮融资,但是公司已有了几款短视频产品,量都不大,核心的产品秒拍也是不温不火。职场小白,跟随着公司也一步步的经历了很多的大事件,像“冰桶挑战”,“小咖秀爆红”等等,每天产生数十亿的播放量,也一步步建立起了围绕秒拍的短视频矩阵,记得当时任泉(我们投资人之一)在公司庆功宴上说“把一款产品从0做到火爆全网,可能肯多人一辈子都无法经历的事,能跟大家一起见证,真的非常荣幸”。的确,但是作为一个技术人,除了感到幸运之外,也正是这样的经历,让我明白技术团队在什么时刻应该做什么,来更好的助力业务。

16年开始,秒拍的量持续增长,“祖传三代”的单体架构已经不堪重负了,我同时转到了研发中心的平台架构部,在架构师的带领下,我们逐步的把秒拍的技术架构从单体过渡到微服务。其实,业务架构最难的不是技术实现,而是在不能影响老业务稳定的前提下,去完成新架构的建设。我们当时,一个团队6个人,既要负责线上千台服务器的运维,又要负责基础服务的开发和老业务的迁移,同时还要承担业务团队的培训和流程管理。秒拍业务的增长,每天都有不同的挑战,真可谓是压力与机遇并存。不过好在上边KPI卡的不是很死,我们前后花了近一年的时间,把秒拍的技术架构和人员架构都维持在了一个相对高效的范畴,同时把我们业务流程管理积累的一些经验,研发了我们公司的统一运维平台,实现了业务团队的开发测试管理,线上资源管理,和服务部署平台。公司数十个团队项目也都顺利接了进来。一直到后来我们团队转型去做孵化项目,这些系统也都在继续为技术团队服务。在架构团队这一年多的时间,是我成长最快的一段时间,也真的要感谢老领导“教练型”的启发。这些经历,除了让我技术视野有了很大的提升,最重要的是明白了“影响力和人”的因素,在技术布局中的重要作用。

18年开始,因为受困于秒拍的市场表现,以及公司内部组织架构的调整,在CTO的带领下,我们开始转做孵化项目,探索短视频社交的可能性,办公地点也搬到了B座一个小的独立办公区。那段时间团队重组带来的不仅仅是人员的变化,更重要的是团队节奏的变化,已经不是之前那么有计划性的稳扎稳打了,更多的是回归了公司初期创业的心态,节奏也更加的鲜明快速。从技术方面讲的话,相比于在开始加入公司的时候,自己最大的感受是,已经可以开始可以主导团队的技术方案,像核心的功能服务,包括一些活动的前期设计也都是自己在做。并且由点及面,逐渐考虑整个系统的整体,团队的整体,产品、研发、测试、运维、线上数据反馈,再到产品的下阶段需求,怎么形成闭环,从而达成团队的螺旋式增长。另一方面,从年初开始,我们和华为云就陆续有了很多战略合作,除了基础的云服务外,还有推荐系统、机器学习等这些AI服务,我也开始负责一些服务的研发和这些线上资源的运维。并且后边有幸能够代表团队接受华为云和infoq的联合采访,来分享一些秒拍的“迁云”经验(二叉树的奇幻漂流)。

到18年10月份,秒拍重新恢复上架。在这个时候,我们团队重新接管了秒拍,在CTO的推荐下,我也开始负责团队的管理工作。可以说是临危受命,当时我跟我们CTO交流更多的是,除了产品上面临的困境,更重要的是团队人员的凝聚力,怎么能给团队带来新的希望和斗志。秒拍从11年发展到现在,能做的都做了,下一步该怎么,谁也不知道。那段时间,我自己也感觉像在迷雾中行走,不仅仅是刚开始带领团队,没有太多的管理经验,还有充分的业务理解、技术建设、团队文化、团队赋能,等等这些需要管理者考虑的事情。在这里真的要感谢我们CTO给予的很多支持和赋能,能让自己有一种使命感,在给团队带来希望的同时,也在给自己带来希望。

18年底,我们事业部在新VP的带领下,开始做一款新的短视频APP“快8”,主打下沉市场。所以我这边抽掉了两个服务端技术和其他团队的两个服务端技术来支持新项目,我除了继续负责秒拍业务,还要负责新项目的流程管理和运维支持。一直到今年年初,经过一两个月时间的产品打磨,新项目的留存也再创佳绩。这期间秒拍其实也在尝试做一些转型,比如:精选、社区等的垂直领域,但是自身的历史包袱实在太重了,转型并没有收到很好的成效。所以到今年3月份,秒拍转做维护状态,我也开始主抓新项目的管理工作。随着新用户逐渐的增加,我主要带团队把重点都投入在了服务端优化上,像我们核心的播放、媒资、推荐,性能和稳定性都有了很大提升,同时产品的各方面数据也持续取得了不错的成绩。

但天不遂人愿,在这个时候,公司强推“中台”战略,组织架构也对应调整,我们CTO选择离职,并且还涉及到了我的一个老领导,和前端技术总监。后端团队从现在事业部抽离出来,并入中台,资源运维也要交接过去;并同时开始为期两个月的“中台全家桶”接入计划。

中台虽然经历了16年研发中心,到现在2年多的发展,却依然只是一个“业务平台”,还远远达到不了“大中台、小前台”,能带给公司的收益也非常少,反而各方面的“团队协作”,“业务支撑”,逐渐变得非常低效,内耗严重,快8的产品数据也在各种制约下,跌回到了起点。我想这也是为什么在前几年掀起的中台热,今年却逐渐有人开始唱衰的原因。在国内的大环境下,中台如何更好的在企业落地,更好的助力业务发展,恐怕还有很长的一段路要走。

到6月份,VP老大准备用3个月把快8数据重新做回来,同时我这边服务端重新划到了业务组,加上项目组其他小组的核心骨干成员,我们成立了新的“快8事业部”。我在经历了几个月的“颠沛流离”,如今重回组织,没有那么的热血和深情,内心却非常的平静。

我开始思考,技术人员赖以生存的技能是什么,技术人员的价值到底体现在哪里。特别是现在互联网已经进入了存量竞争,评价技术人员的能力,已经不仅仅是“需求写的有多快”,“业务有多熟练”,反而是“持续学习精进”,“团队协作”,“深度思考”等等这些无论什么行业的优秀人才都应该具备的素质,以及从软件工程的角度,从全局的角度去思考自己所做事情的价值。所以一方面我开始推进团队内部的架构演进,流程规范,“协作、成长、创新”的团队文化,另一方面我也加强了和产品、运营等其他团队leader的深度沟通,从需求周期的角度协调团队之间的协作。慢慢的,团队士气提升了很多,团队之间的协作效率也提升了很多。

不过令人遗憾的是,我们并没有能够达成既定目标,随着VP的离职,事业部也宣布解散。一直以来我都觉得“如果有一天我离开了公司,那一定是我不能再为公司做什么了”,现在真的到了这样的时刻,离职交接那几天,有几个其他部门的同事过来告别,想想在公司这几年,我也送别了好多同事,如今,也要被其他同事送别,真应了那句“铁打的营盘,流水的兵”。不过,也值了,我在公司这几年,做过研发,做过架构、运维,做过团队管理,也经历了多个产品从0到飞跃的过程,就像我之前说的,很多事情只有亲身经历了,才能有深刻的体会和更多思考问题的角度。并且我也努力过,努力过就不会后悔,人这一辈子最怕的是“本可以做好”。

我们团队小伙伴在离职的当天一起去聚餐,这也算是最近一年多,部门唯一的一次“团建”了,真没想到也是最后一次。在酒杯的碰撞声里,大家吃着串,谈笑风生,每个人的脸上都充满着希望,似乎这次不是别离,而是新的起点。

最后,用送别我老同事的一句话,送给公司和曾经战斗过的兄弟们,“再见,不负遇见”,希望每个人到了新的岗位之后,都能继续发挥自己的光和热,加油哦。… 阅读全文

“二叉树”的奇幻之旅

一直想写的2018年年终总结,直到今天,才有时间静下心来,好好想想一年来发生的点点滴滴,用“奇幻”来形容,真的一点不为过。经历的这些事,最大的感受,还是在心态的变化上,很长的一段时间,自己内心都比较平和,做事也比较轻松,效率比较高。不过话说回来,心态的调整不是一朝一夕能够完成的,特别是身在职场,真的需要长时间的坚持、反复、调整、再坚持的过程,会很难,但是只要坚持下来,带给自己的收益也会越来越大。

大概是12月初的时候,也是机缘巧合,华为云联合infoq的二叉树栏目,要做一次品牌宣传活动,需要相对比较了解技术的客户,聊一聊华为云的使用感受。刚好,我们前段时间,把主体的业务都迁移到了华为云,CTO就推荐我去做这次专访。专访的时间是定在了12月9号,我原本以为前一天晚上我会担心或者兴奋的睡不着觉,但是那天是我近一个月来睡的最踏实的一次,并且当天的采访环节,中间也基本没有卡壳,一遍就过了。反而是采访结束的当天晚上,我失眠了,但是失眠更多的是开心,如果说之前在心态方面的保持都是演习,那么这次真的就是真枪实弹了,并且还拿到了不错的成绩。

前段时间跟一个朋友聊天,他谈到自己工作上遇到的各种奇葩同事,工作上也各种的不配合,其实仔细想想,从自己的整个职业生涯甚至是一生来看,有些事真的是小的不能再小了,绝大多数的人都只是生命里的一个过客,重要的是自己的经历、成长与感受。推荐给大家一本书《当下的力量》,这个在“我的书单”里也有列出来,当我们能把精力都专注在自己正在做的这件事情上的时候,我们就有无穷的力量。恐惧是源于未知,但是未知带来的不只有恐惧,会有更多的兴奋,我们能不断探索未知的兴奋。

2019年的展望,也没有什么特别的,该坚持的还是得继续坚持,像“健身”、“读书”、“平和的心态”,把他们养成一种习惯,成为身体的一部分,但同时也得允许自己偶尔“偷个懒”,有很多朋友做一些事坚持不下去的原因,就是没办法接受这种“暂停”。累的时候就好好给自己放个假,充分享受、放松,等恢复状态之后,继续坚持下去,根本不是问题。

如果真的要想象一下的话,周末就不要加那么多班了,星爷在接收鲁豫有约的采访时候,说“假如我可以再重来的话,我就不要那么忙了,干我喜欢干的事情。现在50多岁了,我发现很多事情都还没有好好地做过。”这么说不是让我们放弃努力实现自我的价值,而是这两者本身就不冲突,多做些喜欢的事情,出去旅旅游,看看这个多彩的世界,能提供给我们更多思考问题的角度,也给我们的人生提供了更多的可能性。

最后,分享一下infoq采访的文字稿和视频:

背景类:

1 秒拍现在的业务体量大概有多大规模?单个页面的峰值和日常流量差距大概有多大?

目前我们每天的PV都上百亿,因为我们继承了很多微博自身的媒体属性,经常会有突发流量,导致并发瞬间能达到几十万,是日常并发的上百倍,并且这种突发情况有很多的不确定因素,有可能半夜某个明星发了个什么视频,就会来一大波流量。

2 秒拍近期的品牌升级动作,在业务方面有哪些体现?

我们公司是11年成立的,其实从刚成立时候,我们就会尝试各种各样有趣的玩法,包括我们之前做秒拍,小咖秀,打造短视频的品牌价值,到后来我们也在尝试很多的创新型项目,整个行业也都还在不段探索中。现在市面上的短视频APP有很多,不过同质化比较严重,单纯的依赖算法太过顺应人性,秒拍是人工筛选和算法结合的方式。公司希望借助这次品牌升级动作,不断优化业务和运营,帮助更多有价值、正能量和真正优质的内容被大众所看到。

3 秒拍为什么会选择云迁移?是之前在工作中遇到了什么问题吗?

我们现在主体业务已经是部署在云上了,但整个技术体系,还是基于传统的虚拟机去承载的,前边我也提到,秒拍自身的这部分媒体属性,导致了不可避免的会经常遇到突发流量,相比与一直比较平稳的流量,这种对服务端的考验更高,核心关注点还是在怎么保障在这种时刻用户都能得到良好的体验。另一方面,由于云平台本身的一些不可抗力因素,不能保证百分百的高可用,怎么降低单点依赖的风险,也是我们需要重点考虑的。

4 在云服务选型的时候有过哪些选择?秒拍最终选择华为云的原因是什么?

最开始接触华为云是在今年年初的时候,那个时候还没怎么听说过华为云,当时还比较惊讶,华为也开始做公有云了?后边我们了解到,华为这边的2012实验室,有业界非常前沿的个性化推荐算法需要数据验证,而我们线上有很多鲜活的数据需要更好的推给用户,双方基于开放合作的共识,慢慢达成了合作意向。再到后来我们的迁移,从最开始的双方互相都不熟悉,到彼此信任,并且合作也取得很多好的效果,这些都是一步步的信任积累起来的,我们信任彼此,所以我们选择彼此。

内容类:

阅读全文

容器化架构迁移升级实战

背景

我们现在主体业务已经是部署在某云上了,但整个技术体系,还是基于传统的虚拟机去承载的,由于我们产品本身的媒体属性,导致了不可避免的会经常遇到突发流量,相比与一直比较平稳的流量,这种对服务端的考验更高,核心关注点还是在怎么保障在这种时刻用户都能得到良好的体验。

另一方面,由于云平台本身的一些不可抗力因素,不能保证百分百的高可用,怎么降低单点依赖的风险,也是我们需要重点考虑的。

经过综合性的权衡,我们决定把主体业务迁移到华为云,并且优化升级原来的架构,以便更好的支撑海量用户访问。前端机也从VM过渡到docker,迁移后的整体架构图如下

各个资源的迁移过程

1. mc迁移

现在业务上使用mc只是做临时缓存,cache miss会从存储(DB、ES等)拉一份写进去,并且业内也没有比较成熟的mc存量与增量迁移方案,所以这部分数据可以忽略,等上线前,预热一部分热点数据进去。不过使用上有一些区别,原平台使用的是服务端集群,现在是客户端集群,需要建立MC连接的时候,添加所有的服务器列表以及权重。

2. mq迁移

mq主要用来解耦业务模块,生产端生产一份数据,消费端可能有多个,迁移的话,需要先配置好资源的vhost,exechange还有queue,服务端先更新配置上线,数据写入到新资源,消费端在旧资源消费完成后,切换到新资源的消费上。

3. redis迁移

redis的迁移需要区分两个场景的数据,一个是缓存数据,可以按照mc的迁移策略忽略,另一部分是持久化数据,主要是业务上的各种计数,这部分数据要求尽量精确快速的迁移到新资源,当时考虑了两种方案

  • 一种呢,是基于快照文件迁移 存量数据可以通过RDB快照,只需要原平台有备份RDB的权限,在新资源通过快照回放完成全量数据的迁移。 这种方案优点比较突出,操作简单快速,但缺点是不支持增量同步。
  • 另一种呢,基于业务迁移 首先,读
阅读全文

Nginx、FPM配置及优化

Nginx配置

nginx的配置主要分为6个区域,main(全局设置),events(工作模式),http(http服务),upstream(负载均衡),server(主机设置),location(url规则)。

main
events {

}
http {
    upstream domain {

    }
    server {
        location {

        }
    }
}

main模块

阅读全文