在大淘寶技術,前端、後端、演算法工程師的日常是什麼樣的?

語言: CN / TW / HK

演算法工程師的思考、寫程式碼的時間是怎麼分配的?前端工程師每天都在幹什麼呢?後端工程師衡量工作的重要指標是什麼,給誰提供服務?

我們邀請了演算法、前端、後端三位工程師,來看看他們的工作日常。

01推薦演算法工程師的日常

閱謙

大家好,我是來自大淘寶技術的一名推薦演算法工程師。下面以我電腦記錄的App使用時間為線索簡單分享一個演算法工程師的日常~

1. Chrome

Chrome是佔用時間最多的App,日常工作中有絕大部分的任務是通過瀏覽器完成的,主要包含以下4個方面:

檢視業務資料報表

每天到公司,我的第一件事情就是檢視最新業務資料報表,這包括大盤的資料、AB的資料和各個細分維度的資料。瞭解最新資料情況可以指導我們下一步工作的展開。演算法的優化是一個不斷迭代試錯的過程,及時獲得反饋並進行調整是非常重要的一環。

進行資料分析和建模

在機器學習領域,garbage in garbage out 意味著如果送給演算法的資料質量不高,那麼得到的結果也不會太好。曾經我就有過因為在準備資料過程中不小心出現樣本穿越的問題,導致後續整個的模型訓練得到的結果都是不可信的,後來又花了很多時間來排查問題和重新搭建資料鏈路。除了演算法使用的資料外,資料分析的邏輯不合理也會引導我們採取錯誤的行動,這樣的行動很可能對業務是無效甚至是負向優化。重視資料環節可以起到事半功倍的效果。公司一般通過DataWorks網頁端進行資料處理程式碼的編寫和定時排程節點的釋出,這佔用了日常工作的大部分時間。

業務方案和演算法模型的部署和釋出

推薦演算法工程師是需要面對線上流量的,而所有的業務邏輯和演算法模型從離線到線上都需要經過一個釋出的流程,通常是先灰度,再小流量,然後逐步擴量最後全量。公司的中臺團隊開發了諸如TPP,BE,RTP等平臺,演算法工程師可以聚焦於演算法和業務本身,工程性的工作由平臺完成。在這些平臺的網頁端,我們可以快速完成業務方案和演算法模型的釋出工作。

學習充電

公司內部有一個技術分享論壇,可以說是演算法工程師的寶藏之地。在這裡有各個業務線和不同崗位的同學分享自己的實踐經驗以及對前沿技術的解讀,每次逛都有很大的收穫。另外,閱讀一些領域相關的paper可以保持對技術的敏感性,如果發現不錯的思路可以結合自己的業務場景進行嘗試。最後,我還會在github等技術社群看看有沒有什麼實用或者有趣的專案,作為技術儲備或直接進行復用。我自己在業餘時間也維護了一些推薦相關的開源專案,感興趣的朋友歡迎加入一起學習交流~https://github.com/shenweichen/DeepCTRhttps://github.com/shenweichen/DeepMatch

2. DingTalk

DingTalk就是大家熟知的釘釘,在公司裡大家都是協同辦公,每一個業務模組的迭代都涉及到諸如產品,運營,開發,演算法等不同崗位的同學。高效的溝通交流對推動工作前進來說非常重要的。除了協同,日常工作中使用公司內部工具可能會遇到一些問題,這時候也需要和相關答疑同學交流解決。我有時候也會看別人交流,在一些群看別人聊天也有收穫。

3. PyCharm

PyCharm是我常用的Python IDE,主要用來編寫各種tf的模型程式碼。也許很多未工作的同學覺得演算法工程師的日常就是寫模型,調模型,就我自己而言,寫模型程式碼的時間相對並不多(這也得益於公司的強大中臺和內部開原始碼庫)。

4. PowerPoint

團隊內部有分享機制,我們分為業務分享和演算法分享兩大方向,截圖的這周正好是我準備PPT的那周,所以花了一些時間寫PPT。除了內部分享,在季度末,績效季末,晉升季等時間點,也會投入一些精力去做工作總彙報的PPT。

5. Intellij IDEA

Intellij IDEA是一個java IDE。除了演算法模型和資料處理外,整個推薦系統的鏈路從使用者請求到來到諸如畫像獲取,召回,排序,重排等模組的串聯也是需要演算法工程師來實現的。公司裡一般通過編寫java程式碼實現,所以給即將入行推薦演算法的同學們的建議是除了Python外再學一下java或者cpp吧!

02 前端開發工程師的日常

時川

加入阿里第 6 年,目前負責集團內使用者量最大的頁面搭建平臺:斑馬。使用者在淘寶瀏覽各種商品活動頁面的時候,中間有很多頁面就是通過這個平臺釋出上線的。我的日常的主要工作就是圍繞淘寶的搭建服務能力建設展開。

嚴格意義上來說,我是一個“圍繞前端工作”的工程師,或許叫做“面向運營交付前端頁面解決方案工程師”更合理一些,日常工作總的來說可以分為兩部分:

  • 搭建平臺服務支援
  • 產品建設和技術探索

