容器技術對 DevOps 的一些啟發

有人說容器技術與 DevOps 二者在發展的過程中是互相促進的關係。得益於 DevOps 設計理念的流行，容器生態系統在設計上與組件選擇上也有相應發展。同時，由於容器技術在生產環境中的使用，反過來也促進了 DevOps 三大主要實踐：支撐 DevOps 的三個實踐。

工作流

容器中的工作流

每個容器都可以看成一個獨立的運行環境，對於容器內部，不需要考慮外部的宿主環境、集群環境，以及其它基礎設施。在容器內部，每個功能看起來都是以傳統的方式運行。從外部來看，容器內運行的應用一般作為整個應用系統架構的一部分：比如 web API、web app 用戶界面、資料庫、任務執行、緩存系統、垃圾回收等。運維團隊一般會限制容器的資源使用，並在此基礎上建立完善的容器性能監控服務，從而降低其對基礎設施或者下游其他用戶的影響。

現實中的工作流

那些跟「容器」一樣業務功能獨立的團隊，也可以借鑒這種容器思維。因為無論是在現實生活中的工作流（代碼發布、構建基礎設施，甚至製造 《傑森一家》中的斯貝斯利太空飛輪 等），還是技術中的工作流（開發、測試、運維、發布）都使用了這樣的線性工作流，一旦某個獨立的環節或者工作團隊出現了問題，那麼整個下游都會受到影響，雖然使用這種線性的工作流有效降低了工作耦合性。

DevOps 中的工作流

DevOps 中的第一條原則，就是掌控整個執行鏈路的情況，努力理解系統如何協同工作，並理解其中出現的問題如何對整個過程產生影響。為了提高流程的效率，團隊需要持續不斷的找到系統中可能存在的性能浪費以及問題，並最終修復它們。

踐行這樣的工作流後，可以避免將一個已知缺陷帶到工作流的下游，避免局部優化導致可能的全局性能下降，要不斷探索如何優化工作流，持續加深對於系統的理解。

—— Gene Kim，《支撐 DevOps 的三個實踐》，IT 革命，2017.4.25

反饋

容器中的反饋

除了限制容器的資源，很多產品還提供了監控和通知容器性能指標的功能，從而了解當容器工作不正常時，容器內部處於什麼樣的狀態。比如目前流行的 Prometheus，可以用來收集容器和容器集群中相應的性能指標數據。容器本身特別適用於分隔應用系統，以及打包代碼和其運行環境，但同時也帶來了不透明的特性，這時，從中快速收集信息來解決其內部出現的問題就顯得尤為重要了。

現實中的反饋

在現實中，從始至終同樣也需要反饋。一個高效的處理流程中，及時的反饋能夠快速地定位事情發生的時間。反饋的關鍵詞是「快速」和「相關」。當一個團隊被淹沒在大量不相關的事件時，那些真正需要快速反饋的重要信息很容易被忽視掉，並向下游傳遞形成更嚴重的問題。想像下如果露西和埃塞爾能夠很快地意識到：傳送帶太快了，那麼製作出的巧克力可能就沒什麼問題了（儘管這樣就不那麼搞笑了）。（LCTT 譯註：露西和埃塞爾是上世紀 50 年代的著名黑白情景喜劇《我愛露西》中的主角）

DevOps 中的反饋

DevOps 中的第二條原則，就是快速收集所有相關的有用信息，這樣在問題影響到其它開發流程之前就可以被識別出。DevOps 團隊應該努力去「優化下游」，以及快速解決那些可能會影響到之後團隊的問題。同工作流一樣，反饋也是一個持續的過程，目標是快速的獲得重要的信息以及當問題出現後能夠及時地響應。

快速的反饋對於提高技術的質量、可用性、安全性至關重要。

—— Gene Kim 等人，《DevOps 手冊：如何在技術組織中創造世界級的敏捷性，可靠性和安全性》，IT 革命，2016

持續學習

容器中的持續學習

踐行第三條原則「持續學習」是一個不小的挑戰。在不需要掌握太多邊緣的或難以理解的東西的情況下，容器技術讓我們的開發工程師和運營團隊依然可以安全地進行本地和生產環境的測試，這在之前是難以做到的。即便是一些激進的實驗，容器技術仍然讓我們輕鬆地進行版本控制、記錄和分享。

現實中的持續學習

舉個我自己的例子：多年前，作為一個年輕、初出茅廬的系統管理員（僅僅工作三周），我被安排對一個運行著某個大學核心 IT 部門網站的 Apache 虛擬主機配置進行更改。由於沒有方便的測試環境，我直接在生產站點上修改配置，當時覺得配置沒問題就發布了，幾分鐘後，我無意中聽到了隔壁同事說：

「等會，網站掛了？」

「沒錯，怎麼回事？」

很多人蒙圈了……

在被嘲諷之後（真實的嘲諷），我一頭扎在工作台上，趕緊撤銷我之前的更改。當天下午晚些時候，部門主管 —— 我老闆的老闆的老闆 —— 來到我的工位詢問發生了什麼事。「別擔心，」她告訴我。「我們不會責怪你，這是一個錯誤，現在你已經學會了。」

而在容器中，這種情形在我的筆記本上就很容易測試了，並且也很容易在部署生產環境之前，被那些經驗老道的團隊成員發現。

DevOps 中的持續學習

持續學習文化的一部分是我們每個人都希望通過一些改變從而能夠提高一些東西，並勇敢地通過實驗來驗證我們的想法。對於 DevOps 團隊來說，失敗無論對團隊還是個人來說都是成長而不是懲罰，所以不要畏懼失敗。團隊中的每個成員不斷學習、共享，也會不斷提升其所在團隊與組織的水平。

隨著系統越來越被細分，我們更需要將注意力集中在具體的點上：上面提到的兩條原則主要關注整體流程，而持續學習關注的則是整個項目、人員、團隊、組織的未來。它不僅對流程產生了影響，還對流程中的每個人產生影響。

實驗和冒險讓我們能夠不懈地改進我們的工作，但也要求我們嘗試之前未用過的工作方式。

—— Gene Kim 等人，《鳳凰計劃：讓你了解 IT、DevOps 以及如何取得商業成功》，IT 革命，2013

容器技術帶給 DevOps 的啟迪

有效地應用容器技術可以學習 DevOps 的三條原則：工作流，反饋以及持續學習。從整體上看應用程序和基礎設施，而不是對容器外的東西置若罔聞，教會我們考慮到系統的所有部分，了解其上游和下游影響，打破隔閡，並作為一個團隊工作，以提升整體表現和深度了解整個系統。通過努力提供及時準確的反饋，我們可以在組織內部創建有效的反饋機制，以便在問題發生影響之前發現問題。最後，提供一個安全的環境來嘗試新的想法並從中學習，教會我們創造一種文化，在這種文化中，失敗一方面促進了我們知識的增長，另一方面通過有根據的猜測，可以為複雜的問題帶來新的、優雅的解決方案。

via: https://opensource.com/article/18/9/containers-can-teach-us-devops

作者：Chris Hermansen 選題：lujun9972 譯者：littleji 校對：pityonline, wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive