DevOps 的意義

回想一下你最近一次嘗試改掉一個個人習慣的事情，你可能遇到過這樣的情形，你需要改變你思考的方式並且改掉之前的習慣。這很艱難，你只能試著改變你自己的思維方式。

所以你可能會試著讓自己置身於新的環境。新的環境實際上可幫助我們養成新的習慣，它反過來又會促成新的思維方式。

那就是能否成功改變的所在：思考的越多，得到的越多。你需要知道你在改變的原因以及你的目的所在（而不僅僅你要怎麼做），因為改變本身往往是短暫和短視的。

現在想想你的 IT 組織需要做出的改變。也許你正在考慮採用像 DevOps 這樣的東西。這個我們稱之為 「DevOps」 的東西有三個組件：人、流程和工具。人和流程是任何團體組織的基礎。因此，採用 DevOps 需要對大多數組織的核心進行根本性的改變，而不僅僅是學習新的工具。

如同其它的改變一樣，它也是短視的。如果您將注意力集中在將改變作為單點解決方案 —— 例如，「獲得更好的報警工具」 —— 你可能只是管中窺豹。這種思維方式或許可以提供一套擁有更多鈴聲、口哨以及可以更好地處理呼叫輪詢的工具，但是它不能解決這樣的實際問題：警報不能送達到正確的團隊，或者故障得不到解決，因為實際上沒有人知道如何修復服務。

新的工具（或者至少一個新工具的想法）創造了一個討論潛在問題的機會，可以讓你的團隊討論對監控的看法。新工具讓你能夠做出更大的改變 —— 信仰和做法的改變 —— 它們作為你組織的基礎而顯得更加重要。

創造更深層次的變革需要一種可以全新地改變觀念的方法。要找到這種方法，我們首先需要更好的理解變革的驅動力。

清除柵欄

就改革而言，它不同於推翻。這是一條直白且簡單的原則，這個原則或許被視作悖論。在這種情況下，存在某種制度或法律；這麼說吧，為了簡單起見，在一條路上架設了一個柵欄或門。當今的改革者們來到這兒，並說：「我看不到它的用處，讓我們把它清除掉。」更聰明的改革者會很好地回答：「如果你看不到它的用處，我肯定不會讓你清除它，回去想想，然後你可以回來告訴我你知道了它的用處，我也許會允許你摧毀它。」 — G.K Chesterton, 1929

為了了解對 DevOps 的需求 —— 它試圖將傳統意義上分開的開發部門和運維部門進行重新組合 —— 我們首先必須明白這個分開是如何產生的。一旦我們"知道了它的用處"，然後我們就會知道將它們分開是為了什麼，並且在必要的時候可以取消分開。

今天我們沒有一個單一的管理理論，但是大多數現代管理理論的起源可以追溯到 弗雷德里克·溫斯洛·泰勒 Frederick Winslow Taylor 。泰勒是一名機械工程師，他創建了一個衡量鋼廠工人效率的系統。泰勒認為，他可以對工廠的勞動者運用科學分析的方法，不僅可以改進個人任務，也證明發現了有一個可以用來執行任何任務最佳方法。

我們可以很容易地畫一個以泰勒為起源的歷史樹。從泰勒早在 18 世紀 80 年代後期的研究出現的時間運動研究和其他質量改進計劃，跨越 20 世紀 20 年代一直到今天，我們可以從中看到六西格瑪、精益，等等類似方法。自上而下、指導式管理，再加上研究過程的系統方法，主宰了今天主流商業文化。它主要側重於把效率作為工人成功的測量標準。

如果泰勒是我們這顆歷史樹的根，那麼我們主幹上的下一個主叉將是 20 世紀 20 年代通用汽車公司的 阿爾弗雷德·斯隆 Alfred P. Sloan 。通用汽車公司創造的斯隆結構不僅持續強勁到 21 世紀初，而且在未來五十年的大部分時間裡，都將成為該公司的主要模式。

