阿裡 10 年：一個普通技術人的成長之路

作者 | 宋意  阿裡巴巴進階技術專家

來源|

阿裡巴巴雲原生公衆号

導讀：不管是什麼角色，成長是我們每個人都必須經曆的過程。作為一個技術人，成長不僅是技術上的不斷精進，也包括日常工作中的方方面面。本文主要講述了阿裡巴巴進階技術專家在阿裡 10 年的成長之路，分享他從一個普通技術人開始，在阿裡的三個階段，以及在晉升、轉崗、帶團隊、做事等方面的心得感悟。

自我介紹

宋健，花名宋意，2008 年開始參加工作，至今 12 年多一直專注在運維領域。2010 年 6 月加入支付寶，做過監控、SRE、資源管理、運維産品等方面的工作，經曆并參與了阿裡運維從腳本到工具化再到自動智能化的演進過程，在阿裡的 10 年根據部門變化有三個階段：

• 2010.6-2013.1，支付寶（系統運維部）
• 2013.2-2015.12，技術保障（支付寶、阿裡雲、淘寶、B2B 等運維部門統一後的新 BU）
• 2016.1-至今，天基（負責阿裡全球資料中心和運維體系的“數字化、自動化、智能化”建設）

個人經曆

1. 支付寶

關鍵詞：開源監控、監控值班、應急響應

入職後加入的團隊是運維部的監控組，那個時候團隊剛剛開始組建，所有的東西從零開始，好在有 B2B 的兄弟團隊可以借鑒經驗，利用 nagios 快速建構了支付寶第一代監控系統。過了幾個月由于 雙11 的原因，我們的上班地點由華星時代搬到了電信二樞紐機房，因為支付寶當時的核心機房在那裡，我們需要 7*24 小時在現場以便快速處置緊急事件。當時小組應該是 6 個同學，一白班一晚班一正常班，我們一邊值班一邊維護監控系統。

随着業務的快速發展伺服器不斷增加，很快一台 nagios 已無法滿足需求，調研後引入 centreon 解決了 nagios 的水準擴充問題。監控項的添加和維護以編輯 nagios 配置檔案為主，沒有辦法開放所有人員，是以監控項的維護工作也是由監控團隊負責，PE 和 DBA 隻要整理好需求發出郵件即可。但建立業務和擴容的頻率越來越高，每天要花費大量時間編輯檔案受理監控需求且經常出錯，和需求方協商後确定了針對不同業務元件設定監控模闆的方案，再想辦法自動擷取到伺服器資訊，那個時候還沒有專門 CMDB，後來總算實作了新機器上線自動比對模闆添加監控和告警。重要的告警都是通過短信發出，告警短信需要和線上業務的短信區分開避免互相影響，是以我們又采購了幾十個短信貓，專門學習了如何通過伺服器控制短信貓發送短信，再後來還演進出了利用短信貓接收短信關閉告警的能力。

這樣的情況持續一年左右逐漸穩定下來，有了經驗沉澱後我們開始嘗試引入外包值班，然後開始招聘和教育訓練外包同學，制定值班和應急标準，建設相應的流程系統。外包值班又持續了差不多一年時間，由于監控可以看到所有業務資料，出于安全考慮又進行了去外包化。目前監控值班的角色仍然存在，辦公地點在西溪的全球運作指揮中心，有專門的辦公室和門禁限制，裡面全是各種酷炫大屏，整個經濟體的業務由他們 7*24 小時守護着。

這兩年就是不停的做事情，不停的遇到問題和解決問題，逢山開路遇水搭橋。

2. 技術保障

關鍵詞：監控統一、OD 分離、資源管理

2013 年我所在部門由支付寶調整至集團，到集團後參與的第一個項目是統一集團監控系統。原來淘寶、支付寶、阿裡雲、B2B 等業務都是自建監控團隊和系統，組織層面統一後必然要将系統進行整合，整合後的新系統叫 alimonitor。當時項目主導方是在運維開發團隊，我參與進來時項目已經啟動，隻有我一個人是在監控團隊，這也是我第一次參與較大型的跨團隊項目。因為剛調整到集團跟其它成員都不熟悉，是以跟大家合作起來阻力很大，但我還是積極參與到項目中，每天跑到開發團隊參加晨會，直到有一次在晨會上被氣哭，但神奇的是從那天後合作就變的非常順暢，再也感受不到壁壘的存在。項目持續了差不多一年時間成功上線，通過這個項目使我和開發團隊的同學們建立起了良好的信任關系，對後續的工作起到了很大幫助。

