Πρόσφατα, τέτοιες αγγελίες έχουν κατακλύσει το Διαδίκτυο. Παρά τον ευχάριστο μισθό, δεν μπορεί κανείς παρά να μπερδευτεί από την άγρια αίρεση που είναι γραμμένη μέσα. Αρχικά, υποτίθεται ότι οι όροι "DevOps" και "μηχανικός" μπορούν με κάποιο τρόπο να συνδυαστούν σε μία λέξη, και στη συνέχεια υπάρχει μια τυχαία λίστα απαιτήσεων, μερικές από τις οποίες είναι σαφώς αντιγραμμένες από την κενή θέση ενός διαχειριστή συστήματος.
Σε αυτήν την ανάρτηση θα ήθελα να μιλήσω λίγο για το πώς φτάσαμε σε αυτό το σημείο της ζωής μας, τι είναι στην πραγματικότητα το DevOps και τι μπορούμε να κάνουμε με αυτό τώρα.
Τέτοιες κενές θέσεις εργασίας μπορούν να επικριθούν με κάθε τρόπο, αλλά το γεγονός παραμένει: υπάρχουν πολλές από αυτές, και έτσι είναι δομημένη η αγορά αυτή τη στιγμή. Διοργανώσαμε ένα συνέδριο DevOps και δηλώνουμε ανοιχτά: « — όχι για μηχανικούς DevOps". Αυτό θα φανεί παράξενο και τρελό σε πολλούς: γιατί οι άνθρωποι που διοργανώνουν μια εντελώς εμπορική εκδήλωση πηγαίνουν κόντρα στην αγορά. Θα τα εξηγήσουμε όλα τώρα.
Σχετικά με τον πολιτισμό και τις διαδικασίες
Ας ξεκινήσουμε με το γεγονός ότι το DevOps δεν είναι ένας κλάδος της μηχανικής. Όλα ξεκίνησαν με το γεγονός ότι η ιστορικά καθιερωμένη διαίρεση ανά ρόλους δεν λειτουργεί για την ποιότητα των προϊόντων. Όταν οι προγραμματιστές μόνο προγραμματίζουν, αλλά δεν θέλουν να ακούσουν τίποτα για δοκιμές, το λογισμικό είναι γεμάτο σφάλματα. Όταν οι διαχειριστές δεν ενδιαφέρονται για το πώς και γιατί γράφεται το λογισμικό, η υποστήριξη μετατρέπεται σε κόλαση.
Για παράδειγμα, η περιγραφή της διαφοράς μεταξύ των προσεγγίσεων sysadmin και SRE στη διαχείριση υπηρεσιών Ενδιαφέρουσες μελέτες έχουν διεξαχθεί στο πλαίσιο του — είναι σαφές ότι οι καλύτεροι προγραμματιστές καταφέρνουν με κάποιο τρόπο να αναπτύσσουν νέες αλλαγές στην παραγωγή πιο γρήγορα από μία φορά την ώρα. Δεν κάνουν χειροκίνητες δοκιμές σε ποσοστό μεγαλύτερο του 10% (αυτό είναι εμφανές από ). Πώς το κάνουν; «Εξαιρετικά ή πεθαίνετε», αναφέρει ένας από τους τίτλους της έκθεσης. Για μια λεπτομερή συζήτηση αυτών των στατιστικών στοιχείων όσον αφορά τις δοκιμές, ανατρέξτε στην κεντρική ομιλία του Baruch Sadogursky. στο άλλο μας συνέδριο, το Heisenbug.
«Όταν δεν υπάρχει συμφωνία μεταξύ συντρόφων,
Τα πράγματα δεν θα πάνε καλά γι' αυτούς,
Και τίποτα δεν θα προκύψει από αυτό, μόνο βασανιστήρια.
Μια φορά κι έναν καιρό, ένας κύκνος, μια καραβίδα και ένας λούτσος…»
Ποιο ποσοστό προγραμματιστών ιστού πιστεύετε ότι κατανοεί πραγματικά τις συνθήκες υπό τις οποίες χρησιμοποιούνται οι εφαρμογές τους στην παραγωγή; Πόσοι από αυτούς θα πάνε στους διαχειριστές και θα προσπαθήσουν να καταλάβουν τι θα συμβεί εάν η βάση δεδομένων καταρρεύσει; Και ποιοι από αυτούς θα πάνε στους δοκιμαστές και θα ζητήσουν να μάθουν πώς να γράφουν σωστά τεστ; Και υπάρχουν επίσης ειδικοί ασφαλείας, διαχειριστές προϊόντων και ένα σωρό άλλοι άνθρωποι.
Η γενική ιδέα των DevOps είναι η βελτίωση των αλληλεπιδράσεων μεταξύ ρόλων και τμημάτων. Αυτό επιτυγχάνεται κυρίως όχι μέσω κάποιου έξυπνα διαμορφωμένου λογισμικού, αλλά μέσω της πρακτικής της επικοινωνίας. Τα DevOps αφορούν την κουλτούρα, την πρακτική, τη μεθοδολογία και τις διαδικασίες. Δεν υπάρχει ειδικότητα μηχανικής που να απαντά σε αυτά τα ερωτήματα.
Φαύλος κύκλος
Από πού προήλθε τότε ο κλάδος της «μηχανικής devops»; Έχουμε μια θεωρία! Οι ιδέες των DevOps αποδείχθηκαν καλές - τόσο καλές που έγιναν θύματα της ίδιας τους της επιτυχίας. Κάποιοι ύποπτοι στρατολόγοι και διακινητές ανθρώπων άρχισαν να στροβιλίζονται γύρω από όλο αυτό το θέμα, και έχουν τη δική τους ατμόσφαιρα.
Φανταστείτε: χθες φτιάχνατε σαουάρμα στο Χίμκι, και σήμερα είστε ένας μεγάλος σκοπευτής, ένας ανώτερος υπεύθυνος προσλήψεων. Υπάρχει μια ολόκληρη διαδικασία αναζήτησης και επιλογής υποψηφίων, όλα είναι περίπλοκα, πρέπει να καταλάβετε. Ας υποθέσουμε ότι ο επικεφαλής ενός τμήματος λέει: βρείτε έναν ειδικό στο Χ. Προσθέστε τη λέξη «μηχανικός» στο Χ, και τελειώσατε. Χρειάζεστε LinuxΛοιπόν, αυτό είναι σίγουρο. LinuxΑν είστε μηχανικός και θέλετε DevOps, είστε μηχανικός DevOps. Μια αγγελία εργασίας δεν είναι απλώς ένας τίτλος. Πρέπει να συμπεριλάβετε κάποιο κείμενο μέσα. Ο ευκολότερος τρόπος είναι απλώς να πληκτρολογήσετε μια δέσμη λέξεων-κλειδιών Google, όσο πιο δημιουργικά μπορείτε. Το DevOps αποτελείται από δύο λέξεις - "Dev" και "Ops", που σημαίνει ότι πρέπει να συνδυάσετε λέξεις-κλειδιά που σχετίζονται με προγραμματιστές και διαχειριστές, όλες σε ένα μέρος. Έτσι προκύπτουν οι αγγελίες εργασίας με επάρκεια σε 42 γλώσσες προγραμματισμού και 20 χρόνια χρήσης Kubernetes και Swarm ταυτόχρονα. Ακολουθεί ένα λειτουργικό παράδειγμα.
Έτσι έχει ριζώσει στο μυαλό των ανθρώπων η άσκοπη και ανελέητη εικόνα κάποιου είδους υπερήρωα "devops", οι οποίοι θα στήσουν μια ανάπτυξη Jenkins για όλους, και η ευτυχία θα έρθει. Μακάρι όλα να ήταν τόσο απλά. "Και μπορείς να κυνηγάς και sysadmins με αυτόν τον τρόπο", σκέφτεται ο HR, "η λέξη είναι της μόδας, οι λέξεις-κλειδιά είναι οι ίδιες, θα έπρεπε να είναι ελκυστικές".
Η ζήτηση δημιουργεί προσφορά και όλες αυτές οι κενές θέσεις εργασίας καλύφθηκαν με έναν τρελό αριθμό διαχειριστών συστημάτων που συνειδητοποίησαν ότι μπορούσαν να κάνουν τα ίδια πράγματα όπως πριν, αλλά να κερδίζουν αρκετές φορές περισσότερα, αυτοαποκαλούμενοι "devops". Όπως ακριβώς ρυθμίζετε τους διακομιστές μέσω SSH χειροκίνητα έναν προς έναν, έτσι θα συνεχίσετε να τους ρυθμίζετε, αλλά τώρα υποτίθεται ότι είναι μια πρακτική devops. Αυτό είναι ένα είδος σύνθετου φαινομένου, που σχετίζεται εν μέρει με την υποτίμηση των κλασικών διαχειριστών και τη διαφημιστική εκστρατεία γύρω από τα DevOps, αλλά γενικά - ό,τι συνέβη, συνέβη.
Έτσι, έχουμε προσφορά και ζήτηση. Ένας φαύλος κύκλος που τροφοδοτείται από τον εαυτό του. Αυτό ακριβώς καταπολεμούμε (μεταξύ άλλων και με τη δημιουργία του συνεδρίου DevOops).
Φυσικά, εκτός από τους sysadmins που έχουν μετονομαστεί σε "devops", υπάρχουν και άλλοι συμμετέχοντες - για παράδειγμα, επαγγελματίες SRE ή προγραμματιστές Infrastructure-as-Code.
Τι κάνουν οι άνθρωποι στο DevOps (πραγματικά)
Θέλετε, λοιπόν, να προχωρήσετε στην εκμάθηση και την εφαρμογή πρακτικών DevOps. Αλλά πώς να το κάνετε αυτό, προς τα πού να κοιτάξετε; Προφανώς, η τυφλή παρακολούθηση δημοφιλών λέξεων-κλειδιών δεν αξίζει τον κόπο.
Αν υπάρχει δουλειά που πρέπει να γίνει, κάποιος πρέπει να την κάνει. Έχουμε ήδη διαπιστώσει ότι δεν πρόκειται για "μηχανικούς devops", άρα ποιος; Φαίνεται πιο σωστό να το διατυπώσουμε αυτό όχι με βάση τις θέσεις, αλλά με βάση συγκεκριμένους τομείς εργασίας.
Καταρχάς, μπορείτε να αντιμετωπίσετε την καρδιά των DevOps: τις διαδικασίες και την κουλτούρα. Η κουλτούρα είναι κάτι αργό και δύσκολο και, ενώ παραδοσιακά αποτελεί ευθύνη των στελεχών, όλοι, από τους προγραμματιστές μέχρι τους διαχειριστές, εμπλέκονται με τον έναν ή τον άλλον τρόπο. Πριν από μερικούς μήνες, ο Tim Lister :
«Η κουλτούρα καθοδηγείται από τις βασικές αξίες ενός οργανισμού. Οι άνθρωποι συνήθως δεν το παρατηρούν αυτό, αλλά εμείς έχουμε μάθει να το παρατηρούμε στο συμβουλευτικό μας έργο εδώ και πολλά χρόνια. Μπαίνετε σε μια εταιρεία και μέσα σε λίγα λεπτά μπορείτε να μυρίσετε τι συμβαίνει. Το ονομάζουμε «άρωμα». Μερικές φορές το άρωμα είναι πραγματικά καλό. Μερικές φορές είναι αηδιαστικό. (...) Δεν μπορείτε να αλλάξετε την κουλτούρα μέχρι να κατανοήσετε τις αξίες και τις πεποιθήσεις πίσω από τις ενέργειες. Η συμπεριφορά είναι εύκολο να παρατηρηθεί, αλλά οι πεποιθήσεις είναι δύσκολο να βρεθούν. Το DevOps είναι ένα εξαιρετικό παράδειγμα του πώς τα πράγματα γίνονται όλο και πιο περίπλοκα.»
Υπάρχει επίσης ένα τεχνικό μέρος του ζητήματος, φυσικά. Εάν έχετε νέο κώδικα που δοκιμάζεται σε ένα μήνα και τελικά κυκλοφορεί μόνο σε ένα χρόνο και είναι φυσικά αδύνατο να επιταχυνθεί, μπορεί να μην ζήσετε για να δείτε καλές πρακτικές. Οι καλές πρακτικές υποστηρίζονται από καλά εργαλεία. Για παράδειγμα, έχοντας κατά νου την ιδέα της Υποδομής ως Κώδικα, μπορείτε να χρησιμοποιήσετε οτιδήποτε, από το AWS CloudFormation και το Terraform μέχρι το Chef-Ansible-Puppet. Πρέπει να γνωρίζετε και να είστε σε θέση να κάνετε όλα αυτά, και αυτό είναι ήδη ένας εντελώς μηχανικός κλάδος. Είναι σημαντικό να μην συγχέετε την αιτία και το αποτέλεσμα: πρώτον, εργάζεστε σύμφωνα με τις αρχές του SRE και μόνο στη συνέχεια εφαρμόζετε αυτές τις αρχές με τη μορφή ορισμένων συγκεκριμένων τεχνικών λύσεων. Ταυτόχρονα, το SRE είναι μια πολύπλοκη μεθοδολογία που δεν σας λέει πώς να ρυθμίσετε το Jenkins, αλλά περίπου πέντε κύριες αρχές:
- Βελτίωση της συνεργασίας μεταξύ ρόλων και τμημάτων
- Αποδοχή λαθών ως αναπόσπαστο κομμάτι της εργασίας
- Σταδιακή εφαρμογή αλλαγών
- Χρήση εργαλείων και άλλων αυτοματισμών
- Μέτρηση όλων όσων μπορούν να μετρηθούν
Αυτό δεν είναι απλώς ένα σύνολο δηλώσεων, αλλά ένα συγκεκριμένο. Για παράδειγμα, στην πορεία προς την αποδοχή λαθών, θα πρέπει να κατανοήσετε τους κινδύνους, να μετρήσετε τη διαθεσιμότητα και τη μη διαθεσιμότητα των υπηρεσιών χρησιμοποιώντας κάτι σαν το SLI () και SLO (), μάθετε πώς να γράφετε μεταθανάτιες αναλύσεις και βεβαιωθείτε ότι η συγγραφή τους δεν είναι τρομακτική.
Στον κλάδο της SRE, η χρήση εργαλείων είναι μόνο ένα μέρος της επιτυχίας, αλλά σημαντικό. Πρέπει να εξελισσόμαστε συνεχώς τεχνικά, να εξετάζουμε τι συμβαίνει στον κόσμο και πώς μπορεί να εφαρμοστεί στην εργασία μας.
Με τη σειρά τους, οι λύσεις Cloud Native έχουν γίνει πλέον πολύ δημοφιλείς. Σύμφωνα με τη σύγχρονη αντίληψη του Cloud Native Computing Foundation, οι τεχνολογίες Cloud Native επιτρέπουν στους οργανισμούς να αναπτύσσουν και να εκτελούν κλιμακούμενες εφαρμογές σε σύγχρονα δυναμικά περιβάλλοντα, όπως δημόσια, ιδιωτικά και υβριδικά cloud. Παραδείγματα περιλαμβάνουν containers, service meshes, microservices, immutable infrastructure και declarative APIs. Όλες αυτές οι τεχνικές επιτρέπουν στα χαλαρά συνδεδεμένα συστήματα να παραμένουν ελαστικά, διαχειρίσιμα και εύκολα παρατηρήσιμα. Ο καλός αυτοματισμός επιτρέπει στους μηχανικούς να κάνουν μεγάλες αλλαγές συχνά και με προβλέψιμα αποτελέσματα, χωρίς να τις μετατρέπουν σε κόλαση. Όλα αυτά υποστηρίζονται από μια στοίβα γνωστών εργαλείων, όπως το Docker και το Kubernetes.
Αυτός ο μάλλον περίπλοκος και ευρύς ορισμός συνδέεται με το γεγονός ότι ο τομέας είναι μάλλον περίπλοκος. Αφενός, υποστηρίζεται ότι οι νέες αλλαγές σε αυτό το σύστημα θα πρέπει να προστίθενται αρκετά εύκολα. Αφετέρου, για να κατανοήσουμε πώς να δημιουργήσουμε ένα περιβάλλον με κοντέινερ στο οποίο οι χαλαρά συνδεδεμένες υπηρεσίες βρίσκονται σε μια υποδομή που ορίζεται από λογισμικό και παρέχονται εκεί χρησιμοποιώντας συνεχή CI/CD, και για να δημιουργήσουμε πρακτικές DevOps γύρω από όλα αυτά, πρέπει να τα βάλουμε όλα σε αυτό.
Τι να κάνεις με όλα αυτά;
Ο καθένας λύνει αυτά τα προβλήματα με τον δικό του τρόπο: για παράδειγμα, μπορείτε να δημοσιεύσετε κανονικές κενές θέσεις εργασίας για να σπάσετε τον φαύλο κύκλο. Μπορείτε να καταλάβετε τι σημαίνουν λέξεις όπως DevOps και Cloud Native και να τις χρησιμοποιήσετε σωστά και εύστοχα. Μπορείτε να αναπτύξετε το DevOps και να δείξετε τις σωστές προσεγγίσεις με το παράδειγμά σας.
Διοργανώνουμε ένα συνέδριο. , η οποία παρέχει την ευκαιρία να εμβαθύνουμε σε ό,τι μόλις συζητήσαμε. Υπάρχουν διάφορες ομάδες αναφορών για τον σκοπό αυτό:
- Διαδικασίες και πολιτισμός;
- Μηχανική Αξιοπιστίας Ιστοτόπου;
- Cloud Native;
Πώς επιλέγετε πού θα πάτε; Υπάρχει ένα λεπτό σημείο εδώ. Από τη μία πλευρά, το DevOps αφορά τη συνεργασία και θέλουμε πραγματικά να παρακολουθήσετε ομιλίες από διαφορετικά τμήματα. Από την άλλη πλευρά, αν είστε υπεύθυνος ανάπτυξης που ήρθε στο συνέδριο για να επικεντρωθεί σε μια συγκεκριμένη εργασία, τότε κανείς δεν σας περιορίζει - προφανώς, αυτό θα είναι το τμήμα που αφορά τις διαδικασίες και την κουλτούρα. Μην ξεχνάτε ότι μετά το συνέδριο θα έχετε σημειώσεις (αφού συμπληρώσετε τη φόρμα σχολίων), ώστε να μπορείτε πάντα να παρακολουθήσετε λιγότερο σημαντικές ομιλίες αργότερα.
Προφανώς, στο ίδιο το συνέδριο δεν μπορείς να πας σε τρία κομμάτια ταυτόχρονα, επομένως διαμορφώνουμε το πρόγραμμα έτσι ώστε κάθε χρονική ζώνη να έχει θέματα για κάθε γούστο.
Τώρα είναι η ώρα να καταλάβετε τι πρέπει να κάνετε αν είστε μηχανικός DevOps! Αρχικά, προσπαθήστε να ορίσετε τι πραγματικά κάνετε. Συνήθως, αυτή η λέξη χρησιμοποιείται για να περιγράψει:
- Προγραμματιστές που εργάζονται σε υποδομές. Οι ομάδες συζήτησης SRE και Cloud Native είναι οι πιο κατάλληλες για εσάς.
- Διαχειριστές συστημάτων. Αυτό είναι πιο περίπλοκο. Το DevOops δεν αφορά τη διαχείριση συστημάτων. Ευτυχώς, υπάρχουν πολλά εξαιρετικά συνέδρια, βιβλία, άρθρα, βίντεο στο Διαδίκτυο κ.λπ. σχετικά με το θέμα της διαχείρισης συστημάτων. Από την άλλη πλευρά, αν ενδιαφέρεστε να αναπτυχθείτε όσον αφορά την κατανόηση της κουλτούρας και των διαδικασιών, τη μελέτη των τεχνολογιών cloud και τις λεπτομέρειες της ζωής με το Cloud Native, τότε θα χαρούμε να σας δούμε! Σκεφτείτε το: κάνετε διαχείριση και τι θα κάνετε στη συνέχεια; Για να μην βρεθείτε ξαφνικά σε μια δυσάρεστη κατάσταση, αξίζει να μάθετε τώρα.
Υπάρχει και μια άλλη επιλογή: επιμένεις και συνεχίζεις να ισχυρίζεσαι ότι είσαι συγκεκριμένα ως μηχανικός DevOps και τίποτα άλλο, ό,τι κι αν σημαίνει αυτό. Τότε πρέπει να σας απογοητεύσουμε, το DevOops δεν είναι ένα συνέδριο για μηχανικούς DevOps!
Σύρετε από στο Μόναχο
Το DevOops 2020 Moscow θα πραγματοποιηθεί στις 29-30 Απριλίου στη Μόσχα, τα εισιτήρια είναι ήδη διαθέσιμα. .
Εναλλακτικά, μπορείτε έως τις 8 Φεβρουαρίου. Λάβετε υπόψη ότι κατά τη συμπλήρωση της φόρμας, πρέπει να επιλέξετε το κοινό-στόχο που θα επωφεληθεί περισσότερο από την αναφορά σας (Υπάρχει μια έκπληξη θαμμένη μέσα στη λίστα).
Πηγή: www.habr.com
