Pada masa menulis artikel ini, carian di tapak kerja popular untuk frasa "Jurutera Rangkaian" mengembalikan kira-kira tiga ratus kekosongan di seluruh Rusia. Sebagai perbandingan, carian untuk frasa "pentadbir sistem" mengembalikan hampir 2.5 ribu kekosongan, dan "jurutera DevOps" - hampir 800.
Adakah ini bermakna bahawa perangkaian tidak lagi diperlukan pada masa awan yang menang, Docker, Kubernetes dan Wi-Fi awam di mana-mana?
Mari kita fikirkan (c)
Jom berkenalan. Nama saya Alexey, dan saya seorang networker.
Saya telah terlibat dalam rangkaian selama lebih daripada 10 tahun dan telah bekerja dengan pelbagai sistem *nix selama lebih daripada 15 tahun (saya mempunyai peluang untuk bermain-main dengan kedua-dua Linux dan FreeBSD). Saya bekerja di operator telekomunikasi, syarikat besar yang dianggap sebagai "perusahaan", dan baru-baru ini saya telah bekerja dalam fintech "muda dan berani", di mana awan, devops, kubernetes dan perkataan menakutkan lain yang pasti akan menjadikan saya dan rakan sekerja saya tidak perlu. . Suatu hari nanti. Mungkin.
penafian: "Dalam hidup kita, tidak semuanya sentiasa dan di mana-mana, tetapi sesuatu, kadang-kadang di tempat" (c) Maxim Dorofeev.
Semua yang ditulis di bawah boleh dan harus dianggap sebagai pendapat peribadi pengarang, yang tidak mendakwa sebagai kebenaran muktamad, malah kajian sepenuhnya. Semua watak adalah rekaan, semua kebetulan adalah rawak.
Selamat datang ke dunia saya.
Di mana anda boleh bertemu dengan networkers?
1. Pengendali telekomunikasi, syarikat perkhidmatan dan penyepadu lain. Segala-galanya mudah di sini: rangkaian untuk mereka adalah perniagaan. Mereka sama ada secara langsung menjual sambungan (pengendali) atau menyediakan perkhidmatan untuk melancarkan/mengekalkan rangkaian pelanggan mereka.
Terdapat banyak pengalaman di sini, tetapi tidak banyak wang (melainkan anda seorang pengarah atau pengurus jualan yang berjaya). Namun, jika anda menyukai rangkaian, dan anda baru di permulaan perjalanan anda, kerjaya yang menyokong beberapa pengendali yang tidak terlalu besar akan, walaupun sekarang, menjadi titik permulaan yang ideal (di persekutuan semuanya sangat skrip, dan ada adalah sedikit ruang untuk kreativiti). Nah, cerita tentang bagaimana anda boleh berkembang daripada jurutera yang bertugas dalam beberapa tahun kepada pengurus peringkat C juga agak nyata, walaupun jarang berlaku, atas sebab-sebab yang jelas. Sentiasa ada keperluan untuk kakitangan, kerana pusing ganti memang berlaku. Ini adalah baik dan buruk pada masa yang sama - sentiasa ada kekosongan, sebaliknya - selalunya yang paling aktif/pintar cepat pergi sama ada untuk promosi atau ke tempat lain yang "lebih panas".
2. “perusahaan” bersyarat. Tidak kira aktiviti utamanya berkaitan dengan IT atau tidak. Perkara utama ialah ia mempunyai jabatan IT sendiri, yang memastikan operasi sistem dalaman syarikat, termasuk rangkaian di pejabat, saluran komunikasi ke cawangan, dll. Fungsi jurutera rangkaian dalam syarikat sedemikian boleh dilakukan "sambilan" oleh pentadbir sistem (jika infrastruktur rangkaian kecil atau dikendalikan oleh kontraktor luar), dan pakar rangkaian, jika ada, boleh di masa yang sama menjaga telefon dan SAN (tidak baik). Mereka membayar secara berbeza - ia sangat bergantung pada keuntungan perniagaan, saiz syarikat dan struktur. Saya bekerja dengan syarikat di mana sistem Cisco kerap "dimuatkan dalam tong", dan dengan syarikat di mana rangkaian dibina daripada najis, kayu dan pita biru, dan pelayan tidak pernah dikemas kini (tidak perlu dikatakan, tiada rizab juga disediakan) . Terdapat lebih sedikit pengalaman di sini, dan hampir pasti akan berada di kawasan kunci vendor yang ketat, atau "cara membuat sesuatu daripada tiada." Secara peribadi, saya mendapati ia sangat membosankan, walaupun ramai yang menyukainya - semuanya agak terukur dan boleh diramal (jika kita bercakap tentang syarikat besar), "dorakha-bahato", dll. Sekurang-kurangnya sekali setahun, beberapa vendor utama mengatakan bahawa mereka telah menghasilkan satu lagi sistem mega-super-duper yang akan mengautomasikan segala-galanya sekarang dan semua pentadbir sistem dan rangkaian boleh tersebar, meninggalkan pasangan untuk menekan butang dalam antara muka yang cantik. Realitinya ialah, walaupun kita mengabaikan kos penyelesaian, rangkaian tidak akan pergi ke mana-mana dari sana. Ya, mungkin bukannya konsol akan ada lagi antara muka web (tetapi bukan sekeping perkakasan tertentu, tetapi sistem besar yang menguruskan puluhan dan ratusan perkakasan sedemikian), tetapi pengetahuan tentang "bagaimana semuanya berfungsi di dalam" akan tetap diperlukan.
3. Syarikat produk, yang keuntungannya datang daripada pembangunan (dan, selalunya, operasi) beberapa perisian atau platform - produk yang sama itu. Biasanya mereka kecil dan lincah, mereka masih jauh dari skala perusahaan dan birokratisasi mereka. Di sinilah devops yang sama, cubers, dockers dan perkataan-perkataan mengerikan lain ditemui secara beramai-ramai, yang pastinya akan menjadikan rangkaian dan jurutera rangkaian sebagai asas yang tidak perlu.
Bagaimanakah perangkaian berbeza daripada pentadbir sistem?
Dalam pemahaman orang bukan dari IT - tiada apa-apa. Kedua-duanya melihat skrin hitam dan menulis beberapa jampi, kadang-kadang secara senyap-senyap mengumpat.
Dalam pemahaman pengaturcara - mungkin mengikut kawasan subjek. Pentadbir sistem mentadbir pelayan, perangkaian mentadbir suis dan penghala. Kadang-kadang pentadbiran tidak baik, dan semuanya berantakan untuk semua orang. Nah, sekiranya berlaku sesuatu yang pelik, rangkaian juga harus dipersalahkan. Hanya kerana meniduri awak, itulah sebabnya.
Malah, perbezaan utama adalah pendekatan untuk bekerja. Mungkin, di kalangan rangkaian terdapat kebanyakan penyokong pendekatan "Jika ia berkesan, jangan sentuh!". Sebagai peraturan, sesuatu boleh dilakukan (dalam satu vendor) hanya dengan satu cara; keseluruhan konfigurasi kotak ada di tapak tangan anda. Kos ralat adalah tinggi, dan kadang-kadang sangat tinggi (contohnya, anda perlu melakukan perjalanan beberapa ratus kilometer untuk but semula penghala, dan pada masa ini beberapa ribu orang akan kehilangan komunikasi - situasi yang agak biasa bagi pengendali telekomunikasi) .
Pada pendapat saya, inilah sebabnya jurutera rangkaian, di satu pihak, sangat bermotivasi untuk kestabilan rangkaian (dan perubahan adalah musuh utama kestabilan), dan kedua, pengetahuan mereka lebih mendalam daripada luasnya (anda tidak perlu dapat mengkonfigurasi berpuluh-puluh daemon yang berbeza, anda perlu mengetahui teknologi dan pelaksanaannya daripada pengeluar peralatan tertentu). Itulah sebabnya pentadbir sistem yang mencari google cara mendaftar vlan pada sistem Cisco belum lagi menjadi rangkaian. Dan tidak mungkin dia akan dapat menyokong (serta menyelesaikan masalah) rangkaian yang lebih atau kurang kompleks dengan berkesan.
Tetapi mengapa anda memerlukan networker jika anda mempunyai hoster?
Untuk wang tambahan (dan jika anda pelanggan yang sangat besar dan disayangi, mungkin juga secara percuma, "sebagai kawan"), jurutera pusat data akan mengkonfigurasi suis anda untuk memenuhi keperluan anda, dan mungkin juga membantu anda mewujudkan antara muka BGP dengan pembekal (jika anda mempunyai subnet alamat IP anda sendiri untuk pengumuman itu).
Masalah utama ialah pusat data bukan jabatan IT anda, ia adalah syarikat berasingan yang matlamatnya adalah untuk membuat keuntungan. Termasuk dengan mengorbankan anda sebagai pelanggan. Pusat data menyediakan rak, menyediakannya dengan elektrik dan sejuk, dan juga menyediakan beberapa sambungan "lalai" ke Internet. Berdasarkan infrastruktur ini, pusat data boleh mengehoskan peralatan anda (colocation), menyewakan pelayan kepada anda (pelayan khusus) atau menyediakan perkhidmatan terurus (contohnya, OpenStack atau K8s). Tetapi perniagaan pusat data (biasanya) bukanlah pentadbiran infrastruktur pelanggan, kerana proses ini agak intensif buruh, kurang automatik (dan dalam pusat data biasa semua yang mungkin adalah automatik), bersatu lebih teruk lagi (setiap pelanggan adalah individu) dan secara amnya penuh dengan aduan (“anda beritahu saya pelayan telah disediakan, tetapi kini ia telah ranap, ini semua salah anda!!!111”). Oleh itu, jika hoster membantu anda dengan sesuatu, dia akan cuba menjadikannya semudah dan semudah mungkin. Kerana melakukannya sukar adalah tidak menguntungkan, sekurang-kurangnya dari sudut pandangan kos buruh jurutera hoster yang sama ini (tetapi situasi berbeza, lihat penafian). Ini tidak bermakna bahawa hoster semestinya akan melakukan segala-galanya dengan teruk. Tetapi ia sama sekali bukan fakta bahawa dia akan melakukan apa yang anda perlukan.
Nampaknya perkara itu agak jelas, tetapi beberapa kali dalam amalan saya, saya telah menemui fakta bahawa syarikat mula bergantung pada penyedia pengehosan mereka lebih sedikit daripada yang sepatutnya, dan ini tidak membawa kepada apa-apa yang baik. Saya terpaksa menerangkan dengan panjang lebar dan terperinci bahawa tidak ada satu SLA yang akan menampung kerugian daripada masa henti (terdapat pengecualian, tetapi biasanya ia sangat, SANGAT mahal untuk pelanggan) dan bahawa hoster tidak mengetahui sama sekali tentang apa yang berlaku dalam infrastruktur pelanggan (kecuali penunjuk yang sangat umum). Dan hoster juga tidak membuat sandaran untuk anda. Keadaan lebih teruk jika anda mempunyai lebih daripada satu hoster. Sekiranya berlaku sebarang masalah di antara mereka, mereka pasti tidak akan mengetahui untuk anda apa yang salah.
Sebenarnya, motif di sini adalah sama seperti semasa memilih "pasukan pentadbir dalaman vs sumber luar". Jika risiko dikira, kualitinya memuaskan, dan perniagaan tidak kisah, mengapa tidak mencubanya. Sebaliknya, rangkaian adalah salah satu lapisan infrastruktur yang paling asas, dan tidak berbaloi untuk menyerahkannya kepada orang luar jika anda sudah menyokong segala-galanya sendiri.
Dalam kes apakah rangkaian diperlukan?
Seterusnya kita akan bercakap secara khusus mengenai syarikat makanan moden. Dengan pengendali dan perusahaan, semuanya jelas, tambah atau tolak - sedikit yang berubah di sana dalam beberapa tahun kebelakangan ini, dan rangkaian diperlukan sebelum ini, dan mereka diperlukan sekarang. Tetapi dengan perkara "muda dan berani" yang sama itu tidak begitu jelas. Selalunya mereka meletakkan keseluruhan infrastruktur mereka di awan, jadi mereka tidak memerlukan pentadbir - kecuali pentadbir awan yang sama, sudah tentu. Infrastruktur, dalam satu tangan, agak mudah dalam reka bentuknya, sebaliknya, ia automatik dengan baik (ansible/puppet, terraform, ci/cd... well, you know). Tetapi di sini terdapat situasi apabila anda tidak boleh melakukannya tanpa jurutera rangkaian.
Contoh 1, klasik
Katakan sebuah syarikat bermula dengan satu pelayan dengan alamat IP awam, yang terletak di pusat data. Kemudian terdapat dua pelayan. Kemudian lagi... Lambat laun, akan ada keperluan untuk rangkaian peribadi antara pelayan. Kerana trafik "luaran" dihadkan oleh kedua-dua jalur lebar (tidak lebih daripada 100Mbit/s sebagai contoh) dan dengan jumlah muat turun/muat naik setiap bulan (hoster yang berbeza mempunyai tarif yang berbeza, tetapi lebar jalur ke dunia luar biasanya jauh lebih mahal daripada rangkaian persendirian).
Hoster menambah kad rangkaian tambahan kepada pelayan dan memasukkannya ke dalam suis mereka dalam vlan yang berasingan. Kawasan setempat "rata" muncul di antara pelayan. Selesa!
Bilangan pelayan semakin meningkat, dan trafik pada rangkaian persendirian juga semakin meningkat - sandaran, replikasi, dsb. Hoster menawarkan untuk memindahkan anda ke suis berasingan supaya anda tidak mengganggu pelanggan lain, dan mereka tidak mengganggu anda. Hoster memasang beberapa suis dan entah bagaimana mengkonfigurasinya - kemungkinan besar, meninggalkan satu rangkaian rata antara semua pelayan anda. Semuanya berfungsi dengan baik, tetapi pada masa tertentu masalah bermula: kelewatan antara hos meningkat secara berkala, log mengadu tentang terlalu banyak paket arp sesaat, dan semasa audit, pentester meniduri seluruh rangkaian tempatan anda, hanya memecahkan satu pelayan.
Apa yang perlu saya lakukan?
Bahagikan rangkaian kepada segmen - vlan. Konfigurasikan pengalamatan anda sendiri dalam setiap vlan, pilih get laluan yang akan memindahkan trafik antara rangkaian. Konfigurasikan acl pada get laluan untuk mengehadkan akses antara segmen, atau malah memasang tembok api berasingan berdekatan.
Contoh 1, bersambung
Pelayan disambungkan ke LAN dengan satu kord. Suis dalam rak entah bagaimana disambungkan antara satu sama lain, tetapi jika berlaku kemalangan dalam satu rak, tiga lagi yang bersebelahan akan jatuh. Skim wujud, tetapi terdapat keraguan tentang kaitannya. Setiap pelayan mempunyai alamat awam sendiri, yang dikeluarkan oleh hoster dan terikat pada rak. Itu. Apabila memindahkan pelayan, alamat perlu ditukar.
Apa yang perlu saya lakukan?
Sambungkan pelayan menggunakan LAG (Kumpulan Pengagregatan Pautan) dengan dua kord ke suis dalam rak (ia juga perlu berlebihan). Simpan sambungan antara rak dan tukarkannya kepada "bintang" (atau CLOS yang kini bergaya) supaya kehilangan satu rak tidak menjejaskan yang lain. Pilih rak "pusat" di mana teras rangkaian akan ditempatkan dan tempat rak lain akan disambungkan. Pada masa yang sama, susun alamat awam, ambil dari hoster (atau dari RIR, jika boleh) subnet, yang anda sendiri (atau melalui hoster) umumkan kepada dunia.
Bolehkah semua ini dilakukan oleh pentadbir sistem "biasa" yang tidak mempunyai pengetahuan mendalam tentang rangkaian? Tidak pasti. Adakah tuan rumah akan melakukan ini? Mungkin ia akan berlaku, tetapi anda memerlukan spesifikasi teknikal yang agak terperinci, yang juga perlu dibuat oleh seseorang. dan kemudian semak bahawa semuanya dilakukan dengan betul.
Contoh 2: Awan
Katakan anda mempunyai VPC dalam sesetengah awan awam. Untuk mendapatkan akses daripada pejabat atau bahagian prasarana kepada rangkaian tempatan di dalam VPC, anda perlu mengkonfigurasi sambungan melalui IPSec atau saluran khusus. Di satu pihak, IPSec lebih murah, kerana tidak perlu membeli perkakasan tambahan; anda boleh menyediakan terowong antara pelayan anda dengan alamat awam dan awan. Tetapi - kelewatan, prestasi terhad (memandangkan saluran perlu disulitkan), serta sambungan tidak terjamin (kerana akses adalah melalui Internet biasa).
Apa yang perlu saya lakukan?
Tingkatkan sambungan melalui saluran khusus (contohnya, AWS memanggilnya Direct Connect). Untuk melakukan ini, cari operator rakan kongsi yang akan menghubungkan anda, tentukan titik sambungan yang paling dekat dengan anda (kedua-dua anda kepada pengendali dan pengendali ke awan), dan, akhirnya, sediakan semuanya. Adakah mungkin untuk melakukan semua ini tanpa jurutera rangkaian? Pasti ya. Tetapi bagaimana untuk menyelesaikan masalah tanpa dia sekiranya berlaku masalah tidak lagi begitu jelas.
Mungkin juga terdapat masalah dengan ketersediaan antara awan (jika anda mempunyai awan berbilang) atau masalah kelewatan antara wilayah yang berbeza, dsb. Sudah tentu, kini banyak alat telah muncul yang meningkatkan ketelusan apa yang berlaku di awan (Seribu Mata yang sama), tetapi ini semua adalah alat jurutera rangkaian, dan bukan penggantinya.
Saya boleh melakar sedozen lagi contoh sedemikian daripada amalan saya, tetapi saya rasa jelas bahawa pasukan itu, bermula dari tahap pembangunan infrastruktur tertentu, mesti mempunyai seseorang (sebaik-baiknya lebih daripada satu) yang mengetahui cara rangkaian berfungsi dan boleh mengkonfigurasi peralatan rangkaian dan menyelesaikan masalah jika ia timbul. Percayalah, dia akan mempunyai sesuatu untuk dilakukan
Apa yang perlu diketahui oleh seorang networker?
Ia sama sekali tidak perlu (malah, kadangkala, berbahaya) bagi seorang jurutera rangkaian untuk berurusan hanya dengan rangkaian dan tiada apa-apa lagi. Walaupun kita tidak mempertimbangkan pilihan dengan infrastruktur yang hidup hampir keseluruhannya dalam awan awam (dan, apa pun yang boleh dikatakan, ia menjadi semakin popular), dan mengambil, sebagai contoh, di premis atau awan peribadi, di mana pada “Pengetahuan peringkat CCNP sahaja” "Anda tidak akan pergi.
Di samping itu, sebenarnya, rangkaian - walaupun terdapat medan yang tidak berkesudahan untuk belajar, walaupun anda hanya menumpukan pada satu kawasan (rangkaian pembekal, perusahaan, pusat data, Wi-Fi ...)
Sudah tentu, ramai di antara anda kini akan mengingati Python dan "automasi rangkaian" lain, tetapi ini hanya perlu, tetapi bukan syarat yang mencukupi. Untuk membolehkan jurutera rangkaian "berjaya menyertai pasukan", dia mesti boleh bercakap bahasa yang sama dengan pembangun dan rakan pentadbir/pembangunan. Apakah maksudnya?
- boleh bukan sahaja bekerja di Linux sebagai pengguna, tetapi juga untuk mentadbirnya, sekurang-kurangnya pada tahap sysadmin-jun: pasang perisian yang diperlukan, mulakan semula perkhidmatan yang gagal, tulis unit sistemd yang mudah.
- Fahami (sekurang-kurangnya dalam istilah umum) bagaimana susunan rangkaian berfungsi dalam Linux, cara rangkaian berfungsi dalam hipervisor dan bekas (lxc / docker / kubernetes).
- Sudah tentu, boleh bekerja dengan ansible/chef/puppet atau sistem SCM yang lain.
- Baris berasingan harus ditulis tentang SDN dan rangkaian untuk awan peribadi (contohnya, TungstenFabric atau OpenvSwitch). Ini adalah satu lagi lapisan pengetahuan yang besar.
Ringkasnya, saya menerangkan pakar bentuk T yang tipikal (seperti yang biasa dikatakan sekarang). Nampaknya seperti tiada yang baharu, tetapi berdasarkan pengalaman temu duga, tidak semua jurutera rangkaian boleh berbangga dengan pengetahuan sekurang-kurangnya dua topik daripada senarai di atas. Dalam amalan, kekurangan pengetahuan "dalam bidang berkaitan" menjadikannya sangat sukar bukan sahaja untuk berkomunikasi dengan rakan sekerja, tetapi juga untuk memahami keperluan yang diletakkan oleh perniagaan pada rangkaian, sebagai infrastruktur peringkat terendah projek. Dan tanpa pemahaman ini, ia menjadi lebih sukar untuk mempertahankan pandangan anda dan "menjual"nya kepada perniagaan.
Sebaliknya, tabiat yang sama untuk "memahami cara sistem berfungsi" memberikan rangkaian kelebihan yang sangat baik berbanding pelbagai "generalis" yang mengetahui tentang teknologi daripada artikel di Habré/medium dan sembang di Telegram, tetapi tidak tahu sama sekali bagaimana untuk melakukannya. prinsip adakah perisian ini atau itu berfungsi? Dan pengetahuan tentang corak tertentu, seperti yang diketahui, berjaya menggantikan pengetahuan tentang banyak fakta.
Kesimpulan, atau hanya TL;DR
- Pentadbir rangkaian (seperti jurutera DBA atau VoIP) ialah pakar dengan profil yang agak sempit (tidak seperti pentadbir sistem/devs/SRE), keperluan yang tidak timbul serta-merta (dan mungkin tidak timbul untuk masa yang lama, sebenarnya) . Tetapi jika ia timbul, ia tidak mungkin digantikan oleh kepakaran luar (sumber luar atau pentadbir tujuan am biasa, "yang turut menjaga rangkaian"). Apa yang lebih menyedihkan ialah keperluan untuk pakar sedemikian adalah kecil, dan, dengan syarat, dalam sebuah syarikat dengan 800 pengaturcara dan 30 devops/pentadbir, mungkin terdapat hanya dua networker yang menjalankan tugas dengan cemerlang dengan tanggungjawab mereka. Itu. pasaran adalah dan sangat, sangat kecil, dan dengan gaji yang baik - malah kurang.
- Sebaliknya, perangkaian yang baik dalam dunia moden mesti mengetahui bukan sahaja rangkaian itu sendiri (dan cara mengautomasikan konfigurasinya), tetapi juga bagaimana sistem pengendalian dan perisian yang berjalan di atas rangkaian ini berinteraksi dengannya. Tanpa ini, amat sukar untuk memahami apa yang diminta oleh rakan sekerja anda daripada anda dan menyampaikan (secara munasabah) kehendak/keperluan anda kepada mereka.
- Tiada awan, ia hanya komputer orang lain. Anda perlu memahami bahawa menggunakan awan awam/swasta atau perkhidmatan penyedia pengehosan "yang melakukan segala-galanya untuk anda secara turnkey" tidak mengubah fakta bahawa aplikasi anda masih menggunakan rangkaian, dan masalah dengannya akan menjejaskan operasi permohonan anda. Pilihan anda ialah di mana pusat kecekapan akan ditempatkan, yang akan bertanggungjawab untuk rangkaian projek anda.
Sumber: www.habr.com