知識星球
如果你問 10 個人關於 DevOps 的問題，你會得到 12 個答案。這是對於 DevOps 的意見和期望的多樣性的結果，更不用說它在實踐中的差異。
為瞭解讀 DevOps 的悖論，我們找到了最瞭解它的人 —— 這個行業的頂尖從業者。這些人熟悉 DevOps，瞭解技術的來龍去脈，並且已經有了多年 DevOps 實踐。他們的觀點應該能鼓勵、刺激和激發你對 DevOps 的想法。
DevOps 對你意味著什麼？
讓我們從基本原理開始。我們不能只在教科書上尋找答案，而應該需要知道專家們怎麼說。
簡而言之，專家們說的是關於 DevOps 的原則、實踐和工具。
IBM 數字企業集團 DevOps 商業平臺領導者 Ann Marie Fred[1]，說，“對於我來說，DevOps 是一套實踐和原則，旨在使團隊在設計、開發、交付和操作軟體方面有更好的效率。”
據紅帽資深 DevOps 佈道者 Daniel Oh[2]，“通常來說，DevOps 促使企業基於當前的 IT 發展與應用開發、IT 運維和安全協議的流程和工具。”
Tactec 戰略解決方案的創始人 Brent Reed[3]，談及了利益相關者的持續改進，“DevOps 對我來說意味著包括了一種思維方式的工作方式，它允許持續改進運維績效，進而提升組織績效，從而讓利益相關者受益。”
許多專家也強調 DevOps 文化。Ann Marie 說，“這也是持續改進和學習的問題。它涉及的是人和文化，以及工具和技術。”
美國保監會 (NAIC) 首席架構師兼 DevOps 領導者 Dan Barker[4]，“DevOps 主要是關於文化…它將幾個獨立的領域聚集在一起，如精益生產、公正文化[5] 和持續的學習。我認為文化是最關鍵和最難執行的。”
Atos 的 DevOps 負責人 Chris Baynham-Hughes[6]，說，“[DevOps] 實踐是透過組織內的文化、流程和工具的發展而被採用的。重點是文化變革，DevOps 文化借鑒的關鍵是協作、試驗、快速反饋和持續改進。”
雲架構師 Geoff Purdy[7]，談及敏捷和反饋，“縮短和放大反饋迴路。我們希望團隊在幾分鐘內而不是幾周內獲得反饋。”
但在最後，Daniel 透過解釋開源和開源文化是如何讓他以簡單快捷的方式實現標的來強調這點，“在推動 DevOps 中，最重要的事情應該是開源文化而不是具體的工具或複雜的解決方案。”
你認為哪些 DevOps 實踐有效？
專家列舉的那些最佳實踐是普遍存在的，但又各不相同。
Ann Marie 表示：“一些十分強大靈活的專案管理[實踐]，能在職能、獨立的小組之間打破壁壘；全自動化持續部署，藍/綠部署實現零時間停機狀態；開發人員設定自己的監控和警告，無縫自我修複，自動化的安全性與合規性。”
Chris 說，“特別的突破是傾情合作、持續改進、開放領導、縮短業務距離、從垂直孤島轉向橫向/跨功能的產品團隊、工作透明化、相互影響、Mobius 迴圈、縮短反饋迴路、自動化（從環境到 CI/CD）。”
Brent 支援“發展學習文化，包括 TTD [測試驅動開發] 和 BDD [行為驅動開發]捕獲事件，並透過持續整合和持續交付從設計、構建和測試到實施在生產環境上一系列事件的自動化。測試採用故障優先的方法，能夠自動化整合和交付流程，併在整個生命週期中包含快速反饋。”
Geoff 強調自動化配置。“選擇一個自動化配置，對我的團隊來說非常有效。更具體地說從版本控制程式碼庫中自動配置。”
Dan 則玩的開心，“ 我們做了很多不同的事情來建立 DevOps 文化。我們舉辦 ‘午餐 & 學習’ 活動，提供免費的食物來鼓勵大家一起學習。我們買書，分組學習。”
你如何激勵你的團隊實現 DevOps 這個標的？
Daniel 強調“自動化的問題就是為了減少 DevOps 計劃中來自多個團隊的異議，你應該鼓勵你的團隊提高開發、測試與 IT 運營的自動化能力，以及新的流程和程式。例如，Linux 容器是實現 DevOps 自動化功能的關鍵工具。”
Geoff 很是贊同，“機械化的勞作，你有討厭現在做的任務嗎？很棒。如果可能的話，讓它們消失。不行，那就讓它們自動化。它能使工作不會變得太枯燥，因為工作總是在變化。”
Dan、Ann Marie 和 Brent 強調團隊的執行力。
Dan 說，“在 NAIC，我們有個很好的獎勵系統來鼓勵特定的行為。我們有多個級別的獎項，其中兩個獎項可以由任何人頒佈給某人。我們也會頒獎給完成重要任務的團隊，但我們通常只獎勵給個人貢獻者。”
Ann Marie 表示，“我所在地區的團隊最大的動力是看見其他人成功。我們每週都會彼此回放一次，其中一部分是分享我們從嘗試新工具或實踐中學到的東西。團隊熱衷於他們現在做的事情，並願意幫助其他人開始，相信更多的團隊很快也會加入進來。”
Brent 表示贊同。“讓每個人學習，並掌握同樣的基礎知識至關重要……我喜歡從評估什麼能幫助團隊實現標的[以及]產品負責人和使用者需要提供的內容入手。”
Chris 推薦採用雙管齊下的方法。“執行可以每週可以實現的小標的，並且[在這]可以看到他們正在運做的功能工作之外的進展，慶祝你所取得的進步。”
DevOps 和敏捷開發如何協同工作？
這是一個重要的問題，因為 DevOps 和敏捷開發都是現代軟體開發的基石。
DevOps 是一個軟體開發的過程，專註與溝通與協作，以促進快速部署應用程式和產品。而敏捷開發是一種開發方法，涉及持續開發、連續迭代和連續測試，以實現可預測和可交付的成果質量。
那麼，它們又有怎樣的聯絡？讓我們去問問專家吧。
在 Brent 來看，“DevOps != 敏捷。其次 敏捷 != Scrum 流程……敏捷工具和工作方式支撐著 DevOps 策略和標的，它們是如此融合在一起的。”
Chris 說，“對我而言敏捷是 DevOps 的一個基本元件。當然，我們可以討論如何在非敏捷開發環境中採用 DevOps 文化，但最終表明，提高軟體設計方式的靈活性是採用 DevOps 成熟讀的一個關鍵指標。”
Dan 將 DevOps 與更偉大的 敏捷宣言[8] 聯絡起來。“我在談到敏捷時總會取用敏捷宣言來設定基準，而有許多實現中並不關註該宣言。當你閱讀這份宣言時，你會發現它確實從開發的角度描述了 DevOps。因此，將敏捷融入 DevOps 文化非常容易，因為敏捷關註於溝通、協作、變化的靈活性以及快速地投入生產。”
Geoff 認為 “DevOps 是敏捷實施的眾多實現之一。敏捷本質上是一套原則，而 DevOps 則是體現這些原則的文化、流程和工具鏈。”
Ann Marie 簡潔說明，“敏捷是 DevOps 的先決條件。DevOps 使敏捷變得更加有效。”
DevOps 是否受益於開源？
這個問題得到了所有參與者的熱烈肯定，然後解釋了他們看到的好處。
Ann Marie 說，“我們站在巨人的肩膀上，在已有的基礎之上發展。拉取請求和程式碼評審的開源樣式，對 DevOps 團隊維護軟體很有效果。”
Chris 贊同 DevOps “毫無疑問”受益於開源。“從設計和工具方面（例如，Ansible），到流程和人員方面，通分享行業內的故事和開源社群的領導。”
Geoff 提到一個好處是“基層的採納”。免費的軟體不需要簽署購買申請。團隊發現了滿足他們需求的工具，可以自行進行修改。[然後]在它之上構建，併為更大的社群提供更好的功能。如此往複。
開源已經向 DevOps 展示著“就像開源軟體開發者正在做的那樣，採用更好的方式來剋服新的變化”，Daniel 說。
Brent 同意道 “DevOps 從開源中獲益良多。一種方法是使用這些工具來理解它們是如何加速 DevOps 的標的和策略；在自動化、自動伸縮、虛擬化和容器化等關鍵方面對開發人員和操作人員進行培訓，如果不引入使 DevOps 更加容易的技術支援，就很難實現這些特性。”
Dan 指出了 DevOps 和開源之間的雙向共生關係，“做好開源需要 DevOps 文化。大多數開源專案都具有非常開放的溝通結構，很少有不透明的地方。對於 Devops 實踐者來說，這實際上是一個很好的學習機會，可以讓他們瞭解到可能需要將什麼引入自己的組織中。此外能夠使用來自社群與組織類似的工具來鼓勵自己的文化成長。我喜歡用 GitLab 作為這種共生關係的一個例子。當我把 GitLab 帶入一家公司時，我們得到了一個很棒的工具，但我們真正購買的是他們獨特的文化，透過我們與他們的互動以及我們的貢獻帶來了巨大價值。他們的工具也可以為 DevOps 組織提供更多東西，而他們的文化已經在我引入它的公司中引起了他們的敬畏。”
現在我們的 DevOps 專家已經參與進來了，請在評論中分享你對 DevOps 的理解，以及向我們提出其他問題。
