透過訪談和約稿的方式，請維運領域老砲輸出深刻洞見，共同碰撞，以期形成一些先進的共識，推動行業更好得前進。
這一期我們邀請到的是又拍雲科技的邵海楊，一個25年的Linux老炮，邵總醉心技術，一步一步往上走，是普通運維人員的典型成長路徑，希望今天的採訪可以對你有那麼一些啟發。
這裡是接地氣、有高度的《運維百家講壇》第 4 期，開講！
我是來自又拍雲科技的邵海楊，從1998年開始使用Linux至今快25年了，資深(老鳥)Linux系統維運/架構師，DevOps八榮八恥倡導者，業餘撰稿人；精通(心虛)系統優化及網路服務管理，Linux系統定制，CDN加速和安全防禦; 擅長互聯網高性能網絡及架構設計、虛擬化KVM及OpenStack雲端平台, K8S容器雲端和Ceph分散式儲存等新技術；喜歡交流分享，活躍於社區，一直積極投身於開源活動的組織和傳播。
又拍雲是一家提供雲端存儲，雲端分發，雲端處理服務的公司，也是國內首創可程式CDN 服務的專業雲端服務供應商，特點就是7x24全年不間斷服務，所以雲端運維也有一些律條或原則，例如：
先保障穩定，然後再優化
過度設計或過早優化很可能會帶來更多的故障停機時間，先集中精力提高系統的可擴展性和高可用性。堅持 “先完成，再完善，後完美”，專案也是“先能用，再好用，後用好”的實施策略。
提供可靠的測試依據和時間驗證
引入新技術到架構之前，要確保新技術的穩定性和足夠時間久的考驗，更要有運維工程化中所發展出來的工具鏈的完整。一旦線上返工或變更造成的措手不及可能已經是故障的導火線。
使用可控的自動化手段提升效率
自動部署、自動編排、自動巡檢、自動升級等自動化手段越來越多應用於雲端維。這是適應雲端運算時代的趨勢，但能力越強，責任越大，要謹慎自動化的雪崩和驚群效應，做好灰階/藍綠部署和各種測試。
保持簡單，監控一切
保持簡單，別把事搞的太複雜。除了常見的異常問題警報外，面向業務指標，市場指標和銷售數據，成本等都可以用來做趨勢分析資訊。定期的輪詢查看各個趨勢資料的峰值峰谷有助於見微知著。
預算導向的維運
維運團隊通常是最大的花費者，因為預算不足，沒有錢的維運是很難兼顧到日益增長的公司業務規模，除非公司業務已經停滯或不再有爆炸性的成長，面對這樣的挑戰，維運要學會降本增益，開源節流，利用新技術實現能源效率比的提升。
面向場景的智能運維
各種各樣的負載場景，從高並發處理到視訊轉碼，從高效能並行計算到海量的網絡請求。這些不同的負載場景，對網路頻寬，各種處理和IO的要求也各不相同。智慧運維就是需要深入理解業務，合理配置資源和架構來滿足不同業務場景的需求。
持續整合和發布系統
持續發布包括灰階發布、測試發布、捲動發布、回滾發布等多種場景，並確保每種場景都應該是可以可控的。
確保任何人都可以被替換
鐵打的營盤流水的兵，人挪活是常態，做好員工的共享文檔管理和知識傳遞和分享，理論上所有人都可以被替換，任何人也不應該成為公司的天花板。
公司一直是積極鼓勵員工的技能自我提升和促進成長：
又拍雲維運團隊內的培養包括：
對於剛步入管理崗的維運來說，我的建議是及時梳理遺留的技術債和人才技能的盤點和培養，先打好基礎，後面才能有更大的空間進步，具體可以參考我的《DevOps的八榮八恥》的分享。
人才上技能樹的盤點，主要是配合人事做好人才九宮格的劃分（如果是開發或維，把左側的績效換成潛力，績效針對銷售而言），考查的是管理者對員工的全方面的辨識能力，知人善用。
再結合公司的OKR目標管理來激勵員工，它的優點在於聚集目標的同時，還能：
雖然Kubernetes代表著目前為止的devops的最佳工程應用實踐(真香)，但也不是所有場合都能應用，如又拍雲的CDN邊緣伺服器，資料中心的日誌分析平台，Ceph分散式儲存就以實體機為主。所以，我建議找一些合適的場景先試用起來，如：
維運工程師= 衝鋒陷陣的將軍
軟體工程師= 坐陣帳中的軍師
理論上，優秀的軟體工程師是可以把部分(甚至全部)維運工程師的工作做掉，比如說業務軟體效能的監控，如果程式設計師在程式中插入很多的鉤子或探針，就可以統計出資料來，不需要維運勞心勞力的監控；比如說程式設計師在設計程式的時候，考慮到了分庫分錶，考慮到了大並發和分散式的設計，那運維就可以水平擴展機器就行；如果軟體沒有那麼多bug ，還有很多如果......但是，現實是殘酷的，這種高水平的程式設計師太少了，尤其在中國，大家都忙於實現業務功能，連個文檔甚至註釋都不願意寫，更別提能夠考慮這麼周全了；同理，運維接觸的很多是開源很優秀很成熟的軟體，從中是可以藉鑑知曉優秀軟體是怎麼設計的，比如優秀的程序，日誌資訊會非常詳盡，我們可以透過標準的syslog或日誌去監控它，所以，資深的運維會:
#當然，要達到上述能力的維運管理，肯定需要潛心研究，承上啟下，協調團隊，任勞任怨的修行多年，到那個時候，運維就不再是對事情的結果負責，而是轉變角色，主導和協調整個過程。當然，這裡指的能力不僅是技能，還包括對業務的理解能力，站在公司管理階層面對整個專案和資源的分配和掌握。因此，維運工程師其實是現實中的軟體工程師的互補，因為大家的能力重點不同，所以大家更要團結一體，要能夠打勝仗，離開誰都是不行的，這是一個共同修煉進步的過程。
最後，我的個人觀點：架構師它可能不是一個人的角色，而是一個團隊的統稱，它可以:
其實溝通不順暢的原因大部分在於對後果的不可預見性，你說冗餘他說預算，你說架構他說工期，各有立場又各有苦衷，但就是沒人為結果負責。我在工作中發現，當故障發生時，各部門的配合是空前團結，戰鬥力也是最強的，所以，溝通協作的關鍵在於：既要團隊協作，也要責任分明
比如說提供在線10W並發的能力，需要冗餘頻寬冗餘伺服器數量x2，因為預算不足減半所導致的後果及責任人；再例如軟體設計不好，透過效能監控，發現指標異常的後果及責任人；當然，警報處理不及時，人為操作故障也會算到運維亦無可厚非；故障文化就是要關注問題和關注事情本身，對事不對人。大家都在故障中成長，在複盤變強。
運維自動化;
監控常態化；
日誌視覺化！
這個篇幅太多了，不展開講，可以參考《雲端運維的啟示與架構設計》
又拍雲通常不會重複造輪子，但一定會先用好輪子，或是把輪子改造得更加稱手，選擇自研往往具備了一定的開發能力，再加上某些必要原因，如：
公有雲做為IaaS基座，容器雲作為CaaS中間層，雲原生做為SaaS應用層，整個雲生態日新月異，SRE團隊的核心職能會更重視頂層系統性的容量規劃，指標監控，高可用性和分散式的彈性設計，所以跨平台跨部門的職能互補、團隊協作、持續精進、勇於承擔包括：
團隊的價值就在於是否總是能夠接受新事物，新的挑戰，各施所長，不做井底之蛙，也不是溫水煮青蛙，在創新或顛覆的時候，也能保持不被時代脫鉤。
技術領域
非技術領域
首先不是工作選擇人，而是人選擇工作，一個人若對某方面有了興趣，真正用心學習了近10000個小時，其實做什麼都是可以的。比如說我畢業那個時候，都是強調複合型人才，根本沒有運維這個職業，我們不光自己攢(DIY)機器，自學Linux操作系統，還學習編程，折騰網絡，自己動手寫論壇聊天室等程序；Linux帶給我們的是每天都有創新的，好玩的，優秀的開源軟體讓我們保持熱情去盡情的折騰和學習，當網路興起的機會來臨時，做個維運總監其實也是順理成章的事； 其實，除此之外，我還轉型做過售前，技術支持，跑過市場，經常做演講培訓，所以真正的高手是什麼不會學什麼，技多不壓身，做個懂業務、會開發的維運工程師。
我認為最重要的能力是表達溝通能力，但不排除維運本身所需的技術儲備、實踐動手能力、程式設計能力和學習能力。考慮到維運大部分還是一個成本支出的崗位，如何把深奧隱晦的性能及瓶頸指標，用直觀的圖表展示來獲取上層持續的投入是需要技巧的；然後面對你的同事，你的兄弟部門，也需要你的影響力去協調推進工作，如果能夠做到這些，說明你已經具備了領導的才能，這樣以後做什麼事都會站在更高的水平，用全局觀的格局去統籌規劃整個項目的目標，人員，工期和資源的合理分配和把握。
以上是又拍雲邵海楊：25年Linux老兵聊DevOps八榮八恥的詳細內容。更多資訊請關注PHP中文網其他相關文章！
