「如何實施 DevOps」這個問題已經存在很多年了，但是好的材料並不多。有時，您會成為不太聰明的顧問的廣告的受害者，他們無論如何都需要出售自己的時間。有時，這些是關於巨型企業的船隻如何在宇宙中航行的模糊且極其籠統的詞語。問題出現了：這對我們來說有什麼關係？親愛的作者，您能在清單中清楚表達您的想法嗎？
這一切都源自於對企業文化轉型成果沒有累積多少真正的實踐與理解。文化的改變是長期的事情，其結果不會在一週或一個月內顯現出來。我們需要一個足夠老的人來見證這些年來公司是如何建立和失敗的。
約翰威利斯 - DevOps 之父之一。約翰擁有數十年與許多公司合作的經驗。最近，約翰開始注意到與他們每個人一起工作時發生的特定模式。利用這些原型，John 引導公司走上 DevOps 轉型的真正道路。請閱讀他在 DevOops 2018 會議上的報告翻譯，以了解有關這些原型的更多資訊。
關於演講者：
擁有超過 35 年的 IT 管理經驗，參與了 Canonical OpenCloud 前身的創建，參與過 10 家新創公司，其中兩家被出售給 Dell 和 Docker。目前，他是 SJ Technologies 的開發營運和數位實踐副總裁。
接下來是約翰視角的故事。
我的名字是 John Willis，最容易找到我的地方是 Twitter， 。我在 Gmail 和 GitHub 上有相同的別名。 A 您可以找到我為他們所做的報告和演示的視頻記錄。
我與各大公司的資訊長進行了多次會議。他們經常抱怨他們不明白 DevOps 是什麼，而每個試圖向他們解釋的人都在談論不同的事情。另一個常見的抱怨是 DevOps 不起作用，儘管看起來董事們正在按照向他們解釋的方式做所有事情。我們談論的是已有一百多年歷史的大公司。與他們交談後，我得出的結論是，對於許多問題來說，最適合的不是高科技，而是技術含量相對較低的解決方案。幾週來我一直在和不同部門的人交談。您在帖子的第一張圖片中看到的是我的最後一個項目，這是工作三天後房間的樣子。
什麼是 DevOps？
事實上，如果你問 10 個不同的人，他們會給 10 個不同的答案。但有趣的是：這十個答案都是正確的。這裡沒有錯誤的答案。我對 DevOps 非常深入，大約有 10 年了，並且是第一個 DevOpsDay 的第一個美國人。我不會說我比所有參與 DevOps 的人都聰明，但幾乎沒有人在這方面付出了那麼多的努力。我相信，當人力資本和技術結合在一起時，DevOps 就會出現。儘管我們經常談論各種文化，但我們經常忘記人的維度。
現在我們有大量的數據、五年的學術研究、工業規模的理論檢驗。這些研究告訴我們，如果將一些行為模式結合到組織文化中，可以達到 2000 倍的加速。這種加速與穩定性的同等提高相匹配。這是對 DevOps 可以為任何公司帶來的好處的定量衡量。幾年前，我向一家財富5000強公司的CEO談論DevOps，當我準備演講時，我非常緊張，因為我必須在5分鐘內總結我多年的經驗。
最後我給了以下內容 DevOps 的定義：它是一套能夠將人力資本轉化為高績效組織資本的實踐和模式。豐田過去 50 或 60 年來的運作方式就是一個例子。
（以下提供的此類圖表不是作為參考資料，而是作為說明。每個新公司的內容都會有所不同。但是，可以單獨查看圖片並放大
最成功的此類做法之一是 價值流圖。關於這一點已經寫了幾本好書，其中最成功的是凱倫馬丁 (Karen Martin) 寫的。但在過去的一年裡，我得出的結論是，即使這種方法也太高科技了。它確實有很多優點，而且我已經用過很多次了。但是，當執行長問你為什麼他的公司不能轉向新的軌道時，現在談論價值流圖還為時過早。有許多更基本的問題必須先得到回答。
我認為我的許多同事犯的錯誤是，他們只是給公司提供了五點指導，然後六個月後回來看看發生了什麼。即使是像價值流圖這樣的好方案也有盲點。在與不同公司的董事進行了數百次訪談之後，我開發了一種特定的模式，使我們能夠將問題分解為各個組成部分，現在我們將按順序討論每個組成部分。在應用任何技術解決方案之前，我都會使用這種模式，因此，我所有的牆上都貼滿了圖表。最近我與一家共同基金合作，最終制定了 100-150 個這樣的計劃。
壞文化吃好早餐
主要想法是：如果組織文化本身很糟糕，再多的精實、敏捷、SAFE 和 DevOps 也無濟於事。這就像在沒有潛水裝備的情況下潛入深處或在沒有 X 光的情況下進行操作一樣。換句話說，套用德魯克和戴明的話說：糟糕的組織文化會吞噬任何好的系統而不至於窒息。
為了解決這個主要問題，您需要採取以下步驟：
- 讓所有工作可見： 你需要讓所有的工作都可見。並不是說它必須顯示在某個螢幕上，而是說它必須是可觀察的。
- 綜合工作管理系統： 管理體系需要整合。在「部落」知識和製度知識問題上，十分之九的瓶頸是人。在書裡 問題出在一個人身上，布倫特，他導致這個計畫比計畫晚了三年。我到處都會遇到這些「布倫特」。為了解決這些瓶頸，我使用了清單中的接下來兩項。
- 約束方法論理論： 約束理論。
- 協作技巧： 協作駭客。
- 豐田卡塔（): 關於豐田 Kata 我就不多說了。有興趣的話可以在我的github上 幾乎涵蓋了所有這些主題。
- 市場導向的組織： 市場導向的組織。
- 左移審核員： 在周期的早期階段進行審計。
我開始與一個組織合作非常簡單：我去公司並與員工交談。正如你所看到的，沒有高科技。您所需要的只是可以寫的東西。我將幾個團隊聚集在一個房間裡，從我的 7 個原型的角度分析他們告訴我的內容。然後我給他們自己一個記號筆，並要求他們在黑板上寫下到目前為止他們大聲說出的所有內容。通常在這類會議中，會有一個人把所有內容都寫下來，最多只能寫下 10% 的討論內容。按照我的方法，這個數字可以提高到40%左右。
（此圖可單獨查看 )
我的方法是基於威廉·施耐德的工作。 ）。這個方法基於這樣的想法：任何組織都可以分為四個方格。對我來說，這個方案通常是與分析組織時出現的數百個其他方案一起工作的結果。假設我們有一個控制水準較高但能力較低的組織。這是一個極不可取的選擇：每個人都聽話，但沒人知道該怎麼做。
更好的選擇是具有高水平控制力和能力的選擇。如果這樣的公司能夠獲利，那麼也許它就不需要 DevOps。與一家控制水平高、能力和合作水平低、但同時文化（修養）水平高的公司合作是最有趣的。這意味著該公司有很多喜歡在那裡工作的人，而且勞動力流動率很低。
（此圖可單獨查看 )
在我看來，具有嚴格指導方針的方法最終會妨礙實現真理。特別是在價值流圖中，有許多關於如何建構資訊的規則。在我現在所說的工作的早期階段，沒有人需要這些規則。如果一個手裡拿著記號筆的人在黑板上描述了公司的真實情況，這就是了解情況的最佳方法。此類資訊不會傳達給董事。此時此刻，打斷對方並說他畫錯了某種箭頭是愚蠢的。在這個階段，最好使用簡單的規則，例如：可以透過使用多色標記簡單地建立多層抽象。
我再說一遍，沒有高科技。黑色標記描繪了一切如何運作的客觀現實。人們用紅色標記標記出他們不喜歡當前事態的地方。重要的是他們寫的，而不是我。當我在會議結束後去找 CIO 時，我不會列出需要解決的 10 件事。我努力尋找公司人員所說的話與現有的經過驗證的模式之間的連結。最後，藍色標記建議了問題的可能解決方案。
（此圖可單獨查看 )
上面描述了這種方法的一個例子。今年年初，我在銀行工作。那裡的安全人員確信他們不應該參與設計和需求審查。
（此圖可單獨查看 )
然後我們與其他部門的人交談，結果發現大約 8 年前，軟體開發人員解雇了安全人員，因為他們拖慢了工作速度。然後就變成了禁令，這是理所當然的。雖然實際上並沒有禁令。
我們的會議以一種極其混亂的方式進行：大約三個小時，五個不同的團隊無法向我解釋程式碼和程序集之間發生了什麼。這似乎是最簡單的事。大多數 DevOps 顧問預先假設每個人都已經知道這一點。
然後沉默了四個小時的IT治理負責人在我們談到他的話題時突然活躍起來，佔據了我們很長一段時間。最後我問他對這次會議的看法，我永遠不會忘記他的回答。他說：“我以前以為我們銀行只有兩種交付軟體的方式，但現在我知道有五種，我什至不知道三種。”
（此圖可單獨查看 )
該銀行的最後一次會議是與投資軟體團隊舉行的。正是和她一起，事實證明用記號筆在紙上寫圖表比在黑板上寫圖表更好，甚至比在智慧板上寫圖表更好。
您看到的照片是我們會議第四天的飯店會議室的樣子。我們使用這些方案來搜尋模式，即原型。
所以，我問工人問題，他們用三種顏色（黑、紅、藍）的記號筆寫下答案。我分析了他們的答案的原型。現在讓我們按順序討論所有原型。
1. 讓所有工作可見：讓工作可見
我工作過的大多數公司都有很高比例的未知工作。例如，一名員工來到另一名員工面前，只是要求做某件事。在大型組織中，可能有 60% 的工作是計劃外的。高達 40% 的工作沒有以任何方式記錄。如果是波音，我這輩子都不會再登上他們的飛機了。如果只記錄了一半的工作，那麼就無法知道這項工作是否正確完成。所有其他方法都被證明是無用的- 嘗試自動化任何東西是沒有意義的，因為已知的50% 可能是工作中最連貫和清晰的部分，其自動化不會產生很好的結果，而且是最糟糕的事物都處於看不見的一半。在沒有文件的情況下，不可能找到各種駭客行為和隱藏的工作，更不可能找到瓶頸，也就是我已經討論過的那些「Brents」。多明尼加·德格蘭迪斯有一本很棒的書 。她透露 五種不同的“時間洩漏” （時間的竊賊）：
- 在製品 (WIP) 過多
- 未知的依賴關係
- 計劃外的工作
- 優先事項相互衝突
- 被忽視的工作
這是非常有價值的分析，這本書也很棒，但如果只有 50% 的數據可見，那麼所有這些建議都是毫無用處的。如果準確率達到90%以上，則可以使用多明尼加提出的方法。我說的是這樣的情況：老闆給下屬一個15分鐘的任務，但他花了三天；但老闆其實不知道這個下屬還要依賴其他四、五個人。
鳳凰計劃是一個關於一個晚了三年的項目的精彩故事。其中一個角色因此面臨被解僱，他遇到了另一個被描繪成蘇格拉底的角色。他幫忙找出到底出了什麼問題。原來，公司有一位系統管理員，名叫布倫特，所有的工作都透過他進行。在一次會議上，一位下屬被問到：為什麼每個半小時的任務要花一週的時間？答案是排隊理論和利特爾定律的一個非常簡單的演示，在這個演示中，事實證明，在 90% 的佔用率下，每個小時的工作需要 9 個小時。每個任務都需要發送給另外七個人，這樣一小時就變成了 63 小時，7 乘以 9。我的意思是，為了使用利特爾定律或任何複雜的排隊論，你至少需要有數據。
因此，當我談論可見性時，我並不是指所有內容都在螢幕上，而是指您至少擁有數據。當他們這樣做時，往往會發現有大量計劃外的工作在不需要的時候以某種方式被發送到布倫特。布倫特是一個很棒的人，他永遠不會說不，但他不會告訴任何人他是如何做他的工作的。
當工作可見時，可以將資料整齊地分類（這就是多米尼卡在照片中所做的事情），可以應用五次洩漏的抽象，並且可以應用自動化。
2. 整合工作管理系統：任務管理
我所說的原型是一種金字塔。如果第一個做得正確，那麼第二個就已經是一種附加元件了。其中許多不適用於新創公司，對於財富 5000 強等大型公司來說，需要牢記它們。我工作的上一家公司有 10 個票務系統。一個團隊使用 Remedy，另一個團隊編寫了某種自己的系統，第三個團隊使用 Jira，還有一些團隊使用電子郵件。如果公司有 30 條不同的管道，也會出現同樣的問題，但我沒有時間討論所有此類情況。
我與人們討論門票是如何創建的，接下來會發生什麼，以及如何規避它們。最有趣的是，我們會議上的人們說話都很真誠。我問有多少人對實際上應該給予“重大影響”的門票提出“輕微/無影響”。事實證明，幾乎每個人都這樣做。我不參與譴責，也盡量不去指名道姓。當他們真誠地向我坦白某件事時，我不會洩漏這個人。但當幾乎每個人都繞過該系統時，這意味著所有安全措施本質上都是門面。因此，無法從該系統的數據得出任何結論。
要解決票務問題，您需要選擇一個主系統。如果您使用 Jira，請保留 Jira。如果有任何選擇，那就讓它成為唯一的選擇。最重要的是，門票應該被視為開發過程中的另一個步驟。每個操作都必須有一個票證，該票證必須貫穿開發工作流程。票證被發送給團隊，團隊將其發佈在故事板上，然後對其負責。
這適用於所有部門，包括基礎設施和營運部門。在這種情況下，至少可以對事態形成一些看似合理的想法。一旦建立了這個流程，就可以輕鬆地確定誰負責每個應用程式。因為現在我們收到的新服務不是 50%，而是 98%。如果這個核心流程有效，那麼整個系統的準確性就會提高。
服務管道
這同樣只適用於大公司。如果您是新領域的新公司，請捲起袖子，使用 Travis CI 或 CircleCI 進行工作。說到世界5000大企業，我工作的銀行就是一個很好的例子。 Google 找到了他們，並向他們展示了舊 IBM 系統的圖表。谷歌的人困惑地問──這個的源碼在哪裡？但沒有原始碼，甚至沒有 GUI。這是大型組織必須面對的現實：古老的大型主機上有 40 年歷史的銀行記錄。我的一位客戶使用具有斷路器模式的 Kubernetes 容器以及 Chaos Monkey，所有這些都用於 KeyBank 應用程式。但這些容器最終連接到 COBOL 應用程式。
Google 的人完全有信心他們會解決我客戶的所有問題，然後他們開始問問題：什麼是 IBM datapipe？他們被告知：這是一個連接器。它連接到什麼？到斯佩里系統。那是什麼？等等。乍看：能有什麼樣的DevOps？但事實上，這是可能的。有些交付系統可讓您將工作流程移交給交付團隊。
3.約束理論：約束理論
讓我們繼續討論第三個原型：制度/「部落」知識。一般來說，在任何組織中都有幾個人知道一切並管理一切。這些人在組織中任職時間最長，並且了解所有解決方法。
當圖表上出現這種情況時，我特意用標記圈出了這些人：例如，事實證明某個盧出席了所有會議。我很清楚：這是當地的布蘭特原油。當 CIO 在穿 T 恤和運動鞋的我和穿西裝的 IBM 人員之間進行選擇時，我被選中是因為我可以告訴主管一些其他人不會告訴的事情，而主管可能不喜歡聽。我告訴他們，他們公司的瓶頸是一個叫弗雷德和一個叫盧的人。這個瓶頸需要被解開，他們的知識需要以某種方式從他們身上獲得。
為了解決這類問題，我可以建議使用 Slack。聰明的導演會問──為什麼？通常，在這種情況下，DevOps 顧問會回答：因為每個人都在這樣做。如果導演真的聰明的話，他會說：那又怎樣。對話到此結束。我對此的回答是：因為公司有四個瓶頸，Fred、Lou、Susie 和 Jane。為了將他們的知識制度化，必須先引入 Slack。你們所有的維基百科都是胡說八道，因為沒有人知道它們的存在。如果工程團隊涉及前後端開發，大家都需要知道，有問題可以聯絡前端開發團隊或基礎建設團隊。那時 Lou 或 Fred 可能有時間加入 wiki。然後在 Slack 中，有人可能會問為什麼，比如說，步驟 5 不起作用。然後 Lou 或 Fred 會更正 wiki 上的說明。如果你建立了這個過程，那麼很多事情就會自行水到渠成。
這是我的要點：要推薦任何高科技，你必須先把它們的基礎打好，這可以透過剛才描述的低技術解決方案來完成。如果你從高科技開始，而不解釋為什麼需要它們，那麼，通常，結果不會好。我們的一個客戶使用 Azure ML，這是一個非常便宜且簡單的解決方案。自學習機本身回答了大約 30% 的問題。而且這個東西是不涉及數據科學、統計學或數學的操作人員寫的。這很重要。這種解決方案的成本是最低的。
4. 協作技巧：協作技巧
第四個原型是對抗孤立的需要。大多數人已經知道這一點：孤立會滋生敵意。如果每個部門都在自己的樓層，除了電梯之外，人們之間沒有任何交集，那麼他們之間很容易產生敵意。但相反，如果人們彼此共處一個房間，她就會立刻離開。當有人拋出一些籠統的指責時，例如，某某介面永遠無法運作，沒有什麼比這更容易解構這樣的指責了。編寫介面的程式設計師只需要開始提出具體問題，很快就會發現，例如，使用者只是錯誤地使用了該工具。
有很多方法可以克服孤立。曾經有人請我為澳洲的一家銀行提供諮詢，但我拒絕了，因為我有兩個孩子和一個妻子。我所能做的就是向他們推薦圖形化的故事敘述方式。這是被證明有效的方法。另一種有趣的方式是精益咖啡會議。在大型組織中，這是傳播知識的絕佳選擇。此外，您還可以舉辦內部開發日、黑客馬拉松等。
5. 教練卡塔
正如我一開始就警告過的，今天我不會談論這個。如果您有興趣，可以看一下 .
Mike Rother 關於這個主題也有一篇很好的演講：
6.市場導向：以市場為導向的組織
這裡有不同的問題。例如「I」人、「T」人、「E」人。 「我」的人是那些只做一件事的人。通常，它們存在於具有孤立部門的組織中。 「T」是指一個人擅長一件事，同時也擅長其他一些事情。 「E」甚至「comb」表示一個人擁有多種技能。
康威定律在這裡起作用（），最簡單的形式可以表述如下：如果三個團隊致力於編譯器，那麼結果將會是一個由三個部分組成的編譯器。因此，如果一個組織內部有高度的隔離，那麼即使這個組織中的 Kubernetes、Circuit Breaker、API 擴充性等花俏的東西也會按照組織本身的方式來安排。嚴格按照康威的說法，也是為了刁難你們這些年輕的極客。
該問題的解決方案已被描述過多次。例如，費爾南多·費爾南德斯描述了組織原型。我剛才講的那個有問題的架構，加上隔離，就是一個功能導向的架構。第二種是最糟糕的，矩陣架構，是其他兩種的混亂。第三種是大多數新創公司所見，大公司也在嘗試匹配這種類型。它是一個以市場為導向的組織。在這裡，我們進行最佳化以實現對客戶請求的最快回應。這有時被稱為扁平組織。
很多人以不同的方式描述這個結構，我喜歡這樣的措詞 建立/運作團隊，在亞馬遜他們稱之為 兩個披薩隊。在這種結構中，所有「I」型人都圍繞著一種服務聚集在一起，逐漸向「T」型人靠攏，如果管理到位，甚至可以成為「E」型人。這裡的第一個反駁是，這樣的結構有不必要的元素。如果可以有一個專門的測試人員部門，為什麼每個部門都需要一名測試人員？我的回答是：這種情況下的額外成本是整個組織未來成為「E」型的代價。在這個架構中，測試人員逐漸了解網路、架構、設計等。因此，組織中的每個參與者都充分了解組織中發生的一切。如果您想了解方案在工業中的運作方式，請閱讀 .
7. 左移審核員：在周期的早期進行審核。遵守展示的安全規則
可以這麼說，這是當你的行為沒有通過氣味測試時。為你工作的人並不傻。如果像上面的例子一樣，他們在各處設置了輕微/無影響，持續了三年，沒有人注意到任何事情，那麼每個人都清楚地知道該系統不起作用。或另一個例子 - 變更諮詢委員會，需要每週（例如週三）提交報告。有一群人在那裡工作（順便說一句，工資不是很高），從理論上講，他們應該知道整個系統是如何運作的。在過去的五年裡，您可能已經注意到我們的系統非常複雜。五、六個人必須就一項他們沒有做出且他們一無所知的改變做出決定。
當然，這種方法是行不通的。我必須擺脫這些東西，因為這些人沒有保護系統。決定必須由團隊自己做出，因為團隊必須為此負責。否則，當一個一生中從未寫過程式碼的經理告訴程式設計師應該花多長時間寫程式碼時，就會出現矛盾的情況。我工作過的一家公司有 7 個不同的委員會來審查每項變更，包括架構委員會、產品委員會等。甚至還有一個強制性的等待期，儘管一位員工告訴我，在十年的工作中，沒有人拒絕過這個人在這個強制性的時期所做的改變。
需要邀請審核員加入我們，而不是解僱他們。告訴他們您編寫了不可變的二進位容器，如果它們通過了所有測試，則永遠保持不可變。告訴他們您有一個管道即代碼並解釋這意味著什麼。向他們展示以下方案：通過所有漏洞測試的容器中的不可變只讀二進位；然後不僅沒有人接觸它，他們甚至沒有接觸創建管道的系統，因為它也是動態創建的。我的客戶 Capital One 正在使用 Vault 來創建類似區塊鏈的東西。審核員不需要展示Chef的「食譜」；展示區塊鏈就足夠了，從中可以清楚生產中的Jira票據發生了什麼以及誰對此負責。
根據 由 Sonatype 在 2018 年創建，2017 年有 87 億個 OSS 下載請求。
由於漏洞而造成的損失是驚人的。此外，您現在看到的上面的數字不包括機會成本。簡而言之，DevSecOps 是什麼？我馬上說，我沒有興趣談論這個名字有多成功。關鍵是，既然 DevOps 如此成功，我們應該嘗試增加該管道的安全性。
此序列的範例：
儘管我喜歡所有產品，但這並不是針對特定產品的推薦。我引用它們作為例子是為了說明DevOps最初是基於工業界的組織範式，它允許你將產品的每個階段的工作自動化。
我們沒有理由不採取同樣的安全方法。
總
作為結論，我將給出一些 DevSecOps 的技巧。您需要讓審核員參與創建系統的過程，並花時間教育他們。您需要與審核員合作。接下來，您需要對誤報進行絕對無情的打擊。即使使用最昂貴的漏洞掃描工具，如果您不知道信噪比是多少，您最終也可能會在開發人員中養成極其壞的習慣。開發人員會對事件感到不知所措，並會簡單地刪除它們。如果你聽過 Equifax 的故事，那幾乎就是那裡發生的事情，最高警報等級被忽略了。此外，需要以明確的方式解釋漏洞，以明確它們如何影響業務。例如，您可以說這與 Equifax 故事中的漏洞相同。安全漏洞應該像其他軟體問題一樣對待，也就是說，它們應該包含在整個 DevOps 流程中。您需要透過 Jira、看板等與他們合作。開發人員不應該認為其他人會這樣做——相反，每個人都應該這樣做。最後，你需要花精力去培訓人才。
有用的鏈接
以下是 DevOops 會議上的一些演講，您可能會覺得有用：
- Sergey Berdnikov、Artyom Kalichkin - 成功故事，或「Dev+DevOps+Ops」（, )
- Baruch Sadogursky、Leonid Igolnik - 大規模的 DevOps：三幕希臘悲劇（, )
- 亞歷山大·蒂托夫、基里爾·托爾卡喬夫 -
- 提摩西李斯特 -
看一眼 DevOops 2020 莫斯科 ——那裡還有很多有趣的事。
來源： www.habr.com