本文經授權轉載簡書作者：顧宇

原文：http://www.jianshu.com/p/c6573e63c752

前言

在#DevOps的前世今生# 1. DevOps編年史一文中，通過追溯 DevOps 活動產生的歷史起源，我們發現了 DevOps 是敏捷思想從軟體開發端(Dev)到系統維護端(Ops)的延伸。無論是 DevOpsDays 的創始人 Patrick Debois，還是同時期的 The Agile Admin。都想通過敏捷來改進傳統的系統維護工作以及軟體開發部門和系統維護部門的合作關係。但是，DevOps 的矛盾從何而來？這還要從 Dev 和 Ops 的起源開始講起。

上古時代——抱著計算機使用手冊，自開發自運維

歷史要追溯到剛剛出現計算機的時期。當時，軟體開發還是少數人通過高學歷才能夠掌握的技能，那個時候只有“程式”（Program），但沒有“軟體”（Software），所以那個時候編寫程式的人員被稱為“程式設計師”（Programmer）。基本的學習材料還只是計算機裝置廠商附送的使用手冊。所以，只能先購買裝置，再自己培養人才。

最先購買計算機的是科研單位，軍隊，政府以及少數大型企業。同時組建了新的部門，成立了資訊科技部（IT Department)，或者叫資訊化辦公室（IT Office）。在中國的有些單位裡乾脆直接叫“電腦部”。他們一個科室，一個辦公室主任，外加兩三個科級幹部和幾個科員，專門管理這些電腦的使用情況，並且學習軟體程式設計技術，用程式來解決其它各部門的。

這是最初的IT運維雛形，在這個時期是沒有 Dev 和 Ops 之分的，他們統稱為 Programmer。由於開發和運維都由同樣的人包攬，自己維護自己開發的程式，也可以被看做是原始的 DevOps。這個時期的計算機系統和問題較簡單，開發和維護並不複雜，無需進行專業區分。

桌面通用軟體時代——軟體成為了一門生意，出現了專業的軟體開發工程師（Dev）。

隨著計算機的成本不斷下降，尤其是以IBM PC為代表微型計算機（ MicroComputer ）開始普及。企業也開始大規模使用計算機進行辦公。由於軟體開發人員數量仍然很少，加之需求很旺盛，專業的軟體開發人員成本依然高昂。

最開始的時候，軟體僅僅通過磁碟拷貝進行流傳，某些介紹計算機或者軟體的雜誌開了先河。程式設計師通過磁碟向雜誌社投稿，雜誌社通過變賣雜誌和軟體獲利。由於軟體的邊際生產成本幾乎是0，所以漸漸有人把銷售軟體變成了一門生意。隨著軟體的擴充套件，當初為個人目的（Personal Purpose）所編寫的軟體漸漸的開始走通用化的路線，慢慢形成了軟體產品。接著有了專門從事軟體開發的公司，並逐漸成為一個產業。並且有了軟體開發工程師（Developer，簡稱Dev）這個職業。

在這個時期，開發軟體仍然是很專業的事情，企業的IT部門要想開發軟體的代價十分高昂。因此，大部分單位，組織和企業通過購買的形式獲得軟體。IT部門逐漸成為了負責資訊化採購以及軟硬體基本操作培訓的部門。此外，由於資訊化發展加速，各行各業軟體層出不窮，加之軟體企業越來越多，IT部門不得不通過更廣泛的學習瞭解技術的變化。

企業級定製化軟體時代——企業級應用的快速發展，出現了專業的系統維護工程師（Ops）。

隨之帶來的問題是：無論企業買來多少軟體，企業的資訊化需要仍然無法被滿足。一臺臺電腦成為了企業的資訊孤島，解決了資訊的分析和儲存問題最多實現了無紙化辦公。沒有讓部門間的資訊有效的流動起來。大型企業最先發現這些問題並且給出了最初的解決方案，使得企業級軟體開發和系統整合（System Integration）慢慢成為了一個熱門的領域。

企業級軟體系統最大的特點是通過計算機網路解決了企業內部的資訊孤島。但這樣的系統無法在PC上執行需要專業的工作站，伺服器以及網路裝置。而這些裝置的管理就理所當然的成為了企業IT部門的職責。

隨著軟硬體技術的發展，特別企業級應用開發的經驗不斷積累，裝置的採購成本和軟體的開發成本進一步降低。大型IT廠商開始瞄準企業級應用市場，尤其是IBM，Oracle和EMC推出了相應的產品。使得軟體定製開發的成本不斷下降。加之隨著開發人員越來越多，開發成本逐漸降低，於是出現了企業定製化軟體開發，出現了MIS和ERP這樣的應用以及J2EE這樣的企業級軟體開發框架。

