作者 ：陳正瑋，來自臺灣。目前是臺灣 DevOps 社群組織者，也是《Effective DevOps》繁體中文版的譯者，以及《DevOsp 三十六計》繁體中文版的審校者。
本文摘選於陳正瑋於 3 月 13 日在 CodeHub#1 線上直播分享《DevOps 前世今生》，希望藉助這場分享能夠帶來一些 DevOps 的基本介紹、科普知識。
直播回顧地址 ：t.cn/ExdGwn6
曾經有人說過這樣的一句話，“IT Doesn't Matter.”，IT 似乎和水、電力一樣變成一種基礎設施、一種成本中心，除了提供基礎資源之外，IT 似乎不再重要，不需再被人們特別拿來一提。但真的是如此嗎？
事實上 IT 變得越來越重要，大家應該也聽過這句話，軟體正吃掉世界。這句話其實有更新版，軟體正“持續地”吃掉世界！現在各式各樣的企業，都正在轉變成為一間軟體公司、IT 公司。IT 及軟體依然“持續地”在各個行業發揮它的影響力。
既然各個企業都在轉變為軟體公司，那就讓我們從軟體開發涉及的組織部門、團隊來看一看。首先，你一定會有一個開發/研發部門，但只有研發部門是不夠的，往前會有業務部門，再往前則是客戶；往後會有運維部門，運維部門負責運維工作，讓客戶能順暢地使用服務。
不過我們都知道，研發一個軟體、產品，想要一帆風順，一次就打中客戶的心是很難的。畢竟，現在是一個高度競爭的時代，我們唯一確定的事情就是，市場總是充滿著不確定性與變化的。
從客戶這邊，我們可以得知市場是快速變化的。這也會反映到業務本身，產品與業務需求同樣快速變化。而常見的一個狀況是“業務與研發”之間經常具有溝通、合作上的問題。
於是，敏捷（Agile）出現了，敏捷宣稱能幫助研發“快速響應變化”，敏捷也幫助業務與研發之間，能擁有更良好的溝通協作。
當研發端敏捷之後，研發和運維之間又有另一個衝突發生。研發想要快速地響應變化，但對運維來說，他們會覺得每次釋出新版本總是有一堆問題需要收拾善後，所以最好沒事不要釋出新版本，能夠一直維持在一個安全且穩定的狀態。
於是 DevOps 出現了，DevOps 解決了研發與運維之間的衝突，幫助企業解決了研發和運維之間的溝通與協作問題。
讓我們換個方式說明，如果我們用軟體開發流程來看，研發和運維只有在軟體 release 的時候雙方才會有互動與交集。
但真實狀況卻是這樣的，兩方其實根本是溝通互動不良的，就像中間有一道牆。而這道牆的產生，可能是因為組織規模日漸擴大、專業能力的分工、或前面提過的成本中心的觀念等等造成的。
因此當研發這一端已經開始敏捷，能夠迅速響應變化。
我們不禁想問兩個問題，首先是“運維，有可能也敏捷起來嗎？”
以及，阻礙了研發和運維的這道牆壁，是不是有可能打破它？
因為這面看不見的牆，就會發生這張圖的狀況：研發將軟體交付之後就棄之不顧，但運維那邊服務已經火燒起來了，房子都快燒光了，但是研發卻說這和他們沒關係，你們運維自己要處理好。
所以我們一定要想辦法打破這道牆！而 DevOps 的出現，也正是告訴我們，這道ƒ牆必須被打破！
既然 DevOps 宣稱能解決這兩個問題，那麼它究竟是何時出現的？關於 DevOps 的誕生，我們可以從幾個歷史事件來談。
首先是 2008 年的“Agile 2008 Conference”，在當時目前被人稱為 DevOps 之父的 Patrick，在當年想要找人討論“Agile Infrastructure”。
這個歷史事件的重大意義在於，這代表了在 2008 年，已經開始有人們關注我們前面提及的這兩個問題“如何打破研發與運維的那道牆”和“如何讓運維敏捷”。
接著的重要事件則是隔年 2009 O'Reilly Velocity 技術大會上，Flickr 發表了一個演講，說明他們是如何做到一天部署 10 次。
當然在 10 年後的現在，一天部署十次可能不是什麼新鮮事，但在 2009 年，肯定是一件創舉。而這場演講現在也被人們公認為是世界首件 DevOps 成功案例。
由於前兩個事件的緣故，DevOps 之父 Patrick 決定要舉辦一場名為 DevOpsDays 的活動，讓大家一起好好的聊一聊這些話題。
當然這場活動舉辦完畢之後，在網際網路上的討論也隨之火熱起來，人們開始在 Twitter 上討論這場活動及相關的主題。然因為 Twitter 有字數限制，為了節省字數，他們就將 DevOpsDays 縮寫為 DevOps，於是 DevOps 這個字正式出現在這個世界上。
除此之外，後續也陸續有更多人響應，持續地討論 DevOps 相關主題，並且陸續有相關的書籍出版上市，像是大家都知道的《持續交付》與《鳳凰專案》。
所以由歷史來看，DevOps 確實是一場 IT、軟體研發行業的轉型運動，而且是一場由社群自主發起的運動。
但除了前面的這些歷史事件之外，其實 DevOps 能火熱起來，還有著更多原因。我個人認為這場運動的火熱，它更像是一場天時、地利、人和的結果，它是由更多的東西累積而來的，不然不可能因為一場 DevOpsDays 就讓全世界都跟著火熱討論。
如我們回顧更多的歷史，不可諱言的，隨著敏捷開發誕生的各種重要觀念、方法，推了 DevOps 一把。當然，各種優良的軟體工程觀念與方法，也推了 DevOps 一把，像是持續整合、持續交付……
除了敏捷之外，看板方法、精益（Lean）對於 DevOps 也是非常重要的。甚至你可以從精益再往前追溯到 TOC 限制理論 或 PDCA 戴明環。
除了這些觀念與實踐方法之外，技術與工具的發展也同樣重要。版本控制系統（例如：git）、虛擬化技術、容器化技術、組態配置管理工具、雲端服務，這些技術也都同樣推了 DevOps 一把。
所以真要說為何 DevOps 能夠火熱，其實是因為在 2009 年，已經有這麼多歷史寶藏的累積，這才令DevOps 能從 2009 年開始一飛沖天，火熱起來！
前面說了這麼多，我們中場休息一下，來個段子。
我們說在一千個讀者眼中，就有一千個哈姆雷特；同樣地，如果你詢問一千位 DevOps 專家，你可能會得到一千零一種相似但有些微差異的 DevOps 定義。
所以到底什麼是 DevOps？它其實就是網際網路上的一個標籤，當年它只是人們為了在網際網路上能夠討論 DevOpsDays 相關的內容，而透過 #devops 這個標籤，將人與人、將研發和運維的兩派人馬串連再一起。
但隨著 DevOps 在網際網路上越來越火熱，於是各方人馬，為了自己的目的（例如：做產品的想賣產品，社群的人想要更廣大的推廣它），於是大家開始為它新增了更多的定義。
既然 DevOps 難有一個標準的定義，因此這裡我覺得，我們不妨換一個角度來談一談 DevOps 的內涵。讓我們一起思考一個問題“一間企業要如何才能生存下去？”
這裡提供一個答案，企業能否存活的關鍵在於“企業能為你的顧客及使用者帶來什麼價值？”唯有能夠持續地將價值交付給使用者的企業，才能贏得市場，企業才能持續生存下去。
按這個思路，我們很容易地能夠理解，為何不論是研發或運維，企業的每個部門都必須具備能夠響應變化的能力，這都是為了滿足一個目標“交付價值”！
所以“價值”是非常重要的東西，那什麼是價值呢？簡單來說，就是我們想要的東西。
價值可能是企業關注的“商業價值”與“使用者價值”，亦可能是實際的資金、可能是市場佔有率。對使用者而言可能是你這個軟體好不好用，操作起來使用者體驗好不好。價值可能是很多不同的東西，涉及不同的層面，但用簡單一句話來說價值就是“我們想要的東西”。
因此我們可以說 DevOps 為我們解決了前述的兩個問題，它幫助企業讓研發和運維能成為一個高效率的團隊，幫助企業能夠交付價值給使用者。
也正是如此，我們即能理解為何談到 DevOps，很多人在討論的內容其實是敏捷、精益，因為敏捷與精益背後的價值觀、精神，也正與“交付價值”息息相關。
故此，我們可以說“順暢和高品質地交付有用的價值”，即“消除浪費”、“使價值交付最大化”，即是藏在 DevOps 背後最重要的一項價值觀。
這也就是為何在討論 DevOps 時，不只談論技術工具，也會談到文化層面的議題；人們不只會談論該使用哪種工具來達成持續整合，更會談到何為良好的團隊文化，如何讓團隊能擁有良好的協作能力與溝通能力。
因為，似乎只要是能夠幫助企業“順暢和高品質地交付有用的價值”的任何主題，都可以被包含在 DevOps 之內。
談完了 DevOps 的過去，接著讓我們快速地看一下 DevOps 的現在，看看現在大家在談到 DevOps 時，都在討論什麼。
如果你隨意的百度搜尋 DevOps 相關的圖片，那麼你很可能會搜尋到的是各式各樣的“智慧運維平臺”、“自動化運維平臺”這一類的內容。確實這些“平臺”對於 DevOps 是重要的，而且當你徹底的解決研發和運維之間的協作問題、流程問題時，往往其中一項成果即是這一類的平臺。
提到了流程，有些人在討論 DevOps 時，會從組織工作流程的持續改進的角度切入。例如在《鳳凰專案》和《DevOps 實踐指南》中提到的三步工作法。這裡就不詳述三步工作法的內容，有興趣的同學可以直接看看這兩本經典好書。
另外，有些人會談 CALMS（Culture、Automation、Lean、Measure 及 Sharing），或者更精簡一點，只談“文化”、“自動化”和“資訊透明度”，在《Effective DevOps》這本書則是從“協作”、“親和力”（Affinity）、“工具”及“擴充套件”（Scaling）切入討論。
時間有限，這裡我也用“自動化”、“資訊透明度”和“文化”來介紹 DevOps。首先說明的是 Automation 自動化。
自動化，以結果而論，可以說就是讓軟體研發至運維流程中的各個環節能夠“又短又快”，併為企業帶來一些實質的益處，像是提升可靠性、減少人為錯誤、提升生產力、減少浪費……而在這背後，你會發現跟精益的精神是密切相關的。
談到“自動化”，多半會提到另外三個詞，分別是“持續整合”、“持續交付”和“持續部署”，但需要注意的是這三個詞並非僅僅只包含著技術和工具，它們更是一種實踐方法，也就是說並非架設了 Jenkins 就代表你已經匯入或實踐了“持續整合”或“持續交付”，更重要的是研發團隊在工作的方法及流程，甚至在價值觀上是否擁抱這些實踐方法所包含的關鍵思維。
接著是“透明度”，或者應該說是“資訊透明度”。包含 Monitor、Metrics、Analytics。
其實也可以換句話說，即是讓資料（資訊）說話。
以軟體研發至運維整個流程來看，每一個環節都有許多值得被視覺化、度量，提升其透明度的資料，DevOps 意味著我們要讓這些資料（資訊）說話，成為企業持續改進的依據。
因此透明度，包含許許多多層面，不僅是與使用者相關的需求反饋、專案管理的狀態、運維的各種資料及日誌，甚至是每位員工擁有的專業知識都需要提升透明度，避免人員成為組織其中一項單點故障的原因。（如只有某位員工擁有某些特定的技能與知識，一旦該員工出了狀況，也可能會造成組織無法順利運作。）
最後，DevOps 是一種文化，DevOps 與文化很有關聯。
文化，是由人與人所形成的。而 DevOps 之父同樣也曾說過“DevOps is a human problem.”
因此我們不僅是要打破研發和運維之間的那道牆，我們更要讓整個企業都擁抱一種名為 DevOps 的良好文化。
就如我們在前面 DevOps 歷史提到的，在 2009 年 Flickr 即能做到一天部署十次，我們除了讚賞這件事之外，別忘了仔細看一下他們演講的副標題“Dev and Ops Cooperation”。
“一天能夠部署十次”是他們的成果，但要達成這件事的關鍵在於“讓研發與運維能夠協同合作”。由此看來，DevOps 確實是“human problem”，DevOps 確實和組織文化息息相關。
文化的形成需要組織從上到下的支援、由下到上共同的努力。DevOps 擁抱多種優良的文化，像是“鼓勵創新”、“容許犯錯”、“持續改善”、“接納多元觀點”、“當責”、“不究責”（對事不對人）……等。
如果你擁有一些企業經營管理的背景，那麼你可能會發現，DevOps 擁抱的這些優良文化，並非是首次被提倡於企業界。其實在企管、企業經理人、航空或醫療行業中，他們亦早已提出類似的觀點。所以這些優良文化，並非是一些空穴來風的東西，而是不同行業的專家們共同的看法與見解。
談了這麼多 DevOps 的內容，我們可以發現當人們在討論 DevOps 時，其實包含了多種層面，我們可以從價值觀、原則、方法、實踐、工具、歷史或運動各種層面來討論 DevOps。
讓我們再舉一個範例，這張圖是由 Gartner 提出的 DevOps Model。（這已經是舊版了，Gartner 有提出更新版本）
你可以看見，Gartner 眼中的 DevOps 包含 Culture、Process、People 及 Technology 四個部分。這四個部分彼此相關聯。
說明到此，相信各位都能理解到一件事，即是現今人們口中的 DevOps 其實是一個包含“人／文化”、“流程”及“技術／工具”的巨大議題！
最後，針對“工具”，特別要介紹一個不一樣的觀點，即是“工具是文化的加速器”。
DevOps 必然包含了技術與工具層面的議題，像是常見的 CI / CD 工具的技術選型，或 Monitor 工具的技術選型……等。
但除了探討工具實際運用的細節之外，我們別忘了“工具”是為誰提供“服務”、是誰在使用這些“工具”。因此，選用什麼工具、工具該如何操作並不是工具最重要的關鍵重點，真正的重點在於“工具之於人們的價值”。
如果你今天匯入了 Jenkins，但團隊內卻沒有人去使用它，那它便毫無價值，同理 Jenkins 可以替換成任何其他的工具、技術，甚至是實踐方法，像是看板、Agile、GitLab、Jira、容器……，無論替換成什麼，務必都要思考這一件事“工具之於人們的價值”。
別忘了，其實“工具與文化息息相關”！試著去思考一下康威定律與逆康威定律吧！
最後一個部分，我們來聊一聊 DevOps 的未來。
首先，SRE 將會是許多企業擁抱 DevOps 的一種實踐方向。畢竟這可是有谷歌掛保證的，谷歌在《SRE》書中提到了 SRE 是他們實踐 DevOps 的具體實踐。這其中包含了技術及文化層面的實踐。
並且當企業持續改善，最終擁抱了 AIOps、自動化運維時，終究會遇到谷歌曾經面臨的困境，於是很自然的企業亦會向著 SRE 的方向前進。
DevOps 的另一項未來發展，即是成為一種人人只要付費就能擁有的平臺或服務，而目前各大雲端供應商也都已經推出自家的 DevOps as a Service。如果花一點小錢就能迅速搭建好一個環境，幫助企業解決研發和運維之間協作流程的諸多問題，相信對於尚未開始匯入 DevOps 的企業而言，應該是一個可以考慮的選項。
當然，還是要再次提醒，你並不會因為匯入了一套工具、平臺或 DevOps as a Service 就能聲稱企業已經成功匯入 DevOps，工具的架設與匯入只是開始。
DevOps 將會成為一種“認證”與“標準”。
對於期望擁抱 DevOps 的企業而言，認證與標準可以成為一項助力，因為在面對 DevOps 所涉及的如此廣大範圍的內容，我們很容易因此迷失方向。但認證與標準，則能為我們提供一份指南，成為我們的道標，讓你有跡可循開始你的 DevOps 旅程。
但同樣的亦要提醒，“What you measure is what you get.”，認證與標準應該要成為你的助力，而不要倒果為因，為了認證而去認證，為了標準而去迎合標準。
最後，DevOps 恐怕將會消失，或同化在每個企業的基因當中。
就像先前一項研究調查，現今國外的軟體研發公司絕大多數皆已經擁抱敏捷（Agile），敏捷似乎已經逐漸成為一種習以為常的標準作法。同樣的，DevOps 亦有往此發展的趨勢，已有越來越多的企業主動擁抱 DevOps。
今晚談了非常多的內容，最後快速做個回顧。
如前面的段子，一千個 DevOps 專家，會有一千零一種 DevOps 定義，如今 DevOps 的標準定義已經不是人們討論的重點了。
現在大家在談的都是實戰經驗，到底在提升企業的生產力、打造高效企業、提升企業交付價值的能力上，你做了些什麼？在你宣稱匯入 DevOps 的過程中，你實踐了哪些方法？又是如何實踐的？
狹義的來看 DevOps，它似乎只是為了解決研發和運維之間的衝突與協作問題，但如果我們提升至廣義的角度來看，廣義的 DevOps 是將整個組織都包含在內，整個組織都應該共同為了“交付價值”而“持續改進”。
畢竟一間組織，不該如上圖左側這樣一層壓榨下一層部門，而應該是右側的金字塔一樣，每個部門都同等重要，缺了一角這個金字塔的結構都有可能因此崩潰。
“DevOps is a human problem.”，DevOps 包含“人／文化”、“流程”及“技術／工具”三個層面，這些都一再提醒我們除了關注企業內的“技術債”，也別忘了處理“文化債”。
要知道“人們並不抵制改變，他們抵制的是被改變。”
唯有形塑出良好的文化，才能為企業帶來長遠深邃的改變，才能讓企業長久擁抱“持續改進”，持續地向使用者“交付價值”。
最後的最後，再說一次別忘了“消除浪費，交付價值”，一起邁向這趟 DevOps 旅程吧！
號外：臺灣 DevOps 社群將於今年 10 月舉辦 DevOpsDays Taipei 2019，目前正在徵求講師與議題，歡迎感興趣的朋友投稿：devopsdays.tw/cfs
| mPaaS 第一期線下沙龍 CodeDay#1 開放報名中：
期待你的參與。