歷史回顧

為了能夠更好的理解什么是DevOps诲锹，我們很有必要對當時還只有程序員(此前還沒有派生出開發(fā)者，前臺工程師涉馅，后臺工程師之類)這個稱號存在的歷史進行一下回顧归园。

如編程之道中所言：

老一輩的程序員是神秘且深奧的。我們沒法揣摩他們的想法稚矿，我們所能做的只是描述一下他們的表象庸诱。

清醒的像一只游過水面的狐貍

警惕的像一位戰(zhàn)場上的將軍

友善的像一位招待客人的女主人

單純的像一塊未經(jīng)雕琢的木頭

深邃的像一潭幽深洞穴中漆黑的池水

程序員開發(fā)了機器語言，機器語言又產(chǎn)生了匯編語言晤揣，匯編語言產(chǎn)生了編譯器桥爽，如今的語言已經(jīng)多不勝數(shù)。每一種語言都有其各自的謙卑用途昧识。每一種語言都表達出軟件的陰和陽钠四。每一種語言都在此道之中有其一席之地。

遙想當年跪楞，軟件程序員的大部分辦公司那時還被稱作實驗室缀去，程序員那時還叫做科學家侣灶。為了開發(fā)出一套優(yōu)秀的軟件，程序員們必須深入了解他們需要的應用相關的所有問題缕碎。他們必須清楚知道這個軟件應用在什么場合褥影，這個軟件是必須在什么系統(tǒng)上運行。本質上說咏雌，程序員對所要開發(fā)的軟件的所有環(huán)節(jié)都有透徹的了解凡怎，從規(guī)格說明書編寫、到軟件開發(fā)赊抖、到測試栅贴、到部署、再到技術支持熏迹。

過了不久，人類(客戶)貪婪的特性就開始表現(xiàn)出來凝赛，他們開始不斷的進行更多的索求注暗。更快的速度，更多的功能墓猎，更多的用戶捆昏，更多的所有所有。

作為一類謙虛毙沾、謙卑骗卜、且平靜的生物，我們的老一輩程序員們將很難在這種爆發(fā)性的過度的需求索取中幸存左胞。最好的取勝辦法就是往不同的方向進化成不同的新物種寇仓。很快，程序員這個稱號就開始絕跡于江湖烤宙，而那些叫做開發(fā)者遍烦、軟件工程師、網(wǎng)絡管理員躺枕、數(shù)據(jù)庫開發(fā)者服猪、網(wǎng)頁開發(fā)者、系統(tǒng)架構師拐云、測試工程師等等更多的新物種就開始誕生罢猪。快速進化和快速適應外界的挑戰(zhàn)成為了他們的DNA的一部分叉瘩。這些新的種族可以在幾個星期內就完成進化膳帕。網(wǎng)頁開發(fā)者很快就能進化成后臺開發(fā)者，前臺開發(fā)者房揭，PHP開發(fā)者备闲，Ruby開發(fā)者晌端，Angular開發(fā)者…多得讓人側目。

很快他們就都忘卻了他們都是起源于程序員這個共同的祖先的事實恬砂，忘卻了曾經(jīng)有過這么一個單純且平靜的咧纠，想要讓這個世界變得更好的科學家。然后他們開始不斷的劍拔弩張泻骤，都聲稱自己才是“程序員”的純血統(tǒng)繼承人漆羔。

隨著時間的轉移鳍咱，各門各派開始獨占山頭闷盔，很少進行交流互動，只有在迫不得已的時刻才會進行溝通妄讯。他們開始不再為同源的遙遠的同宗兄弟們的成功而歡呼雀躍趋惨，甚至再也不會時把的遙寄張明信片進行噓寒問暖鸟顺。

但是在深夜仰望星空的時候，他們還是會發(fā)現(xiàn)他們的心底深處的程序員基因還是會不停的閃爍著器虾，期盼著這閃爍的火花能照亮整個銀河系并帶來和平讯嫂。

在這場自私且以自我為中心的欲征服世界的賽跑旅程里，程序員的子孫們早把他們真正的工作目標置之腦后-為客戶解決問題兆沙。面對一拖再拖的項目交付日期欧芽，昂貴的開發(fā)代價，甚至最終失敗的項目葛圃，客戶們開始對這種情況深惡痛絕千扔。

偶爾，也會有一個閃亮的明星站出來库正，靈機一動的提供一種辦法來嘗試結束這種混亂并帶來和平曲楚。所以瀑布開發(fā)流程就應運而生了。這是一個非常了不起的創(chuàng)意诀诊，因為它利用了不同團隊的開發(fā)者們只在必須的時候才進行溝通的這個事實洞渤。當一個團隊完成了他們的工作的時候，它就會和下游的團隊進行交流并把任務進行往下傳属瓣，如此一級接一級的傳遞下去载迄，永不回首。

