現在所謂的DevOps跟從前定義的運維工程師在具體工作職責上有什麼本質的區別？

01-27

DevOps首先是Dev喊出來的，其初始目的是為了在持續集成敏捷開發這一塊融合進來op工作。說更簡單一點，dev希望更快上線，所以自己搞工具，搞標準化。

當然目前DevOps已經變成廣義的了，只要是寫代碼的op，都說自己devops。包括單絕不限於：上線，測試，監控，配管，優化，可視化……

眾所周知，自古代以來: 一切本質的東西, 都是通俗的、都是直白的。

今天這一帖是哥系列回答中的第一帖。哥準備優惠大酬賓。

盡量認真扯扯。這次先不拿技術名詞來忽悠你。

--------- 黃金分隔線: 1.0 ----------

首先, 什麼是運維工程師? 什麼，你說你不清楚？你去問你運維的同事或朋友呀。

一般他們會告訴你很悲催。經常要上夜班。時不時要忙得打架。心理壓力不小。最重要的工資還不算高。在老闆眼裡呢？就是天天喊著要買機器，裝機器，盯監控。就聽他們喊忙，也不知道忙出啥名堂來了。搞了這麼久了，系統還是老掛。

一句話，有點low吧。

那DevOps呢？聽起來好牛, 啥都能做。無數的技術、工具和理念。大家都在談它, 時髦, fasion。可是朋友, fasion這種東西，可大可小。各有各的喜好的喲。所以，很難說什麼是DevOps。

我們姑且說DevOps是一種思潮吧。而且在我看來, DevOps是一種過渡性的思潮。是的，它現在已經是一個工種，一個職業了。可是。。。

DevOps作為這種職業，它的壽命將是短暫的。（童鞋們，注意啦。這個是考點。）

DevOps思潮的背後推手是哪些邪惡勢力呢？

1. 矽谷的一堆初創公司。

2. Open source的一堆技術狂人。

3. 花了很多冤枉錢，但是還是不放心的CEO, CTO, CIO們。

其中, group1初創公司是最大的推手。

一般軟體系統在製造過程中, 都有三個很重要的環節: 寫代碼，上線和維護。（不要和我談需求分析和商務。這些我不懂）

初創的公司, 一般缺錢，但是呢一般都有幾個技術狂人。老的模式, 上線很麻煩。一堆腳本，一堆人肉操作。而且老出問題。上線後，時不時會出問題，誰都沒有底。更重要的，由於信息不對稱和目標衝突，開發和運維的人員溝通起來還很累，還經常打架。兩邊都是寶，兩邊都要哄。

技術狂人，之所以叫技術狂人。突出一個就是藝高人膽大的特點。而且吼了這麼多年的fullstack，多少還是有些進步的。

終於有一天，有一個技術狂人，老張，忍不下去了。他發出了劃時代的一聲：我來！

而老闆老王（是的，就是隔壁家的那個老王），一聽，心中一陣暗喆。這樣可以少招好幾個人啵，能省不少錢，能省不少事喲。

然後，老煉的老王輕輕拍著老張的肩膀，真誠地問道：老張呀，你確定嗎？我不太懂，不過，看起來很難的樣子呀。一般人搞不定。你能行嗎？

老張，是個老實人。是的，老張，是個老實的人。老張，是個老實人。

在無處次的掙扎和加班中。老張終於做成了。

拿一份工作，幹完三份活。是的，這就是DevOps的標誌性成果。

看到沒，DevOps的最初原動力是：技術狂人和弱雞們溝通太累，一咬牙就自己來。老闆樂得順水推舟，省掉人力成本。

--------- 黃金分隔線 1.1 ----------

初期的DevOps, 主要集中在兩點: 1. 怎麼快速上線，即部署自動化。2. 出問題了，怎麼第一時間知道。即細粒度監控。

慢慢地牛人們找到了更多的規律，更多的經驗。發現很多工作，可以交給機器去做。自己不用為此加很多班，也能把那些事情處理得很好。

機器顯然比人靠譜。運行更快，一般情況下，請的病假和產假也會少一些。

所以越來越多的公司走這種模式。你可以說是精益創業, 也可以說是全棧創業。個人感覺，本質上是一個機器吃人的故事。但是顯然，這是一個時代的進步。

人，不應該老做重複的事情。應該做需要動腦子的事情。

--------- 黃金分隔線 1.2 ----------

DevOps牛刀小試後，效果很理想。所以, 牛人們想，除了之前的兩個環節，整個軟體開發的全流程有什麼我們能優化的呢？也即sdlc(Systems development life cycle)。

