IT公司如何在2019年取得成功？ 會議和聚會上的講師說了很多普通人並不總是能理解的大聲話語。 部署時間、微服務、放棄單體、DevOps 轉型等的鬥爭。 如果我們放棄華麗的語言，直接用俄語說話，那麼一切都可以歸結為一個簡單的論點：製造高品質的產品，並讓團隊感到舒適。
後者已變得至關重要。 商業界終於得出這樣的結論：舒適的開發流程可以提高生產力，如果一切都調試好並且像時鐘一樣工作，那麼在關鍵情況下也可以提供一些迴旋餘地。 曾幾何時，為了這種策略，某個聰明的人想出了備份，但行業正在發展，我們找到了 DevOps 工程師 - 他們將開發和外部基礎設施之間的交互過程轉變為充分且可靠的東西。與薩滿教無關。
整個「模組化」故事很精彩，但是…碰巧的是，一些管理員突然被稱為 DevOps，而 DevOps 工程師本身開始被要求至少具備心靈感應和千里眼的技能。
在我們討論提供基礎設施的現代問題之前，讓我們先定義一下這個術語的含義。 目前，情況的發展使我們達到了這個概念的二元性：基礎設施可以是有條件的外部的，也可以是有條件的內部的。
透過外部基礎設施，我們指的是確保團隊正在開發的服務或產品功能的一切。 這些是應用程式或網站伺服器、託管和其他確保產品功能的服務。
內部基礎設施包括開發團隊本身和其他員工（通常有很多）使用的服務和設備。 這些是代碼儲存系統的內部伺服器、本地部署的任務管理器以及企業內部網路中存在的一切、一切、一切。
系統管理員在公司做什麼？ 除了管理企業內部網路的工作之外，它還常常承擔著經濟問題的負擔，以確保辦公設備的可操作性。 管理員是同一個人，他會迅速從後面的房間拖出一個新的系統單元或一台準備使用的備用筆記型電腦，拿出一個新的鍵盤，然後四肢著地爬過辦公室，拉伸以太網電纜。 管理員不僅是內部和外部伺服器的本地所有者和統治者，而且還是業務主管。 是的，有些管理員只能在系統平面工作，沒有硬體。 他們應該被分成「基礎設施系統管理員」的單獨子類。 有些專門維修辦公設備；幸運的是，如果公司有一百多人，工作就永遠不會結束。 但他們都不是 DevOps。
DevOps 是誰？ DevOps 是談論軟體開發與外部基礎設施互動的人。 更準確地說，現代 DevOps 參與開發和部署過程的程度比簡單地將更新上傳到 ftp 的管理員參與的程度要深得多。 現在，DevOps 工程師的關鍵任務之一是確保開發團隊和產品基礎架構之間有舒適且有效的結構化互動流程。 正是這些人負責部署回溯和部署系統；正是這些人減輕了開發人員的一些負擔，並儘可能專注於他們極其重要的任務。 同時，devops 永遠不會從後面的房間運行新的電纜或發放新的筆記型電腦 (c) KO
有什麼問題嗎？
對於「誰是 DevOps？」這個問題該領域的一半工作人員開始回答類似“嗯，簡而言之，這是管理員......”以及文本中的進一步內容。 是的，曾幾何時，當 DevOps 工程師這個職業剛剛從服務維護方面最有才華的管理員中脫穎而出時，他們之間的差異並不是每個人都顯而易見的。 但現在，當團隊中DevOps和Admin的功能已經變得截然不同時，將它們相互混淆，甚至等同起來是不可接受的。
但這對商業意味著什麼？
招聘，一切都在於此。
你開設了一個「系統管理員」的職缺，裡面列出的需求有「與開發和客戶的互動」、「CI/CD交付系統」、「公司伺服器和設備的維護」、「內部系統的管理」等等在; 你明白雇主在胡說八道。 問題在於，空缺頭銜應該是“DevOps 工程師”，而不是“系統管理員”，如果更改此頭銜，那麼一切都會水到渠成。
然而，當人們讀到這樣的職缺時，會得到什麼印象呢？ 該公司正在尋找一名多機操作員，他將部署版本控制和監控系統，並用牙齒擠壓扭轉器...
但為了不增加勞動市場的毒癮程度，用正確的名字稱呼空缺職位並清楚地了解DevOps工程師和系統管理員是兩個不同的實體就足夠了。 但一些雇主無法抑制地向候選人提出盡可能廣泛的要求，導致「經典」系統管理員不再了解周圍發生的事情。 什麼，這個職業正在變異，他們已經落後於時代了？
不不，再一次不。 負責管理公司內部伺服器或擔任 L2/L3 支援職位並幫助其他員工的基礎設施管理員尚未消失，也不會消失。
這些專家能成為 DevOps 工程師嗎？ 他們當然可以。 事實上，這是一個需要係統管理技能的相關環境，但除此之外，還需要與監控、交付系統合作，通常還需要與開發和測試團隊密切互動。
另一個 DevOps 問題
事實上，一切並不僅限於招募以及管理員和開發人員之間不斷混淆。 在某些時候，企業面臨交付更新以及開發團隊與最終基礎架構互動的問題。
也許是當一位眼睛閃閃發光的叔叔站在某個會議的舞台上說：「我們這樣做，稱之為DevOps。 這些人會解決你所有的問題」——並開始講述實施 DevOps 實踐後公司的生活是多麼美好。
然而，僅僅聘請 DevOps 工程師來讓一切正常運作還不夠。 公司必須進行一次完整的DevOps轉型，就是說我們DevOps的角色和能力在產品開發和測試團隊這邊也必須清楚地體認到。 我們有一個關於這個主題的「精彩」故事，充分說明了一些地方正在發生的所有暴行。
情況。 DevOps 需要部署一個版本回溯系統，而無需真正深入研究它是如何運作的。 假設在使用者係統中，名字、姓氏和密碼有單獨的欄位。 新版本的產品問世了，但對於開發者來說，「回滾」只是一根萬能的魔杖，他們甚至不知道它是如何運作的。 因此，例如，在下一個補丁中，開發人員組合了名字和姓氏字段，將其投入生產，但由於某種原因該版本很慢。 發生了什麼事？ 管理層找到 devops 並說“拉動開關！”，即要求他回滾到先前的版本。 DevOps 做什麼？ 它會回滾到先前的版本，但由於開發人員不想弄清楚這個回滾是如何完成的，所以沒有人告訴 DevOps 團隊資料庫也需要回溯。 結果，一切都崩潰了，用戶看到的不是緩慢的網站，而是「500」錯誤，因為舊版本無法使用新資料庫的欄位。 Devops 並不知道這一點。 開發商沉默了。 管理層開始失去勇氣和金錢，並記住了備份，並提出回滾它們，以便「至少有些東西會起作用」。 結果，用戶在一段時間內丟失了所有資料。
當然，最瘋狂的是 devops，他們“沒有做出適當的回滾系統”，而且沒有人關心這個故事中的駝鹿是開發人員。
結論很簡單：如果沒有正常的 DevOps 方法，它就沒有多大用處。
要記住的主要事情是：DevOps 工程師不是魔術師，如果沒有高品質的溝通和與開發的雙向交互，他將無法應對他的任務。 開發人員不能獨自處理他們的“問題”，也不能被命令“不要干涉開發人員，他們的工作是編碼”，然後希望在關鍵時刻一切都會按預期進行。 事情不是這樣的。
本質上，DevOps 是一種介於管理和技術之間的能力。 此外，在這杯雞尾酒中，技術含量應該多於管理含量，這一點也遠非顯而易見。 如果您確實想要建立更快、更有效率的開發流程，您必須信任您的 DevOps 團隊。 他知道正確的工具，他實施過類似的項目，他知道如何做。 幫助他，聽聽他的建議，不要試圖把他隔離成某種自治單位。 如果管理員可以自己工作，那麼 DevOps 在這種情況下就沒用了；如果你自己不想接受這種幫助，他們將無法幫助你變得更好。
最後一件事：停止冒犯基礎設施管理員。 他們有自己的、極為重要的工作前沿。 是的，管理員可以成為 DevOps 工程師，但這應該是在該人本人的要求下發生的，而不是在壓力下發生的。 系統管理員想要繼續擔任系統管理員這一事實並沒有什麼問題——這是他獨立的職業，也是他的權利。 如果你想進行職業轉型，那麼你千萬不要忘記，你不僅要培養技術技能，還要培養管理技能。 最有可能的是，你作為領導者將所有這些人聚集在一起並教導他們用同一種語言進行交流。
來源： www.habr.com