highlight: atelier-plateau-light theme: devui-blue

文章基本按照時間順序，約5千字，內容講的是：一場意外被辭，一場説走就走的旅遊，一份5年親密陪伴，下水撈過魚，吃了“金蟬子”，野外路過營，舉辦了幾次技術直播，7個月成為了掘金優秀作者，我會簡單陳述一下2022，希望明年總結能有一些精彩。

`因為是參賽文章，所以希望您能`點贊、評論、轉發`或者`評論666

離職背景

程序員被忽悠，期權大餅香不香

兩百多萬的期權誘惑

200萬有多少呢？大概一整個行李箱，剛好裝滿。

可能你感覺200多萬不多，但我很動心。

因為hr百萬的承諾，離職來的這家創業公司。提前透露結局，最後是一場空。

所以當你面對要期權還是要現金的問題的時候，這個需要結合個人情況。

不過有一點是可以肯定的

口頭承諾不如一張紙來的實在

一些有關期權的問題

需要知道一些內容，簡單寫一寫： - 公司期權計劃，在哪裏上市，計劃分幾次授予 - 期權份額，每次授予的時間和條件 - 如何行權 - 期權回購 - 離職時期權是否作廢還是回收，回收價格

依舊打雞血的996，充實而滿足

這家公司996對我來説，也不算特別累。大多時候人生是一種態度，我拒絕做老油條，充分利用好平台，讓自己做大做強，基本上能抓住的機會都想爭取一下。

上一家公司是4個運維，幾個架構師，2個網絡，2個Dba。這次還在架構部門，不過這次也不同。

上一家公司技術中台構成： mermaid graph TD 技術中台 --> 運維技術中台 --> 架構師技術中台 --> 網絡技術中台 --> DBA 在這家公司，我負責devops產品設計、開發（這正好和我的研究生畢業論文一致），負責所有前端同學的開發工作，下面有4個產品線19個前端研發。其中devops基本流程如下：

整體功能很多，我僅僅以其中一塊功能的效果展示一下：

圖片 1.png

如上圖所示：研發雲是用户操作管理界面，負責 - build product - push product - manage k8s

新公司技術中台大體類似，基本上是：

```mermaid 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千左右。

這中間也有感動

第一，我的母親大人，妹妹，也時刻關注着我，我的每一篇文章，每一個沸點，下面人的每一個評論，她們基本每天都在翻看。有時候，還是老媽提示我，有人要轉載文章了，我才發現。

第二，我的幾位同事，基本每一篇技術步道文章都會積極轉發到朋友圈。他們的轉發和傳播，也是一種認可。

第三，掘金團隊，不知道他們能否看到這塊內容，掘金創作平台的流量扶持，以及創作平台的進步。我經常打錯別字，但平台總能友好的提示出來，給出合理的建議。而且，每次我發完文章，很快就能夠得到審核並推薦上榜，這其中跟運營團隊的工作時緊密合作是分不開的。這裏有人可能會説，這是在拍馬屁，但掘金平台對我的流量扶持，是一個不爭的事實。在此，也感謝掘金的運營團隊。