文章基本按照时间顺序，约5千字，内容讲的是：一场意外被辞，一场说走就走的旅游，一份5年亲密陪伴，下水捞过鱼，吃了“金蝉子”，野外路过营，举办了几次技术直播，7个月成为了掘金优秀作者，我会简单陈述一下2022，希望明年总结能有一些精彩。

`因为是参赛文章，所以希望您能`点赞、评论、转发`或者`评论666

离职背景

程序员被忽悠，期权大饼香不香

两百多万的期权诱惑

200万有多少呢？大概一整个行李箱，刚好装满。

可能你感觉200多万不多，但我很动心。

因为hr百万的承诺，离职来的这家创业公司。提前透露结局，最后是一场空。

所以当你面对要期权还是要现金的问题的时候，这个需要结合个人情况。

不过有一点是可以肯定的

口头承诺不如一张纸来的实在

一些有关期权的问题

需要知道一些内容，简单写一写：

公司期权计划，在哪里上市，计划分几次授予
期权份额，每次授予的时间和条件
如何行权
期权回购
离职时期权是否作废还是回收，回收价格

依旧打鸡血的996，充实而满足

这家公司996对我来说，也不算特别累。大多时候人生是一种态度，我拒绝做老油条，充分利用好平台，让自己做大做强，基本上能抓住的机会都想争取一下。

上一家公司是4个运维，几个架构师，2个网络，2个Dba。这次还在架构部门，不过这次也不同。

上一家公司技术中台构成：

graph TD
技术中台 --> 运维
技术中台 --> 架构师
技术中台 --> 网络
技术中台 --> DBA

在这家公司，我负责devops产品设计、开发（这正好和我的研究生毕业论文一致），负责所有前端同学的开发工作，下面有4个产品线19个前端研发。其中devops基本流程如下：

整体功能很多，我仅仅以其中一块功能的效果展示一下：

图片 1.png

如上图所示：研发云是用户操作管理界面，负责

build product
push product
manage k8s

新公司技术中台大体类似，基本上是：

graph TD
技术中台 --> 运维
技术中台 --> 中间件团队 
技术中台 --> 网络
技术中台 --> DBA
技术中台 --> 效能团队

架构上区别不是很大，其中组织架构上不同的是：

效能团队，负责UCP（研发管理系统），包括研发管理和维护；
中间件团队，负责中间件es/kafka/sentinel/hbase/obs/redis/skywalking等，包括研发管理和维护；

除了架构的不同，微观上我在这家公司的职能也出现了变化。我不再负责前端团队，不用再给下面的人打鸡血，求加班。虽然偶尔会帮业务解决个问题。但更多的时间可以做一些自己想做的事情。虽然不用逼别人加班了，可完全还是996的模式。

下面介绍一下我在这家公司都做了哪些内容。

维护老系统

到哪家公司，都难免要填坑。老系统还在运行，当时偶尔维护老系统，分别是：

dbms
kbx---es

一个是angular和vue两个版本的dbms，也就是数据库管理系统。

另外一个是react的es管理系统，常见es的查询，导入和导出。

彻底填好是一种办法。大多数人都想要重建，这确实是一种办法，无可奈何之间，就一定要耐心。

这两个系统都包含了常见的组织架构角色权限、列表详情。这就很容易和别的系统出现“鸿沟”。我们也很自然的想要重建。当时还从上一家公司“挖”一个同事来帮我，他的到来确实让我轻松很多。

但这些老系统还是犹如悬在脑袋上的达摩克利斯的剑，总有“意外之喜”会时不时蹦出来，让人“负重前行”。

“重新造轮子”，但是说服公司，需要综合考虑成本等多个因素。

搭建三套系统

在这家公司主导设计搭建了三套web系统（为什么不是一套而是多套，这个有强烈的研发人员的因素在里面），包括：

redis管理系统
obs管理系统

其实跟常见的管理后台很相似，基本是登录-列表-详情加上表单创建编辑那一套。

然而，每次做一个系统，理需求，做设计，画交互，写代码，上线，都需要认真“揣摩场景”。

虽然整个过程还是老样子，但多一些“用心”去做，收获可能会更多，比如更多的了解了系统架构中中间件以及缓存系统的重要性。

新建三个一级页面

除了这两套系统，公司本身也在使用apm产品中的skywalking。

skywalking确实是很经典的开源产品，也能解决一部分企业问题。但skywalking更像是一个“拼凑”出来的产品，而且最重要的是，他的ui界面非常不友好。限于skywalking缺点，我们做了二开，开发了三个页面：

错误大盘
应用拓扑
核心链路

错误大盘功能介绍

为什么要做错误大盘，其实更多的是想让：

研发更快地看到错误，及时跳转
业务负责人及时“guance”错误的趋势

应用拓扑功能介绍

这里用到了图数据库nebula，同时对是图还是树做了一些思考。

需要提及的是，Skywalking内置了服务拓扑关系，但性能非常差，这也是我们开发上述功能的原因，为了提高这部分的处理性能，我们采用了Lambda架构，周期性生成拓扑快照，同时与增量拓扑叠加实现拓扑结构查询功能。恰逢这个时候看了全球运维大会，其中时序数据库TD engine的陶总的创业精神，深深的感触到了我。在今年8月份，我还参加了TD engine的3.0发布会，左边的是我。

也再次听到了陶老师激情的演讲

核心链路功能介绍

由于系统的复杂性以及告警规则设置的差异性，线上告警是经常发生的，为了避免被告警轰炸，又开发了核心链路监控功能，仅关注核心链路请求响应时间、错误率两个重要指标，通过这两个指标可以快速判断业务主流程是否正常。

核心链路也是这个时候做的。我的有关apm的思考也来源于此。以往文章有过叙述，这里就不赘述了。

上午还在对需求做规划，中午就被提了离职

魏总是直接负责整个架构、运维、中间件团队，也是我这几年的领导，中午告知我，他被辞职了。。。

老大被辞，资本寒冬，业务不佳

大家都人心惶惶，毕竟公司“业务转型”今年也不是第一次。公司对我也没要求，上面无需求下来，下面业务也在停滞，很多研发整天都无事可做。

一张废纸，匆匆离场

两周后，公司给了N+1和一些假期，中间我也不去公司上班。

黯然离场准备去散心

程序员搞旅游，说走就走

我很怕冷，当时已经冬天了，自14年从马来西亚回来之后，就再也没有过长的旅游过，于是想出去转转。

经过比对，选定了云南这个地方。当时离职有10W+的补偿，自己做了2W的预算，报了团。

第一站昆明，四季如春，有点慢，很静。

第一次知道昆明，是09年在一篇国家二级笔译备考文章中，当时文章描述昆明四季体感如春。

正好也适合中转到其他地方，我看了一下机票，选择了晚上两个小时的那班飞机。

大兴机场

以前两耳不闻窗外事，还没去过大兴机场。

昆明海埂大坝

这里生活节奏和北京比，没有那么快，也很安静。我在昆明第一站是海埂大坝，据说海鸥是从西伯利亚过来的。

我随手拍了几张照片。

第二站楚雄

在靠山的类似小山村的地方，我们住了下来。

晚上我出去遛弯，这里有家特别好吃的兔肉店，去了的同学可以搜一搜。

其他地方：西双版纳、丽江、大理古城、茶马古道、玉龙雪山

然后还去了云南旅游基本都不会错过的，丽江古城、洱海、大理古城、玉龙雪山以及西双版纳。

其中西双版纳是边境，所以这边会管控稍微严一些。

程序员养宠物，Ada5岁了，给小美女找个男朋友

下图下面的小狗狗，便是这里的主人公ada（名字源于一种编程语言）。

算一算，ada陪伴我已经有5年了，也到了该生育的年龄了，家有萌宠且有意向的小伙伴可以私聊我。

刚出生时，Ada是这个样子。

