度小滿陳存利:20年老「司令」聊聊維運、績效、成長
透過訪談和約稿的方式,請維運領域老砲輸出深刻洞見,共同碰撞,以期形成一些先進的共識,推動產業更好得前進。
這一期我們邀請到的是陳存利,度小滿系統維運部總經理,20多年的職業生涯中絕大部分時間在互聯網領域。在百度維運部期間由於帶隊風格過硬,兄弟團隊稱其為」陳司令」。今天我們請「陳司令」來聊聊他的觀點。
這裡是接地氣、有高度的《運維百家講壇》第 5 期,開講!
問題預覽
- 您很早加入了百度,後來隨度小滿獨立,我們了解到您身邊有許多員工其實是很長時間一直跟著您,經歷了許多業務的維運考驗,相信大家都很感興趣,在維運這個辛苦的崗位上,如何能凝聚一群人一直走下去,想聽聽您的心得。
- 很多人認為工程師不寫程式碼就沒有價值,這個問題你怎麼看?對於不寫程式碼的工程師該如何持續提升自己,你有什麼建議嗎?
- 您在百度和度小滿經歷了大小很多業務的發展和起伏,您認為不同階段和不同體量的業務運維在理念和方法上有沒有什麼差異?是否有一些原則性的方法論指導做出決策?
- 您覺得當下,維運業有沒有哪些普遍做法其實是錯的?為什麼?
- 當下一些火熱的技術方向,包括FinOps、可觀測性、chatGPT等,您對這些技術方向的發展有什麼看法,是炒概念還是有真價值,運維人員是否應該做出什麼樣的因應舉措?
- 隨著雲端的發展,傳統的只做Ops的運維崗位長期來看必將消亡,您是否認可這個觀點?對於這類朋友的轉型路徑您有沒有什麼建議?
- 很多朋友在脈上吐槽公司績效打分不公平,您對他們有沒有什麼建議?另外您身為管理者,能否分享一下您是如何設計績效評估機制的?
訪談實錄
問:您很早加入了百度,後來隨度小滿獨立,我們了解到您身邊有許多員工其實很長時間一直跟著您,經歷了許多業務的維運考驗,相信大家都很感興趣,在維運這個辛苦的崗位上,如何能凝聚一群人一直走下去,想聽聽您的心得。
答:我理解你們這是在讚美我,我深表感謝。
2000年創業做電腦訓練開啟了我職業生涯,後來又在國企工作3年,2004年在北京開啟我的網路相關工作生涯。回顧我20多年職業經歷,很多都是從零組建團隊,因此運維類部門里工作過的同事應該超過千人,和我並肩打過幾次硬仗的兄弟也有300-400人,18年在小滿,再次從零組建了現在的團隊,一直走到今天。其實每次離開原有團隊和同學從零組成新團隊是痛苦和傷感的事。但看到很多過去的同仁,現在的工作和生活狀態都很好,部分人離開我的團隊後自己挑戰行業極限非常成功,當然賺的也比我多,我內心也替他們高興。
如果說我帶團隊有啥特點,我總結有3點:
- 首先,我們很重視團隊文化。每個新人入職的第一天就告訴他們我們團隊的願景要成為是“全球頂尖的技術保障團隊”,團隊核心成員的夢想是“用技術重新定義服務保障,讓服務保障更簡單”。我們招大家來不是來填坑的,招大家來就是為了改變,用技術去改變現實工作中的不合理之處。有個小故事對我個人影響很大,今天也分享給大家:北方的早晨,母親送孩子去上學的路上等紅綠燈,這時旁邊一位清潔工老人在辛勤的工作,這時母親為了教育孩子說:「你看清潔工爺爺他們每天那麼辛苦,你可得好好學習,學習不好長大了就只能當清潔工掃大街了。」同樣場景,另外一位母親教育孩子的語言就很觸動我,她說:“孩子,你看清潔工爺爺每天很辛苦,你要好好學習,將來發明出掃地的機器,讓所有人不要再辛苦的人工清理街道”,這個故事很觸動我,有些崗位的工作總是需要人去做的,我們做了就要做得不一樣,要用科技改變它,讓未來的人不再那麼難。
- 其次,我們很注意人才的培養,分階段不同方式的來培養。我們認為工作都是人來做的,只有提升這些人的能力才能做出不一樣的工作。我在2015年的時候總結了一套5-7年工程人才的培養機制。這套機制裡邊把人分做3個階段,第一階段是剛進場的人,這類人前兩年主要歷練工作方法,技術深入的能力和成功的經歷,這裡每一項都很重要。隨後他們將進入第二個階段,我們將透過2-3年提升綜合視野和實踐能力,現在的計算機工程涉及太廣,從網絡到操作系統,到內核再到應用和數據庫存儲等等,一名優秀的工程師在架構設計和故障排查時應當每個方向都有所涉獵,如果只看材料沒有實踐的經歷,會到處碰壁,在這個階段我們會有計劃的讓人員輪崗,每個方向都歷練一段時間,當然也會徵求他們個人的意願,通過輪崗歷練後,我們認為這些人技術通常不是問題,那麼就進入第三個階段,在第三個階段我們會和他們協作,讓他們選一個自己喜歡、擅長的方向,一起去挑戰產業極限,共同一起成長。當然,這個階段離開的人也會比較多,因為他們能力強了,在外面也很容易獲得有挑戰且自己喜歡的方向,通常回報也會非常好,我常跟他們說,你們很多人未來都會比我走的更遠,到時別忘了我們,做事要積極、正向,別給我們一起奮鬥過的團隊和人丟臉。
- 最後,我們很重視團隊人員的多元性和協作。複雜的工作通常都不是一個工種可以獨立完成的,我們把維運看做是一種技術保障,要做好這個保障,必須從運維場景分析、運維能力提升、維運產品創新開始,對應的產品、研發,維運,營運是都不可或缺的。這就好比軍隊的一個特戰隊,要有通訊員,衛生員、火力小組,狙擊小組等,要根據團隊需求尋找合適的人,並保證他們的協作效率,要在實踐和團建中建立信任,做到坦誠相待。
問:很多人認為工程師不寫程式就沒有價值,這個問題你怎麼看?對於不寫程式碼的工程師該如何持續提升自己,你有什麼建議嗎?
答:這個主題可以參考軍事管理,大家給我一個綽號叫“司令”,這可能跟我工作中喜歡經常用軍事的方法來做參照物有關,在我看來,這個問題就和軍人要不要上戰場開槍是一個道理:軍人要懂基本武器的使用,最好還有定期的鍛煉,當然也不是所有的軍人都拿武器去拼命才能打勝仗,打仗打的是後勤補給,打的是武器的先進性,打的也是正義,不論做後勤、做武器研究、還是做宣傳的人,都是戰爭必不可少的一部分,但無論在哪個崗位,都應該把崗位職責做到極致,剩下的要交給戰爭的指揮者。所以回到這個問題上,我理解工程師首先要了解好自己崗位在公司的定位,再結合個人自身的定位,盡量做到二者匹配,如果不匹配的話,還是換到匹配比較好。
問:您在百度和度小滿經歷了大小很多業務的發展和起伏,您認為不同階段和不同體量的業務運維在理念和方法上有沒有什麼差異?是否有一些原則性的方法論指導做出決策?
答:這是一個很好的問題。不同體量的工作遇到的困難是完全不一樣的,維護10,000台機器面臨的困難和維護100台機器面臨困難完全不一樣。
在維護100台機器的時候,我們可能還不太需要一個快速發現機器故障並自動修復的工具,因為按行業機器故障率,靠體力就可以完成,而且人們會覺得剛剛好,既不是很累,又有事乾;但維護10,000台機器的時候,如果只依賴人工,每台機器的巡檢就忙不過來,再加上跟供應商和業務協調維修時間,我們會忙到忘記吃飯。所以我給的建議是如果想生活和工作做好平衡,小公司就很好,如果要提升自己的技術能力和視野,肯定要去大規模大流量,這樣才能鍛鍊自己。
再談另一個主題,業務在不同的發展階段有不一樣的業務目標,那對應的維運的理念和方法也有很大的差異。很多公司初期能活下來就不錯了,他們會希望快速部署上線,因為業務得搶市場,只有先活下來才能繼續發展,所以很少考慮長遠的規劃。這時候維上來就跟老闆說,我們應該考慮未來十年的業務成長,結合業務成長需求來建立基礎設施,這是不切實際的。但如果一個業務已經有了幾百萬,甚至幾千萬的核心用戶,那麼大概率業務會關注最終用戶的體驗,此時運維要圍繞用戶的最終體驗來設計整個底層架構和設施,所有提升使用者體驗的工作都會獲得老闆的支持。當然老闆也會關注投入產出的成本,是否可持續(業務成長速度和資源投入的比率)等其它問題。還要注意的是,不同行業間差異也很大,例如金融和網路之間,就存在巨大差異。
總結起來可以概括為:技術是服務業務的,所有能夠幫助業務發展的技術,都會獲得資源的支持,無論什麼工作,都需要從「如何讓公司變得更好「這角度出發思考,公司好,你才會好,你所在的團隊好,你才能好。
問:您覺得當下,維運業有沒有哪些普遍做法其實是錯的?為什麼?
答:我暫時沒有深入的思考過產業有什麼做法是不對的,每家都有自己的現實問題,不好評價。
不過,有一點我想提一下,我從來沒有把自己限制在維運工作上,維運是我擅長的領域,是幫助公司守住用戶基本連結體驗的基礎,但我通常更現在關注公司的業務急需什麼?公司最核心的使用者他們需要什麼?他們需要什麼我們就優先做什麼,因為在我的視野裡,保障服務穩定的工作,每家公司都欠了非常多的債,需要慢慢還。
問:當下一些火熱的技術方向,包括FinOps、可觀測性、chatGPT等,您對這些技術方向的發展有什麼看法,是炒概念還是有真價值,維運人員是否應該做出什麼樣的因應措施?
答:我個人覺得這些方向都很好,如果大家只放在嘴巴上談談,那就是炒概念,只有實際做出來,才是先進的生產力。這些內容過去在百度時就做出不錯的效果,或許在一個體量很大的環境裡更容易實現,因為對應的數據量、人才厚度都會更充足。但如果有人只有100台機器,還談FinOps,那可能真是炒一炒概念,其他也同理。
問:隨著雲端的發展,傳統的只做Ops的運維崗位長期來看必將消亡,您是否認可這個觀點?對於這類朋友的轉型路徑您有沒有什麼建議?
答:維運的職位不會消失,需求也會越來越重,但是否是人來做確實需要好好想想了。
一個軟體工程中,運作維護是非常關鍵的環節,但這個環節是人來做,還是機器來做,要看科技的發展,就跟上面談到的掃大街一樣,只要有大街在,有人生活,掃大街這個需求是不會消失,而且很旺盛,但替代的可能是無人的機器,現在已經逐漸替代為由人駕駛的掃路車。我們要意識到這一點,同時也要認識到另外一點,運行維護是一個極其複雜的事情,它遠比掃路複雜,從雲服務這麼多年的成熟過程大家就能感受到,這是一個漫長的過程,我更建議這個維運自己革自己命的過程,由維運自身來主導和設計,最終我們會成為「營運維護」這個產品的擁有者。
問:很多朋友在脈脈上吐槽公司績效打分數不公平,您對他們有沒有什麼建議?另外您身為管理者,能否分享一下您是如何設計績效評估機制的?
答:這個主題比較敏感,也是維運同學非常期待討論的話題,所以下面觀點只是我個人職涯的經驗,不代表任何公司觀點。
以下是我個人感悟,績效是自己賺來的,談你績效好不好,就要看你為公司帶來多少突出的業績貢獻,你透過自己努力讓自己的本職工作發生哪些質的變化,績效通常是相對的排序,因此是相對公平,很難做到絕對的公平。
我們在談論績效的時候不妨和公司的老闆們換位思考下,一個是為公司賺錢的,一個是為公司守住基本用戶體驗花錢的,只有賺來更多錢才能給大家發工資,因此結果顯而易見。
當然這也和大家吃的苦不一樣有關,有人說人生有五種苦,第一種是體力的苦,強調拼加班,很多傳統運維工作都能吃這個苦;第二種是思考的苦,拼的是你佈局的周密性,做事的精細程度;第三種是耐得住寂寞的苦,要一個人不斷的默默的學習很多知識,人家吃喝玩樂的時候,他自己耗費了大把時光在不斷地學習新知識;第四種是尊嚴的苦,為了陪客戶老臉都不要,見誰都是自己的祖宗一樣點頭哈腰的伺候;第五種可以讓大家去猜一猜。不要說自己什麼苦都能吃,不同角色吃的苦不一樣,有個好的心態是身體健康的基礎。
最後,我祝福大家都能透過自己的努力獲得好的績效。以上觀點只是我個人經驗,不代表任何公司。
擴展閱讀
- #維百家講壇第4期:又拍雲邵海楊:25年Linux老兵聊DevOps八榮八恥
- #維百家講壇第3期:快貓來煒:如何把運維的飯碗端穩
- 運維百家講壇第2期:作業幫聶安:維運如何轉型,聽聽作業幫的OPaS思路
- #維百家講壇第1期:井源:維運幾何
關於SRETalk
本公眾號聊SRE相關的話題,各方面的,主理人是秦曉輝,Open-Falcon、Nightingale 創始研發,極客時間《維運監控系統實戰筆記》作者,快貓星雲(創業方向是統一監控、穩定性保障方向,如有需求歡迎聯絡我做交流)合夥人。
以上是度小滿陳存利:20年老「司令」聊聊維運、績效、成長的詳細內容。更多資訊請關注PHP中文網其他相關文章!

