歷史回顧
為了能夠更好的理解什麼是DevOps，我們很有必要對當時還只有程式設計師(此前還沒有派生出開發者，前臺工程師，後臺工程師之類)這個稱號存在的歷史進行一下回顧。
如程式設計之道中所言：
老一輩的程式設計師是神祕且深奧的。我們沒法揣摩他們的想法，我們所能做的只是描述一下他們的表象。
清醒的像一隻遊過水面的狐狸
警惕的像一位戰場上的將軍
友善的像一位招待客人的女主人
單純的像一塊未經雕琢的木頭
深邃的像一潭幽深洞穴中漆黑的池水
程式設計師開發了機器語言，機器語言又產生了組合語言，組合語言產生了編譯器，如今的語言已經多不勝數。每一種語言都有其各自的謙卑用途。每一種語言都表達出軟體的陰和陽。每一種語言都在此道之中有其一席之地。
遙想當年，軟體程式設計師的大部分辦公司那時還被稱作實驗室，程式設計師那時還叫做科學家。為了開發出一套優秀的軟體，程式設計師們必須深入瞭解他們需要的應用相關的所有問題。他們必須清楚知道這個軟體應用在什麼場合，這個軟體是必須在什麼系統上執行。本質上說，程式設計師對所要開發的軟體的所有環節都有透徹的瞭解，從規格說明書編寫、到軟體開發、到測試、到部署、再到技術支援。
過了不久，人類(客戶)貪婪的特性就開始表現出來，他們開始不斷的進行更多的索求。更快的速度，更多的功能，更多的使用者，更多的所有所有。
作為一類謙虛、謙卑、且平靜的生物，我們的老一輩程式設計師們將很難在這種爆發性的過度的需求索取中倖存。最好的取勝辦法就是往不同的方向進化成不同的新物種。很快，程式設計師這個稱號就開始絕跡於江湖，而那些叫做開發者、軟體工程師、網路管理員、資料庫開發者、網頁開發者、系統架構師、測試工程師等等更多的新物種就開始誕生。快速進化和快速適應外界的挑戰成為了他們的DNA的一部分。這些新的種族可以在幾個星期內就完成進化。網頁開發者很快就能進化成後臺開發者，前臺開發者，PHP開發者，Ruby開發者，Angular開發者…多得讓人側目。
很快他們就都忘卻了他們都是起源於程式設計師這個共同的祖先的事實，忘卻了曾經有過這麼一個單純且平靜的，想要讓這個世界變得更好的科學家。然後他們開始不斷的劍拔弩張，都聲稱自己才是“程式設計師”的純血統繼承人。
隨著時間的轉移，各門各派開始獨佔山頭，很少進行交流互動，只有在迫不得已的時刻才會進行溝通。他們開始不再為同源的遙遠的同宗兄弟們的成功而歡呼雀躍，甚至再也不會時把的遙寄張明信片進行噓寒問暖。
但是在深夜仰望星空的時候，他們還是會發現他們的心底深處的程式設計師基因還是會不停的閃爍著，期盼著這閃爍的火花能照亮整個銀河系並帶來和平。
在這場自私且以自我為中心的欲征服世界的賽跑旅程裡，程式設計師的子孫們早把他們真正的工作目標置之腦後-為客戶解決問題。面對一拖再拖的專案交付日期，昂貴的開發代價，甚至最終失敗的專案，客戶們開始對這種情況深惡痛絕。
偶爾，也會有一個閃亮的明星站出來，靈機一動的提供一種辦法來嘗試結束這種混亂並帶來和平。所以瀑布開發流程就應運而生了。這是一個非常了不起的創意，因為它利用了不同團隊的開發者們只在必須的時候才進行溝通的這個事實。當一個團隊完成了他們的工作的時候，它就會和下游的團隊進行交流並把任務進行往下傳，如此一級接一級的傳遞下去，永不回首。
這種方式在一段時間內發揮了效用，但很快，一如既往，貪婪的人們(客戶)又開始提出更多的訴求。他們希望能夠更多地參加到整個軟體的開發流程中來，不時的提出他們的建議，甚至在很晚的時候還提出改需求這種喪心病狂的事情來。
結果就是如大家有目共睹的事實一樣，軟體專案非常容易失敗這個說法已經作為一個行業標準被人們所接受。資料表明超過50%的專案最終都是以失敗告終的。更可悲的是，在當時看來，人們對這種情況是束手無策。
值得慶幸的是，每一個時代總會有那麼幾個思想開放的英雄如漆黑中的螢火蟲般冒出來。他們知道這些不同團隊的開發者們必須要找到一個可以協同工作、進行交流、並且能夠彈性的向客戶保證對方將會拿到最優的解決方案的方式。這種嘗試最早可以追溯到1957年，偉大的約翰·馮·諾依曼和同行們的努力。但是我們最終卻是等到2001年才收穫到革命的果實，當時行業的十多個精英創造出瞭如今聞名世界的“敏捷宣言”。
敏捷宣言基於以下十二條原則：
我們的首要任務是通過儘早地、持續地交付可評價的軟體來使客戶滿意。
樂於接受需求變更，即使是在開發後期也應如此。敏捷過程能夠駕馭變化，從而為客戶贏得競爭優勢。
頻繁交付可使用的軟體，交付間隔越短越好，可以從幾個星期到幾個月。
在整個專案開發期間，業務人員和開發人員必須朝夕工作在一起。
圍繞那些有推動力的人們來構建專案。給予他們所需的環境和支援，並且信任他們能夠把工作完成好。
與開發團隊以及在開發團隊內部最快速、有效的傳遞資訊的方法就是，面對面的交談。
可使用的軟體是進度的主要衡量指標。
敏捷過程提倡可持續發展。出資人、開發人員以及使用者應該總是共同維持穩定的開發速度。
為了增強敏捷能力，應持續關注技術上的傑出成果和良好的設計。
簡潔——最大化不必要工作量的藝術——是至關重要的。
最好的架構、需求和設計都源自自我組織的團隊。
團隊應該定期反思如何能變得更有戰鬥力，然後相應地轉變並調整其行為。
敏捷宣言是為銀河系帶來和平以及維護各自的平衡所邁出的很重要的第一步。在很長的時間裡，相比此前基於流程和機械化的方式，這是第一次基於文化和“人性”來將不同的關鍵專案關係人連線在一起的方式。人們開始互相交流，進行基本的碰頭會議，並開始不斷的交流意見和看法。他們開始意識到他們是有著很多比想象中還多的共同點的，客戶也開始成為他們之中的一員，而不再是像以往一樣只是往專案砸錢然後開始求神拜佛祈求一切順利如願。
儘管前面還是有不少的障礙需要克服，但是未來已經光明瞭許多。敏捷意味著開放和擁抱(需求)改變。但是，如果改變過多的話，人們就很難專注到最終的目標和交付上來。此時精益軟體開發就開始破土而出了。
因為對精益軟體開發的著迷以及為了達成放逐和驅趕風險的目的，一些程式設計師的子孫們就開始探首窗外，開始向軟體之外的行業進行取經。他們從一家主要的汽車生產商身上找到了救贖。豐田生產系統在精益上面的成就是不可思議的，同時它們的精益生產的經驗也是很容易應用到軟體開發上來的。
精益有以下7個原則：
杜絕浪費
內建質量
建立知識(放大學習)
延遲決策(儘量延遲決定)
快速交付
尊重人員(團隊授權)
全域性優化
將這些放到敏捷上去的話，精益原則就能讓人們在從精神上關注做正確的事情，同時還能夠讓整個開發流程擁有足夠的彈性。
一旦敏捷和精益軟體開發被軟體開發團隊採納，那麼下一步就是把這一套原則應用到IT團隊上來。把IT也納入到整體戰略上，然後我們就來到了DevOps跟前了！
進入DevOps – 高速公路的三條車道
老一派的軟體開發團隊成員會包含業務分析員，系統架構師，前端開發者，後端開發者，測試員，等等。優化如敏捷和精益原則等的軟體開發流程的關注點就在這些地方。比如，軟體一旦達到”可以生產“的程度，就會發到系統工程師、釋出工程師、DBA、網路工程師，安全專家這些“運維人員”的手上。這裡該如何將橫在Dev(開發)和Ops(運維)之間的鴻溝給填平，這就是DevOps的主要關注點了。
DevOps是在整個IT價值流中實施精益原則的結果。IT價值流將開發延伸至生產，將由程式設計師這個遙遠的祖宗所繁衍的所有子孫給聯合在一起。
這是來自Gene Kim的對DevOps的最好的解析，如果你還沒有看過他的《鳳凰專案》這本書的話，我建議你真的該好好花時間看看。
你不應該重新招聘DevOps工程師，且DevOps也不應該是一個IT的新部門。DevOps是一種文化，一種理念，且是和IT糅合成一整體的。世間沒有任何工具可以把你的IT變成一個DevOps組織，也沒有任何自動化方式可以指引你該如何為你的客戶提供最大化的效益。
DevOps通常作為下面這三個方式而為人所熟知，而在我眼裡我是把它們看成是一條高速公路上的三條車道。你從第一條車道開始，然後加速進入到第二條車道，最終在第三車道上高速行駛。
車道1 – 系統級別的整體效率考量是最主要的關注點，這超過對系統中任何一個單獨個體元素的考慮
車道2 – 確保能提供持續不斷的反饋迴圈，且這些反饋不被忽視。
車道3 – 持續的學習和吸取經驗，不停的進步，快速的失敗。
車道1 – 獲取速度
要採納DevOps的原則，理解整個運作系統的重要性並對工作事項進行合適的優先順序排序是組織首先要學的事情。在整個價值流中不能允許任何人產生瓶頸並降低整個工作流程。
確保工作流程的不可中斷是身處流程中的所有成員的終極目標。無論一個成員或者團隊的角色是什麼，他們都必須力圖對整個系統進行深入的理解。這種思維方式對質量會有著直接的影響，因為缺陷永遠不會被下放到“下游“中，這樣做的話將會導致瓶頸的產生。
確保整個工作流程不會被瓶頸堵塞住還不夠。一個高產的組織應該時常考慮該如何提升整個工作流程。有很多方法論可以做到這一點，你不妨去看下“約束理論”，“六西格瑪”，精益，或者豐田生產系統。
DevOps原則不關心你身處哪個團隊，你是否是系統架構師，DBA，QA，或者是網路管理員。相同的規則覆蓋所有的成員，每個成員都應該遵循兩個簡單的原則：
保持系統運作流程不可中斷
隨時提升和優化工作流程
車道2 – 換擋加速
不可中斷的系統流程是定向的，且預期是從開發流向運維。在一個理想的世界中，這就意味著快速的開發出高質量的軟體，部署，併為客戶提供價值。
但是，DevOps並非烏托邦式的理想國。如果單向的交付方式是可行的話，我們的瀑布模式早就能勝任了。評估可交付產品和整個流程中的交流對確保質量是至關重要的。這裡首個必須實現的”面向上游”的交流通道是從Ops到Dev。
我們獨自意淫是件非常容易的事情，但是獲取別人的反饋和提供反饋給別人才是探究事實真相的正確方法。下游的每一步(反饋)都必須緊跟著有一個上游的確定。
你如何建立反饋迴圈機制並不重要。你可以邀請開發人員加入技術支援團隊的會議，或者將網路管理員放到Sprint計劃會議中去。一旦你的反饋機制就緒，反饋能夠被接收並被處理，你就已經可以說是走到了DevOps高速車道上來了。
車道3 – 飛速前進
DevOps這條快速車道並不適合意志脆弱的人。為了進入這條車道，你的組織必須要足夠的成熟。這裡充滿了冒險和對失敗教訓的學習，不斷的嘗試，並認同屢敗屢戰和不斷的實踐是走向成功這條康莊大道的前提條件。在這裡你應該會經常聽到”套路“這個詞，這是有原因的。不斷的訓練和重複所以能培養出大師，是因為其讓複雜的動作常規化。
但是在你要將這些複雜的動作連線起來之前，你很有必要先去掌握好每一個單獨步驟。
“適合大師的動作並不適合新手，脫胎換骨之前你必須先要明白道的真諦。“
DevOps的第三個方式/快速車道包括每天分配時間來持續的進行試驗，時常的獎勵敢於冒險的團隊，並將缺陷特意引入到運作系統上來以增加系統的抗擊打能力。
為了確保你的組織能夠消化好這些方法，你必須在每個團隊之間建立好頻繁的反饋迴圈，同時需要確保所有的瓶頸都能夠及時的被清理掉，並確保整個系統的運作流程是不可中斷的。
實施好這些措施可以讓你的組織時刻保持警惕，並能夠快速且高效的應對挑戰。
概要 – DevOps清單
下面是一張你可以用來檢驗你的組織對DevOps的應用情況的清單。當然你也可以在文章評論後面給出你的觀點。
開發團隊和運維團隊之間沒有障礙。兩者皆是DevOps統一流程的一部分。
從一個團隊流到另一個團隊的工作都能夠得到高質量的驗證
工作沒有堆積，所有的瓶頸都已經被處理好。
開發團隊沒有佔用運維團隊的時間，因為部署和維護都是處於同一個時間盒裡面的。
開發團隊不會在週五下午5點後把程式碼交付進行部署，剩下運維團隊週末加班加點來給他們擦屁股
開發環境標準化，運維人員可以很容易將之擴充套件並進行部署
開發團隊可以找到合適的方式交付新版本，且運維團隊可以輕易的進行部署。
每個團隊之間的通訊線路都很明確
所有的團隊成員都有時間去為改善系統進行試驗和實踐
常規性的引入(或者模擬)缺陷到系統中來並得到處理。每次學習到的經驗都應該文件化下來並分享給相關人員。事故處理成為日常工作的一部分，且處理方式是已知的
總結
使用現代化的DevOps工具，如Chef、Docker、Ansible、Packer、Troposphere、Consul、Jenkins、SonarQube、AWS等，並不代表你就在正確的應用DevOps的原則。DevOps是一種思維方式。我們所有人都是該系統流程的一部分，我們一起分享共同的時光和交付價值。每個參加到這個軟體交付流程上來的成員都能夠加速或減緩整個系統的運作速度。系統出現的一個缺陷，以及錯誤配置的團隊之間的“防火牆”，都可能會使得整個系統癱瘓，
所有的人都是DevOps的一部分，一旦你的組織明白了這一點，能夠幫你管理好這些的工具和技術棧就自然而然的會出現在你眼前了。