通過采訪和約稿的方式，請運維領(lǐng)域老炮輸出深刻洞見，共同碰撞，以期形成一些先進的共識，推動行業(yè)更好得前進。

這一期我們邀請到的是又拍云科技的邵海楊，一個25年的Linux老炮，邵總醉心技術(shù)，一步一步往上走，是普通運維人員的典型成長路徑，希望今天的采訪可以對你有那么一些啟發(fā)。

這里是接地氣、有高度的《??運維百家講壇??》第 4 期，開講！

您好邵總，請您先做個自我介紹吧，聊聊您的履歷和現(xiàn)狀，讓大家更好的認識您，了解您的背景也有助于讀者理解后面的采訪內(nèi)容

我是來自又拍云科技的邵海楊，從1998年開始使用Linux至今快25年了，資深(老鳥)Linux系統(tǒng)運維/架構(gòu)師，DevOps八榮八恥倡導(dǎo)者，業(yè)余撰稿人；精通(心虛)系統(tǒng)優(yōu)化及網(wǎng)絡(luò)服務(wù)管理，Linux系統(tǒng)定制，CDN加速和安全防御; 擅長互聯(lián)網(wǎng)高性能網(wǎng)絡(luò)及架構(gòu)設(shè)計、虛擬化KVM及OpenStack云平臺, K8S容器云和Ceph分布式存儲等新技術(shù)；喜歡交流分享，活躍于社區(qū)，一直積極投身于開源活動的組織和傳播。

運維領(lǐng)域，每個公司都會制定自己的運維準則或者操作規(guī)范，能否分享一下貴司的經(jīng)驗，給我們一些參考？

又拍云是一家提供云存儲，云分發(fā)，云處理服務(wù)的公司，也是國內(nèi)首創(chuàng)可編程CDN 服務(wù)的專業(yè)云服務(wù)提供商，特點就是7x24全年不間斷服務(wù)，所以云運維也有一些律條或原則，比如：

先保障穩(wěn)定，然后再優(yōu)化

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

提供可靠的測試依據(jù)和時間驗證

引入新技術(shù)到架構(gòu)之前，要確保新技術(shù)的穩(wěn)定性和足夠時間久的考驗，更要有運維工程化中開發(fā)出來的工具鏈的完整。一旦線上返工或變更造成的措手不及可能已經(jīng)是故障的導(dǎo)火索。

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

自動部署、自動編排、自動巡檢、自動升級等自動化手段越來越多應(yīng)用于云運維。這是適應(yīng)云計算時代的趨勢，但能力越強，責(zé)任越大，要謹慎自動化的雪崩和驚群效應(yīng)，做好灰度/藍綠部署和各種測試。

保持簡單，監(jiān)控一切

保持簡單，別把事搞的太復(fù)雜。除了常見的異常問題報警外，面向業(yè)務(wù)指標，市場指標和銷售數(shù)據(jù)，成本等都可以用來做趨勢分析信息。定期的輪詢查看各個趨勢數(shù)據(jù)的峰值峰谷有助于見微知著。

面向預(yù)算的運維

運維團隊通常是最大的花費者，因為預(yù)算不足，沒有錢的運維是很難兼顧到日益增長的公司業(yè)務(wù)規(guī)模，除非公司業(yè)務(wù)已經(jīng)停滯或不再有爆炸式的增長，面對這樣的挑戰(zhàn)，運維要學(xué)會降本增益，開源節(jié)流，利用新技術(shù)實現(xiàn)能效比的提升。

面向場景的智能運維

各種各樣的負載場景，從高并發(fā)處理到視頻轉(zhuǎn)碼，從高性能并行計算到海量的網(wǎng)絡(luò)請求。這些不同的負載場景，對網(wǎng)絡(luò)帶寬，各種處理和IO的要求也各不相同。智能運維就是需要深入理解業(yè)務(wù)，合理配置資源和架構(gòu)來滿足不同業(yè)務(wù)場景的需求。