熱AI工具

Undresser.AI Undress
人工智慧驅動的應用程序,用於創建逼真的裸體照片

AI Clothes Remover
用於從照片中去除衣服的線上人工智慧工具。

Undress AI Tool
免費脫衣圖片

Clothoff.io
AI脫衣器

AI Hentai Generator
免費產生 AI 無盡。

熱門文章

熱工具

記事本++7.3.1
好用且免費的程式碼編輯器

SublimeText3漢化版
中文版,非常好用

禪工作室 13.0.1
強大的PHP整合開發環境

Dreamweaver CS6
視覺化網頁開發工具

SublimeText3 Mac版
神級程式碼編輯軟體(SublimeText3)

熱門話題

一、SpringBootActuator端點簡介1.1什麼是Actuator端點SpringBootActuator是一個用來監控和管理SpringBoot應用程式的子專案。它提供了一系列內建的端點(Endpoints),這些端點可以用於查看應用程式的狀態、運行情況和運行指標。 Actuator端點可以以HTTP、JMX或其他形式暴露給外部系統,以便於維運人員對應用程式進行監控、診斷和管理。 1.2端點的作用和功能Actuator端點主要用於實現以下功能:提供應用程式的健康檢查,包括資料庫連接、快取、

曾幾何時,當我還是一名初出茅廬的電腦專業應屆生的時候,在招聘網站上瀏覽了很多招聘貼,眼花繚亂的技術職位讓我摸不著頭腦:研發工程師、運維工程師、測試工程師...大學期間專業課馬馬虎虎,更談不上有什麼技術視野,對於具體從事那個技術方向並沒有什麼明確的想法。直到一位學長對我說:「做運維吧,做運維不用天天寫程式碼,會玩Liunx就行!比做開發輕鬆多了!」我選擇了相信......入行十多年,吃過很多苦,背了很多鍋,弄死過服務器,經歷過部門裁員,如果有人現在跟我說做維運比開發簡單,那我會

