Γεια σου, Χαμπρ! Προηγουμένως, παραπονιόμουν για τη ζωή στην Υποδομή ως πρότυπο κώδικα και δεν πρόσφερα τίποτα για να λύσει την τρέχουσα κατάσταση. Σήμερα επιστρέφω για να σας πω ποιες προσεγγίσεις και πρακτικές θα σας βοηθήσουν να ξεφύγετε από την άβυσσο της απόγνωσης και να κατευθύνετε την κατάσταση στη σωστή κατεύθυνση.
Σε ένα προηγούμενο άρθρο Μοιράστηκα τις εντυπώσεις μου για αυτόν τον τομέα, προσπάθησα να αναλογιστώ την τρέχουσα κατάσταση σε αυτόν τον τομέα και μάλιστα πρότεινα ότι οι τυπικές πρακτικές που είναι γνωστές σε όλους τους προγραμματιστές θα μπορούσαν να βοηθήσουν. Μπορεί να φαίνεται ότι υπήρχαν πολλά παράπονα για τη ζωή, αλλά δεν υπήρχαν προτάσεις για έξοδο από την τρέχουσα κατάσταση.
Ποιοι είμαστε, που βρισκόμαστε και τι προβλήματα έχουμε
Αυτήν τη στιγμή βρισκόμαστε στην ομάδα Sre Onboarding, η οποία αποτελείται από έξι προγραμματιστές και τρεις μηχανικούς υποδομής. Όλοι προσπαθούμε να γράψουμε την Υποδομή ως κώδικα (IaC). Το κάνουμε αυτό γιατί βασικά ξέρουμε πώς να γράφουμε κώδικα και έχουμε ιστορικό προγραμματιστών «πάνω από το μέσο όρο».
- Έχουμε ένα σύνολο πλεονεκτημάτων: ένα ορισμένο υπόβαθρο, γνώση πρακτικών, ικανότητα σύνταξης κώδικα, επιθυμία να μάθουμε νέα πράγματα.
- Και υπάρχει ένα κομμάτι που χαλαρώνει, το οποίο είναι επίσης ένα μείον: η έλλειψη γνώσης σχετικά με το υλικό υποδομής.
Η στοίβα τεχνολογίας που χρησιμοποιούμε στο IaC μας.
- Terraform για τη δημιουργία πόρων.
- Συσκευαστής για τη συναρμολόγηση εικόνων. Αυτές είναι εικόνες Windows, CentOS 7.
- Jsonnet για να δημιουργήσετε μια ισχυρή κατασκευή στο drone.io, καθώς και για να δημιουργήσετε το πακέτο json και τις terraform modules μας.
- Αζω.
- Ansible κατά την προετοιμασία εικόνων.
- Python για βοηθητικές υπηρεσίες και σενάρια παροχής.
- Και όλα αυτά στο VSCode με πρόσθετα κοινά μεταξύ των μελών της ομάδας.
Συμπέρασμα από το δικό μου ήταν κάπως έτσι: Προσπάθησα να εμφυσήσω (πρώτα απ' όλα στον εαυτό μου) αισιοδοξία, ήθελα να πω ότι θα δοκιμάσουμε τις γνωστές μας προσεγγίσεις και πρακτικές για να αντιμετωπίσουμε τις δυσκολίες και τις πολυπλοκότητες που υπάρχουν σε αυτόν τον τομέα.
Αυτήν τη στιγμή παλεύουμε με τα ακόλουθα ζητήματα IaC:
- Ατέλεια εργαλείων και μέσων για την ανάπτυξη κώδικα.
- Αργή ανάπτυξη. Η υποδομή είναι μέρος του πραγματικού κόσμου και μπορεί να είναι αργή.
- Έλλειψη προσεγγίσεων και πρακτικών.
- Είμαστε νέοι και δεν ξέρουμε πολλά.
Extreme Programming (XP) στη διάσωση
Όλοι οι προγραμματιστές είναι εξοικειωμένοι με τον Extreme Programming (XP) και τις πρακτικές που κρύβονται πίσω από αυτό. Πολλοί από εμάς έχουμε εργαστεί με αυτήν την προσέγγιση, και ήταν επιτυχής. Γιατί λοιπόν να μην χρησιμοποιήσετε τις αρχές και τις πρακτικές που ορίζονται εκεί για να ξεπεράσετε τις προκλήσεις των υποδομών; Αποφασίσαμε να ακολουθήσουμε αυτήν την προσέγγιση και να δούμε τι θα συμβεί.
Έλεγχος της δυνατότητας εφαρμογής της προσέγγισης XP στον κλάδο σαςΑκολουθεί μια περιγραφή του περιβάλλοντος για το οποίο είναι κατάλληλο το XP και πώς σχετίζεται με εμάς:
1. Δυναμικά μεταβαλλόμενες απαιτήσεις λογισμικού. Ήταν ξεκάθαρο για εμάς ποιος ήταν ο τελικός στόχος. Αλλά οι λεπτομέρειες μπορεί να διαφέρουν. Εμείς οι ίδιοι αποφασίζουμε πού πρέπει να πάμε ταξί, οπότε οι απαιτήσεις αλλάζουν περιοδικά (κυρίως μόνοι μας). Αν πάρουμε την ομάδα SRE, η οποία κάνει η ίδια τον αυτοματισμό και η ίδια περιορίζει τις απαιτήσεις και το εύρος εργασίας, τότε αυτό το σημείο ταιριάζει καλά.
2. Κίνδυνοι που προκαλούνται από έργα καθορισμένου χρόνου που χρησιμοποιούν νέα τεχνολογία. Μπορεί να αντιμετωπίσουμε κινδύνους όταν χρησιμοποιούμε κάποια πράγματα άγνωστα σε εμάς. Και αυτό είναι 100% η περίπτωσή μας. Ολόκληρο το έργο μας ήταν η χρήση τεχνολογιών που δεν γνωρίζαμε πλήρως. Γενικά, αυτό είναι ένα μόνιμο πρόβλημα, γιατί... Υπάρχουν πολλές νέες τεχνολογίες που αναδύονται συνεχώς στον τομέα των υποδομών.
3,4. Μικρή, συστεγαζόμενη εκτεταμένη ομάδα ανάπτυξης. Η αυτοματοποιημένη τεχνολογία που χρησιμοποιείτε επιτρέπει δοκιμές μονάδων και λειτουργικών δοκιμών. Αυτά τα δύο σημεία δεν μας ταιριάζουν καθόλου. Πρώτον, δεν είμαστε μια συντονισμένη ομάδα και δεύτερον, είμαστε εννέα, που μπορεί να θεωρηθεί μεγάλη ομάδα. Αν και, σύμφωνα με ορισμένους ορισμούς μιας «μεγάλης» ομάδας, πολλά είναι 14+ άτομα.
Ας δούμε μερικές πρακτικές XP και πώς επηρεάζουν την ταχύτητα και την ποιότητα της ανάδρασης.
Αρχή βρόχου ανατροφοδότησης XP
Κατά την κατανόησή μου, η ανατροφοδότηση είναι η απάντηση στην ερώτηση, κάνω το σωστό, πηγαίνουμε εκεί; Το XP έχει ένα θεϊκό σχέδιο για αυτό: έναν βρόχο ανάδρασης χρόνου. Το ενδιαφέρον είναι ότι όσο πιο χαμηλά είμαστε, τόσο πιο γρήγορα μπορούμε να κάνουμε το λειτουργικό σύστημα να απαντήσει στις απαραίτητες ερωτήσεις.
Αυτό είναι ένα αρκετά ενδιαφέρον θέμα για συζήτηση, ότι στη βιομηχανία πληροφορικής μας είναι δυνατό να αποκτήσουμε γρήγορα ένα λειτουργικό σύστημα. Φανταστείτε πόσο οδυνηρό είναι να κάνετε ένα έργο για έξι μήνες και μόνο τότε να ανακαλύψετε ότι υπήρχε ένα λάθος στην αρχή. Αυτό συμβαίνει στο σχεδιασμό και σε οποιαδήποτε κατασκευή πολύπλοκων συστημάτων.
Στην περίπτωσή μας του IaC, η ανατροφοδότηση μας βοηθά. Θα κάνω αμέσως μια μικρή προσαρμογή στο παραπάνω διάγραμμα: το σχέδιο έκδοσης δεν έχει μηνιαίο κύκλο, αλλά εμφανίζεται πολλές φορές την ημέρα. Υπάρχουν ορισμένες πρακτικές που συνδέονται με αυτόν τον κύκλο λειτουργικού συστήματος τις οποίες θα εξετάσουμε με περισσότερες λεπτομέρειες.
Σημαντικό: η ανατροφοδότηση μπορεί να είναι μια λύση σε όλα τα προβλήματα που αναφέρθηκαν παραπάνω. Σε συνδυασμό με πρακτικές XP, μπορεί να σας βγάλει από την άβυσσο της απόγνωσης.
Πώς να βγάλετε τον εαυτό σας από την άβυσσο της απόγνωσης: τρεις πρακτικές
Δοκιμές
Οι δοκιμές αναφέρονται δύο φορές στον βρόχο ανάδρασης XP. Δεν είναι μόνο έτσι. Είναι εξαιρετικά σημαντικά για όλη την τεχνική του Extreme Programming.
Υποτίθεται ότι έχετε τεστ Unit και Acceptance. Μερικά σας δίνουν σχόλια σε λίγα λεπτά, άλλα σε λίγες ημέρες, επομένως χρειάζονται περισσότερο χρόνο για να γραφτούν και ελέγχονται λιγότερο συχνά.
Υπάρχει μια κλασική πυραμίδα δοκιμών, η οποία δείχνει ότι πρέπει να υπάρχουν περισσότερες δοκιμές.
Πώς εφαρμόζεται αυτό το πλαίσιο σε εμάς σε ένα έργο IaC; Στην πραγματικότητα... καθόλου.
- Οι δοκιμές μονάδων, παρά το γεγονός ότι θα πρέπει να είναι πολλές, δεν μπορούν να είναι πάρα πολλές. Ή δοκιμάζουν κάτι πολύ έμμεσα. Μάλιστα μπορούμε να πούμε ότι δεν τα γράφουμε καθόλου. Αλλά εδώ είναι μερικές εφαρμογές για τέτοιες δοκιμές που μπορέσαμε να κάνουμε:
- Δοκιμή κώδικα jsonnet. Αυτός, για παράδειγμα, είναι ο αγωγός συναρμολόγησης drone μας, ο οποίος είναι αρκετά περίπλοκος. Ο κώδικας jsonnet καλύπτεται καλά από δοκιμές.
Χρησιμοποιούμε αυτό . - Δοκιμές για σενάρια που εκτελούνται κατά την εκκίνηση του πόρου. Τα σενάρια γράφονται σε Python και επομένως μπορούν να γραφτούν τεστ σε αυτά.
- Δοκιμή κώδικα jsonnet. Αυτός, για παράδειγμα, είναι ο αγωγός συναρμολόγησης drone μας, ο οποίος είναι αρκετά περίπλοκος. Ο κώδικας jsonnet καλύπτεται καλά από δοκιμές.
- Είναι δυνητικά δυνατός ο έλεγχος της διαμόρφωσης σε δοκιμές, αλλά δεν το κάνουμε αυτό. Είναι επίσης δυνατό να ρυθμίσετε τους κανόνες ρύθμισης παραμέτρων ελέγχου πόρων μέσω . Ωστόσο, οι έλεγχοι εκεί είναι απλώς πολύ βασικοί για το terraform, αλλά πολλά σενάρια δοκιμών είναι γραμμένα για το AWS. Και είμαστε στο Azure, οπότε αυτό και πάλι δεν ισχύει.
- Δοκιμές ολοκλήρωσης εξαρτημάτων: εξαρτάται από το πώς τα ταξινομείτε και πού τα τοποθετείτε. Αλλά βασικά λειτουργούν.
Έτσι μοιάζουν τα τεστ ολοκλήρωσης.
Αυτό είναι ένα παράδειγμα κατά τη δημιουργία εικόνων στο Drone CI. Για να τα φτάσετε, πρέπει να περιμένετε 30 λεπτά για να σχηματιστεί η εικόνα του Packer και μετά να περιμένετε άλλα 15 λεπτά για να περάσουν. Αλλά υπάρχουν!Αλγόριθμος επαλήθευσης εικόνας
- Ο συσκευαστής πρέπει πρώτα να προετοιμάσει πλήρως την εικόνα.
- Δίπλα στη δοκιμή υπάρχει ένα terraform με τοπική κατάσταση, το οποίο χρησιμοποιούμε για να αναπτύξουμε αυτήν την εικόνα.
- Όταν ξεδιπλώνεται, χρησιμοποιείται μια μικρή μονάδα που βρίσκεται κοντά για να διευκολύνεται η εργασία με την εικόνα.
- Μόλις αναπτυχθεί το VM από την εικόνα, μπορούν να ξεκινήσουν οι έλεγχοι. Βασικά, οι έλεγχοι γίνονται με αυτοκίνητο. Ελέγχει πώς λειτουργούσαν τα σενάρια κατά την εκκίνηση και πώς λειτουργούν οι δαίμονες. Για να το κάνουμε αυτό, μέσω ssh ή winrm συνδέουμε το νέο μηχάνημα και ελέγχουμε την κατάσταση διαμόρφωσης ή εάν οι υπηρεσίες είναι ανοιχτές.
- Η κατάσταση είναι παρόμοια με τις δοκιμές ενσωμάτωσης σε ενότητες για terraform. Ακολουθεί ένας σύντομος πίνακας που εξηγεί τα χαρακτηριστικά τέτοιων δοκιμών.
Η ανατροφοδότηση για τον αγωγό είναι περίπου 40 λεπτά. Όλα συμβαίνουν για πολύ καιρό. Μπορεί να χρησιμοποιηθεί για παλινδρόμηση, αλλά για νέα ανάπτυξη είναι γενικά μη ρεαλιστική. Εάν είστε πολύ, πολύ προετοιμασμένοι για αυτό, ετοιμάστε σενάρια εκτέλεσης, τότε μπορείτε να το μειώσετε στα 10 λεπτά. Αλλά αυτά δεν είναι ακόμα δοκιμές Unit, που κάνουν 5 κομμάτια σε 100 δευτερόλεπτα.
Η απουσία δοκιμών μονάδας κατά τη συναρμολόγηση εικόνων ή δομοστοιχείων εδάφους ενθαρρύνει τη μετατόπιση της εργασίας σε ξεχωριστές υπηρεσίες που μπορούν απλώς να εκτελεστούν μέσω REST ή σε σενάρια Python.
Για παράδειγμα, έπρεπε να βεβαιωθούμε ότι όταν ξεκινά η εικονική μηχανή, εγγράφεται στην υπηρεσία , και όταν η εικονική μηχανή καταστράφηκε, διαγράφηκε μόνη της.
Εφόσον έχουμε το ScaleFT ως υπηρεσία, αναγκαζόμαστε να δουλέψουμε μαζί του μέσω του API. Υπήρχε ένα περιτύλιγμα γραμμένο εκεί που μπορούσες να τραβήξεις και να πεις: «Μπείτε και διαγράψτε αυτό και αυτό». Αποθηκεύει όλες τις απαραίτητες ρυθμίσεις και προσβάσεις.
Μπορούμε ήδη να γράψουμε κανονικές δοκιμές για αυτό, αφού δεν διαφέρει από το συνηθισμένο λογισμικό: κάποιο είδος apiha κοροϊδεύεται, το τραβάτε και δείτε τι συμβαίνει.
Αποτελέσματα των δοκιμών: Η δοκιμή μονάδας, η οποία θα πρέπει να δώσει το λειτουργικό σύστημα σε ένα λεπτό, δεν το δίνει. Και οι τύποι δοκιμών υψηλότερα στην πυραμίδα είναι αποτελεσματικοί, αλλά καλύπτουν μόνο ένα μέρος των προβλημάτων.
Προγραμματισμός ζευγών
Οι δοκιμές είναι, φυσικά, καλές. Μπορείτε να γράψετε πολλά από αυτά, μπορεί να είναι διαφορετικών τύπων. Θα δουλέψουν στα επίπεδά τους και θα μας δώσουν σχόλια. Αλλά το πρόβλημα με τις κακές δοκιμές Unit, που δίνουν το ταχύτερο λειτουργικό σύστημα, παραμένει. Ταυτόχρονα, εξακολουθώ να θέλω ένα γρήγορο λειτουργικό σύστημα που να είναι εύκολο και ευχάριστο στην εργασία. Για να μην αναφέρουμε την ποιότητα της λύσης που προκύπτει. Ευτυχώς, υπάρχουν τεχνικές που μπορούν να παρέχουν ακόμη πιο γρήγορη ανατροφοδότηση από τις δοκιμές μονάδας. Αυτός είναι προγραμματισμός ζευγών.
Όταν γράφετε κώδικα, θέλετε να λαμβάνετε σχόλια για την ποιότητά του όσο το δυνατόν γρηγορότερα. Ναι, μπορείτε να γράψετε τα πάντα σε έναν κλάδο χαρακτηριστικών (για να μην σπάσετε τίποτα για κανέναν), να κάνετε ένα αίτημα έλξης στο Github, να το εκχωρήσετε σε κάποιον του οποίου η γνώμη έχει βάρος και να περιμένετε απάντηση.
Αλλά μπορείτε να περιμένετε πολύ. Οι άνθρωποι είναι όλοι απασχολημένοι και η απάντηση, ακόμα κι αν υπάρχει, μπορεί να μην είναι της υψηλότερης ποιότητας. Ας υποθέσουμε ότι η απάντηση ήρθε αμέσως, ο κριτικός κατάλαβε αμέσως την όλη ιδέα, αλλά η απάντηση έρχεται ακόμα αργά, μετά το γεγονός. Μακάρι να ήταν νωρίτερα. Σε αυτό στοχεύει ο προγραμματισμός ζευγών – αμέσως, τη στιγμή της συγγραφής.
Ακολουθούν τα στυλ προγραμματισμού ζεύγους και η δυνατότητα εφαρμογής τους στην εργασία στο IaC:
1. Κλασικό, Έμπειρο+Έμπειρο, μετατόπιση με χρονόμετρο. Δύο ρόλοι - οδηγός και πλοηγός. Δύο άνθρωποι. Δουλεύουν στον ίδιο κώδικα και αλλάζουν ρόλους μετά από μια συγκεκριμένη προκαθορισμένη χρονική περίοδο.
Ας εξετάσουμε τη συμβατότητα των προβλημάτων μας με το στυλ:
- Πρόβλημα: ατέλεια εργαλείων και εργαλείων για την ανάπτυξη κώδικα.
Αρνητικός αντίκτυπος: χρειάζεται περισσότερος χρόνος για να αναπτυχθεί, επιβραδύνουμε, ο ρυθμός/ρυθμός της εργασίας χάνεται.
Πώς πολεμάμε: χρησιμοποιούμε ένα διαφορετικό εργαλείο, ένα κοινό IDE και επίσης μαθαίνουμε συντομεύσεις. - Πρόβλημα: Αργή ανάπτυξη.
Αρνητικός αντίκτυπος: αυξάνει τον χρόνο που απαιτείται για τη δημιουργία ενός λειτουργικού τμήματος κώδικα. Βαριόμαστε περιμένοντας, τα χέρια μας απλώνουν να κάνουμε κάτι άλλο όσο περιμένουμε.
Πώς πολεμάμε: δεν το ξεπεράσαμε. - Πρόβλημα: έλλειψη προσεγγίσεων και πρακτικών.
Αρνητικός αντίκτυπος: δεν υπάρχει γνώση για το πώς να το κάνετε καλά και πώς να το κάνετε άσχημα. Επιμηκύνει τη λήψη σχολίων.
Πώς πολεμάμε: η αμοιβαία ανταλλαγή απόψεων και πρακτικών στην εργασία σε ζευγάρια σχεδόν λύνει το πρόβλημα.
Το κύριο πρόβλημα με τη χρήση αυτού του στυλ στο IaC είναι ο ανομοιόμορφος ρυθμός εργασίας. Στην παραδοσιακή ανάπτυξη λογισμικού, έχετε μια πολύ ομοιόμορφη κίνηση. Μπορείτε να αφιερώσετε πέντε λεπτά και να γράψετε Ν. Αφιερώστε 10 λεπτά και γράψτε 2Ν, 15 λεπτά - 3Ν. Εδώ μπορείτε να αφιερώσετε πέντε λεπτά και να γράψετε Ν, και μετά να αφιερώσετε άλλα 30 λεπτά και να γράψετε το ένα δέκατο του Ν. Εδώ δεν ξέρετε τίποτα, έχετε κολλήσει, ηλίθιος. Η έρευνα απαιτεί χρόνο και αποσπά την προσοχή από τον ίδιο τον προγραμματισμό.
Συμπέρασμα: στην καθαρή του μορφή δεν είναι κατάλληλο για εμάς.
2. Πινγκ-πονγκ. Αυτή η προσέγγιση περιλαμβάνει ένα άτομο που γράφει το τεστ και ένα άλλο κάνει την υλοποίηση για αυτό. Λαμβάνοντας υπόψη το γεγονός ότι τα πάντα είναι περίπλοκα με τις δοκιμές Unit και πρέπει να γράψετε ένα τεστ ολοκλήρωσης που χρειάζεται πολύ χρόνο για να προγραμματιστεί, όλη η ευκολία του πινγκ-πονγκ εξαφανίζεται.
Μπορώ να πω ότι προσπαθήσαμε να διαχωρίσουμε τις αρμοδιότητες για το σχεδιασμό ενός δοκιμαστικού σεναρίου και την εφαρμογή κώδικα για αυτό. Ένας συμμετέχων σκέφτηκε το σενάριο, σε αυτό το μέρος της δουλειάς ήταν υπεύθυνος, είχε τον τελευταίο λόγο. Και ο άλλος ήταν υπεύθυνος για την υλοποίηση. Λειτουργούσε καλά. Η ποιότητα του σεναρίου με αυτήν την προσέγγιση αυξάνεται.
Συμπέρασμα: δυστυχώς, ο ρυθμός εργασίας δεν επιτρέπει τη χρήση του πινγκ-πονγκ ως πρακτική προγραμματισμού ζευγών στο IaC.
3.Strong Style. . Η ιδέα είναι ότι ένας συμμετέχων γίνεται ο πλοηγός οδηγιών και ο δεύτερος παίρνει το ρόλο του οδηγού εκτέλεσης. Σε αυτή την περίπτωση, το δικαίωμα λήψης αποφάσεων ανήκει αποκλειστικά στον πλοηγό. Το πρόγραμμα οδήγησης εκτυπώνει μόνο και μπορεί να επηρεάσει τι συμβαίνει με μια λέξη. Οι ρόλοι δεν αλλάζουν για πολύ καιρό.
Καλό για μάθηση, αλλά απαιτεί ισχυρές μαλακές δεξιότητες. Εδώ είναι που παραπαίαμε. Η τεχνική ήταν δύσκολη. Και δεν πρόκειται καν για υποδομές.
Συμπέρασμα: μπορεί ενδεχομένως να χρησιμοποιηθεί, δεν εγκαταλείπουμε την προσπάθεια.
4. Mobbing, swarming και όλα τα γνωστά αλλά μη καταγεγραμμένα στυλ Δεν το θεωρούμε, γιατί Δεν το έχουμε δοκιμάσει και είναι αδύνατο να μιλήσουμε για αυτό στο πλαίσιο της δουλειάς μας.
Γενικά αποτελέσματα σχετικά με τη χρήση προγραμματισμού ζευγών:
- Έχουμε έναν ανομοιόμορφο ρυθμό εργασίας, ο οποίος προκαλεί σύγχυση.
- Βρεθήκαμε σε ανεπαρκώς καλές soft skills. Και η θεματική δεν βοηθά να ξεπεράσουμε αυτές τις ελλείψεις μας.
- Οι μακροχρόνιες δοκιμές και τα προβλήματα με τα εργαλεία καθιστούν δύσκολη την ανάπτυξη ζευγών.
5. Παρόλα αυτά υπήρξαν επιτυχίες. Καταλήξαμε στη δική μας μέθοδο «Σύγκλιση - Απόκλιση». Θα περιγράψω εν συντομία πώς λειτουργεί.
Έχουμε μόνιμους συνεργάτες για λίγες μέρες (λιγότερο από μία εβδομάδα). Κάνουμε μια εργασία μαζί. Καθόμαστε για λίγο μαζί: ο ένας γράφει, ο άλλος κάθεται και παρακολουθεί την ομάδα υποστήριξης. Μετά διασκορπιζόμαστε για κάποιο διάστημα, ο καθένας κάνει κάποια ανεξάρτητα πράγματα, μετά μαζευόμαστε ξανά, συγχρονιζόμαστε πολύ γρήγορα, κάνουμε κάτι μαζί και διασκορπιζόμαστε ξανά.
Σχεδιασμός και επικοινωνία
Το τελευταίο μπλοκ πρακτικών μέσω του οποίου επιλύονται προβλήματα λειτουργικού συστήματος είναι η οργάνωση της εργασίας με τις ίδιες τις εργασίες. Αυτό περιλαμβάνει επίσης την ανταλλαγή εμπειριών που είναι εκτός της εργασίας σε ζευγάρια. Ας δούμε τρεις πρακτικές:
1. Στόχοι μέσα από το δέντρο στόχων. Οργανώσαμε τη συνολική διαχείριση του έργου μέσα από ένα δέντρο που πηγαίνει ατελείωτα στο μέλλον. Τεχνικά το tracking γίνεται στο Miro. Υπάρχει ένα καθήκον - είναι ένας ενδιάμεσος στόχος. Από αυτό πηγαίνουν είτε μικρότεροι στόχοι είτε ομάδες εργασιών. Τα ίδια τα καθήκοντα προέρχονται από αυτά. Όλες οι εργασίες δημιουργούνται και διατηρούνται σε αυτόν τον πίνακα.
Αυτό το σχήμα παρέχει επίσης ανατροφοδότηση, η οποία συμβαίνει μία φορά την ημέρα όταν συγχρονιζόμαστε σε ράλι. Το να έχουμε ένα κοινό σχέδιο μπροστά σε όλους, αλλά δομημένο και απόλυτα ανοιχτό, επιτρέπει σε όλους να γνωρίζουν τι συμβαίνει και πόσο έχουμε προχωρήσει.
Πλεονεκτήματα της οπτικής όρασης των εργασιών:
- Αιτιότητα. Κάθε εργασία οδηγεί σε κάποιο παγκόσμιο στόχο. Οι εργασίες ομαδοποιούνται σε μικρότερους στόχους. Ο ίδιος ο τομέας της υποδομής είναι αρκετά τεχνικός. Δεν είναι πάντα αμέσως σαφές τι αντίκτυπο έχει στην επιχείρηση, για παράδειγμα, η σύνταξη ενός βιβλίου εκτέλεσης για τη μετάβαση σε άλλο nginx. Η ύπαρξη της κάρτας στόχου κοντά το καθιστά πιο σαφές.
Η αιτιότητα είναι μια σημαντική ιδιότητα των προβλημάτων. Απαντά άμεσα στην ερώτηση: «Κάνω το σωστό;» - Παραλληλισμός. Είμαστε εννέα από εμάς και είναι απλά σωματικά αδύνατο να ρίξουμε τους πάντες σε μία εργασία. Οι εργασίες από έναν τομέα μπορεί να μην είναι πάντα αρκετές. Είμαστε αναγκασμένοι να παραλληλίσουμε την εργασία μεταξύ μικρών ομάδων εργασίας. Ταυτόχρονα, οι ομάδες κάθονται στο καθήκον τους για κάποιο χρονικό διάστημα, μπορούν να ενισχυθούν από κάποιον άλλο. Μερικές φορές οι άνθρωποι απομακρύνονται από αυτήν την ομάδα εργασίας. Κάποιος πάει διακοπές, κάποιος κάνει μια αναφορά για το DevOps conf, κάποιος γράφει ένα άρθρο στο Habr. Είναι πολύ σημαντικό να γνωρίζουμε ποιοι στόχοι και καθήκοντα μπορούν να γίνουν παράλληλα.
2. Αντικαταστάτες παρουσιαστές πρωινών συναντήσεων. Στα stand up έχουμε αυτό το πρόβλημα - οι άνθρωποι κάνουν πολλές εργασίες παράλληλα. Μερικές φορές οι εργασίες συνδέονται χαλαρά και δεν υπάρχει κατανόηση του ποιος κάνει τι. Και η γνώμη ενός άλλου μέλους της ομάδας είναι πολύ σημαντική. Αυτές είναι πρόσθετες πληροφορίες που μπορούν να αλλάξουν την πορεία επίλυσης του προβλήματος. Φυσικά, συνήθως υπάρχει κάποιος μαζί σας, αλλά οι συμβουλές και οι συμβουλές είναι πάντα χρήσιμες.
Για να βελτιώσουμε αυτήν την κατάσταση, χρησιμοποιήσαμε την τεχνική «Αλλαγή του κορυφαίου stand-up». Τώρα εναλλάσσονται σύμφωνα με μια συγκεκριμένη λίστα, και αυτό έχει την επίδρασή του. Όταν έρθει η σειρά σας, αναγκάζεστε να βουτήξετε και να καταλάβετε τι συμβαίνει για να πραγματοποιήσετε μια καλή συνάντηση Scrum.
3. Εσωτερική επίδειξη. Η βοήθεια στην επίλυση ενός προβλήματος από τον προγραμματισμό ζευγών, η οπτικοποίηση στο δέντρο προβλημάτων και η βοήθεια σε συναντήσεις scrum το πρωί είναι καλές, αλλά όχι ιδανικές. Ως ζευγάρι, περιορίζεστε μόνο από τις γνώσεις σας. Το δέντρο εργασιών βοηθά να κατανοήσουμε συνολικά ποιος κάνει τι. Και η παρουσιάστρια και οι συνάδελφοι στην πρωινή συνάντηση δεν θα βουτήξουν βαθιά στα προβλήματά σας. Σίγουρα κάτι μπορεί να τους ξεφύγει.
Η λύση βρέθηκε στην επίδειξη της δουλειάς που έγινε ο ένας στον άλλο και στη συνέχεια στη συζήτηση. Συναντιόμαστε μία φορά την εβδομάδα για μία ώρα και δείχνουμε λεπτομέρειες για λύσεις σε εργασίες που έχουμε κάνει την περασμένη εβδομάδα.
Κατά τη διάρκεια της επίδειξης, είναι απαραίτητο να αποκαλύψετε τις λεπτομέρειες της εργασίας και να βεβαιωθείτε ότι θα επιδείξετε τη λειτουργία της.
Η αναφορά μπορεί να πραγματοποιηθεί χρησιμοποιώντας μια λίστα ελέγχου.1. Εισαγάγετε στο πλαίσιο. Από πού προήλθε το έργο, γιατί ήταν ακόμη απαραίτητο;
2. Πώς λύθηκε το πρόβλημα πριν; Για παράδειγμα, απαιτούνταν τεράστιο κλικ του ποντικιού ή ήταν αδύνατο να γίνει τίποτα απολύτως.
3. Πώς το βελτιώνουμε. Για παράδειγμα: "Κοίτα, τώρα υπάρχει το scriptosik, εδώ είναι το readme."
4. Δείξτε πώς λειτουργεί. Συνιστάται η άμεση εφαρμογή κάποιου σεναρίου χρήστη. Θέλω Χ, κάνω Υ, βλέπω Υ (ή Ω). Για παράδειγμα, αναπτύσσω το NGINX, καπνίζω το url και παίρνω 200 OK. Εάν η δράση είναι μεγάλη, προετοιμάστε την εκ των προτέρων για να μπορείτε να την εμφανίσετε αργότερα. Συνιστάται να μην το σπάσετε πολύ μία ώρα πριν από την επίδειξη, εάν είναι εύθραυστο.
5. Εξηγήστε πόσο επιτυχώς λύθηκε το πρόβλημα, ποιες δυσκολίες παραμένουν, τι δεν ολοκληρώθηκε, ποιες βελτιώσεις είναι δυνατές στο μέλλον. Για παράδειγμα, τώρα CLI, τότε θα υπάρχει πλήρης αυτοματοποίηση στο CI.
Συνιστάται για κάθε ομιλητή να το διατηρεί στα 5-10 λεπτά. Εάν η ομιλία σας είναι προφανώς σημαντική και θα διαρκέσει περισσότερο, συντονίστε την εκ των προτέρων στο κανάλι sre-takeover.
Μετά το πρόσωπο με πρόσωπο υπάρχει πάντα μια συζήτηση στο νήμα. Εδώ εμφανίζεται η ανατροφοδότηση που χρειαζόμαστε για τις εργασίες μας.
Ως αποτέλεσμα, διεξάγεται μια έρευνα για να προσδιοριστεί η χρησιμότητα αυτού που συμβαίνει. Αυτό είναι ανατροφοδότηση σχετικά με την ουσία της ομιλίας και τη σημασία της εργασίας.
Μακρά συμπεράσματα και τι ακολουθεί
Μπορεί να φαίνεται ότι ο τόνος του άρθρου είναι κάπως απαισιόδοξος. Αυτό είναι λάθος. Δύο χαμηλότερα επίπεδα ανατροφοδότησης, δηλαδή οι δοκιμές και ο προγραμματισμός ζευγών, λειτουργούν. Όχι τόσο τέλεια όσο στην παραδοσιακή ανάπτυξη, αλλά υπάρχει θετική επίδραση από αυτήν.
Οι δοκιμές, στην τρέχουσα μορφή τους, παρέχουν μόνο μερική κάλυψη κωδικού. Πολλές λειτουργίες διαμόρφωσης καταλήγουν να μην έχουν δοκιμαστεί. Η επιρροή τους στην πραγματική εργασία κατά τη σύνταξη κώδικα είναι χαμηλή. Ωστόσο, υπάρχει ένα αποτέλεσμα από τα τεστ ολοκλήρωσης και σας επιτρέπουν να πραγματοποιείτε άφοβα ανακατασκευές. Αυτό είναι ένα μεγάλο επίτευγμα. Επίσης, με τη μετατόπιση της εστίασης στην ανάπτυξη σε γλώσσες υψηλού επιπέδου (έχουμε python, go), το πρόβλημα εξαφανίζεται. Και δεν χρειάζεστε πολλούς ελέγχους για την «κόλλα», ένας γενικός έλεγχος ολοκλήρωσης αρκεί.
Η εργασία σε ζευγάρια εξαρτάται περισσότερο από συγκεκριμένα άτομα. Υπάρχει ο παράγοντας εργασίας και οι ήπιες δεξιότητές μας. Με μερικούς ανθρώπους τα πάει πολύ καλά, με άλλους χειρότερα. Σίγουρα υπάρχουν οφέλη από αυτό. Είναι σαφές ότι ακόμη και αν οι κανόνες της εργασίας σε ζευγάρια δεν τηρούνται επαρκώς, το ίδιο το γεγονός της από κοινού εκτέλεσης εργασιών έχει θετική επίδραση στην ποιότητα του αποτελέσματος. Προσωπικά, βρίσκω την εργασία σε ζευγάρια πιο εύκολη και πιο ευχάριστη.
Τρόποι υψηλότερου επιπέδου επιρροής στο λειτουργικό σύστημα - ο σχεδιασμός και η εργασία με εργασίες παράγουν με ακρίβεια αποτελέσματα: ανταλλαγή γνώσεων υψηλής ποιότητας και βελτιωμένη ποιότητα ανάπτυξης.
Σύντομα συμπεράσματα σε μια γραμμή
- Οι επαγγελματίες HR εργάζονται στο IaC, αλλά με μικρότερη αποτελεσματικότητα.
- Ενισχύστε αυτό που λειτουργεί.
- Βρείτε τους δικούς σας αντισταθμιστικούς μηχανισμούς και πρακτικές.
Πηγή: www.habr.com