Ποιοι είναι οι DevOps;

Αυτή τη στιγμή, αυτή είναι σχεδόν η πιο ακριβή θέση στην αγορά. Η φασαρία γύρω από τους μηχανικούς «DevOps» είναι πέρα ​​από κάθε όριο που μπορεί να φανταστεί κανείς, και ακόμη χειρότερα με τους ανώτερους μηχανικούς DevOps.
Εργάζομαι ως επικεφαλής του τμήματος ενοποίησης και αυτοματισμού, μαντέψτε την αγγλική αποκωδικοποίηση - DevOps Manager. Είναι απίθανο η αγγλική μεταγραφή να αντικατοπτρίζει τις καθημερινές μας δραστηριότητες, αλλά η ρωσική έκδοση σε αυτή την περίπτωση είναι πιο ακριβής. Λόγω της φύσης της δραστηριότητάς μου, είναι φυσικό να χρειάζομαι συνεντεύξεις από μελλοντικά μέλη της ομάδας μου και τον περασμένο χρόνο, περίπου 50 άτομα πέρασαν από μέσα μου και ο ίδιος αριθμός αποκόπηκε στην προεπισκόπηση με τους υπαλλήλους μου.

Εξακολουθούμε να αναζητούμε συναδέλφους, γιατί πίσω από την ετικέτα DevOps κρύβεται ένα πολύ μεγάλο στρώμα διαφορετικών ειδών μηχανικών.

Όλα όσα γράφονται παρακάτω είναι προσωπική μου άποψη, δεν χρειάζεται να συμφωνήσετε με αυτό, αλλά ομολογώ ότι θα προσθέσει λίγο χρώμα στη στάση σας στο θέμα. Παρά τον κίνδυνο να πέσει σε δυσμένεια, δημοσιεύω την άποψή μου γιατί πιστεύω ότι πρέπει να είναι.

Οι εταιρείες έχουν διαφορετική αντίληψη για το ποιοι είναι οι μηχανικοί DevOps και, για χάρη της γρήγορης πρόσληψης ενός πόρου, κρεμούν αυτήν την ετικέτα σε όλους. Η κατάσταση είναι αρκετά περίεργη, αφού οι εταιρείες είναι έτοιμες να πληρώσουν μη ρεαλιστικές αμοιβές σε αυτούς τους ανθρώπους, λαμβάνοντας, στις περισσότερες περιπτώσεις, έναν διαχειριστή εργαλείων για αυτούς.

Ποιοι είναι λοιπόν οι μηχανικοί DevOps;

