2019年终总结

wu_sphinx · · 1429 次点击 · · 开始浏览    
这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。

2019年还是发生挺多事的,一直在想该如何写,拖到现在,这是病,得治。

西南飞东南

2019年初辞去成都的工作,来到了一家能源出行企业,从4年后端开发转变成为了一名“资深测试开发”,口味从无辣不欢到清新寡淡,变化让人惊喜,也带着些淡淡不适。

手机自动化测试

头三个月,从没接触过手机端开发的我接到做自动化测试平台任务,于是自备的锤子、苹果手机派上了用场,从领导的推荐开源项目UICrawler到自己发现的AppCrawler,拿来主义终归是没有找到满意的答案,又开始研究Appium自己写遍历代码,使用阿里的Macaca测试方案,还提了自己pr,研究FastmonkeyMaxim等第三方解决方案,始终还是不够满意,最后以为Airtest是银弹,结果发现并不满足于自动化的要求,发现目的有一些迷失、不清晰,最后也是以调研解决方案的demo形式完成了入职答辩,感觉很潦草,但是领导觉得还行,走出了从0到1这一步。

服务容器化

因项目需要终止了手机自动化测试的工作,加入到了服务容器化小组,说是小组,也就是我跟另外一位同事罢了。内心还是挺兴奋的,对手机自动化已经没啥兴趣了,服务容器化呢,因为开发经历的原因,是容器化的重度使用者,但从没有参与容器化的建设与设计。

rancher vs kubeadm

从加入容器化项目伊始,因如何安装k8s集群产生了分歧,由于经验的关系,我强烈推荐Rancher,原因是这是一套开源的k8s管理平台,很适合我们这种小团队,人手也不够。不过我没想到遇到了强大的阻力,另外一位同事觉得就应该用k8s原生的安装方式,原因是可以更好的“研究”k8s。后来我后现所谓的研究也只是安装k8s集群而已,并没有深入代码及k8s架构及其原理,我果断强推了一把rancher,先用rke搭建k8s用起来,让大家能看到rancher的易用性,虽然那位同事由于习惯的原因,依旧固执的要再安装一个k8s自带的dashboard, 但我总算是将rancher用起来了,由此这一争论算是告一段落了

centos vs alpine

容器项目的基础镜像用的centos,最终打包出来的镜像竟然有600M之多,我感觉很震惊,于是问为什么这么做,答曰:因为生产环境用的centos,为了稳定性,要保持一致。于是我开始了争取使用alpine做基础镜像之路,本机下载服务源码,自己打镜像,推到镜像仓库,又折腾了一番java服务,真是一言难尽。为此我仔细想了下为什么要用alpine,用几个考量:轻量化、下载快速、标准化。但是推行的过程同样很艰辛,作为项目的后来参与者,要跟前辈们争取,最后却被认为是激进。

模板 vs helm

服务部署在k8s里面初始形态就是各种资源文件,比如Service、Deployment、Ingress等等,可以自己模板,然后参数渲染,我刚进容器化团队的时候发现他们以前也是这么做的,但是写的过于丑陋。随着对k8s生态的了解,我在社区发现了Helm这一软件包工具,觉得很棒,为此还专门在团队内部做了一个分享,想推广使用Helm,以节省工作量,没想到依赖遭遇了强烈的反对,后来我才想明白,因为先期已经做了一个“容器平台”专门做模板渲染,Helm难免有抢功之嫌,此时我对人性有了新的理解,不过我依然热忠于做技术。

Jenkins vs gitlab

公司没有CI/CD基础设施,本着实践基础设施即代码的原则以及过往的工作经验,我用gitlab做了一个CI/CD流水线的demo演示,还向运维部门申请安装gitlab runner,得到的反馈:我们已经有了Jenkins,不用安装gitlab runner,CI/CD跟当前项目推进方案差别过大,连我们领导也没有经历这种自动化的开发部署方式,自然也难以获得支持,问题是没有CI/CD的支持,如果做容器化?没有办法,只有靠手动人力来做了

化整为零

公司是Java技术栈,Dockerfile不知什么原因用的是同一个,容器里面再套上脚本以作区分处理,这个做法几乎沿用了当前部署的模式,当时我觉既复杂又丑陋,自己花了点心思,将服务按类型整理成4种不同的Dockerfile,找不同的服务做测试,费了点工夫,也没有多少人反对,毕竟这是个吃力不讨好的活,不过直至离职时,这一方案才勉强被采用。

