Εικόνα:
Γεια σε όλους! Είμαστε μηχανικοί αυτοματισμού της εταιρείας και παρέχουμε υποστήριξη για την ανάπτυξη των προϊόντων της εταιρείας: υποστηρίζουμε ολόκληρη τη γραμμή συναρμολόγησης από τη δέσμευση μιας γραμμής κώδικα από προγραμματιστές έως τη δημοσίευση τελικών προϊόντων και αδειών σε διακομιστές ενημέρωσης. Ανεπίσημα, ονομαζόμαστε μηχανικοί DevOps. Σε αυτό το άρθρο θέλουμε να μιλήσουμε για τα τεχνολογικά στάδια της διαδικασίας παραγωγής λογισμικού, πώς τα βλέπουμε και πώς τα ταξινομούμε.
Από το υλικό θα μάθετε για την πολυπλοκότητα του συντονισμού ανάπτυξης πολλαπλών προϊόντων, τι είναι ένας τεχνολογικός χάρτης και πώς βοηθά στην οργάνωση και αναπαραγωγή λύσεων, ποια είναι τα κύρια στάδια και τα βήματα από τα οποία αποτελείται η διαδικασία ανάπτυξης, πώς οριοθετούνται οι τομείς ευθύνης μεταξύ DevOps και ομάδων της εταιρείας μας.
Σχετικά με το Chaos και το DevOps
Ας σημειώσουμε εν συντομία ότι η έννοια του DevOps περιλαμβάνει εργαλεία και υπηρεσίες ανάπτυξης, καθώς και μεθοδολογίες και βέλτιστες πρακτικές για τη χρήση τους. Ας αναδείξουμε το παγκόσμιο γκολ από την εφαρμογή των ιδεών DevOps στην εταιρεία μας: πρόκειται για μια σταθερή μείωση του κόστους παραγωγής και συντήρησης των προϊόντων σε ποσοτικούς όρους (εργατοώρες ή ώρες μηχανής, CPU, RAM, Δίσκος κ.λπ.). Ο απλούστερος και πιο προφανής τρόπος μείωσης του συνολικού κόστους ανάπτυξης σε επίπεδο εταιρείας είναι να ελαχιστοποίηση του κόστους εκτέλεσης τυπικών σειριακών εργασιών σε όλα τα στάδια παραγωγής. Ποια είναι όμως αυτά τα στάδια, πώς μπορούν να διακριθούν από τη γενική διαδικασία, από ποια βήματα αποτελούνται;
Όταν μια εταιρεία αναπτύσσει ένα προϊόν, όλα είναι λίγο πολύ ξεκάθαρα: υπάρχει συνήθως ένας γενικός οδικός χάρτης και ένα σχέδιο ανάπτυξης. Τι να κάνετε όμως όταν η σειρά προϊόντων επεκτείνεται και υπάρχουν περισσότερα προϊόντα; Με την πρώτη ματιά, έχουν παρόμοιες διεργασίες και γραμμές συναρμολόγησης και το παιχνίδι του «βρες Χ διαφορές» σε αρχεία καταγραφής και σενάρια ξεκινά. Τι γίνεται αν υπάρχουν ήδη 5+ έργα σε ενεργό ανάπτυξη και απαιτείται υποστήριξη για πολλές εκδόσεις που έχουν αναπτυχθεί σε πολλά χρόνια; Θέλουμε να επαναχρησιμοποιήσουμε όσο το δυνατόν περισσότερες λύσεις σε σωλήνες προϊόντων ή είμαστε έτοιμοι να ξοδέψουμε χρήματα για μοναδική ανάπτυξη για καθεμία;
Πώς να βρείτε μια ισορροπία μεταξύ της μοναδικότητας και της σειράς των λύσεων;
Αυτά τα ερωτήματα άρχισαν να τίθενται μπροστά μας όλο και πιο συχνά από το 2015. Ο αριθμός των προϊόντων αυξήθηκε και προσπαθήσαμε να επεκτείνουμε στο ελάχιστο το τμήμα αυτοματισμού (DevOps), το οποίο υποστήριζε τις γραμμές συναρμολόγησης αυτών των προϊόντων. Ταυτόχρονα, ήθελα να επαναλάβω όσο το δυνατόν περισσότερες λύσεις μεταξύ των προϊόντων. Τελικά, γιατί να κάνουμε το ίδιο πράγμα σε δέκα προϊόντα με διαφορετικούς τρόπους;
Διευθυντής Ανάπτυξης: "Παιδιά, μπορούμε με κάποιο τρόπο να αξιολογήσουμε τι κάνει το DevOps για προϊόντα;"
Εμείς: "Δεν ξέρουμε, δεν έχουμε κάνει αυτήν την ερώτηση, αλλά ποιοι δείκτες πρέπει να υπολογιστούν;"
Διευθυντής Ανάπτυξης: "Ποιός ξέρει! Νομίζω..."
Όπως σε εκείνη τη διάσημη ταινία: «Πάω στο ξενοδοχείο!...» - «Ε... Μπορείς να μου δείξεις τον δρόμο;» Μετά από σκέψη, καταλήξαμε στο συμπέρασμα ότι πρέπει πρώτα να αποφασίσουμε για τις τελικές καταστάσεις των προϊόντων. αυτός έγινε ο πρώτος μας στόχος.
Λοιπόν, πώς μπορείτε να αναλύσετε μια ντουζίνα προϊόντα με αρκετά μεγάλες ομάδες 10 έως 200 ατόμων και να προσδιορίσετε μετρήσιμες μετρήσεις κατά την αναπαραγωγή λύσεων;
1:0 υπέρ του Chaos ή DevOps στα blades
Ξεκινήσαμε προσπαθώντας να εφαρμόσουμε διαγράμματα IDEF0 και διάφορα διαγράμματα επιχειρηματικών διαδικασιών από τη σειρά BPwin. Η σύγχυση ξεκίνησε μετά το πέμπτο τετράγωνο του επόμενου σταδίου του επόμενου έργου και αυτά τα τετράγωνα για κάθε έργο μπορούν να συρθούν στην ουρά ενός μακριού πύθωνα σε 50+ βήματα. Ένιωσα λυπημένος και ήθελα να ουρλιάξω στο φεγγάρι - δεν ταίριαζε καθόλου.
Τυπικές εργασίες παραγωγής
Η μοντελοποίηση των διαδικασιών παραγωγής είναι μια πολύ περίπλοκη και επίπονη εργασία: πρέπει να συλλέξετε, να επεξεργαστείτε και να αναλύσετε πολλά δεδομένα από διάφορα τμήματα και αλυσίδες παραγωγής. Μπορείτε να διαβάσετε περισσότερα για αυτό στο άρθρο "».
Όταν ξεκινήσαμε να διαμορφώνουμε τη διαδικασία παραγωγής μας, είχαμε έναν συγκεκριμένο στόχο - να μεταφέρουμε σε κάθε εργαζόμενο που εμπλέκεται στην ανάπτυξη των προϊόντων της εταιρείας μας και στους διαχειριστές έργων:
- πώς τα προϊόντα και τα στοιχεία τους, ξεκινώντας από τη δέσμευση μιας γραμμής κώδικα, φτάνουν στον πελάτη με τη μορφή προγραμμάτων εγκατάστασης και ενημερώσεων,
- ποιοι πόροι παρέχονται σε κάθε στάδιο της παραγωγής του προϊόντος,
- ποιες υπηρεσίες εμπλέκονται σε κάθε στάδιο,
- πώς οριοθετούνται οι τομείς ευθύνης για κάθε στάδιο,
- τι συμβόλαια υπάρχουν στην είσοδο και την έξοδο κάθε σταδίου.
Κάντε κλικ στην εικόνα για να ανοίξει σε πλήρες μέγεθος
Η εργασία μας στην εταιρεία χωρίζεται σε πολλούς λειτουργικούς τομείς. Το τμήμα υποδομής ασχολείται με τη βελτιστοποίηση της λειτουργίας όλων των πόρων υλικού του τμήματος, καθώς και την αυτοματοποίηση της ανάπτυξης εικονικών μηχανών και του περιβάλλοντος σε αυτές. Η κατεύθυνση παρακολούθησης παρέχει έλεγχο επί της απόδοσης των υπηρεσιών 24/7. Παρέχουμε επίσης παρακολούθηση ως υπηρεσία για προγραμματιστές. Η κατεύθυνση ροής εργασιών παρέχει στις ομάδες εργαλεία για τη διαχείριση των διαδικασιών ανάπτυξης και δοκιμής, την ανάλυση της κατάστασης κώδικα και τη λήψη αναλυτικών στοιχείων σε έργα. Τέλος, η διεύθυνση webdev διασφαλίζει τη δημοσίευση εκδόσεων στους διακομιστές ενημέρωσης GUS και FLUS, καθώς και την αδειοδότηση προϊόντων που χρησιμοποιούν την υπηρεσία LicenseLab. Για να υποστηρίξουμε τη γραμμή παραγωγής, δημιουργήσαμε και διατηρούμε πολλές διαφορετικές υπηρεσίες υποστήριξης για προγραμματιστές (μπορείτε να ακούσετε ιστορίες για ορισμένες από αυτές σε παλιές συναντήσεις: и). Αναπτύσσουμε επίσης εργαλεία εσωτερικού αυτοματισμού, συμπεριλαμβανομένων .
Τα τελευταία πέντε χρόνια, η δουλειά μας έχει συσσωρεύσει πολλές παρόμοιες και συνήθεις λειτουργίες και οι λεγόμενες τυπικές εργασίες, η λύση του οποίου είναι πλήρως ή μερικώς αυτοματοποιημένη, δεν προκαλεί δυσκολίες στους ερμηνευτές και δεν απαιτεί σημαντικό όγκο εργασίας. Μαζί με τους κορυφαίους τομείς, αναλύσαμε τέτοιες εργασίες και μπορέσαμε να προσδιορίσουμε μεμονωμένες κατηγορίες εργασίας ή στάδια παραγωγής, τα στάδια χωρίζονται σε αδιαίρετα βήματα και αθροίζονται πολλά στάδια αλυσίδα παραγωγικής διαδικασίας.
Το απλούστερο παράδειγμα μιας τεχνολογικής αλυσίδας είναι τα στάδια συναρμολόγησης, ανάπτυξης και δοκιμής καθενός από τα προϊόντα μας εντός της εταιρείας. Με τη σειρά του, για παράδειγμα, το στάδιο κατασκευής αποτελείται από πολλά ξεχωριστά τυπικά βήματα: λήψη πηγών από το GitLab, προετοιμασία εξαρτήσεων και βιβλιοθηκών τρίτων, δοκιμή μονάδας και στατική ανάλυση κώδικα, εκτέλεση σεναρίου έκδοσης στο GitLab CI, δημοσίευση τεχνουργημάτων σε αποθετήριο σε Τεχνητή και δημιουργία σημειώσεων έκδοσης μέσω του εσωτερικού μας εργαλείου ChangelogBuilder.
Μπορείτε να διαβάσετε για τυπικές εργασίες DevOps στα άλλα άρθρα μας στο Habré:"Και"».
Δημιουργούνται πολλές τυπικές αλυσίδες παραγωγής διαδικασία παραγωγής. Η τυπική προσέγγιση για την περιγραφή των διαδικασιών είναι η χρήση λειτουργικών μοντέλων IDEF0.
Ένα παράδειγμα μοντελοποίησης μιας διαδικασίας CI παραγωγής
Δώσαμε ιδιαίτερη προσοχή στην ανάπτυξη τυποποιημένων έργων για ένα σύστημα συνεχούς ολοκλήρωσης. Αυτό κατέστησε δυνατή την επίτευξη της ενοποίησης των έργων, τονίζοντας τα λεγόμενα διάγραμμα κυκλοφορίας των κατασκευών με προσφορές.
Ετσι δουλευει. Όλα τα έργα φαίνονται τυπικά: περιλαμβάνουν τη διαμόρφωση συγκροτημάτων που πηγαίνουν στο αποθετήριο στιγμιότυπων στο Artifactory, μετά από το οποίο αναπτύσσονται και δοκιμάζονται σε πάγκους δοκιμών και στη συνέχεια προωθούνται στο αποθετήριο έκδοσης. Η υπηρεσία Artifactory είναι ένα ενιαίο σημείο για τη διανομή όλων των τεχνουργημάτων κατασκευής μεταξύ ομάδων και άλλων υπηρεσιών.
Εάν απλοποιήσουμε και γενικεύσουμε πολύ το σχήμα κυκλοφορίας μας, περιλαμβάνει τα ακόλουθα στάδια:
- κατασκευή προϊόντων σε πολλαπλές πλατφόρμες,
- ανάπτυξη σε πάγκους δοκιμών,
- έναρξη λειτουργικών και άλλων δοκιμών,
- προώθηση δοκιμασμένων συγκροτημάτων για την έκδοση αποθετηρίων στο Artifactory,
- δημοσίευση εκδόσεων έκδοσης για ενημέρωση διακομιστών,
- παράδοση κατασκευών και ενημερώσεις στην παραγωγή,
- έναρξη εγκατάστασης και ενημερώσεων προϊόντος.
Ας εξετάσουμε, ως παράδειγμα, το τεχνολογικό μοντέλο αυτού του τυπικού σχήματος απελευθέρωσης (στο εξής θα αναφέρεται απλώς ως μοντέλο) με τη μορφή ενός λειτουργικού μοντέλου IDEF0. Αντικατοπτρίζει τα κύρια στάδια της διαδικασίας CI μας. Τα μοντέλα IDEF0 χρησιμοποιούν το λεγόμενο Σημείωση ICOM (Input-Control-Output-Mechanism) για να περιγράψει ποιοι πόροι χρησιμοποιούνται σε κάθε στάδιο, με βάση ποιους κανόνες και απαιτήσεις εκτελείται η εργασία, ποια είναι η έξοδος και ποιοι μηχανισμοί, υπηρεσίες ή άτομα εφαρμόζουν ένα συγκεκριμένο στάδιο.
Κάντε κλικ στην εικόνα για να ανοίξει σε πλήρες μέγεθος
Κατά κανόνα, στα λειτουργικά μοντέλα είναι ευκολότερο να αποσυντεθεί και να λεπτομερώς η περιγραφή των διαδικασιών. Καθώς όμως ο αριθμός των στοιχείων αυξάνεται, γίνεται όλο και πιο δύσκολο να καταλάβουμε κάτι για αυτά. Αλλά στην πραγματική ανάπτυξη υπάρχουν και βοηθητικά στάδια: παρακολούθηση, πιστοποίηση προϊόντων, αυτοματοποίηση των διαδικασιών εργασίας και άλλα. Ακριβώς λόγω του προβλήματος κλιμάκωσης εγκαταλείψαμε αυτήν την περιγραφή.
Γέννηση της Ελπίδας
Σε ένα βιβλίο συναντήσαμε παλιούς σοβιετικούς χάρτες που περιγράφουν τεχνολογικές διαδικασίες (οι οποίες, παρεμπιπτόντως, εξακολουθούν να χρησιμοποιούνται σήμερα σε πολλές κρατικές επιχειρήσεις και πανεπιστήμια). Περίμενε, περίμενε, έχουμε και τεχνολογική διαδικασία!.. Υπάρχουν στάδια, αποτελέσματα, μετρήσεις, απαιτήσεις, δείκτες κ.λπ., κλπ... Γιατί να μην προσπαθήσουμε να εφαρμόσουμε τεχνολογικούς χάρτες στους μεταφορείς των προϊόντων μας; Υπήρχε μια αίσθηση: «Αυτό είναι! Βρήκαμε το σωστό νήμα, ήρθε η ώρα να του δώσουμε ένα καλό τράβηγμα!».
Σε έναν απλό πίνακα, αποφασίσαμε να καταγράψουμε τα προϊόντα ανά στήλες και τεχνολογικά στάδια και βήματα του μεταφορέα προϊόντων ανά σειρές. Τα στάδια είναι κάτι μεγάλο, όπως το στάδιο συναρμολόγησης ενός προϊόντος. Και τα βήματα είναι κάτι μικρότερο και πιο λεπτομερές, για παράδειγμα, το βήμα λήψης του πηγαίου κώδικα στον διακομιστή κατασκευής ή το βήμα μεταγλώττισης του κώδικα.
Στις διασταυρώσεις γραμμών και στηλών του χάρτη, βάζουμε καταστάσεις για ένα συγκεκριμένο στάδιο και προϊόν. Πολλές καταστάσεις έχουν οριστεί για καταστάσεις:
- Нет данных - ή μη πρακτικό. Είναι απαραίτητο να αναλυθεί η ζήτηση για ένα στάδιο στο προϊόν. Είτε η ανάλυση έχει ήδη πραγματοποιηθεί, αλλά το στάδιο δεν χρειάζεται επί του παρόντος ή δεν δικαιολογείται οικονομικά.
- Αναβλήθηκε - ή άσχετο προς το παρόν. Αυτό το στάδιο στον αγωγό είναι απαραίτητο, αλλά δεν υπάρχει ενέργεια για να εφαρμοστεί φέτος.
- Σχεδιασμένος. Το στάδιο έχει προγραμματιστεί να υλοποιηθεί φέτος.
- Εφαρμόστηκε. Το στάδιο στον αγωγό υλοποιείται στον απαιτούμενο βαθμό.
Η συμπλήρωση του πίνακα ξεκίνησε έργο με έργο. Αρχικά, ταξινομήσαμε τα στάδια και τα βήματα ενός έργου και καταγράψαμε την κατάστασή τους. Στη συνέχεια πήραν το επόμενο έργο, κατέγραψαν τις καταστάσεις σε αυτό και πρόσθεσαν στάδια και βήματα που έλειπαν σε προηγούμενα έργα. Ως αποτέλεσμα, λάβαμε τα στάδια και τα βήματα ολόκληρου του αγωγού παραγωγής μας και την κατάστασή τους σε ένα συγκεκριμένο έργο. Το αποτέλεσμα είναι κάτι παρόμοιο με έναν πίνακα ικανοτήτων για έναν μεταφορέα τροφίμων. Ονομάσαμε μια τέτοια μήτρα τεχνολογικό χάρτη.
Με τη βοήθεια του τεχνολογικού χάρτη, μετρολογικά συμφωνούμε ουσιαστικά με τις ομάδες για τα σχέδια εργασίας για το έτος και τους στόχους που θέλουμε να επιτύχουμε μαζί: ποια στάδια προσθέτουμε στο έργο φέτος και ποια αφήνουμε για αργότερα. Επίσης, καθώς εργαζόμαστε, ενδέχεται να δούμε βελτιώσεις στα βήματα που έχουμε ολοκληρώσει μόνο για ένα προϊόν. Στη συνέχεια, επεκτείνουμε τον χάρτη μας και εισάγουμε αυτήν τη βελτίωση ως ένα στάδιο ή ένα νέο βήμα, στη συνέχεια διεξάγουμε μια ανάλυση για κάθε προϊόν και ανακαλύπτουμε τη σκοπιμότητα της αναπαραγωγής της βελτίωσης.
Μπορεί να μας αντιταχθούν: «Όλα αυτά είναι καλά, φυσικά, αλλά με την πάροδο του χρόνου ο αριθμός των βημάτων και των σταδίων θα γίνει απαγορευτικά μεγάλος. Τι πρέπει να κάνω?
Εισάγαμε τυπικές και αρκετά πλήρεις περιγραφές απαιτήσεων για κάθε στάδιο και βήμα, ώστε εντός της εταιρείας να γίνονται κατανοητές από όλους με τον ίδιο τρόπο. Με την πάροδο του χρόνου, καθώς εφαρμόζονται βελτιώσεις, ένα βήμα μπορεί να απορροφηθεί σε άλλο στάδιο ή βήμα - τότε θα καταρρεύσουν. Ταυτόχρονα, όλες οι απαιτήσεις και οι τεχνολογικές αποχρώσεις ταιριάζουν στις απαιτήσεις του γενικευτικού σταδίου ή βήματος.
Πώς να αξιολογήσετε το αποτέλεσμα της αναπαραγωγής λύσεων; Χρησιμοποιούμε μια εξαιρετικά απλή προσέγγιση: αποδίδουμε το αρχικό κόστος κεφαλαίου για την υλοποίηση ενός νέου σταδίου στο ετήσιο γενικό κόστος προϊόντος και, στη συνέχεια, το διαιρούμε μεταξύ όλων κατά την αναπαραγωγή.
Μέρη της ανάπτυξης αντικατοπτρίζονται ήδη ως στάδια και βήματα στον χάρτη. Μπορούμε να επηρεάσουμε τη μείωση του κόστους των προϊόντων μέσω της εισαγωγής αυτοματισμού για τυπικά στάδια. Μετά από αυτό, υπολογίζουμε τις αλλαγές στα ποιοτικά χαρακτηριστικά, τις ποσοτικές μετρήσεις και το κέρδος που έλαβαν οι ομάδες (σε ανθρωποώρες ή ώρες μηχανής που εξοικονομήθηκαν).
Τεχνολογικός χάρτης της παραγωγικής διαδικασίας
Εάν κάνουμε όλα τα στάδια και τα βήματά μας, τα κωδικοποιήσουμε με ετικέτες και τα επεκτείνουμε σε μια αλυσίδα, τότε θα αποδειχθεί πολύ μακρύ και ακατανόητο (ακριβώς η ίδια "ουρά python" για την οποία μιλήσαμε στην αρχή του άρθρου) :
[Production] — [InfMonitoring] — [SourceCodeControl] — [Prepare] — [PrepareLinuxDocker] — [PrepareWinDocker] — [Build] — [PullSourceCode] — [PrepareDep] — [UnitTest] — [CodeCoverage] — [StaticAnalyze] — [BuildScenario] — [PushToSnapshot] — [ChangelogBuilder] — [Deploy] — [PrepareTestStand] — [PullTestCode] — [PrepareTestEnv] — [PullArtifact] — [DeployArtifact] — [Test] — [BVTTest] — [SmokeTest] — [FuncTest] — [LoadTest] — [IntegrityTest] — [DeliveryTest] — [MonitoringStands] — [TestManagement] — [Promote] — [QualityTag] — [MoveToRelease] — [License] — [Publish] — [PublishGUSFLUS] — [ControlVisibility] — [Install] — [LicenseActivation] — [RequestUpdates] — [PullUpdates] — [InitUpdates] — [PrepareEnv] — [InstallUpdates] — [Telemetry] — [Workflow] — [Communication] — [Certification] — [CISelfSufficiency]Αυτά είναι τα στάδια της συναρμολόγησης προϊόντων [Δημιουργία], η ανάπτυξή τους σε δοκιμαστικούς διακομιστές [Ανάπτυξη], η δοκιμή [Δοκιμή], η προώθηση συγκροτημάτων για την έκδοση αποθετηρίων με βάση τα αποτελέσματα δοκιμών [Προώθηση], η δημιουργία και η δημοσίευση αδειών [Άδεια χρήσης], η δημοσίευση [Δημοσίευση] στον διακομιστή ενημέρωσης GUS και παράδοση ενημερώσεων FLUS σε διακομιστές, εγκατάσταση και ενημέρωση στοιχείων προϊόντος στην υποδομή του πελάτη με χρήση Διαχείρισης Διαμόρφωσης Προϊόντων [Εγκατάσταση], καθώς και συλλογή τηλεμετρίας [Telemetry] από εγκατεστημένα προϊόντα.
Εκτός από αυτά, μπορούμε να διακρίνουμε ξεχωριστά στάδια: παρακολούθηση της κατάστασης της υποδομής [InfMonitoring], διαχείριση εκδόσεων του πηγαίου κώδικα [SourceCodeControl], προετοιμασία του περιβάλλοντος συναρμολόγησης [Προετοιμασία], διαχείριση έργου [Workflow], παροχή των ομάδων με εργαλεία επικοινωνίας [ Επικοινωνία], πιστοποίηση προϊόντος [Πιστοποίηση] και διασφάλιση της αυτάρκειας των διαδικασιών CI [CISelfSufficiency] (για παράδειγμα, ανεξαρτησία συγκροτημάτων από το Διαδίκτυο). Δεν θα εξετάσουμε καν δεκάδες βήματα στις διαδικασίες μας, επειδή είναι πολύ συγκεκριμένα.
Θα είναι πολύ πιο εύκολο να κατανοήσετε και να εξετάσετε ολόκληρη τη διαδικασία παραγωγής αν τη φανταστείτε στη μορφή τεχνολογικός χάρτης; Αυτός είναι ένας πίνακας στον οποίο τα επιμέρους στάδια παραγωγής και τα αποσυντιθέμενα βήματα του Μοντέλου καταγράφονται σε σειρές και σε στήλες μια περιγραφή του τι γίνεται σε κάθε στάδιο ή βήμα. Η κύρια έμφαση δίνεται στους πόρους που παρέχουν κάθε στάδιο και στην οριοθέτηση περιοχών ευθύνης.
Για εμάς, ένας χάρτης είναι ένα είδος ταξινομητή. Αντανακλά μεγάλα τεχνολογικά μέρη της παραγωγής προϊόντων. Χάρη σε αυτό, έγινε ευκολότερο για την ομάδα αυτοματισμού μας να αλληλεπιδρά με προγραμματιστές και να σχεδιάζει από κοινού την υλοποίηση των σταδίων αυτοματισμού, καθώς και να κατανοεί το κόστος εργασίας και τους πόρους (ανθρώπινοι και υλικό) που θα απαιτηθούν για αυτό.
Μέσα στην εταιρεία μας, ο χάρτης δημιουργείται αυτόματα από ένα πρότυπο jinja ως κανονικό αρχείο HTML και στη συνέχεια μεταφορτώνεται στον διακομιστή Σελίδων GitLab. Μπορεί να προβληθεί ένα στιγμιότυπο οθόνης με ένα παράδειγμα ενός πλήρως δημιουργημένου χάρτη .
Κάντε κλικ στην εικόνα για να ανοίξει σε πλήρες μέγεθος
Εν ολίγοις, ένας τεχνολογικός χάρτης είναι μια γενικευμένη εικόνα της παραγωγικής διαδικασίας, η οποία αντικατοπτρίζει σαφώς ταξινομημένα μπλοκ με τυπική λειτουργικότητα.
Η δομή του τεχνολογικού μας χάρτη
Ο χάρτης αποτελείται από πολλά μέρη:
- Περιοχή επικεφαλίδας - εδώ είναι μια γενική περιγραφή του χάρτη, εισάγονται βασικές έννοιες και ορίζονται οι κύριοι πόροι και τα αποτελέσματα της παραγωγικής διαδικασίας.
- Πίνακας πληροφοριών - εδώ μπορείτε να ελέγξετε την εμφάνιση δεδομένων για μεμονωμένα προϊόντα· παρέχεται μια σύνοψη των εφαρμοζόμενων σταδίων και των βημάτων γενικά για όλα τα προϊόντα.
- Τεχνολογικός χάρτης - μια πίνακα περιγραφή της τεχνολογικής διαδικασίας. Στον χάρτη:
- δίνονται όλα τα στάδια, τα βήματα και οι κωδικοί τους.
- δίνονται σύντομες και πλήρεις περιγραφές των σταδίων.
- αναφέρονται οι πόροι εισόδου και οι υπηρεσίες που χρησιμοποιούνται σε κάθε στάδιο·
- υποδεικνύονται τα αποτελέσματα κάθε σταδίου και μεμονωμένου βήματος·
- υποδεικνύεται ο τομέας ευθύνης για κάθε στάδιο και βήμα.
- έχουν προσδιοριστεί τεχνικοί πόροι, για παράδειγμα HDD (SSD), RAM, vCPU και εργατοώρες που είναι απαραίτητες για την υποστήριξη της εργασίας σε αυτό το στάδιο, τόσο στο τρέχον - πραγματικό όσο και στο μελλοντικό σχέδιο.
- για κάθε προϊόν υποδεικνύεται ποια τεχνολογικά στάδια ή βήματα για αυτό έχουν υλοποιηθεί, έχουν προγραμματιστεί για εφαρμογή, είναι άσχετα ή δεν έχουν εφαρμοστεί.
Λήψη αποφάσεων με βάση τον τεχνολογικό χάρτη
Αφού μελετήσετε τον χάρτη, μπορείτε να προβείτε σε ορισμένες ενέργειες, ανάλογα με τον ρόλο του υπαλλήλου στην εταιρεία (υπεύθυνος ανάπτυξης, διευθυντής προϊόντων, προγραμματιστής ή δοκιμαστής):
- να κατανοήσουν ποια στάδια λείπουν σε ένα πραγματικό προϊόν ή έργο και να αξιολογήσουν την ανάγκη για την υλοποίησή τους·
- οριοθετήστε τους τομείς ευθύνης μεταξύ πολλών τμημάτων εάν εργάζονται σε διαφορετικά στάδια·
- διαπραγματεύονται συμβάσεις για τις εισροές και τις εκροές των σταδίων·
- ενσωματώστε το στάδιο της εργασίας σας στη συνολική διαδικασία ανάπτυξης·
- αξιολογήσει με μεγαλύτερη ακρίβεια την ανάγκη για πόρους για την υποστήριξη κάθε σταδίου.
Συνοψίζοντας όλα τα παραπάνω
Ο χάρτης τεχνολογίας είναι ευέλικτος, επεκτάσιμος και εύκολος στη συντήρηση. Είναι πολύ πιο εύκολο να αναπτυχθούν και να διατηρηθούν περιγραφές διεργασιών σε αυτή τη μορφή από ό,τι στο αυστηρό ακαδημαϊκό μοντέλο IDEF0. Επιπλέον, μια περιγραφή σε πίνακα είναι απλούστερη, πιο οικεία και καλύτερα δομημένη από ένα λειτουργικό μοντέλο.
Ένα ειδικό εσωτερικό εργαλείο, το CrossBuilder, είναι υπεύθυνο για την τεχνική υλοποίηση των βημάτων - ένα εργαλείο διαστρωμάτωσης μεταξύ συστημάτων CI, υπηρεσιών και υποδομής. Ο προγραμματιστής δεν χρειάζεται να κόψει το ποδήλατό του: στο σύστημα CI μας αρκεί να εκτελέσετε ένα από τα σενάρια (το λεγόμενο task) του εργαλείου CrossBuilder, το οποίο θα το εκτελέσει σωστά, λαμβάνοντας υπόψη τις δυνατότητες της υποδομής μας.
Αποτελέσματα της
Το άρθρο αποδείχθηκε αρκετά μεγάλο, αλλά αυτό είναι αναπόφευκτο όταν περιγράφεται η μοντελοποίηση πολύπλοκων διαδικασιών. Στο τέλος, θα ήθελα να αναφέρω εν συντομία τις βασικές μας ιδέες:
- Ο στόχος της εισαγωγής των ιδεών DevOps στην εταιρεία μας είναι η σταθερή μείωση του κόστους παραγωγής και συντήρησης των προϊόντων της εταιρείας σε ποσοτικούς όρους (εργατοώρες ή ώρες μηχανής, vCPU, RAM, Δίσκος).
- Ένας τρόπος μείωσης του συνολικού κόστους ανάπτυξης είναι η ελαχιστοποίηση του κόστους εκτέλεσης τυπικών σειριακών εργασιών: στάδια και βήματα της τεχνολογικής διαδικασίας.
- Μια τυπική εργασία είναι μια εργασία της οποίας η λύση είναι πλήρως ή μερικώς αυτοματοποιημένη, δεν προκαλεί δυσκολίες στους εκτελεστές και δεν απαιτεί σημαντικό κόστος εργασίας.
- Η διαδικασία παραγωγής αποτελείται από στάδια, τα στάδια χωρίζονται σε αδιαίρετα βήματα, τα οποία αντιπροσωπεύουν τυπικές εργασίες διαφορετικών κλιμάκων και όγκων.
- Από μεμονωμένες τυπικές εργασίες έχουμε καταλήξει σε πολύπλοκες τεχνολογικές αλυσίδες και μοντέλα πολλαπλών επιπέδων της παραγωγικής διαδικασίας, τα οποία μπορούν να περιγραφούν από ένα λειτουργικό μοντέλο IDEF0 ή έναν απλούστερο τεχνολογικό χάρτη.
- Το διάγραμμα ροής είναι μια αναπαράσταση σε πίνακα των σταδίων και των σταδίων μιας παραγωγικής διαδικασίας. Το πιο σημαντικό: ο χάρτης σας επιτρέπει να δείτε ολόκληρη τη διαδικασία στο σύνολό της, σε μεγάλα κομμάτια με δυνατότητα λεπτομέρειας.
- Με βάση τον τεχνολογικό χάρτη, μπορείτε να αξιολογήσετε την ανάγκη υλοποίησης σταδίων σε ένα συγκεκριμένο προϊόν, να οριοθετήσετε τους τομείς ευθύνης, να συμφωνήσετε για συμβάσεις για τις εισροές και τις εκροές των σταδίων και να αξιολογήσετε με μεγαλύτερη ακρίβεια την ανάγκη για πόρους.
Στα επόμενα άρθρα θα μιλήσουμε αναλυτικότερα για το ποια τεχνικά εργαλεία χρησιμοποιούνται για την υλοποίηση συγκεκριμένων τεχνολογικών σταδίων στον χάρτη μας.
Συντάκτες του άρθρου:
- — Επικεφαλής του Τμήματος Αυτοματισμού (DevOps) στη Positive Technologies
- - αναπληρωτής Επικεφαλής του Τμήματος Αυτοματισμού (DevOps) στην Positive Technologies
Πηγή: www.habr.com