Κάποτε παρείχαμε ένα ηλεκτρονικό σύστημα διαχείρισης εγγράφων σε έναν πελάτη σε μια εγκατάσταση. Και μετά σε άλλο αντικείμενο. Και ένα ακόμα. Και την τέταρτη και την πέμπτη. Παρασυρθήκαμε τόσο πολύ που φτάσαμε στα 10 κατανεμημένα αντικείμενα. Αποδείχθηκε δυναμικά... ειδικά όταν φτάσαμε να παραδώσουμε τις αλλαγές. Ως μέρος της παράδοσης στο κύκλωμα παραγωγής, 5 σενάρια του συστήματος δοκιμών απαιτούσαν τελικά 10 ώρες και 6-7 εργαζόμενους. Τέτοιες δαπάνες μας ανάγκασαν να κάνουμε παραδόσεις όσο πιο σπάνια γινόταν. Μετά από τρία χρόνια λειτουργίας, δεν αντέξαμε και αποφασίσαμε να εμπλουτίσουμε το έργο με μια πρέζα DevOps.
Τώρα όλες οι δοκιμές γίνονται σε 3 ώρες και συμμετέχουν 3 άτομα: ένας μηχανικός και δύο δοκιμαστές. Οι βελτιώσεις εκφράζονται ξεκάθαρα σε αριθμούς και οδηγούν σε μείωση του πολυαγαπημένου TTM. Σύμφωνα με την εμπειρία μας, υπάρχουν πολύ περισσότεροι πελάτες που μπορούν να επωφεληθούν από το DevOps από εκείνους που το γνωρίζουν. Επομένως, για να φέρουμε τα DevOps πιο κοντά στους ανθρώπους, έχουμε αναπτύξει έναν απλό κατασκευαστή, για τον οποίο θα μιλήσουμε λεπτομερέστερα σε αυτήν την ανάρτηση.
Τώρα ας σας πούμε με περισσότερες λεπτομέρειες. Μία ενεργειακή εταιρεία αναπτύσσει ένα σύστημα διαχείρισης τεχνικών εγγράφων σε 10 μεγάλες εγκαταστάσεις. Δεν είναι εύκολη η πλοήγηση σε έργα αυτής της κλίμακας χωρίς DevOps, επειδή ένα μεγάλο μερίδιο της χειρωνακτικής εργασίας καθυστερεί πολύ την εργασία και επίσης μειώνει την ποιότητα - κάθε χειρωνακτική εργασία είναι γεμάτη σφάλματα. Από την άλλη πλευρά, υπάρχουν έργα όπου υπάρχει μόνο μία εγκατάσταση, αλλά όλα πρέπει να λειτουργούν αυτόματα, συνεχώς και χωρίς αποτυχία - για παράδειγμα, τα ίδια συστήματα ροής εγγράφων σε μεγάλους μονολιθικούς οργανισμούς. Διαφορετικά, κάποιος θα κάνει τις ρυθμίσεις χειροκίνητα, θα ξεχάσει τις οδηγίες ανάπτυξης - και ως αποτέλεσμα, στην παραγωγή οι ρυθμίσεις θα χαθούν και τα πάντα θα καταρρεύσουν.
Συνήθως συνεργαζόμαστε με τον πελάτη μέσω σύμβασης και σε αυτήν την περίπτωση τα συμφέροντά μας διαφέρουν ελαφρώς. Ο πελάτης εξετάζει το έργο αυστηρά εντός του προϋπολογισμού και των τεχνικών προδιαγραφών. Μπορεί να είναι δύσκολο να του εξηγήσεις τα οφέλη από διάφορες πρακτικές DevOps που δεν περιλαμβάνονται στις τεχνικές προδιαγραφές. Τι γίνεται αν ενδιαφέρεται για γρήγορες εκδόσεις με προστιθέμενη επιχειρηματική αξία ή για την κατασκευή ενός αγωγού αυτοματισμού;
Αλίμονο, όταν εργάζεστε με ένα προεγκεκριμένο κόστος, αυτό το ενδιαφέρον δεν βρίσκεται πάντα. Στο ιατρείο μας, υπήρξε περίπτωση που έπρεπε να σηκώσουμε την ανάπτυξη ενός αδίστακτου και απρόσεκτου εργολάβου. Ήταν τρομερό: δεν υπήρχαν ενημερωμένοι πηγαίοι κώδικες, η βάση κώδικα του ίδιου συστήματος ήταν διαφορετική σε διαφορετικές εγκαταστάσεις, η τεκμηρίωση ήταν εν μέρει απούσα και εν μέρει τρομερής ποιότητας. Φυσικά, ο πελάτης δεν είχε τον έλεγχο του πηγαίου κώδικα, της συναρμολόγησης, των εκδόσεων κ.λπ.
Μέχρι στιγμής, δεν γνωρίζουν όλοι για το DevOps, αλλά μόλις μιλήσουμε για τα πλεονεκτήματά του, για την πραγματική εξοικονόμηση πόρων, τα μάτια όλων των πελατών φωτίζονται. Έτσι, ο αριθμός των αιτημάτων που περιλαμβάνουν DevOps αυξάνεται με την πάροδο του χρόνου. Εδώ, για να μιλάμε εύκολα την ίδια γλώσσα με τους πελάτες, πρέπει να συνδέσουμε γρήγορα τα επιχειρηματικά προβλήματα και τις πρακτικές DevOps που θα βοηθήσουν στη δημιουργία ενός κατάλληλου αγωγού ανάπτυξης.
Άρα, έχουμε ένα σύνολο προβλημάτων από τη μια, έχουμε γνώσεις, πρακτικές και εργαλεία DevOps από την άλλη. Γιατί να μην μοιραστείτε την εμπειρία με όλους;
Δημιουργία ενός κατασκευαστή DevOps
Το Agile έχει το δικό του μανιφέστο. Το ITIL έχει τη δική του μεθοδολογία. Το DevOps είναι λιγότερο τυχερό - δεν έχει ακόμη αποκτήσει πρότυπα και πρότυπα. Αν και καθορίζει την ωριμότητα των εταιρειών με βάση την αξιολόγηση των πρακτικών ανάπτυξης και λειτουργίας τους.
Ευτυχώς η γνωστή εταιρεία Gartner το 2014 και ανέλυσε βασικές πρακτικές DevOps και τις σχέσεις μεταξύ τους. Με βάση αυτό, δημοσίευσα ένα infographic:
Το πήραμε ως βάση για το δικό μας . Κάθε μία από τις τέσσερις περιοχές έχει ένα σύνολο εργαλείων - τα συγκεντρώσαμε σε μια βάση δεδομένων, εντοπίσαμε τα πιο δημοφιλή, εντοπίσαμε σημεία ολοκλήρωσης και κατάλληλους μηχανισμούς βελτιστοποίησης. Συνολικά αποδείχθηκε 36 πρακτικές και 115 εργαλεία, το ένα τέταρτο των οποίων είναι ανοιχτού κώδικα ή ελεύθερο λογισμικό. Στη συνέχεια, θα μιλήσουμε για το τι έχουμε επιτύχει σε κάθε τομέα και, για παράδειγμα, για το πώς αυτό εφαρμόστηκε στο έργο για τη δημιουργία τεχνικής διαχείρισης εγγράφων, με το οποίο ξεκινήσαμε τη δημοσίευση.
Διαδικασίες
Στο περιβόητο έργο EDMS, το σύστημα διαχείρισης τεχνικής τεκμηρίωσης αναπτύχθηκε σύμφωνα με το ίδιο σχήμα σε καθένα από τα 10 αντικείμενα. Η εγκατάσταση περιλαμβάνει 4 διακομιστές: διακομιστή βάσης δεδομένων, διακομιστή εφαρμογών, ευρετηρίαση πλήρους κειμένου και διαχείριση περιεχομένου. Στην εγκατάσταση λειτουργούν σε έναν μόνο κόμβο και βρίσκονται στο κέντρο δεδομένων στις εγκαταστάσεις. Όλα τα αντικείμενα διαφέρουν ελαφρώς στην υποδομή, αλλά αυτό δεν παρεμβαίνει στην παγκόσμια αλληλεπίδραση.
Πρώτα, σύμφωνα με τις πρακτικές DevOps, αυτοματοποιήσαμε την υποδομή τοπικά, μετά φέραμε την παράδοση στο κύκλωμα δοκιμής και μετά στο προϊόν του πελάτη. Κάθε διαδικασία εκπονήθηκε βήμα προς βήμα. Οι ρυθμίσεις περιβάλλοντος είναι σταθερές στο σύστημα πηγαίου κώδικα, λαμβάνοντας υπόψη ποιο είναι το κιτ διανομής μεταγλωττισμένο για αυτόματη ενημέρωση. Σε περίπτωση αλλαγών στη διαμόρφωση, οι μηχανικοί πρέπει απλώς να κάνουν τις κατάλληλες αλλαγές στο σύστημα ελέγχου έκδοσης - και στη συνέχεια η αυτόματη ενημέρωση θα πραγματοποιηθεί χωρίς προβλήματα.
Χάρη σε αυτή την προσέγγιση, η διαδικασία δοκιμών έχει απλοποιηθεί σημαντικά. Προηγουμένως, το έργο είχε δοκιμαστές που δεν έκαναν τίποτα άλλο παρά να ενημερώσουν χειροκίνητα τα stand. Τώρα απλώς έρχονται, βλέπουν ότι όλα λειτουργούν και κάνουν πιο χρήσιμα πράγματα. Κάθε ενημέρωση δοκιμάζεται αυτόματα - από το επίπεδο επιφάνειας έως την αυτοματοποίηση επιχειρηματικών σεναρίων. Τα αποτελέσματα δημοσιεύονται ως ξεχωριστές αναφορές στο TestRail.
Культура
Ο συνεχής πειραματισμός εξηγείται καλύτερα μέσω του παραδείγματος σχεδιασμού δοκιμής. Η δοκιμή ενός συστήματος που δεν υπάρχει ακόμα είναι δημιουργική δουλειά. Κατά τη σύνταξη ενός σχεδίου δοκιμής, πρέπει να κατανοήσετε πώς να δοκιμάζετε σωστά και ποιους κλάδους να ακολουθήσετε. Επίσης, βρείτε μια ισορροπία μεταξύ χρόνου και προϋπολογισμού για να προσδιορίσετε τον βέλτιστο αριθμό ελέγχων. Είναι σημαντικό να επιλέξετε ακριβώς τις απαραίτητες δοκιμές, να σκεφτείτε πώς θα αλληλεπιδράσει ο χρήστης με το σύστημα, να λάβετε υπόψη το περιβάλλον και πιθανούς εξωτερικούς παράγοντες. Είναι αδύνατο να γίνει χωρίς συνεχή πειραματισμό.
Τώρα για την κουλτούρα της αλληλεπίδρασης. Προηγουμένως, υπήρχαν δύο αντίθετες πλευρές - μηχανικοί και προγραμματιστές. Οι προγραμματιστές είπαν: «Δεν μας ενδιαφέρει πώς θα κυκλοφορήσει. Είστε μηχανικοί, είστε έξυπνοι, φροντίστε να λειτουργεί χωρίς αστοχίες». Οι μηχανικοί απάντησαν: «Εσείς οι προγραμματιστές είστε πολύ απρόσεκτοι. Ας είμαστε πιο προσεκτικοί και θα παίζουμε τις κυκλοφορίες σας λιγότερο συχνά. Επειδή κάθε φορά που μας δίνετε έναν κωδικό που διαρρέει, δεν είναι σαφές σε εμάς πώς να αλληλεπιδράσουμε.". Αυτό είναι ένα ζήτημα πολιτισμικής αλληλεπίδρασης που είναι δομημένο διαφορετικά από την άποψη του DevOps. Εδώ, τόσο οι μηχανικοί όσο και οι προγραμματιστές αποτελούν μέρος μιας ενιαίας ομάδας που επικεντρώνεται στο συνεχώς μεταβαλλόμενο, αλλά ταυτόχρονα αξιόπιστο λογισμικό.
Μέσα στην ίδια ομάδα, οι ειδικοί είναι αποφασισμένοι να βοηθήσουν ο ένας τον άλλον. Όπως ήταν πριν; Για παράδειγμα, ετοιμάζονταν κάποιες χοντρές οδηγίες ανάπτυξης, περίπου 50 σελίδων. Ο μηχανικός το διάβασε, δεν κατάλαβε κάτι, έβρισε και ζήτησε από τον προγραμματιστή στις τρεις η ώρα το πρωί να σχολιάσει. Ο προγραμματιστής σχολίασε και επίσης έβρισε - στο τέλος, κανείς δεν ήταν ευχαριστημένος. Επιπλέον, φυσικά, υπήρχαν κάποια λάθη, επειδή δεν μπορείτε να θυμηθείτε τα πάντα στις οδηγίες. Και τώρα ο μηχανικός, μαζί με τον προγραμματιστή, γράφει ένα σενάριο για την αυτοματοποιημένη ανάπτυξη της υποδομής λογισμικού εφαρμογών. Και μιλούν μεταξύ τους σχεδόν στην ίδια γλώσσα.
Άνθρωποι
Το μέγεθος της ομάδας καθορίζεται από το εύρος της ενημέρωσης. Η ομάδα προσλαμβάνεται κατά τον σχηματισμό της παράδοσης· περιλαμβάνει τους ενδιαφερόμενους από τη γενική ομάδα του έργου. Στη συνέχεια συντάσσεται ένα σχέδιο ενημέρωσης με τους υπεύθυνους για κάθε στάδιο και η ομάδα αναφέρει καθώς προχωρά. Όλα τα μέλη της ομάδας είναι εναλλάξιμα. Ως μέρος της ομάδας, έχουμε επίσης έναν εφεδρικό προγραμματιστή, αλλά σχεδόν ποτέ δεν χρειάζεται να συνδεθεί.
Τεχνολογία
Στο διάγραμμα τεχνολογίας, επισημαίνονται μερικά σημεία, αλλά κάτω από αυτά υπάρχει μια δέσμη τεχνολογιών - θα μπορούσατε να δημοσιεύσετε ένα ολόκληρο βιβλίο με τις περιγραφές τους. Θα επισημάνουμε λοιπόν τα πιο ενδιαφέροντα.
Υποδομή ως Κώδικας
Τώρα, μάλλον, αυτή η ιδέα δεν θα εκπλήξει κανέναν, αλλά προηγουμένως οι περιγραφές των υποδομών άφηναν πολλά να είναι επιθυμητά. , τα περιβάλλοντα δοκιμής ήταν μοναδικά, τα αγαπούσαν και τα αγαπούσαν, τα σωματίδια σκόνης ξεπήδησαν από πάνω τους.
Στις μέρες μας κανείς δεν φοβάται να πειραματιστεί. Υπάρχουν βασικές εικόνες εικονικών μηχανών, υπάρχουν έτοιμα σενάρια για την ανάπτυξη περιβαλλόντων. Όλα τα πρότυπα και τα σενάρια αποθηκεύονται σε ένα σύστημα ελέγχου έκδοσης και ενημερώνονται αμέσως. Προηγουμένως, όταν ήταν απαραίτητο να παραδοθεί ένα πακέτο σε ένα περίπτερο, εμφανίστηκε ένα κενό διαμόρφωσης. Τώρα πρέπει απλώς να προσθέσετε μια γραμμή στον πηγαίο κώδικα.
Εκτός από τα σενάρια υποδομής και τους αγωγούς, η προσέγγιση Documentation as a Code χρησιμοποιείται επίσης για τεκμηρίωση. Χάρη σε αυτό, είναι εύκολο να συνδέσετε νέους ανθρώπους στο έργο, να τους εισαγάγετε στο σύστημα με βάση τις λειτουργίες που περιγράφονται, για παράδειγμα, στο σχέδιο δοκιμών, καθώς και να επαναχρησιμοποιήσετε περιπτώσεις δοκιμών.
Συνεχής παράδοση και παρακολούθηση
σχετικά με το DevOps, μιλήσαμε για το πώς επιλέξαμε εργαλεία για την υλοποίηση συνεχούς παράδοσης και παρακολούθησης. Συχνά δεν χρειάζεται να ξαναγράψετε τίποτα - αρκεί να χρησιμοποιήσετε προηγουμένως γραμμένα σενάρια, να δημιουργήσετε σωστά την ενοποίηση μεταξύ των στοιχείων και να δημιουργήσετε μια κοινή κονσόλα διαχείρισης. Και όλες οι διαδικασίες μπορούν να ξεκινήσουν χρησιμοποιώντας ένα κουμπί ή ένα πρόγραμμα.
Στα αγγλικά υπάρχουν διαφορετικές έννοιες, Continuous Delivery και Continuous Deployment. Και τα δύο μπορούν να μεταφραστούν ως "συνεχής παράδοση", αλλά στην πραγματικότητα υπάρχει μια μικρή διαφορά μεταξύ τους. Στο έργο μας για τη ροή τεχνικών εγγράφων μιας εταιρείας κατανεμημένης ενέργειας, χρησιμοποιείται μάλλον Παράδοση - όταν η εγκατάσταση για παραγωγή πραγματοποιείται κατόπιν εντολής. Στο Deployment, η εγκατάσταση πραγματοποιείται αυτόματα. Συνεχής παράδοση σε αυτό το έργο έχει γίνει γενικά κεντρικό τμήμα του DevOps.
Γενικά, συλλέγοντας ορισμένες παραμέτρους, μπορείτε να καταλάβετε ξεκάθαρα γιατί οι πρακτικές DevOps είναι χρήσιμες. Και μεταφέρετε αυτό στη διοίκηση, που αγαπά πολύ τους αριθμούς. Ο συνολικός αριθμός εκκινήσεων, ο χρόνος εκτέλεσης των σταδίων του σεναρίου, το μερίδιο των επιτυχημένων εκκινήσεων - όλα αυτά επηρεάζουν άμεσα την αγαπημένη στιγμή του καθενός στην αγορά, δηλαδή τον χρόνο από το commit στο σύστημα ελέγχου έκδοσης μέχρι την κυκλοφορία μιας έκδοσης σε περιβάλλον παραγωγής. Με την εφαρμογή των απαραίτητων εργαλείων, οι μηχανικοί λαμβάνουν πολύτιμους δείκτες μέσω ταχυδρομείου και ο υπεύθυνος έργου τους βλέπει στον πίνακα ελέγχου. Με αυτόν τον τρόπο μπορείτε να αξιολογήσετε αμέσως τα οφέλη των νέων εργαλείων. Και μπορείτε να τα δοκιμάσετε στην υποδομή σας χρησιμοποιώντας τον σχεδιαστή DevOps.
Ποιος θα μας χρειαστεί ?
Ας μην προσποιούμαστε: για αρχή μας έγινε χρήσιμος. Όπως έχουμε ήδη πει, πρέπει να μιλάτε την ίδια γλώσσα με τον πελάτη και με τη βοήθεια του σχεδιαστή DevOps μπορούμε να σχεδιάσουμε γρήγορα τη βάση για μια τέτοια συνομιλία. Οι ειδικοί των επιχειρήσεων θα είναι σε θέση να αξιολογήσουν μόνοι τους τι χρειάζονται και έτσι να εξελιχθούν πιο γρήγορα. Προσπαθήσαμε να κάνουμε τον σχεδιαστή όσο το δυνατόν πιο λεπτομερή, προσθέτοντας ένα σωρό περιγραφές έτσι ώστε οποιοσδήποτε χρήστης να καταλάβει τι επιλέγει.
Η μορφή του σχεδιαστή σάς επιτρέπει να λαμβάνετε υπόψη τις υπάρχουσες εξελίξεις της εταιρείας στις διαδικασίες κατασκευής και αυτοματισμού. Δεν χρειάζεται να καταρρίψετε τα πάντα και να τα ξαναχτίσετε εάν μπορείτε να επιλέξετε μόνο λύσεις που ενσωματώνονται καλά με τις υπάρχουσες διαδικασίες και που μπορούν απλώς να καλύψουν τα κενά.
Ίσως η ανάπτυξή σας να έχει ήδη προχωρήσει σε υψηλότερο επίπεδο και το εργαλείο μας να φαίνεται πολύ "καπετάνιου". Αλλά το βρίσκουμε χρήσιμο για εμάς και ελπίζουμε ότι θα είναι χρήσιμο σε κάποιους από τους αναγνώστες. Σας θυμίζουμε στον σχεδιαστή - αν μη τι άλλο, λαμβάνετε το διάγραμμα αμέσως μετά την εισαγωγή των αρχικών δεδομένων. Θα είμαστε ευγνώμονες για τα σχόλια και τις προσθήκες σας.
Πηγή: www.habr.com