容器化的理解

服务容器化的初始目标是提高测试环境的运行效率,减少机器使用量,在初期,只是将原有的服务打包扔进容器中而已,这种机械的做法并不能实现服务容器化这件事,没有代码配置书写规范,没有DevOps使用文化,没有基础设施,没有架构的调整,是没法做成容器化的,不能让k8s来适应公司的服务架构,要想清楚为什么要容器化,为了节省机器?坦白讲,我没发现能省机器;流量染色?仅凭概念也没法做,合作推进受到了比较大的阻力,领导也不看好这个项目,一个字,难。(ps:容易的话还要你做?)

自下而上 vs 自上而下

作为资深测开,做着运维开发的活,却身在质量团队,在软件研发体系里面,处于较下的位置,没有多少人会认为质量团队有多少技术含量,甚至于一些自己人也觉得技术上是不如开发的,这就造成了自下而上推广的困难:信任。说实话,以前呆在开发团队,并没有觉得会有这种上上下下的问题,直至自己真实的遇到才后知后觉。如果领导一锤定音,是否容器化这件事就能更容易落地?

心生去意

容器化推进困难,没有多少成效,小组受到一些非议,不得已竟然要接业务测试的活,领导也打算放弃容器化项目了,而我对k8s这一生态非常感兴趣,所以尴尬的是是想做的无法落地,不感兴趣的却要做,怎么办,其实内心已有答案:做技术。坦白讲,公司从来不是技术优先的,背靠传统企业,自然政治意味比较浓。

辞职

裸辞

做出这一决定的原因一是不想给自已留后路,二是确实也没有想好做什么方向,三是单纯想尝试一下

方向

开发再加半年的k8s使用经验,对方向又迷茫了,思索再三,定了几个:1. k8s开发;2. 人工智能 3. 区块链 4. 物联网。这是自己想做的方向,并非优势所在

求职

面试第一家就拿到了offer, 做golang框架开发,写烦的纯业务的我,有点心动,不过因为公司较小,当时我竟然拒绝了

第二家做区块链,有笔试题,毫无准备的情况下,竟然连基本的SQL都写错了,结局自己是败了;

第三家面某为,一面还算轻松,二面算法题竟然没做对,现在想想还是准备不足,非常可惜,工作内容偏底层,做编程语言及编译器相关开发,只恨自己当时不够用心。

经历两周无试可面的情况下,在保证信息准备的情况下,对简历进行了润色,开始接连面试海康威视的容器平台开发,我有k8s使用经历,但无开发实践,全程尬聊,不欢而散;面西子联合旗下的工业互联网,跟技术与hr都聊的很high,最终竟然没有合到offer;小象教育,因为有所准备,笔试做的很好,一面挺不错,二面面试架构设计:笔记类应用设计,还有点带压力面,全线崩溃,深知自己架构能力的不足;面中控蓝卓,一面很轻松,二面觉得我做过的东西没啥难度,尤其听说我最近一段工作经历是测开,立马开始敷衍,虽自知结果,但面完也没有主动给通知;威佩网络面试有尝试,也有广度,有架构设计,但是最后给的offer实在是让觉得不快,工资没涨,所以也没接受;后面拿到两家区块链企业,都不是自己想去的,不过授受了其中一家的offer, 在入职前几天,面试了另一家做k8s开发的岗位,相谈甚欢,也算是一拍即合,果断放弃区块链offer。

总结

这一年,在容器化推进的过程中,积累了很多负能量,归根到底,还是能力不足,想做的事又很大很多,找工作的过程更是发现自己知识积累泛而不深,广而不精,焦虑的同时也比较迷茫,最终工作的方向还是满足找工作的期望,只是深知以后进大厂会更难了,不过这也更能激励自己,做好技术冷板凳,人若无名,便可专心练剑。2020年:把小事做好,把技术做精,少一些无用的焦虑,多一些实在的积累,量变终将引起质变,加油。


有疑问加站长微信联系(非本文作者)

本文来自:简书

感谢作者:wu_sphinx

查看原文:2019年终总结

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

1429 次点击  
加入收藏 微博
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传