ქსელურები (არ არის საჭირო).

ამ წერის დროს, პოპულარულ სამუშაო საიტზე ძიებამ ფრაზა "ქსელის ინჟინერი" გამოავლინა სამასამდე ვაკანსიაზე მთელ რუსეთში. შედარებისთვის, ფრაზის „სისტემის ადმინისტრატორი“ ძიება აბრუნებს თითქმის 2.5 ათას ვაკანსიას, ხოლო „DevOps ინჟინერი“ - თითქმის 800.

ნიშნავს თუ არა ეს, რომ ქსელის დამხმარეები აღარ არიან საჭირო გამარჯვებული ღრუბლების, დოკერის, კუბერნეტის და ყველგან გავრცელებული საჯარო Wi-Fi-ის დღეებში?
მოდით გავარკვიოთ (s)

Მოდით გავეცნოთ. მე მქვია ალექსეი და მე ვარ ქსელური.

მე 10 წელზე მეტია ვმუშაობ ქსელში და ვმუშაობ სხვადასხვა *nix სისტემებთან 15 წელზე მეტი ხნის განმავლობაში (მე მქონდა შანსი ავირჩიო Linux და FreeBSD). ვმუშაობდი ტელეკომის ოპერატორებში, მსხვილ კომპანიებში, რომლებიც ითვლებიან „საწარმოებად“, ბოლო დროს კი ვმუშაობ „ახალგაზრდა და გაბედულ“ ფინტექში, სადაც ღრუბლები, დევოპები, კუბერნეტები და სხვა საშინელი სიტყვები, რომლებიც აუცილებლად გაგაქცევს მე და ჩემს კოლეგებს. არასაჭირო. ერთ დღეს. Შესაძლოა.

უარი პასუხისმგებლობაზე: ”ჩვენს ცხოვრებაში, არა ყველაფერი, ყოველთვის და ყველგან, მაგრამ რაღაც, ზოგჯერ ადგილებში” (გ) მაქსიმ დოროფეევი.

ყველაფერი, რაც ქვემოთ არის დაწერილი, შეიძლება და უნდა ჩაითვალოს ავტორის პირად მოსაზრებად, არ იყოს პრეტენზია საბოლოო ჭეშმარიტებაზე და თუნდაც სრულფასოვან კვლევად. ყველა პერსონაჟი ფიქტიურია, ყველა დამთხვევა შემთხვევითია.

კეთილი იყოს თქვენი მობრძანება ჩემს სამყაროში.

სად შეგიძლიათ იპოვოთ ქსელის დამფუძნებლები?

1. ტელეკომის ოპერატორები, მომსახურების კომპანიები და სხვა ინტეგრატორები. ყველაფერი მარტივია: მათთვის ქსელი ბიზნესია. ისინი ან პირდაპირ ყიდიან დაკავშირებას (ოპერატორებს) ან უზრუნველყოფენ მომსახურებას მათი მომხმარებლების ქსელების გაშვებისთვის/შენარჩუნებისთვის.

აქ არის დიდი გამოცდილება, მაგრამ არც ისე ბევრი ფული (თუ არ ხართ დირექტორი ან წარმატებული გაყიდვების მენეჯერი). და მაინც, თუ მოგწონთ ქსელები და მხოლოდ თქვენი მოგზაურობის დასაწყისში ხართ, ზოგიერთი არც თუ ისე დიდი ოპერატორის მხარდაჭერის კარიერა იდეალური საწყისი წერტილი იქნება ახლაც (ფედერალურებში ყველაფერი ძალიან დაწერილია და იქ მცირე ადგილია შემოქმედებისთვის). ისე, ისტორიები იმის შესახებ, რომ შესაძლებელია რამდენიმე წელიწადში მორიგე ინჟინრიდან C- დონის მენეჯერად გადაქცევა, ასევე საკმაოდ რეალურია, თუმცა იშვიათია, გასაგები მიზეზების გამო. კადრების საჭიროება ყოველთვის არის, რადგან ჯერ კიდევ არის ბრუნვა. ეს ერთდროულად კარგიცაა და ცუდიც - ყოველთვის არის ვაკანსიები, მეორე მხრივ - ხშირად ყველაზე აქტიურები/ჭკვიანები საკმაოდ სწრაფად ან დაწინაურდებიან ან სხვა, "თბილ" ადგილებში მიდიან.

