歡迎光臨
每天分享高質量文章
當前位置：知識星球 > 後端 > 正文

所有你想要知道的 DevOps 基礎知識都在這裡

2019-05-27 分類：後端 閱讀(2753) 評論(0)

 

在當前的 IT 實踐中，為了支援高效和快捷的軟體開發，出現了巨大的轉變：在單體應用的軟體架構正在逐漸被微服務架構取代的情況下，開發、 QA 和運維團隊為了擺脫了之前相互孤立的狀況，開始相互關聯並融合統一，我們將其稱為DevOps。
當今如果一個技術驅動型企業想要以客戶為導向來進行快速的軟體迭代，那麼他們需要更快速的軟體開發和交付週期。而這些需求直接導致了 DevOps 文化的核心 CI/CD 實踐的誕生。

  • CI 持續整合：一種專註於使釋出更容易的軟體開發實踐。

  • CD 持續交付：是持續整合的延伸，以確保您可以以可持續的方式快速向客戶釋出新的更改。

早期整個 SDLC 都是線性和順序的，這拉長了產品的釋出週期。但隨著快速變化的市場動態、激烈的競爭和多變的客戶需求，這些都會導致公司無法繼續使用原先開發流程。他們必須更貼近客戶，需要不斷創新以保持他們的參與。而 DevOps 為此提供瞭解決方案，並被技術驅動的公司廣泛採用，用來改進其快速交付的流程和實踐。
那麼讓我們試著瞭解什麼是 DevOps ？

 

DevOps 的定義

 

提到 DevOps 我經常取用 w.r.t 的話：
任何公司在學會使用最佳 DevOps 實踐進行協作、統一和自動化所有開發和運維流程之前，都將無法擴充套件和維持。這是一種將每個人聯絡在一起實現共同標的的文化。
是時候讓所有團隊成員與他們的部門密切合作，採用工具和實踐來高效地交付軟體產品。
Atlassian 將 DevOps 定義為：
DevOps 是一組軟體開發和運維團隊之間的自動化流程實踐，以便他們可以快速、可靠地構建，測試和釋出軟體。DevOps 的概念建立在為過去相對孤立的團隊之間建立合作文化的基礎上。其帶來的好處包括更加可靠、更快的軟體釋出，快速解決關鍵問題的能力，以及更好地管理計劃外的工作。
Amazon 將 DevOps 定義為：
文化理念、實踐和工具的結合，提高了團隊的高速交付應用程式和服務的能力：與使用單體應用的軟體開發架構管理流程的團隊相比，以更快的速度開發和改進產品。這種速度使團隊能夠更好地為客戶服務，併在市場競爭中佔據有利地位。
Microsoft 以更簡化的方式定義 DevOps：
DevOps 可以為我們的終端客戶持續提供價值的人員，流程和產品的結合。
我認為 DevOps 的最佳解釋為：它是一種文化，是一種將人放在首位團隊理念，為他們提供適宜的環境，使他們能夠蓬勃發展，因此無論他們屬於什麼部門，都可以透過明確的流程進行協作和溝通，從而實現標的。

 

DevOps 是如何工作的？

 

如上所述，DevOps 沒有任何固定的規則和實踐，但它更像是透過來自不同部門具有不同的技能的團隊在一起以實現預期的結果的文化。那麼它實際上是如何工作的，讓我透過下圖簡要解釋一下：

因此，開發人員，QA 和運維團隊使用 CI/CD 實踐來實現客戶的預期標的。開發人員編寫程式碼並將其提交到 GitHub 等原始碼控制工具。DevOps 工程師使用 CI 工具來提取程式碼，來進行自動化測試，並透過 CD 工具部署到處理生產或測試伺服器。
開發和運維人員一起工作，並使用各種工具進行 CI/CD 和監控，以快速響應客戶需求並修複問題和錯誤。

 

DevOps工具在DevOps週期的各個階段

 

DevOps 工程師可以使用多種工具在整個 DevOps 生命週期的每個階段獲取期望的結果。
計劃
您可以使用 Jira 或 Azure DevOps Board 以敏捷方式管理和規劃您的工作。
開發
對於程式碼管理， Git 以分散式方式管理程式碼版本歷史、分支、推送和拉取機制的首要工具。您還可以使用 Microsoft TFVC（Team Foundation Version Control），這是一個集中版本控制系統。
測試
要進行自動化測試，您可以使用 Selenium 、 JUnit 和 Apache JMeter 。
整合
Jenkins 是目前最受歡迎的 CI 工具之一，它可以做到無縫地整合開發和運維流程。
其他 CI 工具還有 Travis ＆ Bamboo。
部署和配置管理
Docker 是最受歡迎和廣泛使用的持續部署工具之一。它也是軟體容器化工具。
其他部署和配置管理工具還有 Kubernetes 、 Chef 、Ansible 和 Puppet。
Kubernetes 是一個開源容器管理（編排）工具。其容器管理職責包括容器部署，容器擴充套件和伸縮以及容器的負載均衡。 （如果你想深入快速學習Kubernetes，可以報名參加我們組織的為期3天的Kubernetes實戰培訓，一線資深講師帶你從0開始上手Kubernetes。）
監控
將產品部署到正確的位置後，持續的監控就變得至關重要。 Nagios、 Splunk 和 New Relics 是廣泛使用的持續監控工具。

 

