彌合差距：DevOps 溝通的重要性

儘管 DevOps 方法已經存在了很長一段時間，但它仍然是激烈討論的中心。 公司想要它，但不確定如何處理它。

DevOps 無處不在。 雖然這是一個有趣的趨勢，但它應該適合產品，而不是相反。

但有些人不這麼看。 我經常被問到諸如“你認為我們應該開始使用 Docker，還是直接跳入 Kubernetes？”之類的問題。 甚至不知道產品是關於什麼的，這樣的問題是毫無意義的。

所有這些花哨的術語——雲、Kubernetes、容器、配置管理、基礎設施即代碼——都有望得到一些改進。 但它們之於 DevOps 就像望遠鏡之於天文學一樣。 它們可能有用，但不是必需的。

DevOps 的核心旨在縮小客戶訂購的內容與開發團隊交付的內容之間的差距。 重點是短髮布週期、迭代設計方法和重複步驟的自動化。 您認為將這些變為現實最重要的是什麼？

如果您說“良好的溝通”，那您是對的。 工具都很好。 但只有當他們改善溝通時，他們才值得投資於他們的錢。

溝通的一個方面是知道完成工作需要什麼。 這項工作並不意味著“將代碼提交到存儲庫”。 可以把它想像成“客戶看到了生產中的變化並接受了它”。

一旦確定了第一步，並且每個人都知道需要發生什麼，那就是寫下來的最佳時機。 在哪裡？ 好吧，我是維護README.md的忠實擁護者。 團隊中的每個人都可以隨時窺視並了解項目的狀態，這對於項目新手來說是自然而然的選擇。

編寫自述文件後的下一步自動化是可選的。 不過，這是記錄過程的自然產物。 是的，在考慮 DevOps 時，經常會想到自動化。

等一下……對於 DevOps，自動化是可選的嗎？ DevOps 不是部署人員的部門嗎？

人們通常在“DevOps 工程師”一詞下所理解的，要么是軟件可靠性工程師、平台工程師，要么是運維自動化工程師。 這些都是能夠實踐 DevOps 的有效角色，但使用“DevOps 工程師”這個統稱可能有點含糊。

因此，讓我們仔細看看 DevOps 本身。

DevOps 解釋

首先，讓我向您展示 DevOps 不是什麼：

1. 它不僅僅是一個職位前綴
2. 它不是一個團隊（但“Dev”和“Ops”是）
3. 這不是一項技術
4. 這並不意味著“可以編碼的系統管理員”
5. 這並不意味著“自動化的東西”
6. 這並不意味著“現在沒有運營團隊”

了解了這一點，您現在意識到您不能簡單地在公司中“聘請 DevOps 工程師”或“創建 DevOps 團隊”以確保您能夠適應未來。 DevOps 類似於敏捷開發。 您會僱用這樣的敏捷開發人員嗎？ 可能不是。 您要么以敏捷的方式開發產品，要么不這樣做。

那麼如何描述 DevOps？ 這是一種方法論。 或者也許是一種文化。 甚至可能是一種精神。 根據 DevOps 原則做產品意味著每個人——無論是開發人員、運營工程師還是產品經理——都有一個共同的願景，並通過溝通來維護它。 在較小程度上，這也意味著每個人都使用相同的工具。 這些工具並非旨在幫助任何單一群體。 它們旨在推動產品向前發展。

採用這個概念需要認真改變思維方式，這是主要障礙。 這是為什麼？ 這是因為人們必須走出自己的舒適區，開始與具有不同能力的人合作。 開發人員突然需要了解雲的工作原理並開始部署自己的代碼。 操作人員需要放棄手動設置並開始編碼。 每個人都需要學​​習新概念。 每個人都有新的責任。

這並不容易，但通過良好的溝通和共同的目標，這是可以實現的。 這種溝通涉及建立文化、建立輕量級流程和維護適當的文檔。

DevOps 自動化是文檔