隨著網路的快速發展,企業級應用的複雜度日益增加。針對這種情況,微服務架構應運而生。它以模組化、獨立部署、可擴展性高等特點,成為當今企業級應用開發的首選。作為一種優秀的微服務架構,SpringCloud在實際應用中展現了極大的優勢。本文將介紹SpringCloud微服務架構的部署與維運。一、部署SpringCloud微服務架構SpringCloud

過節前我和PG中國社區合作搞了一個關於如何使用D-SMART來運維PG數據庫的線上直播,正好我的一個金融行業的客戶聽了我的介紹,打電話過來聊了聊。他們正在做資料庫信創的選型,也試用了多個國產資料庫,最後他們準備選擇TDSQL。當時我覺得有點意外,他們從2020年就開始在做國產資料庫選型,不過好像最初使用TDSQL後的感受並不太好。後來經過溝通才了解到,他們剛開始使用TDSQL的分散式資料庫,發現對研發要求太高,所以後來就全部選擇TDSQL的集中式MYSQL實例,用下來發現挺好用的。整個資料庫雲

可觀測性一詞源自於工程領域,近年來在軟體開發領域也日益普及。簡而言之,可觀測性是指根據外部輸出以了解系統內部狀態的能力。 IBM對可觀測性的定義為:通常,可觀測性是指基於對複雜系統外部輸出的了解就能夠了解其內部狀態或狀況的程度。系統越可觀測,定位效能問題根本原因的過程就能越快速且準確,而無需進行額外的測試或編碼。在雲端運算中,可觀測性也指對分散式應用系統及支撐其運作的基礎設施的資料進行聚合、關聯和分析的軟體工具和實踐,以便對應用系統進行更有效地監控、故障排除和調試,從而實現客戶體驗優化、服務等級協議

