Pada saat artikel ini ditulis, pencarian di situs kerja populer untuk frasa “Insinyur Jaringan” menghasilkan sekitar tiga ratus lowongan di seluruh Rusia. Sebagai perbandingan, penelusuran untuk frasa "administrator sistem" menghasilkan hampir 2.5 ribu lowongan, dan "insinyur DevOps" - hampir 800.
Apakah ini berarti bahwa para penggiat jejaring tidak lagi dibutuhkan di masa kejayaan cloud, Docker, Kubernetes, dan Wi-Fi publik yang ada di mana-mana?
Mari kita cari tahu (c)
Mari Berkenalan. Nama saya Alexei dan saya seorang penggiat jejaring.
Saya telah terlibat dalam jaringan selama lebih dari 10 tahun dan telah bekerja dengan berbagai sistem *nix selama lebih dari 15 tahun (saya berkesempatan untuk bermain-main dengan Linux dan FreeBSD). Saya bekerja di operator telekomunikasi, perusahaan besar yang dianggap “perusahaan”, dan baru-baru ini saya bekerja di fintech yang “muda dan berani”, di mana cloud, devops, kubernetes, dan kata-kata menakutkan lainnya yang pasti akan membuat saya dan rekan-rekan saya tidak berguna. . Suatu hari nanti. Mungkin.
penafian: “Dalam hidup kita, tidak semuanya selalu dan di mana-mana, tetapi sesuatu, terkadang di tempat” (c) Maxim Dorofeev.
Segala sesuatu yang tertulis di bawah ini dapat dan harus dianggap sebagai pendapat pribadi penulis, yang tidak mengklaim sebagai kebenaran hakiki, atau bahkan penelitian yang matang. Semua karakter adalah fiktif, semua kebetulan adalah acak.
Selamat Datang di dunia saya.
Di mana Anda bisa bertemu penggiat jejaring?
1. Operator telekomunikasi, perusahaan jasa dan integrator lainnya. Semuanya sederhana di sini: jaringan bagi mereka adalah bisnis. Mereka menjual konektivitas secara langsung (operator) atau menyediakan layanan untuk meluncurkan/memelihara jaringan pelanggannya.
Ada banyak pengalaman di sini, tetapi tidak banyak uang (kecuali jika Anda seorang direktur atau manajer penjualan yang sukses). Namun, jika Anda menyukai jaringan, dan Anda baru saja memulai perjalanan Anda, karier dalam mendukung beberapa operator yang tidak terlalu besar, bahkan sekarang, akan menjadi titik awal yang ideal (di federal semuanya sangat sesuai dengan skenario, dan di sana hanya ada sedikit ruang untuk kreativitas). Nah, cerita tentang bagaimana Anda dapat berkembang dari seorang insinyur yang bertugas dalam beberapa tahun menjadi manajer tingkat C juga cukup nyata, meskipun jarang, karena alasan yang jelas. Kebutuhan akan personel selalu ada, karena pergantian memang terjadi. Hal ini baik dan buruk pada saat yang sama - sebaliknya selalu ada lowongan - seringkali orang yang paling aktif/pintar dengan cepat pergi untuk promosi atau ke tempat lain yang “lebih hangat”.
2. “Perusahaan” bersyarat. Tidak peduli apakah aktivitas utamanya berhubungan dengan IT atau tidak. Yang utama adalah memiliki departemen IT sendiri yang menjamin berfungsinya sistem internal perusahaan, termasuk jaringan di kantor, saluran komunikasi ke cabang, dll. Fungsi insinyur jaringan di perusahaan tersebut dapat dilakukan “paruh waktu” oleh administrator sistem (jika infrastruktur jaringan kecil atau ditangani oleh kontraktor eksternal), dan spesialis jaringan, jika ada, dapat di pada saat yang sama menjaga telepon dan SAN (tidak bagus). Mereka membayar secara berbeda - ini sangat bergantung pada profitabilitas bisnis, ukuran perusahaan, dan strukturnya. Saya bekerja dengan perusahaan di mana sistem Cisco secara teratur “dimuat dalam tong”, dan dengan perusahaan yang jaringannya dibangun dari kotoran, tongkat, dan pita biru, dan servernya tidak pernah diperbarui (tentu saja, tidak ada cadangan yang disediakan juga) . Pengalaman di sini jauh lebih sedikit, dan hampir pasti akan berada di bidang vendor-lock yang ketat, atau “cara membuat sesuatu dari ketiadaan”. Secara pribadi, menurut saya ini sangat membosankan, meskipun banyak orang menyukainya - semuanya cukup terukur dan dapat diprediksi (jika kita berbicara tentang perusahaan besar), “dorakha-bahato”, dll. Setidaknya setahun sekali, beberapa vendor besar mengatakan bahwa mereka telah menciptakan sistem mega-super-duper lain yang akan mengotomatiskan semuanya sekarang dan semua administrator sistem dan penggiat jejaring dapat disebarkan, menyisakan beberapa orang untuk menekan tombol dalam antarmuka yang indah. Kenyataannya adalah, bahkan jika kita mengabaikan biaya solusinya, para penggiat jejaring tidak akan bisa berbuat apa-apa. Ya, mungkin alih-alih konsol akan ada lagi antarmuka web (tetapi bukan perangkat keras tertentu, tetapi sistem besar yang mengelola puluhan dan ratusan perangkat keras tersebut), tetapi pengetahuan tentang "cara kerja segala sesuatu di dalamnya" akan tetap ada. dibutuhkan.
3. Perusahaan produk, keuntungannya berasal dari pengembangan (dan, seringkali, pengoperasian) beberapa perangkat lunak atau platform - produk yang sama. Biasanya mereka kecil dan gesit, masih jauh dari skala usaha dan birokratisasinya. Di sinilah devops, cuber, buruh pelabuhan, dan kata-kata buruk lainnya ditemukan secara massal, yang tentunya akan membuat jaringan dan insinyur jaringan menjadi hal yang tidak perlu.
Apa perbedaan antara penggiat jejaring dan administrator sistem?
Dalam pemahaman orang bukan dari IT - tidak ada apa-apa. Keduanya melihat ke layar hitam dan menulis beberapa mantra, terkadang mengumpat dengan pelan.
Dalam pemahaman programmer - mungkin berdasarkan bidang studi. Administrator sistem mengelola server, penggiat jaringan mengelola switch dan router. Terkadang pemerintahannya buruk, dan segalanya berantakan bagi semua orang. Nah, jika terjadi sesuatu yang aneh, para penggiat jejaring juga harus disalahkan. Hanya karena menidurimu, itu sebabnya.
Faktanya, perbedaan utamanya adalah pendekatan terhadap pekerjaan. Mungkin, di kalangan penggiat jejaringlah yang paling banyak mendukung pendekatan “Jika berhasil, jangan sentuh!”. Sebagai aturan, sesuatu dapat dilakukan (dalam satu vendor) hanya dengan satu cara; seluruh konfigurasi kotak ada di telapak tangan Anda. Biaya kesalahannya tinggi, dan terkadang sangat tinggi (misalnya, Anda harus menempuh perjalanan beberapa ratus kilometer untuk me-reboot router, dan saat ini beberapa ribu orang akan kehilangan komunikasi - situasi yang cukup umum bagi operator telekomunikasi) .
Menurut pendapat saya, inilah sebabnya mengapa para insinyur jaringan, di satu sisi, sangat termotivasi untuk stabilitas jaringan (dan perubahan adalah musuh utama stabilitas), dan kedua, pengetahuan mereka lebih mendalam daripada luasnya (Anda tidak melakukannya). harus dapat mengkonfigurasi lusinan daemon yang berbeda, Anda perlu mengetahui teknologi dan implementasinya dari produsen peralatan tertentu). Itu sebabnya administrator sistem yang mencari di Google cara mendaftarkan vlan pada sistem Cisco belum menjadi penggiat jaringan. Dan kecil kemungkinannya dia akan mampu secara efektif mendukung (serta memecahkan masalah) jaringan yang kurang lebih kompleks.
Tetapi mengapa Anda memerlukan networker jika Anda memiliki hoster?
Untuk tambahan uang (dan jika Anda adalah klien yang sangat besar dan dicintai, bahkan mungkin gratis, “sebagai teman”), teknisi pusat data akan mengonfigurasi sakelar Anda agar sesuai dengan kebutuhan Anda, dan bahkan mungkin membantu Anda membangun antarmuka BGP dengan penyedia (jika Anda memiliki subnet alamat IP sendiri untuk pengumuman tersebut).
Masalah utamanya adalah pusat data bukanlah departemen TI Anda, melainkan perusahaan terpisah yang tujuannya adalah menghasilkan keuntungan. Termasuk dengan mengorbankan Anda sebagai klien. Pusat data menyediakan rak, menyediakan listrik dan pendingin, dan juga menyediakan konektivitas “default” ke Internet. Berdasarkan infrastruktur ini, pusat data dapat menampung peralatan Anda (colocation), menyewakan server kepada Anda (dedicated server), atau menyediakan layanan terkelola (misalnya, OpenStack atau K8s). Namun bisnis pusat data (biasanya) bukanlah administrasi infrastruktur klien, karena proses ini cukup padat karya, otomatisasi yang buruk (dan dalam pusat data normal segala sesuatu yang mungkin dilakukan secara otomatis), bahkan lebih buruk lagi (setiap klien bersifat individual) dan umumnya penuh dengan keluhan (“Anda memberi tahu saya bahwa server telah diatur, tetapi sekarang server tersebut mogok, itu semua salah Anda!!!111”). Oleh karena itu, jika host membantu Anda dalam sesuatu, dia akan berusaha membuatnya sesederhana dan senyaman mungkin. Karena melakukan hal yang sulit itu tidak menguntungkan, setidaknya dari sudut pandang biaya tenaga kerja para insinyur dari hoster yang sama ini (tetapi situasinya berbeda, lihat penafian). Ini tidak berarti bahwa hoster akan melakukan semuanya dengan buruk. Namun bukan fakta bahwa dia akan melakukan apa yang sebenarnya Anda butuhkan.
Tampaknya hal ini cukup jelas, tetapi beberapa kali dalam praktik saya, saya menemukan fakta bahwa perusahaan mulai lebih bergantung pada penyedia hosting mereka daripada yang seharusnya, dan ini tidak menghasilkan sesuatu yang baik. Saya harus menjelaskan secara panjang lebar dan rinci bahwa tidak ada satu pun SLA yang akan menanggung kerugian akibat downtime (ada pengecualian, tetapi biasanya sangat, SANGAT mahal untuk klien) dan bahwa hoster sama sekali tidak mengetahui apa yang terjadi di infrastruktur pelanggan (kecuali untuk indikator yang sangat umum). Dan hoster juga tidak membuat cadangan untuk Anda. Situasinya lebih buruk lagi jika Anda memiliki lebih dari satu hoster. Jika ada masalah di antara mereka, mereka pasti tidak akan mencari tahu apa yang salah.
Sebenarnya motif disini sama persis dengan saat memilih “tim admin in-house vs outsourcing”. Kalau risikonya sudah diperhitungkan, kualitasnya memuaskan, dan bisnisnya tidak keberatan, kenapa tidak dicoba. Di sisi lain, jaringan adalah salah satu lapisan infrastruktur paling dasar, dan tidak ada gunanya menyerahkannya kepada pihak luar jika Anda sendiri sudah mendukung semuanya.
Dalam kasus apa seorang penggiat jejaring dibutuhkan?
Selanjutnya kita akan membahas secara khusus tentang perusahaan makanan modern. Dengan operator dan perusahaan, semuanya jelas, plus atau minus - hanya sedikit yang berubah di sana dalam beberapa tahun terakhir, dan penggiat jejaring dibutuhkan di sana sebelumnya, dan mereka dibutuhkan sekarang. Tetapi dengan “muda dan berani” yang sama, hal-hal tersebut tidak begitu jelas. Seringkali mereka menempatkan seluruh infrastrukturnya di cloud, sehingga mereka bahkan tidak terlalu membutuhkan admin - kecuali admin dari cloud yang sama, tentunya. Infrastrukturnya, di satu sisi, desainnya cukup sederhana, di sisi lain, terotomatisasi dengan baik (ansible/puppet, terraform, ci/cd... yah, lho). Tetapi bahkan di sini ada situasi ketika Anda tidak dapat melakukannya tanpa seorang insinyur jaringan.
Contoh 1, klasik
Misalkan sebuah perusahaan memulai dengan satu server dengan alamat IP publik, yang terletak di pusat data. Lalu ada dua server. Lalu lagi... Cepat atau lambat, akan ada kebutuhan akan jaringan pribadi antar server. Karena lalu lintas “eksternal” dibatasi baik oleh bandwidth (misalnya tidak lebih dari 100Mbit/s) dan oleh volume pengunduhan/pengunggahan per bulan (hoster yang berbeda memiliki tarif yang berbeda, namun bandwidth ke dunia luar biasanya jauh lebih mahal daripada jaringan pribadi).
Hoster menambahkan kartu jaringan tambahan ke server dan memasukkannya ke dalam switch mereka di vlan terpisah. Area lokal “datar” muncul di antara server. Nyaman!
Jumlah server bertambah, dan lalu lintas di jaringan pribadi - pencadangan, replikasi, dll. Penghosting menawarkan untuk memindahkan Anda ke sakelar terpisah sehingga Anda tidak mengganggu klien lain, dan mereka tidak mengganggu Anda. Penghosting memasang beberapa sakelar dan mengonfigurasinya - kemungkinan besar, meninggalkan satu jaringan datar di antara semua server Anda. Semuanya berfungsi dengan baik, tetapi pada saat tertentu masalah dimulai: penundaan antar host meningkat secara berkala, log mengeluh tentang terlalu banyak paket arp per detik, dan selama audit, pentester mengacaukan seluruh jaringan lokal Anda, hanya merusak satu server.
Apa yang harus saya lakukan?
Bagilah jaringan menjadi beberapa segmen - vlan. Konfigurasikan pengalamatan Anda sendiri di setiap vlan, pilih gateway yang akan mentransfer lalu lintas antar jaringan. Konfigurasikan acl pada gateway untuk membatasi akses antar segmen, atau bahkan memasang firewall terpisah di dekatnya.
Contoh 1, lanjutan
Server terhubung ke LAN dengan satu kabel. Sakelar di rak entah bagaimana terhubung satu sama lain, tetapi jika terjadi kecelakaan di satu rak, tiga rak lainnya yang berdekatan akan jatuh. Skema memang ada, namun ada keraguan mengenai relevansinya. Setiap server memiliki alamat publiknya sendiri, yang dikeluarkan oleh hoster dan diikat ke rak. Itu. Saat memindahkan server, alamatnya harus diubah.
Apa yang harus saya lakukan?
Hubungkan server menggunakan LAG (Link Aggregation Group) dengan dua kabel ke sakelar di rak (mereka juga harus berlebihan). Cadangan sambungan antar rak, ubah menjadi tipe "bintang" (atau CLOS yang sekarang populer), sehingga hilangnya satu rak tidak mempengaruhi rak lainnya. Pilih rak “pusat” di mana inti jaringan akan ditempatkan dan di mana rak lain akan dihubungkan. Pada saat yang sama, atur pengalamatan publik, ambil subnet dari hoster (atau dari RIR, jika mungkin), yang Anda sendiri (atau melalui hoster) umumkan kepada dunia.
Bisakah semua ini dilakukan oleh administrator sistem “biasa” yang tidak memiliki pengetahuan mendalam tentang jaringan? Tidak yakin. Akankah tuan rumah melakukan ini? Mungkin memang demikian, tetapi Anda memerlukan spesifikasi teknis yang cukup rinci, yang juga perlu dibuat oleh seseorang. dan kemudian periksa apakah semuanya telah dilakukan dengan benar.
Contoh 2: Awan
Misalkan Anda memiliki VPC di cloud publik. Untuk mendapatkan akses dari kantor atau bagian infrastruktur lokal ke jaringan lokal di dalam VPC, Anda perlu mengonfigurasi koneksi melalui IPSec atau saluran khusus. Di satu sisi, IPSec lebih murah karena tidak perlu membeli perangkat keras tambahan; Anda dapat mengatur terowongan antara server Anda dengan alamat publik dan cloud. Namun - penundaan, kinerja terbatas (karena saluran perlu dienkripsi), ditambah konektivitas yang tidak terjamin (karena akses dilakukan melalui Internet biasa).
Apa yang harus saya lakukan?
Tingkatkan koneksi melalui saluran khusus (misalnya, AWS menyebutnya Direct Connect). Untuk melakukan ini, temukan operator mitra yang akan menghubungkan Anda, tentukan titik koneksi yang paling dekat dengan Anda (Anda ke operator dan operator ke cloud), dan, terakhir, atur semuanya. Apakah mungkin melakukan semua ini tanpa teknisi jaringan? Tentunya ya. Namun bagaimana cara memecahkan masalah tanpa dia jika terjadi masalah tidak lagi jelas.
Mungkin juga ada masalah dengan ketersediaan antar cloud (jika Anda memiliki multicloud) atau masalah penundaan antar wilayah, dll. Tentu saja, kini telah banyak bermunculan alat yang meningkatkan transparansi tentang apa yang terjadi di cloud (Seribu Mata yang sama), tetapi ini semua adalah alat seorang insinyur jaringan, dan bukan penggantinya.
Saya dapat membuat sketsa selusin contoh serupa dari praktik saya, tetapi menurut saya jelas bahwa tim, mulai dari tingkat pengembangan infrastruktur tertentu, harus memiliki seseorang (sebaiknya lebih dari satu) yang mengetahui cara kerja jaringan dan dapat mengkonfigurasi peralatan jaringan dan menyelesaikan masalah jika muncul. Percayalah, dia akan melakukan sesuatu
Apa yang harus diketahui oleh seorang penggiat jejaring?
Sama sekali tidak perlu (dan bahkan, terkadang, berbahaya) bagi seorang insinyur jaringan untuk hanya berurusan dengan jaringan dan tidak ada yang lain. Bahkan jika kita tidak mempertimbangkan opsi dengan infrastruktur yang hampir seluruhnya berada di cloud publik (dan, apa pun yang dikatakan orang, infrastruktur ini menjadi semakin populer), dan mengambil, misalnya, cloud lokal atau pribadi, di mana pada “Pengetahuan setingkat CCNP saja” "Anda tidak akan pergi.
Faktanya, selain jaringan - meskipun ada banyak sekali bidang studi, meskipun Anda hanya berkonsentrasi pada satu area (jaringan penyedia, perusahaan, pusat data, Wi-Fi ...)
Tentu saja, banyak dari Anda sekarang akan mengingat Python dan “otomatisasi jaringan” lainnya, tetapi ini hanya suatu keharusan, tetapi bukan kondisi yang cukup. Agar seorang insinyur jaringan “berhasil bergabung dengan tim,” dia harus mampu berbicara dalam bahasa yang sama dengan pengembang dan sesama administrator/pengembang. Apa artinya?
- tidak hanya dapat bekerja di Linux sebagai pengguna, tetapi juga mengelolanya, setidaknya pada tingkat sysadmin-jun: menginstal perangkat lunak yang diperlukan, memulai ulang layanan yang gagal, menulis unit systemd sederhana.
- Memahami (setidaknya secara umum) cara kerja tumpukan jaringan di Linux, cara kerja jaringan di hypervisor dan container (lxc/docker/kubernetes).
- Tentu saja, dapat bekerja dengan sistem SCM yang memungkinkan/koki/boneka atau lainnya.
- Baris terpisah harus ditulis tentang SDN dan jaringan untuk private cloud (misalnya, TungstenFabric atau OpenvSwitch). Ini adalah lapisan pengetahuan yang sangat besar.
Singkatnya, saya menjelaskan tipikal spesialis bentuk T (seperti yang biasa dikatakan sekarang). Sepertinya bukan hal baru, namun berdasarkan pengalaman wawancara, tidak semua network engineer dapat membanggakan pengetahuannya setidaknya pada dua topik dari daftar di atas. Dalam praktiknya, kurangnya pengetahuan “di bidang terkait” membuat sangat sulit tidak hanya untuk berkomunikasi dengan rekan kerja, tetapi juga untuk memahami persyaratan yang diterapkan bisnis pada jaringan, sebagai infrastruktur proyek tingkat terendah. Dan tanpa pemahaman ini, akan lebih sulit untuk mempertahankan sudut pandang Anda dan “menjualnya” ke bisnis.
Di sisi lain, kebiasaan yang sama dalam “memahami cara kerja sistem” memberi para penggiat jejaring sebuah keuntungan yang sangat baik dibandingkan berbagai “generalis” yang mengetahui tentang teknologi dari artikel di Habré/medium dan obrolan di Telegram, namun sama sekali tidak tahu bagaimana caranya. prinsip kerja perangkat lunak ini atau itu? Dan pengetahuan tentang pola-pola tertentu, seperti diketahui, berhasil menggantikan pengetahuan tentang banyak fakta.
Kesimpulan, atau hanya TL;DR
- Administrator jaringan (seperti insinyur DBA atau VoIP) adalah spesialis dengan profil yang agak sempit (tidak seperti administrator sistem/devs/SRE), yang kebutuhannya tidak muncul dengan segera (dan sebenarnya mungkin tidak muncul dalam waktu lama) . Namun jika hal ini benar-benar terjadi, kemungkinan besar hal tersebut tidak akan digantikan oleh keahlian dari luar (outsourcing atau administrator umum biasa, “yang juga menjaga jaringan”). Yang lebih menyedihkan adalah kebutuhan akan spesialis seperti itu kecil, dan, dengan syarat, dalam sebuah perusahaan dengan 800 pemrogram dan 30 pengembang/administrator, mungkin hanya ada dua penggiat jejaring yang melakukan tugasnya dengan sangat baik. Itu. pasarnya dulu dan sekarang sangat, sangat kecil, dan dengan gaji yang bagus - bahkan lebih kecil lagi.
- Di sisi lain, penggiat jejaring yang baik di dunia modern harus mengetahui tidak hanya jaringan itu sendiri (dan cara mengotomatiskan konfigurasinya), tetapi juga bagaimana sistem operasi dan perangkat lunak yang berjalan di atas jaringan ini berinteraksi dengannya. Tanpa hal ini, akan sangat sulit untuk memahami apa yang diminta kolega Anda dari Anda dan untuk menyampaikan (secara wajar) keinginan/kebutuhan Anda kepada mereka.
- Tidak ada cloud, itu hanya komputer orang lain. Anda perlu memahami bahwa menggunakan cloud publik/pribadi atau layanan penyedia hosting “yang melakukan segalanya untuk Anda secara turnkey” tidak mengubah fakta bahwa aplikasi Anda masih menggunakan jaringan, dan masalah dengan jaringan tersebut akan memengaruhi pengoperasian. aplikasi Anda. Pilihan Anda adalah di mana pusat kompetensi akan berlokasi, yang akan bertanggung jawab atas jaringan proyek Anda.
Sumber: www.habr.com