什麼是運維開發?

兩者有什麼聯繫?側重點是運維還是開發?


我看了標籤打了 DevOps 所以我按照 DevOps 來回答這個問題。

目前看到的6個回答只有一個人提到 DevOps 是一種工作方式、是一種思想,其他幾個往 DevOps 方向上靠攏的回答都不太好。

初看 DevOps 確實很難理解,我也曾糾結在 DevOps 到底是讓開發干運維的活還是讓運維干開發的活這個問題上很久。

同時我還有一個疑問是 「到底用了什麼才是 DevOps」。但是這兩種提問方式也都是錯的。

首先,我們要將 DevOps 和 運維自身的 開發化進程給區分開來,在幾年前各種如 Ansibel,Puppet 之類的工具,將運維人員從反覆編寫腳本中解放了出來,大大提高了部署效率。但是 DevOps 並不是要說這個事情。

當你搜索 「什麼是 DevOps」這個問題的時候,你已經能看到很多文章,比如 什麼是(不是)DevOps,我們如何實現DevOps? 。其實,他們已經很好的解釋了什麼是 DevOps:

DevOps是一種文化轉變,或者說是一個鼓勵更好地交流和協作(即團隊合作)以便於更快地構建可靠性更高、質量更好的軟體的運動。

只是太抽象了,不太好理解。

我們還是從 Dev 和 Ops 開始說起。DevOps 最初應該是遇到了一個(些)很懶的Dev,他們懶得和 Ops 說話、打交道。但是活得幹下去,怎麼辦呢?想辦法盡量少說話吧。

在談到 DevOps 的時候經常會談到 Docker,Docker 很好的滿足了 Dev 不想說話的這個想法,用了 Docker 以後,它不用再告訴Ops,這個程序部署的時候都需要依賴什麼庫,如何啟動,需要什麼參數。他們甚至可以忽略 Ops 最看重的「發行版本」,你裝了 CentOS?沒關係我可以隨心所欲的用 Ubuntu,Debian 的包等等。

後來還有了 Kubernetes,這下好,Dev 只要學習一下 yaml 的語法,甚至可以做到連部署的細節都可以自己控制了。

我要用 S3,我自己 mount 一個 volume 好了。

初一看,似乎就是 Dev 做了 Ops 的工作,甚至很多地方都這麼解釋。但是其實從我目前看來,工作量並沒有明顯的減少。在上面說的這些內容中,確實一部分的工作從 Ops 轉移到了 Dev 那裡。但是 Kubernetes 誰來做?Jenkins 誰來做?[CI] , Registry 誰來做?無論誰來做,工作量還是在那裡。

但這並不重要的,重要的是我們通過了一系列的工具、方法、標準將迭代次數提高了。我們減少了(優化了) 兩個人群之間的溝通,從而提高了迭代。曾經一天只能發版2次,現在可以 20次 甚至更多。

所以 DevOps 就延伸開了,他的含義是在軟體項目開發、測試、發版、部署、監控、日誌分析等等等等的銜接環節中,更好的優化,從而減少溝通,提高效率,提高迭代次數。

很多地方都貼出這樣一張圖:

請忽略 中間 大大的 Dev 和 Ops 這兩個單詞,嚴格的說這裡面的工作量遠遠超過 Dev 和 Ops 的範疇 。

這張圖要標識的,就是在各個部分 中間是需要銜接的、是需要大量溝通的,每一個部分都很重要。

而 DevOps 的思想就是通過各種方式將銜接的部分儘可能的提高效率,加快速度。


上帝說 要有光 於是就有了運維開發

老闆說 我們要提高效率 於是就有了運維開發 可 事實上並不一定是那樣

所以 運維開發現階段還是完成老闆的需求為主


側重點: 開發。和其他開發一樣,只不過大家面向的業務不一樣。

聯繫: 運維開發是為運維人員提供運維自動化工具、平台支撐。 避免運維人員浪費大量時間重複做一件事情、儘可能降低人為故障、使運維人員更加關注業務本身和系統可用性。

具體如下:

1. 降低運維工作量,讓運維更聚焦業務。 運維工作中有很多重複性工作,比如日常系統巡檢、應用發布等,這些工作十分浪費運維人員時間,但是又不得不做。比如我司運維,每天發布幾十次,運維疲於跟進發布需求,發布多的時候,一天什麼事都做不了,浪費人力,久而久之,運維人員本身也會厭煩。而其中很大一部分工作都是按照既定流程執行的,對於這些任務,運維開發就需要將其抽象化、工程化, 切實解決運維痛點,同一件事需要手動3次以上的,都應該將其平台化。

2. 線上系統可用性。運維開發除了通過自研平台降低運維工作量以外, 還需要考慮到線上業務可用性,如開發數據校驗系統、數據同步系統、業務故障調度系統等,這些系統都是為了保證線上業務持續、穩定運行。

3. 此外,運維開發還需要整體考慮運維平台如何與整個運維繫統對接。運維繫統繁雜,又各種監控系統、運維工具。運維開發需要考慮如何將各類運維繫統和自動化運維平台有機結合。如CMDB、監控系統、發布系統、任務調度系統等如何很好的組織在一起,而不是各自為政。如各自為政,每個平台維護都需要人力,十分浪費。

以上是個人工作的一些體驗。


謝邀,我說重點在測試會不會不太好....好吧其實我也不懂的,我做的事情只是儘可能提高自動化和減少人工干預。然後從配置管理到部署、運維、測試都要用使用工具或腳本統一起來。

其實我只是在做軟體生命周期的各種自動化、持續集成外加各種環境管理等。主要就是開發工具或腳本去做這些事情或讓開發組使用我們開發的東西去做這些事情。

我還沒接觸devops的所謂核心,雖然我不知道核心是什麼。我聽貌似很懂的人說,會有各種什麼人工智慧,什麼機器學習,什麼原子編譯,什麼大數據。我到目前為止還只真正接觸了雲計算和環境管理、數據監控與分析、配置管理與持續集成、自動化測試;高大上的那些一概不懂。


人管代碼,代碼管機器,管代碼的那個人就稱為運維開發


個人從事運維(非產品)工作近兩年,現已棄坑,不從事運維方向的工作。

不玩概念,就工作體驗而言,業務系統運維開發,無非是招運維不好招,弄出來的幌子罷了,這裡針對小企業以及部分中大公司運維崗,尤其外包崗。而運維本身,呵呵,打雜一個。但凡有職位有運維兩字,總之技術方面,想做舉步維艱,怎麼說呢,崗位就已經定義了,想改變,哈哈,有那精力還是準備換新工作吧,不信可以試試,也沒啥大壞處,經驗也有,但是不值。

總之,運維大水筆,入行窮三年。運維類工作也不是一無是處,當你在一個公司待的越久,確實越老越吃香,因為接觸面大,公司情況最為熟悉,可以摸魚,工資待遇可能不漲,但是會越來越清閑,公司也會重視,這對本地人混日子確是個福音。如果你想快速發展個人技能,那麼珍愛時間,遠離運維。

說句悲涼話,對公司而言,運維做最好的境界就是兔死狗烹。運維開發,呵呵,各位自行腦補


用開發的方式完成人肉運維的工作


devops是一種工作思維,而不是特定的工作流程。


重點在開發,是指通過開發維護相關係統工具等幫助運維實現運維工作的自動化


推薦閱讀:

請問大家都使用什麼方案進行生產環境的代碼發布?
如何看待<linux就該就該就該這麼學>作者在知乎推廣行為?
運維如何入門?
軟體測試,還是運維工程師?

TAG:軟體開發 | 運維 | DevOps |