1. 搭建平臺服務支援

大白話講就是答疑,解決使用平臺產品的技術研發同學和業務運營同學遇到的問題,一般會基於自己負責的系統鏈路,或面向業務運營,或面向技術開發。由於我負責的平臺比較特殊,這兩部分都有涉及。

面向研發的服務支援

一般從業務的技術選型階段就會開始介入,提供基於搭建體系的專業技術方案支援,包括基礎的前端框架方案、頁面的渲染服務(SSR、CDN等)、面向個性化場景的資料閘道器服務能力等,涉及的面會比較多,因此必須瞭解整個技術生態和服務體系。在業務技術側確認好相關的技術方案後,就進入了常規的前後端研發流程,這裡一般只需要協助解答一些搭建域特有的技術規範問題即可,直至業務正式釋出上線。後續研發側基本上就進入了一個業務自運營的階段,在平臺能力和業務需求場景沒有太大變化的情況下,我們很少需要長時間的持續投入的場景。

運營服務支援

對於運營的服務支援,除去一些基礎的功能指引,更多的是業務實際需求場景的問題。這部分對於技術研發來說還是比較有挑戰的,因為技術同學的邏輯思維慣性比較大,非常容易把業務的需求過度技術化,面向運營的服務,需要切換到一個完全不同的視角,去消化理解使用者的實際訴求,從產品流程層面給到對應的支援。同時收集相關的資訊,最終再反饋到後續的產品建設中。

2. 產品建設和技術探索

作為一個平臺的產品、技術負責人,從產品的整體發展規劃,到面向內部運營的搭建平臺研發、面向終端使用者的基礎渲染方案架構都需要參與,真·全(省)棧(錢)工程師無疑了。

  • 產品規劃及演進。基於使用者業務場景和需求,不斷演進搭建服務的能力,讓平臺上的業務能夠更快的交付上線,同時作為淘寶搭建服務的重要組成部分,斑馬也是搭建基礎服務和上層業務的橋樑,這期間會持續把業務能力做剝離和抽象,推動底層的基礎搭建服務能力進行迭代。大白話翻譯就是:我兼職 PD~。當然整個專案組的同學都會參與到這項工作中來,因為都是前端線的技術研發,我們建立了一套基礎的產品方案評審流程,從基礎的技術方案實現,到產品互動流程優化,按照雙週的節奏進行評審、研發、釋出。
  • 運營端平臺的架構和研發。這部分工作佔據了我大部分時間,也比較繁雜,因為要面向眾多業務,需要確保平臺的架構足夠輕巧,不被業務侵入的同時具備足夠的靈活性和擴充套件性。總結幾個關鍵詞:Node.js / Midway / Fusion /  飛冰,基本上涵蓋整個平臺的技術棧,這些多是一些軟體工程的基礎實踐,這裡不再贅述。
  • 消費者端渲染方案探索。這是一個技術側比較純粹但是關聯鏈路比較多的部分。核心目標是讓終端使用者更快地訪問到頁面,目前主要是和大促會場的同學共建,將雙十一等大促活動中通過考驗的極致方案通用化,覆蓋到更多的業務,關鍵詞:Rax / Weex (沒錯) / FaaS / EdgeRoutine / CDN

3. 除了工作還有什麼?

  • 肝原神。每天中飯時間我都會先擼半小時打個日常再去食堂,錯峰吃飯還能打個折,精緻省錢大佬無疑了(話說最近好不容易攢了 8000 原石想抽個凌華結果歪成了琴團長,還有救麼=。=);
  • 奶娃。工作日會爭取在 6 點左右下班回家,常規陪玩陪練(我不會告訴你我家學的二胡,每次開練都怕樓上樓下的鄰居打進來),雙休日條件允許的話一般會周邊一日遊(家住杭州但是基本不去西湖那種),比較喜歡去野外探索,不僅環境好,還人少,小朋友們也能更多接觸大自然;
  • 折騰魚缸。幾年前迷上草缸,後來又添置一個原生缸,雖然缸都不大,偶爾坐在草缸前面看水草冒泡泡其實挺解壓的,家裡小朋友也喜歡缸裡的小魚小蝦,放個照片吧;

03 後端工程師的日常

松香

作為一名阿里巴巴普通java開發工作者,從工作模組和職責的角度,給大家分享一下我的具體工作範圍,並從個人經驗角度給新人一些建議。在阿里巴巴,像我這樣的一個普通java開發工作者的工作時間普遍是早上9點到晚上8點。具體工作內容可以分為開發,運維,答疑,每一項工作的時間佔比對於不同崗位職責的同學比例也有所區別。在一個成熟的中介軟體或運維團隊,答疑運維的時間和工作量更多;而在一個初創的剛起步的團隊,開發的工作量會更多。我的具體工作內容如下——

1. 開發工作

