「DevOps」閒聊我心中的運維開發

時間 2019-11-16

標籤 devops 閒聊心中開發简体版

原文原文鏈接

前言

在我入職上家公司的運維部以前，我因此爲的運維工程師只是修修電腦，拉拉網線，布布機器。前端

諸不知，運維所涉及的知識面、專業點很是廣，對從業人員素質也要求很是高，運維工做在大型互聯網公司的重要性不比業務開發差。且分類繁多：vue

桌面運維工程師
業務運維工程師
DBA工程師
配置工程師
運維開發工程師
以及其它....

本來準備寫篇前端眼中的運維開發，恰巧前組長寫了兩篇結合自身六七年開發經驗寫的體會。用他的文章來闡述再合適不過了。如下來自其投稿以及穿插一些知識普及。

1. `DevOps`：打破協做壁壘

來自維基百科程序員

DevOps（ Development和 Operations的組合詞）是一種重視「軟件開發人員（ Dev）」和「IT運維技術人員（ Ops）」之間溝通合做的文化、運動或慣例。

透過自動化「軟件交付」和「架構變動」的流程，來使得構建、測試、發佈軟件可以更加地快捷、頻繁和可靠。面試

傳統的軟件組織將開發、IT運營和質量保障設爲各自分離的部門，在這種環境下如何採用新的開發方法（例如敏捷軟件開發），是一個重要的課題。vue-cli

按照從前的工做方式，開發和部署，不須要IT支持或者QA深刻的跨部門的支持；後端

而如今卻須要極其緊密的多部門協做。而DevOps考慮的還不止是軟件部署，它是一套針對這幾個部門間溝通與協做問題的流程和方法。設計模式

具體來講，就是在 軟件交付和部署過程當中提升溝通與協做的效率，旨在更快、更可靠的的發佈更高質量的產品。架構

2. 運維開發的價值

從崗位職責來看：運維開發要作的工做是：運維

經過開發技能幫助運維實現運維工做的自動化。說白了就是「輔助」，或者說是運維的臂膀，須要把運維中遇到的問題提供平臺查詢，或者把一些常見的重複操做給抽象出來作成工具，減小運維的人工介入。

運維服務伴隨並支撐着業務發展的整個生命週期。工具

而DevOps將運維服務的執行方式升級爲更加軟件工程化的手段，減小人肉操做，DevOps 強調自動化、拉動式來提升團隊交付效率與質量。

而傳統的運維須要謀求技術轉型，從原來只關注操做系統層面的技術已經不夠了，還要增長對程序代碼的性能調優、持續交付、容器化等軟件基礎架構方面的技能提高，也須要持續關注整個業務、應用、服務的生命週期管理。

簡單來講，就是把過去傳統的黑盒運維的思惟方式拋棄，進入白盒運維的時代，咱們必須更加深刻代碼、深刻業務運營，讓整個線上服務運行於更優質高效的狀態。

3. 運維開發是什麼？

要建設運維自動化或者實踐 DevOps 離不開運維開發工程師的參與，但要怎樣才能更好地發揮運維開發的做用呢？

我曾做爲運維開發經理的角色和各類類型的運維開發一塊兒協做過，團隊中有原本就作運維開發的，也有原本作其餘業務（電商、平臺）的開發轉來協助運維團隊的，還有本來是作業務運維後來轉型作運維開發的。

和他們協做一段日子後，整體感受以下：

運維開發首先是一個程序員，不是運維工程師。

一個好的運維開發須要具有「運維理解」+「開發能力」：

對「開發能力」的技術要求低於其餘業務形態（如遊戲、電商、搜索等）。
對運維業務的理解難度會低於電商、遊戲等業務形態，即對「運維理解」的要求不高。
對運維相關技術棧的掌握程度要求高，如Python/PHP/Go/Shell、 Linux、Git、Nginx、Zabbix、Docker、K8S等。

綜上所述，運維開發是一個深度不算太深的職業分支，而如今之因此對運維開發需求量熱起來了，主要因爲老一輩的資深運維廣泛研發能力有限，而這是有歷史緣由的。等到業界提出 DevOps的時候，他們每每已經專一於團隊管理、容量規劃、架構調優、運維服務質量等高級範疇，因此基本不太可能抽出大塊的時間來從新學習編碼並開發自動化系統。

因此，當咱們有自動化系統的建設需求時，須要更專業的程序員來協助。但通常的非專職運維開發的程序員作出來的系統對於運維來講每每不太好使，這時候有部分年輕的運維工程師升級了研發技能，轉型運維開發，把好使的運維繫統作出來了，贏得了運維團隊的好評，你們都爲「運維開發」點贊。

因此，你們將「好使的運維繫統」和「運維開發」等價起來，覺得咱們只要招來一個運維開發，那麼一套完美的運維平臺就能自動誕生出來，這是個很大的誤區。

4. 打造「好使的`DevOps`系統」

