Τι χρειάζεται για να πετύχει μια εταιρεία πληροφορικής το 2019; Οι ομιλητές σε συνέδρια και συναντήσεις λένε πολλά δυνατά λόγια που δεν είναι πάντα κατανοητά από τους κανονικούς ανθρώπους. Ο αγώνας για χρόνο ανάπτυξης, μικροϋπηρεσίες, εγκατάλειψη του μονόλιθου, μετασχηματισμός DevOps και πολλά, πολλά άλλα. Αν απορρίψουμε τη λεκτική ομορφιά και μιλήσουμε απευθείας και στα ρωσικά, τότε όλα καταλήγουν σε μια απλή διατριβή: φτιάξτε ένα προϊόν υψηλής ποιότητας και κάντε το με άνεση για την ομάδα.
Το τελευταίο έχει γίνει εξαιρετικά σημαντικό. Οι επιχειρήσεις κατέληξαν τελικά στο συμπέρασμα ότι μια άνετη διαδικασία ανάπτυξης αυξάνει την παραγωγικότητα και αν όλα διορθωθούν και λειτουργούν σαν ρολόι, δίνει επίσης κάποιο περιθώριο ελιγμών σε κρίσιμες καταστάσεις. Μια φορά κι έναν καιρό, για χάρη αυτού του ελιγμού, ένας συγκεκριμένος έξυπνος άνθρωπος βρήκε αντίγραφα ασφαλείας, αλλά η βιομηχανία αναπτύσσεται και καταλήξαμε σε μηχανικούς DevOps - ανθρώπους που μετατρέπουν τη διαδικασία αλληλεπίδρασης μεταξύ ανάπτυξης και εξωτερικής υποδομής σε κάτι κατάλληλο και δεν σχετίζεται με τον σαμανισμό.
Όλη αυτή η «αρθρωτή» ιστορία είναι υπέροχη, αλλά... Έτυχε ορισμένοι από τους διαχειριστές να ονομαστούν απότομα DevOps, και οι ίδιοι οι μηχανικοί DevOps άρχισαν να απαιτείται να έχουν τουλάχιστον τις δεξιότητες της τηλεπάθειας και της διόρασης.
Πριν μιλήσουμε για σύγχρονα προβλήματα παροχής υποδομών, ας ορίσουμε τι εννοούμε με αυτόν τον όρο. Αυτή τη στιγμή, η κατάσταση έχει εξελιχθεί με τέτοιο τρόπο που έχουμε φτάσει στη διττότητα αυτής της έννοιας: η υποδομή μπορεί να είναι υπό όρους εξωτερική και υπό όρους εσωτερική.
Με τον όρο εξωτερική υποδομή εννοούμε οτιδήποτε διασφαλίζει τη λειτουργικότητα της υπηρεσίας ή του προϊόντος που αναπτύσσει η ομάδα. Πρόκειται για διακομιστές εφαρμογών ή ιστοτόπων, φιλοξενία και άλλες υπηρεσίες που διασφαλίζουν τη λειτουργικότητα του προϊόντος.
Η εσωτερική υποδομή περιλαμβάνει υπηρεσίες και εξοπλισμό που χρησιμοποιείται από την ίδια την ομάδα ανάπτυξης και άλλους υπαλλήλους, οι οποίοι συνήθως είναι πολλοί. Αυτοί είναι εσωτερικοί διακομιστές συστημάτων αποθήκευσης κώδικα, ένας τοπικά αναπτυσσόμενος διαχειριστής εργασιών και τα πάντα, τα πάντα, όλα όσα υπάρχουν στο εταιρικό intranet.
Τι κάνει ένας διαχειριστής συστήματος σε μια εταιρεία; Εκτός από το έργο της διαχείρισης αυτού του πολύ εταιρικού intranet, φέρει συχνά το βάρος των οικονομικών ανησυχιών για τη διασφάλιση της λειτουργικότητας του εξοπλισμού γραφείου. Ο διαχειριστής είναι ο ίδιος τύπος που θα σύρει γρήγορα μια νέα μονάδα συστήματος ή έναν εφεδρικό φορητό υπολογιστή έτοιμο για χρήση από το πίσω δωμάτιο, θα δώσει ένα νέο πληκτρολόγιο και θα συρθεί στα τέσσερα στα γραφεία, τεντώνοντας το καλώδιο Ethernet. Ένας διαχειριστής είναι ένας τοπικός ιδιοκτήτης και κυβερνήτης όχι μόνο εσωτερικών και εξωτερικών διακομιστών, αλλά και στέλεχος επιχείρησης. Ναι, ορισμένοι διαχειριστές μπορούν να εργαστούν μόνο στο επίπεδο συστήματος, χωρίς υλικό. Θα πρέπει να χωριστούν σε μια ξεχωριστή υποκατηγορία «διαχειριστές συστημάτων υποδομής». Και κάποιοι ειδικεύονται στο σέρβις αποκλειστικά εξοπλισμού γραφείου· ευτυχώς, αν η εταιρεία έχει περισσότερα από εκατό άτομα, η δουλειά δεν τελειώνει ποτέ. Αλλά κανένας από τους δύο δεν είναι devops.
Ποιοι είναι οι DevOps; Οι Devops είναι τύποι που μιλούν για την αλληλεπίδραση της ανάπτυξης λογισμικού με την εξωτερική υποδομή. Πιο συγκεκριμένα, οι σύγχρονοι devops εμπλέκονται στις διαδικασίες ανάπτυξης και ανάπτυξης πολύ πιο βαθιά από ό,τι συμμετείχαν ποτέ οι διαχειριστές που απλώς ανέβαζαν ενημερώσεις στο ftp. Ένα από τα βασικά καθήκοντα ενός μηχανικού DevOps τώρα είναι να εξασφαλίσει μια άνετη και αποτελεσματικά δομημένη διαδικασία αλληλεπίδρασης μεταξύ των ομάδων ανάπτυξης και της υποδομής προϊόντων. Αυτοί οι άνθρωποι είναι υπεύθυνοι για την ανάπτυξη συστημάτων επαναφοράς και ανάπτυξης· αυτοί οι άνθρωποι είναι που παίρνουν μέρος του φόρτου από τους προγραμματιστές και επικεντρώνονται όσο το δυνατόν περισσότερο στην εξαιρετικά σημαντική αποστολή τους. Ταυτόχρονα, η devops δεν θα τρέξει ποτέ νέο καλώδιο ή δεν θα εκδώσει νέο φορητό υπολογιστή από το πίσω δωμάτιο (γ) KO
Ποιά είναι η παγίδα?
Στην ερώτηση "Ποιος είναι ο DevOps;" Οι μισοί εργαζόμενοι στο χωράφι αρχίζουν να απαντούν κάτι σαν "Λοιπόν, εν ολίγοις, αυτός είναι ο διαχειριστής που ..." και περαιτέρω στο κείμενο. Ναι, μια φορά κι έναν καιρό, όταν το επάγγελμα του μηχανικού DevOps μόλις αναδυόταν από τους πιο ταλαντούχους διαχειριστές όσον αφορά τη συντήρηση υπηρεσιών, οι διαφορές μεταξύ τους δεν ήταν εμφανείς σε όλους. Αλλά τώρα, όταν οι λειτουργίες του devops και του admin στην ομάδα έχουν γίνει ριζικά διαφορετικές, είναι απαράδεκτο να τα συγχέουμε μεταξύ τους ή ακόμα και να τα εξισώνουμε.
Τι σημαίνει όμως αυτό για τις επιχειρήσεις;
Η πρόσληψη, όλα είναι θέμα.
Ανοίγετε μια κενή θέση για "Διαχειριστής συστήματος" και οι απαιτήσεις που αναφέρονται εκεί είναι "αλληλεπίδραση με ανάπτυξη και πελάτες", "σύστημα παράδοσης CI/CD", "συντήρηση διακομιστών και εξοπλισμού της εταιρείας", "διαχείριση εσωτερικών συστημάτων" κ.λπ. επί; καταλαβαίνεις ότι ο εργοδότης λέει βλακείες. Το πρόβλημά μας είναι ότι αντί για "Διαχειριστής συστήματος" ο τίτλος της κενής θέσης θα πρέπει να είναι "DevOps Engineer" και αν αλλάξει αυτός ο τίτλος, τότε όλα μπαίνουν στη θέση τους.
Ωστόσο, τι εντύπωση έχει κανείς όταν διαβάζει μια τέτοια κενή θέση; Ότι η εταιρεία ψάχνει για χειριστή πολλών μηχανών που θα αναπτύξει και σύστημα ελέγχου έκδοσης και παρακολούθησης και θα σφίξει το στριφτάρι με τα δόντια του...
Αλλά για να μην αυξηθεί ο βαθμός του εθισμού στα ναρκωτικά στην αγορά εργασίας, αρκεί να αποκαλούμε τις κενές θέσεις με τα σωστά τους ονόματα και να κατανοήσουμε ξεκάθαρα ότι ένας μηχανικός DevOps και ένας διαχειριστής συστήματος είναι δύο διαφορετικές οντότητες. Αλλά η ακατανίκητη επιθυμία ορισμένων εργοδοτών να παρουσιάσουν την ευρύτερη δυνατή λίστα απαιτήσεων σε έναν υποψήφιο οδηγεί στο γεγονός ότι οι «κλασικοί» διαχειριστές συστημάτων παύουν να κατανοούν τι συμβαίνει γύρω τους. Τι, μεταλλάσσεται το επάγγελμα και μένουν πίσω από την εποχή;
Όχι όχι και άλλη μια φορά όχι. Οι διαχειριστές υποδομής που θα διαχειρίζονται τους εσωτερικούς διακομιστές της εταιρείας ή θα καταλαμβάνουν θέσεις υποστήριξης L2/L3 και θα βοηθούν άλλους υπαλλήλους, δεν έχουν απομακρυνθεί και δεν πρόκειται να αποχωρήσουν.
Μπορούν αυτοί οι ειδικοί να γίνουν μηχανικοί DevOps; Φυσικά και μπορούν. Στην πραγματικότητα, πρόκειται για ένα σχετικό περιβάλλον που απαιτεί δεξιότητες διαχείρισης συστήματος, αλλά επιπλέον προστίθεται η εργασία με συστήματα παρακολούθησης, παράδοσης και, γενικά, στενή αλληλεπίδραση με την ομάδα ανάπτυξης και δοκιμών.
Ένα άλλο πρόβλημα DevOps
Στην πραγματικότητα, τα πάντα δεν περιορίζονται μόνο σε προσλήψεις και συνεχή σύγχυση μεταξύ διαχειριστών και devops. Κάποια στιγμή, η επιχείρηση βρέθηκε αντιμέτωπη με το πρόβλημα της παράδοσης ενημερώσεων και της αλληλεπίδρασης της ομάδας ανάπτυξης με την τελική υποδομή.
Ίσως ήταν όταν ένας θείος με αστραφτερά μάτια σηκώθηκε στη σκηνή κάποιου συνεδρίου και είπε: «Το κάνουμε αυτό και το ονομάζουμε DevOps. Αυτοί οι τύποι θα σας λύσουν όλα τα προβλήματά σας» - και άρχισε να λέει πόσο καλή είναι η ζωή στην εταιρεία μετά την εφαρμογή πρακτικών DevOps.
Ωστόσο, δεν αρκεί να προσλάβετε έναν μηχανικό DevOps για να λειτουργήσουν όλα όπως θα έπρεπε. Η εταιρεία πρέπει να υποβληθεί σε έναν πλήρη μετασχηματισμό DevOps, δηλαδή, ο ρόλος και οι δυνατότητες των DevOps μας πρέπει επίσης να γίνουν σαφώς κατανοητοί από την πλευρά της ομάδας ανάπτυξης και δοκιμής προϊόντων. Έχουμε μια «υπέροχη» ιστορία για αυτό το θέμα που απεικονίζει πλήρως όλη τη βαρβαρότητα που συμβαίνει σε ορισμένα μέρη.
Κατάσταση. Το DevOps απαιτείται να αναπτύξει ένα σύστημα επαναφοράς έκδοσης χωρίς να εμβαθύνει πραγματικά στο πώς θα λειτουργήσει. Ας υποθέσουμε ότι μέσα στο σύστημα Χρήστες υπάρχουν ξεχωριστά πεδία για όνομα, επίθετο και κωδικό πρόσβασης. Κυκλοφορεί μια νέα έκδοση του προϊόντος, αλλά για τους προγραμματιστές, η "επαναστροφή" είναι απλώς ένα μαγικό ραβδί που θα διορθώσει τα πάντα και δεν ξέρουν καν πώς λειτουργεί. Έτσι, για παράδειγμα, στο επόμενο patch οι προγραμματιστές συνδύασαν τα πεδία ονόματος και επωνύμου, το έβγαλαν στην παραγωγή, αλλά η έκδοση είναι αργή για κάποιο λόγο. Τι συμβαίνει? Η διαχείριση έρχεται στο devops και λέει «Τραβήξτε το διακόπτη!», δηλαδή του ζητά να επιστρέψει στην προηγούμενη έκδοση. Τι κάνει το devops; Επιστρέφει στην προηγούμενη έκδοση, αλλά επειδή οι προγραμματιστές δεν ήθελαν να καταλάβουν πώς έγινε αυτή η επαναφορά, κανείς δεν είπε στην ομάδα devops ότι η βάση δεδομένων έπρεπε επίσης να επαναφερθεί. Ως αποτέλεσμα, τα πάντα κολλάνε για εμάς και αντί για έναν αργό ιστότοπο, οι χρήστες βλέπουν ένα σφάλμα "500", επειδή η παλιά έκδοση δεν λειτουργεί με τα πεδία της νέας βάσης δεδομένων. Ο Ντέβοπς δεν ξέρει για αυτό. Οι προγραμματιστές σιωπούν. Η διοίκηση αρχίζει να χάνει τα νεύρα και τα χρήματά της και θυμάται τα αντίγραφα ασφαλείας, προσφέροντάς τους να αποσυρθούν από αυτά, ώστε «τουλάχιστον κάτι να λειτουργήσει». Ως αποτέλεσμα, οι χρήστες χάνουν όλα τα δεδομένα τους σε μια χρονική περίοδο.
Τα καρύδια, φυσικά, πάνε στο devops, το οποίο «δεν έφτιαξε ένα σωστό σύστημα επαναφοράς» και κανείς δεν νοιάζεται που οι άλκες σε αυτήν την ιστορία είναι προγραμματιστές.
Το συμπέρασμα είναι απλό: χωρίς μια κανονική προσέγγιση στο DevOps ως τέτοιο, είναι ελάχιστα χρήσιμο.
Το κύριο πράγμα που πρέπει να θυμάστε: ένας μηχανικός DevOps δεν είναι μάγος και χωρίς ποιοτικές επικοινωνίες και αμφίδρομη αλληλεπίδραση με την ανάπτυξη, δεν θα αντιμετωπίσει τα καθήκοντά του. Οι προγραμματιστές δεν μπορούν να μείνουν μόνοι με τα «προβλήματά» τους ή να τους δοθεί η εντολή «μην ανακατεύεσαι με τους προγραμματιστές, η δουλειά τους είναι να κωδικοποιούν» και μετά να ελπίζουν ότι σε μια κρίσιμη στιγμή όλα θα λειτουργήσουν όπως θα έπρεπε. Δεν λειτουργεί έτσι.
Ουσιαστικά, το DevOps είναι μια ικανότητα στα σύνορα μεταξύ διαχείρισης και τεχνολογίας. Επιπλέον, δεν είναι καθόλου προφανές ότι σε αυτό το κοκτέιλ θα έπρεπε να υπάρχει περισσότερη τεχνολογία παρά διαχείριση. Εάν θέλετε πραγματικά να δημιουργήσετε ταχύτερες και πιο αποτελεσματικές διαδικασίες ανάπτυξης, πρέπει να εμπιστευτείτε την ομάδα devops σας. Ξέρει τα σωστά εργαλεία, έχει υλοποιήσει παρόμοια έργα, ξέρει να το κάνει. Βοηθήστε τον, ακούστε τη συμβουλή του, μην προσπαθήσετε να τον απομονώσετε σε κάποιου είδους αυτόνομη μονάδα. Εάν οι διαχειριστές μπορούν να δουλέψουν μόνοι τους, τότε τα devop είναι άχρηστα σε αυτήν την περίπτωση· δεν θα μπορούν να σας βοηθήσουν να γίνετε καλύτεροι εάν εσείς οι ίδιοι δεν θέλετε να αποδεχτείτε αυτήν τη βοήθεια.
Και κάτι τελευταίο: σταματήστε να προσβάλλετε τους διαχειριστές υποδομών. Έχουν το δικό τους, εξαιρετικά σημαντικό μέτωπο εργασίας. Ναι, ένας διαχειριστής μπορεί να γίνει μηχανικός DevOps, αλλά αυτό θα πρέπει να συμβεί κατόπιν αιτήματος του ίδιου του ατόμου και όχι υπό πίεση. Και δεν υπάρχει τίποτα κακό με το γεγονός ότι ένας διαχειριστής συστήματος θέλει να παραμείνει διαχειριστής συστήματος - αυτό είναι το ξεχωριστό του επάγγελμα και το δικαίωμά του. Εάν θέλετε να υποστείτε μια επαγγελματική μεταμόρφωση, τότε δεν πρέπει ποτέ να ξεχνάτε ότι θα πρέπει να αποκτήσετε όχι μόνο τεχνολογικές δεξιότητες, αλλά και διοικητικές. Πιθανότατα, θα εναπόκειται σε εσάς ως ηγέτη να συγκεντρώσετε όλους αυτούς τους ανθρώπους και να τους μάθετε να επικοινωνούν στην ίδια γλώσσα.
Πηγή: www.habr.com