透過採訪和約稿的方式,請維運領域老砲輸出深刻洞見,共同碰撞,以期形成一些先進的共識,推動產業更好得前進。這一期我們邀請到的是鄒軼事,途遊遊戲運維總監,鄒總經常戲稱自己是世界500萬強企業的運維代表,可見內心中是覺得中小公司的運維建設思路和大型企業是有差別的,今天我們帶著幾個問題,來請鄒總分享一下他的中小公司研運一體化之路。這裡是接地氣、有高度的《運維百家講壇》第6期,開講!問題預覽途遊是遊戲公司,您覺得遊戲維有哪些獨特性?面臨的最大維運挑戰是什麼?您又是如何解決這些挑戰的?遊戲維運的人

維運不要學golang,原因是:1、golang主要被用於開發高效能和並發效能要求較高的應用程式;2、維運工程師通常使用的工具和腳本語言已經能夠滿足大部分的管理和維護需求;3、學習golang需要一定的程式設計基礎和經驗;4、維運工程師的主要目標是確保系統的穩定和高可用性,而不是開發應用程式。

透過採訪和約稿的方式,請維運領域老砲輸出深刻洞見,共同碰撞,以期形成一些先進的共識,推動產業更好得前進。這一期我們邀請到的是陳存利,度小滿系統維運部總經理,20多年的職業生涯中絕大部分時間在互聯網領域。在百度維運部期間由於帶隊風格過硬,兄弟團隊稱其為」陳司令」。今天我們請「陳司令」來聊聊他的觀點。這裡是接地氣、有高度的《運維百家講壇》第5期,開講!問題預覽您很早加入了百度,後來隨度小滿獨立,我們了解到您身邊有許多員工其實是很長時間一直跟著您,經歷了很多業務的維運考驗,相信大家都很感興