開發團隊負責着集團所有的運維工具，除 alimonitor 外還有 staragent、armory、aone 等，有段時間這些工具經常發生故障，甚至在雙十一、雙十二的關鍵時刻掉鍊子，後來從業務團隊轉來一位資深同學負責團隊，并發起了運維工具的 OD 分離項目，我作為主要負責人承擔所有工具的 PE 職責，也是這時候我開始帶團隊，最終推動 10 多個産品上百個應用完成 OD 分離标準化改造，解決了工具的穩定性問題。由于每個工具負責了運維的其中一個環節，所有工具承載的業務加起來構成了集團的工具運維體系，這段經曆使我對運維業務有了更全面和深層次的了解。

工具 PE 的事情穩定後我又接到了一個事情，負責整個集團開發測試環境的資源管理，測試環境當時有好幾萬台伺服器，但沒有人知道哪些機器在用以及誰在用，而且每年還有數千台的實體機新增預算，成本浪費非常嚴重。我接手後首先建設了一個資源生命周期管理系統，使所有新資源的申請全部經過系統，并且對已有資源發起盤點和認領，所有資源設定有效期，到期後可以續租或釋放，系統還會定期巡檢資源的使用情況，再配合當機回收、閑置降配等營運政策，最終将測試資源盤點的清清楚楚，不僅年度預算 0 新增，還将回收的幾千台實體機在雙十一時支援了生産環境。再後來繼續嘗試通過混部提升測試資源使用率，調研多個方案後選擇了跟 jstorm 團隊合作，但上線後經常出現 jstorm 任務把測試機資源占滿，影響業務的日常測試引發投訴，受限于當時技術限制最終沒能繼續推進下去。

從參與一個跨團隊項目到負責一個跨團隊項目，再到做一個産品解決業務問題，這是我成長最快的兩年。

3. 天基

關鍵詞：StarAgent、Argus、雲監控

2016 年初我轉崗到了産品技術團隊做 StarAgent，SA 是一個非常重要的基礎産品，核心功能是指令通道，幾乎所有操作伺服器的場景都強依賴它，但過去 SA 一直做的不太好，有很長一段時間隻有半個人在兼職支援。我當時的想法也比較簡單，就是想改變這樣的局面。産品得不到重視的原因我覺得是指令功能過于單一，業務價值需要結合場景才能展現出來。是以做的第一件事是 Portal，推動 SA 從背景往前台走，第一個功能是插件平台，提供将一個面向全網的釋出能力，釋出的對象可以是各種運維腳本或者 agent，并且新擴容伺服器也會自動安裝。這樣做的目的是希望将 SA 的最大優勢全網覆寫能力開放出來，使上層系統可以将更多執行邏輯下放到機器，而不是都轉換為指令頻繁調用 SA。

插件平台的主要使用者群體是各個業務運維系統，但是一線開發和運維人員也經常需要登入伺服器執行指令，為了能覆寫到這部分使用者又推出了第二個功能 WEB 終端，人執行指令的場景又可以分為單機的互動操作和多機的批量操作，是以 WEB 終端又分為互動終端和批量終端兩個子功能，WEB 終端在保證安全的前提下解決了人操作伺服器的效率問題。

插件平台統一全網類變更入口後，我們也看到全網類 Agent 越來越多，每台伺服器都有 N 個運維類 Agent，進一步梳理後發現監控類 Agent 是最多的，是以又發起監控 Agent 融合的項目，統一後的新 Agent 叫 Argus，完成集團内的 agent 融合後繼續走向公有雲，目前公共雲外部客戶和阿裡内部使用的監控 Agent 都是同一套代碼。