Ας ξεκινήσουμε με το ιστορικό της εμφάνισής του - Οι Λειτουργίες Ανάπτυξης εμφανίστηκαν ως ένα ακόμη βήμα προς τη βελτιστοποίηση της αλληλεπίδρασης σε μικρές ομάδες για την αύξηση της ταχύτητας παραγωγής προϊόντων, ως αναμενόμενη συνέπεια. Η ιδέα ήταν να ενισχυθεί η ομάδα ανάπτυξης με γνώση διαδικασιών και προσεγγίσεων στη διαχείριση του περιβάλλοντος προϊόντος. Με άλλα λόγια, ο προγραμματιστής πρέπει να κατανοήσει και να γνωρίζει πώς λειτουργεί το προϊόν του σε ορισμένες συνθήκες, πρέπει να κατανοήσει πώς να αναπτύξει το προϊόν του, ποια χαρακτηριστικά του περιβάλλοντος μπορούν να προσαρμοστούν για τη βελτίωση της απόδοσης. Έτσι, για κάποιο χρονικό διάστημα, εμφανίστηκαν προγραμματιστές με μια προσέγγιση DevOps. Οι προγραμματιστές του DevOps έγραψαν σενάρια κατασκευής και συσκευασίας για να απλοποιήσουν τις δραστηριότητές τους και την απόδοση του περιβάλλοντος παραγωγής. Ωστόσο, η πολυπλοκότητα της αρχιτεκτονικής λύσεων και η αμοιβαία επιρροή των στοιχείων της υποδομής με την πάροδο του χρόνου άρχισαν να επιδεινώνουν την απόδοση των περιβαλλόντων· με κάθε επανάληψη, απαιτούνταν ολοένα και βαθύτερη κατανόηση ορισμένων στοιχείων, μειώνοντας την παραγωγικότητα του προγραμματιστή λόγω των πρόσθετων κόστος κατανόησης των εξαρτημάτων και των συστημάτων συντονισμού για μια συγκεκριμένη εργασία. Το κόστος του ίδιου του προγραμματιστή αυξήθηκε, το κόστος του προϊόντος μαζί με αυτό, οι απαιτήσεις για νέους προγραμματιστές στην ομάδα αυξήθηκαν απότομα, επειδή έπρεπε επίσης να καλύψουν τις ευθύνες του "αστέρι" ανάπτυξης και, φυσικά, τα "αστέρια" έγιναν λιγότερα και λιγότερο διαθέσιμο. Αξίζει επίσης να σημειωθεί ότι, από την εμπειρία μου, λίγοι προγραμματιστές ενδιαφέρονται για τις ιδιαιτερότητες της επεξεργασίας πακέτων από τον πυρήνα του λειτουργικού συστήματος, τους κανόνες δρομολόγησης πακέτων και τις πτυχές ασφάλειας του κεντρικού υπολογιστή. Το λογικό βήμα ήταν να προσελκύσει έναν διαχειριστή που να είναι εξοικειωμένος με αυτό και να του αναθέσει παρόμοιες ευθύνες, γεγονός που, χάρη στην εμπειρία του, κατέστησε δυνατή την επίτευξη των ίδιων δεικτών με χαμηλότερο κόστος σε σύγκριση με το κόστος μιας ανάπτυξης «αστέρι». Τέτοιοι διαχειριστές τοποθετήθηκαν σε μια ομάδα και το κύριο καθήκον του ήταν να διαχειρίζεται περιβάλλοντα δοκιμής και παραγωγής, σύμφωνα με τους κανόνες μιας συγκεκριμένης ομάδας, με πόρους που διατίθενται σε αυτήν τη συγκεκριμένη ομάδα. Κάπως έτσι εμφανίστηκαν στην πραγματικότητα τα DevOps στο μυαλό της πλειοψηφίας.

Εν μέρει ή πλήρως, με την πάροδο του χρόνου, αυτοί οι διαχειριστές συστήματος άρχισαν να κατανοούν τις ανάγκες της συγκεκριμένης ομάδας στον τομέα της ανάπτυξης, πώς να κάνουν τη ζωή ευκολότερη για τους προγραμματιστές και τους δοκιμαστές, πώς να διαθέσουν μια ενημέρωση και να μην χρειάζεται να μείνουν τη νύχτα την Παρασκευή στο το γραφείο, διορθώνοντας σφάλματα ανάπτυξης. Ο χρόνος πέρασε και τώρα τα "αστέρια" ήταν οι διαχειριστές συστήματος που καταλάβαιναν τι ήθελαν οι προγραμματιστές. Προκειμένου να ελαχιστοποιηθεί ο αντίκτυπος, άρχισαν να εμφανίζονται βοηθητικά προγράμματα διαχείρισης· όλοι θυμήθηκαν τις παλιές και αξιόπιστες μεθόδους απομόνωσης του επιπέδου λειτουργικού συστήματος, οι οποίες κατέστησαν δυνατή την ελαχιστοποίηση των απαιτήσεων για ασφάλεια, διαχείριση του τμήματος δικτύου και τη διαμόρφωση του κεντρικού υπολογιστή ως ολόκληρα και, ως εκ τούτου, να μειώσει τις απαιτήσεις για νέα «αστέρια».