2. პირობითი „საწარმო“. არ აქვს მნიშვნელობა მისი ძირითადი საქმიანობა IT-თან არის დაკავშირებული თუ არა. მთავარი ის არის, რომ მას აქვს საკუთარი IT დეპარტამენტი, რომელიც ეწევა კომპანიის შიდა სისტემების ფუნქციონირების უზრუნველყოფას, მათ შორის ოფისებში ქსელების, ფილიალების საკომუნიკაციო არხების და ა.შ. ქსელის ინჟინრის ფუნქციები ასეთ კომპანიებში შეიძლება იყოს "ნახევარ განაკვეთზე" შეასრულოს სისტემის ადმინისტრატორმა (თუ ქსელის ინფრასტრუქტურა მცირეა, ან მასში გარე კონტრაქტორია დაკავებული), ხოლო ქსელის მენეჯერს, თუ ის ჯერ კიდევ არსებობს, შეუძლია იზრუნეთ ტელეფონზე და SAN-ზე ერთდროულად (არა ნუაჩო). ისინი იხდიან სხვადასხვა გზით - ეს დიდად არის დამოკიდებული ბიზნესის ზღვარზე, კომპანიის ზომაზე და სტრუქტურაზე. ვმუშაობდი როგორც კომპანიებთან, სადაც ცისკოები რეგულარულად „იტვირთებოდა კასრებში“, ასევე კომპანიებთან, სადაც ქსელი აშენებული იყო განავლით, ჯოხებით და ლურჯი ელექტრო ლენტით და სერვერები არ განახლებულა, დაახლოებით, არასდროს (აუცილებელია ითქვას, რომ იქ არც რეზერვები იყო). აქ გაცილებით ნაკლები გამოცდილებაა და ეს თითქმის აუცილებლად იქნება მყარი გამყიდველის საკეტის არეალში, ან „როგორ გავაკეთო რამე არაფრისგან“. პირადად მე იქ საშინლად მოსაწყენი მეჩვენა, თუმცა ბევრს მოსწონს - ყველაფერი საკმაოდ გაზომილი და პროგნოზირებადია (თუ ვსაუბრობთ დიდ კომპანიებზე), "დორა-ბაჯატო" და ა.შ. წელიწადში ერთხელ მაინც, ზოგიერთი მსხვილი გამყიდველი ამბობს, რომ მათ შექმნეს კიდევ ერთი მეგა-სუპერ-დუპერ სისტემა, რომელიც ავტომატიზირებს ყველაფერს ახლა და ყველა სისტემის ადმინისტრატორისა და ქსელის შემქმნელის გადატვირთვა შესაძლებელია, რაც წყვილს უტოვებს ღილაკების დაჭერას ლამაზ ინტერფეისში. რეალობა ისაა, რომ გადაწყვეტის ღირებულების უგულებელყოფის შემთხვევაშიც კი, ქსელის თანამშრომლები იქიდან არსად წავლენ. დიახ, შესაძლებელია, რომ კონსოლის ნაცვლად კვლავ იყოს ვებ ინტერფეისი (მაგრამ არა რკინის კონკრეტული ნაჭერი, არამედ დიდი სისტემა, რომელიც მართავს ათეულ და ასეულ რკინას), მაგრამ ცოდნა იმის შესახებ, თუ როგორ მუშაობს ყველაფერი შიგნით. ” მაინც საჭირო იქნება.

3. პროდუქციის კომპანიები, რომლის მოგებაც მოდის გარკვეული პროგრამული უზრუნველყოფის ან პლატფორმის შემუშავებიდან (და ხშირად ფუნქციონირებიდან) - სწორედ ეს პროდუქტი. როგორც წესი, ისინი პატარები და მოხერხებულები არიან, ისინი ჯერ კიდევ შორს არიან საწარმოების მასშტაბისგან და მათი ბიუროკრატიზაციისგან. სწორედ აქ გვხვდება იგივე დევოპები, კუბერები, დოკერები და სხვა საშინელი სიტყვები დიდი რაოდენობით, რაც აუცილებლად გახდის ქსელს და ქსელის ინჟინრებს არასაჭირო რუდიმენტად.