在 Argus 完成集團内多套監控系統的 Agent 統一後，進一步分析會發現所有監控系統的采集實作都有類似性，Argus 對接的上遊是配置下遊是通道，将配置、采集、通道三部分組合起來就是标準的資料采集，是以又與 alimonitor 團隊合作，複用已有的配置和通道能力建設了一個覆寫全網的通用資料采集平台。随着在監控領域做的越來越深入，後來幹脆專注于監控場景，将 SA 的事情全部交接了出去，目前我的主要職責是為業務上雲提供一站式監控方案，包括雲資源監控、主機監控、業務監控、鍊路監控等。

埋頭做了好幾年的産品，但是産品的深度都沒有達到自己的預期。主要問題我覺得是過于關注産品技術本身，沒有做到以業務價值驅動，導緻未能獲得持續的資源投入。

這三個階段我會用三個詞概括：做事情-->做項目-->做産品。

做事情和做項目的重點是“正确的做事”，差別是項目多了一層協作。做産品的重點是“做正确的事”，不僅需要關注當下結果，更重要的是如何持續走到未來。

個人成長

“很傻很天真，又猛又持久。”我覺得這句話可以形容我的待人和做事風格，待人方面我會預設相信每一個人，做事方面因為比較笨就會比别人下更多功夫。這些年我始終堅持在一個領域，比别人投入更多的時間和精力，在經曆一次又一次失敗後，不斷的吸取經驗和教訓使自己成長。期間也有過很多次想打退堂鼓，最艱難的時刻總能想到一句充滿力量的阿裡土話安慰自己。

1. 關于晉升

網際網路行業招人時經常會說一句話，崗位對标阿裡的 P 幾，這一點足以說明在阿裡級别的重要性，是以晉升對每個人來講都很重要。但當我們把級别看的很重時也帶來了問題，級别變成了每個人的第一标簽，合作時首先看你的級别而不是負責什麼，做事情首先想到的是晉升而非價值。今年公司在這方面已經有所調整包括隐藏職級等，希望可以讓我們回歸到用事情價值和成就感來驅動自己。

10 年前我入職支付寶時級别為 P4，到目前共經曆 8 次答辯，平均每 2 次答辯成功 1 次，但是 P7 到 P8 的晉升用了 5 年答辯 3 次……每次晉升失敗後最難的是調整心态，感覺自己受到了不公平待遇，評委不客觀、不了解我做的事情、隻能看到我的短闆等，這樣的想法持續太久必然會影響到自己。

如何調整？我的做法是首先擺正心态，相信公司相信評委，公司一定希望給每位同學比對到最合适的評委，評委主觀上也一定是客觀的，不會刻意針對某一人。然後從自己身上找原因，評委的回報是什麼？為什麼會讓評委有這樣的感受？沒表達清楚還是沒思考清楚？

失敗原因可以簡單概括為兩方面：

• 能力沒達到，包括軟技能和硬技能。
• 運氣不好，跟評委氣場沒對上。

能力原因個人是可以改變的，但首先需要認知到自己的不足，技術、業務、表達是哪方面的問題？仔細閱讀和了解評委的回報，有時候回報可能不那麼直接，比如未來展望不夠意思是看不到你負責這個業務的未來，平時你有想過業務的未來嗎？多和主管聊一聊，主管一定願意幫助你找到問題所在。把自己做了一年或者幾年的事情，在 20 分鐘内向幾個陌生評委講清楚，讓他們完全認可和了解我認為一點都不容易。

運氣方面個人能做的就是來年再戰，多試幾次總歸運氣有不那麼差的時候。每個人都有可以提升的地方，成長是無止境的，隻有當實在找不到或不了解的時候，才可以把原因簡單的歸為運氣，使自己心态能夠調整過來，當心态平和後真正的問題就會慢慢清晰，在這個期間需要主管給予更多的安慰和鼓勵。

2. 關于轉崗

這 10 年我隻有一次正式轉崗，但轉崗的念頭還是有過好多次，其中三次印象比較深刻：

