DevOps讓研發人員愈來愈失望？好比工做量與報酬

 　　做爲一名工程師，您在開發軟件時已經有足夠的責任。在您的工做日活動中添加更多任務（好比與DevOps相關的任務）可能聽起來不太吸引人。使用DevOps，您不只負責生成工做軟件，並且如今還須要自動化軟件的構建，測試和部署階段。這要照顧不少！可是除了額外的工做，也許你只是厭倦了DevOps運動，而圍繞它的全部炒做都會致使DevOps疲勞。

　　做爲一名前開發人員，我能夠認同這種疲勞感。我也看到一些同事對DevOps達到了必定的挫敗感。有些時候咱們犯了錯誤，即便是發佈也要承擔一切。若是咱們是完美主義者而且不喜歡提供帶有錯誤的軟件，這種狀況尤其常見。咱們甚至能夠將代碼發佈到生產中。（雖然如今你正在「作」DevOps，但這可能會成爲你的責任。）畢竟，若是咱們編碼它，咱們就知道可能出錯的事情以及若是有問題如何解決它。

　　即便如今我更多地處理服務器的操做方面 - 處理服務器並幫助公司實施DevOps - 讓我與您分享一些關於爲何我認爲工程師正在使DevOps疲勞的想法。

工做更多但得到一樣的報酬

　　DevOps已經再也不僅僅被認爲是開發人員和運營商。但缺點是一些組織正在將DevOps功能轉移給開發人員。開發人員如今可能以爲他們在完成工做後被迫處理交付管道。他們已經很難嘗試建立沒有錯誤的軟件！更有可能的是，開發人員愈來愈感到沮喪，由於他們用更多（和不一樣類型）的工做來賺取相同的工資。

　　正如我以前所說，有時開發人員認爲須要作的比他們應該作的更多。例如，若是操做人員花費太多時間來回答他們的問題和請求，開發人員總會找到一種方法來解決任何問題。他們甚至願意學習像雲和基礎架構這樣的新代碼。當開發人員完成他們的代碼而且它已經準備好運送到生產環境時，會發生不少事情。那時，它不只僅是構建而後複製/粘貼工件。部署和發佈可能更復雜，一個團隊沒法處理全部事情。

　　我不認爲開發人員會加倍努力。但有些時候，這些新職責被視爲理所固然。這就是DevOps的問題在於工程師。

經歷失去專業化的後果

　　儘管工程師仍然在編程，DevOps仍然但願將基礎設施視爲代碼，但工程師如今須要瞭解基礎設施。在不浪費資源的狀況下配置和配置服務器並不是易事。固然，軟件工程師須要確保他們的代碼不會產生內存泄漏，而且不會過分使用線程或網絡。可是知識開發人員須要處理這些任務並不足以證實他們稱他們爲基礎架構專家。

　　必須適當擴展應用程序並運行基礎架構可能須要一些時間才能正確完成。操做人員須要考慮不少事情，例如服務器是在本地運行仍是在雲或混合環境中運行。說擁有Chef食譜，Terraform模板或Ansible playbook就足夠了。若是組織有一個主題專家來充分利用基礎設施並優化成本，那就更好了。什麼都沒有經驗。

　　一樣，開發人員更多地瞭解基礎架構以及他們的代碼如何影響生產系統並非一件壞事。但有些開發人員喜歡建立應用程序代 開發人員可能會以爲DevOps正在對它們進行去專業化，由於他們須要處理全部其餘事情來發布軟件。

　　DevOps實踐和工具不斷髮展和發展，開發人員的領域也是如此。與主題專家合做老是好的，由於當那些奇怪的問題出現時......你會打電話給誰？固然不是捉鬼敢死隊。

聽取每一個人談論DevOps

　　「每一個人都在作DevOps，你也應該這樣作。」 我相信你已經聽到了這個消息。

