Express 42 的管理合夥人兼作者 Alexander Titov 表示，利用這些知識可以去哪裡、在專案中做什麼、賺多少錢、在面試中該說什麼和問什麼。 .
你好！ 儘管DevOps這個術語自2009年以來就已經存在，但俄羅斯社區仍然沒有共識。 您可能已經注意到，有些人認為 DevOps 是一種專業，有些人認為它是一種哲學，有些人認為這個術語是一組技術。 我已經表演過很多次了 關於這個方向的發展，所以本文不再贅述。 我只想說，在 Express 42 中，我們包含以下內容：
DevOps 是一種特定的方法，是一種創建數位產品的文化，團隊中的所有專家都參與生產。
在傳統的企業開發中，一切都是依序進行的：程式設計、測試、然後運行，這個過程從想法到生產的速度是3個月。 這是數位產品的全球性問題，因為不可能快速收到客戶的回饋。
在 DevOps 中，工具和方法旨在確保開發、測試和營運流程同時運作。
這種方法會產生什麼結果？
- 你不可能僱用一些「工程師」來解決生產中的所有問題。 整個團隊必須應用該技術。
- DevOps 並不是下一個需要升級的系統管理員形式。 「DevOps 工程師」聽起來與「敏捷開發人員」大致相同。
- 如果一個團隊使用 Kubernetes、Ansible、Prometheus、Mesosphere 和 Docker，這並不意味著該團隊已經實施了 DevOps 實務。
DevOps 之後的生活將永遠不一樣
首先，DevOps 方法是一種不同的思考方式，一種對整個開發以及個人在流程中的地位的看法。 我們將線上課程分為兩個部分：
1. 自決
首先，我們詳細檢視 DevOps 方法的本質，學生在團隊中發現新的角色，看看哪個角色反應較多，並自行確定發展的方向。
2. 工具與實踐
學生從DevOps方法的角度掌握具體技術。
DevOps 工具既可用於 DevOps 方法，也可用於經典開發。 最明顯的例子是使用 Ansible 設定管理工具。 它的創建和構想是為了實現 DevOps 實踐“基礎設施即程式碼”，這意味著描述系統的不同狀態，從作業系統設定到應用程式軟體。 此描述分為多個層，可讓您管理複雜的、不斷變化的配置。 但工程師經常使用 Ansible 作為在多台機器上執行 bash 腳本的方式。 這既不是壞事，也不是好事，但你需要明白，Ansible 的存在並不能保證公司中 DevOps 的存在。
我們正在這個過程中 您將沉浸在開發類似著名 Reddit 的應用程式的過程中，從單體版本開始，逐步轉向微服務。 我們將逐步掌握新工具：Git、Ansible、Gitlab，最後掌握 Kubernetes 和 Prometheus。
在實踐方面，我們會遵循《DevOps手冊》中描述的三個路徑的策略——持續交付實踐、回饋實踐，整個課程的本質是隨著你的系統不斷學習的實踐。
這些知識為每位專家帶來了什麼？
對於系統管理員
實踐將使您擺脫管理，轉向創建持續交付管道和軟體交付基礎設施平台。 關鍵是他創建了一個產品——一個為開發人員提供的基礎設施平台，幫助他們快速將變更推向生產。
以前，系統管理員是最後的堡壘，之後一切都投入生產。 基本上，他們一直在忙於救火 - 有鑑於此，深入研究業務需求、思考產品和用戶的利益是相當困難的。
感謝 DevOps 方法，思維改變了。 系統管理員了解如何將組態轉換為程式碼，以及這方面有哪些實務。
這很重要，因為公司越來越意識到他們不僅僅需要自動化一切，即老式系統管理員基本上習慣於這樣做，而且他們很少溝通，也沒有告知團隊所做的所有更改。 現在，團隊正在尋找那些將成為內部基礎設施產品製造商並幫助將分離的流程整合為一個流程的人。
開發者
開發人員不再只考慮演算法。 他獲得了使用基礎設施的技能，以及建築景觀意識的技能。 這樣的開發人員了解應用程式如何運作、如何透過持續交付管道、如何監控它、如何註冊它以便使客戶受益。 因此，所有這些知識都可以讓您編寫相關程式碼。
對於測試人員
測試早已進入自動模式；我們都說很多測試不應該做，而應該寫:)測試成為產品整個交付管道的一部分。 測試人員不僅需要學習如何編寫程式碼，還要了解如何將其整合到持續交付系統中，如何在交付的各個階段接收程式碼的回饋，以及如何不斷改進測試以發現錯誤儘早。
事實證明 所有三個階段同時發生。 例如，它可能看起來像這樣：
開發人員編寫程式碼，立即為其編寫測試，並為應運行的程式碼描述一個 docker 容器。 它還立即描述了將監視該服務在生產中的操作的監視，並提交所有這些。
當持續整合開始時，流程同時運作。 服務啟動並配置。 同時，docker容器啟動並檢查是否正在運行。 同時，所有資訊都會進入日誌系統。 在開發的每個階段都是如此——事實證明這是系統管理員、開發人員和測試人員的真正團隊合作。
我學習了 DevOps，下一步該做什麼？
如你所知，在戰場上的人並不是戰士。 如果你的公司不採用這種方法，那麼獲得的技能就會閒置。 在熟悉 DevOps 方法後，您很可能不想成為企業發展的齒輪。 可能有一個例外：您是團隊中的系統管理員，可以以新的方式重建所有流程。 這裡值得補充的是，有很多公司使用這種方法，而且他們沒有受到封鎖的影響，並且正在尋找專家。 因為 DevOps 是關於創建線上產品。
現在說說好東西：掌握 DevOps 實踐和工具可以使您在勞動力市場上的價值增加約 30%。 薪水從 140 萬盧布起，但自然取決於您的主要專業和功能。
您可以查看標記為「面向基礎設施」的職缺，其中包括測試自動化、使用雲端技術開發微服務應用程式、基礎設施工程師的職缺以及有關 DevOps 的各種參考。 請記住，每個公司的定義都有不同的含義 - 請仔細閱讀說明。
在我們課程推出的過程中，我得到了一個洞見——很多人在課程結束後都陷入了 DevOps 工程師的陷阱。 他們找到了一個具有上述頭銜的空缺，收到了一個不錯的報價，然後開始工作，並意識到他們必須在 Jenkins 中維護一個三頁的 bash 腳本。 Kubernetes、ChatOps、金絲雀版本等等都在哪裡？ 但也沒什麼，因為公司不需要DevOps作為方法論，而是採用個人創新。
這是從公司深入了解軟體交付流程如何運作、技術堆疊以及您將履行哪些職責的原因。
如果雇主抽像地回答你的問題，就像從書本上一樣，沒有細節，那麼公司很可能還沒有DevOps流程，但這不是拒絕的理由，研究公司及其產品，是否有在線公司自行開發的服務、行動應用程式、產品理念。
如果是，請澄清您是否必須直接使用這些系統，或者是否有可能橫向移動到這些服務團隊，同時在 DevOps 實踐中展示良好的結果。 如果是的話，那麼就值得去，並且保持活躍和有用，如果您完成我們的課程，後者是有保證的。
值得注意的是，DevOps 從業者只有擁有開發/管理/測試經驗才能獲得真正的價值。 只有這樣，知識才不再是抽象的，而是豐富了專家的知識（在任何意義上）。 因此，如果你從未拿過相機或導演過拍攝，「從頭開始學習 DevOps」的想法與「從頭開始使用鏡頭」的想法大致相同。 為了幫助您確定課程是否適合您，我們進行了入學測試，以檢查您的知識水平是否足夠。
我認為技巧之一 ——在訓練過程中，每個學生都自己決定想要發展的方向。 當開發人員成為基礎設施工程師，管理員意識到他對編寫程式碼感興趣時，我們經常會看到這種轉變 - 然後他進一步研究該語言並用獲得的 DevOps 技能對其進行補充。 因此，我們特別歡迎那些覺得自己的職業生涯陷入十字路口的人。 課程於 28 月 2 日開始，但您可以在課程開始後 XNUMX 週加入。 您可以查看程式並參加測試 。 OTUS見！
來源： www.habr.com