Ένα «υπέροχο» πράγμα εμφανίστηκε - λιμενεργάτης. Γιατί υπέροχο; Ναι, μόνο επειδή η δημιουργία απομόνωσης σε ένα chroot ή jail, καθώς και το OpenVZ, απαιτούσε μη τετριμμένη γνώση του λειτουργικού συστήματος, αντίθετα, το βοηθητικό πρόγραμμα σάς επιτρέπει να δημιουργήσετε απλά ένα απομονωμένο περιβάλλον εφαρμογής σε έναν συγκεκριμένο κεντρικό υπολογιστή με όλα τα απαραίτητα μέσα και στο χέρι πάνω από τα ηνία της ανάπτυξης και πάλι, και ο διαχειριστής του συστήματος μπορεί να διαχειριστεί μόνο με έναν κεντρικό υπολογιστή, διασφαλίζοντας την ασφάλεια και την υψηλή διαθεσιμότητά του - μια λογική απλοποίηση. Αλλά η πρόοδος δεν σταματά και τα συστήματα γίνονται και πάλι όλο και πιο περίπλοκα, υπάρχουν όλο και περισσότερα στοιχεία, ένας κεντρικός υπολογιστής δεν ανταποκρίνεται πλέον στις ανάγκες του συστήματος και είναι απαραίτητο να δημιουργηθούν συμπλέγματα, επιστρέφουμε ξανά στους διαχειριστές συστήματος που είναι σε θέση να κατασκευάσει αυτά τα συστήματα.

Από κύκλο μετά τον κύκλο, εμφανίζονται διάφορα συστήματα που απλοποιούν την ανάπτυξη ή/και τη διαχείριση, εμφανίζονται συστήματα ενορχήστρωσης, τα οποία, μέχρι να χρειαστεί να αποκλίνετε από την τυπική διαδικασία, είναι εύχρηστα. Η αρχιτεκτονική μικροϋπηρεσιών εμφανίστηκε επίσης με στόχο να απλοποιήσει όλα όσα περιγράφονται παραπάνω - λιγότερες σχέσεις, ευκολότερη διαχείριση. Από την εμπειρία μου, δεν βρήκα μια εντελώς αρχιτεκτονική μικροϋπηρεσιών, θα έλεγα ότι το 50 έως 50 - 50 τοις εκατό των μικροϋπηρεσιών, μαύρα κουτιά, μπήκαν, βγήκαν επεξεργασμένα, τα άλλα 50 είναι ένας σκισμένος μονόλιθος, οι υπηρεσίες δεν μπορούν να λειτουργήσουν ξεχωριστά από άλλες συστατικά. Όλα αυτά επέβαλαν και πάλι περιορισμούς στο επίπεδο γνώσεων τόσο των προγραμματιστών όσο και των διαχειριστών.

Παρόμοιες «αλλαγές» στο επίπεδο των ειδικών γνώσεων ενός συγκεκριμένου πόρου συνεχίζονται μέχρι σήμερα. Αλλά ξεφεύγουμε λίγο, υπάρχουν πολλά σημεία που αξίζει να επισημανθούν.

Build Engineer/Release Engineer

Πολύ εξειδικευμένοι μηχανικοί που αναδείχθηκαν ως μέσο τυποποίησης διαδικασιών κατασκευής και εκδόσεων λογισμικού. Κατά τη διαδικασία εισαγωγής του ευρέως διαδεδομένου Agile, φαίνεται ότι έπαψαν να είναι σε ζήτηση, αλλά αυτό απέχει πολύ από την περίπτωση. Αυτή η εξειδίκευση εμφανίστηκε ως μέσο τυποποίησης της συναρμολόγησης και παράδοσης λογισμικού σε βιομηχανική κλίμακα, δηλ. χρησιμοποιώντας τυπικές τεχνικές για όλα τα προϊόντα της εταιρείας. Με την έλευση του DevOps, οι προγραμματιστές έχασαν εν μέρει τις λειτουργίες τους, καθώς οι προγραμματιστές ήταν αυτοί που άρχισαν να προετοιμάζουν το προϊόν για παράδοση και δεδομένης της μεταβαλλόμενης υποδομής και της προσέγγισης για παράδοση όσο το δυνατόν γρηγορότερα χωρίς να λαμβάνεται υπόψη η ποιότητα, με την πάροδο του χρόνου μετατράπηκαν σε ανακόπτει τις αλλαγές, καθώς η τήρηση των προτύπων ποιότητας αναπόφευκτα επιβραδύνει τις παραδόσεις. Έτσι, σταδιακά, μέρος της λειτουργικότητας των μηχανικών Build/Release μεταφέρθηκε στους ώμους των διαχειριστών συστημάτων.

