雲計算和AI時代，運維應該如何做好轉型?

今天我們來聊一聊，在雲計算和AI時代，運維應該如何做好轉型?今天的内容可以說是我們前面運維組織架構和協作模式轉型的姊妹篇。針對運維轉型這個話題，談談我的思考和建議。

我們先來看業界的三個典型案例，一個來自國外，一個來自國内，最後一個是我自己團隊的案例，都非常具有代表性。

先看國外Netfix的模式。

Netfix從一開始就強調開發人員進行自助化運維。我們第一篇文章中就介紹到，Netfix内部的運維工作全部都由開發人員完成，平台也由開發自己完成，隻保留極少的Core SRE角 色專門響應和處理嚴重等級的故障。類似的還有亞馬遜，無論是其電商業務，還是AWS公有雲服務，全部都由開發搞定。

這樣的團隊因為其技術前瞻性，微服務以及分布式這樣的技術架構早已落地，再加上其超強的技術能力，是以可以從一開始就這樣來做。

再看國内阿裡的模式。

阿裡技術團隊在2016年左右，也開始進行“去PE”的組織架構調整，原來需要PE完成的運維工作，全部由開發承擔。原來的PE要麼轉崗去做工具平台開發，要麼作為運維專家做産品 規劃和設計，還有一部分無法适應調整的PE就隻能離開了。之前在業務穩定性保障過程中起到核心作用的PE，随着各類工具平台的逐漸完善，在高度自動化之後，最終也隻能面臨職 業和技能上的轉型。

這種模式，與Netfix正好相反，也就是一開始技術能力無法滿足要求的時候，能靠人就先靠人，然後過程中不斷完善各類自動化平台。

最後，再說說我自己的團隊，發展過程中的模式。

我大緻回顧了一下，發現從去年年初到目前，将近兩年的時間裡，我自己的團隊也沒有招聘新的應用運維人員了。并不是沒有合适的人，我總結了一下主要有兩個原因。

第一個原因，随着自動化逐漸完善，效率不斷提升，單個PE能夠支援的業務變得越來越多;同時，很多事情開發都可以自助完成。

第二個原因，我有意識地招聘具備開發能力的人員，他們入職後一方面參與各類平台的開發，另一方面還要定期輪崗做一些運維工作。後來我發現，隻要有效進行引導，同時具備運 維和開發能力是不成問題的。

是以，結果就是，應用運維的崗位需求已經沒有這麼強烈了。從趨勢上看，跟阿裡的發展過程非常相似。不過這個過程，我從來沒有刻意地設計過，基本算是順其自然。

從上面的這幾個案例來看，無論哪種情況，就運維來說，随着日常重複的人工操作被逐漸自動化之後，如果還是固守原有的工作模式和思路，能做的事情、能夠提供的價值，一定會越來越少。終究有一天，我們會面臨和阿裡PE同樣的轉型問題，而且這個轉型是在可預見的短期内就會到來。

既然預見到了趨勢，那下面我們就來談談應該如何面對。

應用運維的轉型

如果隻允許給一條建議的話，我給出的建議就是:學會寫代碼。

我們早期的運維崗位，基本上都不會對代碼能力有很強的要求。是以對這個崗位上的同學來說，這一點就成了技能上最大的短闆，也成了後續職業發展的瓶頸限制。

但是，運維行業發展到現在，無論是從趨勢上看，還是從我們現在所經曆的實際現狀來看，單純靠人力維護的投入越來越無效。

是以，無論是我們做運維轉型也好，還是做其它技術轉型也好，具備代碼開發能力，已經成為一項必備技能。

這裡多說一點，我們大多數做運維的同學不具備代碼開發能力，并不是自身的能力問題。很多情況下都是因為不夠自信，對寫代碼心存畏懼，擔心自己寫不好，是以一開始就把自己給限制住了。如果是這樣，我給的建議再多也沒用，關鍵還是要靠自己先邁出第一步。

現在我自己的團隊中，有很多同僚做了多年運維工作後，因為樂于嘗試和挑戰，很快就可以獨立程式設計，而且因為自身有很多一線運維經曆和經驗，可以說即懂業務又懂開發，反而比單純做平台和工具的運維開發更有競争力。

下面是一些具體的建議。

1. 代碼開發上

我的建議是可以從Python、PHP或Go這些上手比較簡單的語言開始。這裡不是寫腳本，一定要能夠實作完整的業務功能或流程。一開始嘗試去做一些簡單的工具，實作 一些簡單的功能，再往後可以通過一些複雜的業務場景深入下去。一旦場景的複雜度高了，就會涉及到更高的開發技能，比如并發、緩存、消息甚至是服務化架構等等。關鍵是敢 于邁出第一步，然後逐漸轉變。相信我，真的沒有那麼困難，我身邊有太多的優秀轉型案例，都是這麼過來的。

2. 提升産品意識

這裡不是要求運維同僚都成為優秀的産品經理，或者具備很強的産品設計能力，而是一定要有産品意識，隻要有這麼一點點小轉變就會帶來大不同。我簡單說明一 下，我們很多運維同僚，甚至是資深級别的，往往還是習慣于處在最末端，前面有什麼事情找到我，我就處理什麼事情，屬于被動響應類型的。但是，如果你有産品意識，能夠将 你所做的事情整理彙總起來，然後做一下流程上的串聯，再把流程中每個環節步驟的功能進行較長的描述，同時在梳理的過程中，将一些不合理、不規範的地方進行标準化約定，也 就是我們前面說的标準化過程，然後輸出的内容就是平台開發所需要的需求分析和産品PRD的雛形了。如果能将所做的事情從單純的運維操作轉化到這個次元，那我們呈現的價值 就完全不一樣了。