持續(xù)集成和發(fā)布系統(tǒng)

持續(xù)發(fā)布包括灰度發(fā)布、測試發(fā)布、滾動發(fā)布、回滾發(fā)布等多種場景，并且確保每種場景都應(yīng)該是可以可控的。

確保任何人都可以被替換

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

雖說成長是自己的事情，但如果有合適的場域、合適的項目機會、合適的團隊、合適的機制，會讓工程師的成長更快，團隊更有戰(zhàn)斗力，您能否系統(tǒng)的談一下是如何促成運維同學(xué)的成長的？

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

• 每月開放日：公司內(nèi)技術(shù)委員會會定期舉辦講座，分享前沿研究中的一些收獲，要求有主題，有重點，有應(yīng)用場景，最好有實例。
• 每周分享會：鼓勵所有開發(fā)者定期分享新的技術(shù)，談?wù)撍麄兠鎸Φ膯栴}，或者任何別的他們正思考的東西，分享的內(nèi)容會形成文檔和視頻存檔，并根據(jù)評分給予獎金和積分激勵。
• 公司懸賞項目：無論是公司還是員工自身都可以發(fā)起項目，技術(shù)委員會評審?fù)ㄟ^后，自行組隊完成，根據(jù)產(chǎn)出文檔，數(shù)據(jù)對比，技術(shù)分享后獲取相應(yīng)的項目獎金。申請專利還有相應(yīng)的專利獎金。
• 培養(yǎng)個人影響力：鼓勵員工通過發(fā)表文章或演講的形式，走出去做工程經(jīng)驗分享、工作心得的梳理，提高個人的影響力，并根據(jù)受眾的反饋給予稿費和講師費激勵。
• 訂閱報刊，雜志等紙質(zhì)書籍，了解最新動態(tài)。以部門為單位，配置一定的購書津貼。

又拍云運維團隊內(nèi)的培養(yǎng)包括：

• 化“天花板為托板”：把自己放在一個培養(yǎng)新人的管理角色，不讓自己成公司瓶頸和員工的天花板，鼓勵新人們?nèi)L新和處理故障，增加自身的技能和實戰(zhàn)經(jīng)驗；信任，互助，激勵，他們會持續(xù)不斷創(chuàng)造驚喜。
• 制作“自動化工具”：利用自己的經(jīng)驗抽象業(yè)務(wù)成程序模型，制作或培訓(xùn)自動化腳本的編寫，提高團隊的工作效率，讓員工節(jié)省精力和時間去學(xué)習(xí)其它新知識；
• 承擔(dān)“高精專”項目：提前準備最新知識的研究和可行性分析，整理成文檔作公開培訓(xùn)，再交給團隊去深入研究和實施，轉(zhuǎn)化成生產(chǎn)力，積累一線經(jīng)驗再反饋完善文檔，良性循環(huán)；
• 積極提倡“知識分享”：各種案例和“坑”都會整理成wiki文檔，通過文檔共享，定期分享講座，鼓勵員工撰寫高質(zhì)量的，可讀性很強的文檔，開口培訓(xùn)，增加感染力和自信心；
• 鼓勵“參與開源交流”：公司鼓勵員工走出去參與技術(shù)交流大會，閉門造車耗時耗力，不如專業(yè)的人點撥。也會有購書經(jīng)費，團建活動經(jīng)費，茶歇文化；

運維工程師其中一個典型的職業(yè)路徑是做管理者，但管理者和資深運維要解決的問題截然不同，對于那些剛剛步入管理崗的資深運維，是否可以分享一些您的經(jīng)驗？

對于剛步入管理崗的運維來說，我的建議是及時梳理遺留的技術(shù)債和人才技能的盤點和培養(yǎng)，先打好基礎(chǔ)，后面才能有更大的空間進步，具體可以參考我的《??DevOps的八榮八恥??》的分享。