DevOps 最佳實踐

 

正如文章開頭所討論的那樣，為了使技術驅動的公司變得更加以客戶為導向，他們需要將自己從單體應用的軟體開發實踐轉變為為客戶釋出產品的敏捷方式。讓我們試著瞭解他們需要採用的最佳 DevOps 實踐：

  • 持續整合

  • 持續交付

  • 微服務

  • 基礎設施即程式碼

  • 監控和日誌

  • 溝通與協作

讓我簡要解釋一下：
持續整合
Amazon 將 CI 定義為：
DevOps 軟體開發實踐，開發人員定期將程式碼修改合併到中央儲存庫，然後執行自動構建和測試。持續整合通常是指軟體釋出過程的構建或整合階段，並且需要自動化元件（例如，CI 或構建服務）。持續整合的目的是更快地發現和解決問題，提高軟體質量，並減少驗證和釋出新軟體更新所需的時間。
持續交付
持續交付是一種軟體開發實踐，其中開發人員完成的任何程式碼更改都會自動為釋出到生產環境做好準備。
透過在構建階段之後將所有的程式碼更改部署到測試環境或生產環境，持續交付可在持續整合時進行擴充套件。
微服務：敏捷開發的架構
這是一種新的軟體設計方法，您可以將單個應用程式拆分為一組小型服務/模組。與單體應用架構將所有前端和後端程式碼庫以及資料庫都全部部署在同一個伺服器地址中相比，基於微服務架構的應用程式被分解為服務，其中每個伺服器都在其中執行使用基於 HTTP 的應用程式程式設計介面（API），透過定義良好的介面使自己與其他服務進行通訊。
按照 Amazon 的介紹：
微服務是圍繞業務能力構建的; 每項服務的範圍都是一個簡單的用途。您可以使用不同的框架或程式語言來編寫微服務並將它們作為單個服務或一組服務獨立部署。
基礎設施即程式碼：IaC
是透過機器可讀定義檔案（程式碼庫）管理和配置計算機資料中心的過程，而不是物理硬體配置或互動式配置工具。

Amazon 定義 IaC 為：
作為使用程式碼和軟體開發技術（例如版本控制和持續整合）來配置和管理基礎架構的實踐。雲服務的 API 驅動模型使開發人員和系統管理員能夠以程式設計方式大規模地與基礎架構互動，而不需要手動設定和配置資源。
因此，開發人員可以使用基於程式碼的工具與基礎架構進行互動，使其更像應用程式。這使得可以使用標準化樣式快速部署基礎架構和伺服器，使用最新的補丁和版本進行更新，或以副本的方式進行複製部署。
傳統的服務（生命週期）自動化和配置管理工具用於完成IaC。現在企業也在使用連續配置自動化工具或獨立的 IaC 框架，例如 Microsoft 的 PowerShell DSC 或 AWS CloudFormation。
監控與日誌
公司可以透過監控指標和日誌，來瞭解其應用程式和基礎架構的執行情況。APM（Application performance management 應用程式效能管理）將 IT 指標轉換為有意義的業務指標，致力於檢測和診斷複雜的應用程式效能問題，以維持預期的服務等級。
透過捕獲、分類、分析應用程式和基礎架構生成的資料和日誌，團隊可以瞭解更新是如何影響使用者的，從而深入瞭解問題或報錯的根本原因。
wiki 中介紹：
密切監控兩組效能指標。第一組效能指標定義了應用程式終端使用者所體驗的效能。效能的一個示例是峰值負載下的平均響應時間，包括載入和響應時間。

  • 負載是應用程式處理的事務量，例如，每秒事務數（tps）、每秒請求數、每秒頁數。在沒有被計算機的搜尋、計算、傳輸等需求載入的情況下，大多數應用程式都足夠快，這就是開發人員在開發過程中可能無法捕獲效能問題的原因。

  • 響應時間是應用程式在此類負載下響應使用者操作所需的時間。

溝通與協作
在我看來：
團隊中的 DevOps 作為一種實踐取得成功，需要2個基本支柱：溝通和協作，才能非常有效地工作。如果沒有這種感覺並理解緊密結合團隊工作的重要性，那麼採用 DevOps 最佳實踐將非常困難。
增加團隊中的溝通和協作是 DevOps文化 的關鍵方面之一。有了這種文化，團隊就會以良好的態度和動力聚集在一起，圍繞資訊共享建立強有力的文化規範，並透過溝通工具和應用促進溝通，使團隊的所有部門能夠更加緊密地協調共同的標的。

 

