“小森林” 码工版

2020-06-28 作者:

明.陈全之《蓬窗日录》卷八:“春耕夏耨(nòu),敢辞涂足之勤;秋获冬藏,实切资身之望。”

日剧《小森林》,前后两部四集,全面的描绘出一个不甘挣扎于城市枯燥生活的妹子,返乡后独居,靠自己一双手打造返璞归真“小确幸”的图景,唯美、静心。本是2014/2015的片子,不知为何,去年突然火爆国内,还盖上“日版李子柒”的标签,颇觉给脑袋里整日萦绕“逃离北上广”的年轻人们一丝抚慰。

“农协开的小超市,冬雪中需步行一个半小时,而去临镇的大型城外超市购物,来回要一整天”,一句话下来,心凉半截;前可着村,但后不着店,换言之,一切靠自己了。

剧集展现给我们的,也确实如此:一日三餐,每餐结束之后,手头活计如果不是在准备下一餐,应该就是在准备下N餐(腌制发酵食品,或晾晒干制食品),日复一日,周而复始。另有国产美食剧集《一人食》好像也是在2014年上线的,并没有很火,我也没有看过,家里那口子倒是个不折不扣的美食爱好者。

洋洋洒洒说了这么多,跟码工又有几毛钱关系呢?码工嘛,又称“互联网从业者”,算是近年实体经济普遍乏力后,苦出身底层娃们为数不多的上升通道了。

所谓互联网大厂,自然有大厂的好处。流水线作业毕竟分工细,需求有人出,测试有人做,UI有人画,运维有人管,自己聚焦自己的一亩三分地;即使起新项目,研发主管还给脚手架工程做参考,说到底,搬砖就搬自己的砖,搬多少块结多少账,公平合理。要在大厂晋升,当然也是有讲究的。真材实料不可或缺,搬砖一路搬到CTO多半不可行;即使做技术主管,也得有点架构意识,当个“流水线线长”,知道不同目标需求下的技术组合和性能指标,关注外界趋势,跟合作项目组打太极,了解手底下那几个货适合搬什么砖,以及他们万一不干了,排队来搬砖的还有谁,等等。

言而总之,大厂工作如果不来点自黑,比拼个端午、中秋礼包设计,那真像极了城市生活两点一线,日子不停复制粘贴的感觉。作为移动互联网时代流水线工人,面对“弹性工作”、“996”等潜台词,再看看蒸蒸日上的业务,合同上不菲的现金和RSU,照旧叹一口气,进会议室继续抢项目撕B。

那你的意思是,码工也能回村自给自足,搞“一人码”?

也是,也不是。

全栈工程师不新鲜,算得上自给自足。至于要不要回村,您请自便,如果是农业创业,老板、市场、销售、PM、DevOps、运营、物流啥的您都一人扛了,咱也佩服;如若仅仅实现一人码,那大可不必,怎么也得考虑对接需求方要顺畅吧。

呃……废话太多,来点干货。

好吧,这篇围绕“一人码”的博文,其实来自于处理我“一人码”的一次线上故障。

故障现象:

  • 早上送娃出门前,发新版代码上线。
  • 开车路上,收到服务报警短信。
  • 娃上楼后,车内开热点连服务器看日志,花5分钟找到问题。

直接原因:

  • 新需求设计,需要使用用户二级权限。
  • 需求实现时,发现老的二级权限设计缺乏灵活性。于是新建用户二级权限表,完成需求。
  • 代码上线后,重启API服务,线上前端功能验证无误后,移除旧的二级权限表。
  • 异步框架未同步重启,导致给用户的微信模板消息无法推送(原因是join不到旧的二级权限表),10分钟内服务监控报警

解决方案:

  • 异步框架重启,30秒内积压消息尽数推送,无一失败,线上业务恢复。

深层原因:

  • 测试不足。
  • 进一步讲,一人码因为repo里不会出现不愿意碰的代码,因此看到之前实现不佳的地方,就会主动重构。在重构涉及面广的时候,加上自测不足,有可能造成线上故障。

内心感受:

  • 幸亏从第一次线上故障就花时间做了简单的服务监控报警,真的是太及时了!

如此这般 “一人码” 是何种体验呢?

见图,所有实线模块(虚线部分是合作团队开发)都是在下一人建设。没有黑科技,也没有新技术,自己写的code自己要能长期维护,可靠,可扩展。

  • 需求设计是不是匹配需求逻辑?没人评审;
  • 架构是不是合理,够不不够性能,有没有过度设计?没人参考;
  • 编码是不是符合规范?没人监督。
  • 自己两年前金光闪闪的产出,现在看着那一坨嵌套判断就坑爹,要不要重构?没人逼你。