這種方式在一段時間內發(fā)揮了效用抡蛙，但很快护昧，一如既往，貪婪的人們(客戶)又開始提出更多的訴求粗截。他們希望能夠更多地參加到整個軟件的開發(fā)流程中來惋耙，不時的提出他們的建議，甚至在很晚的時候還提出改需求這種喪心病狂的事情來。

結果就是如大家有目共睹的事實一樣绽榛，軟件項目非常容易失敗這個說法已經(jīng)作為一個行業(yè)標準被人們所接受湿酸。數(shù)據(jù)表明超過50%的項目最終都是以失敗告終的。更可悲的是灭美，在當時看來推溃，人們對這種情況是束手無策。

值得慶幸的是届腐，每一個時代總會有那么幾個思想開放的英雄如漆黑中的螢火蟲般冒出來铁坎。他們知道這些不同團隊的開發(fā)者們必須要找到一個可以協(xié)同工作、進行交流犁苏、并且能夠彈性的向客戶保證對方將會拿到最優(yōu)的解決方案的方式硬萍。這種嘗試最早可以追溯到1957年，偉大的約翰·馮·諾依曼和同行們的努力围详。但是我們最終卻是等到2001年才收獲到革命的果實朴乖，當時行業(yè)的十多個精英創(chuàng)造出了如今聞名世界的“敏捷宣言”。

敏捷宣言基于以下十二條原則：

我們的首要任務是通過盡早地助赞、持續(xù)地交付可評價的軟件來使客戶滿意寒砖。

樂于接受需求變更，即使是在開發(fā)后期也應如此嫉拐。敏捷過程能夠駕馭變化，從而為客戶贏得競爭優(yōu)勢魁兼。

頻繁交付可使用的軟件婉徘，交付間隔越短越好，可以從幾個星期到幾個月咐汞。

在整個項目開發(fā)期間盖呼，業(yè)務人員和開發(fā)人員必須朝夕工作在一起。

圍繞那些有推動力的人們來構建項目化撕。給予他們所需的環(huán)境和支持几晤，并且信任他們能夠把工作完成好。

與開發(fā)團隊以及在開發(fā)團隊內部最快速植阴、有效的傳遞信息的方法就是蟹瘾，面對面的交談。

可使用的軟件是進度的主要衡量指標掠手。

敏捷過程提倡可持續(xù)發(fā)展憾朴。出資人、開發(fā)人員以及使用者應該總是共同維持穩(wěn)定的開發(fā)速度喷鸽。

為了增強敏捷能力众雷，應持續(xù)關注技術上的杰出成果和良好的設計。

簡潔——最大化不必要工作量的藝術——是至關重要的。

最好的架構砾省、需求和設計都源自自我組織的團隊鸡岗。

團隊應該定期反思如何能變得更有戰(zhàn)斗力，然后相應地轉變并調整其行為编兄。

敏捷宣言是為銀河系帶來和平以及維護各自的平衡所邁出的很重要的第一步轩性。在很長的時間里，相比此前基于流程和機械化的方式翻诉，這是第一次基于文化和“人性”來將不同的關鍵項目關系人連接在一起的方式炮姨。人們開始互相交流，進行基本的碰頭會議碰煌，并開始不斷的交流意見和看法舒岸。他們開始意識到他們是有著很多比想象中還多的共同點的，客戶也開始成為他們之中的一員芦圾，而不再是像以往一樣只是往項目砸錢然后開始求神拜佛祈求一切順利如愿蛾派。

盡管前面還是有不少的障礙需要克服，但是未來已經(jīng)光明了許多个少。敏捷意味著開放和擁抱(需求)改變洪乍。但是，如果改變過多的話夜焦，人們就很難專注到最終的目標和交付上來壳澳。此時精益軟件開發(fā)就開始破土而出了。

因為對精益軟件開發(fā)的著迷以及為了達成放逐和驅趕風險的目的茫经，一些程序員的子孫們就開始探首窗外巷波，開始向軟件之外的行業(yè)進行取經(jīng)。他們從一家主要的汽車生產(chǎn)商身上找到了救贖卸伞。豐田生產(chǎn)系統(tǒng)在精益上面的成就是不可思議的抹镊，同時它們的精益生產(chǎn)的經(jīng)驗也是很容易應用到軟件開發(fā)上來的。

精益有以下7個原則：

杜絕浪費

內建質量

創(chuàng)建知識(放大學習)

