Είναι γνωστό ότι η επάρκεια του ΚΟΤ δοκιμάζεται μόνο τη δεύτερη φορά που εκτελεί αυτόν τον ρόλο. Γιατί είναι ένα πράγμα να εργάζεσαι σε μια εταιρεία για πολλά χρόνια, να εξελίσσεσαι μαζί της και, όντας στο ίδιο πολιτισμικό πλαίσιο, να παίρνεις σταδιακά περισσότερες ευθύνες. Και είναι εντελώς διαφορετικό να μπαίνεις κατευθείαν στη θέση του τεχνικού διευθυντή σε μια εταιρεία με κληρονομικές αποσκευές και ένα σωρό προβλήματα που καλύπτονται τακτοποιημένα κάτω από το χαλί.
Υπό αυτή την έννοια, η εμπειρία του Leon Fire, την οποία μοιράστηκε , όχι ακριβώς μοναδικό, αλλά πολλαπλασιασμένο με την εμπειρία του και τον αριθμό των διαφορετικών ρόλων που κατάφερε να δοκιμάσει μέσα σε 20 χρόνια, είναι πολύ χρήσιμο. Κάτω από την περικοπή υπάρχει ένα χρονολόγιο γεγονότων για 90 ημέρες και πολλές ιστορίες που είναι διασκεδαστικό να γελάσουμε όταν συμβαίνουν σε κάποιον άλλο, αλλά που δεν είναι τόσο διασκεδαστικό να τις αντιμετωπίσεις από κοντά.
Ο Leon μιλάει πολύ πολύχρωμα στα ρωσικά, οπότε αν έχετε 35-40 λεπτά, σας συνιστώ να παρακολουθήσετε το βίντεο. Έκδοση κειμένου για εξοικονόμηση χρόνου παρακάτω.
Η πρώτη έκδοση της έκθεσης ήταν μια καλά δομημένη περιγραφή της εργασίας με ανθρώπους και διαδικασίες, που περιείχε χρήσιμες συστάσεις. Αλλά δεν μετέφερε όλες τις εκπλήξεις που συναντήθηκαν στην πορεία. Ως εκ τούτου, άλλαξα τη μορφή και παρουσίασα τα προβλήματα που εμφανίστηκαν μπροστά μου σαν γρύλος στη νέα εταιρεία και μεθόδους επίλυσής τους με χρονολογική σειρά.
Ένα μήνα πριν
Όπως πολλές καλές ιστορίες, έτσι και αυτή ξεκίνησε με το αλκοόλ. Καθόμασταν με φίλους σε ένα μπαρ, και όπως ήταν αναμενόμενο μεταξύ των ειδικών της πληροφορικής, όλοι έκλαιγαν για τα προβλήματά τους. Ένας από αυτούς μόλις είχε αλλάξει δουλειά και μιλούσε για τα προβλήματά του με την τεχνολογία, με τους ανθρώπους και με την ομάδα. Όσο περισσότερο άκουγα, τόσο περισσότερο συνειδητοποιούσα ότι έπρεπε απλώς να με προσλάβει, γιατί αυτά είναι τα είδη των προβλημάτων που λύνω τα τελευταία 15 χρόνια. Του είπα και την επόμενη μέρα βρεθήκαμε σε εργασιακό περιβάλλον. Η εταιρεία ονομαζόταν Teaching Strategies.
Το Teaching Strategies κατέχει ηγετική θέση στην αγορά στο πρόγραμμα σπουδών για πολύ μικρά παιδιά από τη γέννηση έως την ηλικία των τριών ετών. Η παραδοσιακή εταιρεία «χάρτου» είναι ήδη 40 ετών και η ψηφιακή έκδοση SaaS της πλατφόρμας 10. Σχετικά πρόσφατα ξεκίνησε η διαδικασία προσαρμογής της ψηφιακής τεχνολογίας στα εταιρικά πρότυπα. Η "νέα" έκδοση κυκλοφόρησε το 2017 και ήταν σχεδόν σαν την παλιά, μόνο που λειτούργησε χειρότερα.
Το πιο ενδιαφέρον είναι ότι η κίνηση αυτής της εταιρείας είναι πολύ προβλέψιμη - από μέρα σε μέρα, από έτος σε έτος, μπορείτε να προβλέψετε πολύ καθαρά πόσα άτομα θα έρθουν και πότε. Για παράδειγμα, μεταξύ 13 και 15 μ.μ., όλα τα παιδιά στα νηπιαγωγεία πάνε για ύπνο και οι δάσκαλοι αρχίζουν να εισάγουν πληροφορίες. Και αυτό συμβαίνει κάθε μέρα, εκτός από τα Σαββατοκύριακα, γιατί σχεδόν κανείς δεν δουλεύει τα Σαββατοκύριακα.
Κοιτώντας λίγο μπροστά, θα σημειώσω ότι ξεκίνησα τη δουλειά μου την περίοδο της υψηλότερης ετήσιας επισκεψιμότητας, η οποία είναι ενδιαφέρουσα για διάφορους λόγους.
Η πλατφόρμα, η οποία φαινόταν να είναι μόλις 2 ετών, είχε μια περίεργη στοίβα: ColdFusion & SQL Server από το 2008. Το ColdFusion, αν δεν το γνωρίζετε, και πιθανότατα δεν το γνωρίζετε, είναι μια εταιρική PHP που κυκλοφόρησε στα μέσα της δεκαετίας του '90 και από τότε δεν έχω καν ακούσει γι' αυτήν. Επίσης υπήρχαν: Ruby, MySQL, PostgreSQL, Java, Go, Python. Αλλά ο κύριος μονόλιθος έτρεχε σε ColdFusion και SQL Server.
Προβλήματα
Όσο περισσότερο μιλούσα με τους υπαλλήλους της εταιρείας για την εργασία και τα προβλήματα που αντιμετώπισα, τόσο περισσότερο συνειδητοποιούσα ότι τα προβλήματα δεν ήταν μόνο τεχνικού χαρακτήρα. Εντάξει, η τεχνολογία είναι παλιά - και δεν εργάστηκαν σε αυτήν, αλλά υπήρχαν προβλήματα με την ομάδα και τις διαδικασίες, και η εταιρεία άρχισε να το καταλαβαίνει αυτό.
Παραδοσιακά, οι τεχνικοί τους κάθονταν στη γωνία και έκαναν κάποιο είδος δουλειάς. Αλλά όλο και περισσότερες επιχειρήσεις άρχισαν να περνούν από την ψηφιακή έκδοση. Ως εκ τούτου, τον τελευταίο χρόνο πριν ξεκινήσω να εργάζομαι, εμφανίστηκαν νέοι στην εταιρεία: διοικητικό συμβούλιο, CTO, CPO και διευθυντής QA. Δηλαδή, η εταιρεία άρχισε να επενδύει στον τομέα της τεχνολογίας.
Τα ίχνη μιας βαριάς κληρονομιάς δεν υπήρχαν μόνο στα συστήματα. Η εταιρεία είχε διαδικασίες κληρονομιάς, ανθρώπους κληρονομιάς, κουλτούρα κληρονομιάς. Όλα αυτά έπρεπε να αλλάξουν. Σκέφτηκα ότι σίγουρα δεν θα ήταν βαρετό και αποφάσισα να το δοκιμάσω.
δύο μέρες πριν
Δύο μέρες πριν ξεκινήσω μια νέα δουλειά, έφτασα στο γραφείο, συμπλήρωσα τα τελευταία έγγραφα, συνάντησα την ομάδα και ανακάλυψα ότι η ομάδα αντιμετώπιζε ένα πρόβλημα εκείνη τη στιγμή. Ήταν ότι ο μέσος χρόνος φόρτωσης της σελίδας ανέβηκε στα 4 δευτερόλεπτα, δηλαδή 2 φορές.
Κρίνοντας από το γράφημα, κάτι συνέβη ξεκάθαρα και δεν είναι ξεκάθαρο τι. Αποδείχθηκε ότι το πρόβλημα ήταν η καθυστέρηση δικτύου στο κέντρο δεδομένων: η καθυστέρηση 5 ms στο κέντρο δεδομένων μετατράπηκε σε 2 δευτερόλεπτα για τους χρήστες. Δεν ήξερα γιατί συνέβη αυτό, αλλά σε κάθε περίπτωση έγινε γνωστό ότι το πρόβλημα ήταν στο κέντρο δεδομένων.
Η πρώτη μέρα
Πέρασαν δύο μέρες και την πρώτη μέρα δουλειάς ανακάλυψα ότι το πρόβλημα δεν είχε φύγει.
Για δύο ημέρες, οι σελίδες των χρηστών φορτώνονταν κατά μέσο όρο σε 4 δευτερόλεπτα. Ρωτάω αν βρήκαν ποιο είναι το πρόβλημα.
- Ναι, ανοίξαμε εισιτήριο.
- ΚΑΙ?
- Λοιπόν, δεν μας έχουν απαντήσει ακόμα.
Τότε συνειδητοποίησα ότι όλα όσα μου είχαν πει πριν ήταν απλώς μια μικρή κορυφή του παγόβουνου που έπρεπε να παλέψω.
Υπάρχει ένα καλό απόσπασμα που ταιριάζει πολύ σε αυτό:
«Μερικές φορές για να αλλάξεις τεχνολογία πρέπει να αλλάξεις τον οργανισμό».
Αλλά επειδή ξεκίνησα να δουλεύω την πιο πολυσύχναστη εποχή του χρόνου, έπρεπε να εξετάσω και τις δύο επιλογές για την επίλυση του προβλήματος: τόσο γρήγορη όσο και μακροπρόθεσμη. Και ξεκινήστε με αυτό που είναι κρίσιμο αυτή τη στιγμή.
Ημέρα τρία
Έτσι, η φόρτωση διαρκεί 4 δευτερόλεπτα και από τα 13 έως τα 15 οι μεγαλύτερες κορυφές.
Την τρίτη ημέρα κατά τη διάρκεια αυτής της χρονικής περιόδου, η ταχύτητα λήψης φαινόταν ως εξής:
Από την άποψή μου, τίποτα δεν λειτούργησε απολύτως. Από την άποψη όλων των άλλων έτρεχε λίγο πιο αργά από το συνηθισμένο. Αλλά απλά δεν συμβαίνει έτσι - είναι ένα σοβαρό πρόβλημα.
Προσπάθησα να πείσω την ομάδα, στην οποία απάντησαν ότι χρειάζονται απλώς περισσότερους διακομιστές. Αυτή, φυσικά, είναι μια λύση στο πρόβλημα, αλλά δεν είναι πάντα η μόνη και πιο αποτελεσματική. Ρώτησα γιατί δεν υπήρχαν αρκετοί διακομιστές, ποιος ήταν ο όγκος της κίνησης. Έκανα παρέκταση των δεδομένων και διαπίστωσα ότι έχουμε περίπου 150 αιτήματα ανά δευτερόλεπτο, τα οποία, καταρχήν, εμπίπτουν σε λογικά όρια.
Αλλά δεν πρέπει να ξεχνάμε ότι πριν λάβετε τη σωστή απάντηση, πρέπει να κάνετε τη σωστή ερώτηση. Η επόμενη ερώτησή μου ήταν: πόσους διακομιστές frontend έχουμε; Η απάντηση "με μπέρδεψε λίγο" - είχαμε 17 διακομιστές frontend!
— Ντρέπομαι να ρωτήσω, αλλά το 150 διαιρούμενο με το 17 δίνει περίπου 8; Λέτε ότι κάθε διακομιστής επιτρέπει 8 αιτήματα ανά δευτερόλεπτο, και αν αύριο υπάρξουν 160 αιτήσεις ανά δευτερόλεπτο, θα χρειαστούμε άλλους 2 διακομιστές;
Φυσικά, δεν χρειαζόμασταν επιπλέον διακομιστές. Η λύση ήταν στον ίδιο τον κώδικα και στην επιφάνεια:
var currentClass = classes.getCurrentClass();
return currentClass;
Υπήρχε μια λειτουργία getCurrentClass(), επειδή όλα στον ιστότοπο λειτουργούν στο πλαίσιο μιας τάξης - αυτό είναι σωστό. Και για αυτή τη μία λειτουργία σε κάθε σελίδα υπήρχαν 200+ αιτήματα.
Η λύση με αυτόν τον τρόπο ήταν πολύ απλή, δεν χρειαζόταν καν να ξαναγράψετε τίποτα: απλώς μην ζητήσετε ξανά τις ίδιες πληροφορίες.
if ( !isDefined("REQUEST.currentClass") ) {
var classes = new api.private.classes.base();
REQUEST.currentClass = classes.getCurrentClass();
}
return REQUEST.currentClass;Ήμουν πολύ χαρούμενος γιατί αποφάσισα ότι μόλις την τρίτη μέρα είχα βρει το κύριο πρόβλημα. Όσο αφελής ήμουν, αυτό ήταν μόνο ένα από τα πολλά προβλήματα.
Αλλά η επίλυση αυτού του πρώτου προβλήματος έπεσε το γράφημα πολύ χαμηλότερα.
Ταυτόχρονα, κάναμε άλλες βελτιστοποιήσεις. Υπήρχαν πολλά πράγματα στον ορίζοντα που μπορούσαν να διορθωθούν. Για παράδειγμα, την ίδια τρίτη μέρα ανακάλυψα ότι τελικά υπήρχε μια κρυφή μνήμη στο σύστημα (στην αρχή νόμιζα ότι όλα τα αιτήματα προέρχονταν απευθείας από τη βάση δεδομένων). Όταν σκέφτομαι μια κρυφή μνήμη, σκέφτομαι το τυπικό Redis ή το Memcached. Αλλά ήμουν ο μόνος που το σκέφτηκα, γιατί αυτό το σύστημα χρησιμοποιούσε MongoDB και SQL Server για προσωρινή αποθήκευση - το ίδιο από το οποίο μόλις διαβάστηκαν τα δεδομένα.
Δέκατη μέρα
Την πρώτη εβδομάδα αντιμετώπισα προβλήματα που έπρεπε να λυθούν αυτή τη στιγμή. Κάπου στη δεύτερη εβδομάδα ήρθα για πρώτη φορά στο stand-up για να επικοινωνήσω με την ομάδα, να δω τι γίνεται και πώς πάει η όλη διαδικασία.
Κάτι ενδιαφέρον ανακαλύφθηκε ξανά. Η ομάδα αποτελούνταν από: 18 προγραμματιστές; 8 δοκιμαστές? 3 διευθυντές? 2 αρχιτέκτονες. Και συμμετείχαν όλοι σε κοινές τελετουργίες, δηλαδή πάνω από 30 άτομα έρχονταν κάθε πρωί στο stand-up και έλεγαν τι έκαναν. Είναι σαφές ότι η συνάντηση δεν κράτησε 5 ή 15 λεπτά. Κανείς δεν άκουσε κανέναν γιατί όλοι δουλεύουν σε διαφορετικά συστήματα. Σε αυτή τη μορφή, 2-3 εισιτήρια την ώρα για μια συνεδρία περιποίησης ήταν ήδη ένα καλό αποτέλεσμα.
Το πρώτο πράγμα που κάναμε ήταν να χωρίσουμε την ομάδα σε πολλές σειρές προϊόντων. Για διαφορετικές ενότητες και συστήματα, διαθέσαμε ξεχωριστές ομάδες, οι οποίες περιλάμβαναν προγραμματιστές, δοκιμαστές, διαχειριστές προϊόντων και επιχειρηματικούς αναλυτές.
Ως αποτέλεσμα πήραμε:
- Μείωση των stand-up και των ράλι.
- Αντικειμενική γνώση του προϊόντος.
- Αίσθημα ιδιοκτησίας. Όταν οι άνθρωποι συνήθιζαν να ασχολούνται συνεχώς με τα συστήματα, ήξεραν ότι πιθανότατα κάποιος άλλος θα έπρεπε να δουλέψει με τα σφάλματα τους, αλλά όχι οι ίδιοι.
- Συνεργασία μεταξύ ομάδων. Περιττό να πούμε ότι το QA δεν επικοινωνούσε πολύ με τους προγραμματιστές στο παρελθόν, το προϊόν έκανε το δικό του κ.λπ. Τώρα έχουν κοινό σημείο ευθύνης.
Εστιάσαμε κυρίως στην αποτελεσματικότητα, την παραγωγικότητα και την ποιότητα - αυτά είναι τα προβλήματα που προσπαθήσαμε να λύσουμε με τη μεταμόρφωση της ομάδας.
Ημέρα ενδέκατη
Στη διαδικασία αλλαγής της δομής της ομάδας, ανακάλυψα πώς να μετρώ Ιστορίασημεία. 1 SP ήταν ίσο με μία ημέρα και κάθε εισιτήριο περιείχε SP τόσο για ανάπτυξη όσο και για QA, δηλαδή τουλάχιστον 2 SP.
Πώς το ανακάλυψα αυτό;
Βρήκαμε ένα σφάλμα: σε μία από τις αναφορές, όπου καταχωρείται η ημερομηνία έναρξης και λήξης της περιόδου για την οποία απαιτείται η αναφορά, δεν λαμβάνεται υπόψη η τελευταία ημέρα. Δηλαδή κάπου στο αίτημα δεν υπήρχε <=, αλλά απλά <. Μου είπαν ότι πρόκειται για τρία Story Points, δηλαδή 3 ημέρες.
Μετά από αυτό εμείς:
- Το σύστημα αξιολόγησης Story Points έχει αναθεωρηθεί. Τώρα οι διορθώσεις για μικρά σφάλματα που μπορούν να περάσουν γρήγορα μέσω του συστήματος φτάνουν στον χρήστη πιο γρήγορα.
- Αρχίσαμε να συγχωνεύουμε σχετικά εισιτήρια για ανάπτυξη και δοκιμή. Προηγουμένως, κάθε εισιτήριο, κάθε σφάλμα ήταν ένα κλειστό οικοσύστημα, που δεν ήταν συνδεδεμένο με τίποτα άλλο. Η αλλαγή τριών κουμπιών σε μια σελίδα θα μπορούσε να ήταν τρία διαφορετικά εισιτήρια με τρεις διαφορετικές διαδικασίες QA αντί για ένα αυτοματοποιημένο τεστ ανά σελίδα.
- Αρχίσαμε να συνεργαζόμαστε με προγραμματιστές για μια προσέγγιση εκτίμησης του κόστους εργασίας. Τρεις ημέρες για να αλλάξετε ένα κουμπί δεν είναι αστείο.
Ημέρα εικοστή
Κάπου στα μέσα του πρώτου μήνα, η κατάσταση σταθεροποιήθηκε λίγο, κατάλαβα τι συνέβαινε βασικά και άρχισα ήδη να κοιτάζω το μέλλον και να σκέφτομαι μακροπρόθεσμες λύσεις.
Μακροπρόθεσμοι στόχοι:
- Διαχειριζόμενη πλατφόρμα. Εκατοντάδες αιτήματα σε κάθε σελίδα δεν είναι σοβαρά.
- Προβλέψιμες τάσεις. Υπήρχαν περιοδικές αιχμές κυκλοφορίας που με την πρώτη ματιά δεν συσχετίστηκαν με άλλες μετρήσεις - έπρεπε να καταλάβουμε γιατί συνέβη αυτό και να μάθουμε να προβλέπουμε.
- Επέκταση πλατφόρμας. Η επιχείρηση αναπτύσσεται συνεχώς, όλο και περισσότεροι χρήστες έρχονται και η επισκεψιμότητα αυξάνεται.
Στο παρελθόν έλεγαν συχνά: "Ας τα ξαναγράψουμε όλα σε [γλώσσα/πλαίσιο], όλα θα λειτουργήσουν καλύτερα!"
Στις περισσότερες περιπτώσεις αυτό δεν λειτουργεί, είναι καλό αν η επανεγγραφή λειτουργεί καθόλου. Ως εκ τούτου, χρειαζόταν να δημιουργήσουμε έναν οδικό χάρτη - μια συγκεκριμένη στρατηγική που δείχνει βήμα προς βήμα πώς θα επιτευχθούν οι επιχειρηματικοί στόχοι (τι θα κάνουμε και γιατί), ο οποίος:
- αντικατοπτρίζει την αποστολή και τους στόχους του έργου·
- ιεραρχεί τους κύριους στόχους·
- περιέχει ένα χρονοδιάγραμμα για την επίτευξή τους.
Πριν από αυτό, κανείς δεν είχε μιλήσει με την ομάδα για τον σκοπό των αλλαγών που έγιναν. Αυτό απαιτεί τις σωστές μετρήσεις επιτυχίας. Για πρώτη φορά στην ιστορία της εταιρείας, ορίσαμε KPI για την τεχνική ομάδα και αυτοί οι δείκτες συνδέθηκαν με οργανωτικούς.
Δηλαδή, τα οργανωτικά KPI υποστηρίζονται από ομάδες και τα ομαδικά KPI υποστηρίζονται από μεμονωμένα KPI. Διαφορετικά, αν οι τεχνολογικοί KPI δεν συμπίπτουν με τους οργανωτικούς, τότε ο καθένας τραβάει την κουβέρτα πάνω του.
Για παράδειγμα, ένας από τους οργανωτικούς δείκτες KPI αυξάνει το μερίδιο αγοράς μέσω νέων προϊόντων.
Πώς μπορείτε να υποστηρίξετε τον στόχο να έχετε περισσότερα νέα προϊόντα;
- Πρώτον, θέλουμε να αφιερώσουμε περισσότερο χρόνο στην ανάπτυξη νέων προϊόντων αντί να επιδιορθώνουμε ελαττώματα. Αυτή είναι μια λογική λύση που είναι εύκολο να μετρηθεί.
- Δεύτερον, θέλουμε να υποστηρίξουμε την αύξηση του όγκου συναλλαγών, διότι όσο μεγαλύτερο είναι το μερίδιο αγοράς, τόσο περισσότεροι χρήστες και, κατά συνέπεια, περισσότερη επισκεψιμότητα.
Στη συνέχεια, τα μεμονωμένα KPI που μπορούν να εκτελεστούν εντός της ομάδας θα βρίσκονται, για παράδειγμα, στο μέρος από το οποίο προέρχονται τα κύρια ελαττώματα. Εάν εστιάσετε ειδικά σε αυτήν την ενότητα, μπορείτε να βεβαιωθείτε ότι υπάρχουν πολύ λιγότερα ελαττώματα και, στη συνέχεια, ο χρόνος για την ανάπτυξη νέων προϊόντων και ξανά για την υποστήριξη οργανωτικών KPI θα αυξηθεί.
Έτσι, κάθε απόφαση, συμπεριλαμβανομένης της επανεγγραφής κώδικα, πρέπει να υποστηρίζει τους συγκεκριμένους στόχους που έχει θέσει η εταιρεία για εμάς (οργανωτική ανάπτυξη, νέα χαρακτηριστικά, προσλήψεις).
Κατά τη διάρκεια αυτής της διαδικασίας, ένα ενδιαφέρον πράγμα ήρθε στο φως, το οποίο έγινε είδηση όχι μόνο για τους τεχνικούς, αλλά γενικά στην εταιρεία: όλα τα εισιτήρια πρέπει να επικεντρώνονται σε τουλάχιστον έναν KPI. Δηλαδή, εάν ένα προϊόν λέει ότι θέλει να δημιουργήσει μια νέα δυνατότητα, θα πρέπει να τεθεί η πρώτη ερώτηση: "Τι KPI υποστηρίζει αυτή η δυνατότητα;" Εάν όχι, τότε συγγνώμη - φαίνεται σαν ένα περιττό χαρακτηριστικό.
Ημέρα τριάντα
Στο τέλος του μήνα, ανακάλυψα μια άλλη απόχρωση: κανείς στην ομάδα Ops μου δεν έχει δει ποτέ τις συμβάσεις που συνάπτουμε με πελάτες. Μπορεί να ρωτήσετε γιατί πρέπει να δείτε τις επαφές.
- Πρώτον, επειδή τα SLA καθορίζονται στα συμβόλαια.
- Δεύτερον, τα SLA είναι όλα διαφορετικά. Κάθε πελάτης ήρθε με τις δικές του απαιτήσεις και το τμήμα πωλήσεων υπέγραψε χωρίς να κοιτάξει.
Μια άλλη ενδιαφέρουσα απόχρωση είναι ότι η σύμβαση με έναν από τους μεγαλύτερους πελάτες αναφέρει ότι όλες οι εκδόσεις λογισμικού που υποστηρίζονται από την πλατφόρμα πρέπει να είναι n-1, δηλαδή όχι η τελευταία έκδοση, αλλά η προτελευταία.
Είναι σαφές πόσο μακριά ήμασταν από το n-1 εάν η πλατφόρμα βασιζόταν στον ColdFusion και τον SQL Server 2008, ο οποίος δεν υποστηριζόταν πλέον καθόλου τον Ιούλιο.
Ημέρα σαράντα πέντε
Γύρω στα μέσα του δεύτερου μήνα είχα αρκετό χρόνο να καθίσω και να κάνω αξίαμετάδοσηχαρτης πλήρως για όλη τη διαδικασία. Αυτά είναι τα απαραίτητα βήματα που πρέπει να γίνουν, από τη δημιουργία ενός προϊόντος έως την παράδοση του στον καταναλωτή, και πρέπει να περιγραφούν όσο το δυνατόν λεπτομερέστερα.
Σπάτε τη διαδικασία σε μικρά κομμάτια και βλέπετε τι απαιτεί πολύ χρόνο, τι μπορεί να βελτιστοποιηθεί, να βελτιωθεί κ.λπ. Για παράδειγμα, πόσος χρόνος χρειάζεται για να υποβληθεί σε επεξεργασία ένα αίτημα προϊόντος, πότε φτάνει σε ένα εισιτήριο που μπορεί να πάρει ένας προγραμματιστής, QA κ.λπ. Επομένως, εξετάζετε κάθε μεμονωμένο βήμα λεπτομερώς και σκέφτεστε τι μπορεί να βελτιστοποιηθεί.
Όταν το έκανα αυτό, δύο πράγματα τράβηξαν την προσοχή μου:
- υψηλό ποσοστό εισιτηρίων που επιστράφηκαν από QA πίσω στους προγραμματιστές.
- Οι έλεγχοι των αιτημάτων έλξης διήρκεσαν πάρα πολύ.
Το πρόβλημα ήταν ότι αυτά ήταν συμπεράσματα όπως: Φαίνεται να παίρνει πολύ χρόνο, αλλά δεν είμαστε σίγουροι πόσο καιρό.
«Δεν μπορείς να βελτιώσεις αυτό που δεν μπορείς να μετρήσεις».
Πώς να δικαιολογήσετε πόσο σοβαρό είναι το πρόβλημα; Χάνει μέρες ή ώρες;
Για να το μετρήσουμε αυτό, προσθέσαμε μερικά βήματα στη διαδικασία Jira: "έτοιμο για dev" και "έτοιμο για QA" για να μετρήσουμε πόσο χρόνο περιμένει κάθε εισιτήριο και πόσες φορές επιστρέφει σε ένα συγκεκριμένο βήμα.
Προσθέσαμε επίσης το "σε ανασκόπηση" για να γνωρίζουμε πόσα εισιτήρια είναι κατά μέσο όρο για έλεγχο και από αυτό μπορείτε να ξεκινήσετε να χορεύετε. Είχαμε μετρήσεις συστήματος, τώρα προσθέσαμε νέες μετρήσεις και αρχίσαμε να μετράμε:
- Αποτελεσματικότητα διαδικασίας: απόδοση και προγραμματισμένη/παραδοθείσα.
- Ποιότητα διαδικασίας: αριθμός ελαττωμάτων, ελαττώματα από QA.
Βοηθά πραγματικά να καταλάβουμε τι πάει καλά και τι δεν πάει καλά.
Ημέρα πεντηκοστή
Όλα αυτά, φυσικά, είναι καλά και ενδιαφέροντα, αλλά προς το τέλος του δεύτερου μήνα συνέβη κάτι που, καταρχήν, ήταν προβλέψιμο, αν και δεν περίμενα τέτοια κλίμακα. Οι άνθρωποι άρχισαν να φεύγουν επειδή η ανώτατη διοίκηση είχε αλλάξει. Νέοι άνθρωποι ήρθαν στη διοίκηση και άρχισαν να αλλάζουν τα πάντα, και οι παλιοί τα παράτησαν. Και συνήθως σε μια παρέα πολλών ετών, όλοι είναι φίλοι και όλοι γνωρίζονται μεταξύ τους.
Αυτό ήταν αναμενόμενο, αλλά η κλίμακα των απολύσεων ήταν απροσδόκητη. Για παράδειγμα, σε μια εβδομάδα δύο επικεφαλής ομάδων υπέβαλαν ταυτόχρονα την παραίτησή τους με τη θέλησή τους. Ως εκ τούτου, έπρεπε όχι μόνο να ξεχάσω άλλα προβλήματα, αλλά να εστιάσω σε αυτά δημιουργώντας μια ομάδα. Αυτό είναι ένα μακρύ και δύσκολο πρόβλημα προς επίλυση, αλλά έπρεπε να αντιμετωπιστεί γιατί ήθελα να σώσω τους ανθρώπους που είχαν απομείνει (ή τους περισσότερους από αυτούς). Ήταν απαραίτητο να αντιδράσουμε με κάποιο τρόπο στο γεγονός ότι ο κόσμος έφυγε για να διατηρήσει το ηθικό στην ομάδα.
Θεωρητικά, αυτό είναι καλό: έρχεται ένα νέο άτομο που έχει πλήρη λευκή κάρτα, που μπορεί να αξιολογήσει τις δεξιότητες της ομάδας και να αντικαταστήσει το προσωπικό. Στην πραγματικότητα, δεν μπορείτε απλώς να φέρετε νέα άτομα για τόσους πολλούς λόγους. Πάντα χρειάζεται ισορροπία.
- Παλιό και νέο. Πρέπει να κρατήσουμε ηλικιωμένους που μπορούν να αλλάξουν και να υποστηρίξουν την αποστολή. Αλλά ταυτόχρονα, πρέπει να φέρουμε νέο αίμα, θα μιλήσουμε για αυτό λίγο αργότερα.
- Εμπειρία. Μίλησα πολύ με καλούς νεαρούς που ήταν πρόθυμοι και ήθελαν να δουλέψουν μαζί μας. Αλλά δεν μπορούσα να τους αναλάβω γιατί δεν υπήρχαν αρκετοί ηλικιωμένοι για να υποστηρίξουν τους junior και να λειτουργήσουν ως μέντορες για αυτούς. Χρειάστηκε να στρατολογηθεί πρώτα η κορυφή και μόνο μετά η νεολαία.
- Καρότο και ξυλάκι.
Δεν έχω καλή απάντηση στο ερώτημα ποια είναι η σωστή ισορροπία, πώς να τη διατηρήσετε, πόσα άτομα να κρατήσετε και πόσο να πιέσετε. Αυτή είναι μια καθαρά ατομική διαδικασία.
Ημέρα πενήντα μία
Άρχισα να κοιτάζω προσεκτικά την ομάδα για να καταλάβω ποιον είχα, και για άλλη μια φορά θυμήθηκα:
«Τα περισσότερα προβλήματα είναι προβλήματα ανθρώπων».
Διαπίστωσα ότι η ομάδα αυτή καθαυτή - τόσο η Dev όσο και η Ops - έχει τρία μεγάλα προβλήματα:
- Ικανοποίηση από την τρέχουσα κατάσταση.
- Έλλειψη ευθύνης - γιατί κανείς δεν έφερε ποτέ τα αποτελέσματα της δουλειάς των καλλιτεχνών για να επηρεάσει την επιχείρηση.
- Ο φόβος της αλλαγής.
Η αλλαγή σας βγάζει πάντα από τη ζώνη άνεσής σας, και όσο πιο νέοι είναι οι άνθρωποι, τόσο περισσότερο αντιπαθούν την αλλαγή επειδή δεν καταλαβαίνουν γιατί και δεν καταλαβαίνουν πώς. Η πιο συνηθισμένη απάντηση που έχω ακούσει είναι: «Δεν το έχουμε κάνει ποτέ αυτό». Επιπλέον, έφτασε στο σημείο του πλήρους παραλογισμού - οι παραμικρές αλλαγές δεν μπορούσαν να γίνουν χωρίς να αγανακτήσει κάποιος. Και όσο κι αν οι αλλαγές επηρέασαν τη δουλειά τους, ο κόσμος είπε: «Όχι, γιατί; Αυτό δεν θα λειτουργήσει».
Αλλά δεν μπορείς να γίνεις καλύτερος χωρίς να αλλάξεις τίποτα.
Είχα μια απολύτως παράλογη συζήτηση με έναν υπάλληλο, του είπα τις ιδέες μου για βελτιστοποίηση, στην οποία μου είπε:
- Α, δεν είδες τι είχαμε πέρυσι!
- Και λοιπόν?
«Τώρα είναι πολύ καλύτερα από ό,τι ήταν».
- Λοιπόν, δεν μπορεί να γίνει καλύτερο;
- Για ποιο λόγο?
Καλή ερώτηση - γιατί; Είναι σαν να είναι καλύτερα τώρα από ό,τι ήταν, τότε όλα είναι αρκετά καλά. Αυτό οδηγεί σε έλλειψη ευθύνης, κάτι που είναι απολύτως φυσιολογικό καταρχήν. Όπως είπα, το τεχνικό γκρουπ ήταν λίγο στο περιθώριο. Η εταιρεία πίστευε ότι έπρεπε να υπάρχουν, αλλά κανείς δεν έθεσε ποτέ τα πρότυπα. Η τεχνική υποστήριξη δεν είδε ποτέ το SLA, επομένως ήταν αρκετά "αποδεκτό" για την ομάδα (και αυτό με εντυπωσίασε περισσότερο):
- 12 δευτερόλεπτα φόρτωση.
- 5-10 λεπτά διακοπής λειτουργίας κάθε κυκλοφορίας.
- Η αντιμετώπιση κρίσιμων προβλημάτων διαρκεί μέρες και εβδομάδες.
- έλλειψη προσωπικού υπηρεσίας 24x7 / εφημερία.
Κανείς δεν προσπάθησε ποτέ να ρωτήσει γιατί δεν το κάνουμε καλύτερα, και κανείς δεν έχει συνειδητοποιήσει ποτέ ότι δεν χρειάζεται να είναι έτσι.
Ως μπόνους, υπήρχε ένα ακόμη πρόβλημα: έλλειψη εμπειρίας. Οι ηλικιωμένοι έφυγαν και η εναπομείνασα νεαρή ομάδα μεγάλωσε κάτω από το προηγούμενο καθεστώς και δηλητηριάστηκε από αυτό.
Πάνω από όλα αυτά, ο κόσμος φοβόταν επίσης μήπως αποτύχει και φανεί ανίκανος. Αυτό εκφράζεται στο γεγονός ότι, πρώτον, αυτοί σε καμία περίπτωση δεν ζήτησε βοήθεια. Πόσες φορές έχουμε μιλήσει ως ομάδα και μεμονωμένα, και έχω πει: «Κάντε μια ερώτηση αν δεν ξέρετε πώς να κάνετε κάτι». Είμαι σίγουρος για τον εαυτό μου και ξέρω ότι μπορώ να λύσω οποιοδήποτε πρόβλημα, αλλά θα πάρει χρόνο. Επομένως, αν μπορώ να ρωτήσω κάποιον που ξέρει πώς να το λύσει σε 10 λεπτά, θα ρωτήσω. Όσο λιγότερη εμπειρία έχεις, τόσο περισσότερο φοβάσαι να ρωτήσεις γιατί πιστεύεις ότι θα θεωρηθείς ανίκανος.
Αυτός ο φόβος να κάνεις ερωτήσεις εκδηλώνεται με ενδιαφέροντες τρόπους. Για παράδειγμα, ρωτάτε: "Πώς τα πάτε με αυτήν την εργασία;" - «Μερικές ώρες έμειναν, τελειώνω ήδη». Την επόμενη μέρα που ξαναρωτάς, παίρνεις την απάντηση ότι όλα είναι καλά, αλλά υπήρχε ένα πρόβλημα, σίγουρα θα είναι έτοιμο μέχρι το τέλος της ημέρας. Περνά μια άλλη μέρα, και μέχρι να σε κολλήσουν στον τοίχο και να σε αναγκάσουν να μιλήσεις σε κάποιον, αυτό συνεχίζεται. Ένα άτομο θέλει να λύσει ένα πρόβλημα μόνος του· πιστεύει ότι αν δεν το λύσει μόνος του, θα είναι μεγάλη αποτυχία.
Γι 'αυτό οι προγραμματιστές διόγκωσαν τις εκτιμήσεις. Ήταν το ίδιο ανέκδοτο, όταν συζητούσαν για ένα συγκεκριμένο έργο, μου έδωσαν τέτοια φιγούρα που εξεπλάγην πολύ. Στο οποίο μου είπαν ότι στις εκτιμήσεις του προγραμματιστή, ο προγραμματιστής περιλαμβάνει τον χρόνο που θα επιστραφεί το εισιτήριο από την QA, επειδή θα βρουν σφάλματα εκεί, και τον χρόνο που θα πάρει το PR και τον χρόνο που θα πρέπει να ελέγξουν θα είναι απασχολημένος - δηλαδή τα πάντα, ό,τι είναι δυνατό.
Δεύτερον, άνθρωποι που φοβούνται μήπως φανούν ανίκανοι υπεραναλύουν. Όταν λέτε τι ακριβώς πρέπει να γίνει, αρχίζει: "Όχι, τι θα γίνει αν το σκεφτούμε εδώ;" Υπό αυτή την έννοια, η εταιρεία μας δεν είναι μοναδική· αυτό είναι ένα τυπικό πρόβλημα για τους νέους.
Σε απάντηση, εισήγαγα τις ακόλουθες πρακτικές:
- Κανόνας 30 λεπτά. Εάν δεν μπορείτε να λύσετε το πρόβλημα σε μισή ώρα, ζητήστε από κάποιον να σας βοηθήσει. Αυτό λειτουργεί με διάφορους βαθμούς επιτυχίας, επειδή οι άνθρωποι εξακολουθούν να μην ρωτούν, αλλά τουλάχιστον η διαδικασία έχει ξεκινήσει.
- Καταργήστε τα πάντα εκτός από την ουσία, κατά την εκτίμηση της προθεσμίας για την ολοκλήρωση μιας εργασίας, δηλαδή, σκεφτείτε μόνο πόσο χρόνο θα χρειαστεί για να γράψετε τον κώδικα.
- Συνεχής μάθηση για όσους υπεραναλύουν. Είναι απλώς συνεχής δουλειά με ανθρώπους.
Ημέρα εξηκοστή
Ενώ τα έκανα όλα αυτά, ήρθε η ώρα να καταλάβω τον προϋπολογισμό. Φυσικά, βρήκα πολλά ενδιαφέροντα πράγματα εκεί που ξοδέψαμε τα χρήματά μας. Για παράδειγμα, είχαμε ένα ολόκληρο rack σε ένα ξεχωριστό κέντρο δεδομένων με έναν διακομιστή FTP, ο οποίος χρησιμοποιήθηκε από έναν πελάτη. Αποδείχθηκε ότι «... μετακομίσαμε, αλλά έμεινε έτσι, δεν τον αλλάξαμε». Ήταν πριν 2 χρόνια.
Ιδιαίτερο ενδιαφέρον είχε ο λογαριασμός για τις υπηρεσίες cloud. Πιστεύω ότι ο κύριος λόγος για τον υψηλό λογαριασμό cloud είναι οι προγραμματιστές που έχουν απεριόριστη πρόσβαση σε διακομιστές για πρώτη φορά στη ζωή τους. Δεν χρειάζεται να ρωτήσουν: «Παρακαλώ δώστε μου έναν δοκιμαστικό διακομιστή», μπορούν να τον πάρουν μόνοι τους. Επιπλέον, οι προγραμματιστές θέλουν πάντα να χτίζουν ένα τόσο ωραίο σύστημα που το Facebook και το Netflix θα ζηλεύουν.
Αλλά οι προγραμματιστές δεν έχουν εμπειρία στην αγορά διακομιστών και την ικανότητα να προσδιορίζουν το απαιτούμενο μέγεθος διακομιστών, επειδή δεν το χρειάζονταν πριν. Και συνήθως δεν καταλαβαίνουν ακριβώς τη διαφορά μεταξύ επεκτασιμότητας και απόδοσης.
Αποτελέσματα αποθέματος:
- Αφήσαμε το ίδιο κέντρο δεδομένων.
- Καταγγείλαμε τη σύμβαση με 3 υπηρεσίες καταγραφής. Επειδή είχαμε 5 από αυτά - κάθε προγραμματιστής που άρχισε να παίζει με κάτι έπαιρνε ένα νέο.
- 7 συστήματα AWS τερματίστηκαν. Και πάλι, κανείς δεν σταμάτησε τα νεκρά έργα· όλα συνέχισαν να εργάζονται.
- Μειώθηκε το κόστος λογισμικού κατά 6 φορές.
Ημέρα εβδομήντα πέντε
Ο καιρός πέρασε και σε δυόμισι μήνες έπρεπε να συναντηθώ με το διοικητικό συμβούλιο. Το διοικητικό μας συμβούλιο δεν είναι καλύτερο ή χειρότερο από άλλα· όπως όλα τα διοικητικά συμβούλια, θέλει να ξέρει τα πάντα. Οι άνθρωποι επενδύουν χρήματα και θέλουν να καταλάβουν πόσο αυτό που κάνουμε ταιριάζει στα καθορισμένα KPI.
Το διοικητικό συμβούλιο λαμβάνει πολλές πληροφορίες κάθε μήνα: τον αριθμό των χρηστών, την ανάπτυξή τους, ποιες υπηρεσίες χρησιμοποιούν και πώς, απόδοση και παραγωγικότητα και τέλος, μέση ταχύτητα φόρτωσης σελίδας.
Το μόνο πρόβλημα είναι ότι πιστεύω ότι ο μέσος όρος είναι σκέτο κακό. Αλλά είναι πολύ δύσκολο να εξηγηθεί αυτό στο διοικητικό συμβούλιο. Συνηθίζουν να λειτουργούν με συγκεντρωτικούς αριθμούς και όχι, για παράδειγμα, με την εξάπλωση των χρόνων φόρτωσης ανά δευτερόλεπτο.
Υπήρχαν μερικά ενδιαφέροντα σημεία σε αυτό το θέμα. Για παράδειγμα, είπα ότι πρέπει να μοιράσουμε την κυκλοφορία μεταξύ ξεχωριστών διακομιστών ιστού ανάλογα με τον τύπο του περιεχομένου.
Δηλαδή, το ColdFusion περνάει από το Jetty και το nginx και εκκινεί τις σελίδες. Και οι εικόνες, το JS και το CSS περνούν από ένα ξεχωριστό nginx με τις δικές τους διαμορφώσεις. Αυτή είναι μια αρκετά τυπική πρακτική για την οποία μιλάω λίγα χρόνια πριν. Ως αποτέλεσμα, οι φωτογραφίες φορτώνουν πολύ πιο γρήγορα και... η μέση ταχύτητα φόρτωσης έχει αυξηθεί κατά 200 ms.
Αυτό συνέβη επειδή το γράφημα έχει δημιουργηθεί με βάση τα δεδομένα που συνοδεύουν το Jetty. Δηλαδή, το γρήγορο περιεχόμενο δεν περιλαμβάνεται στον υπολογισμό - η μέση τιμή έχει πηδήξει. Αυτό ήταν ξεκάθαρο σε εμάς, γελάσαμε, αλλά πώς μπορούμε να εξηγήσουμε στο διοικητικό συμβούλιο γιατί κάναμε κάτι και τα πράγματα χειροτέρεψαν κατά 12%;
Ημέρα ογδόντα πέντε
Στο τέλος του τρίτου μήνα, συνειδητοποίησα ότι υπήρχε ένα πράγμα στο οποίο δεν είχα υπολογίσει καθόλου: τον χρόνο. Όλα όσα μίλησα χρειάζονται χρόνο.
Αυτό είναι το πραγματικό μου εβδομαδιαίο ημερολόγιο - απλώς μια εβδομάδα εργασίας, όχι πολύ απασχολημένη. Δεν υπάρχει αρκετός χρόνος για όλα. Επομένως, και πάλι, πρέπει να στρατολογήσετε άτομα που θα σας βοηθήσουν να αντιμετωπίσετε τα προβλήματα.
Συμπέρασμα
Δεν είναι μόνο αυτό. Σε αυτήν την ιστορία, δεν έχω καταλάβει καν πώς δουλέψαμε με το προϊόν και προσπαθήσαμε να συντονιστούμε με το γενικό κύμα, ή πώς ενσωματώσαμε την τεχνική υποστήριξη ή πώς λύσαμε άλλα τεχνικά προβλήματα. Για παράδειγμα, έμαθα εντελώς τυχαία ότι στους μεγαλύτερους πίνακες της βάσης δεδομένων δεν χρησιμοποιούμε SEQUENCE. Έχουμε μια αυτογραμμένη λειτουργία nextID, και δεν χρησιμοποιείται σε συναλλαγή.
Υπήρχαν ένα εκατομμύριο άλλα παρόμοια πράγματα για τα οποία θα μπορούσαμε να μιλήσουμε για πολύ καιρό. Αλλά το πιο σημαντικό πράγμα που πρέπει να ειπωθεί είναι ο πολιτισμός.
Είναι ο πολιτισμός ή η έλλειψή του που οδηγεί σε όλα τα άλλα προβλήματα. Προσπαθούμε να οικοδομήσουμε μια κουλτούρα όπου οι άνθρωποι:
- δεν φοβούνται τις αποτυχίες.
- Να μάθουν από τα λάθη.
- συνεργάζεται με άλλες ομάδες·
- παίρνω πρωτοβουλία;
- παίρνω την ευθύνη;
- καλωσορίζω το αποτέλεσμα ως στόχο.
- γιορτάζοντας την επιτυχία.
Με αυτό θα έρθουν όλα τα άλλα.
Leon Fire , και .
Υπάρχουν δύο στρατηγικές σχετικά με την κληρονομιά: αποφύγετε να εργαστείτε με αυτό πάση θυσία ή ξεπεράστε γενναία τις σχετικές δυσκολίες. Εμείς γ Παίρνουμε τον δεύτερο δρόμο, αλλάζοντας διαδικασίες και προσεγγίσεις. Ελάτε μαζί μας , и , και μαζί θα εφαρμόσουμε μια κουλτούρα DevOps.
Πηγή: www.habr.com