　　我相信DevOps的結果很是好，但只有在您以前發現DevOps很是適合解決方案的問題時。若是您只是實施DevOps，由於它是新的趨勢，那麼您可能對當前的交付管道很好。特別是對於DevOps來講，嘗試複製對他人有用的東西並非一個好主意; 每一個人都有不一樣的需求和問題。

　　我喜歡Gene Kim定義DevOps的方式，但我只會引用一篇與這篇文章相關的句子 - 我不想爲你的疲勞作出貢獻。他說，「DevOps不是關於你作什麼，而是你的結果是什麼。」 若是DevOps的是你的什麼結果是，而不是你作什麼，它沒有任何採起的DevOps感。您可能已經在作一些DevOps事情而且尚未注意到。

　　若是你只是厭倦了全部DevOps的東西，那很好。我偶爾也會感到疲勞。在個人狀況下，這是由於人們對DevOps的理解不正確，致使他們實現DevOps運動開始修復的事情 - 好比經過創建一個單獨的團隊或爲每一個人添加「完整堆棧」標題來建立另外一個孤島這創造了每一個人都須要瞭解一切的想法。

得到更多壓力以快速交付

　　人們讓DevOps錯誤的另外一種方式是設置指望，由於他們如今正在「作」DevOps，組織應該天天進行屢次部署。改變一切須要時間。DevOps意味着文化的變化，當組織龐大時，改變文化變得更加困難。認爲你可以在一晚上之間提供更快的速度是錯誤的。你須要照顧不少東西。一些示例是自動構建和測試，相似生產的環境，配置管理等。

　　DevOps有不少不切實際的指望，天天幾回部署就是其中之一。絕不奇怪，當Flickr的John Allspaw和Paul Hammond談到天天在一次會議上進行十次部署時，不少人開始聽到這個消息。該DevOps的報告的2017年國家還增強了思想，高績效（如Amazon，Netflix公司，谷歌和其餘「獨角獸」公司）作天天幾個部署。

　　全部這一切都很吸引人，因此我理解爲何有些組織想要「作」DevOps。但要取得成功，首先須要肯定問題所在。天天進行屢次部署有不少好處，但要作到這一點並不容易。我前一段時間寫了一篇文章。

　　您不該該讓本身X個月符合DevOps標準，而且提供更快的速度。工程師已經有足夠的壓力來知足最後期限，增長更多指望並無任何好處。

結果是重要的

　　讓我再一次重複基因的引用。「DevOps不是關於你作什麼，而是你的結果是什麼。」 當你接受這個想法時，你會開始意識到你對DevOps的許多想法都沒有意義。在您的交付管道中向左移動活動並不意味着開發人員如今將處理全部事情，或者操做人員將在系統中編寫新功能。拼圖中的每個部分都有其目的，而且迫令人們將超出職責範圍的任務添加到他們的工做量中歷來都不是一個好習慣。

　　工程師可能會對DevOps感到厭倦，由於他們最終會作更多的工做。固然，他們正在學習新事物，但他們也在他們的領域脫離專業。或者管理層可能會增長更多壓力和不切實際的指望，而不是意識到這種變化不會在一晚上之間發生。但也有可能工程師剛剛聽到每一個人都在談論DevOps。

　　若是您或您的團隊感到DevOps疲勞，請暫時忘掉它。在將代碼更改推送到生產環境時，肯定您遇到問題的位置。緣由各不相同，但您的流程，工具甚至是您的員工可能會阻止您輕鬆地發佈軟件。DevOps背後的想法並不壞; 問題是每一個人都有不一樣的DevOps定義並以不一樣的方式實現它，這使人沮喪。

————————————————————

推薦閱讀：

老王講架構：負載均衡

支付寶系統架構內部剖析

大數據Spark與Storm技術選型

【贊】用Python實現Zabbix-API 監控

程序員怎麼留住健康？

大數據智慧平臺技術方案

大數據聚合平臺解決方案