與 Jeff Smith 一起粉碎播客第 42 集：什麼是 DevOps？

在本集中，我們將討論 DevOps。 它是什麼，它是添加到您的 Web 開發弓的字符串嗎？ 德魯麥克萊倫與專家傑夫史密斯交談以找出答案。

顯示註釋

• 傑夫在推特上
• Jeff 的書運維反模式，DevOps 解決方案
• 可實現的 DevOps

每週更新

• 彌合設計師和開發人員之間的鴻溝，作者：Matthew Talebi
• Gaurav Khanna 編寫的用於使用 TypeScript 構建靈活組件的有用 React API
• Cosima Mielke 編寫的針對常見 UI 挑戰的智能 CSS 解決方案
• Nataliya Samir 撰寫的評估 UX/UI 設計師的提示和技巧
• 在由 Arijit Mondal 編寫的 Next.js 支持的電子商務網站中解決 CLS 問題

成績單

Drew McLellan：他是一名 DevOps 實踐者，專注於 DevOps 實施的可達到水平，無論您處於旅程的哪個階段。 他是數字廣告平台 Centro 的生產運營總監，同時也是一名公開演講者，與全球觀眾分享他的 DevOps 知識。 他是《Operations Anti-Patterns, DevOps Solutions for Manning Publishing》一書的作者，該書展示瞭如何在大多數開發人員工作的那種不完美的環境中實施 DevOps 技術。所以我們知道他是 DevOps 方面的專家，但你認識 George克魯尼認為他是一代人最好的紙飛機製造商？ 我的 Smashing 朋友，請歡迎 Jeff Smith。 嗨傑夫。 你好嗎？

傑夫·史密斯：德魯，我太棒了，你好嗎？

德魯：我很好。 謝謝你。 聽起來還不錯。 所以我今天想和你談談 DevOps 的主題，這是你的主要關鍵領域之一。 我們的許多聽眾將參與 Web 和應用程序開發，但可能只對操作方面發生的事情不太熟悉。 我知道我們這些可能在大公司工作的人會有整個團隊在做運營。 我們很感激，無論他們做什麼，他們都做得很好。 但是我們聽到越來越多的 DevOps 被提及，感覺就像是開發人員應該真正理解的事情之一。 那麼 Jeff，什麼是 DevOps？

Jeff：所以如果你問 20 個人甚麼是 DevOps，你可能會得到 20 個不同的答案。 所以我會告訴你我的看法，好吧，並且知道如果你在一個會議上提到這個，你可能會和某人打架。 但對我來說，DevOps 真的是關於兩者之間的關係，我們專注於開發和運營，但實際上是團隊間的關係以及我們如何構建我們的工作，更重要的是，構建我們的目標和激勵機制以確保它們是一致，以便我們朝著共同的目標努力。 DevOps 的許多核心思想和概念都來自舊世界，在舊世界中，dev 和 ops 一直是對抗性的，那裡存在著不斷的衝突。 當你考慮到這一點時，這是因為這兩支球隊的激勵方式。 一個團隊被激勵推動變革。 另一個團隊被激勵保持穩定性，這意味著更少的變化。

傑夫：當你這樣做時，你就會產生這種固有的衝突，一切都會從那裡溢出來。 因此，DevOps 真正是為了使這些團隊和目標保持一致，以便我們朝著共同的戰略努力，但同時也採用雙方的實踐，以便開發人員更多地了解運維，運維人員更多地了解開發，以此作為獲取和分享的一種方式彼此同理心，以便我們了解對方來自何處的觀點。

傑夫：但同時也是為了加強我們的工作。 因為再一次，如果我理解你的觀點並在我的工作中考慮到這一點，這對我們每個人都會更有利。 在自動化方面，運維人員可以從開發人員那裡學到很多東西，以及我們如何處理事情以使它們易於重現。 所以就是這種融合和技巧。 你現在看到的是這適用於不同的組組合，所以你聽到的是 DevSecOps、DevSecFinOps、DevSecFinHROps 之類的東西。 它只會繼續增長、增長和增長。 因此，這確實是一個我們可以在整個組織中消除的教訓。

Drew：因此，它採用了我們作為開發人員所理解的一些概念，並將我們的想法進一步傳播到組織中，同時從運營中學習我們可以做些什麼來嘗試推動每個人前進。

傑夫：當然，是的。 運維的另一個方面，你在介紹中提到了一點，我們認為這只是針對這些擁有專門運維團隊的大型組織和類似的東西，但要考慮的一件事是運維正在你的組織中發生，無論大小。 這只是你在做的問題，或者是否有一個單獨的團隊在做，但不知何故你正在部署代碼。 不知何故，您有一台服務器在某處運行。 因此，無論規模大小，運營都存在於您組織的某個地方。 問題是，誰在做？ 如果它是一個人或一個團隊，那麼 DevOps 對你來說甚至可能更加突出，因為你需要了解 ops 所做的事情的類型。

Drew：作為專業的開發人員，您認為掌握 DevOps 是什麼以及實施它的意義對我們來說有多重要？

