圖片來自 Pexels

本文分享阿里巴巴高階技術專家在阿里 10 年的成長之路，分享他從一個普通技術人開始，在阿里的三個階段，以及在晉升、轉崗、帶團隊、做事等方面的心得感悟。

01.關於我

宋健，花名宋意，2008 年開始參加工作，至今 12 年多一直專注在運維領域。

2010 年 6 月加入支付寶，做過監控、SRE、資源管理、運維產品等方面的工作，經歷並參與了阿里運維從指令碼到工具化再到自動智慧化的演進過程。

在阿里的 10 年根據部門變化有三個階段：

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

02.我的經歷

①支付寶

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

入職後加入的團隊是運維部的監控組，那個時候團隊剛剛開始組建，所有的東西從零開始，好在有 B2B 的兄弟團隊可以借鑑經驗，利用 nagios 快速構建了支付寶第一代監控系統。

過了幾個月由於雙 11 的原因，我們的上班地點由華星時代搬到了電信二樞紐機房，因為支付寶當時的核心機房在那裡，我們需要 7*24 在現場以便快速處置緊急事件。

當時小組應該是 6 個同學，一白班一晚班一正常班，我們一邊值班一邊維護監控系統。

隨著業務的快速發展伺服器不斷增加，很快一臺 nagios 已無法滿足需求，調研後引入 centreon 解決了 nagios 的水平擴充套件問題。

監控項的新增和維護以編輯 nagios 配置檔案為主，沒有辦法開放所有人員，因此監控項的維護工作也是由監控團隊負責，PE 和 DBA 只要整理好需求發出郵件即可。

但新建業務和擴容的頻率越來越高，每天要花費大量時間編輯檔案受理監控需求且經常出錯，和需求方協商後確定了針對不同業務元件設定監控模板的方案，再想辦法自動獲取到伺服器資訊。

那個時候還沒有專門 CMDB，後來總算實現了新機器上線自動匹配模板新增監控和告警。

重要的告警都是透過簡訊發出，告警簡訊需要和線上業務的簡訊區分開避免相互影響，所以我們又採購了幾十個簡訊貓，專門學習瞭如何透過伺服器控制簡訊貓傳送簡訊，再後來還演進出了利用簡訊貓接收簡訊關閉告警的能力。

這樣的情況持續一年左右逐漸穩定下來，有了經驗沉澱後我們開始嘗試引入外包值班，然後開始招聘和培訓外包同學，制定值班和應急標準，建設相應的流程系統。

外包值班又持續了差不多一年時間，由於監控可以看到所有業務資料，出於安全考慮又進行了去外包化。

目前監控值班的角色仍然存在，辦公地點在西溪的全球執行指揮中心，有專門的辦公室和門禁限制，裡面全是各種酷炫大屏，整個經濟體的業務由他們 7*24 小時守護著。

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

②技術保障

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

2013 年我所在部門由支付寶調整至集團，到集團後參與的第一個專案是統一集團監控系統。

原來淘寶、支付寶、阿里雲、B2B 等業務都是自建監控團隊和系統，組織層面統一後必然要將系統進行整合，整合後的新系統叫 alimonitor。

當時專案主導方是在運維開發團隊，我參與進來時專案已經啟動，只有我一個人是在監控團隊，這也是我第一次參與較大型的跨團隊專案。

因為剛調整到集團跟其它成員都不熟悉，所以跟大家合作起來阻力很大，但我還是積極參與到專案中，每天跑到開發團隊參加晨會，直到有一次在晨會上被氣哭，但神奇的是從那天后合作就變的非常順暢，再也感受不到壁壘的存在。

專案持續了差不多一年時間成功上線，透過這個專案使我和開發團隊的同學們建立起了良好的信任關係，對後續的工作起到了很大幫助。

開發團隊負責著集團所有的運維工具，除 alimonitor 外還有 staragent、armory、aone 等。

有段時間這些工具經常發生故障，甚至在雙十一雙十二的關鍵時刻掉鏈子，後來從業務團隊轉來一位資深同學負責團隊，併發起了運維工具的 OD 分離專案。

我做為主要負責人承擔所有工具的 PE 職責，也是這時候我開始帶團隊，最終推動 10 多個產品上百個應用完成 OD 分離標準化改造，解決了工具的穩定性問題。

由於每個工具負責了運維的其中一個環節，所有工具承載的業務加起來構成了集團的工具運維體系，這段經歷使我對運維業務有了更全面和深層次的理解。

工具 PE 的事情穩定後我又接到了一個事情，負責整個集團開發測試環境的資源管理，測試環境當時有好幾萬臺伺服器。

但沒有人知道哪些機器在用以及誰在用，而且每年還有數千臺的物理機新增預算，成本浪費非常嚴重。

我接手後首先建設了一個資源生命週期管理系統，使所有新資源的申請全部經過系統。

