DevOps 實踐指南

在去年大概一年的時間裡，我注意到對「Devops 實踐」感興趣的開發人員和系統管理員突然有了明顯的增加。這樣的變化也合理：現在開發者只要花很少的錢，調用一些 API，就能單槍匹馬地在一整套分散式基礎設施上運行自己的應用，在這個時代，開發和運維的緊密程度前所未有。我看過許多博客和文章介紹很酷的 DevOps 工具和相關思想，但是給那些希望踐行 DevOps 的人以指導和建議的內容，我卻很少看到。

這篇文章的目的就是描述一下如何去實踐。我的想法基於 Reddit 上 devops 的一些訪談、聊天和深夜討論，還有一些隨機談話，一般都發生在享受啤酒和美食的時候。如果你已經開始這樣實踐，我對你的反饋很感興趣，請通過我的博客或者 Twitter 聯繫我，也可以直接在下面評論。我很樂意聽到你們的想法和故事。

古代的 IT

了解歷史是搞清楚未來的關鍵，DevOps 也不例外。想搞清楚 DevOps 運動的普及和流行，去了解一下上世紀 90 年代後期和 21 世紀前十年 IT 的情況會有幫助。這是我的經驗。

我的第一份工作是在一家大型跨國金融服務公司做 Windows 系統管理員。當時給計算資源擴容需要給 Dell 打電話（或者像我們公司那樣打給 CDW），並下一個價值數十萬美元的訂單，包含伺服器、網路設備、電纜和軟體，所有這些都要運到生產或線下的數據中心去。雖然 VMware 仍在嘗試說服企業使用虛擬機運行他們的「性能敏感」型程序是更划算的，但是包括我們在內的很多公司都還是願意使用他們的物理機運行應用。

在我們技術部門，有一個專門做數據中心工程和運營的團隊，他們的工作包括價格談判，讓荒唐的月租能夠降一點點，還包括保證我們的系統能夠正常冷卻（如果設備太多，這個事情的難度會呈指數增長）。如果這個團隊足夠幸運足夠有錢，境外數據中心的工作人員對我們所有的伺服器型號又都有足夠的了解，就能避免在盤後交易中不小心搞錯東西。那時候亞馬遜 AWS 和 Rackspace 逐漸開始加速擴張，但還遠遠沒到臨界規模。

當時我們還有專門的團隊來保證硬體上運行著的操作系統和軟體能夠按照預期工作。這些工程師負責設計可靠的架構以方便給系統打補丁、監控和報警，還要定義 基礎鏡像 gold image 的內容。這些大都是通過很多手工實驗完成的，很多手工實驗是為了編寫一個 運行說明書 runbook 來描述要做的事情，並確保按照它執行後的結果確實在預期內。在我們這麼大的組織里，這樣做很重要，因為一線和二線的技術支持都是境外的，而他們的培訓內容只覆蓋到了這些運行說明而已。

（這是我職業生涯前三年的世界。我那時候的夢想是成為制定最高標準的人！）

軟體發布則完全是另外一頭怪獸。無可否認，我在這方面並沒有積累太多經驗。但是，從我收集的故事（和最近的經歷）來看，當時大部分軟體開發的日常大概是這樣：

• 開發人員按照技術和功能需求來編寫代碼，這些需求來自於業務分析人員的會議，但是會議並沒有邀請開發人員參加。
• 開發人員可以選擇為他們的代碼編寫單元測試，以確保在代碼里沒有任何明顯的瘋狂行為，比如除以 0 但不拋出異常。
• 然後開發者會把他們的代碼標記為 「Ready for QA」（準備好了接受測試），質量保障的成員會把這個版本的代碼發布到他們自己的環境中，這個環境和生產環境可能相似，也可能不，甚至和開發環境相比也不一定相似。
• 故障會在幾天或者幾個星期內反饋到開發人員那裡，這個時長取決於其它業務活動和優先事項。