Jeff：我認為這非常重要，尤其是在 DevOps 旅程的這個階段。 我認為這很重要的原因是，當我們再次了解同行在做什麼時，我認為我們總是更有效率。 但另一件事是能夠在您的設計開發和任何技術的實施過程中考慮運營問題。 因此，我在職業生涯中學到的一件事是，即使我認為開發人員是宇宙的主人，並且了解與計算機有關的一切，但事實並非如此。 事實證明，他們在理解方面將很多事情外包給了運維人員，有時這會導致特定的設計選擇或實施選擇可能不是生產部署的最佳選擇。

傑夫：他們在開發和測試之類的事情上可能還不錯，但是一旦你投入生產，那就有點不同了。 所以並不是說他們需要擁有一整套專業知識，但他們至少需要知道足夠多的知識來知道他們不知道的東西。 所以他們知道何時儘早參與運營，因為這是我們看到的一種常見模式，即開發做出選擇。 我什至不會說做出選擇，因為他們甚至沒有意識到這是一個選擇，但是發生了一些事情導致了對操作的次優決策，而開發人員完全沒有意識到。 因此，只要對 ops 有更多的了解，即使這足以說明，也許我們應該讓 ops 參與進來，以便在我們繼續前進之前了解他們的觀點。 顯然，這可以節省大量時間、精力和穩定性，因為它與您發布的任何產品有關。

Drew：我看到與您談論開發與運營之間的關係的方式有很多相似之處，就像我們在設計與開發之間的關係一樣，您讓設計師研究界面的工作原理和外觀，並有很好的理解開發角色實際上將如何構建，並且讓開發人員參與諮詢可以真正改善整體解決方案，只需進行清晰的溝通和了解彼此的工作即可。 似乎這與 DevOps 的原理相同，真的非常好聽。

Drew：當我想到我聽到的關於 DevOps 的事情時，我會聽到諸如 Kubernetes、Docker、Jenkins、CircleCI 之類的術語。 多年來我一直聽說 Kubernetes。 我仍然不知道它是什麼，但從你所說的來看，DevOps 似乎不僅僅是……我們在這裡不只是在談論工具，是嗎？ 但是更多關於工作流程中的流程和溝通方式，對嗎？

傑夫：當然。 因此，過去 20 年我的口頭禪一直是人員流程工具。 你讓人們接受願景。 從那裡，您可以定義實現該願景的流程。 然後你帶來可以為你的流程建模的工具。 所以我總是把工具放在 DevOps 對話的最後，主要是因為如果你沒有那種支持，那也沒關係。 我可以想出有史以來最偉大的持續部署管道，但是如果人們不接受將每個更改直接交付到生產環境的想法，那也沒關係，對吧？ 工具有什麼用？ 因此，這些工具絕對是對話的一部分，只是因為它們是滿足我們定義的一些共同目標的標準化方式。

Jeff：但是你必須確保那些被定義的目標對你的組織有意義。 也許持續部署對您沒有意義。 也許您不想在每一個更改出現的那一刻就將其發送出去。 並且有很多公司和組織以及您不想這樣做的原因。 所以也許像持續部署管道這樣的東西對你來說沒有意義。 因此，雖然工具很重要，但更重要的是關注將為您的組織帶來價值的東西，然後建模和實施實現這一目標所必需的工具。

Jeff：但是不要上網去了解每個人都在做什麼，哦，好吧，如果我們要做 DevOps，我們必須切換到 Docker 和 Kubernetes，因為那是工具鏈。 不，不是這樣。 你可能不需要這些東西。 不是每個人都是谷歌。 不是每個人都是 Netflix。 停止閱讀 Netflix 和 Google 的帖子。 請停止閱讀它們。 因為它讓人們都很興奮，他們就像，這就是我們要做的。 就像，嗯，他們解決的問題與你遇到的問題截然不同。

德魯：所以如果說我正在開始一個新項目，也許我是一家初創企業，將軟件作為一種服務產品。 我有三個開發人員，我有一個空的 Git 存儲庫，我有 IPO 的夢想。 要完全採用 DevOps 方法來構建這個產品，我應該在人員和流程方面擁有哪些構建塊的名稱，我應該從哪裡開始？

傑夫：所以在你的具體例子中，我首先要開始的是盡可能多地使用它，並使用像 Heroku 這樣的東西或類似的東西。 因為你對所有這些 AWS 的東西、Docker 的東西感到非常興奮，而實際上，僅僅構建一個成功的產品是如此困難。 您專注於其中的 DevOps 部分的想法就像，我會說盡可能多地外包這些東西，直到它真正成為一個痛點。 但如果你在那個時候你說好的，我們已經準備好把這些東西帶入內部，我們已經準備好把它帶到一個新的水平。 我想說首先要開始的是，你的痛點在哪裡？ 是什麼導致了你的問題？

Jeff：所以對某些人來說，這就像自動化測試一樣簡單。 嘿，每次有人提交時我們都需要運行測試的想法，因為有時我們正在運送被我們已經編寫的單元測試捕獲的東西。 那麼也許你從持續集成開始。 也許您的部署需要幾個小時才能完成，而且它們非常手動，那麼這就是您關注的地方，您會說，好吧，我們需要什麼自動化才能使其成為一鍵式點擊事件？ 但我討厭開一個通用的，這是你開始的地方，只是因為你的特定情況和你的特定痛點會有所不同。 問題是，如果這是一個痛點，它應該對你大喊大叫。 它絕對應該對你大喊大叫。

