这些年参加过的双11

今年双11在波澜不惊上落下帷幕,这个周末是难得的一个修整机会。百无聊赖之中,对自己参加过的几次双11简单总结。

加上今年双十一,已经参加了三次现场双11。对于普通用户来说,每年的基本盘都是 买买买 ,但对于自己来说,每年的感受却不尽相同。

第一次参加双十一技术支撑保障是2018年。作为还没有转正的新同学,第一次进入作战室的时候更多是新鲜感和第一次亲临现场的兴奋。然而,没想到等待自己的却是各种万丈深渊旁的如履薄冰,如同那年成都伸手不见五指的雾霾,一路战战兢兢,磕磕绊绊完成了任务。好在当时一起搭档的同学非常给力,把现场的问题都快速解决。

事后复盘,数据链路年久失修+系统架构设计太多trck和临时方案是症结。我们不能将这种必然的问题还诉诸于来年的好运。于是,我们花了半年的时间来解决以上问题。在大公司做这样的事情往往是不太被认可的,放在我身上也不例外。更为甚者,还会受到很多业务上的挑战。当时,我选择了接受阶段性不被认可的结果,坚持一条道走到黑。如今想来,有许多更加圆滑的做法,但是如果把我重新放在当时那个位置,我应该还是会选择当时的做法,而这种选择不是认知和经验问题,仅仅是内心自我的坚持吧。

带着第一年复盘的调整结果,信心满满的走进了2019双十一的作战室。是年丈母娘装了新房,当晚的一级保障计划就是给丈母娘 买买买。然而,还没等第一瓶可乐喝完,业务反馈大屏上面一个实时数据的结果不正确,找到当时业务接口同学,她倒也是诚(hou)实(yan)直(wu)接(chi):之前让验收数据的时候,回答是验收通过,其实并没有看数据。得嘞,这时手刃之祭天是没有任何作用的,而大屏数据又是部门万众瞩目的,那只能想办法现场把这个数据开发出来发布上线。抬头看了看时间,不要20点。

然而,因为双11封网一级保障的原因,实时任务开发平台无法新任务开发,沟通了将近1个小时也没有结论。好在想起之前作为集团实时任务计算平台的典型用户,与平台的owner有过一次还算愉快的内外论坛交流,于是直接联系他们解决了平台问题,只是受限于当时的关联系统管控原因,开发的计算任务无法调试,只是发布上线后结果。抬头有看了看时间,22点过了。

为了加快开发速度同时确保开发质量,我和当时搭档的同学每人负责一部分代码的编写,然后合并代码交叉review. 其实代码本身的复杂度不是太高,但是当时的高压环境和氛围让编写任何一个简单的逻辑似乎都变得不再简单。22:30 我们完成了代码编写,code review时候,我发现了一个代码的问题,跟搭档确认时,他也意识到了这是一个问题,不得不说,有时候高压真的会让动作变形。代码很快发布上线,没有调试的情况下,一次性上线成功,数据口径也符合预期。到此,问题解决了一半:由于需要追溯历史数据,因此,计算任务需要调回到今日凌晨开始计算,接下来的一个小时,我们就是盯着任务的追赶进度,终于在 23:45,成功追上了当前时刻的流式数据!

当时的直接主管老阿里也坦诚这是他参加过历次双11颠覆他认知的紧急发布。坦率讲,这次问题处理是有运气成分的,因为我和搭档事后都觉得计算任务不经过调试,一次性发布成功在日常开发中基本是不存在的。但是,过程中我觉得很重要的一个点是:技术自信。日常开发中,有问题我们可以面向google编程,但是当你的开发周期被限制在很小的时间窗口的时候,你日常所有的积累和基本功,当然还有欠下的技术债都会在短时间内爆发并如数奉还,童叟无欺。比如,这次review出来的问题我之前是研究过的,并且计算平台的文档我也是每一页都读过多次的,这个问题在哪些版本会出现也是心中嘹亮的。这些东西可能都称不上知识,只能算是信息和经验,但是假设没有这些助力,我们当晚必然需要二次发布,而时间是肯定不够的,然后也就没有然后了……另外,我很推崇的技术sense是对基础的重视:我们日常99%的问题都可以用基础的80%去覆盖和解决。因此,在追求20%的高精尖的时候(程序员歧视链的必然)永远不要放松对基础的积累和完善。