Οι λειτουργίες είναι τόσο διαφορετικές

Προχωράμε και ξανά η παρουσία μεγάλου εύρους αρμοδιοτήτων και η έλλειψη εξειδικευμένου προσωπικού μας ωθεί προς την αυστηρή εξειδίκευση, όπως τα μανιτάρια μετά τη βροχή, εμφανίζονται διάφορες Επιχειρήσεις:

• TechOps - διαχειριστές συστήματος enikey γνωστός και ως HelpDesk Engineer
• LiveOps - οι διαχειριστές συστήματος είναι κατά κύριο λόγο υπεύθυνοι για τα περιβάλλοντα παραγωγής
• CloudOps - διαχειριστές συστήματος που ειδικεύονται στα δημόσια σύννεφα Azure, AWS, GCP κ.λπ.
• PlatOps/InfraOps/SysOps - διαχειριστές συστημάτων υποδομής.
• NetOps - διαχειριστές δικτύου
• SecOps - διαχειριστές συστημάτων που ειδικεύονται στην ασφάλεια πληροφοριών - συμμόρφωση PCI, συμμόρφωση CIS, επιδιόρθωση κ.λπ.

Το DevOps είναι (θεωρητικά) ένα άτομο που κατανοεί από πρώτο χέρι όλες τις διαδικασίες του κύκλου ανάπτυξης - ανάπτυξη, δοκιμές, κατανοεί την αρχιτεκτονική του προϊόντος, είναι σε θέση να αξιολογεί τους κινδύνους ασφαλείας, είναι εξοικειωμένος με προσεγγίσεις και εργαλεία αυτοματισμού, τουλάχιστον σε υψηλό επίπεδο επίπεδο, εκτός από αυτό, κατανοεί επίσης την υποστήριξη πριν και μετά την επεξεργασία. Ένα άτομο ικανό να ενεργεί ως συνήγορος τόσο για τις Επιχειρήσεις όσο και για την Ανάπτυξη, γεγονός που επιτρέπει την ευνοϊκή συνεργασία μεταξύ αυτών των δύο πυλώνων. Κατανοεί τις διαδικασίες σχεδιασμού της εργασίας από ομάδες και διαχείρισης των προσδοκιών των πελατών.

Για να εκτελέσει αυτού του είδους τις εργασίες και τις ευθύνες, αυτό το άτομο πρέπει να έχει τα μέσα για να διαχειρίζεται όχι μόνο τις διαδικασίες ανάπτυξης και δοκιμών, αλλά και τη διαχείριση της υποδομής του προϊόντος, καθώς και τον προγραμματισμό πόρων. Τα DevOps με αυτήν την κατανόηση δεν μπορούν να εντοπίζονται ούτε στο IT, ούτε στην Ε&Α, ούτε ακόμη και στο PMO· πρέπει να έχουν επιρροή σε όλους αυτούς τους τομείς - ο τεχνικός διευθυντής της εταιρείας, Chief Technical Officer.

Ισχύει αυτό στην εταιρεία σας; - Αμφιβάλλω. Στις περισσότερες περιπτώσεις, πρόκειται είτε για IT είτε για Ε&Α.

