阿里 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. 技術保障

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

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

開發團隊負責着集團全部的運維工具，除 alimonitor 外還有 staragent、armory、aone 等，有段時間這些工具常常發生故障，甚至在雙11、雙十二的關鍵時刻掉鏈子，後來從業務團隊轉來一位資深同窗負責團隊，併發起了運維工具的 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 年在阿里度過我以爲本身很幸運，公司的同事們都頗有智慧，持續與優秀的同事共事，個人認知和行爲也受到影響，逐漸獲得改變和提高。這十年我獲得了不少同事的幫助，謝謝幫助過個人每一位同窗，還有歷任主管和團隊的小夥伴們，由於大家對個人包容和支持使我走到了今天，對下一個十年我充滿了信心和期待！