本文记录了自己的个人生活经历及其感悟,以回忆为主,文中所有姓名均为化名,无心对任何人或者是公司造成影响,如果可能发生,请联系我进行修改
找工作
为什么这段经历要从找工作说起呢?我主要是回忆起了那时候的彷徨与迷茫。从上一家公司离职后,我有点不知所措。就像我之前所诉一样,我不知道我能够匹配什么样的工作,明明感觉自己充满能量,但又觉得前路黯淡。
我明白我的特点是技术广度、快速上手能力以及发散性思维,其实这样的特点在什么岗位都是比较实用的,这在解决问题上是一把好手,不过这样的能力很难通过面试发现,我需要突出这一点。
我一共找了两周的工作,根据先前的工作经验,我是 Node.js 开发、项目经理、运维开发的综合体😕,这太难了😂。不知道是简历写得不好还是履历本来就不够吸引人,或许两者都有吧,我鲜有面试机会。正当我要放弃找工作打算先疯狂学习一阵做几个开源项目再找的时候,七陌电话邀我去面试。跟我约的时间是周五(也就是那两周的最后一个工作日),所以我就抱着最后试一试的心态去了。
这原本是一个运维岗,去了以后我从面试官也就是运维总监那里得知他们的业务越来越复杂,正在向微服务转型,当时差不多已经拆成有大大小小 60 多个服务,在考虑上容器了,甚至考虑为此组建一个部门。听到这个后,我显得比较兴奋,因为这正是我想做的事。我也表明了我的态度:“如果让我来做这个的话,我愿意一试,并且我有信心做成。”。公司的 CTO 张总正在做容器化相关的调研,他对于这方面比较了解,所以面试官拨通了张总的电话,让他对我进行专业的面试。我们互相都比较满意,所以没过多久我就得到了 HR 的通知。
新的起点
之前的公司10个人,新公司有200多人,从规模上讲,已经翻了好几倍了。现在还记得面试时,让我填的「职业生涯规划」,我有很认真的填写我要成为部门 Leader,结果我的部门就两个人,从编制上讲,还挂靠在别的部门😐。我心想我现在也刚进,以后肯定会招人的,先把自己事情做好就行,所以也就没想太多了。
带我的人叫石冷,我去之前,架构部门就他一个人,因此他一向比较忙,平日里都戴着个耳机也不多话,我找他基本都是发 QQ 消息😓。为了快速融入到公司环境中,借着团建做主持的机会,我用了不到两周时间就把成都分公司这边近80号人都认识了。
容器化方案
这是我在这个公司最重要的事,至少在进公司前我都是这么认为的。刚进去那会儿,不了解公司业务、不了解公司组织架构、不知道测试环境、不知道开发环境、不知道生产环境,总之是啥都不了解,石冷不爱说话,也从不安排任务,所以我基本上是被晾在那儿了😁。不过没有状况本身也是一种状况,我能做的就是在不浪费时间的前提下尽可能独立解决问题。首先认清目标,我来公司的目的就是出具并实施容器化解决方案的。
然后,我给自己设立了阶段性目标:
- 理清公司微服务架构的业务逻辑「我的天,60多个服务,分别是干啥的,他们之间如何协同工作的,没有文档,也不清楚」
- 学习 Docker、Kubernetes 相关技术「以前用的容器是 Zone,虽然接触过这俩,但并不多,想根据其能力出具解决方案还差远了」
针对第一点,我必须问,有时候会不好意思,但也不得不问,因为那是我开展工作的必要条件。至于第二点,翻阅官方文档进行学习,为此我还找石冷要了3台测试服务器。整个进展都比较顺利,我估计花了一个月的样子就出具了第一套过渡方案。主要策略是将原系统的中 Consul 和 Kubernetes 中的 etcd 的服务注册与发现的能力以及配置能力进行同步。我跟石冷讲了这个方案,他觉得还不错,我们就正式跟领导层进行了一场方案探讨的会议。可是,张总认为公司大部分研发人员连 Docker 都不了解,如果直接把 kubernetes 用起来有点太重了,难以落地,所以予以否决了『张总的考虑确实有道理,不过我觉得一个好的架构对于研发人员来讲应该是无觉察的,不知是否应当如此?😀』。尽管方案并没有落地实施,公司管理层对我的能力还是予以了充分肯定。
此事过去后不久,公司把我和石冷分别临时下放到了运维部和云客服部,说是让我们能够更好地了解业务以便设计出更接地气的架构。
去了庞然(运维部经理)那儿后,帮他协助私有云部门为私有云客户部署基础服务「MongoDB、Redis、Elasticsearch、Consul、Open office、Solr」,他们之前本来是脚本部署的,还要拷贝好多文件,特麻烦。为了简化流程,我把它们全部抬到了 Ansible 上来,感觉舒服多了「技能库里又多了件宝贝,开心😄」。本来待满一个月我就要回架构部了的,张总突然找到我说私有云部门的阿伟离职了,人手不够需要我,并且那边容器化方案更容易落地。于是乎,我就成了私有云老大湛成的手下。
去到私有云
私有云部门是一个业务部门,主要是为大客户提供自建云客服系统以及可能存在的定制开发服务。私有云项目从服务器批下来到最终完成交付大致会经历 PoC 测试和定制开发(如果需要)两个阶段。所以私有云下又有实施和开发两大模块,服务器给到公司后,会先由运维团队搭建基础服务(也就是我之前在庞然的团队所做的事情),然后由我部门实施人员搭建业务服务并做基本调通,没有问题后移交技术支持与售前。阿伟走后,湛成成了唯一一个具有实施能力的私有云成员,但私有云的工作量不降反升,所以这才把我调了过去。湛成来了成都后,组建实施团队便成了我的任务之一。最终我招募了两位小伙伴,并带他们参与实施工作。实施过程中最难的地方莫过于调通了,像 Consul、Nginx、MongoDB 都很容易出问题,有时调试时,需要用到各种前后端的编程知识,也只能自己去解决。
我们部署项目需要两个自主开发的部署工具:
- vole —— node 编写的 Web 工具,用于录入配置并生成配置文件
- lever —— python 编写的命令行工具,依赖于 Ansible,用于部署业务服务
两个工具都还有这样那样的问题,功能也不全,可能也就支持20来个服务吧。将实施任务交给两个新伙伴后,我开始了两个部署工具的改造之旅,我新加了些项目支持,修复了一些 BUG,甚至还改了下界面,也正是因为在这里更加真切地感受到了这些痛点问题,使得我对于容器化的解决方案又有了一些新的想法。在湛成的支持下,我又开始了我的容器化之旅。我还是用的 Kubernetes,不过这次我落地实施了。我用双容器 Pod 捆绑 Nginx 解决了程序中访问服务写死 127.0.0.1
的问题,并用 Endpoint 直接挂载 Kubernetes 集群以外的 Consul 服务和由 consul-template 渲染出来的 Nginx 代理服务;利用 namespace 解决了环境区分问题;利用 Configmap 解决了每个服务的配置问题;利用 secrets 解决 tls 证书存储问题;利用 Ingress 解决了外部访问的问题,同时有一种非常方便的方式添加或删除 tls 证书;利用 「nfs provisioner」 + storageClass 解决共享存储的问题。最后,我将60多个服务编成镜像放到 Harbor 仓库中,利用 Helm 将所有服务加到一个 application 中,解决批量布署的问题(以前部署一套环境两天,我将其缩短到了两分钟);利用 Telepresence 解决了远程调试问题。不用修改一点代码就将服务布署到了 Kubernetes 集群中。
这60多个项目,大多都是老项目,代码用 SVN 管理的,我没有 SVN 的管理权限没有办法添加 hook,所以我将所有项目都迁移到了 gitlab 上,利用 gitlab-runner 进行 CI/CD,自动化编译和部署,好不方便!新版的 gitlab 对 DevOps 支持就更好了。
公有云那边项目越来越多,再加上公司跟腾讯加强了合作,需要在除阿里云外的腾讯云上再建一套云客服系统。这时候石冷那边一个人忙不过来了,而我在私有云的事情基本告一段落了,于是湛成问我,要不要考虑回去,那里更能体现我的价值,于是乎,我又回去了。「😑老天仿佛跟我开了个玩笑,绕了一圈我又回到了这里」
回到架构部
回到架构部后,除了日常维护私有云团队的 Kubernetes 集群外,我还做了3件事:
- 开发 MongoDB 迁移工具;
- 为日志管理系统开发新的功能;
- 设计开发平台管理系统。
离开
是的,我确实有想要离开的想法,在一个公司来回折腾了几个部门,最后又回到了原来的地方,直到我离开之前,石冷还告诉我,等架构部门的事情做完后,我有计划被调到运维部去和庞然一起调研负载均衡方案。能被组织需要本身是一件特别幸运的事情,但我失去了归属感,觉得这可能与我职业生涯规划的理念相悖。当然了,公司有公司的想法,这本就无可厚非,只是公司在面试时问我要了而我也给了我的职业生涯规划,我觉得这在人事调动的时候还是可以稍微考虑一下的。
尽管我没有跟任何人讲过,并且很长一段时间我也不愿意提起,但我当时并非完全自愿离开的。
公司的代码库做了防火墙,直接锁死只有公司的 ip 能够通过公网进行访问,开发人员如果想在自己家中提交代码,就必须连上 VPN,并且在 git 项目中修改 git 仓库的 url,使用内网地址进行访问。我想到了一个解决办法,就是如果连上 VPN 后,访问 git 的公网 ip 走 VPN 服务器那条线,那就可以合理避免开发人员频繁修改仓库 url 的操作了。VPN 服务器在有客户端连接时,会将路由策略分发至各客户端,客户端根据该策略设置路由,只需要在路由分发上添加一条记录即可实现。我将我的想法进行了测试,保证确实可行没有问题后,我便添加到了 VPN 服务器上。我正为又解决了开发人员一大痛点而感到满足时,公司群里在讨论生产环境服务连接中断的问题。时间有点太凑巧了,但我一直觉得不可能是我的操作导致的,因为我操作的是开发环境的 VPN 服务器啊😳。
整个故障持续了一个多小时。由于我在操作前有向上头报备,运维总监很快找到了我,真是不敢相信😮。那时我才得知,原来生产环境的每一台服务器都连接着开发环境的 VPN,这还不算完,VPN 上 ip 地址分配策略居然跟阿里云的 ip 分配策略是冲突的,所以生产环境上的每一个 ip 地址都是根据阿里云的 ip 分配策略手动分配的,也就是说,ip 如果发生变动将导致网络紊乱😫。我知道了事情发生的详细情况,意识到自己踩了雷,便也不做辩解,当即表示愿意接受任何处罚。
第二天,我发现我所有公司账户都被冻结了,我就大概知道结果了,老实说我并不甘心。在结果下来后,我告诉了湛成,挺对不起他的,因为我很多工作都跟私有云部门亲密合作,很多计划将因此破产,让大家的心血付诸流水,当时也还在帮他做一个运营管理平台的框架搭建,因为我的离开这个项目也搁浅了。
下脚前,没有注意到那个位置有雷,我确有失察之过,假如我在决定操作或在重启 VPN 服务前,认真检查一下跟服务器连接的客户端分别是什么用途,也许就能避免了。为了走得体面一点,我甚至没有要一丁点的赔偿,而选择自愿辞职,若非今日忆起,我可能不会跟任何人讲。走的那天,张总给我来了个电话告诉我:“这件事情你本没有错,怪只能怪你运气不好,埋雷的人是公司创始人,他犯了天大的错,我们也只能削减他的股份,不可能让他走人,只是公司必须给客户和全体员工一个交待,牺牲你是一个让人心痛却又不得不做的决定。”听他说这些,我姑且就相信了吧,毕竟这能让自己心里好受些。后来,运维总监在微信里跟我也说了差不多类似的话,让我不要记恨公司。
心高气傲的我,曾经想象过多种离开的方式,唯独没想过会这样。一个人骑着自行车走在成都的大街上,明明灯火通明,却感觉漆黑一片,眼看着就要过年了,这时候失去了工作,我不知道我该如何告知我的家人、朋友还有我的爱人,也不知找下一份工作时,如何告知面试官我曾被选择😲。
或许,我真应该像我要离开时石冷告诉我的那样『决不做非自己职责范围内的事』吧?不过我真正学到的是,不管做什么样的事不可盲目自信,应当做好万全的考虑,以后无论做什么,我必将更加小心慎重。我还是那个我,初心不改,但挫折必将让我学会成长。如今,我不愿逃避,将此事记录下来,正视自己的错误,愿意面对并承担由此带来的一切后果。『👏我相信』