傑夫：這應該是有人說，哦，你的組織有什麼糟糕的事情之一？ 它應該是，哦，我確切地知道那是什麼。 因此，當您從這個角度處理它時，我認為接下來的步驟對您來說非常明顯，您需要解壓縮並開始使用 DevOps 工具箱中的哪些內容。 然後這些最小的增量變化不斷出現，你注意到隨著你獲得新的能力，你對不合格的東西的胃口變得非常小。 所以你從喜歡，哦，是的，部署需要三個小時，這沒關係。 你付出了一些努力，接下來你知道，在三週內，你就像，伙計，我不敢相信部署仍然需要 30 分鐘。 我們如何從 30 分鐘縮短這個時間？ 你對改善的胃口變得貪得無厭。 所以事情就是從那裡溢出來的。

Drew：我一直在閱讀您最近的書，其中突出了您所說的 DevOps 的四大支柱。 如前所述，它們都不是工具，但如果您願意的話，對於 DevOps 來說，有這四個主要關注領域。 我注意到其中的第一個是文化，我對此感到非常驚訝，首先，因為我期待你更多地談論工具，現在我們明白為什麼了，但是說到文化，這似乎很奇怪一開始就有的東西。 有一個技術方法的基礎。 文化如何影響組織內 DevOps 實施的成功程度？

Drew： ……DevOps 實施在組織內的成功程度。

傑夫：當你想到它時，文化真的是一切的基石。 這很重要，因為文化，我們在書中更深入地探討了這一點，但文化確實為組織內的規範奠定了基礎。 正確的。 你可能去過一家公司，如果你提交了沒有自動化測試的 PR，那並不是什麼大事。 人們接受它並繼續前進。

傑夫：但是還有其他一些組織，這是一個大罪。 正確的。 如果你這樣做了，就像，“哇，你瘋了嗎？ 你在幹嘛？ 這裡沒有測試用例。” 正確的。 不過那是文化。 這種文化正在強制執行這種規範，比如“這不是我們所做的”。

Jeff：任何人都可以寫一份文件說我們將擁有自動化測試用例，但是組織的文化是在人們中強制執行該機制的原因。 這只是文化為何如此重要的一個小例子。 如果你有一個組織，文化是一種恐懼文化，一種報復文化。 這就像如果你犯了一個錯誤，對，那就是褻瀆。 正確的。 這無異於叛國。 正確的。

傑夫：您在該組織中創建了對任何可能有風險或可能失敗的事情不利的行為。 這最終會在桌面上留下很多機會。 然而，如果你創造一種從失敗中學習的文化，就會接受這種心理安全的理念，人們可以在其中進行實驗。 如果他們錯了，他們可以弄清楚如何安全地失敗並重試。 你會得到一種實驗文化。 你會得到一個人們對新想法持開放態度的組織。

傑夫：我想我們都曾在那些公司工作過，“嗯，這就是它的做法。 沒有人能改變這一點。” 正確的。 你不希望這樣，因為世界在不斷變化。 這就是為什麼我們把文化放在首位和中心，因為組織內的許多行為都是因為存在的文化而存在的。

傑夫：問題是，文化演員可能是好是壞。 正確的。 具有諷刺意味的是，我們在書中也談到了這一點，改變組織文化並不需要像你想像的那麼多人。 正確的。 因為大多數人，有批評者，然後有支持者，然後在涉及任何形式的變化時，還有圍觀者。 大多數人都是圍欄保姆。 正確的。 只需要少數支持者就可以真正扭轉局面。 但從同樣的意義上說，實際上也只需要少數批評者就可以傾斜天平。

傑夫：就像，改變文化並不需要太多。 如果你把精力投入其中，即使不是高級領導，你也可以真正影響團隊文化，最終影響部門文化，最終影響組織文化。

傑夫：作為個人貢獻者，您可以做出這些文化變革，只需大聲支持這些想法和這些行為並說：“這些就是我們從中獲得的好處。” 這就是為什麼我認為文化必須放在首位，因為你必須讓每個人都接受這個想法，他們必須明白，作為一個組織，這將是值得的並支持它。

德魯：是的。 我想，這一定是一種生活方式。

傑夫：沒錯。

德魯：是的。 我對自動化領域真的很感興趣，因為在我的職業生涯中，我從未見過一些已經實施的自動化沒有帶來好處。 正確的。 我的意思是，除了奇怪的事情之外，也許有些事情是自動化的並且出了問題。 一般來說，當你花時間坐下來自動化你一直在手動做的事情時，它總是可以節省你的時間，節省你的頭部空間，而且它只是減輕你的負擔。

Drew：在採用 DevOps 方法時，您希望在工作流程中實現哪些自動化？ 您希望從手動完成任務中看到什麼收益？

傑夫：談到自動化，就你的觀點而言，很少有自動化沒有讓生活變得更好的時候。 正確的。 人們遇到的困難是找時間建立自動化。 正確的。 通常，在我目前的工作中，對我們來說，這實際上是請求的重點。 正確的。 因為在某些時候你必須說，“我將停止手動執行此操作，我將使其自動化。”