• 一、 以可配置為榮，以硬編碼為恥
• 二、 以互備為榮，以單點為恥
• 三、 以隨時重啟為榮，以不能遷移為恥
• 四、 以整體交付為榮，以部分交付為恥
• 五、 以無狀態(tài)為榮，以有狀態(tài)為恥
• 六、以標準化為榮，以特殊化為恥
• 七、以自動化工具為榮，以手動和人肉為恥
• 八、以無人值守為榮，以人工介入為恥

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

再結(jié)合公司的OKR目標管理來激勵員工，它的優(yōu)點在于聚集目標的同時，還能：

• 激勵個人自驅(qū)力，鼓勵員工創(chuàng)新和反思；
• 考查的是相對結(jié)果，鼓勵有難度的挑戰(zhàn)和突破；
• 考核的協(xié)同配合能力，鼓勵員工去全方位的協(xié)調(diào)推進；

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

雖然Kubernetes代表著目前為止的devops的最佳工程應(yīng)用實踐(真香)，但也不是所有場合都能應(yīng)用，如又拍云的CDN邊緣服務(wù)器，數(shù)據(jù)中心的日志分析平臺，Ceph分布式存儲就以物理機為主。所以，我建議找一些合適的場景先試用起來，如：

• 機器資源錯峰空閑浪費嚴重的；
• CPU，磁盤和網(wǎng)絡(luò)IO都不密集的；
• 不需要持久化存儲的或搶占資源的；
• 軟件架構(gòu)已經(jīng)做了微服務(wù)改造的；
• 業(yè)務(wù)處理程序有周期性、可彈性擴容的；

運維和研發(fā)是最親密的伙伴，貴司是如何做工作邊界劃分的？另外關(guān)于如何讓這兩個角色保持親密合作，是否可以分享一些經(jīng)驗？

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

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

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

• 積極參與事前的規(guī)劃，配合開發(fā)做演練，自動化部署，協(xié)助架構(gòu)改進
• 合理提需求，要資源，最好是有預(yù)算，做到防患于未燃
• 線上監(jiān)控，故障復(fù)盤，反饋給整個團隊，倒逼上下協(xié)調(diào)做改進

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

最后，我的個人觀點：架構(gòu)師它可能不是一個人的角色，而是一個團隊的統(tǒng)稱，它可以:

• 不必沖鋒陷陣，就可以縱觀全局，運籌帷幄，調(diào)度所有的資源（運維架構(gòu)師的功能）
• 可以帶領(lǐng)和團結(jié)團隊，高屋筑瓴，因時制宜的實現(xiàn)解決方案（軟件架構(gòu)師的功能）
• 可以把握公司業(yè)務(wù)方向和深度，洽談合作，控制成本（業(yè)務(wù)架構(gòu)師的功能）

運維需要和其他多個部門溝通協(xié)作，鑒于各個團隊目標關(guān)注點未必一致，合作起來可能未必有那么順暢，針對這個問題您是用什么招來讓這個過程更加順暢的？

其實溝通不順暢的原因大部分在于對后果的不可預(yù)見性，你說冗余他說預(yù)算，你說架構(gòu)他說工期，各有立場又各有苦衷，但就是沒人對結(jié)果負責(zé)。我在工作中發(fā)現(xiàn)，當(dāng)故障發(fā)生時，各部門的配合是空前團結(jié)，戰(zhàn)斗力也是最強的，所以，溝通協(xié)作的關(guān)鍵在于：既要團隊協(xié)作，也要責(zé)任分明

• 事前部門溝通時，確定好項目預(yù)期，成本，影響要素，故障后果及責(zé)任方；
• 事后故障復(fù)盤時，根據(jù)故障原因，有理有據(jù)的“甩鍋”，同時要引以為戒，亡羊補牢；