爽!整个一个“我不要你觉得,我要我觉得。”

一人吃饱全家不饿,再没有开不完的会和甩不完的锅,听起来是不是不错?

一切靠自己,若设计合理,自然自己省心;不合理也好办,自己运维,自己背锅,喜欢后半夜处理线上故障,也没人拦着你。

时间长了,发现反而对自己要求变高了 —— 格子间上班,不愿做饭就点外卖,活儿干砸了上司先扛 —— 现在自己屁股自己擦。而且时间变慢了,不用盯着排期交出自己都懒得做“冒烟”的渣代码,为了API响应时间调查一个慢查询可以调试一下午。

当然,以上还只是需求实现的coding层面,别忘记你还需要基础设施。

什么基础设施,sudo apt install mysql-community-server?还好吧?

非也……

  • 先选个机架式服务器,Xeon Silver/Gold,双电,SSD/SAS盘,RAID啥的配好。
  • 再来个虚拟化环境,什么openstack、esxi、proxmox的自己选择;客户要求高的,服务器再来仨,带上超融合玩一圈。
  • 客户机房实施环境提前规划好,占几个VLAN,NAT怎么做,维护咋弄,把网络接入计划报给客户评审。
  • 虚拟机搭起来,镜像之类准备好,vm定期snapshot什么的琢磨清楚,别上线没跑仨月,自己挖坑把自己埋了。
  • 然后可以准备一般意义上的基础设施了,vm需要的Linux发行版选择,DB的主备和proxy,各种库版本和环境变量……

What?要吃个大盘鸡,我还得从孵鸡蛋、播小麦和种土豆开始?

干不干您随意哈,但还是那句话,没人评审你的设计,也没人替你背锅。所以从Day One就得考虑架构设计(包括vm host选哪款CPU),越是没人看着越是小心谨慎,古人那句话怎么说来着?

“君子慎独”

窃以为不敢自视君子,也不算道德高尚,唯有一点“just wanna make the life easier”。对客户负责就是对自己负责,多测一个场景,多catch一个exception,将来就少接一个电话,生活就轻松一点,不是么?

只从自己的角度出发,忘记客户的多样性,少年,你想简单了

别忘记离开了大厂,你就不再是螺丝钉,客户也都不再是PM提供的user profile那个样子,变成了真实的“甲方爸爸”。

因此你的设计不是简单到自己能handle就好,更不是能满足当前需求就好,因为没人给你拆好可实现的需求,真实需求往往就是甲方爸爸的微信截图几句话……

  • 自己分析客户意图(以及冰山之下的部分)。
  • 自己琢磨交互、UI、动效。
  • 遇到不可实现的情况,自己联络客户或销售,workout出可实现的产品。
  • 预估实现后可能遇到的反馈,以及同类型客户可能提出的延伸需求,在设计上留有扩展余地。

以上就是“一人码”的普遍生活图景,多数时候每天都不重复,很少有时间去深入把一个东西搞到极致(举例,集群中的高可用块存储);你自己评估实现成本+运维风险,与客户需求及系统扩展性之间的均衡,提出合理的实现方案,跟甲方爸爸做好沟通。

所以这就是“小森林”码工版?

嗯,差不多了。

还有最后一点,你有时间读书、也有时间看新技术,跟着文档搞Hello World。不管经史子集,创业理论,还是新技术新框架的自学自练;原来在大厂听个分享就来的知识点,现在全靠你自己了。

不搞也可以,手头那点吃饭本事,再忽悠5年或许也玩得转。但搞了新玩意之后,哪怕上手的时候并不为某个具体需求,也没有明确目的,而一旦遇到适用场景,采用新技术解决又快又稳还不造轮子的时候,那种成就感着实不是一笔季度奖就能cover的。

一人生活,也要规划好每一天,食必知味,过的有仪式感。

一人coding,同样做好架构,拆分模块,准备两份以上的异地冗余,降低代码重复度,适时重构,排除slow query,跨服务调用尽量异步,应对故障准备好服务报警和降级措施,高风险场景提前演练;没事练练左右互搏(自己开发的两个系统间调用也遵循不信任原则),让多个子系统对接起来,就像个团队作品。

一句话,人,要过的有点念想,别轻易放过自己,也别轻易苛责他人(因为他们也同你一样,不愿轻易放过自己)。

原创文章,转载请注明: 转载自渔人小径

本文链接地址: “小森林” 码工版

打赏 PayPal

文章的脚注信息由WordPress的wp-posturl插件自动生成

打赏 赞(4)
微信
支付宝
微信二维码图片

微信扫描二维码打赏

支付宝二维码图片

支付宝扫描二维码打赏

最近文章

分享

发表评论

电子邮件地址不会被公开。 必填项已用*标注