又拍雲邵海楊 - 25年Linux老兵,聊聊運維的“術”與“道”

您好邵總,請您先做個自我介紹吧,聊聊您的履歷和現狀,讓大家更好的認識您,瞭解您的背景也有助於讀者理解後面的採訪內容

我是來自又拍雲的邵海楊,從1998年開始使用Linux至今快25年了,資深(老鳥)Linux系統運維/架構師,DevOps八榮八恥倡導者,業餘撰稿人;精通(心虛)系統優化及網絡服務管理,Linux系統定製,CDN加速和安全防禦; 擅長互聯網高性能網絡及架構設計、虛擬化KVM及OpenStack雲平臺, K8S容器雲和Ceph分佈式存儲等新技術;喜歡交流分享,活躍於社區,一直積極投身於開源活動的組織和傳播。

運維領域,每個公司都會制定自己的運維準則或者操作規範,能否分享一下貴司的經驗,給我們一些參考?

又拍雲是一家提供雲存儲,雲分發,雲處理服務的公司,也是國內首創可編程CDN 服務的專業雲服務提供商,特點就是7x24全年不間斷服務,所以雲運維也有一些律條或原則,比如:

先保障穩定,然後再優化

過度設計或過早優化很可能會帶來更多的故障停機時間,要先集中精力提高系統的可擴展性和高可用性。堅持 “先完成,再完善,後完美”,項目也是“先能用,再好用,後用好”的實施策略。

提供可靠的測試依據和時間驗證

引入新技術到架構之前,要確保新技術的穩定性和足夠時間久的考驗,更要有運維工程化中開發出來的工具鏈的完整。一旦線上返工或變更造成的措手不及可能已經是故障的導火索。

使用可控的自動化手段提升效率

自動部署、自動編排、自動巡檢、自動升級等自動化手段越來越多應用於雲運維。這是適應雲計算時代的趨勢,但能力越強,責任越大,要謹慎自動化的雪崩和驚羣效應,做好灰度/藍綠部署和各種測試。

保持簡單,監控一切

保持簡單,別把事搞得太複雜。除了常見的異常問題報警外,面向業務指標,市場指標和銷售數據,成本等都可以用來做趨勢分析信息。定期的輪詢查看各個趨勢數據的峯值峯谷有助於見微知著。

面向預算的運維

運維團隊通常是最大的花費者,因爲預算不足,沒有錢的運維是很難兼顧到日益增長的公司業務規模,除非公司業務已經停滯或不再有爆炸式的增長,面對這樣的挑戰,運維要學會降本增益,開源節流,利用新技術實現能效比的提升。

面向場景的智能運維

各種各樣的負載場景,從高併發處理到視頻轉碼,從高性能並行計算到海量的網絡請求。這些不同的負載場景,對網絡帶寬,各種處理和IO的要求也各不相同。智能運維就是需要深入理解業務,合理配置資源和架構來滿足不同業務場景的需求。

持續集成和發佈系統

持續發佈包括灰度發佈、測試發佈、滾動發佈、回滾發佈等多種場景,並且確保每種場景都應該是可以可控的。

確保任何人都可以被替換

鐵打的營盤流水的兵,人挪活是常態,做好員工的共享文檔管理和知識傳遞和分享,理論上所有人都可以被替換,任何人也不應該成爲公司的天花板。

雖說成長是自己的事情,但如果有合適的場域、合適的項目機會、合適的團隊、合適的機制,會讓工程師的成長更快,團隊更有戰鬥力,您能否系統的談一下是如何促成運維同學的成長的?

公司一直是積極鼓勵員工的技能自我提高和促進成長:

  • 每月開放日:公司內技術委員會會定期舉辦講座,分享前沿研究中的一些收穫,要求有主題,有重點,有應用場景,最好有實例。

  • 每週分享會:鼓勵所有開發者定期分享新的技術,談論他們面對的問題,或者任何別的他們正思考的東西,分享的內容會形成文檔和視頻存檔,並根據評分給予獎金和積分激勵。

  • 公司懸賞項目:無論是公司還是員工自身都可以發起項目,技術委員會評審通過後,自行組隊完成,根據產出文檔,數據對比,技術分享後獲取相應的項目獎金。申請專利還有相應的專利獎金。

  • 培養個人影響力:鼓勵員工通過發表文章或演講的形式,走出去做工程經驗分享、工作心得的梳理,提高個人的影響力,並根據受衆的反饋給予稿費和講師費激勵。

  • 訂閱報刊,雜誌等紙質書籍,瞭解最新動態。以部門爲單位,配置一定的購書津貼。