延遲決策(盡量延遲決定)

快速交付

尊重人員(團隊授權)

全局優(yōu)化

將這些放到敏捷上去的話荤傲，精益原則就能讓人們在從精神上關注做正確的事情垮耳，同時還能夠讓整個開發(fā)流程擁有足夠的彈性。

一旦敏捷和精益軟件開發(fā)被軟件開發(fā)團隊采納遂黍，那么下一步就是把這一套原則應用到IT團隊上來终佛。把IT也納入到整體戰(zhàn)略上，然后我們就來到了DevOps跟前了雾家！

進入DevOps – 高速公路的三條車道

老一派的軟件開發(fā)團隊成員會包含業(yè)務分析員查蓉，系統(tǒng)架構師，前端開發(fā)者榜贴，后端開發(fā)者豌研，測試員妹田，等等。優(yōu)化如敏捷和精益原則等的軟件開發(fā)流程的關注點就在這些地方鹃共。比如鬼佣，軟件一旦達到”可以生產(chǎn)“的程度，就會發(fā)到系統(tǒng)工程師霜浴、發(fā)布工程師晶衷、DBA、網(wǎng)絡工程師阴孟，安全專家這些“運維人員”的手上晌纫。這里該如何將橫在Dev(開發(fā))和Ops(運維)之間的鴻溝給填平，這就是DevOps的主要關注點了永丝。

DevOps是在整個IT價值流中實施精益原則的結果锹漱。IT價值流將開發(fā)延伸至生產(chǎn)，將由程序員這個遙遠的祖宗所繁衍的所有子孫給聯(lián)合在一起慕嚷。

這是來自Gene Kim的對DevOps的最好的解析哥牍，如果你還沒有看過他的《鳳凰項目》這本書的話，我建議你真的該好好花時間看看喝检。

你不應該重新招聘DevOps工程師嗅辣，且DevOps也不應該是一個IT的新部門。DevOps是一種文化挠说，一種理念澡谭，且是和IT糅合成一整體的。世間沒有任何工具可以把你的IT變成一個DevOps組織损俭，也沒有任何自動化方式可以指引你該如何為你的客戶提供最大化的效益译暂。

DevOps通常作為下面這三個方式而為人所熟知，而在我眼里我是把它們看成是一條高速公路上的三條車道撩炊。你從第一條車道開始，然后加速進入到第二條車道崎脉，最終在第三車道上高速行駛拧咳。

車道1 – 系統(tǒng)級別的整體效率考量是最主要的關注點，這超過對系統(tǒng)中任何一個單獨個體元素的考慮

車道2 – 確保能提供持續(xù)不斷的反饋循環(huán)囚灼，且這些反饋不被忽視骆膝。

車道3 – 持續(xù)的學習和吸取經(jīng)驗，不停的進步灶体，快速的失敗阅签。

車道1 – 獲取速度

要采納DevOps的原則，理解整個運作系統(tǒng)的重要性并對工作事項進行合適的優(yōu)先級排序是組織首先要學的事情蝎抽。在整個價值流中不能允許任何人產(chǎn)生瓶頸并降低整個工作流程政钟。

確保工作流程的不可中斷是身處流程中的所有成員的終極目標。無論一個成員或者團隊的角色是什么，他們都必須力圖對整個系統(tǒng)進行深入的理解养交。這種思維方式對質量會有著直接的影響精算，因為缺陷永遠不會被下放到“下游“中，這樣做的話將會導致瓶頸的產(chǎn)生碎连。

確保整個工作流程不會被瓶頸堵塞住還不夠灰羽。一個高產(chǎn)的組織應該時常考慮該如何提升整個工作流程鱼辙。有很多方法論可以做到這一點廉嚼，你不妨去看下“約束理論”，“六西格瑪”倒戏，精益怠噪，或者豐田生產(chǎn)系統(tǒng)。

DevOps原則不關心你身處哪個團隊峭梳，你是否是系統(tǒng)架構師舰绘，DBA，QA葱椭，或者是網(wǎng)絡管理員捂寿。相同的規(guī)則覆蓋所有的成員，每個成員都應該遵循兩個簡單的原則：

保持系統(tǒng)運作流程不可中斷

隨時提升和優(yōu)化工作流程

車道2 – 換擋加速

不可中斷的系統(tǒng)流程是定向的孵运，且預期是從開發(fā)流向運維秦陋。在一個理想的世界中，這就意味著快速的開發(fā)出高質量的軟件治笨，部署驳概，并為客戶提供價值。