Η έλλειψη κεφαλαίων και η ικανότητα επηρεασμού τουλάχιστον ενός από αυτούς τους τρεις τομείς δραστηριότητας θα μετατοπίσει το βάρος των προβλημάτων προς τα σημεία που αυτές οι αλλαγές εφαρμόζονται ευκολότερα, όπως η εφαρμογή τεχνικών περιορισμών στις εκδόσεις σε σχέση με «βρώμικο» κώδικα σύμφωνα με το στατικό συστήματα αναλυτών. Δηλαδή, όταν το PMO ορίζει μια αυστηρή προθεσμία για την κυκλοφορία της λειτουργικότητας, η Ε&Α δεν μπορεί να παράγει ένα αποτέλεσμα υψηλής ποιότητας εντός αυτών των προθεσμιών και το παράγει όσο καλύτερα μπορεί, αφήνοντας την αναδιαμόρφωση για αργότερα, τα DevOps που σχετίζονται με το IT μπλοκάρουν την κυκλοφορία με τεχνικά μέσα . Η έλλειψη εξουσίας να αλλάξει την κατάσταση, στην περίπτωση των υπεύθυνων εργαζομένων, οδηγεί στην εκδήλωση υπερ-ευθύνης για ό,τι δεν μπορούν να επηρεάσουν, ειδικά αν αυτοί οι εργαζόμενοι καταλαβαίνουν και βλέπουν λάθη και πώς να τα διορθώνουν - «Η ευδαιμονία είναι άγνοια». και ως συνέπεια της εξουθένωσης και της απώλειας αυτών των εργαζομένων.

Αγορά πόρων DevOps

Ας δούμε πολλές κενές θέσεις για θέσεις DevOps από διαφορετικές εταιρείες.

Είμαστε έτοιμοι να συναντηθούμε μαζί σας εάν:

1. Είστε ιδιοκτήτης του Zabbix και ξέρετε τι είναι ο Προμηθέας.
2. Iptables;
3. BASH PhD Student;
4. Καθηγητής Ansible;
5. Linux Guru;
6. Να γνωρίζετε πώς να χρησιμοποιείτε τον εντοπισμό σφαλμάτων και να βρίσκετε προβλήματα εφαρμογής μαζί με προγραμματιστές (php/java/python).
7. Η δρομολόγηση δεν σας κάνει υστερικούς.
8. Δώστε ιδιαίτερη προσοχή στην ασφάλεια του συστήματος.
9. Δημιουργήστε αντίγραφα ασφαλείας "οτιδήποτε και όλα" και επίσης επαναφέρετε με επιτυχία αυτό το "οτιδήποτε και τα πάντα".
10. Ξέρετε πώς να διαμορφώσετε το σύστημα με τέτοιο τρόπο ώστε να βγάλετε το μέγιστο από το ελάχιστο.
11. Ρυθμίστε την αναπαραγωγή πριν πάτε για ύπνο σε Postgres και MySQL.
12. Η ρύθμιση και η προσαρμογή του CI/CD είναι τόσο απαραίτητη όσο το πρωινό/μεσημεριανό/βραδινό.
13. Έχετε εμπειρία με το AWS.
14. Έτοιμοι να αναπτυχθούν με την εταιρεία.

Έτσι:

• από 1 έως 6 - διαχειριστής συστήματος
• 7 - λίγη διαχείριση δικτύου, η οποία ταιριάζει επίσης στον διαχειριστή συστήματος, Μέσο επίπεδο
• 8 - λίγη ασφάλεια, η οποία είναι υποχρεωτική για έναν διαχειριστή συστήματος μεσαίου επιπέδου
• 9-11 – Μέσος διαχειριστής συστήματος
• 12 — Ανάλογα με τις εργασίες που έχουν ανατεθεί, είτε Middle System Administrator είτε Build Engineer
• 13 - Virtualization - Middle System Administrator, ή το λεγόμενο CloudOps, προηγμένη γνώση των υπηρεσιών ενός συγκεκριμένου ιστότοπου φιλοξενίας, για την αποτελεσματική χρήση των κεφαλαίων και τη μείωση του φόρτου συντήρησης