3. 提升技術營運意識

這一點跟上面類似，簡單來說，就是如何根據需求，把承載了标準化和規範體系的工具平台真正落地應用起來。同時，在落地的過程中，通過問題收集和一定 的資料分析，然後再回到産品設計和需求實作流程中進行改進，形成一個良性的閉環。

在阿裡的PE轉型過程中，有一部分轉型去做效能工具研發，有一部分經驗豐富的資深運維就轉型去做了技術産品和技術營運這樣的運維專家角色。對于開發人員已經可以自助完成的 部分一線運維工作，運維專家還會在這個過程中對開發做一些賦能。

是以，對于目前運維崗位上的同僚來說，有這樣一個先天優勢來承擔這樣的職責，可以參考阿裡PE轉型的經驗，根據自己的優勢特點提前做好方向規劃。

雲計算和AI帶給我們的挑戰

機遇與挑戰并存，上面我們更多地講了機遇，但是與此同時我們也要看到挑戰，甚至是危機。

而最大的挑戰和危機往往都不是來自内部，當我們還在糾結如何不被開發替代的時候，外面的技術環境已經發生了很大的變化，而這種變化帶來的将是颠覆性的改變。

有兩個最大的外部因素，一個是雲計算，一個是火熱的 AI，我們分别來看。

首先，雲計算發展到今天，已經不是我們想象中的隻能提供IaaS服務的雲平台了，目前各大公有雲上的PaaS産品體系也已經非常完善。我們前面講的各類分布式中間件産品都有覆 蓋，而且這些産品，還都是各大公有雲平台公司在自有業務上錘煉出來的非常優秀的産品。

簡單一句話，現在我們去做一個業務，基于這些基礎服務，完全無需自研純技術産品，隻要專注業務邏輯開發即可。我了解到國内某新興的O2O，每日超過千萬筆的訂單量，除業務 代碼外，其它基礎層面的服務就完全依賴于某大型公有雲的IaaS、PaaS以及周邊的各類服務體系。

這種情況下，非但不再需要大量的如SA、網絡工程師、DBA以及應用運維這些崗位，就連技術門檻較高的分布式中間件研發崗位也會大量縮減，是以這個挑戰和危機就會非常大了。

這種情況下，我們應該如何面對?其實，我在前面的文章中已經給出答案，大家可以先回顧一下，然後再往下看。

這裡的答案就是，從價值呈現的角度來思考我們可以做什麼。至于做什麼我前面也提到過，比如持續傳遞以及穩定性保障體系。當然根據業務的不同特點，遠不止這些内容。這些都是 跟業務自身層面相結合的，與平台無關。與業務結合，就會有個性和獨立的地方。如何根據自己的業務特點，找到跟業務相切合的價值呈現點，是我們每一個人應該去思考和探讨的。隻有 找到這些點，我們做的事情才會有價值和意義，我們所在的崗位才會有價值和意義。

然後，再談談AI。這裡說明一下，我們現在談到的AI，其實大部分情況是在談論AI的一種實作方式，就是機器學習算法。關于這一點我在InfoQ分享過一篇文章，我把連結附在文 末，如果你感興趣可以讀一讀。

AI和Ops的結合，更多還是場景驅動的。就是我們要處理的資料量越來越多，面對的場景越來越複雜，而且會大大超出我們人力的認知範疇。比如BAT這樣的公司，幾十萬台伺服器 的規模，出現一個問題，我怎麼能夠快速發現，快速定位，并最終快速恢複?如果是幾百甚至幾千台伺服器，靠人還是可以搞定的，但是幾十萬台，靠人就不可能了。

是以，這個時候，就需要借助技術的能力，而機器學習算法又正好可以滿足我們的訴求。

這裡想特别提一點，機器學習算法的應用，是離不開場景和業務特點的，也就是說怎麼用還是離不開人，離不開對業務和場景熟悉的人。從我現在了解到的情況來看，很多公司和團隊，針對每一個場景都需要投入很大的精力去對某個特定曲線和算法進行調參優化，以確定它們的準确性，也還沒有神乎其神地達到完全不靠人的無監督學習。這裡面并不是說算法本身不具備這個能力，而是現實場景太複雜，我們不能用簡單固化的算法來應對。

說到這裡，我想我們應該可以抓住這裡面的關鍵點了，就是懂線上運維實際情況的人做這個事情，會更加适合。當然，這是極其理想的狀态，因為機器學習算法的應用還是存在比較高的 門檻，不僅僅是技術層面，還要一定的數學基礎，需要對大資料産品有所了解等等，是個相對複雜的過程。

是以，這裡我的建議就是要多去了解，因為未來随着技術、資料和計算能力的提升，AI是一個必然的趨勢。如果一點都不了解，極有可能就會被卡在門檻外面，這就不是轉型的問題了。

總結

上面我結合一些運維發展到目前的現狀以及呈現出的趨勢，做了一些分析和建議。最後我們總結一下。

新時代下，機遇和挑戰并存，我們确實面臨着崗位和技能的轉型。我給出的建議是:學會寫代碼，培養産品意識，提升技術營運意識。