რით განსხვავდება ქსელის მენეჯერი sysadmin-ისგან?

ხალხის გაგებით არა IT - არაფერი. ორივე შავ ეკრანს უყურებს და რაღაც შელოცვებს წერს, ხანდახან რბილად აგინებს.

პროგრამისტების გაგებაში - ალბათ საგნობრივი სფერო. Sysadmins ადმინისტრირებას უწევენ სერვერებს, ქსელის თანამშრომლები ახორციელებენ გადამრთველებსა და მარშრუტიზატორებს. ხანდახან ადმინი ცუდია და ყველასთვის ყველაფერი ძირს უთხრის. ჰოდა, რაიმე უცნაურობის შემთხვევაში, ქსელის თანამშრომლებიც არიან დამნაშავე. მხოლოდ იმიტომ, რომ გაგიჟდი, ამიტომ.

სინამდვილეში, მთავარი განსხვავება მუშაობისადმი მიდგომაა. შესაძლოა, სწორედ ქსელურებს შორისაა, რომ ყველაზე მეტად არიან მიდგომის მხარდამჭერები „მუშაობს - არ შეეხოთ მას!“. თქვენ ჩვეულებრივ შეგიძლიათ გააკეთოთ რაღაც (ერთი გამყიდველის ფარგლებში) მხოლოდ ერთი გზით, ყუთის მთელი კონფიგურაცია - აქ არის ის, ხელის გულზე. შეცდომის ღირებულება მაღალია და ზოგჯერ ძალიან მაღალი (მაგალითად, თქვენ უნდა გაიაროთ რამდენიმე ასეული კილომეტრი როუტერის გადატვირთვისთვის და ამ დროს რამდენიმე ათასი ადამიანი დარჩება კომუნიკაციის გარეშე - სიტუაცია, რომელიც საკმაოდ გავრცელებულია ტელეკომის ოპერატორისთვის. ).

ჩემი აზრით, ამიტომაცაა, რომ ქსელის ინჟინრები, ერთის მხრივ, უკიდურესად მოტივირებულნი არიან ქსელის სტაბილურობისთვის (და ცვლილებები სტაბილურობის მთავარი მტერია) და მეორეც, მათი ცოდნა უფრო ღრმაა, ვიდრე სიგანეში (თქვენ არ გჭირდებათ იმისათვის, რომ შეძლოთ ათობით სხვადასხვა დემონის კონფიგურაცია, თქვენ უნდა იცოდეთ ტექნოლოგიები და მათი განხორციელება კონკრეტული აღჭურვილობის მწარმოებლისგან). ამიტომ სისტემის ადმინისტრატორი, რომელიც გუგლში ეძებდა როგორ დაარეგისტრირო vlan ცისკაზე, ჯერ არ არის ქსელის მენეჯერი. და ნაკლებად სავარაუდოა, რომ მან შეძლოს მეტ-ნაკლებად რთული ქსელის ეფექტურად მხარდაჭერა (ასევე პრობლემების მოგვარება).

მაგრამ რატომ გჭირდებათ ქსელის მენეჯერი, თუ თქვენ გაქვთ ჰოსტერი?

დამატებითი ფულისთვის (და თუ ძალიან დიდი და საყვარელი კლიენტი ხართ, შესაძლოა უფასოდაც, „როგორც მეგობარი“), მონაცემთა ცენტრის ინჟინრები დააკონფიგურირებენ თქვენს კონცენტრატორებს თქვენს საჭიროებებზე და, შესაძლოა, დაგეხმარონ BGP ინტერფეისის ამაღლებაშიც. პროვაიდერებთან (თუ გაქვთ თქვენი ip მისამართების ქვექსელი, რომ გამოაცხადოთ).

მთავარი პრობლემა ის არის, რომ მონაცემთა ცენტრი არ არის თქვენი IT დეპარტამენტი, ეს არის ცალკე კომპანია, რომლის მიზანიც მოგების მიღებაა. მათ შორის თქვენი, როგორც კლიენტის ხარჯზე. მონაცემთა ცენტრი უზრუნველყოფს თაროებს, უზრუნველყოფს მათ ელექტროენერგიით და სიცივით და ასევე აძლევს გარკვეულ "ნაგულისხმევ" კავშირს ინტერნეტთან. ამ ინფრასტრუქტურაზე დაყრდნობით, მონაცემთა ცენტრს შეუძლია თქვენი აღჭურვილობის ერთობლივი განთავსება (კოლოკაცია), დაგიქირავოთ სერვერი (გამოყოფილი სერვერი) ან მოგაწოდოთ მართული სერვისი (მაგალითად, OpenStack ან K8s). მაგრამ მონაცემთა ცენტრის ბიზნესი (ჩვეულებრივ) არ არის მომხმარებელთა ინფრასტრუქტურის ადმინისტრირება, რადგან ეს პროცესი საკმაოდ შრომატევადი, ცუდად ავტომატიზირებულია (და ნორმალურ მონაცემთა ცენტრში ყველაფერი ავტომატიზირებულია), ერთიანი, კიდევ უარესი (თითოეული კლიენტი ინდივიდუალურია) და ზოგადად სავსეა პრეტენზიებით („თქვენ მეუბნებით, რომ სერვერი დაყენებულია და ახლა ის გაფუჭდა, ეს ყველაფერი თქვენი ბრალია!!!111“). ამიტომ, თუ მასტერი დაგეხმარება რამეში, მაშინ ის შეეცდება რაც შეიძლება მარტივი და „კონდო“ გახადოს. ამის გაკეთება ძნელია - წამგებიანი, ყოველ შემთხვევაში, სწორედ ამ ჰოსტერის ინჟინრების შრომის ხარჯების თვალსაზრისით (მაგრამ სიტუაციები განსხვავებულია, იხილეთ პასუხისმგებლობის შეზღუდვა). ეს არ ნიშნავს იმას, რომ მასპინძელი აუცილებლად ყველაფერს ცუდად გააკეთებს. მაგრამ სულაც არ არის ფაქტი, რომ ის გააკეთებს ზუსტად იმას, რაც თქვენ ნამდვილად გჭირდებოდათ.

როგორც ჩანს, ეს საკმაოდ აშკარაა, მაგრამ ჩემს პრაქტიკაში რამდენჯერმე წავაწყდი იმ ფაქტს, რომ კომპანიებმა დაიწყეს თავიანთი ჰოსტინგის პროვაიდერზე დაყრდნობა იმაზე ცოტა მეტი, ვიდრე უნდა, და ამან კარგი არაფერი გამოიწვია. დიდი დრო დასჭირდა დეტალურად ახსნას, რომ არცერთი SLA არ დაფარავს ზარალს (არსებობს გამონაკლისები, მაგრამ, როგორც წესი, ეს ძალიან, ძალიან ძვირია კლიენტისთვის) და რომ ჰოსტერმა საერთოდ არ იცის რა ხდება მომხმარებელთა ინფრასტრუქტურაში. (გარდა ძალიან ზოგადი მაჩვენებლებისა). ჰოსტერიც არ გიკეთებს სარეზერვო ასლებს. სიტუაცია კიდევ უფრო უარესია, თუ ერთზე მეტი ჰოსტერი გყავთ. მათ შორის რაიმე პრობლემის შემთხვევაში, ისინი ნამდვილად ვერ გაარკვევენ თქვენთვის რა მოხდა.

სინამდვილეში, მოტივები აქ ზუსტად იგივეა, რაც "ადმინისტრატორთა საკუთარი გუნდი წინააღმდეგ აუთსორსინგის" არჩევისას. თუ რისკები გათვლილია, ხარისხი უხდება და ბიზნესს არ ადარდებს - რატომ არ სცადო. მეორეს მხრივ, ქსელი ინფრასტრუქტურის ერთ-ერთი ყველაზე საბაზისო ფენაა და ძნელად ღირს მისი გაცემა აუტსაიდერებისთვის, თუ უკვე შენ თვითონ უჭერ მხარს ყველაფერს.

როდის გჭირდებათ ქსელური?