為何選擇DevOps？它的好處是什麼？

 

要瞭解 DevOps 提升的價值已經其如何被公司所採用：
讓我們看看由 veritis 帶給您的以下資訊圖表。
以上給出的圖表清楚地闡述了 DevOps 實踐的主要好處：
速度
DevOps 促進團隊的高速開發，以便您可以更快地為客戶進行創新，更好地適應不斷變化的市場，併在推動業務成果方面提高效率。
快速交付
透過基於 CI/CD 的 DevOps 文化，縮短了應用程式釋出週期，允許更快的客戶反饋和有意義的創新在團隊內的蓬勃發展。您可以更快地釋出新功能並修複錯誤，更快地響應客戶的需求並建立競爭優勢。
可靠性
DevOps 使您能夠透過持續整合和持續交付等實踐不斷提高您的軟體質量，以測試每項變更的功能和安全性。這造就了可靠和經過測試的應用程式和強大的基礎設施的開發。DevOps 持續監控和記錄實踐可以幫助您實時瞭解軟體的效能。
文化
DevOps 培養了一種偉大的工作文化，在其文化樣式下建立更有效的團隊，強調所有權和責任等價值觀。
安全
透過採用 DevOps 模型，組織可以使用基礎架即程式碼和策略即程式碼，在不犧牲安全性的情況下大規模定義和跟蹤合規性。他們可以在保持控制和合規性的同時快速進步。

 

DevOps 的挑戰

 

在團隊中實施 DevOps 文化並不容易。沒有標準的規則可以參考，它更像是改變個人和團隊的心態的遊戲。這就像要求人們離開他們的舒適區。
“當你試圖在團隊中帶來任何相當大的變化時，一開始可能看起來很難，但當你有足夠大的意願時，就會發生變化，並漸進達成標的。”
因此，讓我們看看採用 DevOps 作為文化的一些常見挑戰。
Dev Vs Ops 心態
由於長期的開發和運維團隊一直在孤立地工作，完成不同的任務。所以他們經過精心調整，以不同的方式思考和行動。開發人員試圖儘快創新並做出改變，運維人員則試圖保持 100％ 的服務可用性。他們的標的和優先事項是不同的，所以如果我們必須將 DevOps 作為團隊中的文化實踐，那麼如果他們的心態還是兩個孤立的部分，那麼 DevOps 必將黯然失色。
DevOps 的實踐就是將團隊整合在一起，打破 IT 組織內部的孤島。因此，將它們整合為統一單元以實現共同標的是任何公司在採用 DevOps 實踐時需要剋服的第一個障礙。
從傳統基礎設施轉向微服務架構
多年來，這些公司一直存在遺留的基礎設施，但如果他們必須快速創新，他們必須擺脫這種方法並採用更具可擴充套件性的微服務架構。將基礎設施即程式碼與微服務一起使用是邁向持續創新未來的又一步。
然而，將架構變為微服務架構系統存在很大的障礙。採用微服務架構需要採用最佳的 DevOps 實踐以及 CI/CD 實踐。這為團隊帶來了巨大的工作量和運維挑戰，同時也增加了成本因素。
確實，將開發與部署轉變為現代的軟體開發方案可能會很痛苦，但一旦採用就可以使您的團隊變得更加高效與可擴充套件。
開發和運維工具集的衝突

開發團隊的標的和指標完全不同，因此他們可能需要一個運維團隊可能不需要的工具集。因此，必須將兩個團隊聚集在一起，以瞭解他們兩者可以合作的位置，並整合對他們兩者都有意義的工具，並統一他們可以監控的標的和指標。
一些團隊可能不願意使用傳統工具，這些工具不僅技術上較差，而且由於相容性問題也會降低整個基礎架構的速度。因此，請確保正在使用的工具與公司的產品願景保持一致。

 

總結

 

無論我們在公司方面與個人方面有多麼不同，我們都必須摒棄差異並作為一個整體來實現客戶需求和解決客戶的問題。如果我們能夠在我們團隊的工作文化中吸收這種理念，那麼 DevOps 將成為重視過程和收益的寶貴實踐。
原文連結：https://medium.com/faun/all-about-devops-fundamentalsyou-ever-wanted-to-know-2333328a2b40
贊(0)
標籤：

相關推薦

熱門標籤

iOS (11238)微軟 (4955)Linux (4274)安全 (4180)Python (4161)效能 (3165)運維 (2774)最佳化 (2419).NET (2262)Google (2136)機器學習 (1795)併發 (1613)分散式 (1559)叢集 (1240)SQL (1174)Mysql (1060)區塊鏈 (1017)Docker (977)微服務 (922)面試 (919)Apache (743)NLP (725)Redis (719)Android (668)Git (640)架構師 (632)Nginx (630)Facebook (599)JVM (595)爬蟲 (476)

熱門文章

分享創造快樂