雖然系統管理員和開發人員經常有不一致的意見，但是對「變更管理」卻一致痛恨。變更管理由高度規範的（就我當時的僱主而言）和非常必要的規則和程序組成，用來管理一家公司應該什麼時候做技術變更，以及如何做。很多公司都按照 ITIL 來操作，簡單的說，ITIL 問了很多和事情發生的原因、時間、地點和方式相關的問題，而且提供了一個過程，對產生最終答案的決定做審計跟蹤。

你可能從我的簡短歷史課上了解到，當時 IT 的很多很多事情都是手工完成的。這導致了很多錯誤。錯誤又導致了很多財產損失。變更管理的工作就是盡量減少這些損失，它常常以這樣的形式出現：不管變更的影響和規模大小，每兩周才能發布部署一次。周五下午 4 點到周一早上 5 點 59 分這段時間，需要排隊等候發布窗口。（諷刺的是，這種流程導致了更多錯誤，通常還是更嚴重的那種錯誤）

DevOps 不是專家團

你可能在想 「Carlos 你在講啥啊，什麼時候才能說到 Ansible playbooks？」，我喜歡 Ansible，但是請稍等 —— 下面這些很重要。

你有沒有過被分配到需要跟 DevOps 小組打交道的項目？你有沒有依賴過「配置管理」或者「持續集成/持續交付」小組來保證業務流水線設置正確？你有沒有在代碼開發完的數周之後才參加發布部署的會議？

如果有過，那麼你就是在重溫歷史，這個歷史是由上面所有這些導致的。

出於本能，我們喜歡和像自己的人一起工作，這會導致壁壘的形成。很自然，這種人類特質也會在工作場所表現出來是不足為奇的。我甚至在曾經工作過的一個 250 人的創業公司里見到過這樣的現象。剛開始的時候，開發人員都在聚在一起工作，彼此深度協作。隨著代碼變得複雜，開發相同功能的人自然就坐到了一起，解決他們自己的複雜問題。然後按功能劃分的小組很快就正式形成了。

在我工作過的很多公司里，系統管理員和開發人員不僅像這樣形成了天然的壁壘，而且彼此還有激烈的對抗。開發人員的環境出問題了或者他們的許可權太小了，就會對系統管理員很惱火。系統管理員怪開發人員無時無刻地在用各種方式破壞他們的環境，怪開發人員申請的計算資源嚴重超過他們的需要。雙方都不理解對方，更糟糕的是，雙方都不願意去理解對方。

大部分開發人員對操作系統，內核或計算機硬體都不感興趣。同樣，大部分系統管理員，即使是 Linux 的系統管理員，也都不願意學習編寫代碼，他們在大學期間學過一些 C 語言，然後就痛恨它，並且永遠都不想再碰 IDE。所以，開發人員把運行環境的問題甩給圍牆外的系統管理員，系統管理員把這些問題和甩過來的其它上百個問題放在一起安排優先順序。每個人都忙於怨恨對方。DevOps 的目的就是解決這種矛盾。

DevOps 不是一個團隊，CI/CD 也不是 JIRA 系統的一個用戶組。DevOps 是一種思考方式。根據這個運動來看，在理想的世界裡，開發人員、系統管理員和業務相關人將作為一個團隊工作。雖然他們可能不完全了解彼此的世界，可能沒有足夠的知識去了解彼此的積壓任務，但他們在大多數情況下能有一致的看法。

把所有基礎設施和業務邏輯都代碼化，再串到一個發布部署流水線里，就像是運行在這之上的應用一樣。這個理念的基礎就是 DevOps。因為大家都理解彼此，所以人人都是贏家。聊天機器人和易用的監控工具、可視化工具的興起，背後的基礎也是 DevOps。

Adam Jacob 說的最好：「DevOps 就是企業往軟體導向型過渡時我們用來描述操作的詞。」