傑夫：可能必須在你收到請求時說，“你知道嗎？ 這需要兩週時間。 我知道我們通常會在幾個小時內完成它，但這需要兩週時間，因為這是自動化的請求。” 在確定您自動化的內容方面。 在 Central，我使用的流程基本上是對四個星期內收到的所有不同類型的請求進行抽樣，比方說。 我會將它們歸類為計劃內工作、計劃外工作、增值工作、辛勤工作。 辛勤工作並不是真正有用的工作，但出於某種原因，我的組織必須這樣做。

傑夫：然後確定那些類似的東西，“好吧，如果我們要實現自動化，我們可以擺脫的低垂果實是什麼？ 我們能做些什麼來簡化這一點？” 一些標準是過程的風險。 正確的。 自動數據庫故障轉移有點可怕，因為您不經常這樣做。 和基礎設施的變化。 正確的。 我們說，“我們多久做一次這件事？” 如果我們每年做一次，它可能不值得自動化，因為它的價值很小。 但是，如果這是我們每月獲得兩到三次的那些東西之一，好吧，讓我們來看看。 好的。

傑夫：現在，我們可以做些什麼來加快速度？ 問題是，當我們談論自動化時，我們立即跳到，“我要點擊一個按鈕，這件事就會神奇地完成。” 正確的。 但是，如果您感到不適，您可以在自動化中執行許多不同的步驟。 正確的。 例如，假設您有 10 個步驟和 10 個您通常會運行的不同 CLI 命令。 自動化的第一步可能很簡單，例如運行該命令，或者至少顯示該命令。 正確的。 說，“嘿，這就是我要執行的。 你覺得還行嗎？” “是的。” “好的。 這是我得到的結果。 我可以繼續嗎？” “是的。” “好的。 這就是我得到的結果。” 正確的。

傑夫：這樣你仍然有一點控制權。 你覺得舒服。 然後在 20 次處決之後，你意識到你只是在擊中，是的，是的，是的，是的，是的，是的。 你說：“好吧。 讓我們把所有這些東西都串起來，把它們都變成一個。” 這並不是說您必須跳入其中，單擊它並立即忘記它。 你可以踏入這一步，直到你感到舒服為止。

傑夫：這些是我們作為自動化工作的一部分所做的事情，很簡單，我們如何加快這方面的周轉時間並減少我們的工作量？ 第一天可能不是 100%，但目標始終是達到 100%。 我們將從小塊開始，我們將自動化其中我們覺得舒服的部分。 是的。 我們非常有信心這會奏效。 這部分我們有點冒險，所以也許我們會在繼續之前進行一些人工驗證。

Jeff：我們在談論自動化方面看到的另一件事是，我們為特定流程增加了什麼價值？ 這對於運維來說尤其重要。 因為很多時候 ops 充當了流程的中間人。 那麼他們的參與無非是一些接入的事情。 正確的。 這就像，好吧，ops 必須這樣做，因為 ops 是唯一有權訪問的人。

傑夫：嗯，這就像，嗯，我們如何將訪問外包，以便人們可以做到？ 因為現實是，我們並不擔心開發人員擁有生產訪問權限。 正確的。 我們擔心開發人員擁有不受限制的生產訪問權限。 這確實是一件安全的事情。 正確的。 就好像我的工具箱裡只有鋒利的刀，我會非常小心把它送給誰。 但是，如果我可以將工具箱與勺子和錘子混合在一起，以便人們可以為工作選擇合適的工具，那麼將其借出會容易得多。

Jeff：例如，我們有一個流程，人們需要在生產環境中運行臨時 Ruby 腳本，無論出於何種原因。 正確的。 需要清理數據，需要更正一些不良記錄，等等。 這總是會通過我的團隊來實現。 就像，好吧，我們沒有為此增加任何價值，因為我無法批准這張票。 正確的。 我不知道。 你編寫了軟件，所以我坐在你的肩膀上說“嗯，我認為那是安全的”有什麼好處？ 正確的。 我沒有為輸入添加任何價值，因為我只是在輸入您告訴我輸入的內容。 正確的。

傑夫：最壞的情況，最後，我真的只是你的路障，因為你正在提交一張票，然後你在等我吃完午飯回來。 我吃完午飯回來了，但我還有其他事情要做。 我們說：“我們如何實現自動化，以便將其交到開發人員手中，同時解決我們可能遇到的任何這些審計問題？”

Jeff：我們把它放在 JIRA 工作流程中，我們有一個機器人可以自動執行 JIRA 票證中指定的命令。 然後我們可以在 JIRA 票證中指定它需要幾位高級工程師之一的批准。 正確的。

傑夫：更有意義的是，一名工程師正在批准另一名工程師的工作，因為他們有上下文。 正確的。 他們不必坐在那裡等待操作。 審計部分得到了答复，因為我們已經在 JIRA 中定義了一個清晰的工作流程，該工作流程正在記錄為有人批准，有人要求。 我們有自動化功能，可以在終端中提取該命令並逐字執行該命令。 正確的。

傑夫：你不必擔心我打錯了。 你不用擔心我搶錯票了。 這增加了這些門票的周轉時間，大約是十倍。 正確的。 開發人員暢通無阻。 我的團隊並沒有被束縛在這方面。 真正需要一周或兩週的投資來實際開發自動化和讓他們訪問所需的許可。