又拍雲運維團隊內的培養包括:

  • 化“天花板爲託板”:把自己放在一個培養新人的管理角色,不讓自己成公司瓶頸和員工的天花板,鼓勵新人們去嘗新和處理故障,增加自身的技能和實戰經驗;信任,互助,激勵,他們會持續不斷創造驚喜。

  • 製作“自動化工具”:利用自己的經驗抽象業務成程序模型,製作或培訓自動化腳本的編寫,提高團隊的工作效率,讓員工節省精力和時間去學習其它新知識;

  • 承擔“高精專”項目:提前準備最新知識的研究和可行性分析,整理成文檔作公開培訓,再交給團隊去深入研究和實施,轉化成生產力,積累一線經驗再反饋完善文檔,良性循環;

  • 積極提倡“知識分享”:各種案例和“坑”都會整理成wiki文檔,通過文檔共享,定期分享講座,鼓勵員工撰寫高質量的,可讀性很強的文檔,開口培訓,增加感染力和自信心;

  • 鼓勵“參與開源交流”:公司鼓勵員工走出去參與技術交流大會,閉門造車耗時耗力,不如專業的人點撥。也會有購書經費,團建活動經費,茶歇文化;

運維工程師其中一個典型的職業路徑是做管理者,但管理者和資深運維要解決的問題截然不同,對於那些剛剛步入管理崗的資深運維,是否可以分享一些您的經驗?

對於剛步入管理崗的運維來說,我的建議是及時梳理遺留的技術債和人才技能的盤點和培養,先打好基礎,後面纔能有更大的空間進步,具體可以參考我的《DevOps的八榮八恥》的分享。

一、 以可配置爲榮,以硬編碼爲恥

二、 以互備爲榮,以單點爲恥

三、 以隨時重啓爲榮,以不能遷移爲恥

四、 以整體交付爲榮,以部分交付爲恥

五、 以無狀態爲榮,以有狀態爲恥

六、以標準化爲榮,以特殊化爲恥

七、以自動化工具爲榮,以手動和人肉爲恥

八、以無人值守爲榮,以人工介入爲恥人

才上技能樹的盤點,主要是配合人事做好人才九宮格的劃分(如果是開發或運維,把左側的績效換成潛力,績效針對銷售而言),考查的是管理者對員工的全方面的辨析能力,知人善用。

再結合公司的OKR目標管理來激勵員工,它的優點在於聚集目標的同時,還能:

  • 激勵個人自驅力,鼓勵員工創新和反思;

  • 考查的是相對結果,鼓勵有難度的挑戰和突破;

  • 考覈的協同配合能力,鼓勵員工去全方位的協調推進;

Kubernetes火了好一段時間了,很多公司也在大規模應用了,但顯然,每個技術都不是銀彈,無法解決所有場景的問題,這幾年觀察下來,您覺得哪些公司不適合上Kubernetes?能否給一個這類公司的畫像,並說明理由?

雖然Kubernetes代表着目前爲止的devops的最佳工程應用實踐(真香),但也不是所有場合都能應用,如又拍雲的CDN邊緣服務器,數據中心的日誌分析平臺,Ceph分佈式存儲就以物理機爲主。所以,我建議找一些合適的場景先試用起來,如:

  • 機器資源錯峯空閒浪費嚴重的;

  • CPU,磁盤和網絡IO都不密集的;

  • 不需要持久化存儲的或搶佔資源的;

  • 軟件架構已經做了微服務改造的;

  • 業務處理程序有周期性、可彈性擴容的;