這個時候就是百花齊發，或者說群魔亂舞的時候了。

（很多新人的困惑基本集中在這裡。太多東西要學了。那有什麼建議嗎？我是有的。下次有機會了，我再展開說）

能不能省掉QA呢？所以automated tests就火了起來。能不能減緩一些集成測試的痛苦呢？所以CI/CD就火起來了。能不能更快，更好的使用雲服務呢？所以AWS, 阿里雲就火起來了。

這些都是DevOps嗎？不好講。

很多東西一早就有了。selenium自動化出來了多少年了？在7年前, 日本友人已經推出了Hudson/Jenkins。但是呢，技術強人啥都懂。以前QA沒弄好的，他一來就弄好了。以前scrum master沒弄好的，他一來就好多了。

紅軍主力接管了民防團的陣地。就問你，效果能一樣嗎？ 所以，DevOps在他們的帶領下，就收編了無數時髦的技術。一時間，技術發展呈井奔之勢。

--------- 黃金分隔線 1.3 ----------

那現在DevOps社區的討論重要點哪裡呢？我的觀察是：1. 上雲，上AWS。2. 更安全，也即DevOpsSec。3. 從CM(Ansible, Chef, Puppet) 往容器化轉，向k8s轉。4. Serveless的探研

--------- 黃金分隔線 1.3 ----------

未來五年到十年呢？1. 交鑰匙式解決方案。慢慢標準化，慢慢產品化 2. 將AI帶入運維。智能化的故障排查和修復。3. 雲上省成本。

更多討論，可以看看這個討論（Denny Z. on LinkedIn: amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;quot;Cloud service and AI are…）

--------- 黃金分隔線 1.4 ----------

未來十年到二十年呢？顯然，市面對DevOps這個工種的需求會越來越少。DevOps作為一個Ops和QA的掘墓, 也會慢慢壽終正寢。

好消息是: 知識會過時, 聰明人不會過時。只有不斷地學習，不斷地適應，才能在未來AI橫行的世道謀得一口飯吃。

共勉共勉。對了, 這次之前，記得多鍛煉。游泳，跑步，健身啥的。以強健的體魄為老闆賣命，馴服機器人。

--------- 黃金分隔線 2.0 ----------

那干DevOps收益怎麼樣？不談收益, 只談理想的都是在流氓喲。我已經做了一段時間DevOps, 還是有很多困惑？太多技術要跟進了，你有啥最佳實踐或忠告嗎？

這些都是好問題！不過, 你這個原帖里沒問呀，不是嗎？我就不跑題了。

也不知道, 我說這麼多對你有沒有幫助。也算是我做的一些微小工作。

我就看看你敢不敢給點個贊！

DevOps其實一個體系，而不僅僅是某個崗位，是從總體提高企業IT部門運作效率出發的。

如何提高運作效率這個事情比較複雜也難以抽象，所以很多人就把DevOps具象成了建立一套有效率的開發運維工具，通過這個工具提升個體和團隊協作的效率。

為了做出和使用這些工具，就會要求運維人員具備一系列的技能，比如要會Python、Go語言的開發，要會使用Puppet、Ansible、Saltstack等一系列工具，並能對這些工具進行二次開發。

所以，如果你去做一個號稱是DevOps的崗位，多半會需要你掌握上述技能。

這對大多數傳統運維人員有點難度，但也不失為一個不錯的方向，以後想轉做開發也可以，擇業的路子會更寬一些。

最近DevOps為啥這麼火，跟最近兩年雲計算的快速普及也有很大關係：在雲計算平台上，各種資源，從伺服器到網路、負載均衡都是是有API可以創建和操作的，這就意味著所有的資源都是可以「軟體定義」的，這個給各種自動化運維工具提供了一個非常好的基礎環境。

DevOps的價值點，Puppet有出過一份調研報告，我覺得是講的比較好的，簡單摘抄如下：

（中文版的鏈接在此：http://www.idcos.com/download/devops-report）

? 與傳統組織相比,高效能IT組織的故障數量減少60%,故障恢復速度快168倍,同時部署代碼

時間快30倍,前置時間縮短200倍。故障是不可避免的,但是如何迅速地檢測故障並從故障中恢復,則顯示
出市場領先企業與市場追趕競爭對手兩者之間的區別。