你可能從來沒有這樣想過。 但是大多數通常與 DevOps 相關的工具都是文檔工具：

• 為可讀性而編寫的構建腳本用於記錄構建過程
• 持續集成管道記錄集成過程，從構建單個部件到整個產品
• 通過記錄如何部署您的客戶可以使用的產品，持續部署管道走得更遠
• 配置管理文件記錄了安裝和配置的過程
• 基礎設施即代碼規範記錄了必要的基礎設施（實際上非常正式！）
• 容器帶有自己的Dockerfile記錄如何構建和配置給定的微服務

所有這些花哨的概念基本上只做一件事：它們通過記錄流程幫助團隊成員更好地溝通。 這些過程可以手動運行或自動運行。 重要的是項目中的每個利益相關者都能夠跟隨他們。

將您的流程記錄為代碼與通常的說明手冊相比具有一大優勢。 代碼可以被驗證並具有預測性。 給定相同的輸入，它會產生相同的輸出。

有了書面說明，您就會有與讀者一樣多的解釋。 如果您編寫模棱兩可或含糊不清的文檔，閱讀它的人將填補空白。 關鍵是，您無法控制間隙中的內容。

使用代碼要簡單得多。 如果沒有具體步驟，程序將停止運行。 這些具體步驟是 DevOps 溝通的一個關鍵方面。

DevOps 溝通：彌合開發和運營之間差距的唯一途徑

在《鳳凰計劃》一書中，我們見證了一位負責部署一個大項目的最近晉升的經理所面臨的問題。 由於沒有人知道發生了什麼，每個人都在滅火，但進展不大。 書的副標題提到這是一個關於 DevOps 的故事。 我同意這一點。

但有趣的是，在本書的整個過程中，沒有介紹一個新工具。 您能否僅通過改善溝通來達到 DevOps 的狀態？ 這本書的主角做到了，所以你也有希望！

儘管主角的方法可能被認為是“老派”（使用實際的紙卡而不是適當的錯誤跟踪系統），但只有當所有相關方開始相互交談時，情況才會開始好轉。

您可能認為只有通過在開發和運營之間創建更好的接口（例如服務級別協議或事件積壓）來改善開發和運營之間的協作。 但事實恰恰相反。 通過拆除界面並引入同理心和共同事業，您將擁有一個朝著共同目標努力的團隊。

DevOps 團隊結構：誰在團隊中？

理想情況下，每個產品應該只有一個團隊：產品團隊。

我曾經在一個開發團隊中，與其他團隊沒有共同目標。 開發團隊希望推動盡可能多的變化。 驗證團隊的任務是防止引入缺陷。 他們有不同的經理，他們被單獨評估。

結果？ 開發和驗證與缺陷報告打乒乓球。 當驗證發現一個無法通過的測試時，開發人員更感興趣的是發現測試代碼本身的缺陷，而不是試圖讓自己的代碼沒有錯誤。

當然，發布週期急劇膨脹，因為正確填寫報告、反報告等需要大量開銷。 大多數人似乎沒有意識到，在產品方面，兩個團隊應該有一個共同的目標，並共同努力實現它。 但是缺乏適當的合作和筒倉心態使得它很難被注意到。

與廢物作鬥爭是共同努力

啟發敏捷軟件開發宣言（又將我們介紹給 DevOps）的精益生產心態是關於消除浪費。 我們所說的浪費是指與客戶訂購的東西沒有直接關係的所有東西。 堆積的在製品是一種浪費。 沒有明確導致釋放的過程的每一步都是浪費。

但浪費只能從高處看。 在一個團隊的範圍內，一些程序似乎是必不可少的。 但是，從產品的角度來看，它們很可能毫無用處。

要弄清楚哪些努力被浪費了，您必須聯合起來並考慮已發貨產品的生命週期。 您還需要從客戶的角度思考。 這個功能是客戶想要的嗎？ 如果沒有，你也可以在這個時候跳過它。 您的流程簡單且精益嗎？ 更深入地研究那些跨越團隊界限的人。

