知識星球
https://opensource.com/article/18/1/getting-devops
作者 | Carlos Nunez
譯者 | BeliteX (belitex) ??共計翻譯：2.0 篇 貢獻時間：10 天
這些技巧或許對那些想要踐行 DevOps 的系統運維和開發者能有所幫助。
在去年大概一年的時間裡，我註意到對“Devops 實踐”感興趣的開發人員和系統管理員突然有了明顯的增加。這樣的變化也合理：現在開發者只要花很少的錢，呼叫一些 API，就能單槍匹馬地在一整套分散式基礎設施上執行自己的應用，在這個時代，開發和運維的緊密程度前所未有。我看過許多部落格和文章介紹很酷的 DevOps 工具和相關思想，但是給那些希望踐行 DevOps 的人以指導和建議的內容，我卻很少看到。
這篇文章的目的就是描述一下如何去實踐。我的想法基於 Reddit 上 devops[1] 的一些訪談、聊天和深夜討論，還有一些隨機談話，一般都發生在享受啤酒和美食的時候。如果你已經開始這樣實踐，我對你的反饋很感興趣，請透過我的部落格[2]或者 Twitter[3] 聯絡我，也可以直接在下麵評論。我很樂意聽到你們的想法和故事。
古代的 IT
瞭解歷史是搞清楚未來的關鍵，DevOps 也不例外。想搞清楚 DevOps 運動的普及和流行，去瞭解一下上世紀 90 年代後期和 21 世紀前十年 IT 的情況會有幫助。這是我的經驗。
我的第一份工作是在一家大型跨國金融服務公司做 Windows 系統管理員。當時給計算資源擴容需要給 Dell 打電話（或者像我們公司那樣打給 CDW），並下一個價值數十萬美元的訂單，包含伺服器、網路裝置、電纜和軟體，所有這些都要運到生產或線下的資料中心去。雖然 VMware 仍在嘗試說服企業使用虛擬機器執行他們的“效能敏感”型程式是更划算的，但是包括我們在內的很多公司都還是願意使用他們的物理機執行應用。
在我們技術部門，有一個專門做資料中心工程和運營的團隊，他們的工作包括價格談判，讓荒唐的月租能夠降一點點，還包括保證我們的系統能夠正常冷卻（如果裝置太多，這個事情的難度會呈指數增長）。如果這個團隊足夠幸運足夠有錢，境外資料中心的工作人員對我們所有的伺服器型號又都有足夠的瞭解，就能避免在盤後交易中不小心搞錯東西。那時候亞馬遜 AWS 和 Rackspace 逐漸開始加速擴張，但還遠遠沒到臨界規模。
當時我們還有專門的團隊來保證硬體上執行著的作業系統和軟體能夠按照預期工作。這些工程師負責設計可靠的架構以方便給系統打補丁、監控和報警，還要定義基礎映象的內容。這些大都是透過很多手工實驗完成的，很多手工實驗是為了編寫一個執行說明書來描述要做的事情，並確保按照它執行後的結果確實在預期內。在我們這麼大的組織裡，這樣做很重要，因為一線和二線的技術支援都是境外的，而他們的培訓內容只改寫到了這些執行說明而已。
（這是我職業生涯前三年的世界。我那時候的夢想是成為制定最高標準的人！）
軟體釋出則完全是另外一頭怪獸。無可否認，我在這方面並沒有積累太多經驗。但是，從我收集的故事（和最近的經歷）來看，當時大部分軟體開發的日常大概是這樣：
雖然系統管理員和開發人員經常有不一致的意見，但是對“變更管理”卻一致痛恨。變更管理由高度規範的（就我當時的僱主而言）和非常必要的規則和程式組成，用來管理一家公司應該什麼時候做技術變更，以及如何做。很多公司都按照 ITIL[4] 來操作，簡單的說，ITIL 問了很多和事情發生的原因、時間、地點和方式相關的問題，而且提供了一個過程，對產生最終答案的決定做審計跟蹤。
你可能從我的簡短歷史課上瞭解到，當時 IT 的很多很多事情都是手工完成的。這導致了很多錯誤。錯誤又導致了很多財產損失。變更管理的工作就是儘量減少這些損失，它常常以這樣的形式出現：不管變更的影響和規模大小，每兩周才能釋出部署一次。週五下午 4 點到週一早上 5 點 59 分這段時間，需要排隊等候釋出視窗。（諷刺的是，這種流程導致了更多錯誤，通常還是更嚴重的那種錯誤）
DevOps 不是專家團
你可能在想 “Carlos 你在講啥啊，什麼時候才能說到 Ansible playbooks？”，我喜歡 Ansible，但是請稍等 —— 下麵這些很重要。
你有沒有過被分配到需要跟 DevOps 小組打交道的專案？你有沒有依賴過“配置管理”或者“持續整合/持續交付”小組來保證業務流水線設定正確？你有沒有在程式碼開發完的數周之後才參加釋出部署的會議？
如果有過，那麼你就是在重溫歷史，這個歷史是由上面所有這些導致的。
出於本能，我們喜歡和像自己的人一起工作，這會導致壁壘[5]的形成。很自然，這種人類特質也會在工作場所表現出來是不足為奇的。我甚至在曾經工作過的一個 250 人的創業公司裡見到過這樣的現象。剛開始的時候，開發人員都在聚在一起工作，彼此深度協作。隨著程式碼變得複雜，開發相同功能的人自然就坐到了一起，解決他們自己的複雜問題。然後按功能劃分的小組很快就正式形成了。
在我工作過的很多公司裡，系統管理員和開發人員不僅像這樣形成了天然的壁壘，而且彼此還有激烈的對抗。開發人員的環境出問題了或者他們的許可權太小了，就會對系統管理員很惱火。系統管理員怪開發人員無時無刻地在用各種方式破壞他們的環境，怪開發人員申請的計算資源嚴重超過他們的需要。雙方都不理解對方，更糟糕的是，雙方都不願意去理解對方。
大部分開發人員對作業系統，核心或計算機硬體都不感興趣。同樣，大部分系統管理員，即使是 Linux 的系統管理員，也都不願意學習編寫程式碼，他們在大學期間學過一些 C 語言，然後就痛恨它，並且永遠都不想再碰 IDE。所以，開發人員把執行環境的問題甩給圍牆外的系統管理員，系統管理員把這些問題和甩過來的其它上百個問題放在一起安排優先順序。每個人都忙於怨恨對方。DevOps 的目的就是解決這種矛盾。
DevOps 不是一個團隊，CI/CD 也不是 JIRA 系統的一個使用者組。DevOps 是一種思考方式。根據這個運動來看，在理想的世界裡，開發人員、系統管理員和業務相關人將作為一個團隊工作。雖然他們可能不完全瞭解彼此的世界，可能沒有足夠的知識去瞭解彼此的積壓任務，但他們在大多數情況下能有一致的看法。
把所有基礎設施和業務邏輯都程式碼化，再串到一個釋出部署流水線裡，就像是執行在這之上的應用一樣。這個理念的基礎就是 DevOps。因為大家都理解彼此，所以人人都是贏家。聊天機器人和易用的監控工具、視覺化工具的興起，背後的基礎也是 DevOps。
Adam Jacob[6] 說的最好：“DevOps 就是企業往軟體導向型過渡時我們用來描述操作的詞。”
要實踐 DevOps 我需要知道些什麼
我經常被問到這個問題，它的答案和同屬於開放式的其它大部分問題一樣：視情況而定。
現在“DevOps 工程師”在不同的公司有不同的含義。在軟體開發人員比較多但是很少有人懂基礎設施的小公司，他們很可能是在找有更多系統管理經驗的人。而其他公司，通常是大公司或老公司，已經有一個穩固的系統管理團隊了，他們在向類似於谷歌 SRE[7] 的方向做最佳化，也就是“設計運維功能的軟體工程師”。但是，這並不是金科玉律，就像其它技術類工作一樣，這個決定很大程度上取決於他的招聘經理。
也就是說，我們一般是在找對深入學習以下內容感興趣的工程師：
容器也變得越來越受歡迎。儘管有人對大規模使用 Docker 的現狀表示不滿[9]，但容器正迅速地成為一種很好的方式來實現在更少的作業系統上執行超高密度的服務和應用，同時提高它們的可靠性。（像 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 的選舉服務[10]，一個基於 Java 的簡單投票平臺。我們要求面試候選人透過一個流水線將該服務從 GitHub 部署到生產環境基礎設施上。你可以把這個服務與 Rob Mile 寫的了不起的 DevOps 入門教程[11]結合起來學習。
還有一個熟悉這些工具的好方法，找一個流行的服務，然後只使用 AWS 和配置管理工具來搭建這個服務所需要的基礎設施。第一次先手動搭建，瞭解清楚要做的事情，然後只用 CloudFormation（或者 Terraform）和 Ansible 重寫剛才的手動操作。令人驚訝的是，這就是我們基礎設施開發人員為客戶所做的大部分日常工作，我們的客戶認為這樣的工作非常有意義！
需要讀的書
如果你在找 DevOps 的其它資源，下麵這些理論和技術書籍值得一讀。
理論書籍
技術書籍
如果你想找的是讓你直接跟程式碼打交道的書，看這裡就對了。
不管是在那些把所有應用都直接部署在物理機上的公司，（現在很多公司仍然有充分的理由這樣做）還是在那些把所有應用都做成 serverless 的先驅公司，DevOps 都很可能會持續下去。這部分工作很有趣，產出也很有影響力，而且最重要的是，它搭起橋梁銜接了技術和業務之間的缺口。DevOps 是一個值得期待的美好事物。
首次發表在 Neurons Firing on a Keyboard[24]。使用 CC-BY-SA 協議。
via: https://opensource.com/article/18/1/getting-devops
作者：Carlos Nunez[26] 譯者：belitex 校對：pityonline
本文由 LCTT 原創編譯，Linux中國 榮譽推出