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

• 2020 年 12 月 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次……每次晉陞失敗後最難的是調整心態，感覺自己受到了不公平待遇，評委不客觀、不了解我做的事情、只能看到我的短板等，這樣的想法持續太久必然會影響到自己。

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

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

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

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

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

2 關於轉崗

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

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

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

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

3 做事情

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

一件事情

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

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

「雲上雲下監控數據採集技術統一」，也是一件事情。

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

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

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句話：

定義清楚團隊的一件事

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

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

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

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

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

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

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

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

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

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

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

四 總結

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

原文鏈接
本文為阿里雲原創內容，未經允許不得轉載。