通過采訪和約稿的方式，請運維領域老炮輸出深刻洞見，共同碰撞，以期形成一些先進的共識，推動行業更好得前進。
這一期我們邀請到的是又拍云科技的邵海楊，一個25年的linux老炮，邵總醉心技術，一步一步往上走，是普通運維人員的典型成長路徑，希望今天的采訪可以對你有那么一些啟發。
這里是接地氣、有高度的《??運維百家講壇??》第 4 期，開講！
您好邵總，請您先做個自我介紹吧，聊聊您的履歷和現狀，讓大家更好的認識您，了解您的背景也有助于讀者理解后面的采訪內容
我是來自又拍云科技的邵海楊，從1998年開始使用Linux至今快25年了，資深(老鳥)Linux系統運維/架構師，devops八榮八恥倡導者，業余撰稿人；精通(心虛)系統優化及網絡服務管理，Linux系統定制，CDN加速和安全防御; 擅長互聯網高性能網絡及架構設計、虛擬化KVM及openstack云平臺, K8S容器云和ceph分布式存儲等新技術；喜歡交流分享，活躍于社區，一直積極投身于開源活動的組織和傳播。
運維領域，每個公司都會制定自己的運維準則或者操作規范，能否分享一下貴司的經驗，給我們一些參考？
又拍云是一家提供云存儲，云分發，云處理服務的公司，也是國內首創可編程CDN 服務的專業云服務提供商，特點就是7×24全年不間斷服務，所以云運維也有一些律條或原則，比如：
先保障穩定，然后再優化
過度設計或過早優化很可能會帶來更多的故障停機時間，要先集中精力提高系統的可擴展性和高可用性。堅持 “先完成，再完善，后完美”，項目也是“先能用，再好用，后用好”的實施策略。
提供可靠的測試依據和時間驗證
引入新技術到架構之前，要確保新技術的穩定性和足夠時間久的考驗，更要有運維工程化中開發出來的工具鏈的完整。一旦線上返工或變更造成的措手不及可能已經是故障的導火索。
使用可控的自動化手段提升效率
自動部署、自動編排、自動巡檢、自動升級等自動化手段越來越多應用于云運維。這是適應云計算時代的趨勢，但能力越強，責任越大，要謹慎自動化的雪崩和驚群效應，做好灰度/藍綠部署和各種測試。
保持簡單，監控一切
保持簡單，別把事搞的太復雜。除了常見的異常問題報警外，面向業務指標，市場指標和銷售數據，成本等都可以用來做趨勢分析信息。定期的輪詢查看各個趨勢數據的峰值峰谷有助于見微知著。
面向預算的運維
運維團隊通常是最大的花費者，因為預算不足，沒有錢的運維是很難兼顧到日益增長的公司業務規模，除非公司業務已經停滯或不再有爆炸式的增長，面對這樣的挑戰，運維要學會降本增益，開源節流，利用新技術實現能效比的提升。
面向場景的智能運維
各種各樣的負載場景，從高并發處理到視頻轉碼，從高性能并行計算到海量的網絡請求。這些不同的負載場景，對網絡帶寬，各種處理和IO的要求也各不相同。智能運維就是需要深入理解業務，合理配置資源和架構來滿足不同業務場景的需求。
持續集成和發布系統
持續發布包括灰度發布、測試發布、滾動發布、回滾發布等多種場景，并且確保每種場景都應該是可以可控的。
確保任何人都可以被替換
鐵打的營盤流水的兵，人挪活是常態，做好員工的共享文檔管理和知識傳遞和分享，理論上所有人都可以被替換，任何人也不應該成為公司的天花板。
雖說成長是自己的事情，但如果有合適的場域、合適的項目機會、合適的團隊、合適的機制，會讓工程師的成長更快，團隊更有戰斗力，您能否系統的談一下是如何促成運維同學的成長的？
公司一直是積極鼓勵員工的技能自我提高和促進成長：
- 每月開放日：公司內技術委員會會定期舉辦講座，分享前沿研究中的一些收獲，要求有主題，有重點，有應用場景，最好有實例。
- 每周分享會：鼓勵所有開發者定期分享新的技術，談論他們面對的問題，或者任何別的他們正思考的東西，分享的內容會形成文檔和視頻存檔，并根據評分給予獎金和積分激勵。
- 公司懸賞項目：無論是公司還是員工自身都可以發起項目，技術委員會評審通過后，自行組隊完成，根據產出文檔，數據對比，技術分享后獲取相應的項目獎金。申請專利還有相應的專利獎金。
- 培養個人影響力：鼓勵員工通過發表文章或演講的形式，走出去做工程經驗分享、工作心得的梳理，提高個人的影響力，并根據受眾的反饋給予稿費和講師費激勵。
- 訂閱報刊，雜志等紙質書籍，了解最新動態。以部門為單位，配置一定的購書津貼。
又拍云運維團隊內的培養包括：
- 化“天花板為托板”：把自己放在一個培養新人的管理角色，不讓自己成公司瓶頸和員工的天花板，鼓勵新人們去嘗新和處理故障，增加自身的技能和實戰經驗；信任，互助，激勵，他們會持續不斷創造驚喜。
- 制作“自動化工具”：利用自己的經驗抽象業務成程序模型，制作或培訓自動化腳本的編寫，提高團隊的工作效率，讓員工節省精力和時間去學習其它新知識；
- 承擔“高精專”項目：提前準備最新知識的研究和可行性分析，整理成文檔作公開培訓，再交給團隊去深入研究和實施，轉化成生產力，積累一線經驗再反饋完善文檔，良性循環；
- 積極提倡“知識分享”：各種案例和“坑”都會整理成wiki文檔，通過文檔共享，定期分享講座，鼓勵員工撰寫高質量的，可讀性很強的文檔，開口培訓，增加感染力和自信心；
- 鼓勵“參與開源交流”：公司鼓勵員工走出去參與技術交流大會，閉門造車耗時耗力，不如專業的人點撥。也會有購書經費，團建活動經費，茶歇文化；
運維工程師其中一個典型的職業路徑是做管理者，但管理者和資深運維要解決的問題截然不同，對于那些剛剛步入管理崗的資深運維，是否可以分享一些您的經驗？
對于剛步入管理崗的運維來說，我的建議是及時梳理遺留的技術債和人才技能的盤點和培養，先打好基礎，后面才能有更大的空間進步，具體可以參考我的《??運維百家講壇??》的分享。
- 一、 以可配置為榮，以硬編碼為恥
- 二、 以互備為榮，以單點為恥
- 三、 以隨時重啟為榮，以不能遷移為恥
- 四、 以整體交付為榮，以部分交付為恥
- 五、 以無狀態為榮，以有狀態為恥
- 六、以標準化為榮，以特殊化為恥
- 七、以自動化工具為榮，以手動和人肉為恥
- 八、以無人值守為榮，以人工介入為恥
人才上技能樹的盤點，主要是配合人事做好人才九宮格的劃分（如果是開發或運維，把左側的績效換成潛力，績效針對銷售而言），考查的是管理者對員工的全方面的辨析能力，知人善用。
再結合公司的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給我們帶來的是每天都有創新的，好玩的，優秀的開源軟件讓我們保持激情去盡情的折騰和學習，當互聯網興起的機會來臨時，做個運維總監其實也是順理成章的事； 其實，除此之外，我還轉型做過售前，技術支持，跑過市場，經常做演講培訓，所以真正的高手是什么不會學什么，技多不壓身，做個懂業務、會開發的運維工程師。
您覺得運維人員最重要的素養是什么？對新入行的運維人員有哪些寄語？
我認為最重要的能力是表達溝通能力，但不排除運維本身所需的技術儲備、實踐動手能力、編程能力和學習能力。考慮到運維大部分還是一個成本支出的崗位，如何把深奧隱晦的性能及瓶頸指標，用直觀的圖表展示來獲取上層持續的投入是需要技巧的；然后面對你的同事，你的兄弟部門，也需要你的影響力去協調推進工作，如果能夠做到這些，說明你已經具備了領導的才能，這樣以后做什么事都會站在更高的水平，用全局觀的格局去統籌規劃整個項目的目標，人員，工期和資源的合理分配和把握。
