Για να είμαι ειλικρινής, ο Ιβάν γελούσε συχνά με τις μάταιες προσπάθειες των συναδέλφων του από το τμήμα παρακολούθησης. Έκαναν μεγάλες προσπάθειες για να εφαρμόσουν τις μετρήσεις που τους διέταξε να επιτύχουν η διοίκηση της εταιρείας. Ήταν τόσο απασχολημένοι που δεν ήθελαν κανένας άλλος να κάνει τίποτα.
Αλλά δεν ήταν αρκετό για τη διοίκηση - παρήγγειλαν συνεχώς όλο και περισσότερες νέες μετρήσεις, σταματώντας πολύ γρήγορα να χρησιμοποιούν ό,τι είχε γίνει στο παρελθόν.
Τον τελευταίο καιρό, όλοι μιλούν για το LeadTime - την ώρα για την παράδοση των επιχειρηματικών λειτουργιών. Η μέτρηση έδειξε έναν τρελό αριθμό - 200 ημέρες για να παραδοθεί μία εργασία. Πώς όλοι φώναξαν και σήκωσαν τα χέρια τους στον ουρανό!
Μετά από κάποιο χρονικό διάστημα, ο θόρυβος σταδιακά μειώθηκε και η διοίκηση έλαβε εντολή να δημιουργήσει μια άλλη μέτρηση.
Ήταν απολύτως σαφές στον Ιβάν ότι η νέα μέτρηση θα πέθαινε το ίδιο ήσυχα σε μια σκοτεινή γωνία.
Πράγματι, σκέφτηκε ο Ιβάν, γνωρίζοντας ότι ο αριθμός δεν λέει σε κανέναν απολύτως τίποτα. 200 ημέρες ή 2 ημέρες - δεν υπάρχει διαφορά, γιατί είναι αδύνατο να προσδιοριστεί ο λόγος από τον αριθμό και να καταλάβουμε αν είναι καλό ή κακό.
Αυτή είναι μια τυπική παγίδα μετρικών: φαίνεται ότι μια νέα μέτρηση θα πει την ουσία της ύπαρξης και θα εξηγήσει κάποιο μυστικό μυστικό. Όλοι ελπίζουν τόσο πολύ σε αυτό, αλλά για κάποιο λόγο δεν συμβαίνει τίποτα. Ναι, γιατί το μυστικό δεν πρέπει να βρίσκεται στις μετρήσεις!
Για τον Ιβάν, αυτό ήταν ένα περασμένο στάδιο. Αυτό το κατάλαβε για μετρήσεις και όλα τα μυστικά πρέπει να αναζητηθούν , δηλ. είναι ότι αυτή η μέτρηση σχηματίζεται.
Για ένα ηλεκτρονικό κατάστημα, το αντικείμενο επιρροής θα είναι οι πελάτες του που φέρνουν χρήματα και για τα DevOps θα είναι οι ομάδες που δημιουργούν και διανέμουν διανομές χρησιμοποιώντας μια διοχέτευση.
Μια μέρα, καθισμένος σε μια άνετη καρέκλα στην αίθουσα, ο Ivan αποφάσισε να σκεφτεί προσεκτικά πώς ήθελε να δει τις μετρήσεις του DevOps, λαμβάνοντας υπόψη το γεγονός ότι το αντικείμενο επιρροής είναι οι ομάδες.
Σκοπός των μετρήσεων DevOps
Είναι σαφές ότι όλοι θέλουν να μειώσουν τον χρόνο παράδοσης. 200 μέρες δεν είναι, φυσικά, καλό.
Πώς όμως, αυτό είναι το ερώτημα;
Η εταιρεία απασχολεί εκατοντάδες ομάδες και χιλιάδες διανομές περνούν από τον αγωγό DevOps κάθε μέρα. Ο πραγματικός χρόνος παράδοσης θα εμφανίζεται ως διανομή. Κάθε ομάδα θα έχει τον δικό της χρόνο και τα δικά της χαρακτηριστικά. Πώς μπορείς να βρεις κάτι σε αυτό το χάος;
Η απάντηση προέκυψε φυσικά - πρέπει να βρούμε τις προβληματικές ομάδες και να καταλάβουμε τι συμβαίνει με αυτές και γιατί διαρκεί τόσο πολύ, και να μάθουμε από τις «καλές» ομάδες πώς να κάνουμε τα πάντα γρήγορα. Και για να το κάνετε αυτό, πρέπει να μετρήσετε τον χρόνο που αφιερώνουν οι ομάδες σε κάθε ένα από τα περίπτερα DevOps:
«Σκοπός του συστήματος θα είναι να επιλέγει ομάδες με βάση τον χρόνο που περνούν από την κερκίδα, δηλ. Ως αποτέλεσμα, θα πρέπει να λάβουμε μια λίστα εντολών με τον επιλεγμένο χρόνο και όχι έναν αριθμό.
Αν μάθουμε πόσος χρόνος δαπανήθηκε στην κερκίδα συνολικά και πόσος χρόνος για διακοπές μεταξύ κερκίδων, μπορούμε να βρούμε τις ομάδες, να τις καλέσουμε και να κατανοήσουμε τους λόγους με περισσότερες λεπτομέρειες και να τις εξαλείψουμε», σκέφτηκε ο Ιβάν.
Πώς να υπολογίσετε τον χρόνο παράδοσης για DevOps
Για τον υπολογισμό του, ήταν απαραίτητο να εμβαθύνουμε στη διαδικασία DevOps και στην ουσία της.
Η εταιρεία χρησιμοποιεί περιορισμένο αριθμό συστημάτων και πληροφορίες μπορούν να ληφθούν μόνο από αυτά και πουθενά αλλού.
Όλες οι εργασίες στην εταιρεία καταχωρήθηκαν στο Jira. Όταν αναλαμβανόταν μια εργασία, δημιουργήθηκε ένας κλάδος για αυτήν και μετά την υλοποίηση, πραγματοποιήθηκε μια δέσμευση στο BitBucket και στο Pull Request. Όταν έγινε αποδεκτό ένα PR (Pull Request), μια διανομή δημιουργήθηκε αυτόματα και αποθηκεύτηκε στο αποθετήριο Nexus.
Στη συνέχεια, η διανομή κυκλοφόρησε σε πολλά περίπτερα χρησιμοποιώντας το Jenkins για να ελέγξει την ορθότητα της διάθεσης, της αυτόματης και χειροκίνητης δοκιμής:
Ο Ιβάν περιέγραψε από ποια συστήματα ποιες πληροφορίες μπορούν να ληφθούν για τον υπολογισμό του χρόνου στα περίπτερα:
- Από το Nexus – Χρόνος δημιουργίας διανομής και όνομα του φακέλου που περιείχε τον κωδικό εντολής
- Από Jenkins – Χρόνος έναρξης, διάρκεια και αποτέλεσμα κάθε εργασίας, όνομα βάσης (στις παραμέτρους εργασίας), στάδια (βήματα εργασίας), σύνδεσμος προς τη διανομή στο Nexus.
- Ο Ιβάν αποφάσισε να μην συμπεριλάβει τους Jira και BitBucket στα σκαριά, γιατί... σχετίζονταν περισσότερο με το στάδιο ανάπτυξης και όχι με τη διάθεση της τελικής διανομής στα περίπτερα.
Με βάση τις διαθέσιμες πληροφορίες, σχεδιάστηκε το ακόλουθο διάγραμμα:
Γνωρίζοντας πόσος χρόνος χρειάζεται για να δημιουργηθούν διανομές και πόσος χρόνος δαπανάται για καθεμία από αυτές, μπορείτε εύκολα να υπολογίσετε το συνολικό κόστος της διέλευσης ολόκληρου του αγωγού DevOps (πλήρης κύκλος).
Ακολουθούν οι μετρήσεις DevOps στις οποίες κατέληξε ο Ivan:
- Αριθμός διανομών που δημιουργήθηκαν
- Μερίδιο διανομών που «ήρθαν» στο περίπτερο και «πέρασαν» το περίπτερο
- Χρόνος παραμονής στο σταντ (κύκλος βάσης)
- Πλήρης κύκλος (συνολικός χρόνος για όλες τις κερκίδες)
- Διάρκεια εργασίας
- Χρόνος διακοπής μεταξύ κερκίδων
- Χρόνος διακοπής λειτουργίας μεταξύ εκκινήσεων εργασιών στο ίδιο περίπτερο
Αφενός, οι μετρήσεις χαρακτήρισαν πολύ καλά τον αγωγό DevOps από άποψη χρόνου, αφετέρου θεωρήθηκαν πολύ απλές.
Ικανοποιημένος με την καλή δουλειά που έγινε, ο Ιβάν έκανε μια παρουσίαση και πήγε να την παρουσιάσει στη διοίκηση.
Γύρισε μελαγχολικός και με τα χέρια κάτω.
«Αυτό είναι φιάσκο, αδερφέ», χαμογέλασε ο ειρωνικός συνάδελφος...
Διαβάστε περισσότερα στο άρθρο "».
Πηγή: www.habr.com