本人75后，在職場摸爬滾打了二十載，初期以主機服務器和數(shù)據(jù)庫起家，后期從事運維工作，現(xiàn)在落足在全國知名的一家連鎖餐飲企業(yè)，擔任運維總監(jiān)的職務，負責DevOps平臺建設工作和企業(yè)內(nèi)ToB和ToC端的容器云運維。從國企到私企，從傳統(tǒng)企業(yè)到互聯(lián)網(wǎng)企業(yè)，再到傳統(tǒng)企業(yè)，我深刻的感覺到技術發(fā)展的速度之快，更新迭代使人幾乎處于茫然的境地，我想結合技術趨勢，對于在當今時代運維人員如何學習發(fā)展，談一下自己的心得。
1、開篇前言
在過去幾十年間，技術發(fā)展的格局，發(fā)生了翻天覆地的變化。
在90年代時，商業(yè)化軟件幾乎成為了技術的全部，IOE成為了當年每個IT人員最求職業(yè)高峰的不二之選。而IOE在那個年代也逐步統(tǒng)治了大部分的IT領域，比如Oracle，原來只是數(shù)據(jù)庫軟件，而后通過不斷的兼并，變成了前后端一體的一站式解決方案提供商。從Java、JavaScript、簡易web開發(fā)工具Oracle Application Express，到中間件weblogic，再到數(shù)據(jù)展現(xiàn)工具Obiee、再到ERP領域的Sieble、peoplesoft，再到數(shù)據(jù)庫的高可用RAC、災備datagurad、復制goldengate，最后索性提供一體機Exadata，Oracle展現(xiàn)其統(tǒng)治IT上下游的雄心和實力。其實，那個時候，對IT人方向是比較明確的，就是學習Oracle，就對了，就和學習會計要考CPA一樣，方向明確，不會迷茫。那時的我也是這么想的，想著Oracle可用學習一輩子，能去Oracle原廠工作，必定可以大展宏圖。
但是這世界唯一不變的就是變化，接下來的日子里IT世界發(fā)生了諸多的變化。首先是，云的興起，AWS橫空出世，Saleforce接著跟上，Oracle忽視了，Oracle CEO Larry開始時認為云無足輕重，因為云就是一堆機器用根網(wǎng)線上網(wǎng)。但事情的發(fā)展遠遠超出了他的意料，云的發(fā)展徹底改變了IT世界，源源不斷的有軟件SaaS化、PaaS化，到后來AWS的Aurora DB等數(shù)據(jù)庫開始侵蝕Oracle的數(shù)據(jù)庫市場份額，雖然這種侵蝕每年大約只有0.3%左右，但明顯的Oracle的市場份額在慢慢下滑。而對于IBM來說，就是它們的服務器、小型機的訂單呈下滑趨勢，云端的IaaS使得大家不用擔心服務器的龐大投資了。
其次是開源軟件的廣泛使用，以google為代表的廠商大肆在github上開放其軟件的開源版本；對可靠性要求不高的客戶，開始選擇開源軟件，而不去購買昂貴的IOE的許可證。于是開源軟件開始從前端到后端開始侵蝕IOE的市場。每一種商業(yè)化軟件，總能找到開源替代品。
再次就是分布式應用，分布式的推廣不符合以Oracle為代表的廠商商業(yè)利益，但歷史的前進是無法阻擋的，當服務器的橫向線性性能擴展比縱向擴展的優(yōu)勢逐漸被認同，Oracle也不得不低頭，在Oracle 12c數(shù)據(jù)庫中推出了sharding分片功能。但是不得不說已經(jīng)晚了，各種開源版的分布式應用已經(jīng)占據(jù)了大部分市場。
出于以上三點，作為技術人的我，工作和學習的軌跡發(fā)生了變化，我從一心鉆研Oracle數(shù)據(jù)庫技術，變成了多點開花，開始了從前端到后端，從應用到數(shù)據(jù)的廣度學習，為了在運維這條路上走的長遠而努力。
2、運維技術之路
其實，憑心而論，運維技術這條路不好走。過去不好走，因為學習的成本高，有過經(jīng)歷的同學一定知道，要不停的考認證，我就考過OCM，當初光考試費就是7000多人民幣。現(xiàn)在的路更不好走，因為開源技術發(fā)展太快了，種類繁多，不知道要學什么，容易陷入“生命有限，所學無限”的尷尬處境。
大量開源的新技術出現(xiàn)，前端出現(xiàn)了VueJS大有取代AngularJS的趨勢，而同時React native出現(xiàn)又大有取代VueJS的趨勢，實現(xiàn)IOS端與Andriod端的統(tǒng)一代碼；中間件家族出現(xiàn)了RabbitMQ、RocketMQ,使得IT架構中除了Weblogic和Websphere之外有了其他的選擇；數(shù)據(jù)庫端除了開源MySQl，還有MongoDB等NoSQL數(shù)據(jù)庫，以及MyCat、shardingJDBC，乃至OceanDB、TiDB等眾多分布式解決方案；數(shù)據(jù)分析領域出現(xiàn)了Kylin來取代Oracle OBIEE，Python語言、Hadoop Mapreduce取代SPSS等分析軟件的趨勢；存儲領域，Ceph和超融合系統(tǒng)的出現(xiàn)，利用高速網(wǎng)絡和ssd盤的優(yōu)勢，將本地盤組合成虛擬存儲，大有取代EMC的昂貴陣列的趨勢。
那么如何走并走好運維工程師這條路呢？Google給我們很好的啟迪，將來的運維工程師，目標是應該進化成SRE工程師，具備諸多技術。下面我將展開闡述我的觀點。
2.1技術選型
好，現(xiàn)在問題來了，面對如此之多的技術，學什么，怎么學，學到什么程度，是擺在我們面前的難題。我這里所提倡的是廣度學習，也就是T字中學習法。
2.1.1深度選型–“T”字之”I”
學習中，必須首先選擇好T字中的那個豎線，因為這是根本，將影響你今后的廣度學習的眾多方面。我主張首選開發(fā)，對于運維而言，就是學習python最為妥當，python被譽為是開發(fā)語言中的萬能膠，因為它從前臺到后頭都可以有用武之地，前端python有自己的Django框架，可以編出湊合的頁面，運維有運維的包體，數(shù)據(jù)分析有數(shù)據(jù)分析的包體，人工智能也能對接tensorflow，幾乎是“萬金油”，日本已經(jīng)把它列入了小學課程，把python學精深了是不會錯的。然后，再把mysql或Oracle選一門選精深，形成Python+Mysql或Python+Oracle的T字“豎杠”。
Python的迭代總的來說還是比較慢的，Python2到Python3雖然變化挺大，不過目前都是Python3為主，Python2已經(jīng)不多見了，很好聚焦。而MySql5.7到MySql8.0大都只是增加了一些新功能，幾乎沒有顛覆性的改動，也比較穩(wěn)定，學深學精，從時間上是可以保證的。
2.1.2廣度選型–“T”字之“—”
記得曾經(jīng)剛進一家公司的大數(shù)據(jù)部門的時候，幾乎把我嚇一跳，為什么呢？因為細排了一下，這個大數(shù)據(jù)部門搞的開源軟件，多達50多種，而整個工程師團隊不過30人，追求新技術本質(zhì)上并沒有錯，但學多難精，而且還有很多的新技術如同曇花，剛開始時耀眼奪目，時間一長沒有了維護了，就逐步退出了歷史舞臺或被取代。大家黃金的學習時間區(qū)區(qū)只有十幾年，如果方向選錯了，不僅時間上是種浪費，對你的IT之路也是一種不小的打擊。
首先，在廣度學習的選擇上必須要遵守“從眾”原則，也就是學的人越多，用的公司越多，越是要加入你的學習列表。那如何知道呢？Github給我們提供了很好的依據(jù)，以開源軟件ceph為例，如圖所示
大家可以看到，目前它的commits數(shù)量高達11.1萬，而Stars有7.8k，也就是點贊的有7800次之多，要知道Github是不會有“水軍”這種職業(yè)存在的（就算有也無人付工資?。赃@個數(shù)字基本上可以反映真實情況。而且4小時前發(fā)生過更新，開發(fā)者更新積極。下面來對比另一個項目。
同樣是分布式存儲的項目，glusterfs的commits數(shù)量和stars數(shù)量就比Ceph少很多，而且更新是在昨天，開發(fā)者更新不太積極。
2.1.3實勢選型–“T”字之整合
當今技術發(fā)展日新月異，我們一定要多看看外面，避免閉門造車，必須根據(jù)外界流行的趨勢不斷調(diào)整自己的方向，將“T”字整合起來一起應用。
對于應用架構而言，開始時候，大家熟悉的是三段架構，前端是應用層，大都是放置tomcat，中間是邏輯層放置jar包為主的app和redis緩存，后端是數(shù)據(jù)庫層。而后是Duddo分布式框架，再然后進化到以SpringCloud、Springboot為主的微服務框架。
對于承載架構而言，開始時候還是服務實體機或vmware虛機，而后Openstack的興起打破了vmware的壟斷，但是Openstack畢竟是個半成品，而且本身發(fā)展也有諸多問題，于是應容器化技術docker、Kubernetes技術異軍突起。
而后的應用架構和承載架構整合起來了，形成了基于容器的微服務架構istio，所有的應用裝載在容器的pod中、pod中又有sidecar邊車來控制東西向流量，構成了服務網(wǎng)格（Service Mesh）。
當所有人認為這已經(jīng)是架構演變的最終形態(tài)時，又出現(xiàn)了Serverless模式，無服務架構，這種服務架構，更為節(jié)省資源，容器在pod在用時才建，不用就銷毀。
對應于如此變革，你不需要如何快的變，但你需要知道外面的技術形勢是如何的，根據(jù)外界的形勢，及時修正自己的學習方向和計劃，學無止境，學習是一輩子的事，無論你的年齡，無論你的位置。
2.2學習方法
在學校學習我們是根據(jù)大綱，按照書本按部就班的來學習。但工作了要學習IT技術，就沒這么“好”的條件了。
2.2.1文檔學習
首先，“好”的書本是不存在的，因為技術變化太快的。記得前兩年，我“立志”學習大數(shù)據(jù)買了一本一年前的hadoop大數(shù)據(jù)的書，不料看了網(wǎng)上的資料都與書中不同，原來書中hadoop版本早已淘汰。
所以，我們要靠最新的資料來學習，對應開源軟件最好的學習資料就是document文檔，而文檔大都是英文的，大家可以借助于翻譯軟件翻閱學習。
2.2.2實踐學習
光說不練總是不對的，所以，建立自己的一個實踐平臺是很有必要的。這里我們可以用vmware或vbox虛擬機平臺，當然如果有條件，也可以用公有云上的資源，總之，搞運維的IT人，必須有環(huán)境進行實操。
每個文檔基本上都是這個軟件的最佳實踐，最好就是把最佳實踐都在自己的虛擬機環(huán)境中運行一遍，形成自己的初步經(jīng)驗。
2.2.3學以致用
有很多時候，學過的的東西，如果不用，過段時間就會忘。所以在工作中的學習是尤為重要的，從事運維工作的IT人應該在平時工作時，努力將所學的東西應用于工作，比如：一個非常routine的工作，你就要想如何通過自己學習的Python把它變得自動化，這就是學以致用。這樣一來有成就感，二來學過的也不容易忘。
2.2.4以教代學
雖然有實驗環(huán)境實踐、工作上也盡量使用，但總有些軟件，我們沒有辦法持續(xù)接觸，那怎么辦呢？我們可以用把所學的東西整理一下放在博客上，放在知乎上，這個有時并不是給別人看，是為了自己的學習，應該總結整理過的東西，是非常有邏輯性的，而有邏輯性的東西印象就深刻。
更進一步，可以嘗試把所學的編制成ppt教材，嘗試對著鏡子講出來，我的經(jīng)驗是，知識講的過程才能發(fā)現(xiàn)你理解上的不足，講過幾遍后，就完全是你自己的東西了。
2.2.5不求甚解
有很多人學習中容易犯的一個毛病就是“期望過高”，他們往往看文檔前立下大志向，但很快發(fā)現(xiàn)有些東西難以理解，就中途放棄了。知識體系的復雜有時是前后關聯(lián)的，文檔并不是學校的課本，不可能循序漸進。所以正確的學習姿勢應該是先通讀，后精讀。遇到不懂的地方，先查百度，查谷歌，盡力理解，實在不行，就要暫時放棄，去讀后面的篇章，等通讀完成后，精讀時，再反過來解決先前不懂的東西。
2.3“懶人”至上
做運維工作，必須有懶人的意識，就是盡量“減少”自己的工作量。當然，我們這里絕對不是鼓勵大家逃避工作，推卸責任；而是鼓勵大家用先進的工具技術，提高工作效率，避免重復無謂的工作。
2.3.1 ITIL流程規(guī)范
沒有規(guī)矩不成方圓，有些公司的運維做的不好，不是因為技術不行，而是沒有好的規(guī)范。這點我是有切身感受的。我經(jīng)歷過一家公司，內(nèi)部的運維崗位基本上是受虐的，每天忙的不可開交，而且還要承接老板安排的即時工作，基本就是隨叫隨到，這樣導致運維力量消耗厲害，運維工作很難開展。
正確的方法是按照ITIL的規(guī)范，將工作和責任分散到不同的部門，一切工作按相對固定的流程辦事，建立發(fā)布流程、變更流程、事件處理流程、問題處理流程等等，這樣才能有章可循。記住把工作安排好，工作量合適，也是一種能力。
2.3.2 DevOps理念和工具
DevOps的目的是將一個項目的發(fā)起、設計、開發(fā)、質(zhì)量測試、安全檢查、部署等流程完全標準化、自動化、流程化，把運維、開發(fā)、項目管理人員緊密配合，無縫銜接，最終達到端到端的應用交付。這是當前運維領域，比較流行的理念。運維人員必須對此了解，認知并接受，把自己從一個純粹的運維，變成運維開發(fā)人員。也就是說，將來的運維人員，并不是天天如同救火隊一樣的，去解決問題；而是去搭建維護一個平臺，來承載項目管理、持續(xù)集成持續(xù)部署、自動化質(zhì)量測試等工作。
3未來運維展望
運維的未來會是如何呢？其實DevOps的出現(xiàn)已經(jīng)給大家一個很好的啟示，未來運維必然是在DevOps的基礎上繼續(xù)走下去。
3.1人才方向–SRE轉(zhuǎn)型
在傳統(tǒng)Ops模式上的主要問題是：過分關注如何解決那些常規(guī)問題、緊急問題，而不是找到根本原因和減少緊急事件的數(shù)量。
SRE是google提出的運維工程師理念，是一套方法論體系。全稱叫Site Reliability Engineer(網(wǎng)站可靠性工程師)。一個SRE工程師基本上需要掌握很多知識：算法，數(shù)據(jù)結構，編程能力，網(wǎng)絡編程，分布式系統(tǒng)，可擴展架構，故障排除，這些也就是我在上面讓大家技術選型和學習之路。
SRE工程師，要做到以下四點：
3.1.1擁抱風險
把風險識別出來，用SLI/SLO加以評估、度量、量化出來，最終達到消除風險的目的。
3.1.2質(zhì)量目標
一般可能認為沒有故障就是正常，萬事大吉了。SRE要求明確定義SLI、SLO，定量分析某項服務的質(zhì)量，而監(jiān)控系統(tǒng)是SRE團隊監(jiān)控服務質(zhì)量和可用性的一個主要手段。通過設立這樣的指標，可量化質(zhì)量，使得我們有權力PK業(yè)務研發(fā)，也能跟老板對話，取得更大的話語權。
3.1.3減少瑣事
SRE理念里講究要花50%左右的時間在工程研發(fā)上，剩余50%的時間用來做一些如資源準備、變更、部署的常規(guī)運維，以及查看和處理監(jiān)控、應急事務處理、事后總結等應急處理工作。如果一個屏幕上十幾個窗口，各種刷屏，但卻不徹底解決問題，這時就需要用更好的方式——自動化、系統(tǒng)化、工具化的方式,甚至是自治的方式去處理這些“瑣事”。
這里對傳統(tǒng)運維的思維也有一些挑戰(zhàn)，因為我們?nèi)粘Ｗ龅米疃嗟墓ぷ髟赟RE中是被定義為價值不高的瑣事，運維不是操作，“運維”是個工作內(nèi)容，人工或是軟件都可以做。
在谷歌里，會要求SRE有能力進行自動化工具研發(fā)，對各種技術進行研究，用自動化軟件完成運維工作，并通過軟件來制定、管理合理SLI/SLO。
3.1.4工程研發(fā)
我個人理解的工程研發(fā)工作包括三個方面：
a、推進產(chǎn)品研發(fā)改進架構，經(jīng)常和研發(fā)探討架構、集群、性能問題。
b、引入新的運維技術，基礎組件要hold住，比如TSDB、Bosun、Consul、Zipkin等。
c、自研工程技術、平臺、工具、系統(tǒng)、基礎組件、框架。
3.2運維方向–AIOps之路
AIOps自從Gartner于2016年提出至今已有一段時間,，一直是運維的方向。在頂級互聯(lián)網(wǎng)及電信企業(yè)，已有較多落地，主要包括：精準智能告警、智能異常檢測、智能趨勢預測、智能化故障處理。這里拿智能化故障處理的兩個功能舉例。
3.2.1自愈功能
運維體系會和人工智能相結合，利用深度學習算法，讓這個系統(tǒng)架構有“智慧”，實現(xiàn)自愈功能。比如現(xiàn)在的百度，如何服務器中有幾臺宕機了，是不用立馬去更好換的，系統(tǒng)會自動判斷非正常的服務器，然后利用算法去規(guī)避這些服務器，然后，嘗試通過重啟和重新安裝系統(tǒng)的方法，自動嘗試去恢復這些服務器，恢復后，又能自動加入集群中。
3.2.2自動工單
人工智能能夠根據(jù)故障的特點，來自動填寫工單，自動發(fā)送到相關的部門去處理解決。這個在電信等大企業(yè)中已經(jīng)有相關應用。
4、結束語
運維工程師之路，其實是知易行難的，而且通常都是幕后的，其中辛酸難以為人所表，通常都是有“背鍋俠”之稱，并且，學的東西博而雜，難以統(tǒng)一集中。所以，我根據(jù)自身的經(jīng)歷提出幾點考量，提供給大家借鑒，幫助大家努力把自己塑造成為一名合格的、適合未來需要的運維工程師。