比如說提供在線10W并發(fā)的能力，需要冗余帶寬冗余服務(wù)器數(shù)量x2，因為預(yù)算不足減半所導(dǎo)致的后果及責(zé)任人；再比如軟件設(shè)計不好，通過性能監(jiān)控，發(fā)現(xiàn)指標異常的后果及責(zé)任人；當(dāng)然，報警處理不及時，人為操作故障也會算到運維亦無可厚非；故障文化就是要關(guān)注問題和關(guān)注事情本身，對事不對人。大家都在故障中成長，在復(fù)盤中變強。

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

運維自動化；

監(jiān)控常態(tài)化；

日志可視化！

這個篇幅太多了，不展開講，可以參考《??云運維的啟示和架構(gòu)設(shè)計??》

工具選型這塊，到底是自研，還是使用開源，還是使用商業(yè)產(chǎn)品，是如何抉擇的？

又拍云通常不會重復(fù)造輪子，但一定會先用好輪子，或者把輪子改造得更加稱手，選擇自研往往具備了一定的開發(fā)能力，再加上某些必要原因，如：

• 找不到符合要求的開源軟件，如我們自研的云處理軟件…
• 開源軟件有bug或者issue，社區(qū)短期內(nèi)無法推進，但業(yè)務(wù)又急需，只能通過自研解決，如ats的內(nèi)存泄露問題…
• 開源軟件的功能特點跟公司的業(yè)務(wù)不相符合，不得不改造軟件，如nginx的防盜鏈模塊，需要與客戶對接定制…
• 開源軟件的設(shè)計目標過于高大上，通用性好但很臃腫，如果我們只要某個小功能點，就不需要牛刀了，如性能探針的埋點…
• 有數(shù)據(jù)保護要求，或者有隱私的場合…

越來越多的公司在遷往公有云，云原生架構(gòu)下，SRE團隊的核心職能是否有些變化？應(yīng)該如何凸顯團隊的價值呢？

公有云做為IaaS基座，容器云作為CaaS中間層，云原生做為SaaS應(yīng)用層，整個云生態(tài)日新月異，SRE團隊的核心職能會更加注重頂層系統(tǒng)性的容量規(guī)劃，指標監(jiān)控，高可用性和分布式的彈性設(shè)計，所以跨平臺跨部門的職能互補、團隊協(xié)作、持續(xù)精進、勇于承擔(dān)包括：

• 積極參與事前的規(guī)劃，配合開發(fā)做演練，協(xié)助架構(gòu)改進；
• 合理提可用性需求，冗余資源，最好是有預(yù)算，做到防患于未燃；
• 線上監(jiān)控，故障分析，反饋給整個團隊，倒逼上下協(xié)調(diào)做改進；

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

對于運維工程師個體，SRE的轉(zhuǎn)型路徑是？應(yīng)該注意些什么？

技術(shù)領(lǐng)域

• 學(xué)會抽象業(yè)務(wù)模型，標準化組件，定制化腳本，自動化部署，提升整體效率；
• 學(xué)會收集日志和日志分析并可視化，提升運維監(jiān)控和預(yù)警報警的效率；
• 掌握和熟悉一門或若干語言，能夠幫助你成長，提升你的戰(zhàn)斗力；
• 勤做筆記，溫故而知新，學(xué)思結(jié)合，要學(xué)會沉淀，舉一反三；
• 勇于面對新興技術(shù)的挑戰(zhàn)，打不過就學(xué)它；

非技術(shù)領(lǐng)域

• 學(xué)習(xí)能力，要知識面廣；
• 溝通方面，了解客戶的精確需求；
• 技術(shù)風(fēng)險、人工、進度等成本，權(quán)衡取舍；
• 社區(qū)活動，積極分享，鍛煉口才和交流能力；
• 提升自己的影響力，學(xué)會與人同行，可以交到更多的朋友；

面對當(dāng)下快速發(fā)展的基礎(chǔ)技術(shù)，您對給剛?cè)胄泻腿胄幸丫玫倪\維人員，分別有什么職業(yè)規(guī)劃的建議嗎？

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

您覺得運維人員最重要的素養(yǎng)是什么？對新入行的運維人員有哪些寄語？

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