前言
在#DevOps的前世今生# 1. DevOps編年史一文中，通過追溯 DevOps 活動產(chǎn)生的歷史起源，我們發(fā)現(xiàn)了 DevOps 是敏捷思想從軟件開發(fā)端(Dev)到系統(tǒng)維護端(Ops)的延伸会油。無論是 DevOpsDays 的創(chuàng)始人 Patrick Debois，還是同時期的 The Agile Admin古毛。都想通過敏捷來改進傳統(tǒng)的系統(tǒng)維護工作以及軟件開發(fā)部門和系統(tǒng)維護部門的合作關系翻翩。但是，DevOps 的矛盾從何而來稻薇？這還要從 Dev 和 Ops 的起源開始講起嫂冻。
上古時代——抱著計算機使用手冊，自開發(fā)自運維
歷史要追溯到剛剛出現(xiàn)計算機的時期塞椎。當時桨仿，軟件開發(fā)還是少數(shù)人通過高學歷才能夠掌握的技能，那個時候只有“程序”（Program）案狠，但沒有“軟件”（Software）蹬敲，所以那個時候編寫程序的人員被稱為“程序員”（Programmer）≥航洌基本的學習材料還只是計算機設備廠商附送的使用手冊伴嗡。所以，只能先購買設備从铲，再自己培養(yǎng)人才瘪校。
最先購買計算機的是科研單位，軍隊，政府以及少數(shù)大型企業(yè)阱扬。同時組建了新的部門泣懊，成立了信息技術部（IT Department)，或者叫信息化辦公室（IT Office）麻惶。在中國的有些單位里干脆直接叫“電腦部”馍刮。他們一個科室，一個辦公室主任窃蹋，外加兩三個科級干部和幾個科員卡啰，專門管理這些電腦的使用情況，并且學習軟件編程技術警没，用程序來解決其它各部門的匈辱。
這是最初的IT運維雛形，在這個時期是沒有 Dev 和 Ops 之分的杀迹，他們統(tǒng)稱為 Programmer亡脸。由于開發(fā)和運維都由同樣的人包攬，自己維護自己開發(fā)的程序树酪，也可以被看做是原始的 DevOps浅碾。這個時期的計算機系統(tǒng)和問題較簡單，開發(fā)和維護并不復雜续语，無需進行專業(yè)區(qū)分及穗。
桌面通用軟件時代——軟件成為了一門生意，出現(xiàn)了專業(yè)的軟件開發(fā)工程師（Dev）绵载。
隨著計算機的成本不斷下降，尤其是以IBM PC為代表微型計算機（ MicroComputer ）開始普及苛白。企業(yè)也開始大規(guī)模使用計算機進行辦公娃豹。由于軟件開發(fā)人員數(shù)量仍然很少，加之需求很旺盛购裙，專業(yè)的軟件開發(fā)人員成本依然高昂懂版。
最開始的時候，軟件僅僅通過磁盤拷貝進行流傳躏率，某些介紹計算機或者軟件的雜志開了先河躯畴。程序員通過磁盤向雜志社投稿，雜志社通過變賣雜志和軟件獲利薇芝。由于軟件的邊際生產(chǎn)成本幾乎是0蓬抄，所以漸漸有人把銷售軟件變成了一門生意。隨著軟件的擴展夯到，當初為個人目的（Personal Purpose）所編寫的軟件漸漸的開始走通用化的路線嚷缭，慢慢形成了軟件產(chǎn)品。接著有了專門從事軟件開發(fā)的公司，并逐漸成為一個產(chǎn)業(yè)阅爽。并且有了軟件開發(fā)工程師（Developer路幸，簡稱Dev）這個職業(yè)。
在這個時期付翁，開發(fā)軟件仍然是很專業(yè)的事情简肴，企業(yè)的IT部門要想開發(fā)軟件的代價十分高昂。因此百侧，大部分單位砰识，組織和企業(yè)通過購買的形式獲得軟件。IT部門逐漸成為了負責信息化采購以及軟硬件基本操作培訓的部門移层。此外仍翰，由于信息化發(fā)展加速，各行各業(yè)軟件層出不窮观话，加之軟件企業(yè)越來越多予借，IT部門不得不通過更廣泛的學習了解技術的變化。
企業(yè)級定制化軟件時代——企業(yè)級應用的快速發(fā)展频蛔，出現(xiàn)了專業(yè)的系統(tǒng)維護工程師（Ops）灵迫。
隨之帶來的問題是：無論企業(yè)買來多少軟件，企業(yè)的信息化需要仍然無法被滿足晦溪。一臺臺電腦成為了企業(yè)的信息孤島瀑粥，解決了信息的分析和存儲問題最多實現(xiàn)了無紙化辦公。沒有讓部門間的信息有效的流動起來三圆。大型企業(yè)最先發(fā)現(xiàn)這些問題并且給出了最初的解決方案狞换，使得企業(yè)級軟件開發(fā)和系統(tǒng)集成（System Integration）慢慢成為了一個熱門的領域。
企業(yè)級軟件系統(tǒng)最大的特點是通過計算機網(wǎng)絡解決了企業(yè)內(nèi)部的信息孤島舟肉。但這樣的系統(tǒng)無法在PC上運行需要專業(yè)的工作站修噪，服務器以及網(wǎng)絡設備。而這些設備的管理就理所當然的成為了企業(yè)IT部門的職責路媚。
隨著軟硬件技術的發(fā)展黄琼，特別企業(yè)級應用開發(fā)的經(jīng)驗不斷積累，設備的采購成本和軟件的開發(fā)成本進一步降低整慎。大型IT廠商開始瞄準企業(yè)級應用市場脏款，尤其是IBM，Oracle和EMC推出了相應的產(chǎn)品裤园。使得軟件定制開發(fā)的成本不斷下降撤师。加之隨著開發(fā)人員越來越多，開發(fā)成本逐漸降低拧揽，于是出現(xiàn)了企業(yè)定制化軟件開發(fā)丈氓，出現(xiàn)了MIS和ERP這樣的應用以及J2EE這樣的企業(yè)級軟件開發(fā)框架。
在這個過程中，IT運維的概念逐漸產(chǎn)生万俗，維基百科上是這樣定義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運維的責任是要為內(nèi)部和外部客戶的應用部署提供平滑的基礎設施和操作環(huán)境湾笛，包括網(wǎng)絡基礎設施，服務器和設備管理闰歪，計算機操作嚎研，ITIL管理，甚至作為組織的IT幫助中心库倘。
對于企業(yè)的IT部門來說临扮，工作就不僅僅是維護計算機和網(wǎng)絡這些設備了。還要包括運行在上面的軟件系統(tǒng)教翩，尤其是定制化的企業(yè)級軟件產(chǎn)品杆勇。因此在定制化企業(yè)級軟件交付從乙方交付給甲方的時候就需要一系列的技術審查以確保質量，這就使得原本不需要關心軟件是如何開發(fā)的企業(yè)IT部門提出了更高的要求饱亿。他們必須提升專業(yè)水準以應對這樣的變化蚜退。同時需要重新思考整個IT部門的服務管理和設計。隨著IT部門知識和服務專業(yè)度的提升彪笼，促生出了了ITIL（Information Technology Infrastructure Library钻注，信息技術基礎設施庫）這樣的最佳實踐庫，也使“系統(tǒng)維護工程師”（Ops）更加專業(yè)化配猫。
在這個時期幅恋，Dev和Ops的矛盾，主要是由Dev所代表的乙方和Ops所代表的甲方在定制化軟件產(chǎn)品交付質量上的矛盾泵肄。
敏捷軟件開發(fā)時代——應對頻繁變更的挑戰(zhàn)
隨著企業(yè)級軟件開發(fā)日趨完善和成熟捆交，形成了以RUP（Rational Unified Process，Rational 統(tǒng)一軟件開發(fā)過程）為代表的方法論腐巢。RUP描述了如何有效地利用商業(yè)的可靠的方法開發(fā)和部署軟件品追，是一種重量級過程（也被稱作厚方法學），因此特別適用于大型軟件團隊開發(fā)大型項目系忙。
后來，互聯(lián)網(wǎng)企業(yè)的繁榮著實閃瞎了世界的眼睛惠豺。沒有人想到原本用來進行國防和科研的廣域網(wǎng)居然可以帶來這么大的商業(yè)價值银还。互聯(lián)網(wǎng)創(chuàng)業(yè)公司的成功不斷的顛覆了很多人習以為常的事情洁墙，特別是IT產(chǎn)業(yè)蛹疯。
首先，相較于最多萬人的用戶訪問規(guī)模热监，來自互聯(lián)網(wǎng)的千萬級甚至是億級的訪問規(guī)模是企業(yè)級應用不曾遇到過的捺弦。這對軟件開發(fā)，主機管理，網(wǎng)絡架構都帶來了很大的挑戰(zhàn)列吼。
其次幽崩，企業(yè)級應用和互聯(lián)網(wǎng)應用面對的問題是不一樣的。根據(jù)“康威定理”：設計系統(tǒng)的組織寞钥，其產(chǎn)生的設計和架構等價于組織間的溝通結構慌申。相較于有著清晰的等級和部門分工的組織來說，互聯(lián)網(wǎng)產(chǎn)品的溝通結構更加復雜理郑。
此外蹄溉，互聯(lián)網(wǎng)應用由互聯(lián)網(wǎng)企業(yè)自開發(fā)自維護。雖然從表面上看沒有了甲方和乙方的對立您炉。但開發(fā)和運維相互分離的工作流程和考核方式卻沿用了下來柒爵，職責上的對立依然存在：
Dev的工作是給應用系統(tǒng)增加新的功能/修復軟件的Bug，這一系列價值的產(chǎn)生是通過應用系統(tǒng)變更實現(xiàn)的赚爵。一般的組織會用代碼/功能的貢獻數(shù)量作為KPI作為考核的依據(jù)棉胀，以激勵Dev的工作產(chǎn)出。
Ops的工作則是讓應用系統(tǒng)保持穩(wěn)定和高性能囱晴，即最大化縮短宕機時間并能夠提升應用系統(tǒng)的性能膏蚓，并以這兩者作為Ops的KPI的考核指標。以激勵Ops通過維護工作使應用系統(tǒng)能夠按照預期穩(wěn)定的產(chǎn)出價值畸写。
而市場環(huán)境的瞬息萬變和資本的集中化使得互聯(lián)網(wǎng)軟件產(chǎn)品的生存狀態(tài)十分脆弱：
一方面驮瞧，快速變化的市場難以預測。因此枯芬，基于經(jīng)驗的重量級軟件開發(fā)方法不再適用论笔。取而代之的是強調(diào)適應性，擁抱變化的敏捷方法千所】衲В互聯(lián)網(wǎng)軟件必須通過頻繁增加/修改功能來提升自身對市場的適應程度。
另一方面淫痰，互聯(lián)網(wǎng)軟件的變更給帶來的風險和損失都是難以度量的最楷。因此，互聯(lián)網(wǎng)軟件有更加嚴格的交付標準待错，需要做更多的質量保證籽孙。而基于經(jīng)驗的系統(tǒng)運維實踐并沒有給出足夠的方法以應對這種挑戰(zhàn)。
因此火俄，在這個時期犯建，Dev和Ops的矛盾主要是面向適應性的敏捷軟件交付和面向經(jīng)驗性的傳統(tǒng)運維之間的矛盾。
那么瓜客，如果將敏捷的文化和原則引入運維适瓦，會如何竿开？
請期待下一篇：#DevOps的前世今生# 3. DevOps的文化和原則
感謝ThoughtWorks總監(jiān)咨詢師史凱對本文的改進意見和建議。
參考資源：
https://en.wikipedia.org/wiki/Information_technology_operations
https://en.wikipedia.org/wiki/Software_developer
https://en.wikipedia.org/wiki/Management_information_system
https://en.wikipedia.org/wiki/Enterprise_resource_planning
https://en.wikipedia.org/wiki/Rational_Unified_Process
http://agilemanifesto.org/iso/zhchs/manifesto.html
https://theagileadmin.com/what-is-devops/
http://www.jedi.be/blog/2009/12/22/charting-out-devops-ideas/
http://itrevolution.com/the-convergence-of-devops/
http://joehertvik.com/operations-management/
https://zh.wikipedia.org/wiki/IBM-Rational%E7%BB%9F%E4%B8%80%E8%BF%87%E7%A8%8B
https://zh.wikipedia.org/wiki/%E6%95%8F%E6%8D%B7%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91
