在我作為IT顧問的整個職業生涯中,我與各種平台和技術打交道,我遇到過無數向我解釋他們公司如何接近現代軟件開發的術語。敏捷,DevOps、SAFe等。
他們都有一個熱情的擁護者團體,在麵對任何質疑時,他們隨時準備為這個詞辯護。我個人既不讚成也不反對這些條款。如果某件事對一個組織有效,那就太好了。為了獲得同樣的成功,許多公司陷入了一個過度炒作的解決方案的陷阱,把它當作一個新模板或模式,如果他們想要成功,每個人都必須適應它。
重要的是,公司必須認識到DevOps不是適用於所有公司的一刀切的解決方案。我的印象是,如果像穀歌、Facebook或微軟這樣的潮流引領者決定做某事,那麼所有人都必須做這件事。
再加上過於認真對待自己的額外壓力——變得有點嚴厲——你就像被扔進魚塘的新魚餌,對於像我這樣的人來說,在經曆了這麼多IT項目之後,他們通常充滿了憤世嫉俗。
為什麼“DevOops ?”
當我問一些公司他們在DevOps方麵的成熟程度是多少時,我通常得到的回答是“我們正在朝著那個方向前進。”類似的說法也可以用在與持續性能測試相關的公司上,這通常意味著公司正在做一些事情,但他們還沒有完全弄清楚。
這讓我明白了為什麼我現在把大多數當前的DevOps計劃視為“DevOops”——換句話說,這是對DevOps的錯誤嚐試。大多數商業領袖和公司都在不斷地尋找最新的發展、趨勢或流行詞彙,以加速創新、節省時間和金錢,並與競爭對手競爭。近年來,DevOps已經成為各個公司最流行的詞彙之一。
最終,公司實施敏捷或DevOps模型的最大因素之一是F.O.M.O.(害怕錯過)。因此,公司嚐試采用DevOps實踐是為了保持相關性。
這最終在軟件開發過程中導致了更多的問題,與他們的舊的、傳統的方法相比。這並不是說你們的傳統模式就是你們公司未來的發展方向。您需要確保您已經為這種類型的模型做好了準備。
模仿是最真誠的奉承方式……真的是這樣嗎?
當公司模仿他們的競爭對手時,他們是在試圖跟上他們的競爭對手並保持相關性。很多時候,他們在這樣做的時候,並沒有坐下來確定DevOps模型的最佳實現方式為他們——或者他們是否需要DevOps實踐。如果你的主要目標隻是為了提高速度而提高速度,那就會導致災難(或者在這種情況下,產品開發問題)。
當談到性能測試時,選擇速度而不是性能並不能解決問題。許多公司經常問我如何將每個API測試或端到端性能測試放入CI管道中,以收集計時指標,他們希望盡快做到這一點。
然而,這樣做的結果通常是度量不有效,它們不能幫助解決性能問題,並成為一個“複選框活動”。你可能會問,為什麼這些指標無效?因為收集到的指標並不能為受眾(即開發者)提供真正的價值,這將導致被忽視或被認為是無關緊要的。
與此同時,公司已經遇到的性能問題在為時已晚之後繼續被發現。通常情況下,在支持單中有需要處理的生產中斷或客戶體驗問題。自動化並沒有解決這個問題。測試通過CI管道運行的速度並沒有解決問題。頭痛依然存在。
但是等等,有光!
根據我的經驗,有三件事表明一家公司成功地實施了DevOps模型/戰略;
- 已經實現了服務虛擬化(或等效的):這使他們能夠針對未完成的特性和服務進行測試,而不必等到開發完成才進行測試。如果他們沒有辦法對工作的功能進行自動化測試,而其他功能還沒有創建,那麼他們將落後於自動化,測試也將永遠落後。
- 他們將產品版本與用戶訪問新特性分離開來:這意味著他們在無聲地發布代碼,以允許終端用戶以他們選擇的速度訪問,例如試點組。如果他們推出的東西把一切都搞砸了,他們可以通過特性標誌快速恢複到以前的版本。
- 重複的任務自動化:他們不斷地在研究如何通過自動化重複任務來減少工作環境中的辛勞,同時確保有適當的手動審查,即使標準的通過/失敗標準有例外。並不是所有的事情都是如此簡單——通過或不通過。一個好的DevOps組織知道如何在減少工作量和不加思考的管道速度之間取得平衡。
最終,困擾公司性能測試計劃的解決方案將歸結於他們希望從測試結果中收集的結果類型。如果您希望實現可靠的性能測試結果,使您的公司能夠做出自信的業務決策,那麼隻需查看終端用戶體驗即可。
未來向前DevOps
目前,DevOps的采用仍處於“宣傳周期”階段,或者被Gartner稱為“過高期望的頂峰“因此,有很多人並沒有完全認真對待他們的DevOps追求,並拒絕讓DevOps工作的核心事情,因為它們很難做。
在未來的五年裏,我們將看到DevOps的熱潮逐漸消退,因為公司將“提高”他們的員工的技能,並為站點可靠性工程師所需的技能設置新雇員的期望。到那時,公司將知道如何從它獲得正確的價值,一些公司將知道他們可以在沒有它的情況下獲得更好的價值。
關於作者:
Scott Moore,客戶工程總監,Tricentis