傑夫：現在我們完全擺脫了這一點。 開發實際上能夠將其中一些功能外包給組織的較低部分。 他們已將其推送給客戶服務。 就像現在，當客戶服務知道此記錄需要更新時，他們不需要開發。 他們可以提交我們已批准用於此功能的標準腳本。 他們可以通過與開發完全相同的工作流程來運行它。 這真的是一個福音。

傑夫：然後它允許我們在整個組織中將工作推得越來越低。 因為當我們這樣做時，工作變得越來越便宜，因為我可以讓一個花哨的、昂貴的開發人員來運行它。 正確的。 或者我可以讓一個直接與客戶合作的客戶服務人員，在他們與客戶通電話時自己運行它，讓客戶糾正問題。

Jeff：我認為自動化是任何組織的關鍵。 我要說的最後一點是，它還允許您輸出專業知識。 正確的。 現在，如果我需要在命令行上執行一堆命令，我可能是唯一知道如何執行此操作的人。 但如果我把它放在自動化中，我可以把它交給任何人。 人們知道最終結果是什麼，但他們不需要知道所有的中間步驟。 通過將其推向組織並利用我的專業知識並將其編碼為可出口的東西，我將我的價值提高了十倍。

Drew：您談到了自動化頻繁發生的任務。 是否有一個論據支持自動化任務的發生頻率如此之低，以至於開發人員需要很長時間才能恢復其應該如何工作的速度？ 因為大家都忘記了。 已經這麼久了。 已經一年了，也許以前沒有人這樣做過。 是否也有將這些事情自動化的論據？

傑夫：這是一個艱難的平衡行為。 正確的。 我總是說逐案處理。 我這麼說的原因是，DevOps 的信條之一是，如果有痛苦，那就更頻繁地去做。 正確的。 因為你做的次數越多，肌肉記憶就越多，你就可以鍛煉並消除這些扭結。

Jeff：我們看到的自動化非常罕見的任務的問題是，環境的格局往往會在自動化執行之間發生變化。 正確的。 最終發生的是您的代碼對環境做出了特定的假設，而這些假設不再有效。 因此，無論如何，自動化最終都會崩潰。

德魯：然後你有兩個問題。

傑夫：對。 正確的。 確切地。 確切地。 你會說，“我打錯了嗎？ 或者是這個？ 不，這東西居然壞了。” 所以-

傑夫：打錯了，或者這不是，這東西實際上壞了。 因此，當涉及到不經常執行的任務的自動化時，我們真的會逐個案例來了解，如果這不起作用，會有什麼風險，對吧。 如果我們弄錯了，是我們狀態不好還是只是我們沒有完成這項任務？ 因此，如果您可以確保這會優雅地失敗並且不會產生負面影響，那麼值得嘗試將其自動化。 因為至少，你有一個理解應該發生什麼的框架，因為至少，有人將能夠閱讀代碼並理解，好吧，這就是我們正在做的事情。 而且我不明白為什麼這不再起作用，但我清楚地了解至少在編寫本文時的設計時應該發生什麼。

Jeff：但是，如果您遇到故障可能導致數據更改或類似情況的情況，我通常會謹慎行事並保持手動操作，因為如果我有自動化腳本，如果我找到了一些 confluence 文檔那個說運行這個腳本已經三年了，我傾向於對那個腳本有百分之一百的信心並執行它。 正確的。 然而，如果它是四年前記錄的一系列手動步驟，我會說，我需要在這裡做一些驗證。 正確的？ 讓我稍微介紹一下，並與幾個人交談。 有時當我們設計流程時，強制這個思考過程是值得的，對吧？ 你必須考慮人類的組成部分以及他們將如何表現。 有時值得讓這個過程變得更麻煩一點，迫使人們認為我現在應該這樣做嗎？

Drew：還有其他方法可以通過監控系統和測量事物來識別應該自動化的內容嗎？ 我的意思是，我認為 DevOps 並且我認為儀表板是其中之一，漂亮的圖表。 而且我確信這些儀表板不僅僅是看起來漂亮，但擁有漂亮的儀表板總是很好的。 有沒有辦法衡量一個系統在做什麼，以幫助你做出這些決定？

傑夫：當然。 對凸輪的指標部分進行這種劃分，對，我們在系統中跟踪哪些內容以了解它們是否有效運行？ 指標的常見缺陷之一是我們尋找錯誤而不是驗證成功。 這是兩種截然不同的做法，對吧？ 因此，某些東西可能會流經系統，不一定會出錯，但不一定會按照應有的方式完成整個過程。 因此，如果我們將一條消息放到消息隊列中，則應該有一個相應的指標顯示“並且這條消息已被檢索和處理”，對嗎？ 如果不是，對，你很快就會出現不平衡，並且系統無法按應有的方式工作。 我認為我們可以使用指標作為一種方式來理解當我們進入那些糟糕的狀態時應該自動化的不同事物。

