原文地址:http://www.drdobbs.com/architecture-and-design/what-exactly-is-devops/240009147 作者:Neil Garnichaud
軟體開發目前的最新趨勢是DevOps文化，即開發人員和運營人員一起確保軟體以最低的故障率執行。
很多組織發現他們面臨這樣的挑戰，即隨著雲的Web應用程式的發展，要求快速釋出以便及時響應來自使用者社群的問題或請求。及時響應使用者需求是每個軟體開發團隊的目標，但是會給組織內的功能團隊造成壓力。壓力往往導致更多的缺陷和對團隊持續性的打斷。DevOps通過構建一種開發和運營（這就是DevOps名字的由來）之間的關係來試圖解決該問題。在該結構中，開發團隊支援運營需求，比如部署指令碼，異常診斷，以及從週期最開始就進行的負載和效能測試；而運營團隊在軟體部署前，部署時及部署後向開發團隊提供知識支援和及時的反饋。
DevOps是很多軟體開發團隊正在前進的方向。他們之前忍受著組織給予的壓力，即在QA缺少時間測試的情況下還要生產高質量的程式碼。而DevOps是一個新的環境，如果開發人員想要成功，就不得不有所調整。在截止期限的壓縮，分為開發，QA，產品的故事牆成為了敏捷的阻礙。DevOps試圖打破這個牆。現在，團隊協作能力變得與技術能力一樣重要。因此，單一關注終端使用者的體驗，來看其是如何影響業務的。DevOps並不是新的工具或組織，而是新的文化和流程。它是開發，QA以及運營相互工作來加快開發和解決問題。
為什麼開發人員需要DevOps
DevOps對於開發人員來說是好事。開發人員想工作於DevOps為導向的組織中，有三個主要的原因：
更好的生活質量。DevOps模式的開發人員很少會在半夜接到電話要求解決產品問題。這是因為問題在產生災難性之前已經被發現，主動監控比被動警告要好的多。
引以為豪的所有權。傳統的軟體流程中，一旦軟體被部署，就被“甩手扔給了”QA，然後甩手扔到了產品環境。所以終端使用者看到的可能與開發人員編寫的完全不同。但在DevOps模式下，編寫的即是釋出的，因為開發人員在程式碼被交給QA甚至到產品環境後，仍可以繼續檢視和訪問程式碼。換句話說，開發人員擁有從建立到實現的整個交付過程的程式碼所有權。
更多相關的工作。開發人員和大多數人類一樣，在真實世界中相關的工作中更容易得到滿足感。因為在傳統組織中的開發人員是孤立的，他們經常虛構使用者場景來模擬問題。當出問題的時候他們只能儘量模擬接近這個問題。在DevOps模式中，場景是真實的。環境是經過負載測試的，比如，在軟體被放入產品環境之前會測試是否能正確工作。另一個例子是測試指令碼本身可以測試產品你環境，而不僅僅是模擬環境。將測試結果分享給開發人員，給予了開發人員檢視在真實條件下他們編寫的程式碼的效能的機會。
已經實現DevOps意味著什麼
可能你的組織已經採用了DevOps模型。有三個問題可以讓你清楚的瞭解DevOps的實行情況：
你作為一個開發人員，能夠實時獲取故障資訊嗎？
產品環境中是否使用了開發團隊的測試及其它工具來驗證產品環境是否能正常工作？
作為開發人員，你是否視網路團隊為你的合作伙伴？
如果這些回答都是“否”，那麼你並未真正實現DevOps。有一些建議可以改進該情況。先從工具說起。DevOps是文化和流程高於組織，工具可以幫助執行最佳實踐。特別是跨團隊共享故障資訊。這要求在軟體中新增更多的檢測資訊以便檢視軟體在QA及產品環境中的執行情況，而不僅僅是開發環境中。這些程式碼會捕獲錯誤，檢查系統引數，報告功能超時，以及返回程式執行期間的其它值，並將其寫入到日誌檔案中。
在孤立的環境中，一旦程式碼被髮布到產品環境中，開發人員往往不能再檢視這些日誌檔案。在DevOps世界中，開發人員可以檢視任意環境中的日誌檔案，不管是開發環境，QA環境還是產品環境。這樣不僅可以快速修復缺陷，也可以避免同樣的缺陷出現在將來的釋出中。這使得開發自身對業務能更快速，更具響應性，把敏捷質量引入到敏捷開發中。
打破舊習慣
DevOps也要求打破舊習慣。比如自然傾向是軟體bug數量作為衡量質量的方式。但修復單個bug並不意味著能更快的建立無bug的軟體。更好的衡量方式是處理bug的流程。換句話說，整個流程中是那個環節引入這個bug的？例如，是因為開發人員本地的構建環境與QA環境或產品環境不一致？或者是程式碼行為之所以在不同環境中表現不一致是因為某些環境中無法顯示某些東西？
除非程式碼版本是跨環境緊密同步的，而且這些環境也是緊密同步的，否則很難搞清楚一個問題到底是個邏輯問題還是資料問題，抑或環境問題，或者其它問題。而工具能夠保證其一致性。即工具能自動的將同樣的程式碼一次性部署到多個環境中。
合作伙伴或譴責者？
開發人員需要做的最大改變可能就是與其他團隊成員要有日常互動。開發人員是是主動解決軟體問題（比如通過日常監控操作日誌），還是等待問題報告給他們？當有問題時，又是如何被解決的？團隊成員是合作伙伴還是譴責者？
很多都取決於領導力。不管管理團隊如何說教DevOps願景，請以身作則，提供必要的培訓和支援，獎勵開發人員的團隊貢獻，而不僅僅是技術能力。DevOps需要一個樂隊指揮。即使當前工作並不是你的工作領域，你也應當接受它。實現DevOps環境需要理解什麼對於管理是重要的；是不是釋出更快了？是不是質量更高了？是不是開發人員對他們的程式碼更負責了？這些都與DevOps環境的方式有關。
Neil Garnichaud是SmartBear公司的Host Solutions Business經理，負責產品開發及軟體研發。