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
編輯 | 山河來源 | http://www.jianshu.com/u/66fea2f123b
論Dev與Ops衝突的根源、表現形式及解決方案
一、衝突的根源 開發團隊的目標：滿足產品的功能需求，把使用者的需求實現，釋出到現網，交付到使用者手裡。 從之前的敏捷過程來看，其實開發／測試甚至是QA團隊的目標是一致的。 運維團隊的目標：質量永遠是第一位的。這導致一個有意思的現象： 變更是主要的故障之源，你同意麼？ 之前在一篇論文中給出資料
灰度釋出，連結 Dev 與 Ops 的正確姿勢
作者： 萬金 編輯：濟萌 作者簡介 萬金 ThoughtWorks 高階顧問 10年+知名外企與中國企業的IT從業經驗，包括IBM，華為，中興，Thomson. 具有7年雲端計算相關經驗，多系統的研發和運維經驗，熟練掌握敏捷和DevOps方法論和實踐，具有軟體研發生命週期工具與流程改進豐富經驗。
sugar與阿龍的互懟（第一季）
電視劇 不回 多人 戀愛 談戀愛 吃飯 spa 都在 中國 § 第一季 回家風波 高考了，啦啦啦~ 快要高考了，顯然sugar很傷心。 顯然不是因為快要考試了sugar才
互聯網科普-淘寶與天貓的對標
ron 支付寶 沒有 b2c font http 主體 track 什麽 一、淘寶VS天貓的對照分析1、從商業模式上看：都是聚集買家與賣家在一個平臺交易的雙邊商業模式，沒差異2、從價值主張來看：都是撮合交易。僅僅只是撮合交易兩方主體不同。淘寶對於交易兩方無資質要求，而天
DevOps的前世今生（2）Dev和Ops矛盾緣何而來 ？
本文經授權轉載簡書作者：顧宇 原文：http://www.jianshu.com/p/c6573e63c752 前言 在#DevOps的前世今生# 1. DevOps編年史一文中，通過追溯 DevOps 活動產生的歷史起源，我們發現了 DevOps 是敏捷思想從軟體開發端(Dev)到系統維護端(O
Android與H5互調（通過實例來了解Hybrid App）
ext 傳感器 顯示 相同 blank show ima 一次 點擊 前些日子，Android原生開發將被取締的吵得火熱，JavaScript是能做一個完全的APP，但只使用JavaScript做出來的APP也不會牛逼到哪裏去。最好的是混合（Hybrid）開發，在需要的
C# 圖片與Base64互轉
name oba mar base64 richtext sender bin binary ram /// <summary> /// 將圖片數據轉換為Base64字符串 /// </summary> /// <pa
Unicode與Ansi互轉
form nic code 手動 char empty ret wchar art 1 BOOL CTool::AnsiToUnicode(const char *pSrc, CString &strResult) 2 { 3 #ifndef _UNICOD
-save-dev 與 -save的區別
壓縮 gulp 依賴 node 服務 利用 發布 表示 save -save-dev是指將包信息添加到devDependencies，表示你開發時依賴的包裹。 -save是指將包信息添加到dependencies，表示你發布時依賴的包裹。 例如，我們在開發時會用到gulp來
BYTE[]與OBJECT互轉工具
apt lis [] hao123 互轉 dap music ada adapter %E8%87%AA%E5%B7%B1%E7%90%86%E8%A7%A3%E7%9A%84aDapTER%E6%B3%A8%E9%87%8A http://music.hao123.com
華為騰訊用戶隱私互懟的背後，AI才是重點！
騰訊華為數據日前，中國硬件巨頭華為，軟件巨頭騰訊，因《華爾街日報》一篇名為《華為和騰訊陷入用戶數據之爭 後者要求政府介入》的報道而成為了媒體關註的焦點。華為手機曾在此前推出一款榮耀Magic手機，它也被稱為華為第一款人工智能手機，它可以通過收集數據從而達到智能推薦等功能，而這些數據裏面就包括了微信聊天記錄等大
OpenGL與CUDA互操作方式總結
source 紋理貼圖 cnblogs 過程 嘗試 cuda _array vao 開始 一、介紹 CUDA是Nvidia推出的一個通用GPU計算平臺，對於提升並行任務的效率非常有幫助。本人主管的項目中采用了OpenGL做圖像渲染，但是在數據處理方面比較慢，導致幀率一直上
KETTLE：mongdb與mysql互傳數據
spa kettle 集合 點擊 技術 use 選擇 json 為知筆記 註：部分內容引用了 http://blog.sina.com.cn/s/blog_4ac9f56e0101g881.html1、mongodb傳數據到mysql1)在kettle中，mongodb i
字符串與json互轉
ont 兼容ie value cti span == eval foreach clas 一、json 轉字符串 var str = "1:測試1-1;2:測試1-2;3:測試1-3"; //字符串 var str
前端的UI設計與交互之圖標篇
風格 設計 維度 特殊情況 面積 需要 標識 調整 例如 圖標是具有指代意義的圖形，也是一種標識。通過使用圖標表達命令，強調狀態，表示產品或類別。為了系統及跨平臺之間圖形認知保持一致， 圖標在設計和使用時有以下兩個原則點需要註意：簡單的圖形語言以及高辨識度。清晰、直觀的圖
前端的UI設計與交互之字體篇
界面設計 不同 需求 上下 一個 幫助 保持 文本顏色 影響 跨平臺的字體設定，力求在各個操作系統下都有最佳展示效果。字體是界面設計中最重要的基本構成之一，用戶通過文本來消化內容和完成工作，優雅的字體將大大提升用戶的閱讀體驗及工作效率。在滿足不同終端始終保持良好的閱讀體驗的
前端的UI設計與交互之導航篇
頂部 隱藏 標簽 距離 例如 適合 操作類 允許 垂直 在廣義上，任何告知用戶他在哪裏，他能去什麽地方以及如何到達那裏的方式，都可以稱之為導航。當設計者使用導航或者自定義一些導航結構時，請註意：盡可能提供標識、上下文線索，避免用戶迷路；保持導航樣式和行為一致或者減少導航數量
前端的UI設計與交互之反饋示篇
指向 優先 進一步 承載 not 交互操作 對象 自動 con 為了幫助用戶了解應用當前要做什麽，也給用戶的下一步行為做參考，以及了解操作後所產生的結果 ，當用戶和系統需要交互時，使用不同的模式來反饋信息或結果。當設計者使用反饋或者自定義一些反饋時，請註意：為用戶在各
JSONUtil(JAVA對象/List與json互轉，xml與json互轉)
transpose boolean ngs final span arraylist setname clas pro 1 package com.chauvet.utils.json; 2 3 import java.io.BufferedReader;