1920 年，通用公司正經歷一場管理危機，或者說是缺乏管理的危機。斯隆向董事會寫了一份為通用汽車的多個部門提出了一個新的結構《組織研究》。這一新結構的核心概念是「集中管理下放業務」。與雪佛蘭，凱迪拉克和別克等品牌相關的各個部門將獨立運作，同時為中央管理層提供推動戰略和控制財務的手段。

在斯隆的建議下（以及後來就任 CEO 的指導下），通用汽車在美國汽車工業中佔據了主導地位。斯隆的計劃把一個處於災難邊緣公司創造成了一個非常成功的公司。從中間來看，自治單位是黑盒子，激勵和目標被設置在頂層，而團隊在底層推動。

泰勒思想的「最佳實踐」 —— 標準、可互換和可重複的行為 —— 仍然在今天的管理理念中佔有一席之地，與斯隆公司結構的層次模式相結合，主導了僵化部門的分裂和孤島化以實現最大的控制。

我們可以指出幾份管理研究來證明這一點，但商業文化不是通過閱讀書籍而創造和傳播的。組織文化是 真實的 人在 實際的 情形下執行推動文化規範的 具體的 行為的產物。這就是為何類似泰勒和斯隆這樣的理論變得固化而不可動搖的原因。

技術部門投資就是一個例子。以下是這個周期是如何循環的：投資者只投資於他們認為可以實現 他們的 特定成功觀點的公司。這個成功的模式並不一定源於公司本身（和它的特定的目標）；它來自董事會對一家成功的公司 應該 如何看待的想法。許多投資者來自從經營企業的嘗試和苦難中倖存下來的公司，因此他們對什麼會使一個公司成功有 不同的 理念。他們為那些能夠被教導模仿他們的成功模式的公司提供資金，希望獲得資金的公司學會模仿。這樣，初創公司孵化器就是一種重現理想的結構和文化的直接的方式。

「開發」和「運維」的分開不是因為人的原因，也不是因為不同的技能，或者放在新員工頭上的一頂魔法分院帽；它是泰勒和斯隆的理論的副產品。責任與人員之間的清晰而不可滲透的界線是一個管理功能，同時也注重員工的工作效率。管理上的分開可以很容易的落在產品或者項目界線上，而不是技能上，但是通過今天的業務管理理論的歷史告訴我們，基於技能的分組是「最好」的高效方式。

不幸的是，那些界線造成了緊張局勢，這些緊張局勢是由不同的管理鏈出於不同的目標設定的相反目標的直接結果。例如：

• 敏捷 ⟷ 穩定
• 吸引新用戶 ⟷ 現有用戶的體驗
• 讓應用程序增加新功能 ⟷ 讓應用程序保持可用
• 打敗競爭對手 ⟷ 維持收入
• 修復出現的問題 ⟷ 在問題出現之前就進行預防

今天，我們可以看到組織的高層領導人越來越認識到，現有的商業文化（並擴大了它所產生的緊張局勢）是一個嚴重的問題。在 2016 年的 Gartner 報告中，57％ 的受訪者表示，文化變革是 2020 年之前企業面臨的主要挑戰之一。像作為一種影響組織變革的手段的敏捷和 DevOps 這樣的新方法的興起反映了這一認識。「影子 IT」 的出現更是事物的另一個方面；最近的估計有將近 30％ 的 IT 支出在 IT 組織的控制之外。

這些只是企業正在面臨的一些「文化擔憂」。改變的必要性是明確的，但前進的道路仍然受到昨天的決定的約束。

抵抗並不是沒用的

Bert Lance 認為如果他能讓政府採納一條簡單的格言「如果東西還沒損壞，那就別去修理它」，他就可以為國家節省三十億。他解釋說：「這是政府的問題：『修復沒有損壞的東西，而不是修復已經損壞了的東西。』」 — Nation's Business, 1977.5