გარდა ამისა, ჩვენ ყურადღებას გავამახვილებთ თანამედროვე პროდუქტის კომპანიებზე. ოპერატორებთან და საწარმოებთან, ყველაფერი პლიუს ან მინუს ნათელია - ბოლო წლების განმავლობაში იქ ცოტა რამ შეიცვალა და ქსელის დამფუძნებლები აქ ადრე იყო საჭირო, ისინი ახლა საჭიროა. მაგრამ ამ ძალიან "ახალგაზრდებთან და გაბედულებთან" ყველაფერი არც ისე მარტივია. ხშირად ისინი თავიანთ ინფრასტრუქტურას მთლიანად ღრუბლებში ათავსებენ, ამიტომ ადმინებიც კი არ სჭირდებათ, გარდა იმავე ღრუბლების ადმინებისა, რა თქმა უნდა. ინფრასტრუქტურა, ერთი მხრივ, საკმაოდ მარტივია თავისი დიზაინით, მეორეს მხრივ, კარგად ავტომატიზირებული (ansible / თოჯინა, ტერაფორმი, ci / cd ... კარგად, თქვენ იცით). მაგრამ აქაც არის სიტუაციები, როდესაც არ შეგიძლიათ ქსელის ინჟინრის გარეშე.

მაგალითი 1, კლასიკური

დავუშვათ, კომპანია იწყება ერთი სერვერით საჯარო ip-მისამართით, რომელიც მდებარეობს მონაცემთა ცენტრში. შემდეგ არის ორი სერვერი. მერე კიდევ... ადრე თუ გვიან, სერვერებს შორის ჩნდება პირადი ქსელის საჭიროება. იმის გამო, რომ "გარე" ტრაფიკი შემოიფარგლება როგორც გამტარუნარიანობით (მაგალითად, არაუმეტეს 100 Mbps), ასევე ჩამოტვირთული / ატვირთული ოდენობით თვეში (სხვადასხვა ჰოსტერს აქვს განსხვავებული ტარიფი, მაგრამ გარე სამყაროს გამტარუნარიანობა, როგორც წესი, ბევრია. უფრო ძვირია, ვიდრე კერძო ქსელი).

ჰოსტერი ამატებს დამატებით ქსელურ ბარათებს სერვერებს და აერთიანებს მათ გადამრთველებში ცალკე vlan-ში. სერვერებს შორის ჩნდება „ბრტყელი“ LAN. კომფორტული!

იზრდება სერვერების რაოდენობა, ასევე იზრდება ტრაფიკი კერძო ქსელში - სარეზერვო ასლები, რეპლიკაციები და ა.შ. ჰოსტერი გთავაზობს გადაგიყვანოთ ცალ-ცალკე გადამრთველებზე, რათა არ ჩაერიოთ სხვა კლიენტებთან და მათ ხელი არ შეგიშალოთ. ჰოსტერი აყენებს რაიმე სახის კონცენტრატორებს და როგორღაც აკონფიგურირებს მათ - სავარაუდოდ, ტოვებს ერთ ბრტყელ ქსელს თქვენს ყველა სერვერს შორის. ყველაფერი კარგად მუშაობს, მაგრამ გარკვეულ მომენტში პრობლემები იწყება: პერიოდულად იზრდება შეფერხებები მასპინძლებს შორის, ჟურნალები აგინებენ ძალიან ბევრ arp პაკეტს წამში და პენტესტერმა გააუპატიურა თქვენი მთელი ადგილობრივი ტერიტორია აუდიტის დროს, დაარღვია მხოლოდ ერთი სერვერი.

რა უნდა გაკეთდეს?

დაყავით ქსელი სეგმენტებად - vlans. დააყენეთ თქვენი საკუთარი მისამართი თითოეულ vlan-ში, აირჩიეთ კარიბჭე, რომელიც გადასცემს ტრაფიკს ქსელებს შორის. კარიბჭეზე, დააკონფიგურირეთ acl, რომ შეზღუდოთ წვდომა სეგმენტებს შორის, ან თუნდაც დააყენოთ ცალკე ფაირვოლი მის გვერდით.

მაგალითი 1, გაგრძელება