並且對已有資源發起盤點和認領，所有資源設定有效期，到期後可以續租或釋放，系統還會定期巡檢資源的使用情況，再配合宕機回收、閒置降配等運營策略，最終將測試資源盤點的清清楚楚。

不僅年度預算 0 新增，還將回收的幾千臺物理機在雙十一時支援了生產環境。

再後來繼續嘗試透過混部提升測試資源使用率，調研多個方案後選擇了跟 jstorm 團隊合作，但上線後經常出現 jstorm 任務把測試機資源佔滿，影響業務的日常測試引發投訴，受限於當時技術限制最終沒能繼續推進下去。

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

關鍵詞：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 的事情全部交接了出去，目前我的主要職責是為業務上雲提供一站式監控方案，包括雲資源監控、主機監控、業務監控、鏈路監控等。

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

這三個階段我會用三個詞概括：做事情→做專案→做產品。

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

03.我的成長

“很傻很天真，又猛又持久。”我覺得這句話可以形容我的待人和做事風格，待人方面我會預設相信每一個人，做事方面因為比較笨就會比別人下更多功夫。

這些年我始終堅持在一個領域，比別人投入更多的時間和精力，在經歷一次又一次失敗後，不斷的吸取經驗和教訓使自己成長。

期間也有過很多次想打退堂鼓，最艱難的時刻總能想到一句充滿力量的阿里土話安慰自己。

①關於晉升

網際網路行業招人時經常會說一句話，崗位對標阿里的 P 幾，這一點足以說明在阿里級別的重要性，所以晉升對每個人來講都很重要。

但當我們把級別看的很重時也帶來了問題，級別變成了每個人的第一標籤，合作時首先看你的級別而不是負責什麼，做事情首先想到的是晉升而非價值。

今年公司在這方面已經有所調整包括隱藏職級等，希望可以讓我們迴歸到用事情價值和成就感來驅動自己。

10 年前我入職支付寶時級別為 P4，到目前共經歷 8 次答辯，平均每 2 次答辯成功 1 次，但是 P7 到 P8 的晉升用了 5 年答辯 3 次……

每次晉升失敗後最難的是調整心態，感覺自己受到了不公平待遇，評委不客觀、不瞭解我做的事情、只能看到我的短板等，這樣的想法持續太久必然會影響到自己。

如何調整?我的做法是首先擺正心態，相信公司相信評委，公司一定希望給每位同學匹配到最合適的評委，評委主觀上也一定是客觀的，不會刻意針對某一人。

然後從自己身上找原因，評委的反饋是什麼?為什麼會讓評委有這樣的感受?沒表達清楚還是沒思考清楚?

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

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

能力原因個人是可以改變的，但首先需要認知到自己的不足，技術、業務、表達是哪方面的問題?

仔細閱讀和理解評委的反饋，有時候反饋可能不那麼直接，比如未來展望不夠意思是看不到你負責這個業務的未來，平時你有想過業務的未來嗎?

多和主管聊一聊，主管一定願意幫助你找到問題所在。把自己做了一年或者幾年的事情，在 20 分鐘內向幾個陌生評委講清楚，讓他們完全認可和理解我認為一點都不容易。

運氣方面個人能做的就是來年再戰，多試幾次總歸運氣有不那麼差的時候。

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

②關於轉崗

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

第一次是入職兩年後，大概 2012 年中，第一次覺得遇到了瓶頸，已有事情無法再讓自己突破，所以就去找主管聊了聊。

主管也覺得我需要做些更有挑戰的事情，瞭解想法後也主動幫助我找團隊，就在定下團隊準備走流程時發生了組織調整，支付寶整個運維部被合併至集團新成立的 BU 技術保障，事情也跟著發生了變化。

從原來的支付寶監控轉變為統一整個集團的監控，對我來講又有了新的挑戰就擁抱變化放棄了轉崗。

第二次是在 2015 年底，當時集團正在去 PE 化，技術保障大 PE 團隊分拆到了各業務線，我負責的工具&測試 PE 團隊也被拆分調整，但自己對調整後的事情並不太感興趣。

幾年的 PE 做下來感覺運維最大挑戰還是工具，思考很久決定轉崗至負責運維工具的產品技術部，選擇的產品是 StarAgent，BU 沒有變化還是在技術保障。

第三次是在 2019 年底，SA 做了近四年且連續兩次晉升失敗之後，在我的主導下 SA 從一個純粹的命令通道升級為主機管理平臺，成為所有運維繫統和人員管理伺服器的第一入口。

感覺自己已經用盡了全力，卻仍然不知道怎麼突破，陷入了迷茫。後來在主管幫助下終於想明白，自己一直想著怎麼把事情做好，但很少思考做的是不是正確的事情，導致做的越來越多越來越累。

轉崗的目的還是為了解決問題，無論什麼時候有轉崗想法後，應該首先找主管聊一聊，必要的話也可以找主管的主管或 HRG 去聊。

不要擔心聊了會被打“標籤”，坦誠的去溝通，主管一定也很想幫助你，只是他可能還沒意識到問題，問題聊清楚了才可能得到解決，沒有溝通直接找新團隊其實還是在迴避。

個人在當前團隊成長受限、看不到當前業務的前景，如果溝通後確實是這些方面的問題，那麼轉崗就是必要的。但除此外遇到如協作或溝通等方面的問題，則需要慎重考慮。

換團隊的成本非常高，需要時間來和新主管及成員建立信任感，當前得不到解決的問題換個地方後大機率還會碰到，新團隊也會帶來新的問題甚至問題更多。

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

一件事情：“讓天下沒有難做的生意”，是一件事情;“做技術驅動的世界第一的商業基礎設施服務商”，也是一件事情;“雲上雲下監控資料採集技術統一”，也是一件事情。

每個人每天都在做事情，為什麼有的人做的好有的人做的不好?我認為很重要的一點是做的事情之間有沒有產生連線。

做的好的應該是：每天做的事是每個月的一件事的一部分，每個月做的事是該季度一件事的一部分，每個季度做的事是本年度一件事的一部分。當做的所有事情建立起了關係，組成了更大的一件事才有意義。

每天的一件事和每月的一件事的高度是不一樣的，複雜度和解決需要的時間也不一樣。

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

99% 和 1%：一件事情可以分為 99% 和 1% 兩部分，大部分時候我們做到 99% 就覺得可以了，如某個成功率指標做到 99.99% 之後，可能發現最後 0.01% 要付出的代價比之前的全部還要高，要不要做?

我覺得應該儘可能推進，因為越深入越能體現出競爭力，至於最後做到 5 個 9 還是 6 個 9 取決於和業界拉開的距離。

99% 是必須做的，1% 是需要突破的，深度和壁壘往往體現在最後的 1%。每次完成一件事情較之前進步 0.01% 也是突破，100 次 0.01% 就是 1%。

但如果每次做到 99% 就停止了，那麼我們和流水線上的工人沒有本質區別，都是在重複做事情只是重複的東西不一樣而已。

完成一件一件有關聯的事情將自己打造成一個服務，避免完成一件一件無關的事情讓自己成為一個資源。

一件事情體現的是業務廣度，1% 體現的是技術深度，規劃時需要業務廣度，落地時需要技術深度，二者結合起來才能保證所做事情的正確性和競爭力。

④帶團隊

帶團隊的目的還是做事情，只是由一個人變成了多個人，多個人做一件不斷逼近 100% 的事。

對於團隊負責人最重要的事情我總結為 3 句話：

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

我是從 2014 年開始帶團隊，雖然每年也在做計劃，但早些年主要以羅列事情為主，每次彙報都被老闆批，直到近兩年才想明白這一點。

現在來看前些年帶團隊自己更像個 PM，不停地為產品做新功能，但上線後又缺乏長期演進方案，導致支援工作越來越多，團隊同學越來越辛苦，產品沒有深度也缺乏競爭力。

在老闆和其它團隊眼中只把我們當資源，只要支援好業務的需求就可以，當業務方沒有投訴老闆也不願意再投入。

團隊同學看不到希望就會想轉崗，轉走後又沒有新的人員補充，每個人的事情都越來越多，為了不使大家那麼辛苦，自己也去負責答疑做各種日常事務，最終使團隊陷入一種惡性迴圈的狀態。

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

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

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

招聘策略我會傾向於多校招，只有少數專業類人才需要社招。校招最難的是第一年，因為第二年這些同學可以推薦學弟學妹，後續每年基本就不會斷檔了。

第一年怎麼招?如果實在找不到更好的渠道，內部的公海池是個不錯的選擇，總歸可以篩選出一些優秀的同學。如果每年都有校招新同學加入，新同學又會變成老同學，天然的就建立起了人才梯隊。

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

與更多團隊合作形成更大的一件事：BU 的一件事是靠 BU 內的多個部門合作實現，部門的一件事又需要部門內多個小組合作完成，重點專案基本都是多個團隊協同完成，一個團隊的力量始終是有限的。

反觀自己這些年大部分時候在單打獨鬥，負責一塊獨立的業務，好處是自主空間比較大、不用依賴別人看人臉色，但這樣的業務往往也不在主幹道上，做的好或不好影響都有限。

這一點我覺得自己現在做的還不夠好，還是會有小農意識，需要繼續加強與兄弟團隊的合作，一起做一件更有價值的事。

04.總結

最好的 10 年在阿里度過我覺得自己很幸運，公司的同事們都很有智慧，持續與優秀的同事共事，我的認知和行為也受到影響，逐漸得到改變和提升。