第 0 天/第 1 天/第 2 天：雲時代的軟體生命週期

在當今的專業 IT 媒體中有一個非常突出的話題，那就是在軟體生命週期中的“第 0 天/第 1 天/第 2 天”。在演講和會議講話當中，通常著重於使軟體開發過程有效且易於管理，為此，有必要明確定義所使用的概念。通常，如果直觀地理解基本術語“第 0 天（Day 0）/第 1 天（Day 1）/第 2 天（Day 2）”，這在談論軟體生命週期時可能會引起一些歧義。因此，我決定更準確地定義它們，以展示軟體開發的整個過程以及它們在實際專案中的使用方式。這篇簡短的部落格文章提供了“天”的定義，這些“天”被理解為軟體生命週期的各個階段。它還描述了雲如何改變了有關軟體開發和維護過程的傳統思維方式。畢竟，正如《RightScale 2019 雲狀態報告》所確認的那樣，我們正處於“雲時代”。該報告解釋說，有 94％ 的調查受訪者正在使用雲（私有云或公有云）。因此，閒話少說，讓我們探討一下“天”和雲如何結合在一起。

“天”究竟是什麼？

在 IT 中，術語“第 0 天/第 1 天/第 2 天”指的是軟體生命週期的不同階段。用軍事術語來說，“第 0 天”是訓練的第一天，新兵進入訓練階段。在軟體開發中，它代表設計階段，在此階段中指定專案需求並確定解決方案的體系結構。

“第 1 天”涉及開發和部署在“第 0 天”階段設計的軟體。在此階段，我們不僅建立應用程式本身，還建立應用程式的基礎設施、網路、外部服務，並實現所有部分的初始配置。

“第 2 天”是產品出廠或交付給客戶的時間。在這裡，大部分工作都集中在維護、監控和優化系統上。分析系統的行為並做出正確的反應至關重要，因為所產生的反饋迴圈將一直持續到應用程式生命週期結束為止。

在雲時代之前的日子裡，這些階段是分別處理的，彼此之間沒有重疊。今天，情況已不再如此。讓我們看一下所有這些如何應用於現代應用程式的生命週期。

第 0 天：無聊但必不可少

第 0 天經常被忽略，因為它可能很無聊，但這並不會降低其重要性。成功的軟體產品是經過全面規劃和設計過程的結果。必須仔細計劃系統或應用程式的體系結構以及啟動和執行所需的資源（CPU、儲存空間、RAM）。其次，你應該定義可衡量的里程碑，以實現專案目標。每個里程碑應有一個準確的日期。這有助於衡量專案的進度，並確定你是否延遲了計劃執行。所有專案時間估算都應基於概率，而不僅僅是按最佳情況預估。進行計劃時，最好新增緩衝餘量，因為意外事件甚至可能使精心策劃的計劃陷入困境。測試階段也起著重要的作用，也應該包括在初始專案計劃中。這些是基本要求，它們在“雲時代”中同以往一樣重要。

 

儘管如此，在計算資源的第 0 天計劃中，雲還是改變了兩件事。由於雲可以在專案的任何地方獲得不同的資源或新資源（CPU、儲存空間、RAM），因此比本地基礎設施要容易得多。因此，可以避免在計劃階段犯下的一些錯誤。另一方面，在計劃階段對特定雲供應商的承諾可能會在以後導致供應商鎖定。這可能會花費你的金錢，並且需要時間來進行更改，因此選擇雲供應商時要明智一些。

其次，正如我們當前在向雲的遷移中觀察到的那樣，與運維相關的工作依舊保持不變，但不再專注於基礎設施。現在，正是軟體在推動著自動化和價值。

第 1 天：實現創意的階段

對於開發人員和專案負責人而言，第 1 天絕對是最有趣的階段。最初的設計得以實現，並根據專案的規範建立了基礎設施。為了成為真正的雲原生，必須遵守最佳實踐。可以遵循諸如十二要素應用程式方法（Twelve-Factor Apps methodology）之類的準則。此外，使用雲端意味著你應該遵循重要的 DevOps 慣例：持續整合/持續交付（如果你想了解有關 CI/CD 的更多資訊，請參閱我們的部落格文章）。

云為我們帶來了從傳統方法到軟體開發的重要變化：將第一行程式碼拼湊在一起以進行概念驗證後，應用程式即開始執行。你可以從持續整合實踐開始，以測試你的應用程式的健全性，但是你很快會讓企業邁入到持續交付。在開發應用程式時，我們開始引入一些運維元素，尤其是在使用多個環境的情況下。注意這些運維要素將使維護團隊在維護階段（第 2 天）的工作更加輕鬆。

在第 1 天期間可以使用幾種工具。可以將它們按解決的問題分組。這個列表的頂部應提及“基礎設施即程式碼（Infrastructure-as-a-code）”（IaaC）。 IaaC 就像應用程式或程式碼一樣管理運維環境。這種方法允許將 DevOps 最佳實踐（包括版本控制、虛擬化測試和持續監視）應用於驅動基礎設施的程式碼。這裡有很多工具可供我們使用，例如 Terraform、Ansible 或 Puppet 等。第二類工具與容器的自動化部署和管理的容器編排系統有關。Kubernetes 及其實現（例如 Google Kubernetes Engine 和亞馬遜的 Elastic Kubernetes Service）至關重要。最後，還有諸如 Jenkins、Zuul 和 CircleCI 之類的 CI/CD 系統，可幫助工程師自動化軟體的構建、測試以及交付或部署。

第 2 天：日常運維環節

一旦軟體準備就緒，它就會上線，客戶開始使用它。第 2 天始於此，並引入了包括軟體維護和客戶支援在內的各個元素。該軟體本身將不斷髮展，以適應不斷變化的需求和客戶需求。在第 2 天期間，主要重點是建立反饋迴圈。我們監控該應用程式的工作方式，收集使用者反饋並將其傳送給開發團隊，該團隊將在產品中實施該應用程式併發布新版本。軍事術語“觀察-導向-決定-行動（Observe-Orient-Decide-Act）”（OODA）恰當地抓住了這一階段發生的事情。

• 觀察：從監視系統獲取資訊（資源使用情況和指標，應用程式效能監控）。
• 導向：執行問題的根本原因分析。
• 決定：找到解決問題的方法。
• 行動：實施解決方案。

與戰鬥中一樣，該迴圈不斷重複。

監控程式基於服務水平協議（Service Level Agreement）（SLA）中定義的要求。 SLA 基於服務水平目標（Service Level Objectives）（SLO），代表我們的服務水平指標（Service Level Indicators）（SLI）的狀態。自動化和監控是解決第 2 天職責的關鍵。

有幾種工具可幫助完成第 2 天的工作。 應用程式效能監控（Application Performance Monitoring）（APM）類軟體可以幫助 IT 管理員監控應用程式效能，從而提供高質量的使用者體驗。在這裡，我們可以點名 Datadog、Dynatrace、SignalFX 或 Nutanix Xi Epoch。 還有一些自動化和編排工具，例如 Ansible 或 Kubernetes，可幫助管理應用程式環境。你可能已經注意到，這些工具的應用與第 1 天的工作重疊。最後，工單系統（例如 Servicedesk 或 Zendesk）可以處理客戶服務，使使用者可以報告故障以及與他們正在執行的應用程式有關的問題。 

雲將改變遊戲規則

在前雲時代，這些階段之間的分隔清晰可見，但是今天，隨著雲的日常執行，事物在不斷變化。使用雲和現代軟體開發實踐，可以更輕鬆地處理軟體生命週期中不斷變化的要求。持續整合/持續開發方法使我們能夠動態響應客戶反饋並實時改進應用程式，而無需等待主要版本進行改進。

基於雲和原生雲的軟體中的 DevOps 實踐有助於實現向左移動（shift left）（LCTT 譯註：環節前置的意思），這意味著傳統上一直保留到最後的步驟現在可以更快地執行。除此以外，這導致第 1 天和第 2 天現在相互重疊。此外，傳統軟體開發的最大痛點在於從第 1 天到第 2 天的過渡：從開發人員到運維人員的過渡。現在，DevOps 展示瞭如何解決此問題：及早啟動流程，並使流程一直執行到應用程式生命週期結束。最後但同樣重要的是，工具鏈正在完善，這使得執行第 1 天的任務和適應第 2 天的更改成為可能。 可以根據我們的需求對所使用的工具進行建模，並且過程中涉及的每個人都可以使用同一套工具。

訂閱“Linux 中國”官方小程式來檢視