Συνοψίζοντας αυτή την κενή θέση, μπορούμε να πούμε ότι ο Middle/Senior Administrator System είναι αρκετός για τα παιδιά.

Παρεμπιπτόντως, δεν πρέπει να διχάζετε έντονα τους διαχειριστές σε Linux/Windows. Φυσικά, καταλαβαίνω ότι οι υπηρεσίες και τα συστήματα αυτών των δύο κόσμων είναι διαφορετικά, αλλά η βάση για όλους είναι η ίδια και κάθε διαχειριστής που σέβεται τον εαυτό του είναι εξοικειωμένος τόσο με το ένα όσο και με το άλλο, και ακόμα κι αν δεν είναι εξοικειωμένος, θα Δεν είναι δύσκολο για έναν ικανό διαχειριστή να εξοικειωθεί με αυτό.

Ας εξετάσουμε μια άλλη κενή θέση:

1. Εμπειρία στην κατασκευή συστημάτων υψηλού φορτίου.
2. Άριστη γνώση Linux OS, γενικού λογισμικού συστήματος και web stack (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
3. Εμπειρία με συστήματα εικονικοποίησης (KVM, VMWare, LXC/Docker).
4. Γνώση σεναρίου.
5. Κατανόηση των αρχών λειτουργίας των δικτύων πρωτοκόλλου δικτύου.
6. Κατανόηση των αρχών κατασκευής συστημάτων ανοχής σε σφάλματα.
7. Ανεξαρτησία και πρωτοβουλία.

Ας δούμε:

• 1 – Ανώτερος διαχειριστής συστήματος
• 2 - Ανάλογα με το νόημα που τίθεται σε αυτήν τη στοίβα - Μέσος/Ανώτερος Διαχειριστής συστήματος
• 3 - Εργασιακή εμπειρία, συμπεριλαμβανομένου, μπορεί να σημαίνει - "Το σύμπλεγμα δεν ανέβασε, αλλά δημιούργησε και διαχειριζόταν εικονικές μηχανές, υπήρχε ένας κεντρικός υπολογιστής Docker, η πρόσβαση σε κοντέινερ δεν ήταν διαθέσιμη" - Middle System Administrator
• 4 - Junior System Administrator - ναι, ένας διαχειριστής που δεν ξέρει πώς να γράφει βασικά σενάρια αυτοματισμού, ανεξάρτητα από τη γλώσσα, όχι ένας διαχειριστής - enikey.
• 5 - Μέσος διαχειριστής συστήματος
• 6 – Ανώτερος διαχειριστής συστήματος

Συνοψίζοντας - Μέσος/Ανώτερος Διαχειριστής συστήματος

Αλλο ένα:

1. Devops εμπειρία?
2. Εμπειρία στη χρήση ενός ή περισσότερων προϊόντων για τη δημιουργία διαδικασιών CI/CD. Το Gitlab CI θα είναι πλεονέκτημα.
3. Εργασία με κοντέινερ και εικονικοποίηση. Αν χρησιμοποιήσατε docker, καλό, αλλά αν χρησιμοποιήσατε k8, υπέροχο!
4. Εμπειρία εργασίας σε ευέλικτη ομάδα.
5. Γνώση οποιασδήποτε γλώσσας προγραμματισμού.

Ας δούμε:

• 1 - Χμμ... Τι εννοούν τα παιδιά; =) Το πιθανότερο είναι ότι οι ίδιοι δεν ξέρουν τι κρύβεται πίσω από αυτό
• 2 - Μηχανικός Δόμησης
• 3 - Μέσος διαχειριστής συστήματος
• 4 - Soft skill, δεν θα το εξετάσουμε προς το παρόν, αν και το Agile είναι ένα άλλο πράγμα που ερμηνεύεται με τρόπο που είναι βολικό.
• 5 - Πολύ περίπλοκο - θα μπορούσε να είναι γλώσσα σεναρίου ή μεταγλωττισμένη. Αναρωτιέμαι αν θα τους ταιριάζει να γράφουν σε Pascal και Basic στο σχολείο; =)