傑夫：對吧？ 因為很多時候這是一個非常簡單的步驟，需要採取清理措施，對吧？ 對於已經操作一段時間的人，對，磁盤空間警報，每個人都知道這一點。 哦，我們裝滿了光盤。 哦，我們忘記了它是月末和計費運行和計費總是填滿日誌。 然後 VAR 日誌正在消耗所有磁盤空間，因此我們需要運行日誌輪換。 正確的？ 如果這是你的偏好，你可以在凌晨三點起床。 但如果我們知道那是行為，我們的指標應該能夠為我們提供線索。 我們可以簡單地自動化日誌輪換命令，對吧？ 哦，我們已經達到了這個閾值，執行日誌輪換命令。 讓我們看看警報是否清除。 如果是這樣，繼續生活。 如果沒有，那麼也許我們會叫醒某人，對吧。

Jeff：你在基礎設施自動化方面也看到了更多，對，就像，“嘿，我們每秒的請求是否達到了我們的理論最大值。 也許我們需要擴展集群。 也許我們需要在負載均衡池中添加三四個節點。” 我們可以做到這一點，而不一定需要有人干預。 我們可以只查看這些指標並採取行動，然後在基礎設施低於特定閾值時收縮該基礎設施，但是您必須擁有這些指標，並且您必須將這些掛鉤連接到您的監控環境中才能做到這一點。 這就是對話的整個指標部分的來源。

傑夫：另外，能夠與其他人分享這些信息也很好，因為一旦你有了數據，你就可以開始在一個共享的現實中談論事情，對，因為忙碌是一個通用術語，但每秒 5,200 個請求已經很多了更具體，我們都可以推理。 而且我經常認為，當我們就容量或任何事情進行對話時，我們會使用這些隨意的術語，而相反，我們可以查看儀表板並給出非常具體的值並確保每個人都可以訪問這些儀表板，即它們並沒有隱藏在某些只有我們出於某種未知原因才能訪問的操作牆後面。

Drew: So while sort of monitoring and using metrics as a decision-making tool for the businesses is one aspect of it, it sounds like the primary aspect is having the system monitor itself, perhaps, and to respond maybe with some of these automations as the system as a whole gives itself feedback on onto what's happening.

Jeff: Absolutely. Feedback loops are a key part of any real system design, right, and understanding the state of the system at any one time. So while it's easy in the world where everything is working fine, the minute something goes bad, those sorts of dashboards and metrics are invaluable to have, and you'll quickly be able to identify things that you have not instrumented appropriately. 正確的。 So one of the things that we always talk about in incident management is what questions did you have for the system that couldn't be answered, right. So what is it, or you're like, “Oh man, if we only knew how many queries per second were going on right now.” 正確的。

Jeff: Well, okay. How do we get that for next time? How do we make sure that that's radiated somewhere? And a lot of times it's hard when you're thinking green field to sit down and think of all the data that you might want at any one time. But when you have an incident, it becomes readily apparent what data you wish you had. So it's important to sort of leverage those incidents and failures and get a better understanding of information that's missing so that you can improve your incident management process and your metrics and dashboarding.

Drew: One of the problems we sometimes face in development is that teammate members, individual team members hold a lot of knowledge about how a system works and if they leave the company or if they're out sick or on vacation, that knowledge isn't accessible to the rest of the team. It seems like the sort of DevOps approach to things is good at capturing a lot of that operational knowledge and building it into systems. So that sort of scenario where an individual has got all the information in their head that doesn't happen so much. 這是一個公平的評價嗎？

Jeff: It is. I think we've probably, I think as an industry we might have overstated its efficacy. And the only reason I say that is when our systems are getting so complicated, right? Gone are the days where someone has the entire system in their head and can understand it from beginning to end. Typically, there's two insidious parts of it. One, people typically focus on one specific area and someone doesn't have the whole picture, but what's even more insidious is that we think we understand how the system works. 正確的。 And it's not until an incident happens that the mental model that we have of the system and the reality of the system come into conflict. And we realize that there's a divergence, right? So I think it's important that we continuously share knowledge in whatever form is efficient for folks, whether it be lunch and learns, documentation, I don't know, presentations, anything like that to sort of share and radiate that knowledge.

Jeff: But we also have to prepare and we have to prepare and define a reality where people may not completely understand how the system works. 正確的。 And the reason I think it's important that we acknowledge that is because you can make a lot of bad decisions thinking you know how the system behaves and being 100% wrong. 正確的。 So having the wherewithal to understand, okay, we think this is how the system works. We should take an extra second to verify that somehow. 正確的。 I think that's super important in these complicated environments in these sprawling complex microservice environments. Whereas it can be very, it's easy to be cavalier if you think, oh yeah, this is definitely how it works. And I'm going to go ahead and shut the service down because everything's going to be fine. And then everything topples over. So just even being aware of the idea that, you know what, we may not know a hundred percent how this thing works.

Jeff: So let's take that into account with every decision that we make. I think that's key. And I think it's important for management to understand the reality of that as well because for management, it's easy for us to sit down and say, “Why didn't we know exactly how this thing was going to fail?” And it's like, because it's complicated, right, because there's 500 touch points, right, where these things are interacting. And if you change one of them, it changes the entire communication pattern. So it's hard and it's not getting any easier because we're getting excited about things like microservices. We're getting excited about things like Kubernetes. We're giving people more autonomy and these are just creating more and more complicated interfaces into these systems that we're managing. And it's becoming harder and harder for anyone to truly understand them in their entirety.