但是旷赖，DevOps并非烏托邦式的理想國顺又。如果單向的交付方式是可行的話，我們的瀑布模式早就能勝任了等孵。評估可交付產(chǎn)品和整個流程中的交流對確保質量是至關重要的稚照。這里首個必須實現(xiàn)的”面向上游”的交流通道是從Ops到Dev。

我們獨自意淫是件非常容易的事情俯萌，但是獲取別人的反饋和提供反饋給別人才是探究事實真相的正確方法果录。下游的每一步(反饋)都必須緊跟著有一個上游的確定。

你如何建立反饋循環(huán)機制并不重要咐熙。你可以邀請開發(fā)人員加入技術支持團隊的會議弱恒，或者將網(wǎng)絡管理員放到Sprint計劃會議中去。一旦你的反饋機制就緒棋恼，反饋能夠被接收并被處理返弹，你就已經(jīng)可以說是走到了DevOps高速車道上來了锈玉。

車道3 – 飛速前進

DevOps這條快速車道并不適合意志脆弱的人。為了進入這條車道琉苇，你的組織必須要足夠的成熟嘲玫。這里充滿了冒險和對失敗教訓的學習，不斷的嘗試并扇，并認同屢敗屢戰(zhàn)和不斷的實踐是走向成功這條康莊大道的前提條件去团。在這里你應該會經(jīng)常聽到”套路“這個詞，這是有原因的穷蛹。不斷的訓練和重復所以能培養(yǎng)出大師土陪，是因為其讓復雜的動作常規(guī)化。

但是在你要將這些復雜的動作連接起來之前肴熏，你很有必要先去掌握好每一個單獨步驟鬼雀。

“適合大師的動作并不適合新手，脫胎換骨之前你必須先要明白道的真諦蛙吏≡戳ǎ“

DevOps的第三個方式/快速車道包括每天分配時間來持續(xù)的進行試驗，時常的獎勵敢于冒險的團隊鸦做，并將缺陷特意引入到運作系統(tǒng)上來以增加系統(tǒng)的抗擊打能力励烦。

為了確保你的組織能夠消化好這些方法，你必須在每個團隊之間建立好頻繁的反饋循環(huán)泼诱，同時需要確保所有的瓶頸都能夠及時的被清理掉坛掠，并確保整個系統(tǒng)的運作流程是不可中斷的。

實施好這些措施可以讓你的組織時刻保持警惕治筒，并能夠快速且高效的應對挑戰(zhàn)屉栓。

概要 – DevOps清單

下面是一張你可以用來檢驗你的組織對DevOps的應用情況的清單。當然你也可以在文章評論后面給出你的觀點耸袜。

開發(fā)團隊和運維團隊之間沒有障礙友多。兩者皆是DevOps統(tǒng)一流程的一部分。

從一個團隊流到另一個團隊的工作都能夠得到高質量的驗證

工作沒有堆積堤框，所有的瓶頸都已經(jīng)被處理好域滥。

開發(fā)團隊沒有占用運維團隊的時間，因為部署和維護都是處于同一個時間盒里面的胰锌。

開發(fā)團隊不會在周五下午5點后把代碼交付進行部署，剩下運維團隊周末加班加點來給他們擦屁股

開發(fā)環(huán)境標準化藐窄，運維人員可以很容易將之擴展并進行部署

開發(fā)團隊可以找到合適的方式交付新版本资昧，且運維團隊可以輕易的進行部署。

每個團隊之間的通信線路都很明確

所有的團隊成員都有時間去為改善系統(tǒng)進行試驗和實踐

常規(guī)性的引入(或者模擬)缺陷到系統(tǒng)中來并得到處理荆忍。每次學習到的經(jīng)驗都應該文檔化下來并分享給相關人員格带。事故處理成為日常工作的一部分撤缴，且處理方式是已知的

總結

使用現(xiàn)代化的DevOps工具，如Chef叽唱、Docker屈呕、Ansible、Packer棺亭、Troposphere虎眨、Consul、Jenkins镶摘、SonarQube嗽桩、AWS等，并不代表你就在正確的應用DevOps的原則凄敢。DevOps是一種思維方式碌冶。我們所有人都是該系統(tǒng)流程的一部分，我們一起分享共同的時光和交付價值涝缝。每個參加到這個軟件交付流程上來的成員都能夠加速或減緩整個系統(tǒng)的運作速度扑庞。系統(tǒng)出現(xiàn)的一個缺陷，以及錯誤配置的團隊之間的“防火墻”拒逮，都可能會使得整個系統(tǒng)癱瘓罐氨，

所有的人都是DevOps的一部分，一旦你的組織明白了這一點消恍，能夠幫你管理好這些的工具和技術棧就自然而然的會出現(xiàn)在你眼前了岂昭。