? 精益管理和持續交付實踐為更快、更可持續地交付價值創造了條件。20世紀80年代精益原則的實踐運用徹底
地改變了製造業。今天,則需要IT行業實現精益管理。當你運用精益管理和持續交付實踐實現軟體交付時,
你將得到相同的結果━ 質量更高、周期更短、反饋迴路更便捷以及成本更低。精益管理和持續交付實踐帶
來的優勢並不局限於此:這些實踐也有助於創建組織內部的學習型文化並持續改進,最終實現較低程度的職
業倦怠感以及更高的組織整體績效表現。

無論你的應用程序是新開發、待開發還是已開發━ 只要它們的架構考慮到可測試性和可部署性方面的問題,
高性能是可以實現的。我們驚訝地發現各個系統類型━ 無論是互動型系統還是記錄型系統、成套系統或定
制系統、現有系統或待開發系統━ 這並不重要,只要系統採用正確的架構,持續交付就可以應用於任何系
統。我們還發現高績效企業更多地使用微服務架構,同時較少外包軟體開發或在大型機上運行自己的軟體。

IT經理在任何DevOps改造實踐中都起著關鍵性作用。今年的報告向我們展示了IT經理如何通過DevOps改造
幫助團隊獲得成功並領導組織。經理在聯繫商業戰略目標與團隊工作的工程中發揮至關重要的作用。經理可
以通過減少無效工作以及投資提升團隊成員能力等種種努力來改善團隊的績效。

團隊多樣性至關重要。研究表明,擁有更多女性成員的團隊具有更高的集體智慧,將實現更好的業務改善。
我們的調查顯示很少有團隊注重成員性別的多樣性。我們建議希望實現高績效的團隊要儘可能招聘和留用更
多女性,同時在其他領域也進一步改善,實現多樣性。

部署之痛可以讓你更加了解IT效能。你想知道你的團隊表現如何嗎?你所要做的是問一個簡單問題:「部署
將會多痛苦?我們發現,那些認為代碼部署最痛苦的組織,其IT效能、組織績效和文化也最糟糕。

DevOps可以幫助避免職業倦怠感。職業倦怠感與病態的組織文化以及無效、浪費的工作息息相關。倦怠感
的後果對於個人和組織而言都十分嚴重。組織可以通過建立一個有利的工作環境,確保員工明白自己工作的
重要性及其工作與組織的戰略目標緊密聯繫,從而改善導致倦怠感的外部條件。

謝邀

--------

個人認為，運維工程師需要轉變思路，主動尋求解決辦法，改變坐等工具的態度。運維和開發之間要更多主動性，更多責任感，更多的溝通！

title: DevOps實用資源分享

date: 2016-03-25 16:31:24

categories: 學習 | Study

description: DevOps是一個持續改進的過程

---

## 前言

其實一直很想整理一篇DevOps學習資源導航類文章，主要原因除了自己的懶惰外，技術的不斷創新也讓未來更加值得期待。雖然在大多數情況下我們既無法面面俱到也突破不了點的極限，但是這也不會阻礙我們對於學習的熱愛。梳理這篇文章也是希望自己能夠始終保持學習的態度，完善自己的知識體系，堅持技術沉澱的過程，享受點滴進步的快樂。

&>DevOps是一個持續改進的過程

---

## 更新歷史

2016年03月25日 - 增加InfoQ，神秘的程序員

2016年02月14日 - 增加Forvo，Coursera，自強學堂

2016年01月04日 - 增加利器

2015年12月22日 - 增加極客學院，網易公開課，曹政微信訂閱號

2015年10月29日 - 初稿

閱讀原文 - DevOps實用資源分享

---

## 圖書

&>我推薦大家嘗試使用Kindle改變自己閱讀的習慣

Kindle Paperwhite - http://www.amazon.cn/

## 搜索引擎

&> 善用搜索引擎，穿過一堵牆你的知識面可能會更加立體

FQ - GFW翻牆小結 | HelloDog

- 翻牆是一種學習態度

Google - https://www.google.com/

Google Images - https://images.google.com/

Google Scholar - https://scholar.google.com/

- 事實證明大多數情況下還是Google最懂我們的心

WikipediA - https://www.wikipedia.org/

- 試著把維基百科作為你的首選，弱化自己對於百度的依賴

Forvo - http://zh.forvo.com/

- 媽媽再也不用擔心我不會發音了，讓Forvo來做你的發音指南

## 安全

&>黑客的思路往往讓人眼前一亮，多向大牛們學習

知道創宇研發技能表 - http://blog.knownsec.com/Knownsec_RD_Checklist/