Drew: We've talked a lot about a professional context, big organizations and small organizations too. But I know many of us work on smaller side projects or maybe we volunteer on projects and maybe you're helping out someone in the community or a church or those sorts of things. Can a DevOps approach benefit those smaller projects or is it just really best left to big organizations to implement?

Jeff: I think DevOps can absolutely benefit those smaller projects. And specifically, because I think sort of some of the benefits that we've talked about get amplified in those smaller projects. 正確的？ So exporting of expertise with automation is a big one, right? If I am… Take your church example, I think is a great one, right? If I can build a bunch of automated tests suites to verify that a change to some HTML doesn't break the entire website, right, I can export that expertise so that I can give it to a content creator who has no technical knowledge whatsoever. 正確的。 They're a theologian or whatever, and they just want to update a new Bible verse or something, right. But I can export that expertise so that they know that I know when I make this content change, I'm supposed to run this build button.

Jeff: And if it's green, then I'm okay. And if it's red, then I know I screwed something up. 正確的。 So you could be doing any manner of testing in there that is extremely complicated. 正確的。 It might even be something as simple as like, hey, there's a new version of this plugin. And when you deploy, it's going to break this thing. 正確的。 So it has nothing to do with the content, but it's at least a red mark for this content creator to say “Oh, something bad happened. I shouldn't continue. 正確的。 Let me get Drew on the phone and see what's going on.” 正確的。 And Drew can say, “Oh right. This plugin is upgraded, but it's not compatible with our current version of WordPress or whatever.” 正確的。 So that's the sort of value that we can add with some of these DevOps practices, even in a small context, I would say specifically around automation and specifically around some of the cultural aspects too.

Jeff: Right? So I've been impressed with the number of organizations that are not technical that are using get to make changes to everything. 正確的。 And they don't really know what they're doing. They just know, well, this is what we do. This is the culture. And I add this really detailed commit message here. And then I push it. They are no better than us developers. They know three get commands, but it's the ones they use over and over and over again. But it's been embedded culturally and that's how things are done. So everyone sort of rallies around that and the people that are technical can take that pattern.

Jeff: … around that and the people that are technical can take that pattern and leverage it into more beneficial things that might even be behind the scenes that they don't necessarily see. So I think there's some value, definitely. It's a matter of how deep you want to go, even with the operations piece, right? Like being able to recreate a WordPress environment locally very easily, with something like Docker. They may not understand the technology or anything, but if they run Docker Compose Up or whatever, and suddenly they're working on their local environment, that's hugely beneficial for them and they don't really need to understand all the stuff behind it. In that case, it's worthwhile, because again, you're exporting that expertise.

Drew: We mentioned right at the beginning, sort of putting off as much sort of DevOps as possible. You mentioned using tools like Heroku. And I guess that sort of approach would really apply here on getting started with, with a small project. What sort things can platforms like Heroku offer? I mean, obviously, I know you're not a Heroku expert or representative or anything, but those sorts of platforms, what sort of tools are they offering that would help in this context?

Jeff: So for one, they're basically taking that operational context for you and they're really boiling it down into a handful of knobs and levers, right? So I think what it offers is one, it offers a very clear set of what we call the yellow brick road path, where it's like, “If you go this route, all of this stuff is going to be handled for you and it's going to make your life easier. If you want to go another route, you can, but then you got to solve for all this stuff yourself.” So following the yellow brick road route helps because one, they're probably identifying a bunch of things that you hadn't even thought of. So if you're using their database container or technology, guess what? You're going to get a bunch of their metrics for free. You're going to get a lot of their alerting for free. 你什麼都沒做。 You didn't think anything. It's just when you need it, it's there. And it's like, “Oh wow, that's super are helpful.”

Jeff: Two, when it comes to performance sizing and flexibility, this becomes very easy to sort of manage because the goal is, you're a startup that's going to become wildly successful. You're going to have hockey stick growth. And the last thing you necessarily really want to be doing is figuring out how to optimize your code for performance, while at the same time delivering new features. So maybe you spend your way out of it. You say, “Well, we're going to go up to the next tier. I could optimize my query code, but it's much more efficient for me to be spending time building this next feature that's going to bring in this new batch of users, so let's just go up to the next tier,” and you click button and you move on.

Jeff: So being able to sort of spend your way out of certain problems, I think it's hugely beneficial because tech debt gets a bad rap, but tech debt is no different than any debt. It's the trade off of acquiring something now and dealing with the pain later. And that's a strategic decision that you have to make in every organization. So unchecked tech debt is bad, right? But tech debt generally, I think, is a business choice and Heroku and platforms like that enable you to make that choice when it comes to infrastructure and performance.

Drew: You've written a book, Operations, Anti-Patterns, DevOps Solutions, for Manning. I can tell it's packed with years of hard-earned experience. The knowledge sort of just leaps out from the page. And I can tell it's been a real labor of love. It's packed full of information. Who's your sort of intended audience for that book? Is it mostly those who are already working in DevOps, or is it got a broader-

