Bu makalenin yazıldığı sırada popüler bir iş sitesinde "Ağ Mühendisi" terimi arandığında Rusya genelinde yaklaşık üç yüz boş pozisyon ortaya çıktı. Karşılaştırma yapmak gerekirse, "sistem yöneticisi" ifadesi arandığında neredeyse 2.5 bin boş pozisyon ve "DevOps mühendisi" - neredeyse 800 boş pozisyon döndürülür.
Bu, başarılı bulutların, Docker'ın, Kubernetes'in ve her yerde kullanıma açık Wi-Fi'nin hakim olduğu zamanlarda ağ uzmanlarına artık ihtiyaç duyulmadığı anlamına mı geliyor?
Hadi çözelim (c)
Hadi tanışalım. Adım Alexey ve ben bir ağ uzmanıyım.
10 yıldan fazla bir süredir ağlarla ilgileniyorum ve 15 yıldan fazla bir süredir çeşitli *nix sistemleriyle çalışıyorum (hem Linux hem de FreeBSD ile uğraşma şansım oldu). Telekom operatörlerinde, “kurumsal” olarak değerlendirilen büyük şirketlerde çalıştım ve son zamanlarda bulutların, devopsların, kubernetlerin ve beni ve meslektaşlarımı kesinlikle gereksiz kılacak diğer korkutucu sözlerin olduğu “genç ve cesur” fintech alanında çalışıyorum. . Bir gün. Belki.
sorumluluk reddi beyanı: "Hayatımızda her şey her zaman ve her yerde değil, bazen bazı yerlerde bir şey vardır" (c) Maxim Dorofeev.
Aşağıda yazılan her şey, yazarın nihai gerçek, hatta tam teşekküllü bir çalışma olduğunu iddia etmeyen kişisel görüşü olarak değerlendirilebilir ve değerlendirilmelidir. Tüm karakterler hayal ürünüdür, tüm tesadüfler rastgeledir.
Dünyama hoşgeldin.
Ağ oluşturucularla nerede tanışabilirsiniz?
1. Telekom operatörleri, hizmet şirketleri ve diğer entegratörler. Burada her şey basit: onlar için ağ bir iştir. Ya doğrudan bağlantı (operatörler) satarlar ya da müşterilerinin ağlarını başlatmak/sürdürmek için hizmetler sağlarlar.
Burada çok fazla deneyim var, ancak çok fazla para yok (yönetici veya başarılı bir satış müdürü olmadığınız sürece). Yine de, eğer ağları seviyorsanız ve yolculuğunuzun henüz başındaysanız, çok büyük olmayan bazı operatörleri destekleyen bir kariyer, şimdi bile ideal bir başlangıç noktası olacaktır (federal olanlarda her şey çok yazılıdır ve oradadır). yaratıcılık için çok az yer var). Birkaç yıl içinde görevdeki bir mühendisten C düzeyinde bir yöneticiye nasıl dönüşebileceğinize dair hikayeler de oldukça gerçektir, ancak nadir de olsa, bariz nedenlerden dolayı. Personel değişimi olduğu için her zaman personele ihtiyaç vardır. Bu aynı zamanda hem iyi hem de kötü - öte yandan her zaman boş pozisyonlar vardır - çoğu zaman en aktif/zeki olanlar ya terfi için ya da başka "daha sıcak" yerlere hızla ayrılırlar.
2. Koşullu “girişim”. Ana faaliyetinin BT ile ilgili olup olmaması önemli değil. Önemli olan, ofislerdeki ağ, şubelere giden iletişim kanalları vb. dahil olmak üzere şirketin iç sistemlerinin çalışmasını sağlayan kendi BT departmanına sahip olmasıdır. Bu tür şirketlerde ağ mühendisinin görevleri, bir sistem yöneticisi (ağ altyapısı küçükse veya dışarıdan bir yüklenici tarafından yönetiliyorsa) tarafından “yarı zamanlı” olarak yerine getirilebilir ve varsa bir ağ uzmanı da bu görevleri yerine getirebilir. aynı zamanda telefon ve SAN ile de ilgilenin (iyi değil). Farklı ödeme yapıyorlar - bu büyük ölçüde işin karlılığına, şirketin büyüklüğüne ve yapısına bağlıdır. Cisco sistemlerinin düzenli olarak "varillere yüklendiği" şirketlerle ve ağın dışkı, çubuk ve mavi banttan oluşturulduğu ve sunucuların hiçbir zaman güncellenmediği (söylemeye gerek yok, rezerv de sağlanmadığı) şirketlerle çalıştım. Burada çok daha az deneyim var ve bu neredeyse kesinlikle katı satıcı kilidi veya "yoktan bir şeyin nasıl yapılacağı" alanında olacak. Şahsen ben bunu son derece sıkıcı buldum, ancak birçok insan bundan hoşlanıyor - her şey oldukça ölçülü ve öngörülebilir (eğer büyük şirketlerden bahsediyorsak), "dorakha-bahato" vb. Yılda en az bir kez, bazı büyük satıcılar artık her şeyi otomatikleştirecek başka bir mega-süper-kandırılmış sistem bulduklarını ve tüm sistem yöneticilerinin ve ağ çalışanlarının dağıtılabileceğini ve güzel bir arayüzde düğmelere basacak birkaç kişi bırakılabileceğini söylüyor. Gerçek şu ki, çözümün maliyetini göz ardı etsek bile ağ oluşturucular buradan hiçbir yere gidemeyecektir. Evet, belki konsol yerine yine bir web arayüzü olacak (ancak belirli bir donanım parçası değil, onlarca ve yüzlerce donanım parçasını yöneten büyük bir sistem), ancak "içeride her şeyin nasıl çalıştığı" bilgisi yine de olacak ihtiyaç duyulması.
3. Ürün şirketleri, karı bazı yazılım veya platformun (aynı ürün) geliştirilmesinden (ve çoğu zaman işletilmesinden) gelir. Genellikle küçük ve çeviktirler, henüz işletme ölçeğinden ve bürokratikleşmesinden uzaktırlar. Aynı devops, cuber, docker ve diğer korkunç kelimelerin topluca bulunduğu yer burasıdır; bu da kesinlikle ağ ve ağ mühendislerini gereksiz bir ilkel haline getirecektir.
Bir ağ uzmanının sistem yöneticisinden farkı nedir?
BT'den olmayan insanların anlayışında - hiçbir şey. Her ikisi de siyah ekrana bakıyor ve bazen sessizce küfür ederek bazı büyüler yazıyor.
Programcıların anlayışına göre - belki konu alanına göre. Sistem yöneticileri sunucuları yönetir, ağ çalışanları ise anahtarları ve yönlendiricileri yönetir. Bazen yönetim kötüdür ve herkes için her şey alt üst olur. Tuhaf bir şey olması durumunda ağ oluşturucular da suçlanacak. Sırf seni sikeyim diye, bu yüzden.
Aslında temel fark işe yaklaşımdır. Belki de “Eğer işe yarıyorsa, dokunmayın!” yaklaşımının en fazla destekçisi ağ çalışanları arasında bulunmaktadır. Kural olarak, bir şey (tek bir satıcı içinde) yalnızca tek bir şekilde yapılabilir; kutunun tüm konfigürasyonu avucunuzun içindedir. Bir hatanın maliyeti yüksektir ve bazen çok yüksektir (örneğin, yönlendiriciyi yeniden başlatmak için birkaç yüz kilometre gitmeniz gerekecek ve şu anda birkaç bin kişi iletişimsiz kalacak - bir telekom operatörü için oldukça yaygın bir durum) .
Bana göre, ağ mühendislerinin bir yandan ağ istikrarı konusunda son derece yüksek motivasyona sahip olmalarının (ve istikrarın ana düşmanı değişimdir) ve ikinci olarak, onların bilgilerinin genişlikten ziyade derinliğe gitmesinin nedeni budur (bunu bilmiyorsunuz). düzinelerce farklı arka plan programını yapılandırabilmeniz gerekir, teknolojileri ve belirli bir ekipman üreticisinin uygulamalarını bilmeniz gerekir). Bu nedenle Cisco sistemine vlan'ın nasıl kaydedileceğini Google'da araştıran bir sistem yöneticisi henüz bir ağ oluşturucu değildir. Ve az ya da çok karmaşık bir ağı etkili bir şekilde destekleyebilmesi (aynı zamanda sorunları giderebilmesi) pek olası değildir.
Peki bir barındırıcınız varsa neden bir ağ oluşturucuya ihtiyacınız var?
Ek para karşılığında (ve çok büyük ve sevilen bir müşteriyseniz, hatta belki ücretsiz olarak, "arkadaş olarak"), veri merkezi mühendisleri anahtarlarınızı ihtiyaçlarınıza uyacak şekilde yapılandıracak ve hatta belki de sağlayıcılarla bir BGP arayüzü kurmanıza yardımcı olacaktır. (duyuru için kendi IP adresi alt ağınız varsa).
Asıl sorun, veri merkezinin sizin BT departmanınız olmaması, amacı kar elde etmek olan ayrı bir şirket olmasıdır. Müşteri olarak masraflarınız size ait olmak üzere. Veri merkezi raflar sağlar, onlara elektrik ve soğukluk sağlar ve ayrıca İnternet'e bazı "varsayılan" bağlantı sağlar. Bu altyapıya dayanarak, veri merkezi ekipmanınızı barındırabilir (ortak yerleşim), size bir sunucu kiralayabilir (özel sunucu) veya yönetilen bir hizmet sağlayabilir (örneğin, OpenStack veya K8s). Ancak bir veri merkezinin işi (genellikle) müşteri altyapısının yönetimi değildir, çünkü bu süreç oldukça emek yoğundur, otomatikleştirmesi zayıftır (ve normal bir veri merkezinde mümkün olan her şey otomatikleştirilmiştir), daha da kötüsü birleştirilmiştir (her müşteri bireyseldir) ve genellikle şikayetlerle doludur (“sunucunun kurulduğunu söylüyorsun ama şimdi çöktü, hepsi senin hatan!!!111”). Bu nedenle, ev sahibi size bir konuda yardımcı olursa, bunu olabildiğince basit ve kullanışlı hale getirmeye çalışacaktır. Çünkü bunu zorlaştırmak, en azından aynı barındırıcının mühendislerinin işçilik maliyetleri açısından kârsızdır (ancak durumlar farklıdır, bkz. sorumluluk reddi). Bu, ev sahibinin mutlaka her şeyi kötü yapacağı anlamına gelmez. Ancak tam olarak ihtiyacınız olanı yapacağı kesinlikle bir gerçek değil.
Görünüşe göre durum oldukça açık, ancak uygulamalarımda birkaç kez şirketlerin barındırma sağlayıcılarına olması gerekenden biraz daha fazla güvenmeye başladıkları ve bunun iyi bir şeye yol açmadığı gerçeğiyle karşılaştım. Tek bir SLA'nın kesinti süresinden kaynaklanan kayıpları karşılamayacağını (istisnalar vardır, ancak genellikle müşteri için çok çok pahalıdır) ve barındırıcının neler olup bittiğinin hiç farkında olmadığını uzun ve ayrıntılı bir şekilde açıklamak zorunda kaldım. müşterilerin altyapısı (çok genel göstergeler hariç). Barındırıcı da sizin için yedekleme yapmaz. Birden fazla barındırma sağlayıcınız varsa durum daha da kötüdür. Aralarında herhangi bir sorun olması durumunda, neyin yanlış gittiğini kesinlikle sizin için öğrenemeyeceklerdir.
Aslında buradaki amaç, “şirket içi yönetici ekibi mi yoksa dış kaynak mı” seçimiyle tamamen aynı. Riskler hesaplanıyorsa, kalite tatmin ediciyse ve işletme bunu sorun etmiyorsa neden denemiyorsunuz? Öte yandan, ağ, altyapının en temel katmanlarından biridir ve eğer geri kalan her şeyi kendiniz destekliyorsanız, bunu dışarıdaki adamlara bırakmaya pek değmez.
Hangi durumlarda bir ağ oluşturucuya ihtiyaç duyulur?
Daha sonra özellikle modern gıda şirketleri hakkında konuşacağız. Operatörler ve işletmeyle ilgili her şey açık, artı veya eksi - son yıllarda orada çok az şey değişti ve orada ağ oluşturuculara daha önce ihtiyaç duyuldu ve şimdi de onlara ihtiyaç var. Ancak aynı "genç ve cesur" kişilerle ilgili işler o kadar net değil. Çoğu zaman tüm altyapılarını bulutlara yerleştiriyorlar, dolayısıyla aslında aynı bulutların yöneticileri dışında yöneticilere bile ihtiyaç duymuyorlar. Altyapı, bir yandan tasarımı oldukça basit, diğer yandan iyi bir şekilde otomatikleştirilmiş (ansible/puppet, terraform, ci/cd... yani, biliyorsunuz). Ancak burada bile ağ mühendisi olmadan yapamayacağınız durumlar vardır.
Örnek 1, klasik
Bir şirketin, bir veri merkezinde bulunan, genel IP adresine sahip bir sunucuyla başladığını varsayalım. Sonra iki sunucu var. Sonra daha fazlası... Er ya da geç sunucular arasında özel bir ağa ihtiyaç duyulacaktır. Çünkü "harici" trafik hem bant genişliğiyle (örneğin 100 Mbit/s'den fazla değil) hem de aylık indirilen/yüklenenlerin hacmiyle (farklı barındırıcıların farklı tarifeleri vardır, ancak dış dünyaya bant genişliği genellikle bir sunucudan çok daha pahalıdır) sınırlıdır. özel ağ).
Barındırıcı, sunuculara ek ağ kartları ekler ve bunları ayrı bir vlan'daki anahtarlarına dahil eder. Sunucular arasında “düz” bir yerel alan beliriyor. Rahat!
Sunucu sayısı artıyor ve özel ağdaki trafik de artıyor - yedeklemeler, çoğaltmalar vb. Barındırıcı, diğer istemcilere müdahale etmemeniz ve onların da size müdahale etmemesi için sizi ayrı anahtarlara taşımayı teklif eder. Barındırıcı bazı anahtarlar yükler ve bir şekilde bunları yapılandırır; büyük olasılıkla tüm sunucularınız arasında tek bir düz ağ bırakır. Her şey yolunda gidiyor, ancak belli bir anda sorunlar başlıyor: ana bilgisayarlar arasındaki gecikmeler periyodik olarak artıyor, günlükler saniyede çok fazla arp paketi olduğundan şikayet ediyor ve bir denetim sırasında pentester tüm yerel ağınızı becererek yalnızca bir sunucuyu bozuyor.
Ne yapayım?
Ağı segmentlere (vlanlara) bölün. Her vlan'da kendi adreslemenizi yapılandırın, ağlar arasında trafiği aktaracak bir ağ geçidi seçin. Segmentler arasındaki erişimi sınırlamak için ağ geçidinde acl'yi yapılandırın, hatta yakınlara ayrı bir güvenlik duvarı kurun.
Örnek 1, devamı
Sunucular LAN'a tek kabloyla bağlanır. Raflardaki anahtarlar bir şekilde birbirine bağlı, ancak bir rafta kaza olursa bitişik üç raf daha düşüyor. Planlar mevcut ancak bunların geçerliliği konusunda şüpheler var. Her sunucunun, barındırıcı tarafından verilen ve rafa bağlanan kendi genel adresi vardır. Onlar. Bir sunucuyu taşırken adresin değiştirilmesi gerekir.
Ne yapayım?
Sunucuları LAG (Bağlantı Toplama Grubu) kullanarak raftaki anahtarlara iki kabloyla bağlayın (bunların da yedekli olmaları gerekir). Raflar arasındaki bağlantıları ayırın, bunları "yıldız" tipine (veya artık moda olan CLOS'a) dönüştürün, böylece bir rafın kaybı diğerlerini etkilemez. Ağ çekirdeğinin yerleştirileceği ve diğer rafların bağlanacağı “merkezi” rafları seçin. Aynı zamanda, genel seslendirmeyi düzene koyun, kendinizin (veya barındırıcı aracılığıyla) dünyaya duyurduğunuz ana bilgisayardan (veya mümkünse RIR'den) bir alt ağ alın.
Bütün bunlar, ağlar hakkında derin bilgiye sahip olmayan "sıradan" bir sistem yöneticisi tarafından yapılabilir mi? Emin değil. Ev sahibi bunu yapacak mı? Belki öyle olacak, ancak oldukça ayrıntılı bir teknik spesifikasyona ihtiyacınız olacak ve birisinin de bunu hazırlaması gerekecek. ve ardından her şeyin doğru şekilde yapıldığını kontrol edin.
Örnek 2: Bulut
Diyelim ki genel bir bulutta bir VPC'niz var. Altyapının ofisten veya şirket içi kısmından VPC içindeki yerel ağa erişim sağlamak için IPSec veya özel bir kanal aracılığıyla bir bağlantı yapılandırmanız gerekir. Bir yandan IPSec daha ucuzdur çünkü ek donanım almanıza gerek yok; genel adresli sunucunuz ile bulut arasında bir tünel kurabilirsiniz. Ancak - gecikmeler, sınırlı performans (kanalın şifrelenmesi gerektiğinden) ve garanti edilmeyen bağlantı (erişim normal İnternet üzerinden olduğu için).
Ne yapayım?
Özel bir kanal aracılığıyla bağlantı kurun (örneğin, AWS buna Direct Connect adını verir). Bunu yapmak için, sizi bağlayacak bir ortak operatör bulun, size en yakın bağlantı noktasına karar verin (hem siz operatöre hem de operatör buluta) ve son olarak her şeyi ayarlayın. Tüm bunları bir ağ mühendisi olmadan yapmak mümkün mü? Elbette evet. Ancak sorun olması durumunda onsuz nasıl sorun giderileceği artık o kadar net değil.
Ayrıca bulutlar arasındaki kullanılabilirlik sorunları (çoklu bulutunuz varsa) veya farklı bölgeler arasındaki gecikmeler vb. ile ilgili sorunlar da olabilir. Elbette artık bulutta olup bitenlerin şeffaflığını artıran birçok araç ortaya çıktı (aynı Bin Göz), ancak bunların hepsi bir ağ mühendisinin araçlarıdır ve onun yerine geçmez.
Uygulamamdan buna benzer bir düzine örnek daha çizebilirim, ancak belli bir altyapı geliştirme düzeyinden başlayarak ekibin, ağın nasıl çalıştığını bilen ve yapılandırabilen bir kişiye (tercihen birden fazla) sahip olması gerektiği açıktır. ağ ekipmanı ve ortaya çıkarsa sorunları çözer. İnan bana, yapacak bir işi olacak
Bir ağ uzmanı ne bilmeli?
Bir ağ mühendisinin yalnızca ağla uğraşması ve başka hiçbir şeyle ilgilenmesi hiç de gerekli değildir (ve hatta bazen zararlıdır). Neredeyse tamamen genel bulutta yaşayan bir altyapı seçeneğini düşünmesek bile (ve ne derse desin, giderek daha popüler hale geliyor) ve örneğin şirket içi veya özel bulutları ele alalım; “Yalnızca CCNP düzeyinde bilgi” üzerine "Ayrılmayacaksınız.
Aslında ağlara ek olarak - yalnızca tek bir alana odaklansanız bile (sağlayıcı ağları, işletmeler, veri merkezleri, Wi-Fi ...)
Elbette çoğunuz artık Python'u ve diğer "ağ otomasyonunu" hatırlayacaktır, ancak bu yalnızca gerekli bir koşuldur, ancak yeterli bir koşul değildir. Bir ağ mühendisinin "ekibe başarılı bir şekilde katılabilmesi" için hem geliştiricilerle hem de yönetici/geliştiricilerle aynı dili konuşabilmesi gerekir. Bu ne anlama geliyor?
- Linux'ta yalnızca kullanıcı olarak çalışmakla kalmayıp, aynı zamanda onu en azından sistem yöneticisi-haziran düzeyinde yönetebilmek: gerekli yazılımı yükleyin, arızalı bir hizmeti yeniden başlatın, basit bir sistem birimi yazın.
- Ağ yığınının Linux'ta nasıl çalıştığını, ağın hipervizörlerde ve konteynerlerde (lxc / docker / kubernetes) nasıl çalıştığını (en azından genel anlamda) anlayın.
- Elbette ansible/chef/puppet veya başka bir SCM sistemi ile çalışabilmek.
- Özel bulutlar için SDN ve ağlar (örneğin TungstenFabric veya OpenvSwitch) hakkında ayrı bir satır yazılmalıdır. Bu başka bir büyük bilgi katmanıdır.
Kısacası, tipik bir T-şekli uzmanını tanımladım (şu anda söylemek moda olduğu için). Yeni bir şey gibi görünmüyor, ancak röportaj deneyimlerine göre tüm ağ mühendisleri yukarıdaki listeden en az iki konu hakkında bilgi sahibi olmakla övünemez. Uygulamada, "ilgili alanlardaki" bilgi eksikliği, yalnızca meslektaşlarla iletişim kurmayı değil, aynı zamanda işletmenin projenin en alt düzey altyapısı olan ağa yerleştirdiği gereksinimleri anlamayı da çok zorlaştırıyor. Ve bu anlayış olmadan, bakış açınızı savunmak ve onu iş dünyasına "satmak" daha zor hale gelir.
Öte yandan, aynı "sistemin nasıl çalıştığını anlama" alışkanlığı, ağ oluşturuculara, Habré/medium'daki makalelerden ve Telegram'daki sohbetlerden teknolojiler hakkında bilgi sahibi olan ancak bunu nasıl yapacakları konusunda kesinlikle hiçbir fikri olmayan çeşitli "genel uzmanlara" karşı çok iyi bir avantaj sağlar. şu veya bu yazılım prensipler üzerinde çalışıyor mu? Ve bilindiği gibi, belirli kalıplara ilişkin bilgi, birçok gerçeğin bilgisinin yerini başarıyla alır.
Sonuçlar veya sadece TL;DR
- Bir ağ yöneticisi (bir DBA veya VoIP mühendisi gibi), oldukça dar bir profile sahip bir uzmandır (sistem yöneticileri/devs/SRE'den farklı olarak), ihtiyacı hemen ortaya çıkmaz (ve aslında uzun bir süre ortaya çıkmayabilir). . Ancak ortaya çıkması durumunda, bunun dışarıdan bir uzman tarafından (dış kaynak veya "aynı zamanda ağla da ilgilenen" sıradan genel amaçlı yöneticiler) değiştirilmesi pek olası değildir. Biraz daha üzücü olan ise, bu tür uzmanlara olan ihtiyacın az olması ve şartlı olarak, 800 programcı ve 30 geliştirici/yöneticinin bulunduğu bir şirkette, sorumluluklarıyla mükemmel bir iş çıkaran yalnızca iki ağ oluşturucunun bulunabilmesidir. Onlar. Pazar çok çok küçüktü ve hala da iyi bir maaşla, hatta daha az.
- Öte yandan, modern dünyada iyi bir ağ oluşturucunun yalnızca ağların kendisini (ve bunların yapılandırmasını nasıl otomatikleştireceğini) değil, aynı zamanda bu ağların üzerinde çalışan işletim sistemleri ve yazılımların onlarla nasıl etkileşime girdiğini de bilmesi gerekir. Bu olmadan meslektaşlarınızın sizden ne istediğini anlamak ve onlara (makul şekilde) istek/taleplerinizi iletmek son derece zor olacaktır.
- Bulut yok, sadece başka birinin bilgisayarı. Genel/özel bulutları veya "sizin için her şeyi anahtar teslimi olarak yapan" bir barındırma sağlayıcısının hizmetlerini kullanmanın, uygulamanızın hala ağı kullandığı gerçeğini değiştirmediğini ve bununla ilgili sorunların, uygulamanın çalışmasını etkileyeceğini anlamalısınız. başvurunuz. Seçiminiz, projenizin ağından sorumlu olacak yeterlilik merkezinin nerede bulunacağıdır.
Kaynak: habr.com