锐客网

  1. 首页 > it技术 > >

2019年终总结

2019年还是发生挺多事的，一直在想该如何写，拖到现在，这是病，得治。
西南飞东南 2019年初辞去成都的工作，来到了一家能源出行企业，从4年后端开发转变成为了一名“资深测试开发”，口味从无辣不欢到清新寡淡，变化让人惊喜，也带着些淡淡不适。
手机自动化测试 头三个月，从没接触过手机端开发的我接到做自动化测试平台任务，于是自备的锤子、苹果手机派上了用场，从领导的推荐开源项目UICrawler到自己发现的AppCrawler，拿来主义终归是没有找到满意的答案，又开始研究Appium自己写遍历代码，使用阿里的Macaca测试方案，还提了自己pr，研究Fastmonkey、Maxim等第三方解决方案，始终还是不够满意，最后以为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。
总结 【2019年终总结】这一年，在容器化推进的过程中，积累了很多负能量，归根到底，还是能力不足，想做的事又很大很多，找工作的过程更是发现自己知识积累泛而不深，广而不精，焦虑的同时也比较迷茫，最终工作的方向还是满足找工作的期望，只是深知以后进大厂会更难了，不过这也更能激励自己，做好技术冷板凳，人若无名，便可专心练剑。2020年：把小事做好，把技术做精，少一些无用的焦虑，多一些实在的积累，量变终将引起质变，加油。

    推荐阅读


    上一篇：瘦下来，你的生活会发生怎样的改变（）

    下一篇：是缘份来了还是赌石（）