近日，這類廣告充斥網路。 儘管薪資待遇不錯，但裡面寫滿了異端邪說，不禁讓人感到尷尬。 首先，假設「DevOps」和「工程師」可以以某種方式黏在一起成為一個詞，然後有一個隨機的需求列表，其中一些顯然是從系統管理員職位空缺中複製的。
在這篇文章中，我想談談我們是如何走到這一步的、DevOps 到底是什麼以及現在該怎麼辦。
這種空缺可以用各種可能的方式來譴責，但事實是：這樣的空缺很多，這就是目前市場的運作方式。 我們召開了 DevOps 大會並公開宣稱：「 - 不適用於 DevOps 工程師。” 這對很多人來說似乎很奇怪和瘋狂：為什麼那些做完全商業活動的人會逆市而行。 現在我們將解釋一切。
關於文化和流程
首先，DevOps 不是一門工程學科。 這一切都始於歷史上建立的角色分工不利於產品品質。 當程式設計師只進行編程，而不想聽到任何有關測試的資訊時，軟體就會充滿錯誤。 當管理員不關心軟體的編寫方式或原因時，支援就會變成地獄。
例如，描述系統管理員和 SRE 服務管理方法之間的區別 。 有趣的研究已經在 - 很明顯，最好的開發人員以某種方式設法以比每小時一次更快的速度將新變更部署到生產中。 他們用手測試不超過10%（這一點可以從 ）。 他們如何做到這一點？ 報告標題之一寫道：「要嘛成功，要嘛死亡」。 有關測試背景下這些統計數據的詳細討論，可以參考 Baruch Sadogursky 的主題演講 在我們的另一次會議 Heisenbug 上。
「當同誌之間沒有達成一致意見時，
他們的日子不會好過
這樣做不會有任何結果，只有折磨。
從前有一隻天鵝、一隻小龍蝦和一條梭子魚…”
您認為 Web 程式設計師中哪一部分真正了解他們的應用程式在生產中使用的條件？ 他們中有多少人會去找管理員並嘗試弄清楚如果資料庫崩潰會發生什麼？ 而他們中的哪一個會去找測試人員並請他們教他們如何正確寫測驗？ 還有保安，產品經理，還有其他一堆人。
DevOps的整體想法是創造角色和部門之間的協作。 首先，這不是透過一些巧妙配置的軟體來實現的，而是透過溝通的實踐來實現的。 DevOps 涉及文化、實踐、方法論和流程。 沒有任何工程專業可以回答這些問題。
惡性循環
「devops 工程」這門學科從何而來？ 我們有一個版本！ DevOps 想法很好——太好了，以至於他們成為了自己成功的受害者。 一些陰暗的招募者和人販子，他們有自己的氛圍，開始圍繞這整個話題打轉。
想像一下：昨天你在希姆基製作沙瓦瑪，今天你已經是一個大人物，一名高級招募人員。 尋找和選擇候選人有一個完整的過程，一切都不容易，你需要理解。 假設某部門的負責人說：找一位 X 方面的專家。我們將「工程師」一詞分配給 X，然後就完成了。 需要Linux嗎？ 嗯，這絕對是一名 Linux 工程師，如果你想要 DevOps，那就是一名 DevOps 工程師。 空缺不僅包含標題，還必須在裡面輸入一些文字。 最簡單的方法是輸入一組來自Google的關鍵字，這取決於您的想像。 DevOps 由兩個字組成——“Dev”和“Ops”，這意味著我們需要將與開發人員和管理員相關的關鍵字黏在一起，全部黏在一起。 精通 42 種程式語言、同時使用 Kubernetes 和 Swarm 20 年的職缺就這樣出現了。 工作圖。
某個「devops」超級英雄的無意義、無情的形象就這樣在人們心中紮根，他將配置所有人部署到Jenkins上，幸福就會到來。 哦，如果一切都這麼簡單就好了。 “這也是你追捕系統管理員的方法，”HR 認為，“這是一個時髦的詞，關鍵字都一樣，他們應該上鉤。”
需求創造供應，所有這些垃圾空缺都被大量的系統管理員填補，他們意識到：你可以像以前一樣做所有事情，但通過稱自己為“devops”可以得到數倍的好處。 正如您一次透過 SSH 手動設定伺服器一樣，您將繼續配置它們，但現在這應該是一種 DevOps 實踐。 這是某種複雜的現象，部分與對經典管理員的低估和圍繞 DevOps 的炒作有關，但總的來說，發生的事情就發生了。
所以我們有供給和需求。 惡性循環，自食其力。 這就是我們正在反對的（包括透過創建 DevOops 會議）。
當然，除了自稱為「devops」的系統管理員之外，還有其他參與者——例如專業的 SRE 或基礎設施即程式碼開發人員。
人們在 DevOps 中做什麼（真的）
因此，您希望在學習和應用 DevOps 實踐方面取得進步。 但如何做到這一點，朝哪個方向看呢？ 顯然，你不應該盲目依賴流行關鍵字。
如果有工作，就應該有人去做。 我們已經發現他們不是“devops工程師”，那麼誰是呢？ 似乎不是從職位的角度來表達這一點，而是從具體工作領域的角度來表達更為正確。
首先，您可以解決 DevOps 的核心—流程和文化。 文化是一項緩慢而艱難的事業，儘管傳統上它是管理者的責任，但從程式設計師到管理員，每個人都以這樣或那樣的方式參與其中。 幾個月前 提姆‧利斯特 :
「文化是由組織的核心價值決定的。 通常人們不會注意到這一點，但在諮詢行業工作了多年，我們已經習慣了注意到這一點。 你進入一家公司，幾分鐘之內你就會開始感受到正在發生的事情。 我們稱之為「風味」。 有時候這種味道真的很好聞。 有時會引起噁心。 (...) 在具體行動背後的價值觀和信念被理解之前，你無法改變一種文化。 行為很容易觀察，但尋找信念卻很困難。 DevOps 只是一個很好的例子，說明事情是如何變得越來越複雜的。”
當然，這個問題還有一個技術部分。 如果您的新程式碼在一個月內測試，但僅在一年後發布，並且實際上不可能加快全部速度，那麼您可能無法實現良好的實踐。 好的實踐需要好的工具來支持。 例如，考慮到基礎架構即程式碼的概念，您可以使用從 AWS CloudFormation 和 Terraform 到 Chef-Ansible-Puppet 的任何內容。 你需要知道並且能夠做到這一切，這已經是一門工程學科了。 重要的是不要混淆因果關係：首先根據 SRE 的原則進行工作，然後才能以一些具體的技術解決方案的形式實施這些原則。 同時，SRE是一個非常全面的方法論，它不會告訴你如何設定Jenkins，而是告訴你五個基本原則：
- 改善角色和部門之間的溝通
- 接受錯誤作為工作的一個組成部分
- 逐漸做出改變
- 使用工具和其他自動化
- 測量所有可以測量的東西
這不僅僅是一些陳述，而是一個具體的 。 例如，在接受錯誤的過程中，您需要了解風險，使用 SLI 等工具來衡量服務的可用性和不可用性（) 和 SLO (），學會寫事後分析，讓寫起來不再可怕。
在 SRE 學科中，工具的使用雖然很重要，但只是成功的一部分。 我們需要不斷地發展技術，看看世界上正在發生什麼，以及如何將其應用到我們的工作中。
反過來，雲端原生解決方案現在變得非常流行。 根據雲端原生運算基金會今天的定義，雲端原生技術使組織能夠在當今的動態環境（例如公有雲、私有雲和混合雲）中開發和運行可擴展的應用程式。 範例包括容器、服務網格、微服務、不可變基礎架構和聲明性 API。 所有這些技術都允許鬆散耦合的系統保持彈性、可管理和高度可觀察。 良好的自動化使工程師能夠頻繁地進行重大更改並獲得可預測的結果，而不會使其成為一件苦差事。 所有這一切都得到了 Docker 和 Kubernetes 等一系列知名工具的支援。
這個相當複雜且廣泛的定義是因為該領域也相當複雜。 一方面，有人認為應該非常簡單地對該系統添加新的更改。 另一方面，要弄清楚如何創建一種容器化環境，其中鬆散耦合的服務存在於軟體定義的基礎設施上，並使用持續的CI/CD 進行交付，並圍繞所有這些構建DevOps 實踐- 所有這些都需要更多勝過吃狗。
面對這一切該怎麼辦
每個人都用自己的方式解決這些問題：例如，您可以發布正常的職缺來打破惡性循環。 您可以弄清楚 DevOps 和 Cloud Native 等字詞的含義，並正確、切題地使用它們。 您可以在 DevOps 中進行開發，並透過範例示範正確的方法。
我們正在開一個會議 ，這提供了一個深入研究我們剛才談到的事情的機會。 為此有幾組報告：
- 流程和文化；
- 現場可靠度工程；
- 雲原生；
如何選擇去哪裡？ 這裡有一個微妙的點。 一方面，DevOps 是關於互動的，我們真的希望您參加來自不同領域的演示。 另一方面，如果您是開發經理，參加會議是為了專注於一項特定任務，那麼沒有人會限制您 - 顯然，這將是一個關於流程和文化的障礙。 不要忘記，您將在會議結束後（填寫回饋表後）獲得錄音，以便您可以隨時觀看不太重要的演示。
顯然，在會議本身上，你不能同時進行三個軌道，因此我們以這樣的方式組織節目，每個時段都有適合各種口味的主題。
剩下的就是了解如果您是 DevOps 工程師該怎麼做！ 首先，嘗試確定您實際上在做什麼。 通常他們喜歡這樣稱呼這個詞：
- 從事基礎設施工作的開發人員。 有關 SRE 和雲端原生的報告組最適合您。
- 系統管理員。 這裡更複雜。 DevOops 與系統管理無關。 幸運的是，網路上有很多關於系統管理主題的優秀會議、書籍、文章、影片等。 另一方面，如果您有興趣在了解文化和流程、了解雲端技術以及雲端原生生活細節方面發展自己，那麼我們很高興見到您！ 大家想一想，你是做行政的，那你做什麼？ 為了避免突然發現自己陷入不愉快的境地，你應該現在就學習。
還有另一個選擇：你堅持並繼續聲稱你是 特別是 DevOps 工程師 沒有別的，無論這意味著什麼。 那我們就得讓你失望了，DevOops 不是 DevOps 工程師的會議！
幻燈片自 在慕尼黑
DevOops 2020 莫斯科將於 29 月 30-XNUMX 日在莫斯科舉行，門票已開始發售 .
或者，您可以 直到8月XNUMX日。 請注意，填寫表格時，您必須選擇將從您的報告中受益最多的目標受眾（清單裡藏著一個驚喜).
來源： www.habr.com