|
當一個名詞被不斷提及，就是火了嗎？但是，受關注的程度與被了解并很好的執(zhí)行并不一定成正比。DevOps，就是一個例子。對于DevOps的定義，有人說是一組流程、有人說是一個概念、有人說是應用開發(fā)和系統(tǒng)運維團隊執(zhí)行任務的混合體、有人說是一個新興的軟件集成以及IT業(yè)務的溝通協(xié)作方式、還有說是一個軟件方法……這些理解，你認為都對嗎？ DevOps的演進 先來看看DevOps是怎么發(fā)展起來的？一開始DevOps由兩個運動組成，第一個，被稱之為敏捷系統(tǒng)管理的運動，觸發(fā)點是2008年舉辦的Velocity Conference會議，主要討論關于Web的運維，以提高整個web運維的效率。之后，2009年的時候由Gordon Banner正式地推展敏捷系統(tǒng)管理的運動。第二個，對DevOps的歷史有影響的運動叫企業(yè)系統(tǒng)管理的運動，在2000年中旬的時候，由John Willis和Mark Hinkle這兩個人開始。這兩個運動的結合也就是DevOps的運動。 開發(fā)人員VS運維人員 平時，在工作當中，我們常常遇到相關不同角色的一些同事，甚至同處于一個項目中，像開發(fā)人員，環(huán)境準備人員，測試人員，運維人員，以及負責應用支援的人員、業(yè)務主管等。但經常各自劃分了'領地'，開發(fā)的同事常會告訴我們說，我用了70%時間來等待；環(huán)境準備人員常常談論沒有多余的環(huán)境了；測試人員常常告訴我們說，測試環(huán)境不夠真實，運維的同事會說應用發(fā)布就是噩夢，應用支援的同事更慘，常會問怎么找問題？但是，你發(fā)現(xiàn)沒，里面缺少了一個很重要的角色，就是業(yè)務主管，“業(yè)務主管常常會對IT部門說：“你們IT在做什么，我們正在錯過外面所帶來的業(yè)務的機會，我需要新的應用，我需要新的功能……”?？梢?，各角色僅關注于自己本身的工作，而非各角色之間的分界點。 IT正處在變革當中，現(xiàn)在大家在談論最多的就是應用經濟，因為，應用經濟所帶來的機會是巨大的。但是，很多時候我們發(fā)現(xiàn)沒有很好的抓住這些機會，其實這是由于IT創(chuàng)新能力的低下。面對業(yè)務所帶來的需求，我們仍選擇的是二十年前開發(fā)應用的方式來進行應用運維，這說明，IT需要補足這個差距。 到底是什么導致停滯不前呢？根據Forrester的調查數據顯示，低于40%的決策者認為IT能按時，按預約提供新服務，75%的決策者認為有必要提高整體IT的效率，這里面包含 IT的效率、創(chuàng)新的能力、簡化的流程、工作的效率。 DevOps的精髓，整體觀念 那么，問題怎么解決呢？IT部門的骨干是有兩個最主要的工作部門組成的，一個是研發(fā)（Development）另外一個是運維部門（Operations）,他們都有自己的思維方式來做事，研發(fā)同事常會需要快速地創(chuàng)新，寫簡易的代碼，簡單使用，Agile交付等更多功能上。而負責運維的同事有另外一套思維模式，需要系統(tǒng)穩(wěn)定地運行，最好是十年都不做任何的改變，完善的安全機制，更簡易的管理步驟等等。 而如何把這雙方的差異點整合起來，就是DevOps的精髓。DevOps（開發(fā)運維）是Development與operation這兩個詞所組成的。CA公司認為，DevOps所要達到的目的是確保穩(wěn)定的創(chuàng)新，使用敏捷開發(fā)來交付應用，敏捷運維來運維應用，這是DevOps整體的觀念。 整合開發(fā)和運維人員 目前，在高速競爭的市場，如何快速地把應用推出，如何快速地交付新的服務，成為IT不可避免的問題。那么，一套增強開發(fā)及運維之間的集成，協(xié)作及溝通的方法是很有必要的。而DevOps恰巧就能協(xié)助各個企業(yè)解決這個問題，快速地把應用交付出來。 DevOps首先，可以更快地交付業(yè)務的價值，在服務交付的過程中打破孤島，即打破開發(fā)與運維之間溝通的成本；第二，整合開發(fā)和運維的能力成為一個協(xié)作的團隊，他們不再是開發(fā)，不再是運維，而是IT的團隊。第三，DevOps最主要專注的是端到端服務交付流程的變革。 當實現(xiàn)整個DevOps的交付過程當中，必須要確保流程的變革、新式工具的推廣、或者新工作流程推廣的時候是不影響安全性，應用的兼容性，以及應用的性能，這是DevOps所需要帶來的一個價值。 DevOps的終極目標，持續(xù)交付 那么 DevOps的終極目標是什么？CA稱之為持續(xù)交付。DevOps打破信息的孤島，讓開發(fā)與運維之間更好的協(xié)作。協(xié)作目的是確保應用能快速地由開發(fā)流轉到測試，再到運維。當運維遇到問題的時候，能建制一個完整的閉環(huán)回到開發(fā)環(huán)節(jié)。 我們知道，一個應用的開始都是由開發(fā)人員開始把我們的應用開發(fā)完成了，當然我們前端還有我們的相關業(yè)務部門，業(yè)務部門把這個需求提給開發(fā)，開發(fā)的同事分析完需求之后進行他們的開發(fā)，開發(fā)完之后相關的代碼我們會放到我們的代碼庫上，這是大家現(xiàn)在常做的做法。 在一個持續(xù)交付的觀念里面，開始由相關業(yè)務部門根據需求提供給開發(fā)人員，開發(fā)人員分析完需求并并行開發(fā)，開發(fā)完成后，相關的代碼會放到代碼庫中。這時候應該有一個持續(xù)集成，也就是構建自動化（Continuous integration）平臺，平臺提供開源的工具、持續(xù)集成的工具、build的工具來進行建制持續(xù)的集成。 CA DevOps解決方案 持續(xù)集成的結果就是工件，工件可以存到代碼庫上，之后讓持續(xù)集成工具開始來呼叫CA的應用發(fā)布解決方案，——CA DevOps解決方案，將會由工件庫把最新的工件取下來，比如， ear file, war file, jar, exe 等等，這時，會自動結合發(fā)布清單把相關的應用透過已經定制好的發(fā)布流程，發(fā)布到SIT環(huán)境上去。 那么問題來了，在正常的狀況下，手工進行SIT的測試，為了實現(xiàn)持續(xù)交付的目的，自動化的測試變成必不可缺的一個環(huán)節(jié)。在這個環(huán)節(jié)上CA DevOps解決方案能呼叫下一個解決方案（CA Service Virtualization）。CA服務虛擬化包含了兩個部分，第一部分是測試的發(fā)起端，它包含錄制網頁的一些測試腳本，也包含透過傳輸協(xié)議直接發(fā)起的測試，甚至包含移動終端的一些應用的測試。 另外一部分，是能把測試過程當中應用所依賴的第三方的內外部的資源，透過服務虛擬化解決方案資源透過一定的手段虛擬出來，這樣就能達到真正的自動化測試。當啟動服務虛擬化之后，能自動針對SIT環(huán)境上面所部署的應用進行自動化完整的測試。 在測試過程當中一切順利的話，下一步會回饋到自動化的解決方案平臺，將會針對下一個環(huán)境UAT的參數、配置，跟當初所測試的工件做一個集合，然后發(fā)布到UAT環(huán)境上去，同樣，使用CA服務虛擬化解決方案，直接進行自動化完整測試。若測試過程當中發(fā)現(xiàn)某一個錯誤發(fā)生了，就能自動地回滾。 CA DevOps解決方案平臺能自動把應用回滾成舊的版本，而且是在各個環(huán)境當中都能自動地都回滾成舊版本。 接下來CA DevOps解決方案平臺用同樣的工件結合同樣環(huán)境發(fā)布清單，把應用完整地發(fā)布到生產環(huán)境上面去。而在生產環(huán)境上會面臨一個挑戰(zhàn)，就是沒有辦法進行任何流程或是交易測試。原因很簡單，因為在生產環(huán)境上做任何測試都會影響到生產的數據。所以，往往發(fā)布之后是沒辦法進行完整的測試，只能等到使用者上線使用的時候才可能發(fā)現(xiàn)問題。但是在高競爭的環(huán)境底下，當發(fā)現(xiàn)問題已經太遲了。透過CA服務虛擬化解決方案，在測試環(huán)境上就開始進行相對驗證了，在這個場景下除了應用是真實的，發(fā)起端、接收端都是虛擬的。這樣進行完整應用的交易測試以及確認應用發(fā)布完成，一切正常。 CA DevOps解決方案平臺還有一個特性，就是在發(fā)布過程當中把所有的數據記錄下來，比如，做過的動作，進行的工作，都完整地記錄下來，供后續(xù)的發(fā)布報告分析。 DevOps的終極目標，也就是持續(xù)的交付。出發(fā)點是為確保提高整體IT的運維，研發(fā)，以及交付能力效率。CA DevOps解決方案平臺做到了這一點。
|
|
|