სერვერები დაკავშირებულია ადგილობრივ ზონასთან ერთი კაბელით. თაროებში ჩამრთველები ერთგვარად არის დაკავშირებული, მაგრამ ერთ თაროში ავარიის შემთხვევაში კიდევ სამი მეზობელი იშლება. სქემები არსებობს, მაგრამ არსებობს ეჭვი მათ შესაბამისობაში. თითოეულ სერვერს აქვს საკუთარი საჯარო მისამართი, რომელიც გაცემულია ჰოსტის მიერ და მიბმული თაროზე. იმათ. სერვერის გადაადგილებისას მისამართი უნდა შეიცვალოს.

რა უნდა გაკეთდეს?

დააკავშირეთ სერვერები LAG-ის (Link Aggregation Group) გამოყენებით ორი კაბელით თაროში ჩამრთველებთან (ისინი ასევე უნდა იყოს ზედმეტი). შეინახეთ კავშირი თაროებს შორის, გადააკეთეთ ისინი "ვარსკვლავით" (ან ახლა მოდური CLOS) ისე, რომ ერთი თაროს დაკარგვამ არ იმოქმედოს სხვებზე. აირჩიეთ "ცენტრალური" თაროები, სადაც განთავსდება ქსელის ბირთვი და სადაც იქნება სხვა თაროები. ამავდროულად, დაალაგეთ საჯარო მიმართვა, აიღეთ ჰოსტერიდან (ან RIR-დან, თუ შესაძლებელია) ქვექსელი, რომელსაც თქვენ თავად (ან ჰოსტერის მეშვეობით) უცხადებთ მსოფლიოს.

შეუძლია თუ არა სისტემის „რეგულარულ“ ადმინისტრატორს, რომელსაც არ აქვს ღრმა ცოდნა ქსელების შესახებ? Დარწმუნებული არ ვარ. ამას მასპინძელი გააკეთებს? შეიძლება ასეც იყოს, მაგრამ დაგჭირდებათ საკმაოდ დეტალური TOR, რომელიც ასევე დაგჭირდებათ ვინმეს მიერ შედგენილი. და შემდეგ შეამოწმეთ, რომ ყველაფერი სწორად არის გაკეთებული.

მაგალითი 2: მოღრუბლული

დავუშვათ, რომ თქვენ გაქვთ VPC ზოგიერთ საჯარო ღრუბელში. იმისათვის, რომ მიიღოთ წვდომა ოფისიდან ან ინფრასტრუქტურის წინასწარი ნაწილიდან ადგილობრივ ქსელში VPC-ის შიგნით, თქვენ უნდა დააყენოთ კავშირი IPSec-ის ან გამოყოფილი არხის მეშვეობით. ერთის მხრივ, IPSec უფრო იაფია. არ არის საჭირო დამატებითი ტექნიკის შეძენა, შეგიძლიათ დააყენოთ გვირაბი თქვენს სერვერს შორის საჯარო მისამართით და ღრუბელთან. მაგრამ - შეფერხებები, შეზღუდული შესრულება (რადგან არხი საჭიროებს დაშიფვრას), პლუს არაგარანტირებული კავშირი (რადგან წვდომა გადის ჩვეულებრივ ინტერნეტს).

რა უნდა გაკეთდეს?

გაზარდეთ კავშირი გამოყოფილი არხის მეშვეობით (მაგალითად, AWS მას უწოდებს Direct Connect). ამისათვის იპოვეთ პარტნიორი ოპერატორი, რომელიც დაგაკავშირებთ, გადაწყვიტეთ თქვენთან ყველაზე ახლოს კავშირის წერტილი (როგორც თქვენ შედიხართ ოპერატორში, ასევე ოპერატორი ღრუბელში) და ბოლოს დააყენეთ ყველაფერი. შესაძლებელია თუ არა ეს ყველაფერი ქსელის ინჟინრის გარეშე? რა თქმა უნდა, დიახ. მაგრამ როგორ უნდა მოგვარდეს პრობლემები ამის გარეშე პრობლემების შემთხვევაში, აღარ არის ნათელი.

ასევე შეიძლება იყოს პრობლემები ღრუბლებს შორის ხელმისაწვდომობასთან დაკავშირებით (თუ თქვენ გაქვთ მულტიღრუბელი) ან პრობლემები შეფერხებებთან დაკავშირებით სხვადასხვა რეგიონებს შორის და ა.შ. რა თქმა უნდა, ახლა არის მრავალი ინსტრუმენტი, რომელიც ზრდის ღრუბელში მომხდარის გამჭვირვალობას (იგივე ათასი თვალი), მაგრამ ეს ყველაფერი ქსელის ინჟინერია და არა ჩანაცვლება.

