DevOps

menu icon

DevOps

DevOps 結合並自動執行軟體開發和 IT 作業團隊的工作,以加快高品質軟體的交付速度。

何謂 DevOps?

DevOps 透過定義概述軟體開發流程和組織文化變遷,其中藉由自動化並整合開發和 IT 作業團隊,這兩個團體在傳統上各行其事,或者說互不來往的工作來加速提供品質更高的軟體。

在實務上,最佳的 DevOps 流程和文化是超越開發和運作的,目標是將所有應用程式利害關係人 - 包括平台和基礎架構工程、安全、合規性、治理、風險管理、事業單位、一般使用者及客戶 - 的投入納進軟體開發生命週期中。

DevOps 代表過去 20多年來軟體交付週期演進的最新狀況,從每幾個月或每幾天發行巨型應用程式層面程式碼,到每天或一天數次頻繁反覆發行小規模特性或功能更新。

最終,DevOps 意味著滿足軟體使用者對於以下兩方面不斷增加的需求:頻繁且創新的新功能,以及不中斷的效能與可用性。

如何邁向 DevOps

直到 2000 年之前,大多數軟體都是使用瀑布方法進行開發與更新的,這是用於大型開發專案的線性方法。 軟體開發團隊花費數月時間開發新程式碼的龐大主體,其將影響大部分或整體的應用程式。 由於有大量變更,他們得多花數個月的時間把新程式碼整合到程式碼庫中。

接下來,品質保證 (QA)、安全和維運團隊將另外花好幾個月的時間來測試程式碼。 結果就是軟體版次之間相隔數月甚至數年,而且不同版次之間往往有數個重大的修補程式或錯誤修正程式。 而此功能交付的「大爆炸」方法,其特徵往往是複雜且有風險的部署計劃,很難安排與上游和下游系統互鎖,而且 IT「寄予厚望」的是,商業需求在幾個月內不會發生重大改變,這樣正式作業即可順利「上線」。

為了加速開發與提高品質,開發團隊開始採用敏捷軟體開發方法,這種方法是反覆而非線性的,重點在於為應用程式碼庫製作比較小但比較頻繁的更新項目。 在這些方法中主要項目是持續整合持續交付 (CI/CD)。 在 CI/CD 中,新程式碼的小型區塊每隔一或兩個星期會合併到程式碼庫中,然後自動執行整合、測試並準備好部署至正式作業環境中。 「敏捷」將 「大爆炸」方法演進為一連串「小片斷」,同時也將風險區隔化。

這些敏捷開發作法越有效地加速軟體開發與交付,被揭露的孤島 IT 作業就越多,例如: 系統佈建、配置,接受測試、管理、監視, 這些都是軟體交付生命週期當中的下一個瓶頸。

因此,DevOps 是從敏捷衍生而來的。 它增加了新的流程和工具,以將 CI/CD 的持續整合和自動化延伸到軟體交付生命週期的其餘部分。 此外,它還在此過程的每個步驟中,在開發和營運之間實施密切的協同作業。

DevOps 如何運作: DevOps 生命週期

顯示 DevOps 生命週期路徑的圖表

圖 1: DevOps 生命週期

DevOps 生命週期(有時稱為持續交付管線 - 在描繪其線性方式時)是一連串反覆的自動化開發過程或工作流程,它們在更廣大的自動化反覆開發生命週期,為了提供最佳的高品質軟體快速交付中執行。 視您詢問的對象而定,工作流程的名稱和數目可能會不一樣,但通常可分成以下六個:

  • 規劃(或構思)。在此工作流程中,團隊會琢磨下個版次的新增特性與功能,他們會從優先的一般使用者回饋與個案研討以及所有內部利害關係人的輸入進行挑選。 規劃階段的目標是將產品的商業價值最大化,方法是產生功能待辦事項,這些功能將會在交付時產生具有價值的預期結果。
  • 開發。這是程式設計步驟,其中開發人員測試、編碼,並根據待辦事項中的使用者腳本和工作項目來建置新增和加強功能。 一個實務作法組合,其中包括測試驅動的開發 (TDD)、配對程式設計、同儕程式碼審查以及其他常見作法。 開發人員通常會先使用其本端工作站來執行撰寫與測試程式碼的「內部迴圈」,然後再將程式碼往下傳到持續交付管線。
  • 整合(或建置,或者持續整合與持續交付 (CI/CD))。如上所述,在此工作流程中,新程式碼會整合到現有的程式碼庫中,然後進行測試並封裝成執行檔以供部署。 常見自動化活動包括將程式碼變更合併成「主要」副本、檢查原始碼儲存庫中的程式碼,然後自動編譯、單元測試並封裝成執行檔。 最佳作法是將 CI 階段的輸出儲存在二進位儲存庫中,以供下一個階段使用。
  • 部署(通常稱為持續部署。在這裡,(來自整合)的執行時期建置輸出將會部署至執行時期環境中 - 通常是一個開發環境,其中會為了品質、合規性及安全而進行執行時期測試。 如果發現錯誤或缺陷,開發人員就可以在任何一般使用者發現之前,搶先截取與補救任何問題。 通常會有開發、測試和正式作業等環境,而每個環境都需要越來「越嚴格」的品質門檻。 部署到正式作業環境的良好作法通常是,先部署到一般使用者的子集,然後在建立穩定性之後,最終部署至所有使用者。
  • 維運。將功能交付給正式作業環境會用「Day 1」來表示,然後一旦功能在正式作業中執行,就會出現「Day 2」作業。 監視功能的效能、行為及可用性,以確保這些保功能可以為一般使用者提供增值。 維運可確保功能順利執行,而且沒有任何服務中斷 - 藉由確定網路、儲存、平台、運算及安全狀態都很健康! 如果發生任何錯誤,維運可確保識別事件、警示適當人員、判定問題,以及套用修正程式。
  • 學習(有時稱為持續回饋)。這是指向一般使用者和客戶收集他們對於特性、功能、效能及商業價值的意見回饋,以便用來幫下一個版次規劃加強功能和特性。 其中還包括來自維運活動的任何學習和待辦事項,藉此加強開發人員的能力,以利主動避免在未來再次發生過去事件。 這是從「環繞」到「規劃階段」的發生點,而且我們會「持續改良」。

另外三個重要的持續工作流程出現在這些工作流程之間:

持續測試:標準 DevOps 生命週期包括出現在整合與部署之間的離散「測試」階段。 不過,DevOps 已經有所進步,測試的特定元素可以出現在規劃(行為驅動的開發)、開發(單元測試、合約測試)、整合(靜態程式碼掃描、CVE 掃描、Lint 分析)、部署(煙霧測試、滲透測試、配置測試)、維運(混沌測試、合規性測試),以及學習(A/B 測試)。 測試是一種強大的風險和漏洞識別形式,其可為 IT 提供接受、減輕或補救風險的機會。

安全:瀑布方法和敏捷實作都是在交付或部署之後才「添加」安全工作流程,DevOps 則致力於從一開始(規劃)就納入安全考量(這時最容易解決安全問題,同時也最不費力), 並且持續延伸到到整個開發週期的其餘部分。 這種安全方法稱為儘早測試(查看圖 1 比較容易理解)。 有些組織的儘早測試不如其他組織那麼成功,這造就了 DevSecOps 的崛起(見下文)。

合規性。合規性(治理和風險)也最好從開發生命週期的早期開始處理,然後延伸到整個開發生命週期中。 受監管的產業往往必須針對他們如何在其執行時期維運環境中交付與管理功能,提供一定程度的可觀察性、可追蹤性及存取權。 這需要在持續交付管線和執行時期環境中規劃、開發、測試與強制執行原則。 對於向第三方審核者證明合規性來說,合規措施的可審核性極為重要。

DevOps 文化

一般認為欠缺 DevOps 文化承諾的 DevOps 方法無法運作,這可歸結為軟體開發的不同組織和技術方法。

在組織層面上,DevOps 需要在所有軟體交付利害關係者之間進行持續溝通、協同作業和責任分攤, 軟體開發與 IT 維運團隊必不可少,但還要有安全、合規性、治理、風險及事業單位等團隊, 才能快速且持續地創新,並且從一開始就將品質納入軟體建置中。

在大多數情況下,完成此工作的最佳方法是打破這些孤島,並將它們重近組織成跨部門的自主 DevOps 團隊,以便能夠處理程式碼專案的開始到完成 (規劃意見回饋), 完全無需換手或等待其他團隊的核准。 在敏捷開發的脈絡下,責任分攤與協同作業是擁有共同產品焦點 的基石,而它會帶來寶貴成果。

在技術層面上,DevOps 需要承諾自動化,以便在工作流程內部和之間保持專案運轉,以及承諾意見回饋測量,以便讓團隊能夠持續加速循環週期,並改善軟體的品質與效能。

DevOps 工具: 建置 DevOps 工具鏈

DevOps 與 DevOps 文化等方面的需求催生了一些工具,以支援非同步協同作業、無縫整合 DevOps 工作流程,並儘可能自動執行整個 DevOps 生命週期。 DevOps 工具的種類包括:

  • 專案管理工具 - 這些工具可讓團隊建置形成編碼專案之使用者個案(需求)的待辦事項,將它們拆解成比較小的作業,並追蹤這些作業直到完成。 開發人員帶進 DevOps 中的許多工具都支援敏捷專案管理作法,例如 Scrum、Lean 及 Kanban。 熱門的開放原始碼選項包括 GitHub Issues 和 Jira。
  • 協同的原始碼儲存庫 - 實施版本控制的編碼環境,其可讓多位開發人員針對相同的程式碼庫進行處理。 程式碼儲存庫應該與 CI/CD、測試和安全工具等相整合,以便在儲存庫認可程式碼時,可以自動移至下一步。 開放原始碼儲存庫包括 GiHub 和 GitLab。
  • CI/CD 管線 - 這些工具可自動執行程式碼檢查、建置、測試及部署。 Jenkins 是這類工具中最受歡迎的開放原始碼工具;許多先前的開放原始碼替代方案,例如 CircleCI,現在都提供商業版本了。 說到持續部署 (CD) 工具,Spinnaker 會以程式碼層的形式橫跨在應用程式和基礎架構之間。 ArgoCD 是適用於 Kubernetes 原生 CI/CD 的另一個熱門開放原始碼選擇。
  • 測試自動化架構 - 其中包括用於提供自動化單元、合約、功能、效能、可用性、滲透及安全測試的軟體工具、程式庫和最佳作法。 這些工具最棒的地方是支援多種語言;有些使用人工智慧 (AI) 來自動重新配置測試,以便回應程式碼變更。 測試工具和架構的擴充十分廣泛! 熱門的開放原始碼測試自動化架構包括 Selenium、Appium、Katalon、Robot Framework 及 Serenity (舊稱 Thucidides)。
  • 配置管理(基礎架構即程式碼)工具 - 這些工具可讓 DevOps 工程師透過執行 Script 來配置與佈建完整版本化且完整記錄的基礎架構。 開放原始碼選項包括 Ansible (Red Hat)、Chef、Puppet 及 TerraformKubernetes 可為容器化應用程式執行相同功能(查看下面的「 DevOps 和雲端原生開發」)。
  • 監視工具 - 這些工具協助 DevOps 團隊識別與解決系統問題;它們還會即時收集與分析資料,以揭露程式碼變更如何影響應用程式效能。 開放原始碼監視工具包括 Datadog、Nagios、Prometheus 及 Splunk。
  • 持續回饋工具 - 這些工具可向使用者收集意見回饋,方法是透過熱圖(在畫面上記錄使用者的動作)、意見調查或自助式問題單。

DevOps 和雲端原生開發

雲端原生 是一種用來建置應用程式的方法,其中運用基礎雲端運算技術。 雲端原生的目標是跨公有雲、私有雲和多雲等環境,提供一致且最佳的應用程式開發、部署、管理及效能。

現今的雲端原生應用程式在建置時通常

  • 使用微服務 - 鬆散連結的可獨立部署元件,它們擁有自己的獨立自足堆疊,並透過 REST API、事件串流或訊息分配管理系統相互通訊。
  • 部署在容器 中 - 在可執行的程式碼單元中,包含了執行應用程式所需的所有程式碼、執行時期及作業系統相依關係。對於大部分的組織來說,「容器」是 Docker 容器的同義詞,然而其實還存在其他的容器類型。
  • 使用 Kubernetes 來(大規模)運作,此開放原始碼容器編排平台用於排程與自動執行容器化應用程式的部署、管理及擴充。

雲端原生開發與 DevOps 在許多方面可說是天生絕配。

例如,開發與更新微服務, 也就是將小單位程式碼的反覆遞送到一個小型程式碼庫, 可完美配合 DevOps 的快速發行和管理週期。 如果沒有 DevOps 部署和維運,將會難以處理微服務架構的複雜性。最近 IBM 對開發人員和 IT 主管所做的意見調查發現,78% 的現有微服務使用者預期將會對他們已投資的架構增加時間、金錢和心力投入,而 56% 的非使用者則可能在未來兩年採用微服務。 如果要探索特定微服務的某些優點及其所帶來的挑戰,請使用下面的互動式工具:

(資料來源: 'Microservices in the enterprise 2021: Real benefits, worth the challenges'。)

容器藉由封裝與永久修正所有 OS 相依關係,來提供快速的 CI/CD 和部署週期,因為所有的整合、測試及部署都會發生在相同環境中。 而 Kubernetes 編排可為非容器化應用程式執行與 Ansible、Puppet 及 Chef 為容器化應用程式執行的相同持續配置作業。

領先群倫的雲端運算供應商, 包括 AWS、Google、Microsoft Azure 及 IBM Cloud 都會提供某種受管理的 DevOps 管線解決方案。

何謂 DevSecOps?

DevSecOps 是指在整個 DevOps 生命週期中持續整合與自動執行資訊安全的 DevOps。 從開始到完成,從規劃到意見回饋,然後再回到規劃。

另一種說法是,DevSecOps 是 DevOps 從一開始就本該如此。 但在採用 DevOps 的早期會面臨兩個重大(且時間無法逾越的)挑戰,其一是將安全專業知識整合到跨部門團隊中(文化問題),其二是在 DevOps 生命週期中實作安全自動化(技術問題)。 在許多 DevOps 作法中,都認為資訊安全是「說不的團隊」,而且是一個成本高昂的瓶頸。

DevSecOps 以初衷就是專門努力整合與自動執行資訊安全的姿態出現。 在 DevSecOps 中,安全是指「一流」的公民和利害關係人以及開發與維運,並將安全帶進以產品為焦點的開發過程中。

觀看「何謂 DevSecOps?」以進一步瞭解 DevSecOps 的原則、優點和使用案例:

DevOps 和網站可靠性工程 (SRE)

網站可靠性工程 (SRE) 運用軟體工程技術來自動執行 IT 維運作業, 例如正式作業系統管理、變更管理、事件回應,甚至緊急應變, 這些可能原本由系統管理者手動執行。 SRE 試圖將典型的系統管理者轉換成工程師。

SRE 的最終目標類似於 DevOps 的目標,只是更加具體: SRE 旨在平衡組織對於快速應用程式開發的需求與以下需要:符合在客戶與一般使用者服務水準協定 (SLA) 中指定的效能和可用性等級。

網站可靠性工程師達成此平衡的方法是,決定可接受的應用程式維運風險等級,稱為「錯誤預算」, 以及自動執行維運以符合該等級。

在跨部門 DevOps 團隊中,SRE 可以做為開發和維運之間的橋樑,提供所需的衡量指標和自動化,以便團隊儘快透過 DevOps 管線推送程式碼變更和新功能,而且完全不會「打破」組織 SLA 的條款。

進一步瞭解網站可靠性工程

DevOps 與 IBM Cloud

DevOps 需要商業、開發與維運利害關係人協同作業,以便快速交付與執行可靠軟體。 在商業和 IT 維運的自動化需求不斷增加時,使用 DevOps 工具和作法的組織,可為數位轉型和應用程式現代化建立強大的基礎。

邁向更高度的自動化應該從可測量成功的小型專案開始,然後針對其他流程序和組織的其他部分進行擴充與最佳化。

您可以與 IBM 合作以取得 AI 型自動化功能,包括預先建置的工作流程,以便讓每個 IT 服務流程變得更有智慧、讓團隊撥出時間以專注於最重要的 IT 問題,並且加速創新。

進行下一步:

立即開始使用 IBM Cloud 帳戶

IBM Cloud Pak for Watson AIOps 使用機器學習和自然語言理解,即時在您維運工具鏈中的結構化和非結構化資料之間產生關聯,以利發掘隱藏的洞察並協助加速找出主要原因。 Watson AIOps 消除了多儀表板需求,將洞察與建議直接提供給您的團隊工作流程,以加速解決事件。

關於作者

Andrea C. Crawford 是一位 IBM 傑出工程師,她擁有傳統和現代 DevOps 的專業知識。 她熱衷於協助客戶透過人員、流程及工具現代化來轉換應用程式交付。 Andrea 喜歡探索具謀略性的「離群者」,像是園藝和騎摩托車。

https://twitter.com/acmthinks(IBM 外部鏈結)

https://medium.com/@acmThinks(IBM 外部鏈結)