其實「好使的DevOps系統」真正等價於「運維理解」+「開發能力」，這兩種能力也是能夠分離的，不必定要強加在運維開發工程師一我的的身上。

相似其餘業務形態的開發過程，須要產品經理和程序員兩種角色分離，企業也不會說要招聘既會寫代碼、又會出需求的程序員。

因此，當運維能把運維自動化的需求細緻地文檔化下來，把自動化系統的設計、架構等關鍵環節確立下來，這就是最好的「運維理解」。這時把這份靠譜、好使、細緻的需求文檔交給具有強「開發能力」的程序員，最終就能夠獲得「好使的運維繫統」。

固然，通常企業不會專門爲運維開發配備「產品經理」，因此運維開發想要再往高級發展的話，也能夠替代運維出需求，升級爲運維產品經理，以程序員的思惟角度來解決運維服務的工程效率和質量問題，我認爲這也是相似 Google 所提倡的 SRE 文化。

4.1 `DevOps`平臺

編者補充描述

光說不練假把戲，編者在上家公司的主職就是將DevOps操做界面化。其中的核心模塊：應用部署發佈監控

圖爲DevOps應用部署發佈監控界面圖

咱們組在作上圖的DevOps系統時，面臨的狀況是：

無產品、無設計、需求也是靠業務運維和開發們的口頭描述。

其中的核心功能：應用部署界面，在參考其它同類產品後，發現都不適合業務場景，要麼功能太分散，要麼就僅是流程控制。因而前端功能裏，咱們作了這些：

區分不一樣環境下的包，實現有序管理。
應用的狀態能夠經過界面作啓停、查看配置等任務。
Jenkins服務操做可經過界面完成，簡化配置工程師的工做。
業務運維與開發團隊的平常發包工做界面化

此時一個優秀的運維開發需具有如下技能：產品規劃、產品設計、面向對象、需求模型、領域模型、設計模型、設計原則、設計模式、產品工具和文檔能力等。

因此，當運維需求被理解、分析得足夠透徹，以及運維開發得到了「產品經理」能力後，運維開發就是一種普通的開發分支，按需求文檔編碼便可。

5. 優秀的運維開發

從事DevOps平臺開發相關工做已有六七年了，自身經歷總結，以爲一個優秀的運維開發工程師應當具有如下能力和素質。

1. 提升運維意識。

從下到上，從上到下的工做都要作好，對上運維工做的價值和含金量能夠獲得承認，對下咱們的工做可以提升效率解放運維。

運維意識是很重要，並非你技術很牛，學的技術不少很熟，就不表明你不須要運維意識。

其實領導很看重運維意識的，例若有沒有作好備份，權限分配問題，平臺測試狀況，故障響應時間等，這些都是意識，而不是你學了不少技術自認大牛了，平臺發現故障你又沒什麼大不子，覺得很簡單的問題喜歡處理就處理，不須要向其它部門反饋等，領導不是看你的技術如何，而是看你的運維意識如何，你沒運維意識，技術再牛也沒用，只會讓其它部門的人跟你不協調。

2. 瞭解業務場景

DevOps平臺最終服務於運維部和開發測試部同事，所以只有熟悉瞭解了每一項業務的運維場景，才能更好去設計功能與代碼開發，熟悉業務場景才能方方面面考慮周全，開發出來的代碼才能知足各種場景應用。

3. 拒絕重複犯錯

人不免會犯錯，這是沒法避免的，咱們應當根據已有的犯錯經驗，總結犯錯的緣由，以及如何避免同類狀況再次發生，甚至能夠把一些典型的錯誤在團隊中分享，把一我的的錯誤獲得的經驗傳播於整個團隊。

4. 凡事有備份，可回退

運維工做中常常有一些發佈，遷移，備份等複雜操做，所以，在研發DevOPs平臺的時候，要作好全面的操做計劃，思考每一步可能的回退與備份。

5. 平臺操做盡可能簡化

DevOps平臺目的就是爲了可以提升運維的工做效率，解放運維，所以在設計與開發的時候，應當保持操做簡單，不要讓事情變得太複雜，能點一下到位的，儘可能不要讓人點五六下才能完成操做。

6. 注重優化用戶體驗

DevOps開發是一個迭代的過程，雖然咱們常說以功能開發爲主，可是用戶體驗也同等重要，試想一下，縱使你開發的功能衆多，若是體驗不友好，用戶便失去了再次使用的慾望，若是用戶拒絕，抵觸使用平臺，作再多功能也是失敗，最終平臺推廣失敗。所以，在研發的過程當中，咱們應當深刻體驗本身開發的產品，把本身當成用戶去體驗平臺操做。儘量的去優化用戶體驗。這是一個優秀的運維開發工程師必須要懂的。

在設計與開發的過程當中常常會碰到複雜，繁瑣的場景，這個時候咱們很容易失去耐心，咱們要時刻提醒本身，必須嚴格履行本身的工做職責，端正本身的工做態度，作一件事，要麼不作，既然作了就要作好：當你想要放棄的時候,想一想當初爲何要開始。