做者 ：陳正瑋，來自臺灣。目前是臺灣 DevOps 社區組織者，也是《Effective DevOps》繁體中文版的譯者，以及《DevOsp 三十六計》繁體中文版的審校者。 本文摘選於陳正瑋於 3 月 13 日在 CodeHub#1 線上直播分享《DevOps 前世此生》，但願藉助這場分享可以帶來一些 DevOps 的基本介紹、科普知識。git
直播回顧地址 ：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 的過程當中，你實踐了哪些方法？又是如何實踐的？oop
狹義的來看 DevOps，它彷佛只是爲了解決研發和運維之間的衝突與協做問題，但若是咱們提高至廣義的角度來看，廣義的 DevOps 是將整個組織都包含在內，整個組織都應該共同爲了「交付價值」而「持續改進」。
畢竟一間組織，不應如上圖左側這樣一層壓榨下一層部門，而應該是右側的金字塔同樣，每一個部門都同等重要，缺了一角這個金字塔的結構都有可能所以崩潰。
「DevOps is a human problem.」，DevOps 包含「人／文化」、「流程」及「技術／工具」三個層面，這些都一再提醒咱們除了關注企業內的「技術債」，也別忘了處理「文化債」。
要知道「人們並不抵制改變，他們抵制的是被改變。」 惟有形塑出良好的文化，才能爲企業帶來長遠深邃的改變，才能讓企業長久擁抱「持續改進」，持續地向用戶「交付價值」。
最後的最後，再說一次別忘了「消除浪費，交付價值」，一塊兒邁向這趟 DevOps 旅程吧！性能
號外：臺灣 DevOps 社區將於今年 10 月舉辦 DevOpsDays Taipei 2019，目前正在徵求講師與議題，歡迎感興趣的朋友投稿：devopsdays.tw/cfs 3d
| mPaaS 第一期線下沙龍 CodeDay#1 開放報名中： 版本控制
活動主題 ：移動端高性能架構演進與跨平臺開發實踐日誌
本期邀請支付寶移動端技術專家，與你們面對面一同探討在跨平臺開發下的高可用、高性能架構演進與跨平臺開發、動態化更新實踐。
報名方式 ：點擊「閱讀原文」進入活動頁進行報名；沒法到現場的同窗可經過釘釘搜索羣號「23124039」當即加入技術交流羣，屆時獲取直播地址，並有機會與講師在羣內深度交流。
期待你的參與。