- 感謝[@餘弦](http://evilcos.me/)

納威安全導航 - http://navisec.it/

- 烏雲，FreeBuf，i春秋等都值得你多逛逛

## 閱讀訂閱

&>信息爆炸的時代如何過濾噪音很重要

知乎日報 - http://daily.zhihu.com/

- 每天 3 次，每次 7 分鐘

- 我習慣下班後離線閱讀生活中的美

- 讀讀日報和好奇心日報也推薦大家試試

開發者頭條 - http://toutiao.io/

- 碼農周刊團隊為程序員設計的閱讀分享平台

- 極客頭條，稀土掘金，伯樂在線等也是類似的

灣區日報 - http://wanqu.co/

- 關注創業與技術,每天推送5篇優質英文文章

- 堅持向來不易，鍛煉下英文閱讀能力也不錯哦

深藍閱讀 - http://bluereader.org/

- 簡單好用的內容訂閱平台

利器 - http://liqi.io/

- 創造者和他們的工具

## 社區

&> Way to Explore Way too Extreme

V2EX - http://www.v2ex.com/

- 一個與眾不同的社區

Stack Overflow - http://stackoverflow.com/

- 如果你使用Google相信會在這裡看到不少高質量的答案

## 微信訂閱號

小道消息 - WebNotes

- 馮大輝的小道消息已經成為微信訂閱號的標杆之一

曹政 - caozsay

- 曹大做為一個有故事的人，願意分享更願意交流，已經很難得了

高效運維 - greatops

- 蕭田國組織維護的"高效運維"公眾號每周多篇乾貨滿滿的原創好文

神秘的程序員 - coderstory

- 西喬和霍炬共同創作的程序員主題漫畫，為生活添加一抹色彩

InfoQ - infoqchina

- InfoQ在微信端的推廣和推送質量都是滿滿的誠意

## OJ

&>ACM和奧數類似屬於有天賦的你們，但實際工作中更要注重學習方法和問題總結

LeetCode - http://leetcode.com/

- leetcode 是一個針對程序員的面試準備平台

ACM之家 - http://www.acmerblog.com/

- POJ、HDU、ZOJ等在線OJ解題報告，相關經典演算法收集整理

牛客網 - http://www.nowcoder.com/

- 一個新的專業IT筆試面試備考平台

## 信息聚合

&>分享一些實用的技術學習路線

InfoQ - http://www.infoq.com/

- 促進軟體開發領域知識與創新的傳播

鳥哥的Linux私房菜 - http://vbird.dic.ksu.edu.tw/

- 我也是跟著鳥哥的文章進入Linux

存儲基礎知識 - https://community.emc.com/thread/176852

- EMC官方整理的教程，由淺入深知識面也很廣

菜鳥教程 - http://www.runoob.com/

- 學的不僅是技術，更是夢想

- 同類型還有w3school等

自強學堂 - http://www.ziqiangxuetang.com/

- 感謝@塗偉忠，Django可是自強學堂的招牌教程

優設 - http://hao.uisdc.com/

- 以前很喜歡騰訊CDC的設計理念，現在老了只能偶爾瞅瞅

VMware - http://www.vmware.com/cn/support/support-resources/pubs/

- 沒有貼圖還能把虛擬化手冊寫得灰常清晰具有可操作性，VMware必須得算一個

- 當然也推薦大家閱讀RedHat，SuSE，Oracle等官方幫助文檔

## Blog

&>推薦的Blog不多，希望大家找到適合自己的博客

編程隨想 - https://program-think.blogspot.com/

- 你應該了解一些真實的信息

阮一峰 - http://www.ruanyifeng.com/

- 堅持分享技術和生活的典範

酷殼 - http://coolshell.cn/

- 堅持更新技術類Blog的人或團隊越來越少，這也是認真做事的態度

## 在線教育

極客學院 - http://wiki.jikexueyuan.com/

- 在線教育類網站很多，我不做太多推薦，極客學院Wiki是一個好產品

網易公開課 - http://open.163.com/

- 國內外優質的MOOC資源很豐富，一起系統的完善自己的知識體系吧

Coursera - https://www.coursera.org/

- 在網上學習全世界最好的課程

- 在國外生活的同學幾乎都會推薦的網路學習平台

## 其它

&>還有很多需要耐心等待時間的驗證

用開發的思維解決運維的問題。

網路上說是一套溝通方式，但我覺得，應該是讓運維人員走到開發中去，讓開發人員開發的時候考慮一些運維因素。

以我目前所知，開發與運維存在不小鴻溝，經常溝通不足。運維為了穩定，開發為了功能，他們的奮鬥目標漸漸地發生偏移，不是為了產品更好，這樣存在的內耗會日益嚴重。所以需要他們進行溝通與協作，開發需要運維的知識與需求，運維需要開發的技能與目標，這樣子才能共同為了目標而奮鬥。所謂的devops應該就是為了這個而產生的，而不是說運維自己開發工具，也不是開發自己搞運維

DevOps是Dev和Ops兩者平衡的產物。前者希望能更快的上線，後者則希望更穩定。

傳統的Ops更像是一個「清理門戶的角色」。就比如Dev發布一個release，Ops上線，開始維護，兩者之間交集很少。

DevOps則是要在Dev開發的過程中深入整個開發進程，對將來BAU Operations中可能出現的在架構和細節上的技術陷阱和技術債務提出自己的疑慮。同時，還要負責開發高效的部署系統和監控系統，儘可能地保證版本能夠快速的部署，穩定的運行。

DevOps實際處理BAU的時間比Ops少很多，就以我現在職責為例，只有大概40%不到的時間在處理各種事務性運維工作，剩下主要是在做監控系統和各種DevOps tool的開發。

總結一下，Ops更傳統，效率較為低下。DevOps更自動化，效率更高，同時運維風險也更大（更高的自動化程度意味著更大的技術風險）。平衡好自動化和手動化兩者之間的關係，是一個合格的DevOps必須要做的功課。

Devops本身不是一種職位，Devops強調開發人員和運維人員的合作，實現軟體交付和基礎設施變更的自動化。它旨在建立一種可以快速、頻繁、可靠地構建、測試和發布軟體的文化。

基於Devops文化的運維工程從工作內容上講和傳統的運維工程師沒有本質的區別，但是更強調與開發人員的合作，以及利用工具實現自動化。

devops到底是什麼？華為軟體開發雲教會了我

根據Gartner 2015 IO Automation 報告，DevOps處於技術發展的最高點，實踐受到高度關注，到底devops魔力在哪裡？

從devops實踐看主要是打破開發人員和運營人員界限，讓運營思想能提前落地在研發的前端，避免研發過多的關注功能，而忽略運營需求。從這個角度講，devops理論上來講對整個開發效率提升並沒有明顯的促進作用，如果僅是開發人員和運營人員融合，這個成本代價也是很高的，既懂得研發又懂得運營的這種全面人才估計企業內部少有，還提高了門檻，那到底怎麼提升效率又不提高人員能力門檻呢？我一直百思不得其解，直到看到了華為剛發布的華為軟體開發雲服務，看到它的幫助才知道devops理念怎麼貫穿整個開發流程提升效率，怎麼通過華為開發雲服務就能簡單實現一個項目的devops高效流程。

打開華為雲的官網http://www.hwclouds.com，點擊左上的產品項就可以看到華為雲服務的所有產品，其中紅框的就是軟體開發雲服務，有項目管理、配置管理、流水線、代碼檢查、編譯構建、部署服務、測試管理、發布管理8大服務項。

一個項目開發需要進行這樣操作即可,「新建項目 &> 新建迭代 &> 新建工作項 &> 新建代碼倉庫 &> 新建代碼檢查任務 &> 新建編譯構建任務 &> 測試管理 &> 部署管理 &> 發布管理」，整個流程涉及代碼開發、代碼檢查、代碼編譯構建、部署、發布這幾個流程全部可以通過流水線定製自動化執行，這樣通過華為軟體開發雲就能很簡單的構建整個持續集成和部署、發布流程，自動化和流程化整個開發和運營流程，這個才是devops核心，華為軟體開發雲服務一下就解決了項目中落地devops的難題。

整個過程通過簡單選項添加即可，如添加一個新的構建選項如下圖：

自動化執行一鍵啟動就自動完成了

成功失敗可以等待，也可以直接看右上角的消息，直接能看到自動化流水線的結果

感覺使用華為軟體開發雲進行企業的devops流程熟悉和做一些個人項目開發管理都是一個好工具，後面繼續進行深入研究，有好的新的也公布給大家。

作為一個行業中工作了8年的技術人員，5年的運維工作經驗，這幾年也在從事devops開發，最近也在慕課網出了一個全網稀缺的devops python開發課程。

從我的職業角度，這是我對devops的理解。我認為devops工程師，工作職責上：

一方面向下服務，就是可以讓運維或者相關管理員的工作變得更輕鬆。如：資產管理系統，拿某視頻公司來說，視頻網站的硬體資產不僅豐富而且資產數量龐大，光維護成本就是一筆不小的投入，有了運維開發，我們可以通過cmdb、自動化任務執行等系統，讓資產更多的通過自動化的手段實現信息變更、流程、監控等繁瑣而且低效率的時期。

另外一方面就是向上服務了，服務企業的系統應用服務，如：早期的mogo代碼存在一些缺陷，有些甚至的非常嚴重的，我們需要去發現並追蹤這些代碼漏洞，實現系統應用服務的穩定性，或者說，為公司的實際需求添加更多的功能。

運維開發會將來會轉向devops開發，越來越多的擔負更多重要的角色。

最後附上，我的運維開發課程鏈接：

全網稀缺Python自動化運維項目實戰-慕課網實戰coding.imooc.com

剛好是普通SA，湊合來回答一下這個問題吧。

﹉﹉﹉﹉

devops是去年以來經常在文章或者同行業嘴裡提到的名詞。devops出現後，招聘網站上有兩個崗位類似:測試開發工程師、運維開發工程師。devops涉及了配置管理，自動化這些。

說實話，國內的IT環境下，人肉運維或者寫個腳本就冒充自動化的公司不在少數，SA在大部分公司並不重要，在他們眼裡只是花錢湊人頭而已，隨時換人又如何？（尤其業務對象是政府類）

傳統運維，一個新人剛開始不熟悉，幾個月之後自然會了。馬馬虎虎，後面的工作自然有不少重複勞動。所以devops更多是在傳統運維基礎上，做一些自動化的東西。說白了，就是偷懶。

誰說傳統OPS效率就比DEVOPS低啊？

誰說傳統OPS只考慮穩定，不考慮持續發布，自動化集成的？

套用一句話「不管是黑貓白貓，抓到耗子就是好貓。」

不管是啥OPS，只要能解決工作痛點就是好OPS。

自動化

DevOps是一種模式或者理念，而傳統運維是具體崗位。

關於DevOps我的理解是溝通開發（Dev）和運維（Ops）的一座橋，可以是一組工具，甚至模糊成一種文化，讓開發和運維之間互相了解對方的工作，從對方的角度去思考問題並且完善完成手上的項目。

之前看過數人云的一篇文章，裡面有一些數據可以看出DevOps和傳統運維本質的區別——

「據調查已經有33%的企業在IT項目中採用了DevOps模式；47%的企業準備在未來兩年內採用DevOps；只有20%的企業沒有這個規劃，」

「2016年的DevOps 報告指出，企業落地實踐DevOps減少了50%的返工時間，使用DevOps 模式工作的員工比未使用DevOps模式的員工多了66%的時間可以用在新項目上。」

「根據DevOps報告顯示，高績效的企業都改善了關鍵性指標：較之前200倍的部署、縮短了2555倍的交付時間、24倍的故障恢復速度以及降低了3倍的故障率。」

所以DevOps講基礎工作優化成自動化且增加了穩定性和減少了返工率。

這就是最本質的區別！

專業運維和專業開發之間的補充，不過國內很多公司為了省錢，再加上運維運營管理方面的落後，直接就省掉了專業運維。簡單點就是：本來應該是汽車上高速，現在直接開摩托車上高速公路了，等以後出事了再請專業運維來補鍋。

DevOps 不是一種職位，因此所謂的 DevOps 工程師到底是什麼？是不是就是具備很強編碼能力的運維（或者叫基礎設施工程師更合適）。

DevOps 也不是一個部門，不是 DevOps 工程師的集合。

DevOps 也不意味這 Dev 和 Ops 要歸屬統一部門，向同一領導報告。只要觀念和認識沒有變化，認識不到大家的共同目標，沒有採取積極的溝通方式，即使在同一個團隊，不同角色的人也很難做到統一思想、團結一致向前看。

DevOps 是一種思想、文化和最佳實踐的組合。DevOps 強調開發人員和運維人員（IT人員）的合作，實現軟體交付和基礎設施變更的自動化。它旨在建立一種可以快速、頻繁、可靠地構建、測試和發布軟體的文化。

更多討論可以參考： DevOps 是什麼不是什麼

從運維的標準化和自動化走向服務化，以前是提供給開發工具，現在則是提供一個服務化平台，運維更加高效，透明

只要技術夠牛，這些都不是問題。

『DevOps』是如何傷害一個開發者的我覺得這個角度更真實