廣義的開發工作的內容非常複雜,涵蓋的範圍也非常廣,從最基礎的開會討論環節(例如需求評審或設計評審)到狹義的開發環節即程式碼Coding實現到測試和上線都是屬於開發工作的一部分,詳細來說開發工作包含了如下內容:

2. 需求評審

在專案中,需求分析是最開始的工作,同時也是最重要的工作。在這一步驟中,開發人員需要和產品經理,測試等人員就專案目標、需求理解、系統原型、術語定義等達成一致。

3. 系統設計

在理解專案的目標之後就可以開始做系統設計,其中包含了技術選型(專案使用什麼語言,使用什麼框架,資料持久化選用sql/nosql,資料庫又該選用什麼),模組拆分(大到閘道器/入口/功能/基礎設施的架構分層設計,小到具體功能間的耦合拆分設計),細節設計(通過諸如時序圖,類圖等描述某個功能或者設計的關係與流程,定義互動協議的資料格式),設計評審(通過團隊內外評審的方式查缺補漏看看設計是否有錯誤或者是不恰當的地方)。這一步在整體開發工作中有著至關重要的作用,一個好的系統設計可以非常有效地減少編寫程式碼時的思考和工作量。

4. 程式碼實現

在完成系統或者是方案設計後,就可以按照預先定義的流程進行程式碼編寫和實現,在完成編寫後需要邀請1位以上同學進行CodeReview評審程式碼的質量與邏輯的完備性。

5. 測試迴歸

對於開發人員來說,測試主要是程式碼層面和功能實現層面的測試,前者主要是編寫unit test單元測試以方法或者類的維度驗證程式碼的正確性,後者是功能編寫完畢後進行全鏈路的測試從入口開始編造流量看整體效果是否和預期一致,通常這步也需要專業的測試人員介入,在出現異常問題時,需要進行debug和問題修復。

6. 功能上線

任何一個功能或系統上線都是複雜的,引入流量前需要配置關鍵業務節點上的監控,釋出過程中最開始先beta灰度並進行功能驗證,確認功能正常,指標監控平穩後可以開始作分批發布(如果是大規模的系統叢集),在釋出過程中與完成後需要實時緊盯監控指標以防止出現線上問題。

7. 效果驗證

專案上線後就可以通過服務端的埋點日誌資料進行篩選統計,檢視上線後整體功能是否滿足預期的目標。

8. 文件記錄

寫文件是一個開發人員工作的本職工作,上述的每一個開發步驟都應該在專案文件或者是系統文件中予以記錄。

9. 運維工作

運維工作包括日常運維,包括系統容器的狀態的管理(重啟/置換/擴容/縮容),大促運維(預算申報,預案管理與演練,重保節點配置等)以我本人為例,我負責的是淘寶直播互動訊息擴散架構,在每次大促活動或者是頭部主播搞大活動,都需要作直播間相關資訊的提前配置與準備,確認容器狀態都正常,這些都是系統運維相關的工作。

10. 答疑工作

每個人負責的系統應該都只是一個系統鏈路的一部分,這種時候對於你的業務方就需要提供答疑工作: 幫助完成系統接入,幫助排查問題,解答功能細節等等,現在在阿里巴巴內部這部分工作逐漸轉為由自動化答疑和排查工具來完成,但免不了出現疑難雜症需要開發人員介入解決。

11. 工作外的充電

阿里巴巴內部有一個技術分享論壇,在其中能看到各種系統設計介紹,疑難問題的排查亦或者是思維方法論等等,我們在閒暇時間都會在論壇上學習他人的分享,踩坑記錄或者是成功經驗。我們團隊內部也經常會有技術分享和文章書籍介紹,例如《領域驅動設計》《重構》《Designing Data-Intensive Application》等等,這些必要的充電對於個人能力的提升也是非常巨大的。

12. 對新人的建議

一般情況下,團隊內來了新人後會有一段時間來適應工作環境和內容,團隊也會給新人配備一個mentor的角色(阿里巴巴則稱之為”師兄“)來負責入職後的適應階段。新人做的第一件事情就是熟悉環境,包括同事間的相處風格、公司技術棧、中介軟體等等。在適應完成後一般主管會給你分配一些簡單的任務比如一個模組功能的實現,新人就需要通過這樣一個任務去落地,包括功能效果的實現,團隊和上下游業務的熟悉瞭解等等。最後給新人的一些建議就是要在工作中要多溝通交流,剛入職的時候對整體的業務和技術棧甚至包括自己擔任的職責和負責的範圍等等都會有疑惑,這是非常正常的一件事情。這種時候多和主管或者是mentor作溝通交流不斷明確你的工作的目標和當前的進度情況,這樣新人落地也會更加順利一點。有時候新人在技術實現上會遇到困難,這種時候除了需要靠自己多思考學習外同樣需要多和同事討論,向資深員工學習請教也會讓你工作更加順利。

工程師的工作日常,沒有那麼多的轟轟烈烈,大多時候是日拱一卒,反覆且平淡。因為擁有目標,擁有方向,所以只需保持認真與專注,然後心無旁騖,一往無前。