在傳統的開發週期，開發團隊會將軟體版本丟過這道牆給營運團隊，營運團隊撿起這些版本構件並開始準備他們的部署，手動處理開發者提供或是他們自己建立的部署指令碼。他們也編輯配置檔案來反映生產環境，而這與開發或 QA 環境有極大的不同。最好的情況是他們正在複製之前環境中已經做好的工作，最壞的情況是他們即將引進或發現新的錯誤。
再來，IT 營運團隊就會著手於他們認為目前正確的部署程序，但由於開發與營運團隊的指令碼、設定、程序與環境不同，這基本上是第一次被運行。當然如果過程中遇到問題的話，開發者會被叫來幫忙解決問題。營運團隊會覺得是開發團隊給他們錯誤的程式碼，而開發者則會反駁，在他們的環境中執行並沒有問題，所以一定是營運團隊有哪裡做錯了。開發者會非常難察覺問題所在，因為導致這樣結果的設定、檔案位置與程序都跟他們想像的不同。時間就這樣流逝在不停切換畫面上，當然也沒有牢靠的方法讓環境恢復到之前那個好的狀態。本來應該平靜無事的部署，演變成全員出動的消防演習，面對一大堆考驗與錯誤，最後才讓生產環境變成一個可以使用的狀態。
DevOps
如果您沒辦法快速地傳遞高品質的軟體或建構錯誤的東西來開始，以下是實際的後果數據：
40% 的 IT 實作最後都重做，因為它們並不符合使用者原本的需求。
一個客戶導向的應用程式停機一小時的平均成本是每小時 USD $100 元，而且還不考慮受損的聲譽，可能會更嚴重。
修復像這樣生產上的問題平均每個事件要花上 200 分鐘。
有四分之三的開發團隊採用敏捷開發，使他們開發得更快。雖然這比例很大，但是如果因為 IT 營運團隊是不敏捷的，使採用敏捷開發的開發團隊在部署上還是得花數星期或數個月，這一點幫助都沒有。
這只是三個非常高階的例子，但所有的數據都指向同一個結論 － 這不僅僅只是個小挫折或輕微的延遲而已。開發與營運團隊缺乏合作會對公司的盈虧與成功造成嚴重的影響。
人＝文化
人/員工是一個組織文化的成敗關鍵元素。試圖改變文化，需要時間，改變文化也不例外，您不可能光靠一個人完成，表揚令人信服的事件：停機時間、雲技術導入、DevOps 熱潮。
一些初始的問題？
有一個共同的使命與動機：基礎架構程式化、應用程式即服務、DevOps/皆為團隊。
將硬體視為商品，而伺服器就像是農場動物。
打造深度檢測到服務中，複雜度向上推進。
圍繞在敏捷周圍、共同的標準、持續整合 CI、服務負責人隨時 on call 等。
程序－定義與設計、一致性、持續改善
人－責任、管理、技術開發、訓練
產品－工具和基礎設備
實作像是 ITIL
- Infrastructure as Code（IaC）
![devops-4]()
- 持續整合
![devops-5]()
- 持續傳遞
![devops-6]()
- 持續部署
![devops-7]()
- 自動測試
- 發行管理
- 應用程式效能監控
- 負載測試 & 自動比例
- 可用性監控
- 變更/配置管理
- 功能旗標
- 自動環境解除佈建
- 自助環境
- 自動復原（復原 & 向前復原）
- 假說驗證開發
- 生產中測試
- 錯誤注射
- 使用量監控/使用者遙測
實施辦法
有很多可用的工具與技術來讓我們能夠實踐 DevOps
Microsoft 也在開源的生態系統投資了很多，並能讓您保持在開源工具現有的投資，同時有可能與我們自己的技術整合。在下面的異質環境您可以看到我們許多不同有互通性的開源產品，他們扮演不同的角色在整個應用程式生命週期。
這些開源工具往往不只在產品生命週期的單一方面發會作用，但它們被列在這裡是基於與微軟技術主要的整合點。
最後，我想指出的是，Microsoft Azure 平台，您可能會決定裝載您的應用程式支援各種程式語言，像是 Node.js、php、Java 以及開源的作業系統 Linux。
您可以到這裡查看更多有關 DevOps 專案的內容。
使用 Azure 作為基礎
當提到雲端，在產業中有許多混淆。您瞭解產業內發生了什麼與我們如何思考雲端是很重要的。
這是最常用來區分雲端服務類型的分類：
產業定義了三個服務的類別：
- 提供基礎架構的雲端服務（IaaS）－ 基礎建設等級的功能，像是提供作業系統、網路連線等付費使用的服務，並可以用來裝載應用程式。
- 平台即服務（PaaS）－ 較高等級的功能，為要建置應用程式開發者的耗材服務。PaaS 提供開發者一個開發平台，使其能夠使應用程式快速被組成。
- 軟體即服務（SaaS）－ 被使用服務交付模型交付的應用程式，組織可以簡單地消費與使用應用程式。通常一個組織會付費使用應用程式或應用程式可以透過廣告收入賺錢。
要注意的是這三種類型的服務是可以獨立存在或彼此組合。
內部部署或外部部署
Microsoft Azure Stack 讓貴組織能夠在公有雲上做任何事透過新的 Azure 資源管理器 API 在 portal.azure.com，內部部署在他們自己的數據中心。所以不管您是否喜歡在雲端上工作，混合式或內部部署，微軟都已幫您顧及到了。
如果您對於教導 DevOps 有興趣或是想要分享您的故事，請聯繫我們。
資源
Getting Started with Visual Studio
Azure Grant for DevOps in the Curricula
本文翻譯自 DevOps the Wall of Confusion understanding the basics of DevOps
若對以上技術及產品有任何問題，很樂意為您服務! 請洽：台灣微軟開發工具服務窗口 – MSDNTW@microsoft.com / 02-3725-3888 #4922