• 第一次是入職兩年後，大概 2012 年中，第一次覺得遇到了瓶頸，已有事情無法再讓自己突破，是以就去找主管聊了聊，主管也覺得我需要做些更有挑戰的事情，了解想法後也主動幫助我找團隊，就在定下團隊準備走流程時發生了組織調整，支付寶整個運維部被合并至集團新成立的 BU 技術保障，事情也跟着發生了變化，從原來的支付寶監控轉變為統一整個集團的監控，對我來講又有了新的挑戰就擁抱變化放棄了轉崗。
• 第二次是在 2015 年底，當時集團正在去 PE 化，技術保障大 PE 團隊分拆到了各業務線，我負責的工具 & 測試 PE 團隊也被拆分調整，但自己對調整後的事情并不太感興趣。幾年的 PE 做下來感覺運維最大挑戰還是工具，思考很久決定轉崗至負責運維工具的産品技術部，選擇的産品是 StarAgent，BU 沒有變化還是在技術保障。
• 第三次是在 2019 年底，SA 做了近四年且連續兩次晉升失敗之後，在我的主導下 SA 從一個純粹的指令通道更新為主機管理平台，成為所有運維系統和人員管理伺服器的第一入口。感覺自己已經用盡了全力，卻仍然不知道怎麼突破，陷入了迷茫。後來在主管幫助下終于想明白，自己一直想着怎麼把事情做好，但很少思考做的是不是正确的事情，導緻做的越來越多越來越累。和主管讨論後對職責進行了調整，将精力聚焦在一件事上面，其它事情進行了交接。

轉崗的目的還是為了解決問題，無論什麼時候有轉崗想法後，應該首先找主管聊一聊，必要的話也可以找主管的主管或 HRG 去聊。不要擔心聊了會被打“标簽”，坦誠的去溝通，主管一定也很想幫助你，隻是他可能還沒意識到問題，問題聊清楚了才可能得到解決，沒有溝通直接找新團隊其實還是在回避。

個人在目前團隊成長受限、看不到目前業務的前景，如果溝通後确實是這些方面的問題，那麼轉崗就是必要的。但除此外遇到如協作或溝通等方面的問題，則需要慎重考慮。換團隊的成本非常高，需要時間來和新主管及成員建立信任感，目前得不到解決的問題換個地方後大機率還會碰到，新團隊也會帶來新的問題甚至問題更多。

3. 做事情

我也經常看書和聽别人分享，要學習的方法論實在太多，但每次看完聽完就沒有然後了，最後仍然是走了很多彎路撞了很多次牆，才慢慢吸收形成了自己的方法，我的經驗總結下來就兩句話。

1）一件事情

“讓天下沒有難做的生意”，是一件事情。

“做技術驅動的世界第一的商業基礎設施服務商”，也是一件事情。

“雲上雲下監控資料采集技術統一”，也是一件事情。

每個人每天都在做事情，為什麼有的人做的好有的人做的不好？我認為很重要的一點是做的事情之間有沒有産生連接配接。做的好的應該是：每天做的事是每個月的一件事的一部分，每個月做的事是該季度一件事的一部分，每個季度做的事是本年度一件事的一部分。當做的所有事情建立起了關系，組成了更大的一件事才有意義。

每天的一件事和每月的一件事的高度是不一樣的，複雜度和解決需要的時間也不一樣。每個事情都該做，每個問題都該被解決，但我們的時間和精力是有限的，判斷事情該不該做的依據就是這個事情能否成為你的月度、季度或年度的一件事的一部分，如果可以則制定計劃去做，否則說明這個事情不該你來做。

2）99% 和 1%

一件事情可以分為 99% 和 1% 兩部分，大部分時候我們做到 99% 就覺得可以了，如某個成功率名額做到 99.99% 之後，可能發現最後 0.01% 要付出的代價比之前的全部還要高，要不要做？我覺得應該盡可能推進，因為越深入越能展現出競争力，至于最後做到 5 個 9 還是 6 個 9 取決于和業界拉開的距離。

99% 是必須做的，1% 是需要突破的，深度和壁壘往往展現在最後的 1%。每次完成一件事情較之前進步 0.01% 也是突破，100 次 0.01% 就是 1%。但如果每次做到 99% 就停止了，那麼我們和流水線上的勞工沒有本質差別，都是在重複做事情隻是重複的東西不一樣而已。