Jeff: It's got a broader… So one of the motivations for the book was that there were plenty of books for people that we're already doing DevOps. 你知道我的意思？ So we were kind of talking to ourselves and high-fiving each other, like, “Yeah, we're so advanced. Awesome.” But what I really wanted to write the book for were people that were sort of stuck in these organizations. I don't want to use the term stuck. That's unfair, but are in these organizations that maybe aren't adopting DevOps practices or aren't at the forefront of technology, or aren't necessarily cavalier about blowing up the way they do work today, and changing things.

傑夫：我想寫信給他們，主要是個人貢獻者和中層管理人員說，“你不需要成為 CTO 就能做出這些漸進式的改變，你也不必擁有這個整個銷售革命能夠獲得 DevOps 的一些好處。” 所以這真的是一封寫給他們的情書，比如，“嘿，你可以分段完成。 你可以自己做。 你可能認為所有這些事情都與 DevOps 無關，因為你認為它是工具和 Kubernetes。” 不是每個組織……如果你是紐約州，就像州政府一樣，你不會一夜之間進來並實施 Kubernetes。 正確的？ 但是您可以實現團隊如何相互交談、他們如何一起工作、我們如何理解彼此的問題，以及我們如何通過自動化解決這些問題。 這些是你影響範圍內的事情，可以改善你的日常生活。

Jeff：所以這確實是給那些人的一封信，但我認為那裡有足夠的數據和足夠的信息，可供 DevOps 組織中的人們收集並說，“嘿，這對我們仍然有用。 ” 很多人，我認為通過閱讀這本書很快就可以確定，他們不在 DevOps 組織中，他們只是換了一個職位。 這種情況經常發生。 所以他們會說，“嘿，我們現在是 DevOps 工程師，但我們沒有做本書中談到的這類實踐，我們如何做到這一點？”

Drew：所以聽起來你的書就是其中之一，但還有其他資源可以讓想要開始使用 DevOps 的人轉向嗎？ 有學習這些東西的好地方嗎？

傑夫：是的。 我認為 Emily Freeman 的 DevOps For Dummies 是一個很好的起點。 它確實很好地整理了一些核心概念和想法，以及我們正在努力的目標。 所以這將是一個很好的起點，只是為了了解一下這塊土地。 我認為鳳凰計劃顯然是 Gene Kim 的另一個重要來源。 這很好，這為不在 DevOps 環境中可能產生的問題類型奠定了基礎。 它很好地突出了我們在所有類型的組織中一遍又一遍地看到的這些模式和個性。 我認為它在突出這些方面做得很好。 如果你讀了那本書，我想你最終會衝著書頁尖叫，“是的，是的。 這。 這。” 所以，那是另一個很棒的地方。

Jeff：然後從那裡深入研究任何 DevOps 手冊。 我會因為這樣說而自責，但 Google SRE 手冊是另一個值得一看的好地方。 明白你不是谷歌，所以不要覺得你必須實施一切，但我認為他們的很多想法和策略對任何組織都是合理的，並且是你可以採取一些事情的好地方可以說，“好吧，我們要讓我們的運營環境更有效率。” 這就是，我認為對於扮演運維角色的開發人員來說尤其重要，因為它確實專注於解決其中一些問題的許多程序化方法。

Drew：所以，我一直在學習有關 DevOps 的所有知識。 你最近在學習什麼，傑夫？

傑夫： Kubernetes，伙計。 是的。 Kubernetes 對我們來說是一種真正的閱讀和知識來源。 因此，我們目前正嘗試在 Centro 實現這一點，作為進一步授權開發人員的一種手段。 我們希望從我們所處的位置更進一步。 我們已經實現了很多自動化，但是現在，當涉及到新服務的加入時，我的團隊仍然相當多地參與其中，具體取決於服務的性質。 而且我們不想從事那項工作。 我們希望開發人員能夠將一個想法從概念到代碼再到部署，並在系統內編纂運營專業知識的情況下做到這一點。 所以，當你在系統中移動時，系統會引導你。 所以我們認為 Kubernetes 是一個可以幫助我們做到這一點的工具。

傑夫：這非常複雜。 這是一大塊咬掉的東西。 那麼弄清楚部署是什麼樣的？ 我們如何在 Kubernetes 中利用這些運算符？ CICD在這個新世界中會是什麼樣子？ 所以有很多閱讀，但在這個領域，你一直在學習，對吧？ 不管你在這個領域工作了多久，你做了多久，在這個領域的某個方面，你都是個白痴。 所以，這只是你適應的東西

Drew：好吧，就像我說的那樣，儘管這麼多年過去了，雖然我有點理解它在堆棧中的位置，但我仍然真的不知道 Kubernetes 在做什麼。

傑夫：我有時也有類似的感覺。 感覺就像它在做每一件事，對吧？ 它是 21 世紀的 DNS。

德魯：如果你，聽眾，想從傑夫那裡聽到更多，你可以在推特上找到他，他在黑暗和書呆子，並在他的網站上找到他的書和過去的演示文稿和博客文章的鏈接，actainabledevops.com。 感謝您今天加入我們，傑夫。 你有什麼臨別的話嗎？

傑夫：繼續學習，走出去，繼續學習，與你的同齡人交談。 說話，說話，說話。 你和你一起工作的人交談得越多，你就會對他們產生更好的理解，更好的同理心，如果你討厭組織中的某個人，請確保先與他們交談。