運維和研發是最親密的夥伴,貴司是如何做工作邊界劃分的?另外關於如何讓這兩個角色保持親密合作,是否可以分享一些經驗?

  • 運維工程師 = 衝鋒陷陣的將軍

  • 軟件工程師 = 坐陣帳中的軍師

理論上,優秀的軟件工程師是可以把部分(甚至全部)運維工程師的工作做掉,比如說業務軟件性能的監控,如果程序員在程序中插入很多的鉤子或探針,就可以統計出數據來,不需要運維勞心勞力的監控;比如說程序員在設計程序的時候,考慮到了分庫分表,考慮到了大併發和分佈式的設計,那運維就可以水平擴展機器就行;如果軟件沒有那麼多bug,還有很多如果......但是,現實是殘酷的,這種高水平的程序員太少了,尤其在中國,大家都忙於實現業務功能,連個文檔甚至註釋都不願意寫,更別提能夠考慮這麼周全了;同理,運維接觸的很多是開源很優秀很成熟的軟件,從中是可以借鑑知曉優秀軟件是怎麼設計的,比如優秀的程序,日誌信息會非常詳盡,我們可以通過標準的syslog或者日誌去監控它,所以,資深的運維會:

  • 積極參與事前的規劃,配合開發做演練,自動化部署,協助架構改進

  • 合理提需求,要資源,最好是有預算,做到防患於未燃

  • 線上監控,故障覆盤,反饋給整個團隊,倒逼上下協調做改進

當然,要達到上述能力的運維管理,肯定需要潛心研究,承上啓下,協調團隊,任勞任怨的修行多年,到那個時候,運維就不再是對事情的結果負責,而是轉變角色,主導和協調整個過程。當然,這裏指的能力不僅僅是技能,還包括對業務的理解能力,站在公司管理層面對整個項目和資源的分配和把握。因此,運維工程師其實是現實中的軟件工程師的互補,因爲大家的能力側重點不同,所以大家更要團結一體,要能夠打勝仗,離開誰都是不行的,這是一個共同修煉進步的過程。

最後,我的個人觀點:架構師它可能不是一個人的角色,而是一個團隊的統稱,它可以:

  • 不必衝鋒陷陣,就可以縱觀全局,運籌帷幄,調度所有的資源(運維架構師的功能)

  • 可以帶領和團結團隊,高屋築瓴,因時制宜的實現解決方案(軟件架構師的功能)

  • 可以把握公司業務方向和深度,洽談合作,控制成本(業務架構師的功能)

運維需要和其他多個部門溝通協作,鑑於各個團隊目標關注點未必一致,合作起來可能未必有那麼順暢,針對這個問題您是用什麼招來讓這個過程更加順暢的?

其實溝通不順暢的原因大部分在於對後果的不可預見性,你說冗餘他說預算,你說架構他說工期,各有立場又各有苦衷,但就是沒人對結果負責。我在工作中發現,當故障發生時,各部門的配合是空前團結,戰鬥力也是最強的,所以,溝通協作的關鍵在於: 既要團隊協作,也要責任分明

  • 事前部門溝通時,確定好項目預期,成本,影響要素,故障後果及責任方;

  • 事後故障覆盤時,根據故障原因,有理有據地“甩鍋”,同時要引以爲戒,亡羊補牢;

比如說提供在線10W併發的能力,需要冗餘帶寬冗餘服務器數量x2,因爲預算不足減半所導致的後果及責任人;再比如軟件設計不好,通過性能監控,發現指標異常的後果及責任人;當然,報警處理不及時,人爲操作故障也會算到運維亦無可厚非;故障文化就是要關注問題和關注事情本身,對事不對人。大家都在故障中成長,在覆盤中變強。

您覺得運維工作最重要的幾個目標是什麼?您是怎麼落地這些目標的?

運維自動化;

監控常態化;

日誌可視化!

這個篇幅太多了,不展開講,可以參考《雲運維的啓示和架構設計

工具選型這塊,到底是自研,還是使用開源,還是使用商業產品,是如何抉擇的?