您想確保產品的開發盡可能高效嗎？ 邀請一個局外人看看你是如何工作的。 不屬於您團隊的人將能夠提出有見地的問題並發現需要改進的新領域。

DevOps 原則：保持冷靜

CALMS 非常準確地描述了應該如何實踐 DevOps：

• 文化
• 自動化
• 精益
• 測量
• 分享

請注意，它的形狀像三明治。 三個中間值更具技術性，而外部值與軟技能有關。 但所有文化的基礎是溝通：我們與其他團隊成員交換我們的價值觀和信念，直到我們就事情應該如何表現達成共識。

分享也是一樣。 分享食物等基本的東西不需要交流。 然而，手勢本身也可以被視為一種交流行為。 “我在乎你，所以我分享給你。” 我們不想將範圍僅限於口頭交流。

然而，分享想法和工具需要溝通。 我們應該如何分享它們？ 我們應該把它們放在哪裡？ 它們對團隊中的每個人有用還是只對較小的群體有用？

如果您只關注更技術性的方面——自動化、精益和測量——你就錯過了 DevOps 的重點。 擁有一個除了作者之外沒人使用的自動部署腳本有什麼好處？ 如果腳本為她節省了一些時間，那麼它可能是合理的。 但是想像一下，如果每個人都共享這個腳本，可以節省多少時間。 這說明了與浪費作鬥爭！

DevOps 讓業務更接近發展

有人說 DevOps 使運營更接近開發。 這是事實，但不是全部事實。 如果做得好，DevOps 會讓每個單元更接近。 它允許企業和客戶幾乎實時地看到開發正在做什麼。

這種更短的反饋循環有益於所有利益相關者。 這項工作通常更加明顯，開發人員也可以輕鬆地看到客戶如何使用他們生成的代碼。 使用傳統部署，您可以等待幾個月才能有人注意到錯誤或遺漏的需求。 通過持續部署，每個人都可以對出現的任何問題做出反應。 開發人員、運營人員、業務人員和客戶可以坐在一個房間裡，根據當前需要修改工作應用程序。

DevOps 工具優先？ 再想一想

當然，需要所有工具來實現它。

但是，任何工具都無法替代公司內部的良好溝通和同理心。 我曾經觀察過一個產品，其中構建過程歸一個團隊所有，而提供的代碼歸另一個團隊所有。

構建系統的問題很常見。 開發人員不確定如何使用它。 它基於標準工具，但它們經過定制，以至於網絡上可用的每個文檔都被證明是無用的。

每個人都想改善情況，但兩支球隊之間沒有任何默契。 這意味著雙方在沒有與對方協商的情況下引入了新工具。 這只會擴大差距，而不是縮小差距。

如果您想在組織內開始 DevOps 轉型，請從改進溝通方式開始。 不要簡單地假設解決方案：首先以開放的心態進行頭腦風暴。 然後您可能會發現，例如，工具支持不足以滿足您的需求。 那時您可以考慮調整您當前的工具或引入一些新的工具——否則您可能會增加原來的問題。

建立 DevOps 的最快方法？ 更好的溝通！

在介紹中，我提到了客戶經常問我的問題：“我應該使用 Docker 還是應該直接跳到 Kubernetes？” 閱讀本文後，您可以看到，在做一些準備工作之後，最好以 DevOps 的心態回答這樣的問題。

如果您知道您的產品團隊了解 DevOps 對自己和客戶的好處，那麼團隊和客戶可以從設定他們的期望開始。 然後工程師可以弄清楚開發和部署模型。 最後，您可以確定需要哪些工具。

一旦記錄了所有需求，就更容易做出技術選擇。

我是所有偉大的 DevOps 自動化工具的擁護者，這些工具使我們的工作更輕鬆、更易於管理。 但我們的日常工作是與人打交道。 讓我們花一些時間來改進 DevOps 最佳實踐的這一方面，而不是獲得另一個技術證書。