阿里妹導讀
作者總結了在阿里的三年時間中所收穫的寶貴經驗和成長感悟。
二零二一年的七月九號，我以校招生的身份入職了阿里，開啟了一段十分有意思、有意義的阿里旅程。
這三年，我從企業金融技術部，到ICBU技術部，中間還借調到1688技術部一段時間。整個濱江園區的業務我好像都經歷了一遍。
在這三年裡，換過N個小組。中間經歷過很多好的壞的、各種鬧心奇葩的坑爹事。但是幸好周圍的各位大佬對我不厭其煩幫助、孜孜不倦地教誨，讓我感受到了阿里人溫暖，在這裡收穫了友情，成長和感動。
在阿里有句俗語，三年成人，在這個時間點，我小小地做個總結，歡迎拍磚～
搞業務與做技術
“面試造火箭，入職擰螺絲”。
在越來越卷的當下，面試的難度越來越高，HR先篩選一下簡歷，非985的不要，沒專案的不要。面試階段，大部分阿里的面試官一上來先來幾道八股文練練手，再結合簡歷專案看看實力，最後問幾道高併發完美收場。面試官的這套組合拳打完後，面試者真的會以為將來工作的場景會和這些高併發高可用休慼相關，拳打千萬併發、腳踢億級流量，一想到億級使用者將透過在下手中的程式碼完成一次次交易與支付，激動之情就難以言表，喜不自勝。
但是入職之後卻發現，面試時候信手拈來的各種高效能、高可用、高效能的奇技淫巧暫時沒有用武之地， 取而代之的是被PD各種虐，CURD就是幹，每天在N年前古人寫下的深山中猜測各種古老的業務細節。
很多人入職都會進入業務團隊，他們就會後發現，自己日常接觸的程式碼，或許因為業務迭代的壓力，或許困於前任設計的缺陷，幾乎沒有任何“技術”的設計可言，一言不合加機器、升配置，是最常見、也可能是唯一的處理所謂高併發的手段。
至於高可用，中介軟體平臺已經夠完善了，根本不可能出現之前面試所說的極端問題——即使出現，也不在業務場景的考慮範圍內，因為資料流量太小，離線核對訂正往往是最常見的解決方案。
所以，入職業務技術團隊後，相信大部分校招同學，在開發一段時間業務需求之後，輕則懷疑公司，生出“阿里就這？”的感嘆，然後麻木地被業務需求往前趕；重則道心破碎，開始懷疑自己的當初的夢想，最後要麼被幹要麼跑路換行。
我剛入職後就屬於前者，看著周圍一些同學CURD一把梭，不禁陷入了迷茫，開始懷疑自己在學校鑽研了三年技術的意義。我常常想，難道我每天CURD就能解決問題了嗎？
純粹的CRUD當然是解決不了問題的。隨著工作的深入，我發現事情遠沒有我想象的那麼簡單。雖然是增刪改查，但是在寫增刪改查的前提一定是對業務有相當程度的瞭解和熟悉。只有透過技術完成對真實業務的抽象和建模，才能寫出來高擴充套件性的程式碼。而隨著承接越來越多和越來越大的需求，我們所瞭解的業務知識也會慢慢變成自己的壁壘。在這個過程中，我們也會寫出越來越健壯、可讀性越來越高、擴充套件性越來越強的程式碼，我們掌握了對應業務知識，以及當前業務需要的效能和穩定性指標，都會成為我們寶貴的職業財富。
業務技術團隊和純技術團隊最大的不同是解決不一樣的問題。業務團隊負責解決真實世界的業務問題，純技術團隊則負責解決技術問題。某種程度上來說，科班出身的計算機同學更容易受到geek風的影響，認為畢業將來一定會做很多技術相關的工作，再加上面試過程中各種硬核問題，拉高了面試者的工作預期，才會導致大家投入工作後產生很大的割裂感。
在業務團隊，對於技術人來說，很大的忌諱就是硬秀肌肉，大家都想嘗試新的技術，更高難度的技術挑戰。但是，既然低併發能夠解決業務問題，為什麼還要處理高併發的各種問題自討苦吃呢？尤其是在現在經營責任制的環境下，技術要做的就是服務業務，最小代價的解決業務的問題。
其實處處留心皆學問，雖然很多硬核技術在日常的業務場景中用不到，但如果實在喜歡鑽研技術，進入阿里後，還是有很多機會學習的。抽時間看中介軟體的原始碼、應用中介軟體的設計模式、解決日常遇到的各種詭異問題（maven排包、類載入）、線上問題的響應與處理，等等。只要抽出身來，即使在業務團隊擰螺絲，但只要多花點時間準備，為業務造火箭的機會可能就會到來。
草船借箭的勇氣
寫這篇文章的時候，透過GPT搜尋了下，程式設計師中的I人會佔到60%甚至更高，這種性格固然會使得大家在開發的時候更專注，但是往往也會導致開發同學在與人的溝通上不那麼積極。
很多人剛入職的時候，無論是學習業務，還是開發需求，在遇到問題的時候，都不好意思問師兄。甚至有些同學在師兄問專案進度的時候，支支吾吾地說快完成了，結果等到聯調的時候才發現，自己寫的程式碼和業務預期的程式碼，還是有相當大的出入的。
所以，對於校招生來說，為了保證自己進步的速度，在合適的時機，多向周圍的師兄、老闆、業務方諮詢問題，是一件非常有必要的事情。但是，大家往往缺少問問題的勇氣，結合我自己和身邊的例子，大概統計了下，一般有以下原因：
-
和被諮詢的人沒打過交道不熟悉，不知道怎麼開口； -
擔心問題太簡單，害怕被諮詢的人嘲笑或者看低自己； -
大家都很忙，害怕影響到被諮詢人的工作
之前另外印象很深刻的一個例子，幾年前，隔壁組一個剛入職的校招生在工位熬夜搞到11點，剛好我也在處理些事情，看他一直沒走，就上前搭了幾句話，得知他正在處理一個非常經典的Spring啟動的問題。所以我就順手幫他解決了。後來才知道，這個問題他已經看了快3個小時了。如果他能找機會向其他同學尋求幫助，那天晚上11點他就可以直接在床上原神啟動了。
不只是問別人，阿里有太多的技術資產了。遇到問題，搜尋語雀、ata往往就有50%的機率解決問題。學會使用工具，也是成長的一部分。
不像古代男耕女織、幾乎一個家庭就能完成從生產到消費的全鏈路，現在的社會是以分工合作為基礎的，所以我們必不可免的要和其他人打交道。甚至很多時候，我們自己的工作需要主動或者被動的依賴別人的幫助才能完成。
新同學剛進入工作的時候，一定要多向師兄和同事借力。在新手保護期的階段，大家會更容忍你有更多的“不知道”，所以，一定要在最懵懂的時候，儘可能的獲取更多的知識。
專案遇到卡點的時候，一定要多向老闆借力。業務方工期緊？合作方不配合？這些涉及到更高層級溝通的地方，一定要向老闆彙報，讓老闆站在更高的視角幫我們推動專案的執行。不過，在找老闆之前，不能只把問題拋給老闆，還有給出一定的解決方案和預期時間，這樣在後續爭取資源或者撕逼扯淡的時候，老闆才會不至於那麼被動。
作為業務開發，業務的知識也是開發必須要掌握的基礎之一。在遇到業務問題的時候，要多向業務借力。想業務諮詢問題背景、可能的方案以及原因。多與業務溝通，不僅能掌握更多的業務知識，從功利的角度講，也算是和業務方刷刷臉。大家更熟悉了，後續合作需求的gap也會越來越小，工作起來也會越來越順心。
草船借箭，不僅需要勇氣，更需要智慧。聊之前準備好草船，也要注意時間和場合。完事之後表達感激也是必不可少的。至於是一句thanks，還是一杯咖啡，抑或是一頓飯，這個見仁見智吧～～～
預期與專案管理
無論是寫程式碼，還是PM技術專案，核心都是保障事情按時交付。在這個過程中，一定有自己不瞭解的地方，所以如何平衡好未知的坑和確定的交付時間，是我入職之後做技術PM最痛苦的點之一。
如果遇到一個自己有超過30%都不熟悉的專案，建議此時一定要給自己多留一點buffer。這樣做的原因有兩點，一方面是面對未知的坑，運氣好一點可以直接跳過去；運氣差的話，直接陷進去一週都出不來。無論專案大小，作為專案負責人，我們不能讓專案的交付時間跟隨運氣的好壞而波動。這樣不僅會使得自己陷入被動，專案的對外放聲，前線運營也會受到影響。
給自己留buffer，不僅僅是幫助自己有更多時間踩坑，也是給自己留更多地和業務方聊排期的空間。如果一上來和業務聊了一個很緊張，加班後勉強才能做完的時間，後面這個專案大機率是要延期的。這麼一搞，自己在合作方中的印象分就會很低。魯迅大爺說過：“中國人的性情總是喜歡調和，折中的。譬如你說，這屋子太暗，須在這裡開一個天窗，大家一定不允許的，但如果你主張拆掉屋頂，他們就回來調和，願意開窗了。”所以，剛開始估一個留buffer的排期，後面到底是拆屋頂還是開天窗，就有很大的活動空間了。
但是有的時候，專案的排期並不是我們這些小P能夠決定的。930、330前要上線的專案一大堆，各個專案問就是P0、第N增長曲線，必須要做。沒有留buffer的空間，這個時候該怎麼辦？
過去的經驗告訴我，在不斷發現風險，解決風險的專案過程中，遇到難以解決的風險一定同步老闆。及時讓老闆瞭解專案的進度，適時地管理專案參與方對專案的預期。這樣才不至於在專案的各個里程碑中給各位大佬一個驚喜的SURPRISE。
獨樂樂不如眾樂樂
在阿里這三年，發現了太多大牛前輩，他們中的大部分人在我阿里的歷程中都給予過非常重要的幫助。當我不解問及他們為何要在工作如此繁忙的時候還會抽出時間來給我答疑，他們的答案出奇的相似：
“因為當時淋過雨，才知道做這些無聊的事情有多痛苦”
“這些概念性的東西，知道後會少走很多彎路，沒必要讓你們把時間浪費在這些沒有價值的事情上”
我聽了之後甚是感動，在我看來，這是阿里師兄文化最好的體現。從實習到校招，我的每一任師兄和每一任老闆，都在盡力幫我landing，教我瞭解技術原理、告訴我如何學習和成長、如何管理專案、如何控制風險，感謝這三年與他們相處的每一個瞬間，與他們相處的日子是我這輩子最寶貴的財富（之一，哈哈哈哈）。
所以如果有時間，不妨多去幫助那些新來的朋友們，在他們成長起來之前，少一點PUA，多給予力所能及的幫助。這樣自己開心，大家也高興，無形之中團隊的氛圍就會慢慢變好，阿里的文化也會一點點的傳承下去。
其實幫助他們成長，對我們自己來說，又何嘗不是一種成長？
萬物是否皆可卷
我是2020年入職阿里實習，以本科生身份校招轉正的漏網之魚。網際網路公司在20、21、22這三年校招擴招的校招生非常多，站在現在的角度，以當下的招聘標準，作為一個普通本科生，我是無論如何也不會被招進來的。現在部門的校招生研究生起步、985打底，卷學歷，作為開發，我已經輸在了起跑線上。
如果不能卷學歷，那還能卷什麼？卷加班時長？卷程式碼量？還是卷aone的工時？
我覺得這些都是一些過程指標，卷這些東西除了能夠安慰和緩解下上次管理者的焦慮之外，是很難明顯地解決其他問題的，對於自身的成長和提升更是沒有一點幫助。
網際網路頭部大廠作為人才的蓄水池，周圍隨處可見的都是優秀的人才，技術能力高，業務sense強，甚至每個人都有一套為人處事的方式方法。作為剛進入職場的菜鳥小白，我們應該努力卷我們自身的技能，向周圍的大佬看齊，提升技術，學習業務，然後再將學習到的東西進行實踐，從模仿到超越，實現學習、理解、實踐、提升的閉環。
在具備基礎的技術和業務能力之後，作為業務開發，不要只盯著自己技術域的一畝三分地，而是慢慢地開始去卷業務，瞭解自己開發業務的背景、發展和規劃，學著站在全域性的地方去考慮問題。阿里對新人還是有容錯的，校招生快速試錯，然後不斷成長，等待機會，承擔更大的責任。
不妨慢一點，給自己一點時間，找到一兩個自己在工作中和生活中真正想做的事情，然後堅持做下去。不要去卷各種無謂的指標，校招生，從卷自己開始。
踩坑了，然後呢
作為新人，在剛入職的時候，一定有很多不懂的地方，甚至有些同學之前沒有使用過部門常用的開發語言，這都是很正常的事情。在剛來的一年時間裡，大家總是會踩各種各樣的坑，印象中，我踩了很多坑：
-
dts任務批次呼叫導致下游報警
-
奧創釋出上線不生效
-
某些租戶缺少配置導致NPE，等等
有些還導致了P5故障，在覆盤的過程中，老闆和師兄們幫我總結經驗，讓我收穫了很多。很多人把這些當做工作履歷的黑點不想面對，但是對於校招生來說，正相反，只要問題不大，都是改錯的大好時機。俗話說，好記性不如爛筆頭，像高中寫錯題筆記一樣，將之前踩過的坑記錄下來。一定會有一天，在第二次遇到類似的問題後，腦海中突然閃過第一次踩坑的場景，然後把記錄的問題翻開，成功跳過這個坑，繼續前行。
大家對校招生的容錯度是很高的，新同學一定要利用這個時間區間來試錯和學習。記得我剛實習的時候，師兄給我review程式碼提了一些建議但是當時我沒有放在心上，並沒有改正，師兄很嚴厲的指出了我在回覆comments過程中的問題，耐心教育我，“有人幫你CR指出錯誤，一定要有回應、討論或者改正，這體現了對reviewer的重視。如果不回覆的話，以後找相同人CR就很難獲得高質量的comments”。這個建議我一直很受用，後續正式入職後，在師兄組織大面積CR的時候，在得到一些高質量的CR時候，我就會立刻提patch修復，其實，修復的越早，上線的風險也就越低。
同時，踩坑之後，不僅要記得防止自己踩坑，如果能形成公開文件或者知識庫，防止別人踩坑，或者是順手把坑修復掉，這就更加功德無量了。（當然，如何讓別人知道你把坑修復掉，這是一門藝術 //v//）
聽得懂、講明白
作為程式設計師，雖然在日常的開發中與機器打交道的比較多，但是在專案管理的過程中，與人的溝通也是必不可免的。資訊墒在傳遞的過程中一定是有損失的。所以，在交流的過程中，我們要透過各種方式來儘可能地保證資訊的正確和完整傳遞。
溝通是一個需要長期鍛鍊的技巧，有兩個比較重要的點，一個是耐心，一個是細心。在聽的時候，能夠給夥伴足夠多自我表達的空間，正常情況下，不要著急去否定和打斷對方，正如你講話時也不希望別人打斷一樣。此時我們需要做的就是細心去聽，然後分條分點地把對方要表達的觀點記錄下來並消化。同時，在回答別人問題之前，可以用幾句話把對方剛才的語言複述下來，儘量降低兩個人溝通之間的GAP。
同樣的，在表達自己觀點的時候，儘量也分條分點，像寫作文一樣，用總分總的方式，開篇和結尾表達問題關鍵點，中間分條分點論述。除此之外，一定要注意交代好上下文和背景。否則，很容易造成接受者的資訊紊亂，形成驢頭不對馬嘴的尷尬場景。尤其是諮詢問題的時候，如果直接問某一個具體的細節點，可能對方很難一下子get到意思，如果背景交代清楚，溝通起來就可能順暢許多。
但是，一切的技巧終歸是點綴，自己的影響力足夠高，很多事情就迎刃而解了。
擁抱變化
擁抱變化作為新六脈，每一位同學都不陌生。在公司，擁抱變化不僅體現在口號上，更是在行動上表現的淋漓盡至。
作為校招生，剛開始對變化這兩個詞其實感知是不深刻的。第一次感知到變化的時候，是我入職5個月後整個組被通知換到了另一個BU，因為只是換了組織關係，周圍合作的同學和老闆沒有變化，所以對於這次的變化只是有一個感性的認識。第二次感知到變化的時候，是22年從實習就開始帶我的老闆畢業之後，整個團隊都陷入了一場漩渦之中，那次我就陷入了思考。第三次感知到變化，則是我自己的選擇，選擇了換個環境繼續工作。
在這幾次變化中，我有幾點感觸：
第一，很多校招生在剛進入工作的時候，思想可能有一個誤區，認為自己一定要做自己專業強相關的事情，狠狠地鑽研技術，開發程式碼。但是進入工作後，我認為這種學生思維可能要稍微發生點變化。做技術當然是要持續精進的，但是核心的點更應該關注需求，關注組織的需求，把自己的技術或者能力應用到需求上去。中間商賺錢的本質就是供需匹配，有時候做做報表、思考下業務，也是一種成長。
第二，變化是一體兩面的，它不僅代表著自己離開了原來的舒適區，更代表自己面臨著新的環境，可能會有更大的機會。當自己從一個組織換成到另一個組織之後，不適應、不習慣，是剛開始融入時候必須面對的困境。可能有人在剛開始面臨變化的時候會想，“為什麼變化他而不變化我？”。我個人感覺，不要對組織抱有太大的惡意，可能我們也沒發現，自己從原來的地方被變化走已經代表了自己在原來領域的發展已經受限，所以，不如用更積極的態度去擁抱這次變化，在新的領域重新開始。
第三，塞翁失馬，焉知非福。有些變化，從短期來看可能讓我們有所損失，但是長期的事情誰能說的準。短短三年間，我就見到過很多例子，剛開始以為是好的變化，結果後來的發展又偏離了自己預想的方向；還有剛開始變化完天崩開局，結果後面柳暗花明。所以面對變化的時候，用積極的心做好自己的事，守正出奇，靜待花開。
我們一定要承認一個事實，就是業務離開誰都可以轉。大多數開發都沒有那種技術能力強到令人望塵莫及的地步，剛開始我還會天真地想，這個大佬這麼懂這塊技術，他變化了業務可怎麼辦？後來工作時間久了慢慢發現，人變了，事情才有可能發生變化，沒有需求是加程式碼、加人日、上重構解決不了的。雖然所謂的重構有可能也是把之前的feature又實現了一遍，你就說能不能用吧，哈哈哈。
所以，學習的能力很重要，在面對變化的時候，我們要學會迅速融入環境，這是一件非常重要的事情。學會快速學習業務，快速接手新的程式碼邏輯，整理一套自己的方法論。要知道，再也沒有校招入職時候連給2個月熟悉程式碼的快樂時光了，如何在不熟悉的程式碼中交付業務需求、不出現風險，甚至還能保證架構的統一，是作為程式設計師，在我司的大環境下擁抱變化的基礎能力。
接雨水和修屋頂
雖然說並不是啥都能卷，但是在當下這個卷的環境下，很多時候我們會不得不陷入內卷的困境裡，麻木地做著一成不變的事情。剛進入工作時候的那種激情和勇敢，就會在這種不斷承接被動需求的環境下慢慢地被消磨殆盡。
甚至有時候，我們可能會因為同事的負面看法而每天患得患失；可能會因為工作中的一點小疏漏而徹夜輾轉反側；可能會因為專案未完成而悶悶不樂，封閉自我。“他人即地獄”，工作久了之後，我們往往會陷入周圍的評價體系裡面，成為他人語言的奴隸，而不再是自己的主人。這個時候，向外求索，可能會是一種解法。
公司的光環和個人的能力是有區別的。不妨在公司內部的評價標準上，嘗試透過外部的評價來更確切地定位自己。空閒時多接接雨水，未雨綢繆，方才能讓自己在暴雨如注之時獨善其身。
未雨綢繆，晴天修屋頂也是十分必要的。在需求少的時候，身體上放鬆，精神上重視。多瞭解對手公司的競品動態，反思自己在工作中的優與劣。時刻掌握本領域業界的趨勢，反哺自己領域的業務和技術。用積極的態度，為自己建立一個更加全面的評價體系，清晰的定位自己，進而針對性提升。說句題外話，現在大模型這麼火，公司的每個部門都希望透過大模型來緩解眼前問題，畫大餅、講新故事，如果作為大頭兵的我們還不瞭解這些東西，一味的curd，看似是處在舒適區，其實是自己把自己推向了深淵。雪崩的時候，沒有一篇雪花是無辜的。
海闊憑魚躍，天高任鳥飛。
無論如何，這也只是一份工作，因為工作導致抑鬱，實在得不償失。珍惜身邊的每一位朋友，嘗試與自己和解，接受自己做不到的，爭取自己能得到的，坦然面對結果，做人生的朋友。
山窮水復疑無路，柳暗花明又一村。
新的開始
本來想在三週年之際發表這篇文章，沒想到中間經歷了一系列的事情，這一耽擱就是半年。不過雖然拖拉了這麼久，但是好在釋出出來了:)
悟以往之不諫，知來者之可追。以此，來祭奠我的阿里三週年，迎接在阿里的新挑戰^_^。
高效防護 web 應用
隨著網路技術的不斷發展，您的Web應用如果沒有流量入口的防護，會面臨諸多風險。本方案以ECS例項接入WAF為例，推薦您使用Web應用防火牆（WAF）開啟應用防護，避免網站伺服器被惡意入侵導致效能異常等問題，保障網站的業務安全和資料安全。同時，為您節約開發成本，滿足行業合規要求。
點選閱讀原文檢視詳情。