Θα ήθελα επίσης να αφήσω μια σημείωση σχετικά με το σημείο 3, προκειμένου να ενισχυθεί η κατανόηση του γιατί αυτό το σημείο καλύπτεται από τον διαχειριστή του συστήματος. Το Kubernetes είναι απλώς μια ενορχήστρωση, ένα εργαλείο που αναδιπλώνει άμεσες εντολές σε προγράμματα οδήγησης δικτύου και κεντρικούς υπολογιστές εικονικοποίησης/απομόνωσης σε μερικές εντολές και σας επιτρέπει να κάνετε την επικοινωνία μαζί τους αφηρημένη, αυτό είναι όλο. Για παράδειγμα, ας πάρουμε το 'build framework' Make, το οποίο, παρεμπιπτόντως, δεν θεωρώ πλαίσιο. Ναι, ξέρω για τη μόδα του να σπρώχνω το Make οπουδήποτε, όπου είναι απαραίτητο και δεν χρειάζεται - τυλίγοντας το Maven στο Make, για παράδειγμα, σοβαρά;
Ουσιαστικά, το Make είναι απλώς ένα περιτύλιγμα πάνω από το κέλυφος που απλοποιεί τις εντολές μεταγλώττισης, σύνδεσης και περιβάλλοντος μεταγλώττισης, ακριβώς όπως τα k8s.

Κάποτε, πήρα συνέντευξη από έναν τύπο που χρησιμοποίησε k8 στην εργασία του πάνω από το OpenStack και μίλησε για το πώς ανέπτυξε υπηρεσίες σε αυτό, ωστόσο, όταν ρώτησα για το OpenStack, αποδείχθηκε ότι διαχειριζόταν, καθώς και αυξήθηκε από το σύστημα διαχειριστές. Αλήθεια πιστεύετε ότι ένα άτομο που έχει εγκαταστήσει το OpenStack, ανεξάρτητα από την πλατφόρμα που χρησιμοποιεί πίσω του, δεν μπορεί να χρησιμοποιήσει k8s; =)
Αυτός ο αιτών δεν είναι στην πραγματικότητα DevOps, αλλά Διαχειριστής συστήματος και, για να είμαστε πιο ακριβείς, Διαχειριστής Kubernetes.

Ας συνοψίσουμε για άλλη μια φορά - Ο μεσαίος/ανώτερος διαχειριστής συστήματος θα είναι αρκετός για αυτούς.

Πόσο να ζυγίζει σε γραμμάρια

Το εύρος των προτεινόμενων αποδοχών για τις αναγραφόμενες κενές θέσεις είναι 90-200
Τώρα θα ήθελα να κάνω έναν παραλληλισμό μεταξύ των χρηματικών ανταμοιβών των Διαχειριστών Συστήματος και των Μηχανικών DevOps.

Κατ 'αρχήν, για να απλοποιήσετε τα πράγματα, μπορείτε να σκορπίσετε τους βαθμούς με βάση την εργασιακή εμπειρία, αν και αυτό δεν θα είναι ακριβές, αλλά για τους σκοπούς του άρθρου θα είναι αρκετό.

Μια εμπειρία:

1. έως 3 ετών – Junior
2. έως 6 ετών – Μέση
3. περισσότερα από 6 – Ανώτερος

Ο ιστότοπος αναζήτησης εργαζομένων προσφέρει:
Διαχειριστές συστήματος:

1. Junior - 2 ετών - 50k τρίψιμο.
2. Μέση - 5 ετών - 70k τρίψιμο.
3. Senior - 11 ετών - 100k τρίψτε.

Μηχανικοί DevOps:

1. Junior - 2 ετών - 100k τρίψιμο.
2. Μέση - 3 ετών - 160k τρίψιμο.
3. Senior - 6 ετών - 220k τρίψτε.

