Πρόσφατα, τέτοιες διαφημίσεις έχουν κατακλύσει το Διαδίκτυο. Παρά τον ευχάριστο μισθό, δεν μπορεί κανείς να μην ντρέπεται που μέσα είναι γραμμένη άγρια αίρεση. Αρχικά υποτίθεται ότι το "DevOps" και το "engineer" μπορούν με κάποιο τρόπο να κολληθούν μαζί σε μια λέξη και, στη συνέχεια, υπάρχει μια τυχαία λίστα απαιτήσεων, ορισμένες από τις οποίες αντιγράφονται σαφώς από την κενή θέση του sysadmin.
Σε αυτήν την ανάρτηση θα ήθελα να μιλήσω λίγο για το πώς φτάσαμε σε αυτό το σημείο της ζωής, τι είναι πραγματικά το DevOps και τι να το κάνουμε τώρα.
Τέτοιες κενές θέσεις μπορούν να καταδικαστούν με κάθε δυνατό τρόπο, αλλά το γεγονός παραμένει: υπάρχουν πολλές από αυτές, και έτσι λειτουργεί η αγορά αυτή τη στιγμή. Πραγματοποιήσαμε μια διάσκεψη devops και δηλώνουμε ανοιχτά: - όχι για μηχανικούς DevOps." Αυτό θα φανεί περίεργο και άγριο σε πολλούς: γιατί οι άνθρωποι που κάνουν μια εντελώς εμπορική εκδήλωση πηγαίνουν κόντρα στην αγορά. Τώρα θα τα εξηγήσουμε όλα.
Σχετικά με τον πολιτισμό και τις διαδικασίες
Ας ξεκινήσουμε με το γεγονός ότι το DevOps δεν είναι κλάδος μηχανικής. Όλα ξεκίνησαν από το γεγονός ότι η ιστορικά καθιερωμένη κατανομή ρόλων δεν λειτουργεί για την ποιότητα των προϊόντων. Όταν οι προγραμματιστές προγραμματίζουν μόνο, αλλά δεν θέλουν να ακούσουν τίποτα για τη δοκιμή, το λογισμικό είναι γεμάτο σφάλματα. Όταν οι διαχειριστές δεν ενδιαφέρονται για το πώς ή γιατί είναι γραμμένο το λογισμικό, η υποστήριξη μετατρέπεται σε κόλαση.
Για παράδειγμα, περιγράφοντας τη διαφορά μεταξύ ενός διαχειριστή συστήματος και μιας προσέγγισης SRE στη διαχείριση υπηρεσιών . Ενδιαφέρουσες μελέτες έχουν πραγματοποιηθεί εντός — είναι σαφές ότι οι καλύτεροι προγραμματιστές καταφέρνουν με κάποιο τρόπο να αναπτύξουν νέες αλλαγές στην παραγωγή γρηγορότερα από μία φορά την ώρα. Δοκιμάζουν με τα χέρια τους όχι περισσότερο από 10% (αυτό φαίνεται από ). Πώς το κάνουν αυτό; «Excel or die» λέει ένας από τους τίτλους της έκθεσης. Για μια λεπτομερή συζήτηση αυτών των στατιστικών στο πλαίσιο των δοκιμών, μπορείτε να ανατρέξετε στην κεντρική ομιλία του Baruch Sadogursky στο άλλο συνέδριό μας, το Heisenbug.
«Όταν δεν υπάρχει συμφωνία μεταξύ των συντρόφων,
Οι δουλειές τους δεν θα πάνε καλά,
Και δεν θα βγει τίποτα από αυτό, μόνο αλεύρι.
Μια φορά κι έναν καιρό ένας Κύκνος, μια Καραβίδα και ένας Λούτσος...»
Ποιο μέρος των προγραμματιστών Ιστού πιστεύετε ότι κατανοεί πραγματικά τις συνθήκες υπό τις οποίες χρησιμοποιούνται οι εφαρμογές τους στην παραγωγή; Πόσοι από αυτούς θα πάνε στους διαχειριστές και θα προσπαθήσουν να καταλάβουν τι θα συμβεί εάν η βάση δεδομένων διακοπεί; Και ποιος από αυτούς θα πάει στους δοκιμαστές και θα τους ζητήσει να τους μάθουν πώς να γράφουν σωστά τεστ; Και υπάρχουν επίσης φύλακες, διαχειριστές προϊόντων και ένα σωρό άλλα άτομα.
Η συνολική ιδέα του DevOps είναι να δημιουργήσει συνεργασία μεταξύ ρόλων και τμημάτων. Πρώτα απ 'όλα, αυτό δεν επιτυγχάνεται με κάποιο έξυπνα διαμορφωμένο λογισμικό, αλλά με την πρακτική της επικοινωνίας. Το DevOps αφορά την κουλτούρα, τις πρακτικές, τη μεθοδολογία και τις διαδικασίες. Δεν υπάρχει ειδικότητα μηχανικού που να μπορεί να απαντήσει σε αυτά τα ερωτήματα.
Φαύλος κύκλος
Από πού προήλθε τότε η πειθαρχία της «devops engineering»; Έχουμε μια έκδοση! Οι ιδέες DevOps ήταν καλές—τόσο καλές που έγιναν θύματα της δικής τους επιτυχίας. Κάποιοι σκιεροί στρατολόγοι και διακινητές ανθρώπων, που έχουν τη δική τους ατμόσφαιρα, άρχισαν να στροβιλίζονται γύρω από όλο αυτό το θέμα.
Φανταστείτε: χθες φτιάχνατε shawarma στο Khimki, και σήμερα είστε ήδη μεγάλος άνδρας, ανώτερος υπάλληλος προσλήψεων. Υπάρχει μια ολόκληρη διαδικασία αναζήτησης και επιλογής υποψηφίων, δεν είναι όλα εύκολα, πρέπει να καταλάβετε. Ας πούμε ότι ο επικεφαλής ενός τμήματος λέει: βρείτε έναν ειδικό στο Χ. Αντιστοιχίζουμε τη λέξη «μηχανικός» στο Χ και τελειώσαμε. Χρειάζεστε Linux; Λοιπόν, αυτός είναι σίγουρα ένας μηχανικός Linux, αν θέλετε DevOps, τότε ένας μηχανικός DevOps. Η κενή θέση δεν αποτελείται μόνο από τίτλο, αλλά και κάποιο κείμενο πρέπει να εισαχθεί μέσα. Ο πιο εύκολος τρόπος είναι να εισαγάγετε ένα σύνολο λέξεων-κλειδιών από την Google, ανάλογα με τη φαντασία σας. Το DevOps αποτελείται από δύο λέξεις - "Dev" και "Ops", που σημαίνει ότι πρέπει να κολλήσουμε λέξεις-κλειδιά που σχετίζονται με προγραμματιστές και διαχειριστές, όλες σε ένα σωρό. Έτσι εμφανίζονται κενές θέσεις σχετικά με την επάρκεια σε 42 γλώσσες προγραμματισμού και 20 χρόνια χρήσης του Kubernetes και του Swarm ταυτόχρονα. Διάγραμμα εργασίας.
Έτσι έχει ριζώσει στο μυαλό των ανθρώπων η ανούσια και ανελέητη εικόνα ενός συγκεκριμένου υπερήρωα «devops», ο οποίος θα διαμορφώσει τους πάντες για να αναπτυχθούν στον Jenkins και η ευτυχία θα έρθει. Αχ, να ήταν όλα τόσο απλά. «Και αυτός είναι επίσης ο τρόπος με τον οποίο μπορείτε να κυνηγήσετε τους διαχειριστές συστημάτων», σκέφτεται ο HR, «είναι μια λέξη της μόδας, οι λέξεις-κλειδιά είναι ίδιες, θα πρέπει να κάνουν το δόλωμα».
Η ζήτηση δημιουργεί προσφορά και όλες αυτές οι κενές θέσεις σκουπιδιών έχουν γεμίσει με έναν τρελό αριθμό διαχειριστών συστήματος που συνειδητοποίησαν: μπορείτε να κάνετε τα πάντα όπως πριν, αλλά να πάρετε πολλές φορές περισσότερα αποκαλώντας τον εαυτό σας "devops". Ακριβώς όπως ρυθμίσατε τους διακομιστές μέσω SSH χειροκίνητα έναν κάθε φορά, θα συνεχίσετε να τους διαμορφώνετε, αλλά τώρα αυτό υποτίθεται ότι είναι μια πρακτική devops. Αυτό είναι ένα είδος περίπλοκου φαινομένου, που σχετίζεται εν μέρει με την υποτίμηση των κλασικών διαχειριστών και τη διαφημιστική εκστρατεία γύρω από τα DevOps, αλλά γενικά, αυτό που συνέβη, συνέβη.
Άρα έχουμε προσφορά και ζήτηση. Ένας φαύλος κύκλος που τρέφεται μόνος του. Αυτό είναι που αγωνιζόμαστε (συμπεριλαμβανομένης της δημιουργίας του συνεδρίου DevOops).
Φυσικά, εκτός από τους διαχειριστές συστήματος που έχουν μετονομαστεί σε "devops", υπάρχουν και άλλοι συμμετέχοντες - για παράδειγμα, επαγγελματίες SRE ή προγραμματιστές Infrastructure-as-Code.
Τι κάνουν οι άνθρωποι στο DevOps (πραγματικά)
Θέλετε λοιπόν να προχωρήσετε στην εκμάθηση και την εφαρμογή πρακτικών DevOps. Αλλά πώς να το κάνετε αυτό, προς ποια κατεύθυνση να κοιτάξετε; Προφανώς, δεν πρέπει να βασίζεστε τυφλά σε δημοφιλείς λέξεις-κλειδιά.
Αν υπάρχει δουλειά, κάποιος να την κάνει. Έχουμε ήδη ανακαλύψει ότι αυτοί δεν είναι «μηχανικοί devops», τότε ποιοι είναι; Φαίνεται πιο σωστό να διατυπωθεί αυτό όχι με όρους θέσεων, αλλά με όρους συγκεκριμένων τομέων εργασίας.
Πρώτον, μπορείτε να απευθυνθείτε στην καρδιά του DevOps—διαδικασίες και κουλτούρα. Ο πολιτισμός είναι μια αργή και δύσκολη επιχείρηση, και παρόλο που παραδοσιακά είναι ευθύνη των μάνατζερ, όλοι εμπλέκονται με τον ένα ή τον άλλο τρόπο, από προγραμματιστές μέχρι διαχειριστές. Πριν από μερικούς μήνες ο Τιμ Λίστερ :
«Ο πολιτισμός καθορίζεται από τις βασικές αξίες του οργανισμού. Συνήθως οι άνθρωποι δεν το προσέχουν αυτό, αλλά έχοντας εργαστεί στη συμβουλευτική για πολλά χρόνια, έχουμε συνηθίσει να το παρατηρούμε. Μπαίνεις σε μια παρέα και κυριολεκτικά μέσα σε λίγα λεπτά αρχίζεις να νιώθεις τι συμβαίνει. Αυτό το λέμε «γεύση». Μερικές φορές αυτό το άρωμα είναι πραγματικά καλό. Μερικές φορές προκαλεί ναυτία. (...) Δεν μπορείτε να αλλάξετε μια κουλτούρα μέχρι να γίνουν κατανοητές οι αξίες και οι πεποιθήσεις πίσω από συγκεκριμένες ενέργειες. Η συμπεριφορά είναι εύκολο να παρατηρηθεί, αλλά η αναζήτηση πεποιθήσεων είναι δύσκολη. Το DevOps είναι απλώς ένα εξαιρετικό παράδειγμα του πώς τα πράγματα γίνονται όλο και πιο περίπλοκα».
Υπάρχει βέβαια και το τεχνικό κομμάτι του θέματος. Εάν ο νέος σας κώδικας δοκιμαστεί σε ένα μήνα, αλλά κυκλοφορήσει μόνο ένα χρόνο αργότερα και είναι φυσικά αδύνατο να επιταχυνθεί όλο αυτό, μπορεί να μην ανταποκριθείτε στις καλές πρακτικές. Οι καλές πρακτικές υποστηρίζονται από καλά εργαλεία. Για παράδειγμα, έχοντας κατά νου την ιδέα του Infrastructure-as-Code, μπορείτε να χρησιμοποιήσετε οτιδήποτε, από το AWS CloudFormation και το Terraform έως το Chef-Ansible-Puppet. Πρέπει να τα ξέρεις και να μπορείς να τα κάνεις όλα αυτά, και αυτό είναι ήδη αρκετά μηχανικός κλάδος. Είναι σημαντικό να μην συγχέετε την αιτία με το αποτέλεσμα: πρώτα εργάζεστε σύμφωνα με τις αρχές του SRE και μόνο μετά εφαρμόζετε αυτές τις αρχές με τη μορφή ορισμένων συγκεκριμένων τεχνικών λύσεων. Ταυτόχρονα, το SRE είναι μια πολύ ολοκληρωμένη μεθοδολογία που δεν σας λέει πώς να ρυθμίσετε το Jenkins, αλλά για πέντε βασικές αρχές:
- Βελτιωμένη επικοινωνία μεταξύ ρόλων και τμημάτων
- Η αποδοχή των λαθών ως αναπόσπαστο μέρος της δουλειάς
- Κάνοντας αλλαγές σταδιακά
- Χρήση εργαλείων και άλλων αυτοματισμών
- Μετρώντας όλα όσα μπορούν να μετρηθούν
Αυτό δεν είναι απλώς ένα σύνολο δηλώσεων, αλλά ένα συγκεκριμένο . Για παράδειγμα, στην πορεία προς την αποδοχή σφαλμάτων, θα χρειαστεί να κατανοήσετε τους κινδύνους, να μετρήσετε τη διαθεσιμότητα και τη μη διαθεσιμότητα υπηρεσιών χρησιμοποιώντας κάτι σαν το SLI () και SLO (), μάθετε να γράφετε μεταθανάτια και κάντε τη γραφή τους να μην είναι τρομακτική.
Στον κλάδο SRE, η χρήση εργαλείων είναι μόνο ένα μέρος της επιτυχίας, αν και σημαντικό. Πρέπει να εξελισσόμαστε συνεχώς τεχνικά, να κοιτάμε τι συμβαίνει στον κόσμο και πώς μπορεί να εφαρμοστεί στη δουλειά μας.
Με τη σειρά τους, οι λύσεις Cloud Native έχουν γίνει πλέον πολύ δημοφιλείς. Όπως ορίζεται σήμερα από το Cloud Native Computing Foundation, οι τεχνολογίες Cloud Native επιτρέπουν στους οργανισμούς να αναπτύσσουν και να εκτελούν επεκτάσιμες εφαρμογές στα σημερινά δυναμικά περιβάλλοντα, όπως δημόσια, ιδιωτικά και υβριδικά σύννεφα. Παραδείγματα περιλαμβάνουν κοντέινερ, πλέγματα υπηρεσιών, μικροϋπηρεσίες, αμετάβλητη υποδομή και δηλωτικά API. Όλες αυτές οι τεχνικές επιτρέπουν στα χαλαρά συζευγμένα συστήματα να παραμένουν ελαστικά, διαχειρίσιμα και εξαιρετικά παρατηρήσιμα. Ο καλός αυτοματισμός επιτρέπει στους μηχανικούς να κάνουν μεγάλες αλλαγές συχνά και με προβλέψιμα αποτελέσματα χωρίς να το κάνουν αγγαρεία. Όλα αυτά υποστηρίζονται από μια στοίβα γνωστών εργαλείων όπως το 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