在這個過程中，IT運維的概念逐漸產生，維基百科上是這樣定義IT運維（IT Operations）的：

IT Operations is responsible for the smooth functioning of the infrastructure and operational environments that support application deployment to internal and external customers, including the network infrastructure; server and device management; computer operations; IT infrastructure library (ITIL) management; and help desk services for an organization.

翻譯成中文就是：

IT運維的責任是要為內部和外部客戶的應用部署提供平滑的基礎設施和操作環境，包括網路基礎設施，伺服器和裝置管理，計算機操作，ITIL管理，甚至作為組織的IT幫助中心。

對於企業的IT部門來說，工作就不僅僅是維護計算機和網路這些裝置了。還要包括執行在上面的軟體系統，尤其是定製化的企業級軟體產品。因此在定製化企業級軟體交付從乙方交付給甲方的時候就需要一系列的技術審查以確保質量，這就使得原本不需要關心軟體是如何開發的企業IT部門提出了更高的要求。他們必須提升專業水準以應對這樣的變化。同時需要重新思考整個IT部門的服務管理和設計。隨著IT部門知識和服務專業度的提升，促生出了了ITIL（Information Technology Infrastructure Library，資訊科技基礎設施庫）這樣的最佳實踐庫，也使“系統維護工程師”（Ops）更加專業化。

在這個時期，Dev和Ops的矛盾，主要是由Dev所代表的乙方和Ops所代表的甲方在定製化軟體產品交付質量上的矛盾。

敏捷軟體開發時代——應對頻繁變更的挑戰

隨著企業級軟體開發日趨完善和成熟，形成了以RUP（Rational Unified Process，Rational 統一軟體開發過程）為代表的方法論。RUP描述瞭如何有效地利用商業的可靠的方法開發和部署軟體，是一種重量級過程（也被稱作厚方法學），因此特別適用於大型軟體團隊開發大型專案。

後來，網際網路企業的繁榮著實閃瞎了世界的眼睛。沒有人想到原本用來進行國防和科研的廣域網居然可以帶來這麼大的商業價值。網際網路創業公司的成功不斷的顛覆了很多人習以為常的事情，特別是IT產業。

首先，相較於最多萬人的使用者訪問規模，來自網際網路的千萬級甚至是億級的訪問規模是企業級應用不曾遇到過的。這對軟體開發，主機管理，網路架構都帶來了很大的挑戰。

其次，企業級應用和網際網路應用面對的問題是不一樣的。根據“康威定理”：設計系統的組織，其產生的設計和架構等價於組織間的溝通結構。相較於有著清晰的等級和部門分工的組織來說，網際網路產品的溝通結構更加複雜。

此外，網際網路應用由網際網路企業自開發自維護。雖然從表面上看沒有了甲方和乙方的對立。但開發和運維相互分離的工作流程和考核方式卻沿用了下來，職責上的對立依然存在：

Dev的工作是給應用系統增加新的功能/修復軟體的Bug，這一系列價值的產生是通過應用系統變更實現的。一般的組織會用程式碼/功能的貢獻數量作為KPI作為考核的依據，以激勵Dev的工作產出。

Ops的工作則是讓應用系統保持穩定和高效能，即最大化縮短宕機時間並能夠提升應用系統的效能，並以這兩者作為Ops的KPI的考核指標。以激勵Ops通過維護工作使應用系統能夠按照預期穩定的產出價值。

而市場環境的瞬息萬變和資本的集中化使得網際網路軟體產品的生存狀態十分脆弱：

一方面，快速變化的市場難以預測。因此，基於經驗的重量級軟體開發方法不再適用。取而代之的是強調適應性，擁抱變化的敏捷方法。網際網路軟體必須通過頻繁增加/修改功能來提升自身對市場的適應程度。

另一方面，網際網路軟體的變更給帶來的風險和損失都是難以度量的。因此，網際網路軟體有更加嚴格的交付標準，需要做更多的質量保證。而基於經驗的系統運維實踐並沒有給出足夠的方法以應對這種挑戰。

因此，在這個時期，Dev和Ops的矛盾主要是面向適應性的敏捷軟體交付和麵向經驗性的傳統運維之間的矛盾。

那麼，如果將敏捷的文化和原則引入運維，會如何？

感謝ThoughtWorks總監諮詢師史凱對本文的改進意見和建議。

參考資源：