შემეძლო კიდევ ათეული ასეთი მაგალითი გამოვხატო ჩემი პრაქტიკიდან, მაგრამ ვფიქრობ, ცხადია, რომ გუნდში, ინფრასტრუქტურის განვითარების გარკვეული დონიდან დაწყებული, უნდა იყოს ადამიანი (ან უკეთესი, ერთზე მეტი), რომელმაც იცის, როგორ არის ქსელი. მუშაობს, შეუძლია ქსელის აღჭურვილობის კონფიგურაცია და პრობლემების მოგვარება, თუ ისინი წარმოიქმნება. დამიჯერე, მას რაღაც მოუწევს გასაკეთებელი

რა უნდა იცოდეს ქსელურმა?

საერთოდ არ არის აუცილებელი (და ზოგჯერ საზიანოც კი) ქსელის ინჟინერი მხოლოდ ქსელთან და სხვა არაფერთან. მაშინაც კი, თუ ჩვენ არ განვიხილავთ ვარიანტს ინფრასტრუქტურით, რომელიც თითქმის მთლიანად ცხოვრობს საჯარო ღრუბელში (და, რაც არ უნდა ითქვას, ის სულ უფრო პოპულარული ხდება), და ავიღოთ, მაგალითად, შენობაში ან კერძო ღრუბლებზე, სადაც მხოლოდ ”ცოდნა CCNP დონეზე ”თქვენ არ წახვალთ.

გარდა, ფაქტობრივად, ქსელებისა - თუმცა უბრალოდ არის სწავლისთვის გაუთავებელი ველი, მაშინაც კი, თუ კონცენტრირდებით მხოლოდ ერთ მიმართულებაზე (პროვაიდერის ქსელები, საწარმოები, მონაცემთა ცენტრები, Wi-Fi ...)

რა თქმა უნდა, ახლა ბევრ თქვენგანს ახსოვს პითონი და სხვა "ქსელის ავტომატიზაცია", მაგრამ ეს მხოლოდ აუცილებელი, მაგრამ არა საკმარისი პირობაა. იმისათვის, რომ ქსელის ინჟინერმა „წარმატებით შეუერთდეს გუნდს“, მას უნდა შეეძლოს ერთსა და იმავე ენაზე საუბარი როგორც დეველოპერებთან, ასევე ადმინისტრატორებთან/დევოპებთან. Რას ნიშნავს?

• შეძლებს არა მხოლოდ იმუშაოს Linux-ში, როგორც მომხმარებელი, არამედ მისი ადმინისტრირება, სულ მცირე, sysadmin-junior-ის დონეზე: დააინსტალირეთ საჭირო პროგრამული უზრუნველყოფა, გადატვირთეთ დაცემული სერვისი, დაწერეთ მარტივი systemd-unit.
• გაიგეთ (ყოველ შემთხვევაში ზოგადი თვალსაზრისით) როგორ მუშაობს ქსელის სტეკი Linux-ში, როგორ მუშაობს ქსელი ჰიპერვიზორებსა და კონტეინერებში (lxc / docker / kubernetes).
• რა თქმა უნდა, შეეძლოს მუშაობა ansible/chef/თოჯინა ან სხვა SCM სისტემასთან.
• ცალკე ხაზი უნდა დაიწეროს SDN-ის და კერძო ღრუბლების ქსელების შესახებ (მაგალითად, TungstenFabric ან OpenvSwitch). ეს არის კიდევ ერთი დიდი ცოდნის ნაწილი.