要實踐 DevOps 我需要知道些什麼

我經常被問到這個問題，它的答案和同屬於開放式的其它大部分問題一樣：視情況而定。

現在「DevOps 工程師」在不同的公司有不同的含義。在軟體開發人員比較多但是很少有人懂基礎設施的小公司，他們很可能是在找有更多系統管理經驗的人。而其他公司，通常是大公司或老公司，已經有一個穩固的系統管理團隊了，他們在向類似於谷歌 SRE 的方向做優化，也就是「設計運維功能的軟體工程師」。但是，這並不是金科玉律，就像其它技術類工作一樣，這個決定很大程度上取決於他的招聘經理。

也就是說，我們一般是在找對深入學習以下內容感興趣的工程師：

• 如何管理和設計安全、可擴展的雲平台（通常是在 AWS 上，不過微軟的 Azure、Google Cloud Platform，還有 DigitalOcean 和 Heroku 這樣的 PaaS 提供商，也都很流行）。
• 如何用流行的 CI/CD 工具，比如 Jenkins、GoCD，還有基於雲的 Travis CI 或者 CircleCI，來構造一條優化的發布部署流水線和發布部署策略。
• 如何在你的系統中使用基於時間序列的工具，比如 Kibana、Grafana、Splunk、Loggly 或者 Logstash 來監控、記錄，並在變化的時候報警。
• 如何使用配置管理工具，例如 Chef、Puppet 或者 Ansible 做到「基礎設施即代碼」，以及如何使用像 Terraform 或 CloudFormation 的工具發布這些基礎設施。

容器也變得越來越受歡迎。儘管有人對大規模使用 Docker 的現狀表示不滿，但容器正迅速地成為一種很好的方式來實現在更少的操作系統上運行超高密度的服務和應用，同時提高它們的可靠性。（像 Kubernetes 或者 Mesos 這樣的容器編排工具，能在宿主機故障的時候，幾秒鐘之內重新啟動新的容器。）考慮到這些，掌握 Docker 或者 rkt 以及容器編排平台的知識會對你大有幫助。

如果你是希望做 DevOps 實踐的系統管理員，你還需要知道如何寫代碼。Python 和 Ruby 是 DevOps 領域的流行語言，因為它們是可移植的（也就是說可以在任何操作系統上運行）、快速的，而且易讀易學。它們還支撐著這個行業最流行的配置管理工具（Ansible 是使用 Python 寫的，Chef 和 Puppet 是使用 Ruby 寫的）以及雲平台的 API 客戶端（亞馬遜 AWS、微軟 Azure、Google Cloud Platform 的客戶端通常會提供 Python 和 Ruby 語言的版本）。

如果你是開發人員，也希望做 DevOps 的實踐，我強烈建議你去學習 Unix、Windows 操作系統以及網路基礎知識。雖然雲計算把很多系統管理的難題抽象化了，但是對應用的性能做調試的時候，如果你知道操作系統如何工作的就會有很大的幫助。下文包含了一些這個主題的圖書。

如果你覺得這些東西聽起來內容太多，沒關係，大家都是這麼想的。幸運的是，有很多小項目可以讓你開始探索。其中一個項目是 Gary Stafford 的選舉服務，一個基於 Java 的簡單投票平台。我們要求面試候選人通過一個流水線將該服務從 GitHub 部署到生產環境基礎設施上。你可以把這個服務與 Rob Mile 寫的了不起的 DevOps 入門教程結合起來學習。

還有一個熟悉這些工具的好方法，找一個流行的服務，然後只使用 AWS 和配置管理工具來搭建這個服務所需要的基礎設施。第一次先手動搭建，了解清楚要做的事情，然後只用 CloudFormation（或者 Terraform）和 Ansible 重寫剛才的手動操作。令人驚訝的是，這就是我們基礎設施開發人員為客戶所做的大部分日常工作，我們的客戶認為這樣的工作非常有意義！