又拍雲通常不會重複造輪子,但一定會先用好輪子,或者把輪子改造得更加稱手,選擇自研往往具備了一定的開發能力,再加上某些必要原因,如:

  • 找不到符合要求的開源軟件,如我們自研的雲處理軟件…

  • 開源軟件有bug或者issue,社區短期內無法推進,但業務又急需,只能通過自研解決,如ats的內存泄露問題…

  • 開源軟件的功能特點跟公司的業務不相符合,不得不改造軟件,如nginx的防盜鏈模塊,需要與客戶對接定製…

  • 開源軟件的設計目標過於高大上,通用性好但很臃腫,如果我們只要某個小功能點,就不需要牛刀了,如性能探針的埋點…

  • 有數據保護要求,或者有隱私的場合…

越來越多的公司在遷往公有云,雲原生架構下,SRE團隊的核心職能是否有些變化?應該如何凸顯團隊的價值呢?

公有云作爲IaaS基座,容器雲作爲CaaS中間層,雲原生作爲SaaS應用層,整個雲生態日新月異,SRE團隊的核心職能會更加註重頂層系統性的容量規劃,指標監控,高可用性和分佈式的彈性設計,所以跨平臺跨部門的職能互補、團隊協作、持續精進、勇於承擔包括:

  • 積極參與事前的規劃,配合開發做演練,協助架構改進;

  • 合理提可用性需求,冗餘資源,最好是有預算,做到防患於未燃;

  • 線上監控,故障分析,反饋給整個團隊,倒逼上下協調做改進;

團隊的價值就在於是否總是能夠接受新事物,新的挑戰,各施所長,不做井底之蛙,也不是溫水煮青蛙,在創新或者顛覆來臨的時候,也能保持不被時代脫鉤。

對於運維工程師個體,SRE的轉型路徑是?應該注意些什麼?

技術領域

  • 學會抽象業務模型,標準化組件,定製化腳本,自動化部署,提升整體效率;

  • 學會收集日誌和日誌分析並可視化,提升運維監控和預警報警的效率;

  • 掌握和熟悉一門或若干語言,能夠幫助你成長,提升你的戰鬥力;

  • 勤做筆記,溫故而知新,學思結合,要學會沉澱,舉一反三;

  • 勇於面對新興技術的挑戰,打不過就學它;

非技術領域

  • 學習能力,要知識面廣;

  • 溝通方面,瞭解客戶的精確需求;

  • 技術風險、人工、進度等成本,權衡取捨;

  • 社區活動,積極分享,鍛鍊口才和交流能力;

  • 提升自己的影響力,學會與人同行,可以交到更多的朋友;

面對當下快速發展的基礎技術,您對給剛入行和入行已久的運維人員,分別有什麼職業規劃的建議嗎?

首先不是工作選擇人,而是人選擇工作,一個人若對某方面有了興趣,真正用心學習了近10000個小時,其實做什麼都是可以的。比如說我畢業那個時候,都是強調複合型人才,根本沒有運維這個職業,我們不光自己攢(DIY)機器,自學Linux操作系統,還學習編程,折騰網絡,自己動手寫論壇聊天室等程序;Linux給我們帶來的是每天都有創新的,好玩的,優秀的開源軟件讓我們保持激情去盡情的折騰和學習,當互聯網興起的機會來臨時,做個運維總監其實也是順理成章的事;其實,除此之外,我還轉型做過售前,技術支持,跑過市場,經常做演講培訓,所以真正的高手是什麼不會學什麼,技多不壓身,做個懂業務、會開發的運維工程師。

您覺得運維人員最重要的素養是什麼?對新入行的運維人員有哪些寄語?

我認爲最重要的能力是表達溝通能力,但不排除運維本身所需的技術儲備、實踐動手能力、編程能力和學習能力。考慮到運維大部分還是一個成本支出的崗位,如何把深奧隱晦的性能及瓶頸指標,用直觀的圖表展示來獲取上層持續的投入是需要技巧的;然後面對你的同事,你的兄弟部門,也需要你的影響力去協調推進工作,如果能夠做到這些,說明你已經具備了領導的才能,這樣以後做什麼事都會站在更高的水平,用全局觀的格局去統籌規劃整個項目的目標,人員,工期和資源的合理分配和把握。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章