Dev 与 Ops 互怼 | 科普一下 DevOps
編輯 | 山河
來源 | http://www.jianshu.com/u/66fea2f123be
一、前言
在《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部門的職責。
Ops 需要管理很多的設備和應用
隨著軟硬件技術的發展,特別企業級應用開發的經驗不斷積累,設備的采購成本和軟件的開發成本進一步降低。
大型 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 的矛盾主要是面向適應性的敏捷軟件交付和面向經驗性的傳統運維之間的矛盾。
那么,如果將敏捷的文化和原則引入運維,會如何?
從 2009 年第一屆 DevOpsDays 算起,DevOps 已經經歷了 8 年,即將迎來自己的第 9 個生日。
然而,DevOps 工具繁多,概念不一,使得 DevOps 知識體系逐漸龐大,難以下手。
本課程從 DevOps 歷史源頭出發,追蹤 DevOpsDays 全球發展動態,并結合作者過去 4 年在國內外進行 DevOps 咨詢和實踐過程中的經驗總結而成,每一個實踐和方法均來自于真實客戶的實踐案例,相關的敏感信息已經做了刪改。
本課程針對的讀者是想進行 DevOps 轉型的組織領導者和實踐 DevOps 轉型的咨詢師或敏捷教練。
共包括 10 篇文章,其內容涉及 DevOps 轉型的評估、設計和落地,每部分環環相扣,并配有案例講解和實踐示例,能夠幫讀者更快的依據所在上下文設計出更好的 DevOps 評估和落地方案。掃碼免費試讀
總結
以上是生活随笔為你收集整理的Dev 与 Ops 互怼 | 科普一下 DevOps的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: bili上李沐大神的d2l中的损失函数的
- 下一篇: 拼多多百亿会员怎么取消?聚创卓跃电商