მოკლედ, მე აღვწერე ტიპიური T- ფორმის სპეციალისტი (როგორც ახლა მოდაშია ნათქვამი). როგორც ჩანს, ახალი არაფერია, თუმცა, ინტერვიუების გამოცდილებიდან გამომდინარე, ქსელის ყველა ინჟინერი ვერ დაიკვეხნის ზემოაღნიშნული სიიდან მინიმუმ ორი თემის ცოდნით. პრაქტიკაში, ცოდნის ნაკლებობა "დაკავშირებულ სფეროებში" ძალიან ართულებს არა მხოლოდ კოლეგებთან კომუნიკაციას, არამედ იმ მოთხოვნების გაგებას, რომლებსაც ბიზნესი აწესებს ქსელში, როგორც პროექტის ყველაზე დაბალი დონის ინფრასტრუქტურა. და ამ გაგების გარეშე, უფრო რთული ხდება თქვენი თვალსაზრისის გონივრულად დაცვა და მისი ბიზნესისთვის „მიყიდვა“.

მეორეს მხრივ, „სისტემის მუშაობის გაგების“ ჩვევა ძალიან კარგ უპირატესობას ანიჭებს ქსელის მომხმარებლებს სხვადასხვა „გენერალისტებთან“ შედარებით, რომლებმაც იციან ტექნოლოგიების შესახებ სტატიებიდან Habré/საშუალო და ტელეგრამის ჩეთებზე, მაგრამ აბსოლუტურად წარმოდგენა არ აქვთ რა პრინციპებით. რომ პროგრამული უზრუნველყოფა მუშაობს. ზოგიერთი კანონზომიერების ცოდნა კი, მოგეხსენებათ, წარმატებით ანაცვლებს მრავალი ფაქტის ცოდნას.

დასკვნები, ან უბრალოდ TL;DR

1. ქსელის ადმინისტრატორი (როგორიცაა DBA ან VoIP ინჟინერი) არის საკმაოდ ვიწრო პროფილის სპეციალისტი (განსხვავებით sysadmins / devops / SRE-სგან), რომლის საჭიროება დაუყოვნებლივ არ წარმოიქმნება (და შეიძლება არ წარმოიშვას დიდი ხნის განმავლობაში, ფაქტობრივად) . მაგრამ თუ ის მაინც წარმოიქმნება, მაშინ ნაკლებად სავარაუდოა, რომ იგი შეიცვლება გარე ექსპერტიზით (აუთსორსინგი ან ჩვეულებრივი გენერალისტი ადმინისტრატორები, „რომლებიც ასევე ზრუნავენ ქსელზე“). რაც უფრო სამწუხაროა, არის ის, რომ ასეთი სპეციალისტების საჭიროება მცირეა და, პირობითად, კომპანიაში, რომელშიც 800 პროგრამისტი და 30 დევოპი/ადმინისტრატორია, შეიძლება იყოს მხოლოდ ორი ქსელური, ვინც თავის საქმეს შესანიშნავად ასრულებს. იმათ. ბაზარი იყო და არის ძალიან, ძალიან პატარა და კიდევ უფრო ნაკლები კარგი ხელფასით.
2. მეორეს მხრივ, თანამედროვე სამყაროში კარგმა ქსელურმა უნდა იცოდეს არა მხოლოდ თავად ქსელები (და როგორ მოახდინოს მათი კონფიგურაციის ავტომატიზაცია), არამედ ის, თუ როგორ ურთიერთქმედებენ მათთან ოპერაციული სისტემები და პროგრამული უზრუნველყოფა, რომლებიც გადის ამ ქსელებზე. ამის გარეშე უკიდურესად რთული იქნება იმის გაგება, თუ რას ითხოვენ კოლეგები თქვენგან და თქვენი სურვილების/მოთხოვნების (გონივრული) გადაცემა მათთვის.
3. ღრუბელი არ არის, ის უბრალოდ სხვისი კომპიუტერია. თქვენ უნდა გესმოდეთ, რომ საჯარო / კერძო ღრუბლების ან ჰოსტინგის პროვაიდერების სერვისების გამოყენება "ვინც ყველაფერს აკეთებს თქვენთვის" არ უარყოფს იმ ფაქტს, რომ თქვენი აპლიკაცია კვლავ იყენებს ქსელს და მასთან დაკავშირებული პრობლემები გავლენას მოახდენს თქვენი აპლიკაციის მუშაობაზე. . თქვენი არჩევანია სად განთავსდება კომპეტენციის ცენტრი, რომელიც იქნება პასუხისმგებელი თქვენი პროექტის ქსელზე.

წყარო: www.habr.com