在撰寫本文時，在一個流行的招聘網站上搜索“網絡工程師”一詞，在俄羅斯各地找到了大約 2.5 個職位空缺。 相比之下，搜索“系統管理員”一詞會返回近 800 個職位空缺，而“DevOps 工程師”則會返回近 XNUMX 個職位空缺。
這是否意味著在雲、docker、kubernetis 和無處不在的公共 Wi-Fi 獲勝的時代不再需要網絡人員？
讓我們來弄清楚(s)
讓我們結識。 我叫阿列克謝，是一名網絡工作者。
我從事網絡工作已超過 10 年，並且使用各種 *nix 系統也已超過 15 年（我有機會同時選擇 Linux 和 FreeBSD）。 我曾在電信運營商、大公司這些被認為是“企業”的地方工作過，最近我一直在“年輕而大膽”的金融科技工作，那裡的雲、devops、kubernetes等可怕的詞肯定會讓我和我的同事們感到恐懼。不必要。 有一天。 或許。
免責聲明：“在我們的生活中，不是所有事情，總是、無處不在，而是某些東西，有時在某些地方”（c）馬克西姆·多洛費耶夫（Maxim Dorofeev）。
下面所寫的所有內容都可以而且應該被視為作者的個人觀點，並不聲稱是最終的真理，甚至是一項成熟的研究。 所有人物都是虛構的，所有巧合都是隨機的。
歡迎來到我的世界。
哪裡可以找到網絡達人？
1、電信運營商、服務公司等集成商。 一切都很簡單：網絡對他們來說就是一項業務。 他們要么直接銷售連接（運營商），要么提供啟動/維護客戶網絡的服務。
這裡有很多經驗，但錢不多（除非你是總監或成功的銷售經理）。 然而，如果你喜歡網絡，並且你才剛剛開始你的旅程，即使是現在，支持一些不是很大的運營商的職業也將是一個理想的起點（一切都在聯邦網絡中非常有腳本性，並且有創造力的空間很小）。 嗯，關於在幾年內從值班工程師成長為 C 級經理的故事也是相當真實的，儘管很少見，但原因顯而易見。 總是需要人員，因為仍然存在人員流動。 這既是好事也是壞事——另一方面，總是有職位空缺——通常最活躍/最聰明的人要么很快升職，要么去其他“更溫暖”的地方。
2、有條件的“企業”。 他的主要活動是否與 IT 相關並不重要。 最主要的是它有自己的IT部門，負責保證公司內部系統的運行，包括辦公室的網絡、與分支機構的溝通渠道等。 在此類公司中，網絡工程師的職能可以由系統管理員“兼職”執行（如果網絡基礎設施規模較小，或者有外部承包商從事），而網絡經理（如果仍然存在）可以同時照顧電話和 SAN（不是 nuacho）。 他們以不同的方式支付——這在很大程度上取決於業務利潤、公司規模和結構。 我與那些經常將思科“裝在桶裡”的公司合作過，也與那些網絡是用糞便、棍子和藍色電工膠帶構建的公司合作過，而且服務器幾乎從未更新過（有必要說，有也沒有儲備）。 這裡的經驗要少得多，而且幾乎肯定是在硬供應商鎖定領域，或者“如何從無到有”。 就我個人而言，儘管很多人喜歡它，但在我看來，那裡非常無聊——一切都是經過衡量和可預測的（如果我們談論的是大公司），“dorah-bajato”等。 至少每年一次，一些主要供應商表示，他們已經推出了另一個超級超級騙局系統，現在可以自動化一切，所有系統管理員和網絡人員都可以超頻，只需要幾個人在漂亮的界面中按下按鈕即可。 現實情況是，即使我們忽略解決方案的成本，網絡人員也不會從那裡走下去。 是的，有可能不再有控制台，而是有一個網絡界面（但不是特定的一塊鐵，而是一個管理數十個和數百個這樣的鐵的大型系統），但了解“內部一切如何工作” ” 仍然需要。
3、產品公司，其利潤來自某些軟件或平台（即產品）的開發（通常是運營）。 它們通常規模小、靈活，距離企業規模和官僚化還很遠。 正是在這裡，那些同樣的devops、cubers、dockers和其他可怕的詞大量出現，這肯定會讓網絡和網絡工程師成為不必要的雛形。
網絡管理員與系統管理員有何不同？
在人們的理解中，不是來自IT——什麼都沒有。 兩人都看著黑色的屏幕，寫著一些咒語，時而輕聲咒罵。
在程序員的理解中——也許是學科領域。 系統管理員管理服務器，網絡管理員管理交換機和路由器。 有時管理員很糟糕，每個人的一切都會崩潰。 好吧，萬一出現什麼奇怪的情況，網絡人也難辭其咎。 只是因為操你，這就是原因。
事實上，主要的區別在於工作方式。 也許，在網絡工作者中，最有“它有效 - 不要碰它！”這一方法的支持者。 您通常只能用一種方式（在一個供應商內）做某件事，即盒子的整個配置 - 就在這裡，在您的手掌中。 錯誤的成本很高，有時甚至非常高（比如你要跑幾百公里去重啟路由器，這時候幾千人就無法通訊了——這種情況對於電信運營商來說是很常見的） ）。
在我看來，這就是為什麼網絡工程師一方面對網絡穩定性有著極其強烈的動力（而變化是穩定的主要敵人），其次他們的知識深度大於廣度（你不需要為了能夠配置數十種不同的惡魔，您需要了解特定設備製造商的技術及其實現）。 這就是為什麼在 tsiska 上搜索如何在 tsiska 上註冊 VLAN 的系統管理員還不是網絡管理員。 而且他不太可能有效地支持（以及排除故障）或多或少複雜的網絡。
但是，如果您有託管服務商，為什麼還需要網絡管理員呢？
為了額外的錢（如果您是一個非常大且受人喜愛的客戶，甚至可能免費，“作為朋友”），數據中心工程師將配置您的交換機以滿足您的需求，甚至可能幫助建立 BGP 接口與提供商（如果您有自己的 IP 地址子網要公佈）。
主要問題是數據中心不是你的IT部門，它是一個獨立的公司，其目標是盈利。 包括以您作為客戶的費用為代價。 數據中心提供機架，為它們提供電力和冷氣，還提供一些與互聯網的“默認”連接。 基於此基礎設施，數據中心可以對您的設備進行託管（colocation）、向您租用服務器（專用服務器）或提供託管服務（例如OpenStack或K8s）。 但數據中心的業務（通常）不是客戶基礎設施的管理，因為這個過程相當勞動密集型，自動化程度很低（在普通數據中心，一切都是自動化的），統一性更差（每個客戶都是單獨的）並且通常充滿了索賠（“你告訴我服務器已經設置好了，現在它崩潰了，這都是你的錯!!!111”）。 因此，如果房東願意幫助您做某事，那麼他會盡力使其盡可能簡單和“公寓”。 因為這很難做到 - 無利可圖，至少從這個主機的工程師的勞動力成本的角度來看（但情況不同，請參閱免責聲明）。 這並不意味著主人一定會做壞事。 但事實上他根本不會做你真正需要的事情。
這似乎是很明顯的事情，但在我的實踐中，我多次遇到這樣一個事實：公司開始過度依賴他們的託管提供商，但這並沒有帶來任何好處。 花了很長時間才詳細解釋沒有任何 SLA 可以彌補停機損失（也有例外，但通常對客戶來說成本非常非常高）並且託管商根本不知道客戶基礎設施中發生了什麼（非常一般的指標除外）。 而且託管服務商也不為您進行備份。 如果您有多個託管服務商，情況會更糟。 如果他們之間出了什麼問題，他們肯定不會幫你找出問題所在。
實際上，這裡的動機與選擇“自己的管理團隊還是外包”時的動機完全相同。 如果風險經過計算，質量適合，並且企業不介意 - 為什麼不嘗試一下呢？ 另一方面，網絡是基礎設施的最基本層之一，如果您自己已經支持其他所有內容，那麼幾乎不值得將其交給外人。
什麼時候需要網絡管理員？
此外，我們將重點關注現代產品公司。 對於運營商和企業來說，一切都是明確的——近年來幾乎沒有什麼變化，以前需要網絡人員，現在也需要網絡人員。 但對於那些非常“年輕而大膽”的人來說，事情就沒那麼簡單了。 他們通常將基礎設施完全放置在雲中，因此他們甚至不需要管理員，當然，除了相同雲的管理員之外。 一方面，基礎設施的設計非常簡單，另一方面，它的自動化程度很高（ansible / puppet，terraform，ci / cd ...嗯，你知道）。 但即便如此，在某些情況下您也離不開網絡工程師。
示例1，經典
假設一家公司從一台具有公共 IP 地址的服務器開始，該服務器位於數據中心。 然後有兩台服務器。 還有更多......遲早，服務器之間需要專用網絡。 因為“外部”流量受到帶寬（例如不超過 100Mbps）和每月下載/上傳量的限制（不同的託管商有不同的資費，但通常到外界的帶寬要多得多）。比專用網絡更昂貴）。
託管商向服務器添加額外的網卡，並將它們包含在單獨 VLAN 中的交換機中。 服務器之間出現“扁平”LAN。 舒服的！
服務器數量在增長，專用網絡中的流量也在增長——備份、複製等。 託管服務商提出將您轉移到單獨的交換機，這樣您就不會干擾其他客戶端，他們也不會干擾您。 託管商放置了某種交換機並以某種方式配置它們 - 最有可能的是，在所有服務器之間留下一個平坦的網絡。 一切都運行良好，但在某個時刻，問題開始出現：主機之間的延遲週期性地增長，日誌每秒有太多的 arp 數據包，並且滲透測試人員在審計期間強奸了您的整個本地區域，只破壞了一台服務器。
怎麼辦？
將網絡劃分為多個段 - VLAN。 在每個 VLAN 中設置您自己的尋址，選擇將在網絡之間傳輸流量的網關。 在網關上，配置acl來限製網段之間的訪問，甚至可以在旁邊放置一個單獨的防火牆。
示例 1（續）
服務器通過一根線連接到本地。 機架中的交換機以某種方式相互連接，但如果一個機架發生事故，另外三個相鄰的交換機就會掉落。 計劃是存在的，但人們對其相關性存疑。 每台服務器都有自己的公共地址，由主機發布並綁定到機架上。 那些。 移動服務器時，必須更改地址。
怎麼辦？
使用 LAG（鏈路聚合組）通過兩根電線將服務器連接到機架中的交換機（它們也需要冗餘）。 保留機架之間的連接，用“星”（或現在流行的CLOS）重新製作它們，以便一個機架的丟失不會影響其他機架。 選擇網絡核心所在位置以及其他機架所在的“中央”機架。 同時，按順序排列公共尋址，從託管服務商（或從 RIR，如果可能）獲取子網，您自己（或通過託管服務商）向全世界公佈該子網。
一個對網絡沒有深入了解的“普通”系統管理員可以完成這一切嗎？ 沒有把握。 樓主會做嗎？ 也許會，但你需要一個相當詳細的 TOR，它也需要由某人編譯。 然後檢查一切是否正確完成。
示例 2：多雲
假設您在某個公共雲中有一個 VPC。 要從基礎設施的辦公室或本地部分訪問 VPC 內的本地網絡，您需要通過 IPSec 或專用通道建立連接。 一方面，IPSec 更便宜。 無需購買額外的硬件，您可以在具有公共地址的服務器和雲端之間建立隧道。 但是 - 延遲、有限的性能（因為通道需要加密）以及不受保證的連接（因為訪問通過常規互聯網進行）。
怎麼辦？
通過專用通道提升連接（例如，AWS 稱之為 Direct Connect）。 為此，請找到一個能夠連接您的合作運營商，決定離您最近的連接點（您連接到運營商，運營商連接到雲），最後設置好一切。 這一切可以在沒有網絡工程師的情況下完成嗎？ 當然，是的。 但一旦出現問題如何在沒有它的情況下排除故障就不再那麼清楚了。
並且還可能存在雲之間的可用性問題（如果您有多雲）或不同區域之間的延遲問題等。 當然，現在有許多工具可以提高雲中發生的事情的透明度（相同的千眼），但這些都是網絡工程師工具，而不是替代品。
我可以從我的實踐中勾畫出更多這樣的例子，但我認為很明顯，在一個團隊中，從基礎設施開發的一定水平開始，應該有一個人（或者更好，不止一個）知道網絡如何工作，可以配置網絡設備並處理出現的問題。 相信我，他會有事可做
網絡工作者應該知道什麼？
網絡工程師完全沒有必要（有時甚至是有害的）只處理網絡而不處理其他事情。 即使我們不考慮幾乎完全位於公共雲中的基礎設施選項（並且，無論人們怎麼說，它變得越來越流行），並採取例如本地雲或私有云，其中只有“CCNP 級別的知識 “你不會離開。
事實上，除了網絡之外——儘管有一個無窮無盡的研究領域，即使你只專注於一個方向（提供商網絡、企業、數據中心、Wi-Fi ...）
當然，你們中的許多人現在會記得Python和其他“網絡自動化”，但這只是一個必要條件，但不是充分條件。 為了讓網絡工程師“成功加入團隊”，他必須能夠與開發人員和其他管理員/開發人員使用相同的語言。 這是什麼意思？
- 不僅能夠以用戶身份在 Linux 中工作，而且能夠至少在初級系統管理員的級別上對其進行管理：安裝必要的軟件、重新啟動失效的服務、編寫一個簡單的 systemd 單元。
- 了解（至少一般而言）網絡堆棧如何在 Linux 中工作，網絡如何在虛擬機管理程序和容器（lxc / docker / kubernetes）中工作。
- 當然，能夠與 ansible/chef/puppet 或其他 SCM 系統一起工作。
- 應單獨編寫一行有關 SDN 和私有云網絡（例如，TungstenFabric 或 OpenvSwitch）的內容。 這又是一個巨大的知識。
簡而言之，我描述了一個典型的T型專家（現在流行這樣的說法）。 這似乎不是什麼新鮮事，然而，根據面試的經驗，並不是所有的網絡工程師都能誇耀自己至少掌握上述列表中的兩個主題。 在實踐中，由於缺乏“相關領域”的知識，不僅很難與同事溝通，而且很難理解業務對作為項目最底層基礎設施的網絡提出的要求。 如果沒有這種理解，合理地捍衛你的觀點並將其“推銷”給企業就會變得更加困難。
另一方面，“了解系統如何工作”的習慣使網絡人員比各種“通才”具有很大的優勢，這些“通才”從 Habré/medium 和 telegram 聊天的文章中了解技術，但完全不知道這或什麼原理。該軟件有效。 正如你所知，一些規律性的知識成功地取代了許多事實的知識。
結論，或者簡單地說 TL;DR
- 網絡管理員（如 DBA 或 VoIP 工程師）是一個專業範圍相當狹窄的專家（與系統管理員/devops/SRE 不同），其需求不會立即出現（事實上，可能很長時間都不會出現） 。 但如果它確實出現，那麼它不太可能被外部專家（外包或普通的多面手管理員，“他們也照顧網絡”）所取代。 更令人悲哀的是，對此類專家的需求很小，而且有條件地，在一家擁有 800 名程序員和 30 名開發人員/管理員的公司中，只能有兩名網絡人員能夠完美地完成自己的工作。 那些。 市場過去和現在都非常非常小，如果薪水不錯的話就更小了。
- 另一方面，現代世界的優秀網絡人員不僅應該了解網絡本身（以及如何自動化其配置），還應該了解在這些網絡上運行的操作系統和軟件如何與網絡交互。 如果沒有這一點，就很難理解同事對你的要求並向他們（合理地）傳達你的願望/要求。
- 沒有云，它只是別人的計算機。 您需要了解，使用公共/私有云或“為您做一切”的託管提供商的服務並不能否定您的應用程序仍在使用網絡的事實，並且它的問題將影響您的應用程序的運行。 您的選擇取決於能力中心的所在地，該中心將負責您的項目網絡。
來源： www.habr.com