需要讀的書

如果你在找 DevOps 的其它資源，下面這些理論和技術書籍值得一讀。

理論書籍

• Gene Kim 寫的 《 鳳凰項目 The Phoenix Project 》。這是一本很不錯的書，內容涵蓋了我上文解釋過的歷史（寫的更生動形象），描述了一個運行在敏捷和 DevOps 之上的公司向精益前進的過程。
• Terrance Ryan 寫的 《 佈道之道 Driving Technical Change 》。非常好的一小本書，講了大多數技術型組織內的常見性格特點以及如何和他們打交道。這本書對我的幫助比我想像的更多。
• Tom DeMarco 和 Tim Lister 合著的 《 人件 Peopleware 》。管理工程師團隊的經典圖書，有一點過時，但仍然很有價值。
• Tom Limoncelli 寫的 《 時間管理：給系統管理員 Time Management for System Administrators 》。這本書主要面向系統管理員，它對很多大型組織內的系統管理員生活做了深入的展示。如果你想了解更多系統管理員和開發人員之間的衝突，這本書可能解釋了更多。
• Eric Ries 寫的 《 精益創業 The Lean Startup 》。描述了 Eric 自己的 3D 虛擬形象公司，IMVU，發現了如何精益工作，快速失敗和更快盈利。
• Jez Humble 和他的朋友寫的 《 精益企業 Lean Enterprise 》。這本書是對精益創業做的改編，以更適應企業，兩本書都很棒，都很好地解釋了 DevOps 背後的商業動機。
• Kief Morris 寫的 《 基礎設施即代碼 Infrastructure As Code 》。關於「基礎設施即代碼」的非常好的入門讀物！很好的解釋了為什麼所有公司都有必要採納這種做法。
• Betsy Beyer、Chris Jones、Jennifer Petoff 和 Niall Richard Murphy 合著的 《 站點可靠性工程師 Site Reliability Engineering 》。一本解釋谷歌 SRE 實踐的書，也因為是「DevOps 誕生之前的 DevOps」被人熟知。在如何處理運行時間、時延和保持工程師快樂方面提供了有意思的看法。

技術書籍

如果你想找的是讓你直接跟代碼打交道的書，看這裡就對了。

• W. Richard Stevens 的 《 TCP/IP 詳解 TCP/IP Illustrated 》。這是一套經典的（也可以說是最全面的）講解網路協議基礎的巨著，重點介紹了 TCP/IP 協議族。如果你聽說過 1、2、3、4 層網路，而且對深入學習它們感興趣，那麼你需要這本書。
• Evi Nemeth、Trent Hein 和 Ben Whaley 合著的 《 UNIX/Linux 系統管理員手冊 UNIX and Linux System Administration Handbook 》。一本很好的入門書，介紹 Linux/Unix 如何工作以及如何使用。
• Don Jones 和 Jeffrey Hicks 合著的 《 Windows PowerShell 實戰指南 Learn Windows Powershell In A Month of Lunches 》。如果你在 Windows 系統下做自動化任務，你需要學習怎麼使用 Powershell。這本書能夠幫助你。Don Jones 是這方面著名的 MVP。
• 幾乎所有 James Turnbull 寫的東西，針對流行的 DevOps 工具，他發表了很好的技術入門讀物。

不管是在那些把所有應用都直接部署在物理機上的公司，（現在很多公司仍然有充分的理由這樣做）還是在那些把所有應用都做成 serverless 的先驅公司，DevOps 都很可能會持續下去。這部分工作很有趣，產出也很有影響力，而且最重要的是，它搭起橋樑銜接了技術和業務之間的缺口。DevOps 是一個值得期待的美好事物。

首次發表在 Neurons Firing on a Keyboard。使用 CC-BY-SA 協議。

via: https://opensource.com/article/18/1/getting-devops

作者：Carlos Nunez 譯者：belitex 校對：pityonline

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

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