今年双11保障基本面很早就进行了部署和实施,11.1的作战室现场也是波澜不惊。但是,因为11.3黑色事件与双11有重叠时间的原因,业务层面在10号早上提了新需求。而再过几个小时就是双十一了……而我选择了接下这个需求,除了所谓的 价值观,还有一个原因是我觉得这是一个与其他同学进行技术PK的好机会。中午放弃了午休开始编码,下午3点过完成了开发,业务验收通过,然后关联业务方得知以后似乎觉得我这里的开发是不要钱的,又追加了一个需求……当然,在迟到了几分钟进作战室,都毫无意外的完成开发,并发布上线。

其实很多老人都觉得这个时候接这种需求很容易搬石头砸自己脚,其实我也是这样认为的。只是我评估业务需求后,我没有走跟我PK同学相对比较笨重的java技术路线,而是选择了Golang,在编译和调试速度上都占尽了优势,同时凭借自己平时维护的标准扩展库,很多任务都是一行代码可以解决。典型的现场现状是:我比其他线的技术同学提前了好几个小时把任务开发完发布上线,反馈问题修改也是在分钟级搞定。另外,大家可能有个疑惑:为什么没有像去年那样交给下面的人一起合作去做?一方面是因为这条技术线路在短时间内只有自己最熟悉,跟合作同学简单沟通后发现其技术面还未覆盖这些领域,我这个时候只能选择跟我上的方式,功劳大家分;另一方面,这个事情除去价值观,我有私心,我就是要用技术的方式PK一些日常看不惯的技术同学。我深知,这其实也是某种不成熟, 只是,时间久了,有些东西只是变味了,未必是成熟了

总结下来,参加这几年双11的几点感悟:

  • 未雨绸缪,实践检验真理。
  • 不要把偶然的运气当做实力。偶然的好运学会感恩和感谢,必然的倒霉也不必气馁,区分好概率和实力。
  • 养兵千日,用兵一时。高压之下,要有自负的技术自信。
  • 日常学会辨别气味相投的人,并投资积累信用,而不是表面上nice的人。
  • 技术人要学会通过技术做表达,从技术的力量视角去理解商业的本质。

九月总结及阶段思考

9月最后一天,开完最后一个会议,早早的从公司溜了,顺便突然出现在妞儿单位的停车场给她个惊喜,同时实现一下接女儿放学的小小心愿,这应该是9月份最开心的事了(还真是枯燥无味,朴实无华…)。

9.30意味着S1财年结束了。转瞬间,两年过去了,很多事情无论是经历的业务还是心路,过去的半年比过去的一年似乎更多更长,有着别样的滋味。

合作关系上一直比较幸运,少有的低谷也在不知不觉间得到了扭转。感恩这种幸运,同时也感谢自己一直坚持的信用价值。否则我相信纵使有更多人从身旁路过,也只不过是一个过客。

过去两年的主题一直是在找寻成长。但讽刺的是,从blog看,技术输出明显变少了。如今对于这一点已经非常坦然了,我相信技术出生的同学依然会介意这一点,因为技术上的学习和成长很容易从对比中去量化。人们对于可预期,强反馈的事物总是非常有执念。

然而,个人的成长远不止技术成长。其他层面的成长反而是非常难以标定和量化的。因此,过去一年,我一直在尝试通从别人眼中照镜子的方式来衡量自己的成长。这种照镜子一方面是你能够成就自己的同时,也能成就他人,并且这种成就有时候可能对你短期来说是有损的。比如,你闪光的idea、plan中关键的环节,这些你是否愿意交个他人,同时在一定程度上退身,兜底的是你,上台领奖交给他。坦率讲,我说的这些在过去的一年之于我不是“比如”,而是事实,我也并不是慈善家。但是,我出奇的发现,你在意的人其实是能够看清这背后的逻辑关系的,你的退身反而是价值和口碑的积累。

其次是要在你的关系网络中找到关键点。很多人谈中年危机,其实本质上都是因为他在他赖以生存的网络中出了问题,而这一切跟年龄无关,如果一定要说有什么关系的话,只是年轻的时候输了一局你还有下一局。从这点看,无论你是要在技术领域深入成为不可替代,还是在业务层面八面玲珑,四处延伸,本质上都是提高你在生存网络上的附着力。

