Το ερώτημα "πώς να εφαρμόσετε το devops" υπάρχει εδώ και χρόνια, αλλά δεν υπάρχουν πολλά καλά υλικά. Μερικές φορές πέφτετε θύμα διαφημίσεων από όχι και τόσο έξυπνους συμβούλους που πρέπει να πουλήσουν τον χρόνο τους, ανεξάρτητα από το πώς. Μερικές φορές αυτές είναι ασαφείς, εξαιρετικά γενικές λέξεις για το πώς τα πλοία των μεγαλοεταιρειών οργώνουν τις εκτάσεις του σύμπαντος. Τίθεται το ερώτημα: τι σημασία έχει αυτό για εμάς; Αγαπητέ συγγραφέα, μπορείτε να διατυπώσετε με σαφήνεια τις ιδέες σας σε μια λίστα;
Όλα αυτά πηγάζουν από το γεγονός ότι δεν έχει συσσωρευτεί πολύ πραγματική πρακτική και κατανόηση του αποτελέσματος των μετασχηματισμών της κουλτούρας της εταιρείας. Οι αλλαγές στην κουλτούρα είναι μακροπρόθεσμα πράγματα, τα αποτελέσματα των οποίων δεν θα φανούν σε μια εβδομάδα ή ένα μήνα. Χρειαζόμαστε κάποιον αρκετά μεγάλο για να έχει δει πώς έχουν δημιουργηθεί και αποτύχει οι εταιρείες όλα αυτά τα χρόνια.
Τζον Γουίλις - ένας από τους πατέρες του DevOps. Ο John έχει εμπειρία δεκαετιών σε συνεργασία με τεράστιο αριθμό εταιρειών. Πρόσφατα, ο John άρχισε να παρατηρεί συγκεκριμένα μοτίβα που λαμβάνουν χώρα όταν εργαζόταν με καθένα από αυτά. Χρησιμοποιώντας αυτά τα αρχέτυπα, ο John καθοδηγεί τις εταιρείες στην αληθινή πορεία του μετασχηματισμού του DevOps. Διαβάστε περισσότερα για αυτά τα αρχέτυπα στη μετάφραση της έκθεσής του από το συνέδριο DevOops 2018.
Σχετικά με τον ομιλητή:
Περισσότερα από 35 χρόνια στη διαχείριση πληροφορικής, συμμετείχε στη δημιουργία του προκατόχου του OpenCloud στην Canonical, συμμετείχε σε 10 startups, δύο από τις οποίες πωλήθηκαν στην Dell και την Docker. Επί του παρόντος είναι Αντιπρόεδρος DevOps και Digital Practices στην SJ Technologies.
Ακολουθεί η ιστορία από τη σκοπιά του Γιάννη.
Με λένε John Willis και το πιο εύκολο μέρος για να με βρεις είναι στο Twitter, . Έχω το ίδιο ψευδώνυμο στο Gmail και στο GitHub. ΕΝΑ μπορείτε να βρείτε εγγραφές βίντεο των αναφορών μου και παρουσιάσεις για αυτούς.
Έχω πολλές συναντήσεις με CIO διαφόρων μεγάλων εταιρειών. Πολύ συχνά παραπονιούνται ότι δεν καταλαβαίνουν τι είναι το DevOps και όλοι όσοι προσπαθούν να τους το εξηγήσουν μιλούν για κάτι διαφορετικό. Ένα άλλο κοινό παράπονο είναι ότι το DevOps δεν λειτουργεί, αν και φαίνεται ότι οι διευθυντές κάνουν τα πάντα όπως τους εξηγήθηκε. Μιλάμε για μεγάλες εταιρείες που ξεπερνούν τα εκατό χρόνια ζωής. Αφού μίλησα μαζί τους, κατέληξα στο συμπέρασμα ότι για πολλά προβλήματα, δεν είναι η υψηλή τεχνολογία που ταιριάζει καλύτερα, αλλά μάλλον οι λύσεις σχετικά χαμηλής τεχνολογίας. Για εβδομάδες μίλησα με ανθρώπους από διαφορετικά τμήματα. Αυτό που βλέπετε στην πρώτη κιόλας εικόνα της ανάρτησης είναι το τελευταίο μου έργο, έτσι ήταν το δωμάτιο μετά από τρεις μέρες δουλειάς.
Τι είναι το DevOps;
Πράγματι, αν ρωτήσεις 10 διαφορετικά άτομα, θα σου δώσουν 10 διαφορετικές απαντήσεις. Αλλά εδώ είναι το ενδιαφέρον: και οι δέκα από αυτές τις απαντήσεις θα είναι σωστές. Δεν υπάρχει λάθος απάντηση εδώ. Ήμουν αρκετά βαθιά στο DevOps, για περίπου 10 χρόνια, και ήμουν ο πρώτος Αμερικανός στην πρώτη DevOpsDay. Δεν θα πω ότι είμαι πιο έξυπνος από όλους όσους ασχολούνται με το DevOps, αλλά δεν υπάρχει σχεδόν κανένας που έχει ξοδέψει τόση προσπάθεια σε αυτό. Πιστεύω ότι το DevOps συμβαίνει όταν το ανθρώπινο κεφάλαιο και η τεχνολογία ενώνονται. Συχνά ξεχνάμε την ανθρώπινη διάσταση, αν και μιλάμε πολύ για κάθε είδους πολιτισμό.
Τώρα έχουμε πολλά δεδομένα, πέντε χρόνια ακαδημαϊκής έρευνας, δοκιμή θεωριών σε βιομηχανική κλίμακα. Αυτό που μας λένε αυτές οι μελέτες είναι ότι εάν συνδυάσετε ορισμένα πρότυπα συμπεριφοράς σε μια οργανωτική κουλτούρα, μπορείτε να επιτύχετε επιτάχυνση 2000x. Αυτή η επιτάχυνση συνοδεύεται από ίση βελτίωση στη σταθερότητα. Αυτή είναι μια ποσοτική μέτρηση του οφέλους που μπορεί να προσφέρει το DevOps σε οποιαδήποτε εταιρεία. Πριν από μερικά χρόνια, μιλούσα για το DevOps στον Διευθύνοντα Σύμβουλο μιας εταιρείας Fortune 5000. Όταν προετοιμαζόμουν για την παρουσίαση, ήμουν πολύ νευρικός γιατί έπρεπε να συνοψίσω την εμπειρία μου σε 5 λεπτά.
Στο τέλος έδωσα το εξής Ορισμός του DevOps: Είναι ένα σύνολο πρακτικών και προτύπων που επιτρέπουν τη μετατροπή του ανθρώπινου κεφαλαίου σε οργανωτικό κεφάλαιο υψηλής απόδοσης. Ένα παράδειγμα είναι ο τρόπος που λειτουργεί η Toyota τα τελευταία 50 ή 60 χρόνια.
(Στο εξής, τέτοια διαγράμματα παρέχονται όχι ως υλικό αναφοράς, αλλά ως απεικονίσεις. Το περιεχόμενό τους θα διαφέρει για κάθε νέα εταιρεία. Ωστόσο, η εικόνα μπορεί να προβληθεί ξεχωριστά και να μεγεθυνθεί
Μία από τις πιο επιτυχημένες τέτοιες πρακτικές είναι χαρτογράφηση προστιθέμενης αξίας. Έχουν γραφτεί αρκετά καλά βιβλία για αυτό, τα πιο επιτυχημένα από τα οποία είναι της Κάρεν Μάρτιν. Αλλά τον περασμένο χρόνο, κατέληξα στο συμπέρασμα ότι ακόμη και αυτή η προσέγγιση είναι πολύ υψηλής τεχνολογίας. Σίγουρα έχει πολλά πλεονεκτήματα και το έχω χρησιμοποιήσει πολύ. Αλλά όταν ο Διευθύνων Σύμβουλος σας ρωτά γιατί η εταιρεία του δεν μπορεί να στραφεί σε νέες ράγες, είναι πολύ νωρίς για να μιλήσουμε για χαρτογράφηση ροής αξίας. Υπάρχουν πολλά πολύ πιο θεμελιώδη ερωτήματα που πρέπει πρώτα να απαντηθούν.
Νομίζω ότι το λάθος που κάνουν πολλοί από τους συναδέλφους μου είναι ότι απλώς δίνουν στην εταιρεία έναν οδηγό πέντε σημείων και μετά επιστρέφουν έξι μήνες αργότερα και βλέπουν τι συνέβη. Ακόμη και ένα καλό σχήμα όπως η χαρτογράφηση ροής αξίας έχει, ας πούμε, τυφλά σημεία. Μετά από εκατοντάδες συνεντεύξεις με διευθυντές διαφόρων εταιρειών, έχω αναπτύξει ένα συγκεκριμένο μοτίβο που μας επιτρέπει να αναλύσουμε το πρόβλημα στα συστατικά του και τώρα θα συζητήσουμε καθένα από αυτά τα στοιχεία με τη σειρά. Πριν εφαρμόσω οποιεσδήποτε τεχνολογικές λύσεις, χρησιμοποιώ αυτό το μοτίβο και ως αποτέλεσμα, όλοι οι τοίχοι μου καλύπτονται με διαγράμματα. Πρόσφατα δούλευα με ένα αμοιβαίο κεφάλαιο και κατέληξα σε 100-150 τέτοια σχήματα.
Η κακή κουλτούρα τρώει καλές προσεγγίσεις για πρωινό
Η κύρια ιδέα είναι η εξής: κανένας αριθμός Lean, Agile, SAFE και DevOps δεν θα βοηθήσει εάν η ίδια η κουλτούρα του οργανισμού είναι κακή. Είναι σαν να καταδύεσαι σε βάθος χωρίς εξοπλισμό κατάδυσης ή να λειτουργείς χωρίς ακτινογραφία. Με άλλα λόγια, για να παραφράσουμε τους Drucker και Deming: μια κακή οργανωτική κουλτούρα θα καταπιεί οποιοδήποτε καλό σύστημα χωρίς να το πνίγει.
Για να λύσετε αυτό το κύριο πρόβλημα, πρέπει να ακολουθήσετε τα ακόλουθα βήματα:
- Κάντε ορατές όλες τις εργασίες: πρέπει να κάνετε όλη την εργασία ορατή. Όχι με την έννοια ότι πρέπει απαραίτητα να εμφανίζεται σε κάποια οθόνη, αλλά με την έννοια ότι πρέπει να είναι παρατηρήσιμο.
- Ενοποιημένα Συστήματα Διαχείρισης Εργασιών: τα συστήματα διαχείρισης πρέπει να ενοποιηθούν. Στο πρόβλημα της «φυλετικής» γνώσης και της θεσμικής γνώσης, σε 9 από τις 10 περιπτώσεις το σημείο συμφόρησης είναι οι άνθρωποι. Στο βιβλίο Το πρόβλημα ήταν με ένα μόνο άτομο, τον Brent, ο οποίος έκανε το έργο να καθυστερήσει τρία χρόνια από το χρονοδιάγραμμα. Και συναντώ παντού αυτά τα «Brents». Για να επιλύσω αυτά τα σημεία συμφόρησης, χρησιμοποιώ τα επόμενα δύο στοιχεία της λίστας μας.
- Μεθοδολογία Θεωρίας Περιορισμών: θεωρία περιορισμών.
- Hacks συνεργασίας: αμυχές συνεργασίας.
- Toyota Kata (): Δεν θα μιλήσω πολύ για το Toyota Kata. Αν ενδιαφέρεστε, στο github μου σχεδόν σε κάθε ένα από αυτά τα θέματα.
- Οργανισμός με προσανατολισμό στην αγορά: οργάνωση προσανατολισμένη στην αγορά.
- Shift-αριστερά ελεγκτές: έλεγχος στα αρχικά στάδια του κύκλου.
Ξεκινάω να συνεργάζομαι με έναν οργανισμό πολύ απλά: πηγαίνω στην εταιρεία και μιλάω με τους υπαλλήλους. Όπως μπορείτε να δείτε, δεν υπάρχει υψηλή τεχνολογία. Το μόνο που χρειάζεστε είναι κάτι να γράψετε. Συγκεντρώνω πολλές ομάδες σε ένα δωμάτιο και αναλύω αυτά που μου λένε από την οπτική των 7 αρχετύπων μου. Και μετά τους δίνω οι ίδιοι έναν μαρκαδόρο και τους ζητώ να γράψουν στον πίνακα όλα όσα έχουν πει δυνατά μέχρι τώρα. Συνήθως σε τέτοιου είδους συναντήσεις υπάρχει ένα άτομο που καταγράφει τα πάντα και στην καλύτερη περίπτωση μπορεί να γράψει το 10% της συζήτησης. Με τη μέθοδό μου, αυτό το ποσοστό μπορεί να αυξηθεί σε περίπου 40%.
(Αυτή η εικόνα μπορεί να προβληθεί ξεχωριστά )
Η προσέγγισή μου βασίζεται στο έργο του William Schneider. ). Η προσέγγιση βασίζεται στην ιδέα ότι κάθε οργανισμός μπορεί να χωριστεί σε τέσσερα τετράγωνα. Αυτό το σχήμα για μένα είναι συνήθως το αποτέλεσμα της συνεργασίας με αυτά τα εκατοντάδες άλλα σχήματα που προκύπτουν κατά την ανάλυση ενός οργανισμού. Ας υποθέσουμε ότι έχουμε έναν οργανισμό με υψηλό επίπεδο ελέγχου, αλλά με χαμηλή ικανότητα. Αυτή είναι μια εξαιρετικά ανεπιθύμητη επιλογή: όταν όλοι ακολουθούν τη γραμμή των ποδιών, αλλά κανείς δεν ξέρει τι να κάνει.
Μια κάπως καλύτερη επιλογή είναι αυτή με υψηλό επίπεδο ελέγχου και ικανότητας. Εάν μια τέτοια εταιρεία είναι κερδοφόρα, τότε ίσως δεν χρειάζεται DevOps. Είναι πιο ενδιαφέρον να συνεργαστείς με μια εταιρεία που έχει υψηλό επίπεδο ελέγχου, χαμηλή ικανότητα και συνεργασία, αλλά ταυτόχρονα υψηλό επίπεδο κουλτούρας (καλλιέργεια). Αυτό σημαίνει ότι η εταιρεία έχει πολλούς ανθρώπους που τους αρέσει να εργάζονται εκεί και ο κύκλος εργασιών είναι χαμηλός.
(Αυτή η εικόνα μπορεί να προβληθεί ξεχωριστά )
Μου φαίνεται ότι οι μέθοδοι με άκαμπτες κατευθυντήριες γραμμές καταλήγουν να εμποδίζουν την επίτευξη της αλήθειας. Ειδικά στη χαρτογράφηση ροής αξίας, υπάρχουν πολλοί κανόνες σχετικά με τον τρόπο δομής των πληροφοριών. Στα πρώτα στάδια της εργασίας, για τα οποία μιλάω τώρα, κανείς δεν χρειάζεται αυτούς τους κανόνες. Εάν ένα άτομο με ένα μαρκαδόρο στα χέρια του περιγράφει την πραγματική κατάσταση στην εταιρεία στο ταμπλό, αυτός είναι ο καλύτερος τρόπος για να κατανοήσετε την κατάσταση των πραγμάτων. Τέτοιες πληροφορίες δεν φτάνουν στους διευθυντές. Αυτή τη στιγμή, είναι ανόητο να διακόπτεις το άτομο και να λες ότι τράβηξε κάποιο είδος βέλους λάθος. Σε αυτό το στάδιο, είναι καλύτερο να χρησιμοποιείτε απλούς κανόνες, για παράδειγμα: η αφαίρεση πολλαπλών επιπέδων μπορεί να δημιουργηθεί απλά χρησιμοποιώντας πολύχρωμους δείκτες.
Επαναλαμβάνω, όχι υψηλή τεχνολογία. Ο μαύρος μαρκαδόρος απεικονίζει την αντικειμενική πραγματικότητα του πώς λειτουργούν τα πάντα. Με έναν κόκκινο μαρκαδόρο, οι άνθρωποι σημειώνουν αυτό που δεν τους αρέσει στην τρέχουσα κατάσταση. Σημασία έχει να το γράφουν αυτοί, όχι εγώ. Όταν πηγαίνω στο CIO μετά από μια συνάντηση, δεν προσφέρω μια λίστα με 10 πράγματα που πρέπει να διορθωθούν. Προσπαθώ να βρω συνδέσεις μεταξύ αυτών που λένε οι άνθρωποι στην εταιρεία και των υπαρχόντων αποδεδειγμένων προτύπων. Τέλος, ένας μπλε δείκτης προτείνει πιθανές λύσεις στο πρόβλημα.
(Αυτή η εικόνα μπορεί να προβληθεί ξεχωριστά )
Ένα παράδειγμα αυτής της προσέγγισης απεικονίζεται τώρα παραπάνω. Στις αρχές του τρέχοντος έτους συνεργάστηκα με μια τράπεζα. Οι άνθρωποι ασφαλείας εκεί ήταν πεπεισμένοι ότι δεν έπρεπε να έρθουν σε αναθεωρήσεις σχεδιασμού και απαιτήσεων.
(Αυτή η εικόνα μπορεί να προβληθεί ξεχωριστά )
Και μετά μιλήσαμε με άτομα από άλλα τμήματα και αποδείχθηκε ότι πριν από περίπου 8 χρόνια, προγραμματιστές λογισμικού απέλυσαν υπαλλήλους ασφαλείας επειδή επιβράδυναν την εργασία. Και μετά μετατράπηκε σε απαγόρευση, η οποία θεωρήθηκε δεδομένη. Αν και στην πραγματικότητα δεν υπήρχε απαγόρευση.
Η συνάντησή μας προχώρησε με έναν εξαιρετικά συγκεχυμένο τρόπο: για περίπου τρεις ώρες, πέντε διαφορετικές ομάδες δεν μπορούσαν να μου εξηγήσουν τι συνέβαινε μεταξύ του κώδικα και της συναρμολόγησης. Και αυτό φαίνεται να είναι το πιο απλό πράγμα. Οι περισσότεροι σύμβουλοι DevOps υποθέτουν εκ των προτέρων ότι όλοι το γνωρίζουν ήδη αυτό.
Τότε ο υπεύθυνος της διακυβέρνησης πληροφορικής, ο οποίος είχε σιωπήσει για τέσσερις ώρες, ξαφνικά ζωντάνεψε όταν φτάσαμε στο θέμα του και μας απασχόλησε για πάρα πολύ καιρό. Στο τέλος τον ρώτησα τι πιστεύει για τη συνάντηση και δεν θα ξεχάσω ποτέ την απάντησή του. Είπε: «Νόμιζα ότι η τράπεζά μας είχε μόνο δύο τρόπους παράδοσης λογισμικού, αλλά τώρα ξέρω ότι υπάρχουν πέντε από αυτούς και δεν ήξερα καν για τρεις».
(Αυτή η εικόνα μπορεί να προβληθεί ξεχωριστά )
Η τελευταία συνάντηση σε αυτή την τράπεζα ήταν με την ομάδα επενδυτικού λογισμικού. Ήταν μαζί της που αποδείχθηκε ότι η γραφή διαγραμμάτων με μαρκαδόρο σε ένα φύλλο χαρτιού είναι καλύτερη από ό, τι σε έναν πίνακα και ακόμη καλύτερα από ό, τι σε μια έξυπνη κάρτα.
Οι φωτογραφίες που βλέπετε είναι πώς έμοιαζε η αίθουσα συνεδριάσεων του ξενοδοχείου την τέταρτη μέρα της συνάντησής μας. Και χρησιμοποιήσαμε αυτά τα σχήματα για να αναζητήσουμε μοτίβα, δηλαδή αρχέτυπα.
Κάνω λοιπόν ερωτήσεις στους εργαζόμενους, γράφουν τις απαντήσεις με μαρκαδόρους τριών χρωμάτων (μαύρο, κόκκινο και μπλε). Αναλύω τις απαντήσεις τους για αρχέτυπα. Τώρα ας συζητήσουμε όλα τα αρχέτυπα με τη σειρά.
1. Make All Work Visible: Κάντε την εργασία ορατή
Οι περισσότερες εταιρείες με τις οποίες συνεργάζομαι έχουν πολύ υψηλό ποσοστό άγνωστης εργασίας. Για παράδειγμα, αυτό συμβαίνει όταν ένας υπάλληλος έρχεται σε έναν άλλο και απλώς ζητά να κάνει κάτι. Σε μεγάλους οργανισμούς, μπορεί να υπάρχει 60% απρογραμμάτιστη εργασία. Και έως και το 40% της εργασίας δεν τεκμηριώνεται με κανέναν τρόπο. Αν ήταν Boeing, δεν θα επιβιβαζόμουν ποτέ ξανά στο αεροπλάνο τους στη ζωή μου. Εάν μόνο το ήμισυ της εργασίας είναι τεκμηριωμένη, τότε δεν είναι γνωστό εάν αυτή η εργασία γίνεται σωστά ή όχι. Όλες οι άλλες μέθοδοι αποδεικνύονται άχρηστες - δεν έχει νόημα να προσπαθήσουμε να αυτοματοποιήσουμε οτιδήποτε, επειδή το γνωστό 50% μπορεί να είναι το πιο συνεκτικό και σαφές μέρος της εργασίας, η αυτοματοποίηση του οποίου δεν θα δώσει εξαιρετικά αποτελέσματα και το χειρότερο τα πράγματα είναι στο αόρατο μισό. Ελλείψει τεκμηρίωσης, είναι αδύνατο να βρούμε κάθε είδους αμυχές και κρυφές εργασίες, να μην βρούμε σημεία συμφόρησης, αυτά τα ίδια τα «Brents» για τα οποία μίλησα ήδη. Υπάρχει ένα υπέροχο βιβλίο της Dominica DeGrandis . Αυτή αποκαλύπτει πέντε διαφορετικές «διαρροές χρόνου» (κλέφτες του χρόνου):
- Πάρα πολύ δουλειά σε εξέλιξη (WIP)
- Άγνωστες εξαρτήσεις
- Απρογραμματισμένη εργασία
- Αντικρουόμενες προτεραιότητες
- Παραμελημένη εργασία
Αυτή είναι πολύ πολύτιμη ανάλυση και το βιβλίο είναι υπέροχο, αλλά όλες αυτές οι συμβουλές είναι άχρηστες αν είναι ορατό μόνο το 50% των δεδομένων. Οι μέθοδοι που προτείνει η Dominica μπορούν να χρησιμοποιηθούν εάν επιτευχθεί ακρίβεια άνω του 90%. Μιλάω για καταστάσεις όπου ένα αφεντικό δίνει σε έναν υφιστάμενο μια εργασία 15 λεπτών, αλλά του παίρνει τρεις μέρες. αλλά το αφεντικό δεν ξέρει πραγματικά ότι αυτός ο υφιστάμενος εξαρτάται από τέσσερα ή πέντε άλλα άτομα.
Το Phoenix Project είναι μια υπέροχη ιστορία για ένα έργο που άργησε τρία χρόνια. Ένας από τους χαρακτήρες αντιμετωπίζει την απόλυση εξαιτίας αυτού και συναντά έναν άλλο χαρακτήρα που παρουσιάζεται ως ένα είδος Σωκράτη. Βοηθά να καταλάβουμε τι ακριβώς πήγε στραβά. Αποδεικνύεται ότι η εταιρεία έχει έναν διαχειριστή συστήματος, του οποίου το όνομα είναι Brent, και όλη η δουλειά περνάει κατά κάποιον τρόπο από αυτόν. Σε μια από τις συναντήσεις, ένας από τους υφισταμένους ρωτιέται: γιατί κάθε ημίωρη εργασία διαρκεί μια εβδομάδα; Η απάντηση είναι μια πολύ απλοποιημένη παρουσίαση της θεωρίας της ουράς και του νόμου του Little, και σε αυτήν την παρουσίαση αποδεικνύεται ότι σε πληρότητα 90%, κάθε ώρα εργασίας διαρκεί 9 ώρες. Κάθε εργασία πρέπει να σταλεί σε επτά άλλα άτομα, έτσι ώστε η ώρα να γίνει 63 ώρες, 7 επί 9. Το σημείο που επισημαίνω είναι ότι για να χρησιμοποιήσετε τον νόμο του Little ή οποιαδήποτε περίπλοκη θεωρία ουράς, πρέπει τουλάχιστον να έχετε δεδομένα.
Όταν λοιπόν μιλάω για ορατότητα, δεν εννοώ ότι είναι όλα στην οθόνη, αλλά ότι τουλάχιστον έχεις δεδομένα. Όταν το κάνουν, συχνά αποδεικνύεται ότι υπάρχει ένας πολύ μεγάλος όγκος απρογραμμάτιστης εργασίας που με κάποιο τρόπο αποστέλλεται στο Brent όταν δεν υπάρχει ανάγκη. Και ο Μπρεντ είναι υπέροχος τύπος, δεν θα πει ποτέ όχι, αλλά δεν λέει σε κανέναν πώς κάνει τη δουλειά του.
Όταν το έργο είναι ορατό, τα δεδομένα μπορούν να ταξινομηθούν προσεκτικά (αυτό κάνει η Dominika στη φωτογραφία), μπορεί να εφαρμοστεί η αφαίρεση των πέντε διαρροών χρόνου και να εφαρμοστεί αυτοματισμός.
2. Ενοποίηση Συστημάτων Διαχείρισης Εργασίας: Διαχείριση εργασιών
Τα αρχέτυπα για τα οποία μιλάω είναι ένα είδος πυραμίδας. Εάν το πρώτο γίνει σωστά, τότε το δεύτερο είναι ήδη ένα είδος πρόσθετου. Πολλά από αυτά δεν λειτουργούν για νεοφυείς επιχειρήσεις, πρέπει να τα έχουμε κατά νου για μεγαλύτερες εταιρείες όπως το Fortune 5000. Η τελευταία εταιρεία στην οποία εργάστηκα είχε 10 συστήματα έκδοσης εισιτηρίων. Μια ομάδα είχε το Remedy, μια άλλη έγραψε κάποιο δικό της σύστημα, μια τρίτη χρησιμοποίησε το Jira και κάποιες αρκέστηκαν στο email. Το ίδιο πρόβλημα προκύπτει εάν η εταιρεία έχει 30 διαφορετικούς αγωγούς, αλλά δεν έχω χρόνο να συζητήσω όλες αυτές τις περιπτώσεις.
Συζητώ με τους ανθρώπους πώς ακριβώς δημιουργούνται τα εισιτήρια, τι τους συμβαίνει στη συνέχεια και πώς παρακάμπτονται. Το πιο ενδιαφέρον είναι ότι οι άνθρωποι στις συναντήσεις μας μιλούν αρκετά ειλικρινά. Ρώτησα πόσοι άνθρωποι έβαλαν «ελάσσονος / μηδενικός αντίκτυπος» στα εισιτήρια που θα έπρεπε στην πραγματικότητα να έχουν «μεγάλο αντίκτυπο». Αποδείχθηκε ότι σχεδόν όλοι το κάνουν αυτό. Δεν ασχολούμαι με την καταγγελία και προσπαθώ με κάθε δυνατό τρόπο να μην ταυτίζω άτομα. Όταν μου ομολογούν ειλικρινά κάτι, δεν δίνω το άτομο. Αλλά όταν σχεδόν όλοι παρακάμπτουν το σύστημα, αυτό σημαίνει ότι όλη η ασφάλεια είναι ουσιαστικά κάλυψη παραθύρων. Επομένως, δεν μπορούν να εξαχθούν συμπεράσματα από τα δεδομένα αυτού του συστήματος.
Για να λύσετε το πρόβλημα του εισιτηρίου, πρέπει να επιλέξετε ένα κύριο σύστημα. Εάν χρησιμοποιείτε το Jira, κρατήστε το Jira. Αν υπάρχει κάποια εναλλακτική, ας είναι η μόνη. Η ουσία είναι ότι τα εισιτήρια πρέπει να θεωρούνται ως ένα άλλο βήμα στη διαδικασία ανάπτυξης. Κάθε ενέργεια πρέπει να έχει ένα εισιτήριο, το οποίο πρέπει να διέρχεται από τη ροή εργασιών ανάπτυξης. Τα εισιτήρια αποστέλλονται στην ομάδα, η οποία τα αναρτά στο storyboard και στη συνέχεια αναλαμβάνει την ευθύνη για αυτά.
Αυτό ισχύει για όλα τα τμήματα, συμπεριλαμβανομένων των υποδομών και των λειτουργιών. Σε αυτή την περίπτωση, είναι δυνατό να σχηματιστεί τουλάχιστον κάποια εύλογη ιδέα για την κατάσταση των πραγμάτων. Μόλις καθιερωθεί αυτή η διαδικασία, γίνεται ξαφνικά εύκολο να εντοπιστεί ποιος είναι υπεύθυνος για κάθε εφαρμογή. Γιατί τώρα δεν λαμβάνουμε το 50%, αλλά το 98% των νέων υπηρεσιών. Εάν αυτή η βασική διαδικασία λειτουργεί, τότε η ακρίβεια βελτιώνεται σε όλο το σύστημα.
Αγωγός υπηρεσιών
Αυτό ισχύει και πάλι μόνο για μεγάλες εταιρείες. Εάν είστε νέα εταιρεία σε έναν νέο τομέα, σηκώστε τα μανίκια σας και δουλέψτε με το Travis CI ή το CircleCI. Όταν πρόκειται για εταιρείες του Fortune 5000, μια ενδεικτική περίπτωση που συνέβη στην τράπεζα όπου εργαζόμουν. Τους ήρθε η Google και τους έδειξαν διαγράμματα παλαιών συστημάτων IBM. Τα παιδιά από την Google ρώτησαν μπερδεμένα - πού είναι ο πηγαίος κώδικας για αυτό; Αλλά δεν υπάρχει πηγαίος κώδικας, ούτε καν GUI. Αυτή είναι η πραγματικότητα με την οποία καλούνται να αντιμετωπίσουν οι μεγάλοι οργανισμοί: τραπεζικά αρχεία 40 ετών σε έναν αρχαίο κεντρικό υπολογιστή. Ένας από τους πελάτες μου χρησιμοποιεί δοχεία Kubernetes με μοτίβα Circuit Breaker, συν το Chaos Monkey, όλα για την εφαρμογή KeyBank. Αλλά αυτά τα δοχεία συνδέονται τελικά με μια εφαρμογή COBOL.
Τα παιδιά από την Google ήταν απολύτως βέβαιοι ότι θα έλυναν όλα τα προβλήματα του πελάτη μου και μετά άρχισαν να κάνουν ερωτήσεις: τι είναι το IBM datapipe; Τους λένε: αυτός είναι ένας σύνδεσμος. Με τι συνδέεται; Στο σύστημα Sperry. Και τι είναι αυτό? Και ούτω καθεξής. Με την πρώτη ματιά φαίνεται: τι είδους DevOps μπορεί να υπάρχουν; Αλλά στην πραγματικότητα, είναι δυνατό. Υπάρχουν συστήματα παράδοσης που σας επιτρέπουν να παραδώσετε τη ροή εργασίας στις ομάδες παράδοσης.
3. Theory of Constraints: Theory of Constraints
Ας περάσουμε στο τρίτο αρχέτυπο: θεσμική/«φυλετική» γνώση. Κατά κανόνα, σε κάθε οργανισμό υπάρχουν αρκετοί άνθρωποι που ξέρουν τα πάντα και διαχειρίζονται τα πάντα. Αυτοί είναι εκείνοι που είναι στον οργανισμό το μεγαλύτερο διάστημα και γνωρίζουν όλες τις λύσεις.
Όταν εμφανίζεται αυτό στο διάγραμμα, κυκλώνω συγκεκριμένα τέτοιους ανθρώπους με ένα μαρκαδόρο: για παράδειγμα, αποδεικνύεται ότι ένας συγκεκριμένος Λου είναι παρών σε όλες τις συναντήσεις. Και είναι ξεκάθαρο για μένα: αυτό είναι το τοπικό Brent. Όταν ο CIO επιλέγει ανάμεσα σε εμένα με μπλουζάκι και αθλητικά παπούτσια και τον τύπο της IBM με κοστούμι, με επιλέγουν επειδή μπορώ να πω στον διευθυντή πράγματα που ο άλλος δεν θα πει και που ο σκηνοθέτης μπορεί να μην ήθελε να ακούσει . Τους λέω ότι το σημείο συμφόρησης στην εταιρεία τους είναι κάποιος που λέγεται Φρεντ και κάποιος Λου. Αυτό το στενό πρέπει να λυθεί, οι γνώσεις τους πρέπει να αντληθούν από αυτούς με τον έναν ή τον άλλον τρόπο.
Για την επίλυση αυτού του είδους προβλήματος, μπορώ, για παράδειγμα, να προτείνω τη χρήση του Slack. Ένας έξυπνος σκηνοθέτης θα ρωτήσει - γιατί; Συνήθως, σε τέτοιες περιπτώσεις, οι σύμβουλοι DevOps απαντούν: γιατί όλοι το κάνουν. Αν ο σκηνοθέτης είναι πραγματικά έξυπνος, θα πει: και τι. Και εδώ τελειώνει ο διάλογος. Και η απάντησή μου σε αυτό είναι: επειδή υπάρχουν τέσσερα σημεία συμφόρησης στην εταιρεία, ο Φρεντ, ο Λου, η Σούζι και η Τζέιν. Για να θεσμοθετήσει κανείς τις γνώσεις τους, πρέπει πρώτα να εισαγάγει το Slack. Όλα τα wiki σας είναι εντελώς ανοησίες γιατί κανείς δεν γνωρίζει την ύπαρξή τους. Εάν η ομάδα μηχανικών εμπλέκεται στην ανάπτυξη front-end και back-end και όλοι πρέπει να γνωρίζουν ότι μπορούν να επικοινωνήσουν με την ομάδα ανάπτυξης front-end ή την ομάδα υποδομής με ερωτήσεις. Τότε είναι που ο Λου ή ο Φρεντ θα έχουν πιθανώς χρόνο να συμμετάσχουν στο wiki. Και μετά στο Slack κάποιος μπορεί να ρωτήσει γιατί, ας πούμε, το βήμα 5 δεν λειτουργεί. Και τότε ο Λου ή ο Φρεντ θα διορθώσουν τις οδηγίες στο wiki. Εάν καθιερώσετε αυτή τη διαδικασία, τότε πολλά πράγματα θα μπουν στη θέση τους από μόνα τους.
Αυτό είναι το κύριο σημείο μου: για να προτείνετε οποιεσδήποτε υψηλές τεχνολογίες, πρέπει πρώτα να βάλετε σε τάξη τις βάσεις για αυτές, και αυτό μπορεί να γίνει με τις λύσεις χαμηλής τεχνολογίας που μόλις περιγράφηκαν. Εάν ξεκινήσετε με υψηλές τεχνολογίες και δεν εξηγήσετε γιατί χρειάζονται, τότε, κατά κανόνα, αυτό δεν τελειώνει καλά. Ένας από τους πελάτες μας χρησιμοποιεί το Azure ML, μια πολύ φθηνή και απλή λύση. Περίπου το 30% των ερωτήσεών τους απαντήθηκαν από την ίδια τη μηχανή αυτομάθησης. Και αυτό το πράγμα γράφτηκε από χειριστές που δεν ασχολούνταν με την επιστήμη των δεδομένων, τη στατιστική ή τα μαθηματικά. Αυτό είναι σημαντικό. Το κόστος μιας τέτοιας λύσης είναι ελάχιστο.
4. Συνεργατικές αμυχές: Συνεργατικές αμυχές
Το τέταρτο αρχέτυπο είναι η ανάγκη καταπολέμησης της απομόνωσης. Οι περισσότεροι το γνωρίζουν ήδη: η απομόνωση γεννά εχθρότητα. Εάν κάθε τμήμα βρίσκεται στον δικό του όροφο και οι άνθρωποι δεν διασταυρώνονται μεταξύ τους με κανέναν τρόπο, παρά μόνο στο ασανσέρ, τότε η εχθρότητα μεταξύ τους προκύπτει πολύ εύκολα. Αλλά αν, αντίθετα, οι άνθρωποι βρίσκονται στο ίδιο δωμάτιο μεταξύ τους, εκείνη φεύγει αμέσως. Όταν κάποιος εκτοξεύει κάποια γενική κατηγορία, για παράδειγμα, η τάδε διεπαφή δεν λειτουργεί ποτέ, δεν υπάρχει τίποτα πιο εύκολο να αποδομήσει μια τέτοια κατηγορία. Οι προγραμματιστές που έγραψαν τη διεπαφή πρέπει απλώς να αρχίσουν να κάνουν συγκεκριμένες ερωτήσεις και σύντομα θα γίνει σαφές ότι, για παράδειγμα, ο χρήστης απλώς χρησιμοποιούσε το εργαλείο εσφαλμένα.
Υπάρχουν πολλοί τρόποι για να ξεπεράσεις την απομόνωση. Κάποτε μου ζητήθηκε να συμβουλευτώ μια τράπεζα στην Αυστραλία, αλλά αρνήθηκα να το κάνω γιατί έχω δύο παιδιά και μια γυναίκα. Το μόνο που μπορούσα να κάνω για να τους βοηθήσω ήταν να προτείνω γραφική αφήγηση. Αυτό είναι κάτι που αποδεδειγμένα λειτουργεί. Ένας άλλος ενδιαφέρων τρόπος είναι οι συναντήσεις με άπαχο καφέ. Σε έναν μεγάλο οργανισμό, αυτή είναι μια εξαιρετική επιλογή για τη διάδοση της γνώσης. Επιπλέον, μπορείτε να διεξάγετε εσωτερικά devopsdays, hackathons και ούτω καθεξής.
5. Coaching Kata
Όπως προειδοποίησα στην αρχή, δεν θα μιλήσω για αυτό σήμερα. Αν σε ενδιαφέρει, μπορείς να ρίξεις μια ματιά .
Υπάρχει επίσης μια καλή συζήτηση για αυτό το θέμα από τον Mike Rother:
6. Market Oriented: προσανατολισμένος στην αγορά οργάνωση
Εδώ υπάρχουν διάφορα προβλήματα. Για παράδειγμα, άτομα «εγώ», άτομα «Τ» και άτομα «Ε». Οι άνθρωποι «εγώ» είναι αυτοί που κάνουν μόνο ένα πράγμα. Συνήθως υπάρχουν σε οργανισμούς με απομονωμένα τμήματα. «Τ» είναι όταν ένας άνθρωπος είναι καλός σε ένα πράγμα αλλά και καλός σε κάποια άλλα πράγματα. «Ε» ή ακόμα και «χτένα» είναι όταν ένα άτομο έχει πολλές δεξιότητες.
Ο νόμος του Conway λειτουργεί εδώ (), το οποίο στην πιο απλοποιημένη μορφή μπορεί να δηλωθεί ως εξής: εάν τρεις ομάδες εργαστούν στον μεταγλωττιστή, τότε το αποτέλεσμα θα είναι ένας μεταγλωττιστής τριών μερών. Επομένως, εάν υπάρχει υψηλό επίπεδο απομόνωσης μέσα σε έναν οργανισμό, τότε ακόμη και το Kubernetes, ο διακόπτης κυκλώματος, η επεκτασιμότητα του API και άλλα φανταχτερά πράγματα σε αυτόν τον οργανισμό θα τακτοποιηθούν με τον ίδιο τρόπο όπως ο ίδιος ο οργανισμός. Αυστηρά σύμφωνα με τον Conway και για να πείραμα όλοι εσείς οι νέοι geeks.
Η λύση σε αυτό το πρόβλημα έχει περιγραφεί πολλές φορές. Υπάρχουν, για παράδειγμα, οργανωτικά αρχέτυπα που περιγράφονται από τον Fernando Fernandez. Αυτή η προβληματική αρχιτεκτονική για την οποία μόλις μίλησα, με απομόνωση, είναι μια αρχιτεκτονική προσανατολισμένη στη λειτουργία. Ο δεύτερος τύπος είναι ο χειρότερος, αρχιτεκτονική matrix, ένα χάος από τα άλλα δύο. Το τρίτο είναι αυτό που παρατηρείται στις περισσότερες νεοφυείς επιχειρήσεις, και οι μεγάλες εταιρείες προσπαθούν επίσης να ταιριάξουν με αυτόν τον τύπο. Είναι ένας οργανισμός προσανατολισμένος στην αγορά. Εδώ βελτιστοποιούμε για να επιτύχουμε την ταχύτερη απόκριση στα αιτήματα των πελατών. Αυτό μερικές φορές ονομάζεται επίπεδη οργάνωση.
Πολλοί άνθρωποι περιγράφουν αυτή τη δομή με διαφορετικούς τρόπους, μου αρέσει η διατύπωση δημιουργία/τρέξτε ομάδες, στο Amazon το λένε δύο ομάδες πίτσας. Σε αυτή τη δομή, όλα τα άτομα τύπου «Ι» ομαδοποιούνται γύρω από μία υπηρεσία και σταδιακά πλησιάζουν τον τύπο «Τ» και εάν υπάρχει η σωστή διαχείριση, μπορούν ακόμη και να γίνουν «Ε». Το πρώτο αντεπιχείρημα εδώ είναι ότι μια τέτοια δομή έχει περιττά στοιχεία. Γιατί χρειάζεστε έναν ελεγκτή σε κάθε τμήμα εάν μπορείτε να έχετε ένα ειδικό τμήμα ελεγκτών; Στο οποίο απαντώ: το επιπλέον κόστος σε αυτή την περίπτωση είναι το τίμημα για να γίνει ολόκληρος ο οργανισμός τύπου «Ε» στο μέλλον. Σε αυτή τη δομή, ο δοκιμαστής μαθαίνει σταδιακά για τα δίκτυα, την αρχιτεκτονική, το σχεδιασμό κ.λπ. Ως αποτέλεσμα, κάθε συμμετέχων στον οργανισμό είναι πλήρως ενήμερος για όλα όσα συμβαίνουν στον οργανισμό. Αν θέλετε να μάθετε πώς λειτουργεί αυτό το σχήμα στη βιομηχανία, διαβάστε .
7. Shift-αριστερά ελεγκτές: έλεγχος στις αρχές του κύκλου. Συμμόρφωση με τους κανόνες ασφαλείας στην οθόνη
Αυτό συμβαίνει όταν οι ενέργειές σας δεν περνούν το τεστ όσφρησης, ας πούμε έτσι. Οι άνθρωποι που δουλεύουν για σένα δεν είναι ανόητοι. Εάν, όπως στο παραπάνω παράδειγμα, θέτουν παντού μικρό/καμία επίδραση, αυτό κράτησε τρία χρόνια και κανείς δεν παρατήρησε τίποτα, τότε όλοι γνωρίζουν πολύ καλά ότι το σύστημα δεν λειτουργεί. Ή ένα άλλο παράδειγμα - ένα συμβουλευτικό συμβούλιο αλλαγής, όπου οι αναφορές πρέπει να υποβάλλονται κάθε, ας πούμε, Τετάρτη. Υπάρχει μια ομάδα ανθρώπων που εργάζεται εκεί (παρεμπιπτόντως όχι πολύ καλά αμειβόμενοι) που, θεωρητικά, θα έπρεπε να γνωρίζουν πώς λειτουργεί το σύστημα στο σύνολό του. Και τα τελευταία πέντε χρόνια, πιθανότατα έχετε παρατηρήσει ότι τα συστήματά μας είναι απίστευτα πολύπλοκα. Και πέντε ή έξι άτομα πρέπει να πάρουν μια απόφαση για μια αλλαγή που δεν έκαναν και για την οποία δεν γνωρίζουν τίποτα.
Φυσικά, αυτή η προσέγγιση δεν λειτουργεί. Πρέπει να απαλλαγώ από τέτοια πράγματα γιατί αυτοί οι άνθρωποι δεν προστατεύουν το σύστημα. Την απόφαση πρέπει να την πάρει η ίδια η ομάδα, γιατί η ομάδα πρέπει να είναι υπεύθυνη για αυτό. Διαφορετικά, δημιουργείται μια παράδοξη κατάσταση όταν ένας μάνατζερ που δεν έχει γράψει ποτέ κώδικα στη ζωή του λέει στον προγραμματιστή πόσο χρόνο χρειάζεται για να γράψει κώδικα. Μια εταιρεία με την οποία συνεργάστηκα είχε 7 διαφορετικούς πίνακες που εξέταζαν κάθε αλλαγή, συμπεριλαμβανομένου ενός πίνακα αρχιτεκτονικής, ενός πίνακα προϊόντων κ.λπ. Υπήρχε ακόμη και μια υποχρεωτική περίοδος αναμονής, αν και ένας υπάλληλος μου είπε ότι σε δέκα χρόνια εργασίας, κανείς δεν είχε ποτέ απορρίψει μια αλλαγή που έκανε αυτό το άτομο κατά τη διάρκεια αυτής της υποχρεωτικής περιόδου.
Οι ελεγκτές πρέπει να προσκληθούν να ενωθούν μαζί μας και όχι να τους ξεφορτωθούν. Πείτε τους ότι γράφετε αμετάβλητα δυαδικά δοχεία που, αν περάσουν όλα τα τεστ, παραμένουν αμετάβλητα για πάντα. Πείτε τους ότι έχετε έναν κώδικα ως κώδικα και εξηγήστε τι σημαίνει αυτό. Δείξτε τους το ακόλουθο σχήμα: ένα αμετάβλητο δυαδικό αρχείο μόνο για ανάγνωση σε ένα κοντέινερ που περνάει όλες τις δοκιμές ευπάθειας. και μετά όχι μόνο δεν το αγγίζει κανείς, αλλά ούτε καν το σύστημα που δημιουργεί τον αγωγό, αφού δημιουργείται και δυναμικά. Έχω πελάτες, την Capital One, που χρησιμοποιούν το Vault για να δημιουργήσουν κάτι σαν blockchain. Ο ελεγκτής δεν χρειάζεται να δείξει «συνταγές» από τον Chef, αρκεί να δείξει το blockchain, από το οποίο είναι ξεκάθαρο τι συνέβη με το εισιτήριο Jira στην παραγωγή και ποιος είναι υπεύθυνος για αυτό.
Σύμφωνα με , που δημιουργήθηκε το 2018 από τη Sonatype, υπήρξαν 2017 δισεκατομμύρια αιτήματα λήψης OSS το 87.
Οι απώλειες λόγω τρωτών σημείων είναι απαγορευτικές. Επιπλέον, τα στοιχεία που βλέπετε τώρα παραπάνω δεν περιλαμβάνουν κόστος ευκαιρίας. Τι είναι το DevSecOps με λίγα λόγια; Να πω αμέσως ότι δεν με ενδιαφέρει να μιλήσω για το πόσο επιτυχημένο είναι αυτό το όνομα. Το θέμα είναι ότι εφόσον το DevOps ήταν τόσο επιτυχημένο, θα πρέπει να προσπαθήσουμε να προσθέσουμε ασφάλεια σε αυτόν τον αγωγό.
Ένα παράδειγμα αυτής της ακολουθίας:
Δεν είναι σύσταση για συγκεκριμένα προϊόντα, αν και μου αρέσουν όλα. Τους ανέφερα ως παράδειγμα για να δείξω ότι το DevOps, το οποίο βασίστηκε αρχικά στο οργανωτικό παράδειγμα στη βιομηχανία, σας επιτρέπει να αυτοματοποιήσετε κάθε στάδιο της εργασίας σε ένα προϊόν.
Και δεν υπάρχει κανένας λόγος για τον οποίο δεν μπορούσαμε να ακολουθήσουμε την ίδια προσέγγιση για την ασφάλεια.
Σύνολο
Ως συμπέρασμα, θα δώσω μερικές συμβουλές για το DevSecOps. Πρέπει να συμπεριλάβετε ελεγκτές στη διαδικασία δημιουργίας των συστημάτων σας και να αφιερώσετε χρόνο στην εκπαίδευσή τους. Πρέπει να συνεργαστείτε με ελεγκτές. Στη συνέχεια, πρέπει να διεξάγετε έναν απολύτως ανελέητο αγώνα ενάντια στα ψευδώς θετικά. Ακόμη και με το πιο ακριβό εργαλείο σάρωσης ευπάθειας, μπορείτε να καταλήξετε να δημιουργείτε εξαιρετικά κακές συνήθειες μεταξύ των προγραμματιστών σας, αν δεν γνωρίζετε ποια είναι η αναλογία σήματος προς θόρυβο. Οι προγραμματιστές θα κατακλύζονται από συμβάντα και απλώς θα τα διαγράφουν. Αν ακούσατε για την ιστορία του Equifax, αυτό συνέβη λίγο πολύ εκεί, όπου το υψηλότερο επίπεδο συναγερμού αγνοήθηκε. Επιπλέον, τα τρωτά σημεία πρέπει να εξηγηθούν με τρόπο που να καθιστά σαφές πώς επηρεάζουν την επιχείρηση. Για παράδειγμα, θα μπορούσατε να πείτε ότι πρόκειται για την ίδια ευπάθεια όπως στην ιστορία του Equifax. Τα τρωτά σημεία ασφαλείας θα πρέπει να αντιμετωπίζονται με τον ίδιο τρόπο με άλλα ζητήματα λογισμικού, δηλαδή να περιλαμβάνονται στη συνολική διαδικασία DevOps. Πρέπει να συνεργαστείτε μαζί τους μέσω Jira, Kanban κ.λπ. Οι προγραμματιστές δεν πρέπει να πιστεύουν ότι κάποιος άλλος θα το κάνει αυτό - αντίθετα, όλοι πρέπει να το κάνουν αυτό. Τέλος, πρέπει να ξοδέψετε ενέργεια για την εκπαίδευση των ανθρώπων.
χρήσιμοι σύνδεσμοι
Ακολουθούν μερικές ομιλίες από τη διάσκεψη DevOops που μπορεί να σας φανούν χρήσιμες:
- Sergey Berdnikov, Artyom Kalichkin - Ιστορία επιτυχίας ή "Dev+DevOps+Ops" (, )
- Baruch Sadogursky, Leonid Igolnik - DevOps σε κλίμακα: μια ελληνική τραγωδία σε τρεις πράξεις (, )
- Alexander Titov, Kirill Tolkachev -
- Timothy Lister -
Εξετάσουμε DevOops 2020 Μόσχα — υπάρχουν επίσης πολλά ενδιαφέροντα πράγματα εκεί.
Πηγή: www.habr.com