Πρόσφατα παρακολούθησα το DevOpsForum 2019, με οικοδεσπότη τη Logrocon. Σε αυτό το συνέδριο, οι συμμετέχοντες προσπάθησαν να βρουν λύσεις και νέα εργαλεία για αποτελεσματική αλληλεπίδραση μεταξύ των επιχειρήσεων και των ειδικών στην ανάπτυξη και στις υπηρεσίες πληροφορικής.
Το συνέδριο στέφθηκε με επιτυχία: υπήρχαν πραγματικά πολλές χρήσιμες αναφορές, ενδιαφέρουσες μορφές παρουσιάσεων και πολλή επικοινωνία με τους ομιλητές. Και είναι ιδιαίτερα σημαντικό ότι κανείς δεν προσπάθησε να μου πουλήσει τίποτα, κάτι για το οποίο φταίνε οι ομιλητές σε μεγάλα συνέδρια τον τελευταίο καιρό.
Ένα απόσπασμα από τις ομιλίες της Raiffeisenbank, της Alfastrakhovanie, της εμπειρίας της Mango Telecom στην εφαρμογή αυτοματισμών και άλλες λεπτομέρειες κάτω από το κόψιμο.
Με λένε Yana, εργάζομαι ως δοκιμαστής, κάνω αυτοματισμούς, καθώς και DevOps και μου αρέσει να πηγαίνω σε συνέδρια και συναντήσεις. Τα τελευταία δύο χρόνια, έχω πάει σε συνέδρια του Oleg Bunin (HighLoad++, TeamLead Conf), Jug events (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
Πρώτα απ 'όλα, εφιστώ την προσοχή στο πρόγραμμα του συνεδρίου. Κοιτάζω λιγότερο το τι θα αφορά η έκθεση και περισσότερο τον ομιλητή. Ακόμα κι αν η αναφορά αποδειχθεί πολύ τεχνολογική και ενδιαφέρουσα, δεν είναι γεγονός ότι θα μπορείτε να εφαρμόσετε μερικές από τις βέλτιστες πρακτικές από την αναφορά στην εταιρεία σας. Και τότε χρειάζεστε ένα ηχείο.
Φως στο τέλος του αγωγού στη Raiffeisenbank
Συνήθως, κυνηγάω ηχεία στο περιθώριο που με ενδιαφέρουν. Στο DevOpsForum 2019, ένας ομιλητής από τη Raiffeisenbank, ο Mikhail Bizhan, τράβηξε το ενδιαφέρον μου. Κατά τη διάρκεια της ομιλίας του, μίλησε για το πώς γαντζώνουν σταδιακά τις ομάδες τους στο DevOps, γιατί το χρειάζονται και πώς να πουλήσουν την ιδέα του μετασχηματισμού του DevOps στις επιχειρήσεις. Λοιπόν, γενικά, μίλησα για το πώς να δω το φως στο τέλος του αγωγού.
Mikhail Bizhan, διευθυντής αυτοματισμού στη Raiffeisenbank
Τώρα δεν έχουν "DevOps" στην εταιρεία τους. Δουλεύει δηλαδή, αλλά όχι σε όλες τις ομάδες. Κατά την εφαρμογή του DevOps, βασίζονται στην ετοιμότητα των ομάδων, τόσο από την άποψη των συγκεκριμένων μηχανικών, όσο και από την άποψη της ανάγκης του προϊόντος και της ωριμότητας της πλατφόρμας στην οποία είναι χτισμένο αυτό το προϊόν. Ο Misha είπε πώς να εξηγήσει σε μια επιχείρηση γιατί χρειάζεται το DevOps.
Ο τραπεζικός τομέας έχει πολλούς παράγοντες ανάπτυξης: κόστος υπηρεσιών και επέκταση της πελατειακής βάσης. Η αύξηση του κόστους των υπηρεσιών δεν είναι πολύ καλός οδηγός, αλλά η αύξηση της πελατειακής βάσης είναι το αντίθετο. Εάν οι ανταγωνιστές κυκλοφορούν ένα αντικειμενικά δροσερό προϊόν, όλοι οι πελάτες πηγαίνουν εκεί, τότε με την πάροδο του χρόνου η αγορά ισοπεδώνεται. Επομένως, η εισαγωγή νέων προϊόντων στην αγορά και η ταχύτητα εισαγωγής τους είναι το κύριο πράγμα στο οποίο εστιάζουν οι τράπεζες. Αυτό ακριβώς είναι το DevOps και οι επιχειρήσεις το καταλαβαίνουν αυτό.
Η επόμενη σημαντική σημείωση: Το DevOps δεν μειώνει πάντα το χρόνο στην αγορά. Το DevOps δεν μπορεί να λειτουργήσει μόνο του, είναι απλώς μέρος της διαδικασίας δημιουργίας και διάθεσης ενός προϊόντος στην αγορά από την ανάπτυξη στην παραγωγή (από τον κώδικα στον πελάτη). Αλλά όλα πριν από τον κώδικα δεν σχετίζονται άμεσα με το DevOps. Δηλαδή, οι έμποροι μπορούν να μελετήσουν την αγορά για χρόνια και να περάσουν ολόκληρη τη ζωή τους προσεγγίζοντας τους ανταγωνιστές. Είναι απαραίτητο να κατανοήσετε γρήγορα τι χρειάζεται ο πελάτης και να σχεδιάσετε την εφαρμογή αυτού ή εκείνου του χαρακτηριστικού - συχνά αυτό δεν είναι αρκετό για να λειτουργήσει το DevOps και η εταιρεία να επιτύχει τον στόχο της. Επομένως, πρώτα απ 'όλα, η Raiffeisenbank συμφώνησε με τις επιχειρήσεις ότι ήταν απαραίτητο να μάθουμε πώς να χρησιμοποιείτε το DevOps. Ο αυτοματισμός για χάρη του αυτοματισμού δεν θα βοηθήσει πολύ στον αγώνα για νέους πελάτες.
Γενικά, ο Misha πιστεύει ότι το DevOps πρέπει να εφαρμοστεί, αλλά με σύνεση. Και πρέπει να είμαστε προετοιμασμένοι για το γεγονός ότι στην αρχή του μετασχηματισμού η παραγωγικότητα της ομάδας θα πέσει, θα κερδίσει λιγότερα χρήματα, αλλά στη συνέχεια θα δικαιωθεί.
Αυτοματοποίηση δοκιμών στην Mango Telecom
Μια άλλη ενδιαφέρουσα αναφορά για εμένα ως δοκιμαστή έδωσε ο Egor Maslov από την Mango Telecom. Η παρουσίαση ονομάστηκε «Αυτοματοποίηση του πλήρους κύκλου δοκιμών σε μια ομάδα SCRUM». Ο Egor πιστεύει ότι το DevOps δημιουργήθηκε ειδικά για το SCRUM, αλλά την ίδια στιγμή, η εισαγωγή του DevOps σε μια ομάδα SCRUM είναι αρκετά προβληματική. Αυτό συμβαίνει επειδή η ομάδα SCRUM τρέχει πάντα κάπου, δεν υπάρχει χρόνος να αποσπαστεί η προσοχή από τις καινοτομίες και να ξαναχτίσετε τη διαδικασία. Το πρόβλημα έγκειται επίσης στο γεγονός ότι το SCRUM δεν περιλαμβάνει τον διαχωρισμό των υπο-ομάδων στην ομάδα (ομάδα δοκιμής, ομάδα ανάπτυξης κ.λπ.). Λοιπόν, επιπλέον, για να αυτοματοποιηθεί μια υπάρχουσα διαδικασία, απαιτείται τεκμηρίωση και στο SCRUM, τις περισσότερες φορές δεν υπάρχει πλήρης τεκμηρίωση - "το προϊόν είναι πιο σημαντικό από κάποιο είδος γραφής".
Μετά τη μετάβαση στο SCRUM, οι υπεύθυνοι δοκιμών άρχισαν να διαβουλεύονται με προγραμματιστές σχετικά με τον τρόπο δοκιμής των δυνατοτήτων. Σταδιακά, ο όγκος της λειτουργικότητας αυξήθηκε, δεν υπήρχε τεκμηρίωση και άρχισαν να πιάνουν πολλά σφάλματα στη λειτουργικότητα που δεν καλύπτονταν από δοκιμές και γενικά δεν ήταν πλέον σαφές ποιος το δοκίμασε και πότε. Με λίγα λόγια - σύγχυση και αμφιταλαντεύσεις. Αποφασίσαμε να στραφούμε στον αυτοματισμό δοκιμών. Αλλά και τότε υπήρξε μια πλήρης αποτυχία. Προσέλαβαν ειδικούς αυτοματισμού σε εξωτερικούς συνεργάτες που έγραφαν σε μια στοίβα άγνωστη στους εσωτερικούς δοκιμαστές. Το πλαίσιο για τις αυτόματες δοκιμές λειτούργησε, φυσικά, αλλά μετά την αποχώρηση των εξωτερικών συνεργατών, κράτησε δύο εβδομάδες. Στη συνέχεια έγινε μια προσπάθεια εισαγωγής του αυτόματου ελέγχου νούμερο δύο. Ξεκίνησε με το γεγονός ότι όλα πρέπει να χτιστούν μέσα στην εταιρεία, μόνοι σου (το σωστό διάνυσμα: να αποκτήσεις τεχνογνωσία εσωτερικά), στο πλαίσιο του SCRUM και να δημιουργήσεις τεκμηρίωση στη διαδικασία. Η στοίβα για αυτοματισμό θα πρέπει να είναι ίση με τη στοίβα του προϊόντος (εδώ την προσθέτω, μην δοκιμάσετε το έργο JavaScript με οτιδήποτε άλλο). Στο τέλος του σπριντ, έκαναν ένα demo για το πώς λειτουργεί το autotest με όλη την ομάδα (χρήσιμο). Έτσι, αυξήθηκε η συμμετοχή όλων των μελών της ομάδας στη διαδικασία αυτοματισμού, καθώς και η εμπιστοσύνη στα autotests και η πιθανότητα να χρησιμοποιηθεί σίγουρα αυτό το autotest (και δεν θα σχολιαστεί σε ένα μήνα λόγω συνεχών αποτυχιών).
Παρεμπιπτόντως, στο DevOpsForum 2019 υπήρχε ένα ανοιχτό μικρόφωνο - μια γνωστή και, κατά τη γνώμη μου, χρήσιμη μορφή ομιλιών. Περπατάτε έτσι, ακούτε αναφορές και μετά αποφασίζετε ότι στη διάσκεψη αξίζει να συζητήσετε ένα συγκεκριμένο θέμα ή πρόβλημα, να μοιραστείτε τη σχετική εμπειρία για την επίλυση του προβλήματος.
Παρατήρησα επίσης ότι οι διοργανωτές έκαναν μια ροή σύντομων αναφορών. Κάθε αναφορά διαρκεί όχι περισσότερο από 10 λεπτά, ακολουθούμενη από ερωτήσεις. Με αυτόν τον τρόπο μπορείτε να καλύψετε πολλά θέματα ταυτόχρονα και να κάνετε ερωτήσεις σε ομιλητές που σας ενδιαφέρουν.
Μεταξύ των παρουσιάσεων, περπατούσα στα περίπτερα των συνεργατών του συνεδρίου και έκλεψα/κέρδισα πολλά πράγματα. Ω, μου αρέσει το φυλλάδιο!
Στρογγυλή τράπεζα και θέματα DevOps με τον διευθυντή ανάπτυξης στην Alfastrakhovanie
Το κερασάκι στην τούρτα DevOpsForum 2019 για μένα ήταν η ωριαία σύνοδος ολομέλειας με ειδικούς του DevOps. Τέσσερις συμμετέχοντες κλήθηκαν να δουν τα DevOps από διαφορετικές οπτικές γωνίες: Anton Isanin (Alfastrakhovanie, διευθυντής ανάπτυξης), Nailya Zamashkina (Fintech Lab, λειτουργικός διευθυντής), Oleg Egorkin (Rostelecom, Agile coach) και Anton Martyanov (ανεξάρτητος ειδικός, εξέτασε το DevOps από επιχειρηματική άποψη).
Οι ειδικοί κάθισαν πιο κοντά στον κόσμο και μετά άρχισαν να συμβαίνουν πράγματα: για μια ολόκληρη ώρα, οι συμμετέχοντες από το κοινό έκαναν τις ερωτήσεις τους και οι ειδικοί έπαιρναν το ραπ. Μερικές φορές γίνονταν πραγματικές συζητήσεις. Οι ερωτήσεις ήταν πολύ διαφορετικές, για παράδειγμα: χρειάζονται καθόλου μηχανικοί DevOps, γιατί δεν μπορούν να εκπαιδευτούν ως διαχειριστές συστήματος, εάν το DevOps προσφέρεται σε όλους, ποια είναι η αξία του και ούτω καθεξής.
Στη συνέχεια, μίλησα προσωπικά με τον Anton Isanin. Συζητήσαμε την ανάγκη να φέρουμε την κουλτούρα DevOps σε κάθε σπίτι και αποκαλύψαμε τη σκοτεινή πλευρά του μετασχηματισμού DevOps.
Ας φανταστούμε ότι όλοι συγκεντρώθηκαν και αποφάσισαν ότι το DevOps χρειάζεται τόσο από το προϊόν όσο και από την επιχείρηση και την ομάδα. Πάμε να το εφαρμόσουμε. Όλα λειτούργησαν. Εκπνεύσαμε. Το DevOps μας έφερε πιο κοντά στον πελάτη, τώρα μπορούμε να εκπληρώσουμε γρήγορα όλες τις επιθυμίες του. Ως αποτέλεσμα, έχουμε ένα μεγάλο τμήμα Ops με αυστηρούς κανονισμούς και απαιτήσεις, και βρίσκει συνεχώς ελαττώματα στο προϊόν και δημιουργεί ένα σωρό αιτήματα. Επιπλέον, σε όλα τα ελαττώματα εκχωρείται η κατάσταση «επείγοντος», ακόμα κι αν ο πελάτης ήθελε απροσδόκητα να χρωματίσει το κουμπί κίτρινο αντί για πράσινο. Το έργο αυξάνεται, ο αριθμός των κυκλοφοριών αυξάνεται και, κατά συνέπεια, ο αριθμός των ελαττωμάτων και των παρεξηγήσεων της νέας λειτουργικότητας από τους πελάτες. Η Ops προσλαμβάνει 10 ακόμη άτομα για να συμβαδίζει με την αναφορά ελαττωμάτων και η ανάπτυξη προσλαμβάνει 15 ακόμη για να συμβαδίσει με το κλείσιμό τους. Και αντί να εισάγει νέες δυνατότητες, η ομάδα εργάζεται με ατελείωτα SD's, εξηγώντας τη λειτουργικότητα στον χρήστη και την υποστήριξη ταυτόχρονα. Ως αποτέλεσμα, τόσο το Ops όσο και η ανάπτυξη λειτουργούν, αλλά ο πελάτης και η επιχείρηση είναι δυσαρεστημένοι: οι νέες δυνατότητες κολλάνε. Αποδεικνύεται ότι το DevOps φαίνεται να υπάρχει, αλλά δεν φαίνεται να υπάρχει.
Όσον αφορά την ανάγκη εφαρμογής DevOps, ο Anton δήλωσε ξεκάθαρα ότι αυτό εξαρτάται άμεσα από την κλίμακα της επιχείρησης. Εάν η εξυπηρέτηση ενός πελάτη ετησίως αποφέρει στην εταιρεία ένα δισεκατομμύριο, δεν χρειάζεται DevOps (με την προϋπόθεση ότι δεν χρειάζεται να πραγματοποιείτε τακτικά νέες αλλαγές σε αυτόν τον πελάτη). Όλα είναι καλυμμένα με σοκολάτα. Αλλά αν η επιχείρηση αναπτυχθεί και εμφανιστούν περισσότεροι πελάτες, τότε πρέπει να συμμορφωθείτε. Κατά κανόνα, αρχικά δεν υπάρχει cool Ops στην εταιρεία. Πρώτα κόβουμε το προϊόν και μόνο τότε καταλαβαίνουμε ότι για να λειτουργήσει το προϊόν, πρέπει να παρακολουθούμε τους διακομιστές και να παρακολουθούμε τις προμήθειες. Τότε είναι που δημιουργείται το Ops. Μένει να γίνει κατανοητό ότι η Ops, ως ξεχωριστό τμήμα, θα αρχίσει να βάζει ένα σωρό εμπόδια στην ανάπτυξη και όλες οι παραδόσεις θα αρχίσουν να σταματούν. Δηλαδή, σε αυτήν την περίπτωση, η κουλτούρα DevOps είναι ήδη σχετική, αλλά δεν πρέπει να ξεχνάμε τη σκοτεινή πλευρά της.
Πηγή: www.habr.com