最后是要充分理解精致利己主义者,这其中包括你自己。我一直认为个人的成长是内环境熵减的过程,如果你成长的速度高于平均,那么周围环境之于你就是一个熵增的过程。因此,但凡是在平均线以上,无论你主观如何认知和解释,本质上你都是在利己的同时在损人。而对于成长速度不在一个层次的人来说,彼此就是彼此的熵增和熵减。从这点看,个人成长跟不上公司发展速度的、夫妻二人成长速度差异太大的,最终只能分道扬镳。而我们可以做的就是不断的迭代中,无论是熵减还是被熵增,保持平和的心态,以及持续对抗的态度。

岁月无静好,希望至美!

谈谈这两年在业务中做技术的思考

一个闷热的中午,照常与几位同事在连廊吃午饭。跟我当初一起入职的同事提起说,已经两年了。他的感受一如他往常的云淡风轻:生了个娃,家庭上忙了很多,工作上留下的印象不多。而我告诉他,我觉得这两年挺漫长,当前的状态也是“很忙”的状态。这种长和忙其实也代表了过去两年的表象,而背后的一些事情值得细细思考和沉淀。

这个两年离技术更远了一些。很多技术出身的人是抵制甚至是有些许恐惧这种距离的。我也一样。技术同学的成长路径大概分两种:按照底层核心/中间件/业务系统由下至上或者自顶而下发展。每个环节根据个体差异,平均停留3~5年,而最后一个层级可能会停留多年。我属于前者。过程曲折,但是也没有什么可纠结的。而这种离技术的远不是完全放弃技术的积累,而是技术不再是唯一的首要位置。另一方面,在技术成长上需要更加体系的方式构建自己的技术框架。

比如,这两年追过Flutter, 了解了它在哪些场景下适合解决什么样的问题,以及解决效果及局限性是怎样。在很多前端同学还在犹豫是否要学习的时候,我已经基于Flutter上线了一个Demo. 但是继续深入的事情那就需要等待合适的土壤了。

这两年离业务近了很多。做业务的技术同学有个普遍的困惑:业务结果是前提,并且以业务结果评估技术结果,在不公平,但是也没办法。因此很容易掉入业务说啥就做啥的陷阱,最后长出来的系统千疮百孔,岌岌可危。这里有一个明显的误区,业务!=业务owner. 很多时候,技术同学只是解决了业务owner的问题,并没有从更高的层次不断抽象,去发现和解决真正的业务问题。

如何避免成为 CRUD boy? 这其实是个伪命题。正确的提问姿势是:如何避免成为只是个 CRUD boy? 两个做法可参考,一是使用已有的轮子或者自己造轮子让这种层次的开发大部分自动化,二是把剩下没法自动化的部分交给团队的人员梯队去消化。

业务系统没有技术含量?这个应该是很多职场初期同学都会问的问题。本着先问是不是,再说为什么的原则:业务系统并不是没有技术含量,而是技术价值输出的对象以及兑现的方式发生了变化。底层核心/中间件层面的轮子很容易在输出给上层系统使用的时候体现其价值。这也是很多技术同学非常熟悉和认可的技术产品生产方式. Talk is cheap, show me the code可以认为也是这种价值转换的诠释。这种价值转换最大的参考案例就是github。然而,对于业务系统而言,Talk is valuable, write the code: 理解和抽象业务非常重要,直接决定了代码的价值。更大层面上,你要理解其背后的用户模型和商业模型。

业务系统技术同学的价值体现在:1. 业务域80%通用问题的技术抽象识别;2. 根据抽象识别选择合适的底座或必要时候能打造适合业务状态的轮子;3. 支撑业务是基线,加速业务达成,扩大业务基本面价值是生命线。对于技术同学来说,要时刻思考:抽离掉技术底座和业务后,你的价值是否归零。

但是,并不是所有的业务都能持续下去。小到一个按钮功能,大到整个公司战略。签字画押前,多跟业务同学沟通,以及业务的历史合作方了解。下定决定了,那就接受那些无法改变的事情。但是,有一点很重要,靠谱的同学无论做什么业务会抢手受欢迎。

一直愉快的合作是非常罕见的。大部分合作都是信用积累和消耗的往复过程。对于个人品牌亦如此。所以,我鼓励大家对人对事上都较真一点,该点出的问题就说出来,不想接的招直接打回去。如果你连内心真实的不认可都无法输出,那么你的赞许也毫无意义。

坦率讲,过去两年虽然发生了很多事情,但是还是觉得自己挺幸运的。遗憾留给过去,平和的心态走向未来。