Τη στιγμή που γραφόταν αυτό το άρθρο, μια αναζήτηση σε μια δημοφιλή τοποθεσία εργασίας για τη φράση "Μηχανικός Δικτύου" έδωσε περίπου τριακόσιες κενές θέσεις σε ολόκληρη τη Ρωσία. Για σύγκριση, μια αναζήτηση για τη φράση "διαχειριστής συστήματος" επιστρέφει σχεδόν 2.5 χιλιάδες κενές θέσεις και "μηχανικός DevOps" - σχεδόν 800.
Σημαίνει αυτό ότι οι δικτυωτές δεν χρειάζονται πλέον στις μέρες των νικητήριων cloud, των docker, των kubernetis και του πανταχού δημόσιου Wi-Fi;
Ας το καταλάβουμε (α)
Ας γνωριστούμε. Το όνομά μου είναι Alexey και είμαι δικτυωτής.
Κάνω δικτύωση για πάνω από 10 χρόνια και εργάζομαι με διάφορα συστήματα *nix για πάνω από 15 χρόνια (είχα την ευκαιρία να επιλέξω Linux και FreeBSD). Εργάστηκα σε τηλεπικοινωνιακούς παρόχους, μεγάλες εταιρείες που θεωρούνται «επιχειρήσεις» και πρόσφατα εργάζομαι σε «νεαρούς και τολμηρούς» fintech, όπου σύννεφα, devops, kubernetes και άλλες τρομακτικές λέξεις που σίγουρα θα κάνουν εμένα και τους συναδέλφους μου περιττός. Κάποια μέρα. Μπορεί.
αποποίηση ευθύνης: "Στη ζωή μας, όχι τα πάντα, πάντα και παντού, αλλά κάτι, μερικές φορές σε μέρη" (γ) Maxim Dorofeev.
Όλα όσα γράφονται παρακάτω μπορούν και πρέπει να θεωρηθούν προσωπική άποψη του συγγραφέα, χωρίς να ισχυρίζονται ότι είναι η απόλυτη αλήθεια, και μάλιστα μια ολοκληρωμένη μελέτη. Όλοι οι χαρακτήρες είναι φανταστικοί, όλες οι συμπτώσεις είναι τυχαίες.
Καλώς ήρθατε στον κόσμο μου.
Πού μπορείτε να βρείτε δικτυωτές;
1. Τηλεπικοινωνιακοί φορείς, εταιρείες παροχής υπηρεσιών και άλλοι φορείς ολοκλήρωσης. Όλα είναι απλά: το δίκτυο για αυτούς είναι μια επιχείρηση. Είτε πωλούν απευθείας συνδεσιμότητα (φορείς) είτε παρέχουν υπηρεσίες για την εκκίνηση/συντήρηση των δικτύων των πελατών τους.
Υπάρχει μεγάλη εμπειρία εδώ, αλλά όχι πολλά χρήματα (εκτός αν είστε διευθυντής ή επιτυχημένος διευθυντής πωλήσεων). Και όμως, αν σας αρέσουν τα δίκτυα και είστε μόλις στην αρχή του ταξιδιού σας, μια καριέρα για την υποστήριξη κάποιου όχι πολύ μεγάλου χειριστή θα είναι, ακόμη και τώρα, μια ιδανική αφετηρία (όλα είναι πολύ γραμμένα σε ομοσπονδιακά, και εκεί είναι λίγο περιθώριο για δημιουργικότητα). Λοιπόν, οι ιστορίες σχετικά με το γεγονός ότι είναι δυνατό να εξελιχθείς από μηχανικός σε υπηρεσία σε λίγα χρόνια σε διευθυντής C-level είναι επίσης αρκετά πραγματικές, αν και σπάνιες, για προφανείς λόγους. Πάντα υπάρχει ανάγκη για προσωπικό, γιατί υπάρχει ακόμη τζίρος. Αυτό είναι και καλό και κακό ταυτόχρονα - υπάρχουν πάντα κενές θέσεις, από την άλλη - συχνά οι πιο δραστήριοι/έξυπνοι αρκετά γρήγορα είτε προβιβάζονται είτε πηγαίνουν σε άλλα, πιο «ζεστά» μέρη.
2. "Επιχείρηση" υπό όρους. Δεν έχει σημασία αν η κύρια δραστηριότητά του σχετίζεται με την πληροφορική ή όχι. Το κυριότερο είναι ότι διαθέτει το δικό της τμήμα πληροφορικής, το οποίο ασχολείται με τη διασφάλιση της λειτουργίας των εσωτερικών συστημάτων της εταιρείας, συμπεριλαμβανομένων των δικτύων σε γραφεία, των καναλιών επικοινωνίας με τα υποκαταστήματα κ.λπ. Οι λειτουργίες ενός μηχανικού δικτύου σε τέτοιες εταιρείες μπορούν να εκτελούνται "μερικής απασχόλησης" από έναν διαχειριστή συστήματος (εάν η υποδομή δικτύου είναι μικρή ή ένας εξωτερικός ανάδοχος ασχολείται με αυτήν) και ο διαχειριστής δικτύου, εάν εξακολουθεί να υπάρχει, μπορεί φροντίστε ταυτόχρονα την τηλεφωνία και το SAN (όχι nuacho). Πληρώνουν με διαφορετικούς τρόπους - εξαρτάται σε μεγάλο βαθμό από το περιθώριο της επιχείρησης, το μέγεθος της εταιρείας και τη δομή. Συνεργάστηκα τόσο με εταιρείες όπου τα cisco «φορτώνονταν σε βαρέλια» τακτικά όσο και με εταιρείες όπου το δίκτυο κατασκευάστηκε από περιττώματα, ξυλάκια και μπλε ηλεκτρική ταινία και οι διακομιστές δεν ενημερώθηκαν, περίπου, ποτέ (είναι απαραίτητο να πούμε ότι υπάρχει δεν υπήρχαν ούτε αποθέματα) . Υπάρχει πολύ λιγότερη εμπειρία εδώ, και σχεδόν σίγουρα θα είναι στην περιοχή ενός σκληρού πωλητή-κλειδώματος ή «πώς να φτιάξεις κάτι από το τίποτα». Προσωπικά, μου φάνηκε πολύ βαρετό εκεί, αν και αρέσει σε πολλούς - όλα είναι αρκετά μετρημένα και προβλέψιμα (αν μιλάμε για μεγάλες εταιρείες), "dorah-bajato", κ.λπ. Τουλάχιστον μία φορά το χρόνο, κάποιος μεγάλος πωλητής λέει ότι έχει καταλήξει σε ένα άλλο σύστημα mega-super-duper που αυτοματοποιεί τα πάντα τώρα και όλοι οι διαχειριστές συστήματος και οι δικτυακοί μπορούν να υπερχρονιστούν, αφήνοντας ένα ζευγάρι να πατήσει κουμπιά σε μια όμορφη διεπαφή. Η πραγματικότητα είναι ότι, ακόμα κι αν αγνοήσουμε το κόστος της λύσης, οι δικτυωτές δεν θα πάνε πουθενά από εκεί. Ναι, είναι πιθανό αντί για την κονσόλα να υπάρχει ξανά μια διεπαφή ιστού (όχι όμως ένα συγκεκριμένο κομμάτι σιδήρου, αλλά ένα μεγάλο σύστημα που διαχειρίζεται δεκάδες και εκατοντάδες τέτοια κομμάτια σιδήρου), αλλά γνώση του «πώς λειτουργούν όλα μέσα » θα χρειαστεί ακόμα.
3. Εταιρείες προϊόντων, των οποίων τα κέρδη προέρχονται από την ανάπτυξη (και, συχνά, τη λειτουργία) κάποιου λογισμικού ή πλατφόρμας - αυτού ακριβώς του προϊόντος. Συνήθως είναι μικροί και ευκίνητοι, απέχουν ακόμα από την κλίμακα των επιχειρήσεων και τη γραφειοκρατικοποίησή τους. Είναι εδώ που αυτά τα ίδια devops, cubers, dockers και άλλες τρομερές λέξεις βρίσκονται σε μεγάλους αριθμούς που σίγουρα θα κάνουν τους μηχανικούς δικτύου και δικτύων ένα περιττό βασικό στοιχείο.
Σε τι διαφέρει ένας διαχειριστής δικτύου από έναν sysadmin;
Στην κατανόηση των ανθρώπων όχι από την πληροφορική - τίποτα. Και οι δύο κοιτάζουν τη μαύρη οθόνη και γράφουν κάποια ξόρκια, μερικές φορές βρίζουν απαλά.
Στην κατανόηση των προγραμματιστών - ίσως η θεματική περιοχή. Οι Sysadmins διαχειρίζονται διακομιστές, οι δικτυακοί διαχειρίζονται διακόπτες και δρομολογητές. Μερικές φορές ο διαχειριστής είναι κακός και όλα πέφτουν κάτω για όλους. Λοιπόν, για κάθε περίεργο, φταίνε και οι networkers. Απλά επειδή σε γαμώ, γι' αυτό.
Στην πραγματικότητα, η κύρια διαφορά είναι η προσέγγιση στη δουλειά. Ίσως, είναι μεταξύ των δικτυωτών που πάνω απ 'όλα υπάρχουν υποστηρικτές της προσέγγισης "Λειτουργεί - μην το αγγίζετε!". Μπορείτε συνήθως να κάνετε κάτι (σε έναν προμηθευτή) μόνο με έναν τρόπο, ολόκληρη τη διαμόρφωση του κουτιού - εδώ είναι, στην παλάμη του χεριού σας. Το κόστος ενός σφάλματος είναι υψηλό και μερικές φορές πολύ υψηλό (για παράδειγμα, πρέπει να διανύσετε αρκετές εκατοντάδες χιλιόμετρα για να επανεκκινήσετε τον δρομολογητή και αυτή τη στιγμή πολλές χιλιάδες άτομα θα είναι χωρίς επικοινωνία - μια κατάσταση που είναι αρκετά συνηθισμένη για έναν τηλεπικοινωνιακό πάροχο ).
Κατά τη γνώμη μου, αυτός είναι ο λόγος για τον οποίο οι μηχανικοί δικτύων, αφενός, έχουν εξαιρετικά ισχυρά κίνητρα για τη σταθερότητα του δικτύου (και οι αλλαγές είναι ο κύριος εχθρός της σταθερότητας) και, δεύτερον, οι γνώσεις τους πηγαίνουν περισσότερο σε βάθος παρά σε εύρος (δεν χρειάζεται για να μπορέσετε να διαμορφώσετε δεκάδες διαφορετικούς δαίμονες, πρέπει να γνωρίζετε τις τεχνολογίες και την εφαρμογή τους από έναν συγκεκριμένο κατασκευαστή εξοπλισμού). Γι' αυτό ο διαχειριστής συστήματος, που έψαξε στο google πώς να καταχωρήσει ένα vlan σε ένα tsiska, δεν είναι ακόμη διαχειριστής δικτύου. Και είναι απίθανο να μπορέσει να υποστηρίξει αποτελεσματικά (καθώς και να αντιμετωπίσει προβλήματα) ένα περισσότερο ή λιγότερο περίπλοκο δίκτυο.
Αλλά γιατί χρειάζεστε έναν διαχειριστή δικτύου εάν έχετε έναν οικοδεσπότη;
Για επιπλέον χρήματα (και αν είστε πολύ μεγάλος και αγαπημένος πελάτης, ίσως ακόμη και δωρεάν, "ως φίλος"), οι μηχανικοί του κέντρου δεδομένων θα διαμορφώσουν τους διακόπτες σας για να ταιριάζουν στις ανάγκες σας και, ίσως, ακόμη και να βοηθήσουν στη δημιουργία μιας διεπαφής BGP με παρόχους (εάν έχετε το δικό σας υποδίκτυο διευθύνσεων IP να ανακοινώσετε).
Το κύριο πρόβλημα είναι ότι το κέντρο δεδομένων δεν είναι το τμήμα πληροφορικής σας, είναι μια ξεχωριστή εταιρεία που στόχος της είναι να έχει κέρδος. Συμπεριλαμβανομένων εις βάρος σας ως πελάτη. Το κέντρο δεδομένων παρέχει racks, τους παρέχει ηλεκτρισμό και κρύο, και επίσης παρέχει κάποια «προεπιλεγμένη» συνδεσιμότητα στο Διαδίκτυο. Με βάση αυτήν την υποδομή, το κέντρο δεδομένων μπορεί να συντοποθετήσει τον εξοπλισμό σας (συντοποθεσία), να σας νοικιάσει έναν διακομιστή (αποκλειστικό διακομιστή) ή να παρέχει μια διαχειριζόμενη υπηρεσία (για παράδειγμα, OpenStack ή K8s). Αλλά η δουλειά του κέντρου δεδομένων (συνήθως) δεν είναι η διαχείριση της υποδομής πελατών, επειδή αυτή η διαδικασία είναι μάλλον εντατικής εργασίας, κακώς αυτοματοποιημένη (και σε ένα κανονικό κέντρο δεδομένων όλα είναι αυτοματοποιημένα), ενοποιημένη ακόμη χειρότερα (κάθε πελάτης είναι ξεχωριστός) και γενικά γεμάτη αξιώσεις («μου λες ότι ο διακομιστής ήταν ρυθμισμένος, αλλά τώρα έχει κολλήσει, για όλα φταίτε!!!111»). Επομένως, εάν ο οικοδεσπότης σας βοηθήσει με κάτι, τότε θα προσπαθήσει να το κάνει όσο πιο απλό και "condo" γίνεται. Γιατί είναι δύσκολο να γίνει - ασύμφορο, τουλάχιστον από την άποψη του κόστους εργασίας των μηχανικών αυτού του ίδιου του hoster (αλλά οι καταστάσεις είναι διαφορετικές, δείτε την αποποίηση ευθυνών). Αυτό δεν σημαίνει ότι ο οικοδεσπότης θα τα κάνει απαραίτητα όλα άσχημα. Αλλά δεν είναι καθόλου γεγονός ότι θα κάνει ακριβώς αυτό που πραγματικά χρειαζόσουν.
Φαίνεται ότι το πράγμα είναι αρκετά προφανές, αλλά αρκετές φορές στην πρακτική μου συνάντησα το γεγονός ότι οι εταιρείες άρχισαν να βασίζονται στον πάροχο φιλοξενίας τους λίγο περισσότερο από όσο θα έπρεπε και αυτό δεν οδήγησε σε τίποτα καλό. Χρειάστηκε πολύς χρόνος για να εξηγηθεί λεπτομερώς ότι καμία SLA δεν θα καλύψει απώλειες χρόνου διακοπής λειτουργίας (υπάρχουν εξαιρέσεις, αλλά συνήθως είναι πολύ, ΠΟΛΥ ακριβό για τον πελάτη) και ότι ο οικοδεσπότης δεν γνωρίζει καθόλου τι συμβαίνει στην υποδομή πελατών (εκτός από πολύ γενικούς δείκτες). Και ο hoster δεν σου κάνει αντίγραφα ασφαλείας. Η κατάσταση είναι ακόμη χειρότερη αν έχετε περισσότερους από έναν οικοδεσπότες. Σε περίπτωση οποιουδήποτε προβλήματος μεταξύ τους, σίγουρα δεν θα ανακαλύψουν για εσάς τι πήγε στραβά.
Στην πραγματικότητα, τα κίνητρα εδώ είναι ακριβώς τα ίδια με αυτά που επιλέγουμε "δική μας ομάδα διαχειριστών έναντι εξωτερικής ανάθεσης". Εάν οι κίνδυνοι είναι υπολογισμένοι, η ποιότητα ταιριάζει και η επιχείρηση δεν πειράζει - γιατί να μην το δοκιμάσετε. Από την άλλη πλευρά, το δίκτυο είναι ένα από τα πιο βασικά στρώματα υποδομής και δύσκολα αξίζει να το παραχωρήσετε σε ξένους αν υποστηρίζετε ήδη όλα τα άλλα μόνοι σας.
Πότε χρειάζεστε έναν δικτυωτή;
Περαιτέρω, θα επικεντρωθούμε σε σύγχρονες εταιρείες προϊόντων. Με τους φορείς εκμετάλλευσης και τις επιχειρήσεις, όλα είναι συν ή πλην ξεκάθαρα - λίγα έχουν αλλάξει εκεί τα τελευταία χρόνια και οι δικτυωτές χρειάζονταν εκεί πριν, χρειάζονται τώρα. Αλλά με αυτούς τους πολύ «νέους και τολμηρούς» τα πράγματα δεν είναι τόσο απλά. Συχνά τοποθετούν την υποδομή τους εξ ολοκλήρου στα σύννεφα, επομένως δεν χρειάζονται καν διαχειριστές, εκτός από τους διαχειριστές αυτών των ίδιων cloud, φυσικά. Η υποδομή, αφενός, είναι αρκετά απλή στο σχεδιασμό της, αφετέρου είναι καλά αυτοματοποιημένη (ansible / puppet, terraform, ci / cd ... καλά, ξέρεις). Αλλά ακόμη και εδώ, υπάρχουν περιπτώσεις όπου δεν μπορείτε να κάνετε χωρίς μηχανικό δικτύου.
Παράδειγμα 1, κλασικό
Ας υποθέσουμε ότι μια εταιρεία ξεκινά με έναν διακομιστή με μια δημόσια διεύθυνση IP, η οποία βρίσκεται στο κέντρο δεδομένων. Στη συνέχεια, υπάρχουν δύο διακομιστές. Τότε περισσότερα ... Αργά ή γρήγορα, υπάρχει ανάγκη για ένα ιδιωτικό δίκτυο μεταξύ των διακομιστών. Επειδή η "εξωτερική" κίνηση περιορίζεται τόσο από το εύρος ζώνης (όχι περισσότερο από 100 Mbps, για παράδειγμα) όσο και από το ποσό λήψης / μεταφόρτωσης ανά μήνα (οι διαφορετικοί κεντρικοί υπολογιστές έχουν διαφορετικά τιμολόγια, αλλά το εύρος ζώνης προς τον έξω κόσμο, κατά κανόνα, είναι πολύ πιο ακριβό από ένα ιδιωτικό δίκτυο).
Ο οικοδεσπότης προσθέτει πρόσθετες κάρτες δικτύου στους διακομιστές και τις περιλαμβάνει στους μεταγωγείς τους σε ένα ξεχωριστό vlan. Ένα «επίπεδο» LAN εμφανίζεται μεταξύ των διακομιστών. Ανετος!
Ο αριθμός των διακομιστών αυξάνεται, η κίνηση στο ιδιωτικό δίκτυο αυξάνεται επίσης - αντίγραφα ασφαλείας, επαναλήψεις κ.λπ. Ο οικοδεσπότης προσφέρει να σας μετακινήσει σε ξεχωριστούς διακόπτες, ώστε να μην παρεμβαίνετε με άλλους πελάτες και να μην παρεμβαίνουν σε εσάς. Ο οικοδεσπότης βάζει κάποιου είδους διακόπτες και με κάποιο τρόπο τους ρυθμίζει - πιθανότατα, αφήνοντας ένα επίπεδο δίκτυο μεταξύ όλων των διακομιστών σας. Όλα λειτουργούν καλά, αλλά σε ένα ορισμένο σημείο αρχίζουν τα προβλήματα: οι καθυστερήσεις μεταξύ των κεντρικών υπολογιστών αυξάνονται περιοδικά, τα αρχεία καταγραφής βρίζουν πάρα πολλά πακέτα arp ανά δευτερόλεπτο και ο pentester βίασε ολόκληρη την περιοχή σας κατά τη διάρκεια του ελέγχου, σπάζοντας μόνο έναν διακομιστή.
Τι πρέπει να κάνω;
Χωρίστε το δίκτυο σε τμήματα - vlans. Ρυθμίστε τη δική σας διεύθυνση σε κάθε vlan, επιλέξτε μια πύλη που θα μεταφέρει κίνηση μεταξύ των δικτύων. Στην πύλη, διαμορφώστε το acl για να περιορίσετε την πρόσβαση μεταξύ των τμημάτων ή ακόμα και να τοποθετήστε ένα ξεχωριστό τείχος προστασίας δίπλα του.
Παράδειγμα 1, συνέχεια
Οι διακομιστές συνδέονται στην τοπική περιοχή με ένα καλώδιο. Οι διακόπτες στα ράφια είναι κατά κάποιο τρόπο συνδεδεμένοι, αλλά σε περίπτωση ατυχήματος σε ένα rack, πέφτουν άλλοι τρεις γειτονικοί. Σχέδια υπάρχουν, αλλά υπάρχουν αμφιβολίες για τη συνάφειά τους. Κάθε διακομιστής έχει τη δική του δημόσια διεύθυνση, η οποία εκδίδεται από τον κεντρικό υπολογιστή και συνδέεται με το rack. Εκείνοι. κατά τη μετακίνηση του διακομιστή, η διεύθυνση πρέπει να αλλάξει.
Τι πρέπει να κάνω;
Συνδέστε διακομιστές χρησιμοποιώντας LAG (Link Aggregation Group) με δύο καλώδια σε διακόπτες στο rack (πρέπει επίσης να είναι περιττοί). Κρατήστε τις συνδέσεις μεταξύ των ραφιών, ξαναφτιάξτε τις με ένα «αστέρι» (ή το μοντέρνο πλέον CLOS) ώστε η απώλεια ενός rack να μην επηρεάσει τα άλλα. Επιλέξτε "κεντρικά" rack όπου θα βρίσκεται ο πυρήνας του δικτύου και όπου θα συμπεριληφθούν άλλα rack. Ταυτόχρονα, βάλτε σε τάξη τις δημόσιες διευθύνσεις, πάρτε από τον hoster (ή από το RIR, αν είναι δυνατόν) ένα υποδίκτυο, το οποίο εσείς οι ίδιοι (ή μέσω του hoster) ανακοινώνετε στον κόσμο.
Μπορεί ένας «κανονικός» διαχειριστής συστήματος που δεν έχει βαθιά γνώση των δικτύων να τα κάνει όλα αυτά; Δεν είμαι σίγουρος. Θα το κάνει ο οικοδεσπότης; Ίσως να είναι, αλλά θα χρειαστείτε ένα αρκετά λεπτομερές TOR, το οποίο θα πρέπει επίσης να συνταχθεί από κάποιον. και μετά ελέγξτε ότι όλα γίνονται σωστά.
Παράδειγμα 2: Συννεφιά
Ας υποθέσουμε ότι έχετε ένα VPC σε κάποιο δημόσιο σύννεφο. Για να αποκτήσετε πρόσβαση από το γραφείο ή μέρος της υποδομής on-prem στο τοπικό δίκτυο εντός του VPC, πρέπει να ρυθμίσετε μια σύνδεση μέσω IPSec ή ενός αποκλειστικού καναλιού. Από τη μία πλευρά, το IPSec είναι φθηνότερο. δεν χρειάζεται να αγοράσετε πρόσθετο υλικό, μπορείτε να δημιουργήσετε ένα τούνελ μεταξύ του διακομιστή σας με δημόσια διεύθυνση και του cloud. Αλλά - καθυστερήσεις, περιορισμένη απόδοση (καθώς το κανάλι πρέπει να κρυπτογραφηθεί), συν μη εγγυημένη συνδεσιμότητα (καθώς η πρόσβαση γίνεται μέσω του κανονικού Διαδικτύου).
Τι πρέπει να κάνω;
Αυξήστε τη σύνδεση μέσω ενός αποκλειστικού καναλιού (για παράδειγμα, το AWS το ονομάζει Direct Connect). Για να το κάνετε αυτό, βρείτε έναν συνεργάτη που θα σας συνδέσει, θα αποφασίσει για το σημείο σύνδεσης που βρίσκεται πιο κοντά σας (τόσο εσείς στον χειριστή όσο και ο χειριστής στο cloud) και, τέλος, θα ρυθμίσει τα πάντα. Όλα αυτά μπορούν να γίνουν χωρίς μηχανικό δικτύου; Σίγουρα, ναι. Αλλά πώς να αντιμετωπίσετε προβλήματα χωρίς αυτό σε περίπτωση προβλημάτων δεν είναι πλέον τόσο σαφές.
Και μπορεί επίσης να υπάρχουν προβλήματα με τη διαθεσιμότητα μεταξύ των cloud (εάν έχετε multicloud) ή προβλήματα με καθυστερήσεις μεταξύ διαφορετικών περιοχών κ.λπ. Φυσικά, τώρα υπάρχουν πολλά εργαλεία που αυξάνουν τη διαφάνεια του τι συμβαίνει στο cloud (το ίδιο Thousand Eyes), αλλά όλα αυτά είναι εργαλεία μηχανικού δικτύου και όχι αντικατάσταση.
Θα μπορούσα να σκιαγραφήσω μια ντουζίνα ακόμη τέτοια παραδείγματα από την πρακτική μου, αλλά νομίζω ότι είναι ξεκάθαρο ότι σε μια ομάδα, ξεκινώντας από ένα συγκεκριμένο επίπεδο ανάπτυξης υποδομής, θα πρέπει να υπάρχει ένα άτομο (ή καλύτερα, περισσότερα από ένα) που να γνωρίζουν πώς το δίκτυο λειτουργεί, μπορεί να διαμορφώσει τον εξοπλισμό δικτύου και να αντιμετωπίσει προβλήματα εάν προκύψουν. Πιστέψτε με, κάτι θα έχει να κάνει
Τι πρέπει να γνωρίζει ένας δικτυωτής;
Δεν είναι καθόλου απαραίτητο (και μάλιστα μερικές φορές επιβλαβές) για έναν μηχανικό δικτύου να ασχολείται μόνο με το δίκτυο και τίποτα άλλο. Ακόμα κι αν δεν εξετάσουμε την επιλογή με μια υποδομή που ζει σχεδόν εξ ολοκλήρου σε ένα δημόσιο σύννεφο (και, ό,τι και να πει κανείς, γίνεται όλο και πιο δημοφιλής), και πάρουμε, για παράδειγμα, σε premise ή private cloud, όπου μόνο «γνώση σε επίπεδο CCNP «Δεν θα φύγεις.
Επιπλέον, στην πραγματικότητα, τα δίκτυα - αν και υπάρχει απλώς ένα ατελείωτο πεδίο μελέτης, ακόμα κι αν επικεντρωθείτε μόνο σε μία κατεύθυνση (δίκτυα παρόχων, επιχειρήσεις, κέντρα δεδομένων, Wi-Fi ...)
Φυσικά, πολλοί από εσάς θα θυμάστε τώρα την Python και άλλους "αυτοματισμούς δικτύου", αλλά αυτό είναι μόνο μια απαραίτητη, αλλά όχι επαρκής συνθήκη. Για να μπορέσει ένας μηχανικός δικτύου «να ενταχθεί με επιτυχία στην ομάδα», πρέπει να μπορεί να μιλά την ίδια γλώσσα τόσο με προγραμματιστές όσο και με άλλους διαχειριστές/διαχειριστές. Τι σημαίνει?
- να μπορεί όχι μόνο να εργάζεται στο Linux ως χρήστης, αλλά και να το διαχειρίζεται, τουλάχιστον σε επίπεδο sysadmin-junior: εγκαταστήστε το απαραίτητο λογισμικό, επανεκκινήστε μια fallen υπηρεσία, γράψτε μια απλή systemd-unit.
- Κατανοήστε (τουλάχιστον σε γενικές γραμμές) πώς λειτουργεί η στοίβα δικτύου στο Linux, πώς λειτουργεί το δίκτυο σε hypervisors και κοντέινερ (lxc / docker / kubernetes).
- Φυσικά, μπορείτε να δουλέψετε με ansible/chef/κούκλα ή άλλο σύστημα SCM.
- Θα πρέπει να γραφτεί μια ξεχωριστή γραμμή για το SDN και τα δίκτυα για ιδιωτικά σύννεφα (για παράδειγμα, TungstenFabric ή OpenvSwitch). Αυτό είναι άλλο ένα τεράστιο κομμάτι γνώσης.
Εν ολίγοις, περιέγραψα έναν τυπικό ειδικό σε σχήμα Τ (όπως είναι πλέον της μόδας να λέμε). Δεν φαίνεται να είναι κάτι καινούργιο, ωστόσο, σύμφωνα με την εμπειρία των συνεντεύξεων, δεν μπορούν όλοι οι μηχανικοί δικτύου να καυχηθούν για γνώση τουλάχιστον δύο θεμάτων από την παραπάνω λίστα. Στην πράξη, η έλλειψη γνώσης «σε συναφείς τομείς» δυσχεραίνει όχι μόνο την επικοινωνία με τους συναδέλφους, αλλά και την κατανόηση των απαιτήσεων που επιβάλλει η επιχείρηση στο δίκτυο ως υποδομής χαμηλότερου επιπέδου του έργου. Και χωρίς αυτή την κατανόηση, γίνεται πιο δύσκολο να υπερασπιστείτε εύλογα την άποψή σας και να την «πουλήσετε» στις επιχειρήσεις.
Από την άλλη πλευρά, η ίδια η συνήθεια της «κατανόησης του τρόπου λειτουργίας του συστήματος» δίνει στους δικτυωτές ένα πολύ καλό πλεονέκτημα έναντι των διάφορων «γενικών» που γνωρίζουν για τεχνολογίες από άρθρα στο Habré/μέσα και συνομιλίες τηλεγραφήματος, αλλά δεν έχουν απολύτως καμία ιδέα για τις αρχές αυτού ή αυτό το λογισμικό λειτουργεί. Και η γνώση κάποιων κανονικοτήτων, όπως γνωρίζετε, αντικαθιστά με επιτυχία τη γνώση πολλών γεγονότων.
Συμπεράσματα, ή απλά TL;DR
- Ένας διαχειριστής δικτύου (όπως ένας μηχανικός DBA ή ένας μηχανικός VoIP) είναι ειδικός ενός μάλλον στενού προφίλ (σε αντίθεση με τα sysadmin / devops / SRE), η ανάγκη του οποίου δεν προκύπτει αμέσως (και μπορεί να μην προκύψει για μεγάλο χρονικό διάστημα, στην πραγματικότητα) . Αλλά αν προκύψει, τότε είναι απίθανο να αντικατασταθεί από εξωτερική τεχνογνωσία (εξωτερική ανάθεση ή απλοί γενικοί διαχειριστές, «οι οποίοι φροντίζουν επίσης το δίκτυο»). Αυτό που είναι κάπως πιο λυπηρό είναι ότι η ανάγκη για τέτοιους ειδικούς είναι μικρή και, υπό όρους, σε μια εταιρεία με 800 προγραμματιστές και 30 devops/διαχειριστές, μπορεί να υπάρχουν μόνο δύο δικτυακοί που κάνουν τέλεια τη δουλειά τους. Εκείνοι. η αγορά ήταν και είναι πολύ πολύ μικρή και ακόμη λιγότερο με καλό μισθό.
- Από την άλλη πλευρά, ένας καλός δικτυωτής στον σύγχρονο κόσμο θα πρέπει να γνωρίζει όχι μόνο τα ίδια τα δίκτυα (και πώς να αυτοματοποιήσει τη διαμόρφωσή τους), αλλά και πώς αλληλεπιδρούν με αυτά τα λειτουργικά συστήματα και το λογισμικό, που τρέχουν σε αυτά τα δίκτυα. Χωρίς αυτό, θα είναι εξαιρετικά δύσκολο να κατανοήσετε τι ζητούν οι συνάδελφοι από εσάς και να τους μεταφέρετε (εύλογα) τις επιθυμίες / απαιτήσεις σας.
- Δεν υπάρχει σύννεφο, είναι απλώς ο υπολογιστής κάποιου άλλου. Πρέπει να καταλάβετε ότι η χρήση δημόσιων / ιδιωτικών cloud ή των υπηρεσιών παρόχων φιλοξενίας "που κάνουν τα πάντα για εσάς" δεν αναιρεί το γεγονός ότι η εφαρμογή σας εξακολουθεί να χρησιμοποιεί το δίκτυο και τα προβλήματα με αυτό θα επηρεάσουν τη λειτουργία της εφαρμογής σας . Η επιλογή σας είναι πού θα βρίσκεται το κέντρο ικανοτήτων, το οποίο θα είναι υπεύθυνο για το δίκτυο του έργου σας.
Πηγή: www.habr.com