作為一名工程師，您在開發軟件時已經有足夠的責任。在您的工作日活動中添加更多任務（比如與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定義並以不同的方式實現它，這令人沮喪。
————————————————————
推薦閱讀：