DevOps 檢查清單

  • 發行項

DevOps 是將開發、質量保證和IT作業整合到統一的文化特性和一組提供軟體的程式。 使用此檢查清單作為評估 DevOps 文化和程式的起點。

文化特性

確保組織與小組之間的業務一致。 組織內資源、用途、目標和優先順序的衝突可能會對成功的作業造成風險。 請確定業務、開發和營運小組都一致。

請確定您的小組瞭解您的軟體生命週期。 您的小組必須瞭解應用程式的整體生命週期，以及每個應用程式在該生命週期內的位置。 擁有這項資訊可協助所有小組成員知道他們現在應該做什麼，以及他們未來應該規劃及準備的內容。

縮短週期時間。 旨在將從想法移至可用開發軟體所需的時間降到最低。 限制個別版本的大小和範圍，以降低測試負擔。 盡可能自動化建置、測試、設定和部署程式。 清除開發人員與營運小組之間通訊的任何障礙。

檢閱和改善程式。 您的程式和程式，無論是自動化和手動，都永遠不會是最終的。 設定目前工作流程、程序和檔的定期檢閱，以持續改善為目標。

進行主動式規劃。 主動規劃失敗。 有流程可快速找出問題發生時、將問題呈報給正確的小組成員以修正，並確認其解決方式。

從失敗中學習。 失敗是不可避免的，但請務必從失敗中學習，以避免重複失敗。 如果發生作業失敗，請分級問題、記錄原因和解決方案，並分享您學到的任何課程。 盡可能更新您的組建程式，以在未來自動偵測這類失敗。

優化速度，並收集數據。 每個計劃改進都是假設。 盡可能以最小的增量工作。 將新想法視為實驗。 檢測實驗，以便收集生產數據以評估實驗有效性。 如果假設錯誤，請準備好快速失敗。

允許學習時間。 失敗和成功提供學習的機會。 在繼續進行新專案之前，請讓時間收集重要的課程，並確定您的小組會吸收這些課程。 也讓您的小組有時間建置技能、實驗及瞭解新的工具和技術。

檔作業。 記錄所有工具、程式和自動化工作，其品質層級與您的原始程式碼相同。 記錄您支援之任何系統的目前設計和架構，以及復原程式和其他維護程式。 將焦點放在您實際執行的步驟上，而不是理論上的最佳程式。 定期檢閱並更新您的檔。 針對程序代碼，請務必包含有意義的批注，特別是在公用 API 中。 使用工具盡可能自動產生程式代碼檔。

分享知識。 只有在人們知道檔存在且可以找到檔時才有用。 讓您的檔保持組織，並使其易於探索。 有創意：使用棕色袋（非正式簡報）、視頻或電子報分享知識。

部署

為開發人員提供類似生產環境的環境。 如果開發和測試環境不符合您的生產環境，則很難測試和診斷問題。 盡可能讓開發和測試環境與生產環境保持接近。 請確定測試數據與您在生產環境中使用的數據一致，即使它是範例數據，而不是實際生產數據（基於隱私權或合規性考慮）。 規劃產生和匿名範例測試數據。

請確定所有授權的小組成員都可以布建基礎結構並部署應用程式。 設定類似生產環境的資源和部署應用程式不應涉及複雜的手動工作或系統的詳細技術知識。 任何具有適當許可權的人都應該能夠建立或部署類似生產環境的資源，而不需要前往您的營運小組。

這項建議並不表示任何人都可以將即時更新推送至生產部署。 這是關於減少開發和 QA 小組的摩擦，以建立類似生產的環境。

檢測每個應用程式以取得深入解析。 若要瞭解應用程式的健康情況，您必須瞭解其執行方式，以及它們是否遇到任何錯誤或問題。 一律包含檢測作為設計需求，並從頭開始將檢測建置至每個應用程式。 檢測必須包含事件記錄以進行根本原因分析，但也包含遙測和計量，以監視每個應用程式的健康情況和使用方式。

追蹤您的技術債務。 許多專案會將發行排程的優先順序設定為程式代碼品質的一或多個程度。 一律會在採取快捷方式或其他次佳實作時記錄，並排程時間重新瀏覽這些問題。

請考慮將更新直接推送至生產環境。 若要減少整體發行週期時間，請考慮直接將經過正確測試的程式代碼認可推送至生產環境。 使用 功能切換 來控制您啟用的功能。 然後，您可以使用切換來啟用或停用功能，從開發快速移至發行。 當您執行 Canary 版本之類的測試時，切換也會很有用，您可以在其中將特定功能部署到生產環境的子集。

測試

自動化測試。 手動測試軟體很乏味且容易發生錯誤。 將一般測試工作自動化，並將測試整合到組建程式中。 自動化測試可確保一致的測試涵蓋範圍和重現性。 當您執行整合式 UI 測試時，也使用自動化工具。 Azure 提供開發和測試資源，可協助您設定和執行測試。 如需詳細資訊，請參閱 在 Azure 上開發和測試。

測試失敗。 當系統無法連線到服務時，系統應該會正常回應。 當服務再次可供使用時，系統應該會復原。 讓錯誤插入測試成為測試和預備環境檢閱的標準部分。 當您的測試程式和做法成熟時，請考慮在生產環境中執行這些測試。

在生產環境中測試。 發行程式不會在部署到生產環境時結束。 已設定測試，以確保已部署的程式代碼如預期般運作。 針對您不常更新的部署，請將生產測試排程為維護的一般部分。

自動化效能測試，以儘早找出效能問題。 嚴重效能問題的影響可能和程序代碼中的 Bug 一樣嚴重。 雖然自動化功能測試可以防止應用程式錯誤，但這些測試可能無法偵測效能問題。 為計量定義可接受的效能目標，例如延遲、載入時間和資源使用量。 在發行管線中包含自動化效能測試，以確保您的應用程式符合這些目標。

執行容量測試。 應用程式可能會在測試條件下正常運作，然後在生產環境中因規模或資源限制而發生問題。 一律定義預期的容量和使用量限制上限。 測試以確定應用程式可以處理這些限制，但也會測試當您超過這些限制時會發生什麼事。 定期進行容量測試。

初始版本之後，每當更新生產程序代碼時，您應該執行效能和容量測試。 使用歷程記錄數據來微調測試，並判斷您需要執行的測試類型。

執行自動化安全性滲透測試。 確保應用程式的安全性與測試任何其他功能一樣重要。 讓自動化滲透測試成為建置和部署程序的標準部分。 排程已部署應用程式的定期安全性測試和弱點掃描、監視開啟的埠、端點和攻擊。 自動化測試不會定期移除深入安全性檢閱的需求。

執行自動化商務持續性測試。 開發大規模商務持續性的測試，包括備份復原和故障轉移。 設定自動化程式以定期執行這些測試。

版本

自動執行部署。 自動化提供許多優點，包括：

  • 啟用更快速且更可靠的部署。
  • 確保任何支持環境的一致部署，包括測試、預備和生產環境。
  • 拿掉手動部署可能會引入人為錯誤的風險。
  • 讓您輕鬆排程發行以方便的時間，以將潛在停機時間的任何影響降到最低。

將每個應用程式部署至測試、預備和生產環境的程式自動化。 讓系統在推出期間偵測任何問題，並透過自動化方式向前復原修正或回復變更。

使用持續整合。 持續整合 （CI） 是將所有開發人員程式代碼合併成以一般排程為基礎的中央程式代碼，然後自動執行標準建置和測試程式的做法。 CI 可確保整個小組可以同時在程式碼基底上工作，而不會發生衝突。 CI 也協助您儘早找到程式碼缺失。 最好每次認可或簽入程序代碼時，CI 進程都應該執行。 它應該每天至少執行一次。

請考慮採用 主幹型開發模型。 在此模型中，開發人員會認可至單一分支（主幹）。 認可永遠不會中斷組建的需求。 此模型有助於 CI，因為您在主幹中執行所有功能工作，而且會在每次認可發生時解決任何合併衝突。

請考慮使用持續傳遞。 持續傳遞 （CD） 是確保程式碼一律準備好部署的做法，方法是自動建置、測試及將程式代碼部署至類似生產環境。 新增 CD 以建立完整的 CI/CD 管線，可協助您儘快偵測程式代碼缺失。 它也可確保您可以在短時間內發行經過適當測試的更新。

持續 部署 是一個程式，可自動採用任何透過 CI/CD 管線傳遞的更新，並將其部署至生產環境。 持續部署需要強固的自動測試和進階程序規劃。 它可能不適合所有小組。

進行小型累加變更。 大型程式代碼變更可能會比較小的程式碼變更更可能引進 Bug。 盡可能保留變更。 這樣做會限制每個變更的潛在影響，並簡化瞭解和偵錯問題的工作。

控制變更的風險。 請確定您控制使用者看到更新的時間。 請考慮在用戶開啟功能時使用功能切換來控制。

實作發行管理策略來降低部署風險。 將應用程式更新部署至生產環境一律會產生一些風險。 若要將此風險降到最低，請使用 Canary 版本或藍/綠部署等策略，將更新部署至使用者子集。 確認每個更新如預期般運作，然後將每個更新推出至系統的其餘部分。

記錄所有變更。 次要更新和設定變更可能是混淆和版本設定衝突的來源。 無論變更多麼小，永遠保持清楚的記錄。 記錄所有變更，包括您套用的修補程式、原則變更和設定變更。 您的整個小組應該可以看到變更的記錄。 但不包含這些記錄中的敏感數據。 例如，記錄認證已更新，以及進行變更的人員，但不會記錄更新的認證。

請考慮讓基礎結構不可變。 不可變的基礎結構是以將基礎結構部署至生產環境之後不應修改基礎結構的原則為基礎。 否則，您可以進入已套用臨機操作變更的狀態，因此很難確切知道變更的內容。 固定基礎結構的運作方式是將整個伺服器取代為任何新部署的一部分。 使用這種方法，您可以測試及部署程式代碼和裝載環境作為區塊。 部署之後，在下次建置和部署週期之前，您不會修改基礎結構元件。

監視

讓系統可觀察。 您的作業小組應該一律清楚了解系統或服務的健康情況和服務狀態。 設定外部健康情況端點以監視狀態，以及程式程式碼應用程式以檢測作業計量。 使用一般且一致的架構，可協助您跨系統相互關聯事件。 追蹤 Azure 資源健康情況和狀態的標準方法是使用 Azure 診斷 和 Application Insights。 Azure 監視器 也提供雲端或混合式解決方案的集中式監視和管理。

匯總和相互關聯記錄和計量。 經過適當檢測的遙測系統提供大量的原始效能數據和事件記錄。 請確定您的系統處理並快速關聯遙測和記錄數據，讓作業人員一律擁有系統健康情況的最新圖片。 組織和顯示數據，讓您可以有問題的一致檢視，並查看事件何時彼此相關。

如需如何處理數據及儲存數據多久的需求，請參閱公司保留原則。

實作自動化警示和通知。 設定監視等監視工具，以偵測指出潛在或目前問題的模式或條件。 將警示傳送給可以解決問題的小組成員。 調整警示以避免誤判。

監視資產和資源是否有到期日。 某些資源和資產，例如憑證到期。 請務必追蹤哪些資產到期、到期時間，以及哪些服務或功能相依於它們。 使用自動化程式來監視這些資產。 在資產到期之前通知您的作業小組，並在到期威脅要中斷應用程式時呈報情況。

管理

自動化作業工作。 手動處理重複的作業程式很容易出錯。 盡可能自動化這些工作，以確保一致的執行和品質。 使用原始檔控制來建立實作自動化的版本代碼。 如同任何其他程式碼，請測試您的自動化工具。

採用基礎結構即程式代碼方法來布建。 將布建資源所需的手動設定數量降到最低。 請改用腳本和 Azure Resource Manager 範本。 將腳本和範本保留在原始檔控制中，就像您維護的任何其他程式碼一樣。

請考慮使用容器。 容器提供標準套件型介面來部署應用程式。 當您使用容器時，您可以使用包含執行應用程式所需的任何軟體、相依性和檔案的自封套件來部署應用程式。 這種做法可大幅簡化部署程式。

容器也會在應用程式和基礎操作系統之間建立抽象層，以在環境之間提供一致性。 此抽象概念也可以隔離容器與主機上執行的其他進程或應用程式。

實作復原和自我修復。 復原能力是應用程式從失敗中復原的能力。 復原策略包括重試暫時性失敗，以及故障轉移至次要實例，或甚至故障轉移至另一個區域。 如需詳細資訊，請參閱 設計可靠的 Azure 應用程式。 檢測您的應用程式，立即回報問題，以便您可以管理中斷或其他系統失敗。

手動操作。 作業手冊或 Runbook 會記錄作業人員維護系統所需的程式和管理資訊。 同時記錄任何作業案例和風險降低計劃，這些方案可能會在服務失敗或其他中斷期間運作。 在您的開發程式期間建立這份檔，並在之後保持最新狀態。 將這些資源視為您需要定期檢閱、測試及改善的活體檔。

共用檔很重要。 鼓勵小組成員參與並分享知識。 您的整個小組應該可以存取檔。 讓小組中的任何人輕鬆協助更新檔。

記錄待命程式。 請務必記錄待命職責、排程和程式，並與所有小組成員共用。 請一律讓此資訊保持在最新狀態。

第三方相依性的檔呈報程式。 如果您的應用程式相依於您未直接控制的外部第三方服務，則需要規劃來處理中斷情況。 為您的計劃性風險降低程式建立檔。 包含支持聯繫人和呈報路徑。

使用組態管理。 規劃設定變更、讓作業看得見，並加以記錄。 您可以針對這些用途使用組態管理資料庫或組態即程序代碼方法。 定期稽核組態，以確保預期的設定實際就緒。

取得 Azure 支援 計劃並了解支援程式。 Azure 提供許多 支援方案。 根據您的需求決定正確的計劃，並確定整個小組都知道如何使用方案。 小組成員應該了解計劃的詳細數據、支援程序的運作方式，以及如何向 Azure 開啟支援票證。 如果您預期會有大規模的事件，Azure 支援 可協助您增加服務限制。 如需詳細資訊，請參閱 Azure 支援 方案常見問題。

當您授與資源的存取權時，請遵循最低許可權原則。 仔細管理資源的存取權。 除非您明確授與使用者對資源的存取權，否則預設會拒絕存取。 只授與使用者完成工作所需的存取權。 追蹤用戶權力並執行一般安全性稽核。

使用 Azure 角色型存取控制。 指派用戶帳戶和資源的存取權不應該是手動程式。 使用 Azure 角色型存取控制 （Azure RBAC） 來授與以 Microsoft Entra ID 身分識別和群組為基礎的存取權。

使用 Bug 追蹤系統來追蹤問題。 如果沒有追蹤問題的好方法，很容易錯過專案、重複工作或引入新問題。 請勿依賴非正式的人員對人員通訊來追蹤 Bug 的狀態。 使用 Bug 追蹤工具來記錄問題的詳細數據、指派資源以解決問題，並提供進度和狀態的稽核線索。

管理變更管理系統中的所有資源。 如果您在管理和版本控制系統中納入 DevOps 程式的所有層面，您可以輕鬆地追蹤和稽核變更。 包含程式代碼、基礎結構、組態、檔和腳本。 在測試、建置和檢閱的過程中，將這些類型的資源視為程序代碼。

使用檢查清單。 作業檢查清單可協助您遵循程式。 很容易錯過大型手冊中的某個專案，但遵循檢查清單可能會強制注意您可能忽略的詳細數據。 維護檢查清單，並持續尋找自動化工作和簡化程式的方式。

下一步