在過去的幾年裡，DevOps 已經成為一個非常流行的話題。 許多人夢想加入其中，但實踐表明，往往只是因為工資水平。
有些人在簡歷中列出了 DevOps，儘管他們並不總是知道或理解這個術語的本質。 有人認為，學習了 Ansible、GitLab、Jenkins、Terraform 之類的東西（這個清單可以根據你的口味繼續），你會立即成為「devopsist」。 當然，這不是真的。
過去幾年，我主要參與各家公司DevOps的實施。 在此之前，他在從系統管理員到 IT 總監等職位上工作了 20 多年。 目前是 Playgendary 的 DevOps 首席工程師。
誰是 DevOps
寫一篇文章的想法是在另一個問題之後產生的：“誰是 DevOps？” 對於它是什麼或是誰，仍然沒有既定的術語。 有些答案已經在這個了 。 首先我會強調其中的重點，然後我會分享我的觀察和想法。
DevOps 不是一個可以被雇用的專家，不是一組公用事業，也不是一個由工程師組成的開發部門。
DevOps 是一種哲學和方法論。
換句話說，它是一組幫助開發人員主動與系統管理員互動的實踐。 也就是說，將工作流程相互連接並整合。
隨著 DevOps 的出現，專家的結構和角色保持不變（有開發人員，有工程師），但互動規則改變了。 部門之間的界線已經模糊。
DevOps 的目標可以用三點來描述：
- 軟體必須定期更新。
- 軟體必須快速完成。
- 軟體的部署應該方便、時間短。
DevOps 沒有單一的工具。 配置、交付和研究幾個產品並不意味著DevOps已經在公司出現。 工具有很多，它們都在不同的階段使用，但都有一個共同的目的。
這只是 DevOps 工具的一部分
我面試 DevOps 工程師職位的人已經有兩年多了，我開始意識到清楚地理解這個術語的本質是多麼重要。 我累積了一些我想分享的具體經驗、觀察和想法。
根據面試經驗，我看到如下圖： 將 DevOps 視為職位名稱的專家通常與同事有誤解.
有一個引人注目的例子。 一位年輕人來面試，他的履歷上寫著很多聰明的話。 在他的前三份工作中，他有 5 至 6 個月的工作經驗。 我離開了兩家新創公司，因為它們「沒有起飛」。 但談到第三家公司，他說那裡沒有人理解他：開發人員在 Windows 上編寫程式碼，總監強制將這些程式碼「包裝」在常規 Docker 中並建置到 CI/CD 管道中。 那傢伙說了很多關於他目前的工作地點和同事的負面言論——我只想回答：“所以你不會賣大象。”
然後我問了他一個問題，這個問題在我的每個候選人的清單中都排在前列。
— DevOps 對您個人來說意味著什麼？
- 一般而言或我如何看待它？
我對他的個人意見很感興趣。 他知道這個術語的理論和起源，但他強烈不同意它們。 他認為 DevOps 是一個職位名稱。 這就是他問題的根源。 以及其他持相同觀點的專家。
雇主們聽過很多「DevOps 的魔力」之後，希望找到一個能創造這種「魔力」的人。 來自「DevOps 是一份工作」類別的申請人不明白，透過這種方法，他們將無法滿足期望。 而且，總的來說，他們在簡歷中寫下了 DevOps，因為這是一種趨勢，而且他們為此付出了很多。
DevOps 方法論與理念
這個方法可以是理論的和實踐的。 在我們的例子中，這是第二個。 正如我上面提到的，DevOps 是一組用於實現既定目標的實踐和策略。 在每種情況下，根據公司的業務流程，可能會大不相同。 這並不會讓事情變得更好或更糟。
DevOps 方法只是實現目標的一種手段。
現在談談 DevOps 理念是什麼。 這可能是最困難的問題。
制定一個簡短而簡潔的答案相當困難，因為它尚未正式化。 由於 DevOps 哲學的追隨者更多地參與實踐，因此根本沒有時間進行哲學思考。 然而，這是一個非常重要的過程。 而且，它與工程活動直接相關。 甚至還有一個專門的知識領域—— .
我的大學裡沒有這樣的科目，我必須利用90年代能找到的材料自學一切。 這個主題對於工程教育來說是可選的，因此缺乏正式的答案。 但那些認真投入 DevOps 的人開始感受到公司所有流程的某種「精神」或「無意識的全面性」。
根據我自己的經驗，我試著將這哲學的一些「假設」形式化。 結果如下：
- DevOps 並不是獨立的東西，可以分成單獨的知識或活動領域。
- 所有公司員工在規劃其活動時都應遵循 DevOps 方法。
- DevOps 影響公司內的所有流程。
- DevOps 的存在是為了減少公司內任何流程的時間成本，以確保其服務的開發和最大程度的客戶舒適度。
- DevOps，用現代語言來說，是公司每位員工的主動立場，旨在降低時間成本並提高我們周圍IT產品的品質。
我認為我的“假設”是一個單獨的討論主題。 但現在有一些東西可以繼續發展。
DevOps 做什麼
這裡的關鍵字是溝通。 有很多溝通，發起人應該是同一個 DevOps 工程師。 這是為什麼？ 因為這是哲學和方法論，然後才是工程知識。
我不能對西方勞動市場有 100% 的信心。 但我對俄羅斯的 DevOps 市場了解很多。 除了數百次訪談之外，在過去的一年半時間裡，我還參與了數百次為俄羅斯大公司和銀行提供的「DevOps 實施」服務的技術預售。
在俄羅斯，DevOps 仍然是一個非常年輕的話題，但已經成為熱門話題。 據我了解，2019年僅莫斯科一地此類專家的缺口就超過1000人。 Kubernetes 這個字對雇主來說幾乎就像紅布對公牛一樣。 即使在沒有必要且經濟上有利可圖的情況下，該工具的追隨者也準備好使用它。 雇主並不總是了解在什麼情況下使用什麼更合適，並且透過正確的部署，維護 Kubernetes 叢集的成本比使用傳統叢集方案部署應用程式高 2-3 倍。 在您真正需要的地方使用它。
實施 DevOps 的資金成本很高。 而且只有當它在其他領域帶來經濟利益時才是合理的，而不是本身。
事實上，DevOps 工程師是先驅——他們應該是第一個在公司中實施這種方法並建立流程的人。 為了取得成功，專家必須不斷與各級員工和同事互動。 正如我通常所說，所有公司員工都應該參與 DevOps 實施過程：從清潔女工到執行長。 這是一個先決條件。 如果團隊中資歷最淺的成員不知道和理解 DevOps 是什麼以及為什麼要執行某些組織操作，那麼成功的實施就行不通。
此外，DevOps 工程師需要不時使用管理資源。 例如，克服「環境阻力」——當團隊尚未準備好接受 DevOps 工具和方法時。
開發人員應該只編寫程式碼和測試。 為此，他不需要一台功能強大的筆記型電腦來部署和本地支援整個專案基礎設施。 例如，前端開發人員將應用程式的所有元素保存在他的筆記型電腦上，包括資料庫、S3 模擬器（minio）等。 也就是說，他花了大量的時間來維護這個本地基礎設施，並獨自努力解決這種解決方案的所有問題。 而不是為前端開發程式碼。 這些人可能非常抗拒任何改變。
但有些團隊卻相反，樂於引入新的工具和方法，並積極參與這個過程。 儘管即使在這種情況下，DevOps 工程師和團隊之間的溝通也沒有取消。
當不需要 DevOps 時
在某些情況下，不需要 DevOps。 這是事實──需要理解和接受。
首先，這適用於任何公司（尤其是小型企業），它們的利潤並不直接取決於是否有向客戶提供資訊服務的IT產品。 這裡我們談論的不是公司的網站，無論是靜態的「名片」還是動態的新聞區塊等。
當您的客戶的滿意度以及他再次回到您身邊的願望取決於這些用於與客戶互動的資訊服務的可用性、其品質和目標時，就需要 DevOps。
一個顯著的例子是一家知名銀行。 該公司沒有通常的客戶辦公室，文件流轉透過郵件或快遞進行，許多員工在家工作。 在我看來，該公司不再只是一家銀行，而是一家擁有成熟 DevOps 技術的 IT 公司。
在專題聚會和會議的錄音中可以找到許多其他範例和講座。 我親自拜訪了他們中的一些人——這對那些想朝這個方向發展的人來說是非常有用的經驗。 以下是 YouTube 頻道的鏈接，其中包含有關 DevOps 的精彩講座和材料：
現在看看您的業務並思考一下：您的公司及其利潤在多大程度上依賴 IT 產品來實現客戶互動？
如果你的公司在小商店裡賣魚，唯一的IT產品是兩個1C：企業配置（會計和UNF），那麼談論DevOps幾乎沒有意義。
如果你在一家大型貿易和製造企業工作（例如，你生產獵槍），那麼你應該考慮一下。 您可以主動向管理階層傳達實施 DevOps 的前景。 好吧，同時，領導這個過程。 積極主動是 DevOps 理念的重要原則之一。
每年財務週轉的規模和數量並不是決定你的公司是否需要DevOps的主要標準。
讓我們想像一個不直接與客戶互動的大型工業企業。 例如，一些汽車製造商和汽車製造公司。 我現在不確定，但根據我過去的經驗，多年來所有客戶互動都是透過電子郵件和電話完成的。
他們的客戶是有限的汽車經銷商。 每一位產品都配備了製造商的一位專家。 所有內部文件流程均透過 SAP ERP 進行。 內部員工本質上是資訊系統的客戶。 但這個 IS 是透過管理集群系統的經典方法來控制的。 這就排除了使用 DevOps 來實踐的可能性。
因此得出的結論是：對於這類企業來說，如果我們回想本文開頭的方法論目標，那麼實施 DevOps 並不是至關重要的事情。 但我不排除他們現在使用一些 DevOps 工具。
另一方面，有許多小公司使用 DevOps 方法、理念、實踐和工具來開發軟體。 而他們認為，實施DevOps的成本就是讓他們在軟體市場上有效競爭的成本。 此類公司的例子可見 .
了解是否需要DevOps的主要標準是：你的IT產品對公司和客戶有什麼價值。
如果公司產生利潤的主要產品是軟體，那麼就需要DevOps。 如果您使用其他產品賺取真金白銀，那麼這並不那麼重要。 這也包括在線商店或帶有遊戲的行動應用程式。
任何遊戲的存在都要歸功於資金：直接或間接來自玩家。 在 Playgendary，我們開發免費手機遊戲，有超過 200 人直接參與創作。 我們如何使用 DevOps？
是的，與上面描述的完全一樣。 我不斷與開發人員和測試人員溝通，對員工進行 DevOps 方法和工具的內部培訓。
我們現在積極使用 Jenkins 作為 CI/CD 管道工具，透過 Unity 執行所有組裝管道，並隨後部署到 App Store 和 Play Market。 經典工具包的更多內容：
- Asana - 用於專案管理。 與 Jenkins 的整合已配置。
- Google Meet - 用於視訊會議。
- Slack - 用於通訊和各種警報，包括來自 Jenkins 的通知。
- Atlassian Confluence - 用於文件和小組工作。
我們的近期計劃包括使用 SonarQube 引入靜態程式碼分析，並在持續整合階段使用 Selenium 進行自動化 UI 測試。
取而代之的是結論
最後我想說的是：要成為一名高素質的 DevOps 工程師，學會如何與人進行現場溝通至關重要。
DevOps 工程師是團隊合作者。 沒有別的。 與同事溝通的主動權應該來自於他，而不是某些環境的影響。 DevOps 專家必須為團隊查看並提出最佳解決方案。
是的，任何解決方案的實施都需要大量的討論，到最後它可能會完全改變。 這樣的人能夠獨立發展、提出並實施自己的想法，對團隊和雇主來說都具有越來越大的價值。 最終，這反映在他每月的薪資金額或額外獎金的形式中。
來源： www.habr.com