Σύμφωνα με την εμπειρία του "DevOps", χρησιμοποιήθηκε εμπειρία που τουλάχιστον κατά κάποιο τρόπο επηρέασε το SDLC.

Από τα παραπάνω προκύπτει ότι στην πραγματικότητα οι εταιρείες δεν χρειάζονται DevOps και επίσης ότι θα μπορούσαν να εξοικονομήσουν τουλάχιστον το 50 τοις εκατό των αρχικά προγραμματισμένων δαπανών με την πρόσληψη ενός Διαχειριστή· επιπλέον, θα μπορούσαν να καθορίσουν με μεγαλύτερη σαφήνεια τις ευθύνες του ατόμου που αναζητούν και καλύψτε την ανάγκη πιο γρήγορα. Δεν πρέπει επίσης να ξεχνάμε ότι η σαφής κατανομή των ευθυνών μας επιτρέπει να μειώσουμε τις απαιτήσεις σε προσωπικό, καθώς και να δημιουργήσουμε μια πιο ευνοϊκή ατμόσφαιρα στην ομάδα, λόγω της απουσίας επικαλύψεων. Η συντριπτική πλειονότητα των κενών θέσεων είναι γεμάτη από βοηθητικά προγράμματα και ετικέτες DevOps, αλλά δεν βασίζονται σε πραγματικές απαιτήσεις για έναν Μηχανικό DevOps, αλλά μόνο σε αιτήματα για διαχειριστή εργαλείου.

Η διαδικασία εκπαίδευσης των μηχανικών DevOps περιορίζεται επίσης μόνο σε ένα σύνολο συγκεκριμένων εργασιών, βοηθητικών προγραμμάτων και δεν παρέχει μια γενική κατανόηση των διαδικασιών και των εξαρτήσεών τους. Είναι σίγουρα καλό όταν ένα άτομο μπορεί να αναπτύξει το AWS EKS χρησιμοποιώντας Terraform, σε συνδυασμό με το Fluentd sidecar σε αυτό το σύμπλεγμα και τη στοίβα AWS ELK για το σύστημα καταγραφής σε 10 λεπτά, χρησιμοποιώντας μόνο μία εντολή στην κονσόλα, αλλά αν δεν κατανοεί αρχή της επεξεργασίας των ίδιων των αρχείων καταγραφής και για το τι χρειάζονται, εάν δεν ξέρετε πώς να συλλέγετε μετρήσεις σε αυτά και να παρακολουθείτε την υποβάθμιση της υπηρεσίας, τότε θα εξακολουθεί να είναι το ίδιο enikey που ξέρει πώς να χρησιμοποιεί ορισμένα βοηθητικά προγράμματα.

Η ζήτηση, ωστόσο, δημιουργεί προσφορά και βλέπουμε μια εξαιρετικά υπερθερμανθείσα αγορά για τη θέση DevOps, όπου οι απαιτήσεις δεν αντιστοιχούν στον πραγματικό ρόλο, αλλά επιτρέπουν μόνο στους διαχειριστές του συστήματος να κερδίζουν περισσότερα.

Ποιοι είναι λοιπόν; DevOps ή άπληστοι διαχειριστές συστήματος; =)

Πώς να συνεχίσετε να ζείτε;

Οι εργοδότες θα πρέπει να διατυπώνουν τις απαιτήσεις με μεγαλύτερη ακρίβεια και να αναζητούν ακριβώς αυτούς που χρειάζονται και να μην πετούν ταμπέλες. Δεν ξέρετε τι κάνουν τα DevOps - δεν τα χρειάζεστε σε αυτήν την περίπτωση.

Εργάτες - Μάθε. Βελτιώστε συνεχώς τις γνώσεις σας, δείτε τη συνολική εικόνα των διαδικασιών και παρακολουθήστε την πορεία προς τον στόχο σας. Μπορείς να γίνεις όποιος θέλεις, δεν έχεις παρά να προσπαθήσεις.

Πηγή: www.habr.com