我最近參加了由 Logrocon 主辦的 DevOpsForum 2019。 在本次會議上，與會者試圖尋找業務和開發以及資訊技術服務專家之間有效互動的解決方案和新工具。
會議非常成功：確實有很多有用的報告、有趣的演示格式以及與演講者的大量交流。 尤其重要的是，沒有人試圖向我推銷任何東西，這是大型會議上的演講者最近犯過的錯誤。
摘錄自Raiffeisenbank、Alfastrakhovanie的演講，芒果電信實施自動化的經驗等細節切下。
我叫 Yana，我是測試員，負責自動化以及 DevOps，我喜歡參加會議和聚會。 在過去的兩年裡，我參加了 Oleg Bunin 的會議（HighLoad++、TeamLead Conf）、Jug 活動（Heisenbug、JPoint）、TestCon 莫斯科、DevOps Pro 莫斯科、Big Data 莫斯科。
首先，我提請大家注意會議議程。 我較少關注報告內容，而更關注演講者。 即使該報告被證明非常技術性和有趣，但事實上您並不能夠在您的公司應用報告中的一些最佳實踐。 然後你需要一個揚聲器。
Raiffeisenbank 管道末端的曙光
通常，我會在場外尋找我有興趣的演講者。 在 2019 年 DevOpsForum 上，Raiffeisenbank 的一位演講者 Mikhail Bizhan 引起了我的興趣。 在演講中，他談到了他們如何逐漸讓自己的團隊迷上DevOps、為什麼需要DevOps，以及如何將DevOps轉型的想法推銷給企業。 嗯，總的來說，我談到瞭如何看到管道末端的光。
Mikhail Bizhan，Raiffeisenbank 自動化總監
現在他們的公司沒有「DevOps」。 也就是說，他在工作，但不是在所有球隊。 在實施 DevOps 時，他們依賴團隊的準備情況，既包括特定工程師的準備情況，也包括產品的需求以及建構該產品的平台的成熟度。 Misha 講述如何向企業解釋為什麼需要 DevOps。
銀行業有幾個成長動力：服務成本和客戶群的擴大。 增加服務成本並不是一個很好的驅動因素，但擴大客戶群則相反。 如果競爭對手發布了客觀上很酷的產品，所有客戶都會去那裡，那麼隨著時間的推移，市場就會趨於平穩。 因此，向市場推出新產品以及推出速度是銀行關注的重點。 這正是 DevOps 的目的，企業也明白這一點。
下一個重要注意事項：DevOps 並不總是能縮短上市時間。 DevOps 不能單獨工作，它只是創建產品並將其推向市場的過程的一部分，從開發到生產（從程式碼到客戶）。 但程式碼之前的所有內容都與 DevOps 沒有直接關係。 也就是說，行銷人員可以研究市場多年，並用一輩子的時間來追趕競爭對手。 有必要快速了解客戶的需求並規劃這個或那個功能的實施 - 通常這不足以讓 DevOps 發揮作用，也不足以讓公司實現其目標。 因此，首先，Raiffeisenbank同意企業界的觀點，即有必要學習如何使用DevOps。 為了自動化而自動化對於爭取新客戶沒有太大幫助。
總的來說，Misha 認為需要明智地實施 DevOps。 我們必須做好準備，在轉型之初，團隊的生產力會下降，賺的錢會減少，但隨後就會變得合理。
芒果電信的測試自動化
作為測試人員，我的另一個有趣的報告是來自 Mango Telecom 的 Egor Maslov。 演講的主題是「SCRUM 團隊中完整測試週期的自動化」。 Egor 認為 DevOps 是專門為 SCRUM 創建的，但同時，將 DevOps 引入 SCRUM 團隊是相當有問題的。 發生這種情況是因為 SCRUM 團隊總是在某個地方運行，沒有時間因創新而分心並重建流程。 問題還在於SCRUM不涉及團隊中子團隊（測試團隊、開發團隊等）的分離。 嗯，此外，要自動化現有流程，需要文檔，而在 SCRUM 中，大多數情況下完全沒有文檔 - “產品比某種寫作更重要。”
切換到 SCRUM 後，測試人員開始與開發人員協商如何測試功能。 逐漸地，功能量增加，沒有文檔，他們開始發現測試未涵蓋的功能中的許多錯誤，並且通常不再清楚誰測試了它以及何時測試。 簡而言之——混亂和動搖。 我們決定轉向測試自動化。 但即便如此，還是完全失敗了。 他們聘請了外包自動化專家，這些專家在內部測試人員不知道的堆疊上進行編寫。 自動測試框架當然有效，但在外包商離開後，它持續了兩週。 接下來是嘗試引入第二個自動測試。 首先，一切都需要在公司內部、您自己（正確的方向：在內部建立專業知識）在 SCRUM 框架內構建，並在此過程中建立文件。 自動化的堆疊應該等於產品的堆疊（這裡我添加它，不要用其他東西測試你的 JavaScript 專案）。 在衝刺結束時，他們示範了自動測試如何與整個團隊一起工作（有幫助）。 因此，所有團隊成員對自動化過程的參與度都增加了，對自動測試的信任度也提高了，而且這個自動測試肯定會被使用的機會（並且不會因為不斷失敗而在一個月內被註釋掉）。
順便說一句，在 DevOpsForum 2019 上有一個開放式麥克風——這是一種眾所周知的、在我看來很有用的演講形式。 你就這樣走來走去，聽聽報告，然後決定在會議上值得討論某個話題或問題，分享解決問題的相關經驗。
我還注意到主辦單位做了一系列的簡短報道。 每份報告持續時間不超過 10 分鐘，隨後提出問題。 透過這種方式，您可以一次涵蓋許多主題並向您感興趣的演講者提問。
在演講間隙，我在會議合作夥伴的展位上走來走去，偷了/贏得了很多東西。 哦，我喜歡講義！
與 Alfastrakhovanie 開發總監的圓桌會議和 DevOps 問題
對我來說，DevOpsForum 2019 的錦上添花是與 DevOps 專家進行的長達一小時的全體會議。 四位會議參與者受邀從不同角度審視DevOps：Anton Isanin（Alfastrakhovanie，開發總監）、Nailya Zamashkina（金融科技實驗室，營運總監）、Oleg Egorkin（Rostelecom，敏捷教練）和Anton Maryanov（獨立專家，著眼於DevOps）從商業角度來看）。
專家們坐在離人們更近的地方，然後事情就開始發生了：整整一個小時，觀眾中的參與者提出了他們的問題，專家們接受了批評。 有時會有真正的辯論。 問題非常不同，例如：是否需要 DevOps 工程師、為什麼不能將他們培訓為系統管理員、是否應該向每個人提供 DevOps、它的價值是什麼，等等。
然後，我親自與安東·伊薩寧進行了交談。 我們討論了將 DevOps 文化帶入每個家庭的必要性，並揭示了 DevOps 轉型的陰暗面。
讓我們想像一下，每個人聚集在一起並決定產品、業務和團隊都需要 DevOps。 讓我們去實施吧。 一切順利。 我們呼出一口氣。 DevOps拉近了我們與客戶的距離，現在我們可以快速滿足他的所有願望。 因此，我們有一個龐大的營運部門，有著嚴格的規定和要求，它不斷地發現產品中的缺陷並產生大量的請求。 此外，所有缺陷都被指派為「緊急」狀態，即使客戶意外地希望將按鈕顏色設為黃色而不是綠色。 專案不斷成長，版本數量不斷增加，相應地，客戶對新功能的缺陷和誤解也不斷增加。 營運部門又僱用了 10 名員工來跟上報告缺陷的速度，開發部門又僱用了 15 名員工來跟上關閉缺陷的速度。 團隊沒有引入新功能，而是與無盡的 SD 合作，同時向用戶解釋功能並提供支援。 結果，營運和開發都在進行業務，但客戶和業務部門都不滿意：新功能陷入困境。 事實證明，DevOps 看似存在，又彷彿不存在。
對於是否需要實施DevOps，Anton明確表示，這直接取決於業務規模。 如果每年為一個客戶提供服務可為公司帶來十億美元的收入，則不需要 DevOps（前提是您不需要定期向該客戶推出新的更改）。 一切都被巧克力覆蓋著。 但如果業務成長並且出現更多客戶，那麼您就需要遵守。 一般來說，公司最初並沒有很酷的營運團隊。 首先我們切割產品，然後我們才明白，為了使產品正常工作，我們需要密切關注伺服器並監控供應。 這就是Ops應運而生的時候。 尚待理解的是，營運作為一個獨立的部門，將開始為開發設置一系列障礙，所有交付都將開始停滯。 也就是說，在這種情況下，DevOps 文化已經是相關的，但我們不能忘記它的陰暗面。
來源： www.habr.com