通常，改革是組織針對所出現的錯誤所做的應對。在這個意義上說，如果緊張局勢（即使逆境）是變革的正常催化劑，那麼對變化的 抵抗 就是成功的指標。但是過分強調成功的道路會使組織變得僵硬、衰竭和獨斷。重視有效結果的政策導向是這種不斷增長的僵局的癥狀。

傳統 IT 部門的成功加劇了 IT 孤島的壁壘。其他部門現在變成了「顧客」，而不是夥伴。試圖將 IT 從成本中心轉移出來創建一個新的操作模式，它可以將 IT 與其他業務目標斷開。這反過來又會對敏捷性造成限制，增加摩擦，降低反應能力。合作被擱置轉而偏向「專家方向」。結果是一個孤立主義的觀點，IT 只能帶來更多的傷害而不是好處。

正如「軟體吃掉世界」，IT 越來越成為組織整體成功的核心。具有前瞻性的 IT 組織認識到這一點，並且已經對其戰略規划進行了有意義的改變，而不是將改變視為恐懼。

例如，Facebook 與人類學家 羅賓·鄧巴 Robin Dunbar 就社會團體的方法進行了磋商，而且意識到這一點對公司成長的內部團體（不僅僅是該網站的外部用戶）的影響。 扎波斯 Zappos 的文化得到了很多的讚譽，該組織創立了一個部門，專註於培養他人對於核心價值觀和企業文化的看法。當然，這本書是 《開放式組織》的姊妹篇，那是一本描述被應用於管理的開放原則 —— 透明度、參與度和社區 —— 可以如何為我們快節奏的互聯時代重塑組織。

決心改變

「如果外界的變化率超過了內部的變化率，那末日就不遠了。」 — Jack Welch, 2004

一位同事曾經告訴我他可以只用 「信息技術基礎設施庫（ITIL）」 框架裡面的辭彙向一位項目經理解釋 DevOps。

雖然這些框架 似乎 是反面的，但實際上它們都集中在風險和變革管理上。它們簡單地介紹了這種管理的不同流程和工具。在 IT 圈子外面談論 DevOps 時，這一點需要注意。不要強調流程問題和故障，而是顯示更小的變化引起的風險 更小 等等。這是強調改變團隊文化的有益方式：專註於 新的 功能而不是老問題，是改變的有效中介，特別是當您採用別人的框架進行參考時。

改革不僅僅只是 重構 組織；它也是跨越歷史上不可跨越的鴻溝的新途徑 —— 通過拒絕把像「敏捷」和「穩定」這樣的東西作為互相排斥的力量來解決我之前提到的那些緊張局勢。建立注重 結果 勝過 功能 的跨部門團隊是一個有效的策略。把不同的團隊 —— 其中每個人的工作依賴於其他人 —— 聚集起來圍繞一個項目或目標是最常見的方法之一。消除這些團隊之間的摩擦和改善溝通能夠產生巨大的改進 —— 即使在堅持鐵倉管理結構時（如果可以掌握，則不需要拆除孤島）。在這些情況下，對改革的 抵抗 不是成功的一個指標；而對改革的擁抱才是。

這些也不是「最佳實例」，它們只是一種檢查你自己的柵欄的方式。每個組織都會有獨特的、由他們內部人員創造的柵欄。一旦你「知道了它的用途」，你就可以決定它是需要拆解還是掌握。

本文是 Opensource.com 即將推出的關於開放組織和 IT 文化指南的一部分。你可以在這註冊以便當它發布時收到通知。

（題圖 : opensource.com）

作者簡介：

Matt Micene 是 Red Hat 公司的 Linux 和容器傳播者。從架構和系統設計到數據中心設計，他在信息技術方面擁有超過 15 年的經驗。他對關鍵技術（如容器，雲計算和虛擬化）有深入的了解。他目前的重點是宣傳紅帽企業版 Linux，以及操作系統如何與計算環境的新時代相關。

via: https://opensource.com/open-organization/17/5/what-is-the-point-of-DevOps

作者：Matt Micene 譯者：zhousiyu325 校對：apemost，wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive