主持人 > 博客 > 管理 > DevOps 是誰？

DevOps 是誰？

目前，這幾乎是市場上最昂貴的位置。 圍繞著「DevOps」工程師的爭論超出了所有想像的極限，對於高級 DevOps 工程師來說更糟。
我擔任整合和自動化部門的負責人，猜英文解碼——DevOps Manager。 英文記錄不太可能反映我們的日常活動，但在這種情況下，俄語版本更準確。 由於我的活動性質，我自然需要採訪我團隊的未來成員，在過去的一年裡，大約有50 個人通過了我的採訪，而同樣數量的人在與我的員工的預篩選中被剪掉了。

我們仍在尋找同事，因為在 DevOps 標籤的背後隱藏著一大堆不同類型的工程師。

下面寫的一切都是我個人的觀點，你不必同意它，但我承認它會為你對這個主題的態度增添一些色彩。 儘管有失寵的風險，我還是發表了我的觀點，因為我相信它有一席之地。

公司對 DevOps 工程師的理解不同，為了快速招募資源，他們給每個人貼上了這個標籤。 這種情況很奇怪，因為公司準備向這些人支付不切實際的報酬，在大多數情況下，為他們提供工具管理員。

那麼 DevOps 工程師是誰呢？

讓我們從它出現的歷史開始 - 開發營運的出現是優化小團隊互動以提高產品生產速度的又一步，這是預期的結果。 這個想法是透過管理產品環境的程序和方法的知識來加強開發團隊。 換句話說，開發人員必須了解並知道他的產品在某些條件下如何運作，必須了解如何部署他的產品，可以調整環境的哪些特徵來提高效能。 因此，一段時間以來，出現了採用 DevOps 方法的開發人員。 DevOps 開發人員編寫建置和打包腳本來簡化他們的活動和生產環境的效能。 然而，隨著時間的推移，解決方案架構的複雜性和基礎設施組件的相互影響開始惡化環境的性能；隨著每次迭代，需要對某些組件有越來越深入的了解，從而降低了開發人員的生產力，因為額外的了解特定任務的組件和調整系統的成本。 開發人員自身成本增長，產品成本也隨之增長，對團隊中新開發人員的要求急劇上升，因為他們還需要承擔開發“明星”的職責，自然“明星”就少了並且可用的較少。 另外值得注意的是，根據我的經驗，很少有開發人員對作業系統核心的封包處理細節、封包路由規則和主機安全性方面感興趣。 合乎邏輯的步驟是吸引一位熟悉這一點的管理員，並為他分配類似的職責，由於他的經驗，與“明星”開發的成本相比，這使得以更低的成本實現相同的指標成為可能。 這些管理員被安排在一個團隊中，他的主要任務是根據特定團隊的規則來管理測試和生產環境，並將資源分配給該特定團隊。 事實上，DevOps 就是這樣出現在大多數人的腦海中的。

隨著時間的推移，這些系統管理員部分或完全地開始了解這個特定團隊在開發領域的需求，如何讓開發人員和測試人員的生活變得更輕鬆，如何推出更新而不必在周五過夜辦公室，修正部署錯誤。 隨著時間的推移，現在的「明星」是了解開發人員想要什麼的系統管理員。 為了最大程度地減少影響，管理實用程式開始出現；每個人都記住了隔離作業系統層級的古老而可靠的方法，這使得可以最大限度地減少對安全性、網路部分管理和主機配置的要求。整體，從而減少對新“明星”的要求。

一個「奇妙」的東西出現了－docker。 為什麼精彩？ 是的，只是因為在chroot 或監獄以及OpenVZ 中創建隔離需要對作業系統有一定的了解，相反，該實用程式允許您在某個主機上簡單地創建一個隔離的應用程式環境，其中包含所有必要的內部和手動內容再次掌控開發，系統管理員只需管理一台主機，確保其安全性和高可用性——邏輯上的簡化。 但進步不會停滯不前，系統又變得越來越複雜，組件越來越多，一台主機已經無法滿足系統的需求，需要建構集群，我們又回到了系統管理員的身上。能夠建構這些系統。

一個又一個週期，各種簡化開發和/或管理的系統出現，編排系統出現，直到您需要偏離標準流程為止，這些系統都很容易使用。 微服務架構的出現也是為了簡化上述一切──更少的關係，更容易管理。 根據我的經驗，我沒有找到一個完全的微服務架構，我想說50% 到50% - 50% 的微服務、黑盒子，進來，出來經過處理，其他50 個是破碎的整體，服務無法與其他服務分開工作成分。 所有這些再次對開發人員和管理員的知識水平施加了限制。

特定資源的專家知識水平的類似「波動」至今仍在繼續。 但我們有點離題了，有很多重點值得強調。

建置工程師/發布工程師

非常專業的工程師，他們的出現是標準化軟體建置流程和發布的一種手段。 在廣泛引入敏捷的過程中，似乎不再需要它們，但事實並非如此。 這種專業化是作為工業規模上標準化軟體組裝和交付的一種手段而出現的，即對所有公司產品使用標準技術。 隨著DevOps 的出現，開發人員部分失去了他們的功能，因為是開發人員開始準備產品交付，並且考慮到不斷變化的基礎設施和不考慮質量的盡快交付的方法，隨著時間的推移，他們改變成了變革的阻礙，因為遵守品質標準不可避免地會減慢交付速度。 因此，逐漸地，建置/發布工程師的部分功能轉移到了系統管理員的肩上。

操作是如此不同

我們一次又一次地前進，職責範圍廣泛，合格人員的缺乏迫使我們走向嚴格的專業化，就像雨後的蘑菇一樣，出現了各種操作：

  • TechOps - enikey 系統管理員又稱服務台工程師
  • LiveOps - 主要負責生產環境的系統管理員
  • CloudOps - 專門從事公有雲 Azure、AWS、GCP 等的系統管理員。
  • PlatOps/InfraOps/SysOps - 基礎設施系統管理員。
  • NetOps - 網路管理員
  • SecOps - 專門從事資訊安全的系統管理員 - PCI 合規性、CIS 合規性、修補等。

DevOps（理論上）是一個直接了解開發週期所有流程（開發、測試）的人，了解產品架構，能夠評估安全風險，熟悉方法和自動化工具，至少在較高水平上級別，除此之外，還了解前處理和後處理、產品發布支援。 一個能夠充當營運和開發倡導者的人，這使得這兩個支柱之間能夠進行良好的合作。 了解團隊規劃工作和管理客戶期望的流程。

為了執行此類工作和職責，此人必須不僅有能力管理開發和測試流程，還必須有能力管理產品基礎設施以及資源規劃。 這種理解下的DevOps既不能位於IT，也不能位於研發，甚至不能位於PMO；它必須在所有這些領域都有影響力──公司的技術總監、技術長。

你們公司也是這樣嗎？ - 我懷疑。 在大多數情況下，這要么是 IT，要么是研發。

缺乏資金和能力來影響這三個活動領域中的至少一個，將把問題的重心轉移到更容易應用這些變化的地方，例如根據靜態數據對與“臟”代碼相關的發布應用技術限制。分析儀系統。 即當PMO對功能的發布設定了嚴格的期限時，研發無法在這個期限內拿出高品質的結果，只能盡力而為，把重構留到以後，IT相關的DevOps透過技術手段阻止發布。 對於負責任的員工來說，缺乏改變情況的權力，會導致對他們無法影響的事情表現出過度責任，特別是如果這些員工了解並看到錯誤，以及如何糾正它們 - “幸福就是無知”，從而導致這些員工的倦怠和流失。

DevOps資源市場

讓我們看看不同公司的幾個 DevOps 職缺。

如果您符合以下條件，我們隨時準備與您會面：

  1. 您擁有 Zabbix 並且知道 Prometheus 是什麼；
  2. iptables；
  3. BASH 博士生；
  4. 安西布爾教授；
  5. Linux 大師；
  6. 懂得如何使用調試，與開發人員一起發現應用程式問題（php/java/python）；
  7. 路由不會讓你歇斯底里；
  8. 高度重視系統安全；
  9. 備份“一切”，並成功恢復“一切”；
  10. 您知道如何配置系統，以便從最小限度中獲得最大收益；
  11. 在Postgres和MySQL上設定睡前複製；
  12. 設定和調整 CI/CD 對您來說就像早餐/午餐/晚餐一樣必要。
  13. 有AWS經驗；
  14. 準備與公司共同發展；

所以：

  • 從 1 到 6 - 系統管理員
  • 7 - 一點網路管理，也適合系統管理員，中級
  • 8 - 一點安全性，這對於中級系統管理員來說是強制性的
  • 9-11 – 中階系統管理員
  • 12 — 根據指派的任務，中階系統管理員或建置工程師
  • 13 - 虛擬化 - 中間系統管理員，或所謂的 CloudOps，對特定託管網站服務的高階了解，以有效利用資金並減少維護負擔

總結這個職位空缺，我們可以說中/高級系統管理員對於這些人來說已經足夠了。

順便說一句，您不應該在 Linux/Windows 上強烈劃分管理員。 當然，我知道這兩個世界的服務和系統是不同的，但一切的基礎都是相同的，任何有自尊心的管理員都熟悉其中一個和另一個，即使他不熟悉，也會對於有能力的管理員來說熟悉它並不困難。

讓我們考慮另一個空缺：

  1. 具有建構高負載系統的經驗；
  2. 精通 Linux 作業系統、通用系統軟體和 Web 堆疊（Nginx、PHP/Python、HAProxy、MySQL/PostgreSQL、Memcached、Redis、RabbitMQ、ELK）；
  3. 具備虛擬化系統（KVM、VMWare、LXC/Docker）經驗；
  4. 熟練腳本語言；
  5. 了解網路協定網路的運作原理；
  6. 了解建構容錯系統的原理；
  7. 獨立性、主動性；

讓我們看看：

  • 1 – 高級系統管理員
  • 2 - 取決於該堆疊的含義 - 中/高級系統管理員
  • 3 - 工作經驗，包括，可能意味著 - “叢集沒有啟動，而是建立和管理虛擬機，有一台 Docker 主機，無法存取容器」 - 中級系統管理員
  • 4 - 初級系統管理員 - 是的，一個不知道如何編寫基本自動化腳本的管理員，無論使用哪種語言，而不是管理員 - enikey。
  • 5 - 中階系統管理員
  • 6 – 高級系統管理員

總結 - 中/高級系統管理員

另一個：

  1. 開發維運經驗；
  2. 具有使用一種或多種產品建立 CI/CD 流程的經驗。 Gitlab CI 將是一個優勢；
  3. 使用容器和虛擬化； 如果您使用 docker，那很好，但如果您使用 k8s，那就太好了！
  4. 有在敏捷團隊工作的經驗；
  5. 了解任何程式語言；

讓我們來看看：

  • 1 - 嗯...這些傢伙是什麼意思？ =) 很可能他們自己也不知道背後隱藏著什麼
  • 2 - 建造工程師
  • 3 - 中階系統管理員
  • 4 - 軟技能，我們暫時不考慮它，儘管敏捷是另一個以方便的方式解釋的東西。
  • 5 - 太冗長 - 它可能是一種腳本語言或編譯語言。 我想知道在學校用 Pascal 和 Basic 寫作是否適合他們？ =)

我還想就第3點留下註釋，以加強對為什麼系統管理員涵蓋這一點的理解。 Kubernetes 只是一個編排，一個工具，它將對網路驅動程式和虛擬化/隔離主機的直接命令包裝在幾個命令中，並允許您與它們進行抽象的通信，僅此而已。 例如，讓我們以「建構框架」Make 為例，順便說一句，我不考慮框架。 是的，我知道把 Make 推到任何地方的時尚，無論是必要的還是不需要的——例如，認真地將 Maven 包裝在 Make 中？
本質上，Make 只是 shell 的包裝，簡化了編譯、連結和編譯環境命令，就像 k8s 一樣。

有一次，我採訪了一個在OpenStack之上工作中使用k8s的人，他談到了他如何在上面部署服務，但是當我詢問OpenStack時，結果發現它是由系統管理的，也是由系統提出的管理員。 你真的認為一個安裝了OpenStack的人，無論他後面使用什麼平台，都不能使用k8s嗎？=）
這位申請人實際上並不是 DevOps 人員，而是系統管理員，更準確地說，是 Kubernetes 管理員。

讓我們再次總結一下——中/高級系統管理員對他們來說就足夠了。

重量是多少克

所示空缺職位的建議薪資範圍為 90k-200k
現在我想將系統管理員和 DevOps 工程師的金錢獎勵進行比較。

原則上，為了簡化事情，您可以根據工作經驗分散成績，雖然這並不準確，但對於本文的目的來說，這已經足夠了。

體驗：

  1. 最長 3 歲 – 初級
  2. 6 歲以下 – 中歲
  3. 超過 6 – 高級

員工搜尋網站提供：
系統管理員：

  1. 青少年 - 2 歲 - 50k 盧布。
  2. 中 - 5 年 - 70k 盧布。
  3. 高年級 - 11 歲 - 100k 盧布。

開發營運工程師：

  1. 青少年 - 2 歲 - 100k 盧布。
  2. 中 - 3 年 - 160k 盧布。
  3. 高年級 - 6 歲 - 220k 盧布。

根據「DevOps」的經驗，所使用的經驗至少在某種程度上影響了SDLC。

由此可見，其實公司並不需要DevOps，而且透過聘請Administrator可以節省至少50%的原計劃成本；而且可以更清晰地定義他們要找的人的職責並更快地滿足需求。 我們也不應該忘記，明確的職責分工可以減少對人員的要求，並在團隊中創造更有利的氛圍，因為沒有重疊。 絕大多數職缺都充滿了實用程式和DevOps標籤，但它們並不是基於對DevOps工程師的實際要求，而只是對工具管理員的要求。

培訓 DevOps 工程師的過程也僅限於一組特定的工作、實用程序，並且不提供對流程及其依賴關係的一般理解。 如果一個人可以在10 分鐘內使用Terraform 部署AWS EKS，並結合該叢集中的Fluentd sidecar 和用於日誌系統的AWS ELK 堆疊，僅使用控制台中的一個命令，這當然是件好事，但如果他不理解處理本身日誌的原則以及它們的用途，如果您不知道如何收集它們的指標並追蹤服務的退化，那麼知道如何使用某些實用程式的人仍然是同一個人。

然而，需求創造供給，我們看到 DevOps 職位的市場極度過熱，其中的要求與實際角色不符，而只是讓系統管理員賺取更多收入。

那麼他們是誰呢？ DevOps 還是貪婪的系統管理員？ =)

如何繼續生活？

雇主應該更精準地制定要求，準確地尋找需要的人，而不是亂貼標籤。 您不知道 DevOps 做什麼 - 在這種情況下您不需要它們。

工人——學習。 不斷提高您的知識，縱觀整個流程並追蹤實現目標的路徑。 你可以成為任何你想成為的人，你只需要嘗試。

來源： www.habr.com

添加評論