DevOps的基礎知識-Part 3
人員與文化
在本文中，我們將討論支持 DevOps 的文化。我們還將回顧:
- 協作和共享的重要性
- 協作的主要特徵
- 變革型領導的重要性
- 變革型領導者的特徵
- DevOps 架構和團隊
- 支持成功實施 DevOps 的組織模型
在我們討論完關於DevOps的人員與文化議題後，我們將能夠總結 IT 在嘗試以"正確的品質、速度和成本"提供服務時所面臨的"文化、架構和技術障礙"，以及為什麼在現代企業中實施 DevOps 所面臨挑戰。
我們將列出 DevOps 轉變文化和更好地組織人員解決 IT 面臨的文化和架構挑戰的方式，並討論 DevOps 在組織內建立團隊和人員以支持其文化、流程和技術的方式。
文化
定義
文化是在組織內形成的。文化是從可觀察到的行為模式中得知，這些模式隨著時間的推移被組織中的員工所內化。每個人都有自己的一套價值觀和態度，但因為組織的框架，每個人都必須將自己的價值觀和態度將其適應組織本身。
員工的行為是由激勵因素、員工如何看待他人的行為、自我保護和社會控制的形式決定的。組織文化並不存在於組織內部的真空中。它在某種程度上是由其所在社會的更廣泛文化所塑造的。此外，組織文化並不像許多人想像的那樣單一。組織內可能存在次文化。例如，IT單位就是其中之一，有自己的心態、價值觀和態度。
組織文化似乎是高階管理層的事，而對其進行整個組織的文化變革可能很難或幾乎不可能，尤其是當我們不是高階主管時。文化變革意味著改變使人們以某種方式行事的舊信念與假設，並灌輸或嵌入新的信念和假設。
這意味著改變人們習慣做事的方式。由於文化往往植根於情感，人們很容易對變化感到不舒服、受到威脅或防禦。然而，重要的是要記住，雖然文化通常會抵制變革，但它自幾本身其實也在不斷變化。這種矛盾的條件限制了變革的速度並消耗大量的組織量能。
但變革是必要的！
無論我們喜歡與否，變革總是會發生。擁抱變革並認識到如果我們作為組織內領導變革的領導者的個人角色最終可能會是一次有益且正面的經歷，這對於確保成功實施 DevOps 至關重要。
許多組織的文化傾向於傳統的作業方式或過時的思維方式，從而導致團隊在穀倉中作業等問題，團隊對自己的工具和流程有防禦和保護本能，團隊缺乏對交付業務價值和滿足客戶需求的關注。
DevOps 文化以結果為導向。因此，DevOps 團隊擁抱新思維，積極主動地作業，並將問題和失敗視為學習機會 — DevOps 文化中不存在穀倉。團隊成員不會因為問題而互相指責，而是相互照護，並作為一個整體來開展作業。
我們需要記住，由於上述原因，轉向 DevOps 文化可能具有挑戰性。DevOps 文化是關於在開發、 維運和業務中分擔責任並朝向透明度、溝通和協作。 它強調更多的多學科、跨職能團隊，專注於提供業務價值和滿足客戶需求。
當領導者討論支持 DevOps 的文化時，他們討論和承認的最重要的一點是協作的必要性。 打破混亂之牆和造成混亂的穀倉需要優先考慮協作和團隊合作，首先打破造成混亂之牆的穀倉心態。
協作的主要特徵
協作可能是一個挑戰。如我們所知，組織的架構和設置方式通常不利於協作。某些行為和態度有時會成為 DevOps 所需的協作的障礙。而領導者與其成員必須消除這些協作障礙才能實現 DevOps 文化。
這項任務可能很困難，因為許多組織都存在阻礙溝通、透明度、信任和問責制的障礙。然而，如果沒有這些關鍵特徵，協作就不可能，因此 DevOps 也不可能。
一般企業，尤其是一些大型企業的溝通障礙通常是需要長時間的等待才能回答或處理問題，或者可能無法請求協助或提出問題是很嚴重但並收到及時回復。
有一些方法可以克服此類溝通障礙。例如，如果等待時間很長，那麼可以透過新的或更好的溝通工具、開放式辦公室來解決這個障礙，或者我們可以改變座位安排或ticket system來解決問題。
而透明度的障礙則是缺乏對為什麼每個團隊以某種方式運作的理解，或者可能是黑箱作業，這意味著你看不到其他人正在做甚麼。
有一些方法可以克服此類透明度障礙。例如，如果對每個團隊為何以某種方式運作缺乏了解，那麼跨職能團隊可以解決障礙，或者跨團隊會議可以提供更大的透明度。
而信任的障礙在於缺乏優先考量彼此需求或理解彼此挑戰的能力。 或者也許是相信其他人沒有共同的優先事項或目標。
有一些方法可以克服這些障礙。 例如，可以透過引入新的技能來解決缺乏對技能的認可問題。認可員工成就的計劃，或概述團隊成員相互指導並學習新技能的舉措。
問責制障礙在於當專案或任務失敗時，角色和職責的重疊可能會導致衝突，或者可能會找替罪羊。
有一些方法可以克服這些障礙。例如，可以透過使用新的或更有效的知識管理系統或工具，或透過將開發團隊成員納入維運團隊來解決從營運到開發缺乏回饋的問題，反之亦然。
共享與實驗
DevOps 鼓勵協作和分享。我們在DevOps的基礎知識-Part 2一文中討論過CALMS(文化、自動化、精實、量測與共享)。共享和協作對於 DevOps 的成功實施至關重要。只有透過協作和分享，DevOps 才能打破開發和維運之間的混亂之牆。
我們已經理解了為什麼開發和維運需要共享優先順序和目標，以幫助打破目前 IT 單位面臨的問題。還需要共享過程和知識以實現流程，例如強調第一種方式(Flow)，並需要分享回饋，如第二種方式(Feedback)強調。
最重要的是，開發和維運最終需要明白他們永遠共享成功和失敗。共享是 DevOps 的基礎，因此 DevOps 是一個集體知識體系，將 DevOps 的定義形式化或試圖控制與 DevOps 相關的思維將與之相對立的。
我們已經看到了一些被認定為障礙的問題，例如溝通、透明度、信任和問責制。社會學家 Ron Westrum 對這些問題進行了分類，其中大多數問題都顯示了病態的組織文化。 在他的模型中，他描述了三種類型的組織 — —
- 病態的(Pathological)
- 官僚的
- 生成的(Generative)
該模型旨在預測醫療保健產業的安全和績效結果。 出於我們只討論DevOps，我們將討論病態和生成文化。
病態文化的特徵是群體之間的協作和合作非常低。為了個人利益而隱瞞資訊，並且由於人們以權力為導向，因此指責(找戰犯)文化猖獗。病態文化並不安全。 這種說法意味著人們創造了一種溝通不良和缺乏信任的文化。
人們缺乏責任感，這些問題導致完全缺乏透明度，因為沒有人願意讓其他人知道自己在做什麼。 在病態文化中工作的員工生活在恐懼之中 — — 害怕失敗、害怕發聲、害怕被解僱或受到指責等等。
DevOps 需要一種生成文化。 在生成文化中，人們會積極尋求資訊； 學習和分享知識很重要。鼓勵溝通，並且由於責任是共同承擔的，因此存在真正的問責制。沒有人害怕失敗或大聲疾呼，因為失敗會引起質疑而不是責備。
此外，新的想法和創新不僅受到鼓勵，而且還得到實施。 DevOps 是關於擁抱生成文化。DevOps 還在於認識到，在某些情況下，重點可能是導入新流程、實踐和新工具。
最最重要的，文化不僅僅是態度。事實上，流程和工具會受到文化的影響。DevOps 旨在創造一種讓每個人都感到安全和受到支持的文化。這種文化讓員工感到被賦予權力，並且能夠進行實驗和創新。
實驗意味著能夠失敗，並認識到失敗並不是消極的，因為它會帶來學習。 事實上，當我們嘗試新事物並接受新想法時，失敗可能會更頻繁地發生，而不是更少。 在 IT 領域，實驗通常是為了證明或反駁假設。
這種方法將使我們能夠確定執行作業的新方法。然而，當我們嘗試確定新方法時，擁有能夠應對失敗的文化非常重要。DevOps 鼓勵失敗，但要負責任地失敗 — — 計算風險，以最小代價快速失敗，然後學習和實施事後實際有效的解決方案。
為此，預計失敗的組織需要積極主動地處理失敗，而不是被動地應對。
讓我們來整理一下病態文化與生成文化:
病態文化:
- 權力導向
- 合作程度低
- 傳遞訊息的人被幹掉
- 責任被推卸
- 不鼓勵跨界
- 失敗導致產生戰犯
- 創新被擠壓
生成文化:
- 積極尋求訊息與新知
- 傳遞訊息的人經過訓練
- 責任是共擔的
- 跨界有獎勵
- 失敗會去尋原因
- 創新已實現
領導力
理想情況下，DevOps 應該在高層次上建立，以便它從上到下滲透到企業文化中。但理想很豐滿，現實很骨感。因此，變革型領導者（不一定在組織中擔任領導角色的人）扮演重要角色。
領導者可以透過建立和支持"生成性和高度信任"的文化規範來說服組織朝著所需的方向前進。 或透過實施可提高開發人員生產力、減少代碼部署交付時間並支援更可靠的基礎架構的技術和流程。透過支援團隊實驗和創新，以更快的速度創造和開發更好的產品。
變革型領導者也可以跨組織的穀倉開展作業，以實現策略一致性。我們可以根據上圖這五個維度衡量變革型領導力。將組織文化甚至團隊或部門文化轉變為某種生成性文化，以強化一組共同的優先事項和目標並支持 DevOps，實際上是一種轉變。
轉型需要一個願景 — — 對為什麼要尋求轉型和變革以及最終結果是什麼有清晰、良好溝通的理解。願景是有抱負的，甚至是理想化的。 它可以回答很多問題，例如：
- 我們希望實現什麼目標來作為未來行動的明確指南？
- 我們可以是誰?
- 我們能做什麼
如果在 DevOps 之旅開始時就制定了願景，那麼專業人士在未來遇到需要答案的問題時可以依靠該願景。這願景將引導他們前進。 如果沒有清晰的願景，在制定決策和實施新流程或工具時就不存在明顯的路徑。 一開始就確立願景可以確保之後發生的一切都保持一致。
清晰的願景還可以幫助專業人士更清楚地關注轉型的結果，並防止領導力和變革的範圍擴大、變得不可阻擋或不明確。要進一步了解變革型領導，我們需要了解傳統領導者和變革型領導者之間的差異。
傳統領導者更傾向於「命令與控制(Command & Control)」模式。 傳統領導者本質上更具權威性。他們發出命令並期望團隊執行這些命令，並且沒有太多協商、討論或挑戰的空間。而這一類的領導風格導致知識集中在高層。讓我們思考一下"need-to-know"這個詞彙(尤其這一個詞彙在資安領域經常被提及)。 傳統領導者囤積訊息，這是之前提過的病態文化的特徵之一。
變革型領導鼓勵韌性、學習、知識分享，最重要的是協作。 變革型領導以精實領導為基礎，更傾向於促發而不是命令與控制。變革型領導者相信團隊成員會為團隊帶來新的獨特技能和知識，並且更願意將領導角色轉移給其他人。他們將合適的人聚集在一起，支持他們，然後去除他們做事的障礙。
讓我們分類一下傳統型領導與變革型領導的不同特徵點:
傳統型領導:
- 制定財務規劃
- 要求快速得到結果
- 以答案來引導
- 快速取得權力或尋找新權力
- 將團隊視為達到目的的手段
- 實施open door policy
變革領導:
- 朝著願景努力
- 表現出耐心
- 以問題引導
- 逐步提升自己的地位
- 發展個人並實現有效的團隊合作
- 透過出席和參與來學習和領導
團隊
哈佛大學教授 理查.哈克曼在《組織中的自我管理心理學》中概述了團隊權威的級別，這在討論變革型領導力、理解領導者的角色應該是什麼以及 DevOps 團隊應該如何構建時非常重要。
哈克曼在他的書中解釋從傳統的管理者領導的團隊到自我管理組織，然後是自主型團隊的連續體。 理解這些不同的團隊和領導風格應該能讓我們認知 DevOps 真正需要的變革型領導。
管理者領導的團 — 哈克曼將傳統的命令和控制風格的團隊稱為管理者領導的團隊。 在這樣的團隊中，管理者負責除執行工作以外的所有事情。 管理者主導的風格是權力導向的，管理者將資訊囤積在自己手上。 這種風格不利於協作。
自我管理 — 領導者控制這樣的團隊，設計團隊，將他們組合在一起，並設定他們的整體方向。然而，管理者不監控或管理他們的工作流程。管理者允許團隊成員有權監控或管理他們自己的工作流程。這一類的團隊鼓勵協作和自主並打破穀倉。
第三種是自主型團隊 — 在這樣的團隊中，領導者只負責設定整體方向，團隊本身負責設計整體背景脈絡。 自主型團隊是獨立的，但團隊成員是相互依賴的。領導者給他們一個使命和整體方向，團隊成員可以以任何他們想要的方式實現使命， 這種團隊模型非常適合敏捷和 DevOps。
最後是自治型團隊 — 在自治型團隊中，領導者不僅要求管理者成為變革型領導者。 自治型團隊要求所有團隊成員對責任和所有權有不同的理解。
為了真正有效能與效率，自治型團隊需要系統性思考和對真正方向的理解以及對端到端價值流的責任感。我們可以在上圖看到傳統團隊和自治型團隊之間的差異。
康威定律表明，所有設計的系統，無論其意圖如何，最終都會圍繞組織本身的結構進行設計。
例如，四層組織結構圖將導致四層審核系統。 我們嘗試在 IT 內實施的任何新方法或系統最終都將符合 IT 部門的現有架構以及整個組織的更大的溝通結構。
因此，在傳統的垂直結構 IT 部門內部創造 DevOps 環境非常困難。這就是為什麼文化堆疊如此重要。 我們無法簡單地在一組現有的層次結構和穀倉中實施 DevOps，並期望它會有效並實現預期的影響。
DevOps 需要正確的組織文化和正確的領導才能真正有效。 它還需要發展自主、自治的團隊。
組織架構
傳統的組織架構包含是垂直型與矩陣型。大型企業的第一次嘗試著重於垂直組織。 人類遠古部落生活是圍繞著一個明確的領導者或領導者群體組織起來。
這種類型的組織足以過著相對和平的日常生活，但是當我們需要完成重大任務時，例如攻擊其他部落或保衛我們自己的部落，我們就會考慮更多類似軍事的結構非常有等級制度。這種架構可以很好地馴服混亂的環境，但它非常被動，並且專注於短期目標，而將長期策略目標留給其他人。 這種垂直結構的缺點是其不可避免的會有穀倉效應。
第二種是矩陣結構 — 接下來是垂直結構的一個分支，即矩陣組織。 這是透過在水平基礎上引入額外的報告責任來克服垂直架構造成的穀倉效應。
特定的基層人員對「指揮鏈」負責，並對他們的教練、導師或技術領域領導者負責，從而使基層人員成為「兩個主人的僕人」。當「二當家」要求的優先事項相互衝突時會發生什麼？ 誰說了算？
過去，這些模型似乎適用於 IT。可依需求透過優化穀倉的量能。 技術知識也可以在整個穀倉層次結構中共享。 可以由老鳥指導菜鳥， 它讓R&R變動、預算責任和快速責任分配，因為如果在特定技術領域出現任何問題，每個人都知道該怪誰。
垂直和矩陣架構的一些缺點正變得越來越明顯。 垂直運營的模型不太能夠管理來自不同來源（例如業務應用程式和使用者）的資訊。 每個單獨的業務計劃都需要所有部門的參與。 當需要跨穀倉進行協調時，這些架構對業務需求的反應較慢，且穀倉之間的大量業務傳遞會造成浪費。
產品結構是組織演變的下一階段。 在許多方面，它只是垂直結構的旋轉，所有忠誠度、衡量標準或風險、獎勵等都集中在產品周圍。
產品線架構的終極目的是擊敗競爭對手，即使在同一家公司內，並按目標進行管理。它仍然是命令和控制，但更多的是精英管理和獎勵、責任和創新。它往往側重於以本地產品為導向的最佳化。
最後一個是自我適應架構 — 這是 DevOps 所倡導的，也是下一階段可觀察進化的趨勢。 在自我適應性組織中，重點聚焦於文化、授權和員工激勵。它重視全域最佳化而不是局部快速修復。 它是關於利害關係人，而不是股東，它就像一個家庭。
適應性組織中的領導者會制定清晰的願景和使命，然後“讓開”，讓員工弄清楚如何實現它。適應性團隊是自主的、自我激勵的、自我組織的。
甚麼樣的DevOps架構是無效的
雖然很多人或組織經常使用「DevOps 團隊」這個術語，但簡單地在維運和開發之間創建另一個功能孤島是存在危險的。 DevOps 不一定只是特定類型的團隊。相反，DevOps 是一場徹底重新思考團隊的運動。這不僅僅是建立一支「從事 DevOps」的團隊。因此，DevOps 並沒有規定「DevOps 團隊」應該是什麼樣子。 相反，DevOps 擁抱各種模式和潛在結構，以實現正確的文化、實踐和技術。
適合每個組織的理想組織架構取決於許多變數。在我們討論「什麼樣的架構和時間點適用於 DevOps」之前，了解有關 DevOps 以及架構和團隊的誤解非常重要。 回顧建立 DevOps 團隊或嘗試實作 DevOps 時最常見的一些錯誤。
如上圖，首先是 DevOps 團隊穀倉。 當有人決定組織需要 DevOps 並組建「DevOps 團隊」而不了解完整堆疊時，就會出現問題，特別是實施 DevOps 所需的文化變革。 如果沒有正確的文化和領導力，這個團隊只會形成另一個穀倉，使開發和維運更加分離。
第二個是DevOps 不需要運維，因為雲端技術可以滿足需求，開發假設維運已經不合時宜了，開發團隊沒有認識到維運技能和專業知識的重要性。 這種態度在開發和維運之間造成了進一步的問題。
第三種是＂DevOps 只是一個工具團隊＂ — 我們可以概述 DevOps 和工具團隊。 因此，開發團隊內部成立了一個團隊來開發與部署流水線、配置管理等相關的工具。這種方法可能有好處，但 DevOps 作為工具團隊繼續將事情「扔到牆外」給維運，而開發和維運之間的溝通和協作的基本問題仍然沒有得到解決。
最後一個是 DevOps 工程師 — 如果組織未能將 IT 視為商業價值，他們可能會決定“實施 DevOps”並聘請“DevOps 工程師”，而不是解決當前文化、流程和技術中的差距。這種方法只是代表把系統管理員這個職缺改為 DevOps而已，而根本問題仍未解決。
有效的DevOps架構
加強開發和維運之間的協作至關重要。 在協作結構中，每個團隊在需要時進行專業化和共享。
Infra as a Service — 在有非常傳統的 IT 維運部門的組織中，將維運視為Infra as a Service也可能是實施 DevOps 的有效方法。這種方法涉及將維運視為一個提供部署和運行應用程式的基礎設施的團隊，並將開發中的團隊視為有關維運功能、指標等的專業知識來源。
臨時性DevOps 團隊是很常見 — 該團隊是針對特定時期而創建的，旨在使開發和維運更加緊密地結合在一起。這個團隊最終會解散，從而避免「DevOps 團隊」成為另一個穀倉的問題。 有了這樣的結構，臨時團隊的成員可以充當橋樑，向每個團隊引入新的想法，並幫助其更好地與其他團隊融合。
這些只是實施 DevOps 時可以考慮的幾種結構和團隊類型。DevOps 的最終的理想目標 — — 是讓團隊完全脫離開發和維運。
團隊的演化
DevOps 團隊的演進分三個階段進行。
DevOps 團隊演進的第一階段涉及簡單地引入變更或新方法，以增強開發和維運之間的協作。在此階段，開發和維運職能一旦確立，就會部署以建立緊密聯繫和高度協作的團隊，並為相同目標並肩工作。
一些組織採取「you build it, you run it」的方法，使開發人員更加負責在生產環境中運作他們的應用程式。這種方法有助於兩個團隊了解彼此的需求，並進一步打破穀倉心態。
DevOps 團隊演進的第二階段涉及組建專門的 DevOps 團隊，該團隊的實施方式不鼓勵其作為另一個穀倉的存在。 通常，在這個階段，目標是建立一個 DevOps 團隊，並在第三階段繼續發展它。
DevOps 團隊結構演進的第三階段涉及重新組織開發和維運以形成跨職能團隊。 跨職能團隊由負責開發和部署服務的所有專門知識的代表組成。他們被設計能被授權、自我管理和自給自足。這些團隊可能是臨時的，並且只為了短期專案而組成。
然而，它們也可能是永久性的。最重要的是，這些團隊類似於適應性、自組織團隊。 當工作是圍繞著任務或角色設計時，就會出現功能障礙。 任務導向會導致穀倉，也會導致局部最佳化並阻礙系統性思考。它也阻礙了創造力並鼓勵人們只專注於任務執行。
由於任務導向，工作變得單調乏味。 此外，由於任務導向，每個人變得根深蒂固於某一專業領域。 任務導向鼓勵領導者進行微觀管理和囤積資訊。 微觀管理導致缺乏對關係和創新的關注。
此外，任務導向促進了一種完成任務而不關心其他任何事情的態度。它也促進了一種指責文化。 為了解決這些問題，領導者需要確保建立跨職能團隊。
領導者在建立跨職能團隊時會考慮一些重要標準，領導者會平衡領域知識。 跨職能團隊的一個關鍵效益是它擁有來自不同業務部門或客戶領域的代表，這是完成迭代所需要的。 跨職能團隊旨在涵蓋所有必要的專業學科。 在跨職能團隊中，重要的是擁有從構思到實施迭代的所有必要技能的人員。
團隊應包括功能性和非功能性領域的專業知識，這種方法減少了作業傳遞和對詳細文件的需求。領導者根據團隊規模平衡技術技能水準，高階和初階角色混合存在，以支持指導、發展和適當工作的分配。
領導者也尋求多樣性，多元化可以意味著許多不同的事情 — — 性別、種族和文化，而不僅僅是其中的三者。也許，同樣重要的是個人如何思考問題、如何做出決定、在做出決定之前需要多少資訊等等。
領導者也認為堅持很重要，因為組建和發展高效團隊需要時間。因此，他們承認有必要盡可能讓合作良好的團隊成員留在同一個團隊中。
現在，審查是通才和純粹專家之間的區別，而 DevOps 團隊需要平衡兩者的方式，建立跨職能團隊可能是一個挑戰，因為它需要一定程度的實際專業化。通才可能不具備與特定任務或要求相關的足夠知識或技能，而純粹的專家可能很難被要求從事其專業以外的工作並接受新的挑戰。
DevOps 團隊在圍繞產品或平台而不是特定功能創建時效果最佳。產品和平台團隊需要跨職能技能。他們對每個人的要求更高，但他們允許人們致力於更少的專案並完成它們，或在整個生命週期中負責。
產品和平台團隊透過授予團隊成員自主權和認可廣泛的技能來進一步減少業務傳遞、鼓勵回饋、激勵和啟發團隊成員， 這解決了任務導向的問題。
我們在這裡檢視一下 DevOps 產品和平台團隊的基本架構。 為了方便我們進行初步分析，以下是 DevOps 產品和平台團隊架構的範例。
在頂層，客戶現在直接與過去的開發團隊進行互動 — — 產品團隊現在在整個生命週期中擁有產品。開發團隊專注於透過交付軟體來交付商業價值。 產品團隊使用先前由維運部門提供的平台服務來開發、運行和維護其應用程式。
平台團隊和產品團隊繼續負責生產中應用程式的維護。平台團隊不對應用程式負責，他們只負責提供平台服務。產品團隊所使用的所有環境都代表平台團隊的生產環境。平台團隊的客戶是產品團隊，平台團隊應該支持和協助產品團隊。而產品團隊與最終使用者（即客戶）互動。
這種方法是 DevOps 中團隊合作的最終演變，它支援持續交付，並在業務所需的速度和敏捷性之間提供最佳平衡。
只有當我們真正理解Full Stack時，這個概念才可以實現 — — 它整合人員和文化、流程和實踐以及技術和自動化的方式。
