Ο ορισμός του DevOps είναι πολύ περίπλοκος, επομένως πρέπει να ξεκινάμε τη συζήτηση από την αρχή κάθε φορά. Υπάρχουν χιλιάδες δημοσιεύσεις για αυτό το θέμα μόνο στο Habré. Αλλά αν διαβάζετε αυτό, πιθανότατα γνωρίζετε τι είναι το DevOps. Επειδή δεν είμαι. γεια το όνομά μου είναι Αλεξάντερ Τίτοφ (@), και θα μιλήσουμε μόνο για τα DevOps και θα μοιραστώ την εμπειρία μου.
Σκέφτομαι για πολύ καιρό πώς να κάνω την ιστορία μου χρήσιμη, επομένως θα υπάρξουν πολλές ερωτήσεις εδώ - αυτές που κάνω στον εαυτό μου και αυτές που ρωτάω στους πελάτες της εταιρείας μας. Απαντώντας σε αυτές τις ερωτήσεις, η κατανόηση γίνεται καλύτερη. Θα σας πω γιατί χρειάζεται το DevOps από την άποψή μου, τι είναι, πάλι, από την άποψή μου και πώς να καταλάβετε ότι κινείστε ξανά προς το DevOps από την άποψή μου. Το τελευταίο σημείο θα είναι μέσω ερωτήσεων. Απαντώντας μόνοι σας, μπορείτε να καταλάβετε εάν η εταιρεία σας κινείται προς το DevOps ή αν υπάρχουν προβλήματα με κάποιο τρόπο.
Κάποτε οδηγούσα τα κύματα των συγχωνεύσεων και των εξαγορών. Πρώτα, δούλευα για μια μικρή startup που ονομάζεται Qik, στη συνέχεια αγοράστηκε από μια ελαφρώς μεγαλύτερη εταιρεία που ονομάζεται Skype, η οποία στη συνέχεια αγοράστηκε από μια ελαφρώς μεγαλύτερη εταιρεία που ονομάζεται Microsoft. Εκείνη τη στιγμή, άρχισα να βλέπω πώς μεταμορφωνόταν η ιδέα του DevOps σε εταιρείες διαφορετικού μεγέθους. Μετά από αυτό, άρχισα να ενδιαφέρομαι να κοιτάξω το DevOps από την άποψη της αγοράς και με τους συναδέλφους μου ιδρύσαμε την εταιρεία Express 42. Εδώ και 6 χρόνια κινούμαστε στα κύματα της αγοράς.
Μεταξύ άλλων, είμαι ένας από τους διοργανωτές της κοινότητας DevOps Moscow και ο διοργανωτής του DevOps-Days 2017, αλλά δεν οργάνωσα το 2018. Η Express 42 συνεργάζεται με πολλές εταιρείες. Αναπτύσσουμε DevOps εκεί, παρακολουθούμε πώς συμβαίνει, βγάζουμε συμπεράσματα, αναλύουμε, λέμε σε όλους τα συμπεράσματά μας και εκπαιδεύουμε τους ανθρώπους στις πρακτικές DevOps. Σε γενικές γραμμές, κάνουμε ό,τι καλύτερο μπορούμε για να αυξήσουμε την εμπειρία και την εξειδίκευσή μας σε αυτό το θέμα.
Γιατί DevOps
Η πρώτη ερώτηση που στοιχειώνει τους πάντες και πάντα είναι - γιατί; Πολλοί πιστεύουν ότι το DevOps είναι απλώς αυτοματισμός ή κάτι παρόμοιο που είχε ήδη κάθε εταιρεία.
— Είχαμε συνεχή ενσωμάτωση - αυτό σημαίνει ότι είχαμε ήδη DevOps και γιατί χρειάζονται όλα αυτά τα πράγματα; Διασκεδάζουν στο εξωτερικό, αλλά μας εμποδίζουν να δουλέψουμε!
Πάνω από 9 χρόνια ανάπτυξης της κοινότητας και της μεθοδολογίας, έχει γίνει ήδη σαφές ότι αυτό δεν είναι ακόμα γκλίτερ μάρκετινγκ, αλλά δεν είναι ακόμα απολύτως σαφές γιατί χρειάζεται. Όπως κάθε εργαλείο και διαδικασία, το DevOps έχει συγκεκριμένους στόχους που τελικά επιτυγχάνει.
Όλα αυτά οφείλονται στο γεγονός ότι ο κόσμος αλλάζει. Απομακρύνεται από την επιχειρηματική προσέγγιση, όταν οι εταιρείες κινούνται κατευθείαν προς ένα όνειρο, όπως τραγούδησε το κλασικό μας της Αγίας Πετρούπολης, από το σημείο Α στο σημείο Β σύμφωνα με μια συγκεκριμένη στρατηγική, με μια συγκεκριμένη δομή φτιαγμένη για αυτό.
Κατ' αρχήν, τα πάντα στην πληροφορική πρέπει να χτίζονται σύμφωνα με αυτήν την προσέγγιση. Εδώ το IT χρησιμοποιείται αποκλειστικά για την αυτοματοποίηση των διαδικασιών.
Ο αυτοματισμός δεν αλλάζει συχνά, γιατί όταν μια εταιρεία πέφτει σε μια ταλαιπωρημένη, τι μπορεί να αλλάξει; Λειτουργεί - μην το αγγίζετε. Τώρα οι προσεγγίσεις στον κόσμο αλλάζουν και αυτή που ονομάζεται Agile υποδηλώνει ότι το τελικό σημείο Β δεν είναι άμεσα ορατό.
Όταν μια εταιρεία περνάει από την αγορά, συνεργάζεται με έναν πελάτη, εξερευνά συνεχώς την αγορά και αλλάζει το τελικό σημείο Β. Επιπλέον, όσο πιο συχνά η εταιρεία αλλάζει κατεύθυνση, τόσο πιο επιτυχημένη είναι τελικά, γιατί επιλέγει περισσότερη αγορά κόγχες.
Η στρατηγική αποδεικνύεται από μια ενδιαφέρουσα εταιρεία για την οποία έμαθα πρόσφατα. Το One Box Shave είναι μια συνδρομητική υπηρεσία παράδοσης ξυραφιών και αξεσουάρ ξυρίσματος σε κουτί. Ξέρουν πώς να προσαρμόζουν το "κουτί" τους για διαφορετικούς πελάτες. Αυτό γίνεται από ένα συγκεκριμένο λογισμικό, το οποίο στη συνέχεια στέλνει την παραγγελία στο κορεατικό εργοστάσιο που παράγει τα προϊόντα.
Αυτό το προϊόν αγοράστηκε από την Unilever για 1 δισεκατομμύριο δολάρια. Πλέον ανταγωνίζεται τη Gillette και έχει αφαιρέσει σημαντικό μερίδιο καταναλωτών στην αμερικανική αγορά. Το One Box Shave λέει:
— 4 λεπίδες; Εισαι σοβαρος? Γιατί το χρειάζεστε - δεν βελτιώνει την ποιότητα του ξυρίσματος. Μια ειδικά επιλεγμένη κρέμα, άρωμα και ένα υψηλής ποιότητας ξυράφι με δύο λεπίδες λύνουν πολύ περισσότερα προβλήματα από αυτές τις ηλίθιες 4 λεπίδες Gillette! Θα φτάσουμε σύντομα στους 10;
Έτσι αλλάζει ο κόσμος. Η Unilever ισχυρίζεται ότι έχει ένα ωραίο σύστημα πληροφορικής που σας επιτρέπει να το κάνετε αυτό. Στο τέλος μοιάζει με concept Χρόνος στην αγορά, για το οποίο κανείς δεν έχει ήδη μιλήσει.
Το θέμα του Time-to-market δεν είναι πόσο συχνά αναπτύσσουμε. Μπορείτε συχνά να αναπτύξετε, αλλά οι κύκλοι απελευθέρωσης θα είναι μεγάλοι. Εάν οι τρίμηνοι κύκλοι κυκλοφορίας υπερτίθενται ο ένας στον άλλο, μετατοπίζοντάς τους κατά μία εβδομάδα, αποδεικνύεται ότι η εταιρεία φαίνεται να αναπτύσσει μία φορά την εβδομάδα. Και από την ιδέα μέχρι την τελική υλοποίηση χρειάζονται 3 μήνες.
Το Time-to-market αφορά την ελαχιστοποίηση του χρόνου από την ιδέα μέχρι την τελική υλοποίηση.
Σε αυτή την περίπτωση, το λογισμικό αλληλεπιδρά με την αγορά. Αυτός είναι ο τρόπος με τον οποίο ο ιστότοπος One Box Shave αλληλεπιδρά με τον πελάτη. Δεν έχουν πωλητές - απλώς έναν ιστότοπο όπου οι επισκέπτες κάνουν κλικ και αφήνουν ευχές. Κατά συνέπεια, κάτι νέο πρέπει να δημοσιεύεται συνεχώς στον ιστότοπο και να ενημερώνεται σύμφωνα με τις επιθυμίες. Για παράδειγμα, στη Νότια Κορέα ξυρίζονται διαφορετικά από ό,τι στη Ρωσία και τους αρέσει το άρωμα όχι του πεύκου, αλλά, για παράδειγμα, των καρότων και της βανίλιας.
Δεδομένου ότι είναι απαραίτητο να αλλάξετε γρήγορα το περιεχόμενο του ιστότοπου, η ανάπτυξη λογισμικού αλλάζει πολύ. Μέσα από το λογισμικό πρέπει να μάθουμε τι θέλει ο πελάτης. Προηγουμένως, το μάθαμε αυτό μέσω ορισμένων κυκλικών τρόπων, για παράδειγμα, μέσω της διαχείρισης επιχειρήσεων. Στη συνέχεια το σχεδιάσαμε, βάλαμε τις απαιτήσεις στο σύστημα πληροφορικής και όλα ήταν ωραία. Τώρα είναι διαφορετικά - το λογισμικό σχεδιάζεται από όλους όσους εμπλέκονται στη διαδικασία, συμπεριλαμβανομένων των μηχανικών, επειδή μέσω των τεχνικών προδιαγραφών μαθαίνουν πώς λειτουργεί η αγορά και μοιράζονται επίσης τις γνώσεις τους με την επιχείρηση.
Για παράδειγμα, στο Qik ξαφνικά μάθαμε ότι στους ανθρώπους άρεσε πολύ να ανεβάζουν λίστες επαφών στον διακομιστή και μας προμήθευσαν μια εφαρμογή. Στην αρχή δεν το σκεφτήκαμε. Σε μια κλασική εταιρεία, όλοι θα είχαν αποφασίσει ότι αυτό ήταν ένα σφάλμα, καθώς η προδιαγραφή δεν έλεγε ότι θα έπρεπε να λειτουργεί τέλεια και γενικά εφαρμόστηκε στο γόνατο, θα είχαν απενεργοποιήσει τη λειτουργία και θα έλεγαν: "Κανείς δεν χρειάζεται αυτό, το πιο σημαντικό είναι ότι λειτουργεί η κύρια λειτουργικότητα.» . Και η εταιρεία τεχνολογίας το βλέπει αυτό ως ευκαιρία και αρχίζει να αλλάζει το λογισμικό σύμφωνα με αυτό.
Το 1968, ένας οραματιστής, ο Μέλβιν Κόνγουεϊ, διατύπωσε την ακόλουθη ιδέα.
Ο οργανισμός που δημιουργεί το σύστημα περιορίζεται από ένα σχέδιο που αναπαράγει τη δομή επικοινωνίας αυτού του οργανισμού.
Πιο αναλυτικά, για να παράγεις συστήματα διαφορετικού τύπου, πρέπει να έχεις και δομή επικοινωνίας μέσα σε εταιρεία διαφορετικού τύπου. Εάν η δομή επικοινωνίας σας είναι κορυφαία ιεραρχική, τότε αυτό δεν θα σας επιτρέψει να δημιουργήσετε συστήματα που μπορούν να παρέχουν έναν πολύ υψηλό δείκτη Χρόνου στην Αγορά.
Ανάγνωση μπορεί κανείς να . Είναι σημαντικό για την κατανόηση της κουλτούρας ή της φιλοσοφίας του DevOps γιατί το μόνο πράγμα που αλλάζει ριζικά στο DevOps είναι η δομή της επικοινωνίας μεταξύ των ομάδων.
Από τη σκοπιά της διαδικασίας, πριν από το DevOps, όλα τα στάδια: ανάλυση, ανάπτυξη, δοκιμή, λειτουργία, ήταν γραμμικά.
Στην περίπτωση των DevOps, όλες αυτές οι διεργασίες συμβαίνουν ταυτόχρονα.
Ο χρόνος για την αγορά είναι ο μόνος τρόπος που μπορεί να γίνει. Για τους ανθρώπους που δούλευαν στην παλιά διαδικασία, αυτό φαίνεται κάπως κοσμικό, και γενικά έτσι.
Γιατί λοιπόν χρειάζεστε τα DevOps;
Για την ανάπτυξη ψηφιακών προϊόντων. Εάν η εταιρεία σας δεν διαθέτει ψηφιακό προϊόν, δεν χρειάζεται DevOps - είναι πολύ σημαντικό.
Το DevOps ξεπερνά τους περιορισμούς ταχύτητας της διαδοχικής παραγωγής λογισμικού. Σε αυτό όλες οι διαδικασίες συμβαίνουν ταυτόχρονα.
Η δυσκολία αυξάνεται. Όταν οι ευαγγελιστές του DevOps σας λένε ότι θα σας διευκολύνουν να κυκλοφορήσετε λογισμικό, αυτό είναι ανοησία.
Με το DevOps, τα πράγματα θα γίνουν πιο περίπλοκα.
Στο συνέδριο στο περίπτερο της Avito, θα μπορούσατε να δείτε πώς ήταν να αναπτύσσετε ένα κοντέινερ Docker - μια μη ρεαλιστική εργασία. Η πολυπλοκότητα γίνεται απαγορευτική· πρέπει να ταχυδακτυλουργήσετε πολλές μπάλες ταυτόχρονα.
Το DevOps αλλάζει εντελώς τη διαδικασία και την οργάνωση στην εταιρεία — πιο συγκεκριμένα, δεν αλλάζει το DevOps, αλλά το ψηφιακό προϊόν. Για να έρθετε στο DevOps, πρέπει να αλλάξετε εντελώς αυτήν τη διαδικασία.
Ερωτήσεις για έναν ειδικό
Τί έχεις? Ερωτήσεις που μπορείτε να κάνετε στον εαυτό σας όσο εργάζεστε σε μια εταιρεία και εξελίσσεστε ως ειδικός.
Έχετε στρατηγική για τη δημιουργία ενός ψηφιακού προϊόντος; Αν υπάρχει, αυτό είναι ήδη καλό. Αυτό σημαίνει ότι η εταιρεία σας κινείται προς το DevOps.
Η εταιρεία σας δημιουργεί ήδη ένα ψηφιακό προϊόν; Αυτό σημαίνει ότι μπορείτε να ανεβείτε άλλο ένα επίπεδο υψηλότερα και να κάνετε πράγματα πιο ενδιαφέροντα – και πάλι από την άποψη του DevOps. Μιλάω μόνο από αυτή την άποψη.
Είναι η εταιρεία σας ένας από τους ηγέτες της αγοράς στον τομέα των ψηφιακών προϊόντων; Οι Spotify, Yandex, Uber είναι εταιρείες που βρίσκονται στο απόγειο της τεχνολογικής προόδου τώρα.
Κάντε αυτές τις ερωτήσεις στον εαυτό σας και αν όλες οι απαντήσεις είναι αρνητικές, τότε ίσως δεν πρέπει να κάνετε DevOps σε αυτήν την εταιρεία. Εάν το θέμα του DevOps είναι πραγματικά ενδιαφέρον για εσάς, ίσως... θα έπρεπε να μετακομίσετε σε άλλη εταιρεία; Εάν η εταιρεία σας θέλει να πάει στο DevOps, αλλά απαντήσατε «Όχι» σε όλες τις ερωτήσεις, τότε είναι σαν αυτόν τον όμορφο ρινόκερο που δεν θα αλλάξει ποτέ.
Οργάνωση
Όπως είπα, σύμφωνα με το νόμο του Conway, η οργάνωση μιας εταιρείας αλλάζει. Θα ξεκινήσω με αυτό που εμποδίζει τα DevOps να διεισδύσουν στο εσωτερικό της εταιρείας από οργανωτική άποψη.
Το πρόβλημα των «πηγαδιών»
Η αγγλική λέξη "Silo" μεταφράζεται εδώ στα ρωσικά ως "καλά". Η ουσία αυτού του προβλήματος είναι ότι δεν υπάρχει ανταλλαγή πληροφοριών μεταξύ των ομάδων. Κάθε ομάδα σκάβει βαθιά στην τεχνογνωσία της, χωρίς να δημιουργεί έναν κοινό χάρτη για πλοήγηση.
Κατά κάποιο τρόπο αυτό μου θυμίζει ένα άτομο που μόλις έφτασε στη Μόσχα και δεν ξέρει ακόμα πώς να πλοηγηθεί στον χάρτη του μετρό. Οι Μοσχοβίτες συνήθως γνωρίζουν πολύ καλά την περιοχή τους και σε όλη τη Μόσχα μπορούν να πλοηγηθούν χρησιμοποιώντας τον χάρτη του μετρό. Όταν έρχεστε στη Μόσχα για πρώτη φορά, δεν έχετε αυτή την ικανότητα και απλώς αποπροσανατολίζεστε.
Το DevOps προτείνει να ξεπεράσετε αυτή τη στιγμή αποπροσανατολισμού και όλα τα τμήματα να συνεργαστούν για να δημιουργήσουν έναν κοινό χάρτη αλληλεπίδρασης.
Δύο παράγοντες εμποδίζουν αυτό.
Συνέπεια του συστήματος εταιρικής διαχείρισης. Είναι χτισμένο σε ξεχωριστά ιεραρχικά «πηγάδια». Για παράδειγμα, υπάρχουν ορισμένοι KPI σε εταιρείες που υποστηρίζουν αυτό το σύστημα. Από την άλλη πλευρά, ο εγκέφαλος ενός ατόμου που δυσκολεύεται να υπερβεί τα όρια της τεχνογνωσίας του και να περιηγηθεί σε ολόκληρο το σύστημα παρεμποδίζει. Είναι απλά άβολο. Φανταστείτε ότι βρίσκεστε στο αεροδρόμιο της Μπανγκόκ - δεν θα βρείτε τον δρόμο σας γρήγορα. Το DevOps είναι επίσης δύσκολο στην πλοήγηση, και γι' αυτό οι άνθρωποι λένε ότι πρέπει να βρείτε έναν οδηγό για να φτάσετε εκεί.
Αλλά το πιο σημαντικό είναι ότι το πρόβλημα των «πηγαδιών» για έναν μηχανικό που είναι εμποτισμένος με το πνεύμα των DevOps, έχει διαβάσει τον Fowler και ένα σωρό άλλα βιβλία, εκφράζεται στο γεγονός ότι Τα «πηγαδάκια» δεν σου επιτρέπουν να κάνεις «προφανή» πράγματα. Συχνά μαζευόμαστε μετά το DevOps Moscow, μιλάμε μεταξύ μας και οι άνθρωποι παραπονιούνται:
— Θέλαμε απλώς να ξεκινήσουμε το CI, αλλά αποδείχθηκε ότι η διοίκηση δεν το χρειαζόταν.
Αυτό συμβαίνει ακριβώς επειδή CI и Διαδικασία συνεχούς παράδοσης βρίσκονται στα όρια πολλών εξετάσεων. Απλά χωρίς να ξεπεράσετε το πρόβλημα των «πηγαδιών» σε οργανωτικό επίπεδο, δεν θα μπορέσετε να προχωρήσετε, ό,τι κι αν κάνετε και όσο λυπηρό κι αν είναι.
Κάθε συμμετέχων στη διαδικασία στην εταιρεία: προγραμματιστές backend και frontend, δοκιμές, DBA, λειτουργία, δίκτυο, σκάβει προς τη δική του κατεύθυνση και κανείς δεν έχει κοινό χάρτη εκτός από τον διαχειριστή, ο οποίος με κάποιο τρόπο τους παρακολουθεί και τους διαχειρίζεται χρησιμοποιώντας το "divide και κατακτώ» μέθοδο.
Οι άνθρωποι παλεύουν για μερικά αστέρια ή σημαίες, όλοι σκάβουν την πείρα τους.
Ως αποτέλεσμα, όταν προκύπτει το καθήκον να συνδέσουμε όλα αυτά μαζί και να χτίσουμε έναν κοινό αγωγό, και δεν υπάρχει πλέον καμία ανάγκη να παλεύουμε για αστέρια και σημαίες, τίθεται το ερώτημα - τι να κάνουμε τέλος πάντων; Πρέπει να καταλήξουμε σε συμφωνία με κάποιο τρόπο, αλλά κανείς δεν μας έμαθε πώς να το κάνουμε αυτό στο σχολείο. Μας διδάσκουν από το σχολείο: όγδοη δημοτικού - ουάου! - σε σύγκριση με την έβδομη τάξη! Το ίδιο είναι και εδώ.
Είναι το ίδιο και στην εταιρεία σας;
Για να το ελέγξετε αυτό, μπορείτε να κάνετε στον εαυτό σας τις ακόλουθες ερωτήσεις.
Χρησιμοποιούν οι ομάδες κοινά εργαλεία και συμβάλλουν σε αλλαγές σε αυτά τα κοινά εργαλεία;
Πόσο συχνά αναδιοργανώνονται οι ομάδες—ορισμένοι ειδικοί από μια ομάδα μετακινούνται σε άλλη ομάδα; Σε ένα περιβάλλον DevOps αυτό γίνεται φυσιολογικό, επειδή μερικές φορές ένα άτομο απλά δεν μπορεί να καταλάβει τι κάνει ένας άλλος τομέας εμπειρογνωμοσύνης. Μετακομίζει σε άλλο τμήμα, εργάζεται εκεί για δύο εβδομάδες για να δημιουργήσει για τον εαυτό του έναν χάρτη προσανατολισμού και αλληλεπίδρασης με αυτό το τμήμα.
Είναι δυνατόν να σχηματιστεί μια επιτροπή αλλαγής και να αλλάξουν τα πράγματα; Ή μήπως απαιτεί το δυνατό χέρι της ανώτατης διοίκησης και διεύθυνσης; Πρόσφατα έγραψα στο Facebook πώς μια ελάχιστα γνωστή τράπεζα εφαρμόζει εργαλεία μέσω παραγγελιών: γράφουμε μια παραγγελία, την υλοποιούμε για ένα χρόνο και βλέπουμε τι θα συμβεί. Αυτό, φυσικά, είναι μακρύ και λυπηρό.
Πόσο σημαντικό είναι για τους διευθυντές να λαμβάνουν προσωπικά επιτεύγματα χωρίς να υπολογίζουν τα επιτεύγματα της εταιρείας;
Εάν απαντήσετε μόνοι σας σε αυτές τις ερωτήσεις, θα γίνει πιο ξεκάθαρο αν έχετε τέτοιο πρόβλημα στην εταιρεία σας.
Η υποδομή ως κωδικός
Αφού ξεπεραστεί αυτό το πρόβλημα, η πρώτη σημαντική πρακτική, χωρίς την οποία είναι δύσκολο να προχωρήσουμε περαιτέρω στο DevOps, είναι υποδομή ως κωδικός.
Τις περισσότερες φορές, η υποδομή ως κώδικας γίνεται αντιληπτή ως εξής:
— Ας αυτοματοποιήσουμε τα πάντα στο bash, ας καλυφθούμε με σενάρια ώστε οι διαχειριστές να έχουν λιγότερη χειρωνακτική εργασία!
Αλλά αυτό δεν είναι αλήθεια.
Η υποδομή ως κώδικας σημαίνει ότι περιγράφετε το σύστημα πληροφορικής με το οποίο εργάζεστε με τη μορφή κώδικα για να κατανοείτε συνεχώς την κατάστασή του.
Μαζί με άλλες ομάδες, δημιουργείτε έναν χάρτη με τη μορφή κώδικα που όλοι μπορούν να κατανοήσουν και μπορούν να πλοηγηθούν και να πλοηγηθούν. Δεν έχει σημασία σε τι γίνεται - Chef, Ansible, Salt ή χρησιμοποιώντας αρχεία YAML στο Kubernetes - δεν υπάρχει διαφορά.
Στο συνέδριο, ένας συνάδελφος από το 2GIS είπε πώς έφτιαξαν το δικό τους εσωτερικό πράγμα για το Kubernetes, το οποίο περιγράφει τη δομή μεμονωμένων συστημάτων. Για να περιγράψουν 500 συστήματα, χρειάζονταν ένα ξεχωριστό εργαλείο που να δημιουργεί αυτήν την περιγραφή. Όταν υπάρχει αυτή η περιγραφή, όλοι μπορούν να ελέγξουν μεταξύ τους, να παρακολουθήσουν τις αλλαγές, πώς να την αλλάξουν και να τη βελτιώσουν, τι λείπει.
Συμφωνώ, τα μεμονωμένα σενάρια bash συνήθως δεν παρέχουν αυτήν την κατανόηση. Σε μια από τις εταιρείες όπου δούλευα, υπήρχε ακόμη και ένα όνομα για το σενάριο "μόνο εγγραφή" - όταν γράφεται το σενάριο, αλλά δεν είναι πλέον δυνατό να το διαβάσω. Νομίζω ότι αυτό είναι γνωστό και σε εσάς.
Η υποδομή ως κωδικός είναι κώδικα που περιγράφει την τρέχουσα κατάσταση της υποδομής. Πολλές ομάδες προϊόντων, υποδομών και υπηρεσιών συνεργάζονται σε αυτόν τον κώδικα και το πιο σημαντικό, πρέπει όλες να κατανοήσουν πώς λειτουργεί πραγματικά αυτός ο κώδικας.
Ο κώδικας διατηρείται σύμφωνα με τις βέλτιστες πρακτικές κώδικα: κοινή ανάπτυξη, αναθεώρηση κώδικα, προγραμματισμός XP, δοκιμές, αιτήματα έλξης, CI για υποδομές κώδικα - όλα αυτά είναι κατάλληλα και μπορούν να χρησιμοποιηθούν.
Ο κώδικας γίνεται κοινή γλώσσα για όλους τους μηχανικούς.
Η αλλαγή της υποδομής στον κώδικα δεν απαιτεί πολύ χρόνο. Ναι, ο κωδικός υποδομής μπορεί να έχει και τεχνικό χρέος. Συνήθως οι ομάδες το αντιμετωπίζουν ενάμιση χρόνο αφότου άρχισαν να εφαρμόζουν την «υποδομή ως κώδικας» με τη μορφή ενός σωρού σεναρίων ή ακόμα και του Ansible, τα οποία γράφουν σαν κώδικας σπαγγέτι και ρίχνουν επίσης σενάρια bash στο μείγμα!
Είναι σημαντικό: Αν δεν έχετε δοκιμάσει ακόμα αυτό το υλικό, να το θυμάστε Το Ansible δεν είναι bash! Διαβάστε προσεκτικά την τεκμηρίωση, μελετήστε τι γράφουν σχετικά.
Η υποδομή ως κώδικας είναι ο διαχωρισμός του κώδικα υποδομής σε ξεχωριστά επίπεδα.
Στην εταιρεία μας διακρίνουμε 3 βασικά στρώματα, τα οποία είναι πολύ ξεκάθαρα και απλά, αλλά μπορεί να είναι περισσότερα. Μπορείτε να δείτε τον κωδικό υποδομής σας και να πείτε εάν έχετε αυτήν την κατάσταση ή όχι. Εάν δεν επισημαίνονται επίπεδα, τότε πρέπει να αφιερώσετε λίγο χρόνο και να αναδιαμορφώσετε λίγο.
στρώμα βάσης - Αυτός είναι ο τρόπος με τον οποίο διαμορφώνονται το λειτουργικό σύστημα, τα αντίγραφα ασφαλείας και άλλα πράγματα χαμηλού επιπέδου, για παράδειγμα, πώς αναπτύσσεται το Kubernetes σε βασικό επίπεδο.
Επίπεδο εξυπηρέτησης - αυτές είναι οι υπηρεσίες που παρέχετε στον προγραμματιστή: καταγραφή ως υπηρεσία, παρακολούθηση ως υπηρεσία, βάση δεδομένων ως υπηρεσία, εξισορροπητής ως υπηρεσία, ουρά ως υπηρεσία, Συνεχής παράδοση ως υπηρεσία - μια δέσμη υπηρεσιών που συλλέγουν μεμονωμένες ομάδες μπορεί να προσφέρει στην ανάπτυξη. Όλα αυτά πρέπει να περιγράφονται σε ξεχωριστές ενότητες στο σύστημα διαχείρισης διαμόρφωσής σας.
Το στρώμα όπου γίνονται οι εφαρμογές και περιγράφει πώς θα ξεδιπλωθούν πάνω από τα δύο προηγούμενα στρώματα.
Ερωτήσεις ελέγχου
Έχει η εταιρεία σας κοινό αποθετήριο υποδομής; Διαχειρίζεστε τεχνικό χρέος στην υποδομή σας; Χρησιμοποιείτε πρακτικές ανάπτυξης σε ένα αποθετήριο υποδομής; Είναι η υποδομή σας κομμένη σε επίπεδα; Μπορείτε να ελέγξετε το διάγραμμα Base-service-APP. Πόσο δύσκολο είναι να κάνεις μια αλλαγή;
Εάν έχετε βιώσει ότι χρειάστηκε μιάμιση μέρα για να κάνετε αλλαγές, αυτό σημαίνει ότι έχετε τεχνικό χρέος και πρέπει να το δουλέψετε. Μόλις πέσατε πάνω σε μια τεχνική τσουγκράνα χρέους στον κωδικό υποδομής σας. Θυμάμαι πολλές τέτοιες ιστορίες όταν, για να αλλάξετε κάποιο CCTL, πρέπει να ξαναγράψετε τον μισό κώδικα υποδομής, επειδή η δημιουργικότητα και η επιθυμία να αυτοματοποιηθούν τα πάντα οδήγησαν στο γεγονός ότι τα πάντα διαβρώνονται παντού, όλες οι λαβές έχουν αφαιρεθεί και είναι απαραίτητο να αναπαραχθεί.
Συνεχής Παράδοση
Ας συγκρίνουμε τη χρέωση με την πίστωση. Πρώτα ακολουθεί μια περιγραφή της υποδομής, η οποία μπορεί να είναι αρκετά βασική. Δεν χρειάζεται να περιγράψετε τα πάντα με λεπτομέρεια, αλλά απαιτείται κάποια βασική περιγραφή για να μπορέσετε να το δουλέψετε. Διαφορετικά, δεν είναι ξεκάθαρο τι να κάνετε στη συνέχεια με τη συνεχή παράδοση. Όλες αυτές οι πρακτικές εκτυλίσσονται ταυτόχρονα όταν έρχεστε στο DevOps, αλλά ξεκινά με την κατανόηση του τι έχετε και πώς να το διαχειριστείτε. Αυτή ακριβώς είναι η πρακτική της υποδομής ως κώδικα.
Μόλις γίνει σαφές ότι το έχετε και πώς να το διαχειριστείτε, αρχίζετε να καταλαβαίνετε πώς να στείλετε τον κώδικα προγραμματιστή στην παραγωγή όσο το δυνατόν γρηγορότερα. Εννοώ μαζί με τον προγραμματιστή - θυμόμαστε το πρόβλημα των "πηγαδιών", δηλαδή, δεν το σκέφτονται μεμονωμένα άτομα, αλλά μια ομάδα.
Όταν είμαστε μαζί Βάνια Ευτούχοβιτς είδε το πρώτο βιβλίο Jez Humble και ομάδες συγγραφέων "Συνεχής Παράδοση", που κυκλοφόρησε το 2009, σκεφτήκαμε για πολύ καιρό πώς να μεταφράσουμε τον τίτλο του στα ρωσικά. Ήθελαν να το μεταφράσουν ως "Συνεχής παράδοση", αλλά, δυστυχώς, μεταφράστηκε ως "Συνεχής παράδοση". Μου φαίνεται ότι υπάρχει κάτι ρωσικό στο όνομά μας, με πίεση.
Συνεχής παράδοση μέσων
Ο κωδικός που βρίσκεται στο αποθετήριο προϊόντων μπορεί πάντα να μεταφορτωθεί στην παραγωγή. Μπορεί να μην ξεφουσκώνει, αλλά είναι πάντα έτοιμος για αυτό. Αντίστοιχα, γράφετε πάντα κώδικα με ένα δυσνόητο συναίσθημα κάποιου άγχους κάτω από την ουρά σας. Εμφανίζεται συχνά όταν διαθέτετε κωδικό υποδομής. Αυτό το αίσθημα κάποιου άγχους θα πρέπει να υπάρχει - ενεργοποιεί εγκεφαλικές διεργασίες που σας επιτρέπουν να γράφετε κώδικα λίγο διαφορετικά. Αυτό θα πρέπει να καταγράφεται στους κανόνες της ανάπτυξης.
Για να παραδίδετε με συνέπεια, χρειάζεστε μια μορφή τεχνουργήματος που να εκτείνεται σε μια πλατφόρμα υποδομής. Εάν πετάξετε «απόβλητα ζωής» διαφορετικών μορφών σε μια πλατφόρμα υποδομής, τότε γίνεται ενοποιημένη, είναι δύσκολο να διατηρηθεί και προκύπτει το πρόβλημα του τεχνικού χρέους. Η μορφή του τεχνουργήματος πρέπει να ευθυγραμμιστεί - αυτό είναι επίσης ένα συλλογικό έργο: πρέπει όλοι να μαζευτούμε, να θροΐσουμε το μυαλό μας και να καταλήξουμε σε αυτήν τη μορφή.
Το τεχνούργημα βελτιώνεται συνεχώς και αλλάζει για να ταιριάζει στο περιβάλλον παραγωγής καθώς κινείται μέσω του αγωγού παράδοσης. Όταν ένα τεχνούργημα κινείται κατά μήκος του αγωγού, συναντά συνεχώς κάποια πράγματα που του είναι άβολα, τα οποία είναι παρόμοια με αυτά που συναντά το τεχνούργημα που βάζετε στην παραγωγή. Εάν στην κλασική ανάπτυξη αυτό γίνεται από έναν διαχειριστή συστήματος που κάνει το rollout, τότε στη διαδικασία DevOps αυτό συμβαίνει συνέχεια: εδώ το δοκίμασαν με μερικές δοκιμές, εδώ το έριξαν σε ένα σύμπλεγμα Kubernetes, το οποίο είναι λίγο πολύ παρόμοιο στην παραγωγή, τότε ξαφνικά άρχισαν τη δοκιμή φορτίου.
Αυτό θυμίζει κάπως το παιχνίδι Pac-Man - το τεχνούργημα περνάει από κάποιο είδος ιστορίας. Ταυτόχρονα, είναι σημαντικό να ελέγχετε εάν ο κώδικας περνάει πραγματικά από την ιστορία και αν σχετίζεται με κάποιο τρόπο με την παραγωγή σας. Οι ιστορίες από την παραγωγή μπορούν να συρθούν στη διαδικασία Συνεχούς Παράδοσης: ήταν έτσι όταν κάτι έπεφτε, τώρα ας προγραμματίσουμε αυτό το σενάριο μέσα στο σύστημα. Κάθε φορά που ο κώδικας θα περνάει από αυτό το σενάριο και δεν θα αντιμετωπίζετε αυτό το πρόβλημα την επόμενη φορά. Θα το μάθετε πολύ νωρίτερα από ό,τι φτάσει στον πελάτη σας.
Διαφορετικές στρατηγικές ανάπτυξης. Για παράδειγμα, χρησιμοποιείτε δοκιμές AB ή αναπτύξεις καναρίνι για να δοκιμάσετε τον κώδικα διαφορετικά σε διαφορετικούς πελάτες, να λάβετε πληροφορίες σχετικά με τον τρόπο λειτουργίας του κώδικα και πολύ νωρίτερα από ό,τι όταν διατεθεί σε 100 εκατομμύρια χρήστες.
Το "Συνεπής παράδοση" μοιάζει με αυτό.
Η διαδικασία παράδοσης Dev, CI, Test, PreProd, Prod δεν είναι ξεχωριστό περιβάλλον, αυτά είναι στάδια ή σταθμοί με πυρίμαχα ποσά από τα οποία περνά το τεχνούργημα σας.
Εάν έχετε κωδικό υποδομής που περιγράφεται ως Base Service APP τότε βοηθάει μην ξεχνάτε όλα τα σενάριακαι γράψτε τα ως κώδικα για αυτό το τεχνούργημα, προώθηση τεχνουργήματος και αλλάξτε το όσο πηγαίνετε.
Ερωτήσεις αυτοδιαγνωστικού ελέγχου
Ο χρόνος από την περιγραφή του χαρακτηριστικού έως την κυκλοφορία στην παραγωγή στο 95% των περιπτώσεων είναι λιγότερο από μία εβδομάδα; Βελτιώνεται η ποιότητα του αντικειμένου σε κάθε στάδιο του αγωγού; Υπάρχει ιστορία που περνάει; Χρησιμοποιείτε διαφορετικές στρατηγικές ανάπτυξης;
Αν όλες οι απαντήσεις είναι ναι, τότε είσαι απίστευτα cool! Γράψτε τις απαντήσεις σας στα σχόλια - θα χαρώ).
ανατροφοδότηση
Αυτή είναι η πιο δύσκολη πρακτική από όλες. Στο συνέδριο DevOpsConf, ένας συνάδελφος από το Infobip, μιλώντας γι 'αυτό, ήταν λίγο μπερδεμένος στα λόγια του, επειδή αυτή είναι πραγματικά μια πολύ περίπλοκη πρακτική σχετικά με το γεγονός ότι πρέπει να παρακολουθείτε τα πάντα!
Για παράδειγμα, πριν από πολύ καιρό, όταν δούλευα στο Qik και καταλάβαμε ότι έπρεπε να παρακολουθούμε τα πάντα. Το κάναμε αυτό και τώρα έχουμε 150 αντικείμενα στο Zabbix, τα οποία παρακολουθούνται συνεχώς. Ήταν τρομακτικό, ο τεχνικός διευθυντής έστριψε το δάχτυλό του στον κρόταφο:
- Παιδιά, γιατί βιάζετε τον διακομιστή με κάτι ασαφές;
Στη συνέχεια όμως συνέβη ένα περιστατικό που έδειξε ότι αυτή είναι πραγματικά μια πολύ ωραία στρατηγική.
Μία από τις υπηρεσίες άρχισε να συντρίβεται συνεχώς. Αρχικά, δεν συνετρίβη, το οποίο είναι ενδιαφέρον, ο κωδικός δεν προστέθηκε εκεί, επειδή ήταν ένας βασικός μεσίτης, ο οποίος πρακτικά δεν είχε καμία επιχειρηματική λειτουργικότητα - απλώς έστελνε μηνύματα μεταξύ μεμονωμένων υπηρεσιών. Η υπηρεσία δεν άλλαξε για 4 μήνες και ξαφνικά άρχισε να καταρρέει με το σφάλμα "Segmentation fault".
Ήμασταν σοκαρισμένοι, ανοίξαμε τα γραφήματα μας στο Zabbix και αποδείχθηκε ότι πριν από μιάμιση εβδομάδα, η συμπεριφορά των αιτημάτων στην υπηρεσία API που χρησιμοποιεί αυτός ο μεσίτης άλλαξε πολύ. Στη συνέχεια είδαμε ότι η συχνότητα αποστολής ενός συγκεκριμένου τύπου μηνύματος είχε αλλάξει. Αργότερα ανακαλύψαμε ότι αυτοί ήταν πελάτες Android. Ρωτήσαμε:
— Παιδιά, τι σας συνέβη πριν από μιάμιση εβδομάδα;
Σε απάντηση, ακούσαμε μια ενδιαφέρουσα ιστορία για το πώς είχαν επανασχεδιάσει το UI. Είναι απίθανο κάποιος να πει αμέσως ότι άλλαξε τη βιβλιοθήκη HTTP. Για τους πελάτες Android, είναι σαν να αλλάζουν σαπούνι στο μπάνιο - απλώς δεν θυμούνται. Ως αποτέλεσμα, μετά από 40 λεπτά συνομιλίας, ανακαλύψαμε ότι είχαν αλλάξει τη βιβλιοθήκη HTTP και οι προεπιλεγμένοι χρονισμοί της είχαν αλλάξει. Αυτό οδήγησε στην αλλαγή της συμπεριφοράς της κυκλοφορίας στον διακομιστή API, η οποία οδήγησε σε μια κατάσταση που προκάλεσε αγώνα εντός του μεσίτη και άρχισε να καταρρέει.
Χωρίς βαθιά παρακολούθηση είναι γενικά αδύνατο να ανοίξει αυτό. Εάν ο οργανισμός εξακολουθεί να έχει το πρόβλημα των «πηγαδιών», όταν όλοι ρίχνουν χρήματα ο ένας στον άλλο, αυτό μπορεί να επιβιώσει για χρόνια. Απλώς κάνετε επανεκκίνηση του διακομιστή γιατί είναι αδύνατο να λυθεί το πρόβλημα. Όταν παρακολουθείτε, παρακολουθείτε, παρακολουθείτε όλα τα συμβάντα που έχετε και χρησιμοποιείτε την παρακολούθηση ως δοκιμή - γράφετε κώδικα και υποδεικνύετε αμέσως πώς να τον παρακολουθείτε, επίσης με τη μορφή κώδικα (έχουμε ήδη την υποδομή ως κωδικό), όλα γίνονται ξεκάθαρα πώς στην παλάμη. Ακόμη και τέτοια περίπλοκα προβλήματα εντοπίζονται εύκολα.
Συλλέξτε όλες τις πληροφορίες σχετικά με το τι συμβαίνει με το τεχνούργημα σε κάθε στάδιο της διαδικασίας παράδοσης - όχι στην παραγωγή.
Ανεβάστε την παρακολούθηση στο CI και κάποια βασικά πράγματα θα είναι ήδη ορατά εκεί. Αργότερα θα τα δείτε στο Test, στο PredProd και στη δοκιμή φόρτωσης. Συλλέξτε πληροφορίες σε όλα τα στάδια, όχι μόνο μετρήσεις, στατιστικά στοιχεία, αλλά και αρχεία καταγραφής: πώς κυκλοφόρησε η εφαρμογή, ανωμαλίες - συλλέξτε τα πάντα.
Διαφορετικά θα είναι δύσκολο να το καταλάβουμε. Είπα ήδη ότι το DevOps είναι πιο περίπλοκο. Για να αντιμετωπίσετε αυτήν την πολυπλοκότητα, πρέπει να έχετε κανονικά αναλυτικά στοιχεία.
Ερωτήσεις για αυτοέλεγχο
Είναι η παρακολούθηση και η καταγραφή σας το εργαλείο ανάπτυξης για εσάς; Όταν γράφετε κώδικα, οι προγραμματιστές σας, συμπεριλαμβανομένου εσάς, σκέφτονται πώς να τον παρακολουθούν;
Ακούτε για προβλήματα από πελάτες; Κατανοείτε καλύτερα τον πελάτη από την παρακολούθηση και την καταγραφή; Καταλαβαίνετε το σύστημα καλύτερα από την παρακολούθηση και την καταγραφή; Αλλάζεις σύστημα απλά επειδή είδες ότι η τάση στο σύστημα μεγαλώνει και καταλαβαίνεις ότι σε άλλες 3 εβδομάδες όλα θα πεθάνουν;
Αφού έχετε αυτά τα τρία στοιχεία, μπορείτε να σκεφτείτε τι είδους πλατφόρμα υποδομής έχετε στην εταιρεία σας.
Πλατφόρμα υποδομής
Το θέμα δεν είναι ότι είναι ένα σύνολο ανόμοιων εργαλείων που διαθέτει κάθε εταιρεία.
Το νόημα μιας πλατφόρμας υποδομής είναι ότι όλες οι ομάδες χρησιμοποιούν αυτά τα εργαλεία και τα αναπτύσσουν μαζί.
Είναι σαφές ότι υπάρχουν ξεχωριστές ομάδες που είναι υπεύθυνες για την ανάπτυξη μεμονωμένων κομματιών της πλατφόρμας υποδομής. Αλλά ταυτόχρονα, κάθε μηχανικός φέρει την ευθύνη για την ανάπτυξη, την απόδοση και την προώθηση της πλατφόρμας υποδομής. Σε εσωτερικό επίπεδο γίνεται κοινό εργαλείο.
Όλες οι ομάδες αναπτύσσουν την πλατφόρμα υποδομής και τη αντιμετωπίζουν με προσοχή ως το δικό τους IDE. Στο IDE σας εγκαθιστάτε διαφορετικά πρόσθετα για να τα κάνετε όλα ωραία και γρήγορα και να διαμορφώνετε τα πλήκτρα πρόσβασης. Όταν ανοίγετε το Sublime, το Atom ή το Visual Studio Code, κατακλύζονται σφάλματα κώδικα και συνειδητοποιείτε ότι είναι αδύνατο να λειτουργήσετε καθόλου, αισθάνεστε αμέσως στεναχώρια και τρέχετε να διορθώσετε το IDE σας.
Αντιμετωπίστε την πλατφόρμα υποδομής σας με τον ίδιο τρόπο. Εάν καταλαβαίνετε ότι κάτι δεν πάει καλά με αυτό, αφήστε ένα αίτημα εάν δεν μπορείτε να το διορθώσετε μόνοι σας. Αν υπάρχει κάτι απλό, επεξεργαστείτε το μόνοι σας, στείλτε αίτημα έλξης, τα παιδιά θα το εξετάσουν και θα το προσθέσουν. Αυτή είναι μια ελαφρώς διαφορετική προσέγγιση για τα εργαλεία μηχανικής στο κεφάλι του προγραμματιστή.
Η πλατφόρμα υποδομής εξασφαλίζει τη μεταφορά του αντικειμένου από την ανάπτυξη στον πελάτη με συνεχή βελτίωση της ποιότητας. Η IP είναι προγραμματισμένη με ένα σύνολο ιστοριών που συμβαίνουν στον κώδικα στην παραγωγή. Με τα χρόνια ανάπτυξης, υπάρχουν πολλές από αυτές τις ιστορίες, μερικές από αυτές είναι μοναδικές και αφορούν μόνο εσάς - δεν μπορούν να αναζητηθούν στο Google.
Σε αυτό το σημείο, η πλατφόρμα υποδομής γίνεται το ανταγωνιστικό σας πλεονέκτημα, επειδή έχει κάτι ενσωματωμένο που δεν είναι στο εργαλείο του ανταγωνιστή. Όσο πιο βαθιά η IP σας, τόσο μεγαλύτερο είναι το ανταγωνιστικό σας πλεονέκτημα όσον αφορά το Time-to-market. Εμφανίζεται εδώ πρόβλημα κλειδώματος πωλητή: Μπορείτε να πάρετε την πλατφόρμα κάποιου άλλου, αλλά χρησιμοποιώντας την εμπειρία κάποιου άλλου, δεν θα καταλάβετε πόσο σχετική είναι για εσάς. Ναι, δεν μπορεί κάθε εταιρεία να δημιουργήσει μια πλατφόρμα όπως η Amazon. Αυτή είναι μια δύσκολη γραμμή όπου η εμπειρία της εταιρείας είναι σχετική με τη θέση της στην αγορά και δεν μπορείτε να χρησιμοποιήσετε μια κλειδαριά πωλητή εκεί. Αυτό είναι επίσης σημαντικό να το σκεφτούμε.
Το σχέδιο
Αυτό είναι ένα βασικό διάγραμμα μιας πλατφόρμας υποδομής που θα σας βοηθήσει να ρυθμίσετε όλες τις πρακτικές και τις διαδικασίες σε μια εταιρεία DevOps.
Ας δούμε από τι αποτελείται.
Σύστημα ενορχήστρωσης πόρων, το οποίο παρέχει CPU, μνήμη, δίσκο σε εφαρμογές και άλλες υπηρεσίες. Πανω απο αυτο - υπηρεσίες χαμηλού επιπέδου: παρακολούθηση, καταγραφή, CI/CD Engine, αποθήκευση αντικειμένων, υποδομή ως κωδικός συστήματος.
Υπηρεσίες ανώτερου επιπέδου: βάση δεδομένων ως υπηρεσία, ουρές ως υπηρεσία, Υπόλοιπο φόρτωσης ως υπηρεσία, αλλαγή μεγέθους εικόνας ως υπηρεσία, εργοστάσιο μεγάλων δεδομένων ως υπηρεσία. Πανω απο αυτο - διοχέτευση που παραδίδει συνεχώς τροποποιημένο κώδικα στον πελάτη σας.
Λαμβάνετε πληροφορίες σχετικά με το πώς λειτουργεί το λογισμικό σας για τον πελάτη, το αλλάζετε, παρέχετε ξανά αυτόν τον κωδικό, λαμβάνετε πληροφορίες - και έτσι αναπτύσσετε συνεχώς τόσο την πλατφόρμα υποδομής όσο και το λογισμικό σας.
Στο διάγραμμα, ο αγωγός παράδοσης αποτελείται από πολλά στάδια. Αλλά αυτό είναι ένα σχηματικό διάγραμμα που δίνεται ως παράδειγμα - δεν χρειάζεται να το επαναλάβετε ένα προς ένα. Τα στάδια αλληλεπιδρούν με τις υπηρεσίες σαν να ήταν υπηρεσίες - κάθε τούβλο της πλατφόρμας έχει τη δική του ιστορία: πώς κατανέμονται οι πόροι, πώς εκκινείται η εφαρμογή, λειτουργεί με πόρους, παρακολουθείται και αλλάζει.
Είναι σημαντικό να καταλάβετε ότι κάθε μέρος της πλατφόρμας φέρει μια ιστορία και αναρωτηθείτε τι ιστορία μεταφέρει αυτό το τούβλο, ίσως θα έπρεπε να πεταχτεί και να αντικατασταθεί με μια υπηρεσία τρίτου μέρους. Για παράδειγμα, είναι δυνατόν να εγκαταστήσετε το Okmeter αντί για τούβλο; Ίσως τα παιδιά να έχουν ήδη αναπτύξει αυτήν την τεχνογνωσία πολύ περισσότερο από εμάς. Αλλά ίσως όχι - ίσως έχουμε μοναδική τεχνογνωσία, πρέπει να εγκαταστήσουμε τον Prometheus και να τον αναπτύξουμε περαιτέρω.
Δημιουργία της πλατφόρμας
Αυτή είναι μια πολύπλοκη διαδικασία επικοινωνίας. Όταν έχετε βασικές πρακτικές, ξεκινάτε την επικοινωνία μεταξύ διαφορετικών μηχανικών και ειδικών που αναπτύσσουν απαιτήσεις και πρότυπα και τα αλλάζετε συνεχώς σε διαφορετικά εργαλεία και προσεγγίσεις. Η κουλτούρα που έχουμε στο DevOps είναι σημαντική εδώ.
Με τον πολιτισμό όλα είναι πολύ απλά - έχει να κάνει με τη συνεργασία και την επικοινωνία, δηλαδή η επιθυμία να εργαστούμε σε ένα κοινό πεδίο μεταξύ τους, η επιθυμία να χειριστείτε ένα όργανο μαζί. Δεν υπάρχει επιστήμη πυραύλων εδώ - όλα είναι πολύ απλά, μπανάλ. Για παράδειγμα, όλοι ζούμε στην είσοδο και την κρατάμε καθαρή - τέτοιο επίπεδο πολιτισμού.
Τί έχεις?
Και πάλι, ερωτήσεις που μπορείτε να κάνετε στον εαυτό σας.
Είναι αφιερωμένη η πλατφόρμα υποδομής; Ποιος είναι υπεύθυνος για την ανάπτυξή του; Κατανοείτε τα ανταγωνιστικά πλεονεκτήματα της πλατφόρμας υποδομής σας;
Πρέπει να κάνετε συνεχώς αυτές τις ερωτήσεις στον εαυτό σας. Εάν κάτι μπορεί να μεταφερθεί σε υπηρεσίες τρίτων, θα πρέπει να μεταφερθεί· εάν μια υπηρεσία τρίτου μέρους αρχίσει να εμποδίζει την κίνησή σας, τότε πρέπει να δημιουργήσετε ένα σύστημα μέσα σας.
Λοιπόν, DevOps...
... αυτό είναι ένα πολύπλοκο σύστημα, πρέπει να έχει:
- Ψηφιακό προϊόν.
- Επιχειρηματικές ενότητες που αναπτύσσουν αυτό το ψηφιακό προϊόν.
- Ομάδες προϊόντων που γράφουν κώδικα.
- Πρακτικές συνεχούς παράδοσης.
- Οι πλατφόρμες ως υπηρεσία.
- Η υποδομή ως υπηρεσία.
- Η υποδομή ως κωδικός.
- Ξεχωριστές πρακτικές για τη διατήρηση της αξιοπιστίας, ενσωματωμένες στα DevOps.
- Μια πρακτική ανατροφοδότησης που τα περιγράφει όλα.
Μπορείτε να χρησιμοποιήσετε αυτό το διάγραμμα, επισημαίνοντας σε αυτό αυτό που έχετε ήδη στην εταιρεία σας με κάποια μορφή: έχει αναπτυχθεί ή χρειάζεται ακόμα να αναπτυχθεί.
Θα τελειώσει σε μερικές εβδομάδες . ως μέρος του RIT++. Ελάτε στο συνέδριο, όπου θα βρείτε πολλές ενδιαφέρουσες αναφορές σχετικά με τη συνεχή παράδοση, την υποδομή ως κώδικα και τον μετασχηματισμό DevOps. , η τελευταία προθεσμία τιμής είναι η 20η Μαΐου
Πηγή: www.habr.com