DevOps 模型定義
DevOps 是集文化哲學、實務與工具於一身的結合，可提升組織快速交付應用程式和服務的能力：相較於使用傳統軟體開發與基礎設施管理程序的組織，這種作法能更快速地開發和改進產品。這樣的速度讓組織可以提供更好的服務給客戶，並在市場上更有效率地競爭。
DevOps 運作方式
在 DevOps 模型之下，開發與營運團隊不再「孤軍奮戰。」 有時，這兩個團隊會合併成為一個團隊，讓工程師負責整個應用程式生命週期中的工作，包含從開發和測試、部署以及營運，並發展出許多不限於單一部門的技能。
在一些 DevOps 模型中，品質保證和安全團隊在整個應用程式生命週期，也能更緊密地與開發和營運團隊整合。DevOps 團隊中的每個人都專注於安全性時，有時稱為 DevSecOps。
這些團隊會使用各種實務，將以往手動且緩慢的程序自動化。他們使用可協助快速且可靠地營運與發展應用程式的技術堆疊與工具。這些工具也可協助工程師獨立完成通常需要其他團隊協助的工作 (例如部署程式碼或佈建基礎設施)，而這樣可以進一步提高團隊的工作速度。
DevOps 的優點
速度
快速交付
可靠性
擴展
經過改進的協作
安全性
DevOps 的重要性
軟體和網際網路已經轉換整個世界和其中的產業，不論是從購物、娛樂到銀行。軟體不再僅僅是支援業務；而是成為業務中每個部分的整合元件。許多公司透過以線上服務或應用程式形式交付的軟體，以及在各種裝置上與客戶互動。這些公司也透過轉換價值鏈中的每個部分 (例如物流、通訊及營運) ，以使用軟體來提升營運效率。這種方式與 20 世紀的實體商品公司相似，他們運用工業自動化來轉變設計、製造和交付產品的方式。而在現今的世界，公司必須轉變建立與交付軟體的方式。
如何採用 DevOps 模型
DevOps 文化哲學
轉換到 DevOps 需要在文化和心態上有所變革。簡而言之，DevOps 將移除兩個傳統上孤立團隊 (開發和營運) 之間的障礙。在某些組織中，甚至可能不會有分開的開發和營運團隊；工程師必須身兼二職。採用 DevOps，兩個團隊會共同工作，以最佳化開發人員的生產力和營運的可靠性。他們會致力於經常溝通、提高效率，以及改進為客戶提供的服務品質。他們會取得服務的完整擁有權，通常會超出傳統範圍中考量一般客戶的需求以及解決這些需求所規定的角色或職務。 品質保證和安全團隊也可以和這些團隊緊密地整合。使用 DevOps 模型的組織，無論其組織架構為何，都會有負責檢視整個開發和基礎設施生命週期的團隊。
DevOps 實務說明
有幾個關鍵實務可協助組織透過自動化與精簡軟體開發和基礎設施管理程序，更快速地進行創新。這些實務大多是用正確的工具來完成。
其中一個基本實務就是執行非常頻繁但小型的更新。這就是組織為客戶更快速進行創新的方式。相較於根據傳統發行實務所執行的不定期更新，這些更新在本質上會頻繁以增量方式提供。頻繁但小型的更新讓每個部署的風險較低。它們可以協助團隊更快速解決錯誤，因為團隊可識別造成錯誤的最新部署。雖然更新的頻率和大小不同，使用 DevOps 模型的組織會比使用傳統軟體部署實務的組織更頻繁部署更新。
組織也可以使用微型服務架構來讓應用程式更有彈性，並啟用更快速的創新。微型服務架構會將大型且複雜的系統分成多個簡單且獨立的專案。應用程式會分解為許多個別的元件 (服務)，且每個服務的範圍都限定為單一用途或功能，而應用程式的對等服務和整個應用程式都可獨立運作。這個架構可減少更新應用程式的協調重擔，而當每個服務都可以和取得該服務擁有權的小型且靈敏的團隊配對時，組織便能更快速地行動。
但是，微型服務和提高的發行頻率組合，會顯著導致更多的部署，而這可能帶來營運挑戰。因此像持續整合和持續交付這類 DevOps 實務便可解決這些問題，讓組織能用安全可靠的方式快速交付。基礎設施自動化實務 (例如基礎設施即程式碼和組態管理) 有助於保持運算資源彈性與回應頻繁變更。此外，使用監控和記錄可協助工程師追蹤應用程式和基礎設施的效能，以便快速回應問題。
這些實務結合在一起之後，有助於組織更快速且更可靠地交付更新給客戶。以下是重要 DevOps 實務的概觀。
DevOps 實務
持續整合
持續整合是一項軟體開發實務，指的是開發人員在執行自動化建置與測試之後，定期將他們的程式碼變更合併到中央儲存庫。持續整合的主要目標是更快發現和解決錯誤、改善軟體品質，還有減少驗證和發行新軟體更新所需的時間。
持續交付
持續交付是一項軟體開發實務，在此實務中會自動建置、測試和準備程式碼變更以發行到生產。在建置階段之後，透過將所有程式碼變更部署到測試環境和/或生產環境，持續交付可結合持續整合來進一步延伸。當適當實作持續交付之後，開發人員永遠都會有已通過標準化測試程序且準備好部署的建置成品。
微型服務
微型服務架構是一種設計方式，用來建立作為一組小型服務的單一應用程式。每個服務都在自己的程序中執行，並且使用輕量機制透過良好定義的界面與其他服務進行通訊，而此機制通常是以 HTTP 為基礎的應用程式開發界面 (API)。微型服務是環繞著商業功能所建立；每個服務的範圍都限定為單一用途。您可以使用不同的架構或程式設計語言來撰寫微型服務，然後將它們分別部署為單一服務或服務群組。
進一步了解 Amazon Container Service (Amazon ECS)
Infrastructure as Code
基礎設施即程式碼是一項使用程式碼和軟體開發技術來佈建與管理基礎設施的實務，例如版本控制和持續整合。雲端的 API 導向模型讓開發人員和系統管理員可以用程式設計方式與基礎設施大規模互動，而不需要手動設定資源。因此，工程師能夠用以程式碼為基礎的工具作為與基礎設施之間的界面，以類似對待應用程式程式碼的方式來對待基礎設施。因為它們是由程式碼來定義，便可以使用標準化模式來快速部署基礎設施和伺服器、使用最新的修補程式和版本來更新或是以可重複的方式來複製。
了解如何使用 AWS CloudFormation 來管理基礎設施即程式碼
組態管理
開發人員和系統管理員可使用程式碼來自動化作業系統和主機組態、營運工作及更多項目。使用程式碼讓組態變更可重複和標準化。這讓開發人員和系統管理員免於手動設定作業系統、系統應用程式或是伺服器軟體。
了解如何使用 Amazon EC2 Systems Manager 設定和管理 Amazon EC2 及內部部署系統
政策即程式碼
運用雲端來編寫基礎設施及其組態，組織便可動態且大規模地施行監控和實施合規。如此便可使用自動化方式來追蹤、驗證及重新設定由程式碼描述的基礎設施。這讓組織更易於控管資源的變更，並確保以分散方式適當地施行安全量值 (例如資訊安全或符合 PCI-DSS 或 HIPAA 規範)。這允許組織中的團隊能以更高的速度行動，因為不合規的資源會自動加上旗標做進一步的調查，甚至自動使其符合規範。
了解如何使用 AWS Config 和 Config 規則來監控和施行基礎設施的合規
監控和記錄
組織會監控指標和日誌，以查看應用程式和基礎設施效能對產品最終使用者體驗影響的方式。透過擷取、分類、接著分析應用程式和基礎設施所產生的資料和日誌，組織便能了解變更或更新影響使用者的方式，深究出問題或未預期變更的根本原因。因為服務必須全年不間斷地提供，而且應用程式和基礎設施的更新越來越頻繁，所以主動監控便越來越重要。建立警示或執行此資料的即時分析也有助於組織能夠更主動地監控服務。
了解如何使用 Amazon CloudWatch 來監控您的基礎設施指標和日誌
了解如何使用 AWS CloudTrail 來記錄 AWS API 呼叫並寫入日誌
通訊與協作
組織中日益增加的通訊與協作是 DevOps 的其中一項關鍵文化層面。透過實際將開發和營運的工作流程與責任結合在一起，使用 DevOps 工具和軟體交付程序自動化便能建立協作。以此為基礎，這些團隊便可透過聊天應用程式、問題或專案追蹤系統以及 Wiki，在資訊共享和促進溝通之間建立強大的文化規範。這有助於加速開發人員、營運，甚至其他團隊 (例如行銷或銷售) 之間的溝通，讓組織中的所有部門都能在目標和專案上進行更緊密的合作。
DevOps 工具
DevOps 模型仰賴有效運用工具來協助團隊快速且可靠地為客戶進行部署和創新。這些工具可將手動工作自動化，協助團隊大規模管理複雜的環境，並讓工程師能夠掌控 DevOps 所提供的高速。AWS 提供專為 DevOps 所設計以及優先搭配 AWS 雲端使用所建立的服務。這些服務可協助您使用上述的 DevOps 實務。