四五个月大的时候ada已经基本能分辨出厕所、阳台、厨房这些词语了。

北京第一场雪后的Ada

应该是2月份北京的第一场雪，我就带她出去了“踩雪”

北京夏天贪玩的Ada

ada非常喜欢在草地上玩，今年我经常跑步的河边在修路，不是很适合跑步，所以我俩今年散步多一些。我会在散步路边一个草坪上，把她放开，让她自由自在一会儿。

在家悠闲自在的Ada

ada在游泳

ada变装

ada在露营

更多有关养宠物的事情，小伙伴可以私聊。

程序员搞可观测性，观测未来，走好每一步

19-21年一直在业务和架构的线上，工作变动后，要做可观测性“步道师”，一下子还是很难转变的。今年基本上，可以分为这几块：

技术交流
解读源码
文章输出

程序员搞技术交流，从忐忑到自信

这一年技术分享比较多，接触了：字节APM团队、美团、去哪儿等众多公司，了解到了不同公司对于这些方面都存在各自的痛点：

用户体验，rum
系统性能，apm
日志治理，logs
告警轰炸，alert
平台割裂，data

以上这些，都是多年来互联网快速发展带来的经验和痛点，很多公司都或多或少的存在。

优势很突出，缺点也很明显

k8s是非常明显的短板，所以在23年第一个Q一定要将cka拿下。

程序员搞写作，菜鸟小白变优秀作者

从2022年5月份开始接触写作平台，开始了在平台的写作。

写作能将平时的思路做一个梳理，也能把一些经验教训分享出来，而不是单纯的依靠平台自吹自擂。

很多情况下，要杜绝一年工作重复了十年情况的出现，就一定要多思考，虽然一思考上帝可能会发笑，但成长总要栽跟头，不突破舒适区，永远不知道哪种死法更快。

程序员搞直播，兴奋但平稳输出

有多次直播，目前还有印象的是：

《观测云有观点》
《如何借助saas服务提高用户体验》

此外，在今年的最后一个月，我在极狐还有一场有关研发管理效能的直播。也欢迎大家到时候来捧场。

掘金文章输出

掘金平台

经过6个多月的时间，最终成为了优秀创作者。哈哈，手动给自己点赞。在决定更要写技术文章时，我给自己的定位是“步道师”,要更多的人注重提高研发质量，更多的人关心到前端同学的艰辛。

这里我首先选择了掘金平台，当然我在其他平台上也有尝试，不过就不在这里赘述了。我只介绍我对掘金的一些看法。

首先掘金确实是一个还算很可以的技术平台，上面已经积累了很多优秀的人和团队，他们分享的内容也都让我受益匪浅。

其次，掘金在前端领域内容的聚集相对比较多，虽然同质化严重，但是我们也都有自己的判断，文章内容质量高低，是摘抄知识点，还是真实案例总结，基本能筛选看出来。

最后，掘金也有相对比较负责的快速运营团队，他们的人都非常有责任，既相对保守，又相对开放，是一个在成长中的平台。

文章统计数据

我自己在掘金上，基本还是按照一周一篇的节奏，今年总共输出大概30篇文章，每篇阅读量基本在8千左右。

这中间也有感动

第一，我的母亲大人，妹妹，也时刻关注着我，我的每一篇文章，每一个沸点，下面人的每一个评论，她们基本每天都在翻看。有时候，还是老妈提示我，有人要转载文章了，我才发现。

第二，我的几位同事，基本每一篇技术步道文章都会积极转发到朋友圈。他们的转发和传播，也是一种认可。

第三，掘金团队，不知道他们能否看到这块内容，掘金创作平台的流量扶持，以及创作平台的进步。我经常打错别字，但平台总能友好的提示出来，给出合理的建议。而且，每次我发完文章，很快就能够得到审核并推荐上榜，这其中跟运营团队的工作时紧密合作是分不开的。这里有人可能会说，这是在拍马屁，但掘金平台对我的流量扶持，是一个不争的事实。在此，也感谢掘金的运营团队。