完成一件一件有關聯的事情将自己打造成一個服務，避免完成一件一件無關的事情讓自己成為一個資源。一件事情展現的是業務廣度，1% 展現的是技術深度，規劃時需要業務廣度，落地時需要技術深度，二者結合起來才能保證所做事情的正确性和競争力。

4. 帶團隊

帶團隊的目的還是做事情，隻是由一個人變成了多個人，多個人做一件不斷逼近 100% 的事。對于團隊負責人最重要的事情我總結為 3 句話：

1）定義清楚團隊的一件事

一件事就是團隊的目标，團隊目标一定是長遠的，最好能先想清楚幾年後的樣子，然後推導出一年的目标，再拆解出完成目标涉及的技術領域，最後确定每個領域的季度或月度目标及負責人。

我是從 2014 年開始帶團隊，雖然每年也在做計劃，但早些年主要以羅列事情為主，每次彙報都被老闆批，直到近兩年才想明白這一點。現在來看前些年帶團隊自己更像個 PM，不停地為産品做新功能，但上線後又缺乏長期演進方案，導緻支援工作越來越多，團隊同學越來越辛苦，産品沒有深度也缺乏競争力。在老闆和其它團隊眼中隻把我們當資源，隻要支援好業務的需求就可以，當業務方沒有投訴老闆也不願意再投入，團隊同學看不到希望就會想轉崗，轉走後又沒有新的人員補充，每個人的事情都越來越多，為了不使大家那麼辛苦，自己也去負責答疑做各種日常事務，最終使團隊陷入一種惡性循環的狀态。

這段經曆使我真正了解了一句話：“用戰術上的勤奮掩蓋戰略上的懶惰”。

2）讓更多的人加入進來做這一件事

想把事情做的更好必然需要更多優秀同學加入，同時每個團隊都會存在人員流動情況，是以第二重要的事就是確定團隊不斷有新鮮血液加入。

剛開始帶團隊一般都是通過組織調整，最初幾年我對招人也是完全沒想法，缺人了就找老闆要，後來才慢慢明白我是在完成自己的目标，不是在幫老闆帶團隊，才意識到招聘對團隊的重要性。

招聘政策我會傾向于多校招，隻有少數專業類人才需要社招。校招最難的是第一年，因為第二年這些同學可以推薦學弟學妹，後續每年基本就不會斷檔了。第一年怎麼招？如果實在找不到更好的管道，内部的公海池是個不錯的選擇，總歸可以篩選出一些優秀的同學。如果每年都有校招新同學加入，新同學又會變成老同學，天然的就建立起了人才梯隊。

随着團隊成員越來越多，管理方面的問題就會暴露出來，管理最重要的我覺得還是讓每個同學清楚自己月度、季度和年度的一件事分别是什麼，然後定期與同學溝通交流，了解實作目标過程中遇到的問題并給予幫助和建議，使同學知道自己的發力方向。

3）與更多團隊合作形成更大的一件事

BU 的一件事是靠 BU 内的多個部門合作實作，部門的一件事又需要部門内多個小組合作完成，重點項目基本都是多個團隊協同完成，一個團隊的力量始終是有限的。

反觀自己這些年大部分時候在單打獨鬥，負責一塊獨立的業務，好處是自主空間比較大、不用依賴别人看人臉色，但這樣的業務往往也不在主幹道上，做的好或不好影響都有限。這一點我覺得自己現在做的還不夠好，還是會有小農意識，需要繼續加強與兄弟團隊的合作，一起做一件更有價值的事。

總結

最好的 10 年在阿裡度過我覺得自己很幸運，公司的同僚們都很有智慧，持續與優秀的同僚共事，我的認知和行為也受到影響，逐漸得到改變和提升。這十年我得到了很多同僚的幫助，謝謝幫助過我的每一位同學，還有曆任主管和團隊的小夥伴們，因為你們對我的包容和支援使我走到了今天，對下一個十年我充滿了信心和期待！