Το DevOps δεν είναι ούτε μέθοδος ούτε εργαλείο, είναι πολιτισμός



Το DevOps είναι η πρακτική των μηχανικών λειτουργίας και ανάπτυξης που συμμετέχουν μαζί σε ολόκληρο τον κύκλο ζωής της υπηρεσίας, από το σχεδιασμό έως τη διαδικασία ανάπτυξης έως την υποστήριξη παραγωγής. Η ευελιξία στο σύστημα μπορεί να θεωρηθεί ως κουλτούρα DevOps.

Ο πολιτισμός συχνά αγνοείται και παρεξηγείται, αλλά αποτελεί βασικό παράγοντα υπεύθυνο για την απόδοση μιας εταιρείας. Αν δεν διαχειριστούμε τον πολιτισμό μας, θα καταλήξουμε σε λάθος πρακτικές που τελικά θα επηρεάσουν τους επιχειρηματικούς μας στόχους.

Κατανόηση της τρέχουσας κουλτούρας ενός οργανισμού

Ο πολιτισμός μας λέει για τις αξίες και τους κανόνες μέσα σε μια ομάδα ή μια εταιρεία. Προσδιορίζει τι είναι σημαντικό καθώς και πώς οι άνθρωποι προσεγγίζουν και συνεργάζονται μεταξύ τους.





ΠΟΛΙΤΙΣΜΟΣ = 'Πώς μπορούν τα πράγματα να γίνουν έξυπνα για επιτυχία'

Ας πάρουμε το παράδειγμα μιας ομάδας υποστήριξης πελατών. Η κουλτούρα αυτής της ομάδας πρέπει να είναι τέτοια ώστε να καταλήγουν στο 97-98% της ικανοποίησης των πελατών.



Λαμβάνοντας υπόψη την απόλαυση του πελάτη, πρώτα απ 'όλα πρέπει να είναι ευγενικοί, ακόμη και σε δύσκολες καταστάσεις πρέπει να είναι καλοί ακροατές για να αποφύγουν τη σύγχυση που πρέπει να δώσουν προτεραιότητα στην εργασία σύμφωνα με τις απαιτήσεις.

Ας σταματήσουμε για μια στιγμή και να θέσουμε μερικές ερωτήσεις στους εαυτούς μας:

  • Ποια είναι η κουλτούρα της εταιρείας μου τώρα;
  • Πόσο καλά ευθυγραμμίζεται αυτή η κουλτούρα με τους επιχειρηματικούς μου στόχους ή τις KRA;
  • Ποια προβλήματα μπορώ να περιμένω λόγω κακής ευθυγράμμισης;

Για κάθε οργανισμό, τα 4C διαδραματίζουν ζωτικό ρόλο



4C οργάνωσης

java code to end πρόγραμμα

Τώρα, ας δούμε την κουλτούρα ενός οργανισμού ανάπτυξης λογισμικού. Υπάρχουν πολλές ομάδες που συμμετέχουν για τη δημιουργία και τη συντήρηση μιας ενιαίας μονάδας λογισμικού. Όλες αυτές οι ομάδες έχουν ξεχωριστούς στόχους και ξεχωριστή κουλτούρα.

Αυτή η διαδικασία ξεκινά μετά την επιβεβαίωση των απαιτήσεων από τον πελάτη.

Οι προγραμματιστές ακολουθούν τις οδηγίες κωδικοποίησης που ορίζονται από τον οργανισμό τους και εργαλεία προγραμματισμού όπως μεταγλωττιστές, διερμηνείς, προγράμματα εντοπισμού σφαλμάτων κ.λπ. χρησιμοποιούνται για τη δημιουργία του κώδικα. Για κωδικοποίηση χρησιμοποιούνται διαφορετικές γλώσσες προγραμματισμού υψηλού επιπέδου όπως C, C ++, Pascal, Java και PHP.

Χωρίζουν το πλήρες πακέτο σε μικρούς φακέλους και στη συνέχεια αναπτύσσουν μικρούς κωδικούς ανάλογα.

Στάδιο 1 : Αυτές οι μικρές μονάδες κωδικών στη συνέχεια κλίνουν για να σχηματίσουν μια μεγάλη μονάδα. Ενώ ενσωματώνουμε τις μικρότερες μάρκες, μια δοκιμή σε επίπεδο έργου πρέπει να εκτελείται γνωστή ως δοκιμή ολοκλήρωσης.

Στάδιο 2 : Μετά την επιτυχή ενσωμάτωση, αναπτύσσεται σε ένα εικονικό σύστημα. Αυτό το εικονικό σύστημα έχει παρόμοια διαμόρφωση με εκείνη του υπολογιστή-πελάτη ή του μηχανήματος όπου το έργο πρέπει τελικά να αναπτυχθεί.

Στάδιο 3 : Τέλος, μετά τη δοκιμή όλων των χαρακτηριστικών σε ένα εικονικό σύστημα, το έργο αναπτύσσεται στον διακομιστή παραγωγής ή στον υπολογιστή-πελάτη.

Αν και αυτή η διαδικασία φαίνεται να είναι πολύ ομαλή και εύκολη, με τεχνικούς όρους, είναι πολύ δύσκολο να επιτευχθεί.

Ας δούμε ποια προβλήματα ενδέχεται να αντιμετωπίσουμε:

Στάδιο 1 :

Ο πελάτης αναζητά πάντα αλλαγές για τη βελτίωση της ποιότητας του προϊόντος. Τις περισσότερες φορές όταν έγινε η πρώτη επανάληψη, ο πελάτης θα προτείνει μερικές αλλαγές. Όταν οι προγραμματιστές λάβουν τις αλλαγές, αρχίζουν να τις ενσωματώνουν, οι οποίες επηρεάζουν την ενσωμάτωση που οδηγεί σε κατεστραμμένες κατασκευές.

Στάδιο 2:

Τις περισσότερες φορές, οι υπεύθυνοι δοκιμών ή άλλοι χειριστές δεν θα γνωρίζουν τις νέες αλλαγές που θα γίνουν. Μόλις λάβουν τον κωδικό από προγραμματιστές, αρχίζουν να τους δοκιμάζουν. Ενώ στο back-end οι προγραμματιστές εξακολουθούν να κάνουν τις αλλαγές.

Δεδομένου ότι δεν έχουν αρκετό χρόνο για να εφαρμόσουν νέες αλλαγές, καταλήγουν να αναπτύσσουν αναποτελεσματικούς κωδικούς που αντιμετωπίζουν άλλα ζητήματα δικτύου και βάσης δεδομένων που καθυστερούν και πάλι τον χρόνο παράδοσής τους.

Όταν τελικά παραδίδουν τους κωδικούς στην ομάδα επιχειρήσεων, τους αφήνουν πολύ ελάχιστος χρόνος για τη δημιουργία και την εφαρμογή νέων δοκιμαστικών περιπτώσεων. Έτσι παραλείπουν πολλές από τις δοκιμαστικές περιπτώσεις που συνειδητοποιούν αργότερα ότι αυτές ήταν υψηλής προτεραιότητας.

Στάδιο 3:

Αν και ουσιαστικά η κατασκευή φαίνεται να είναι έτοιμη για παραγωγή, αλλά τα αποτελέσματα είναι εντελώς απροσδόκητα. Η έκδοση αποτυγχάνει και παρουσιάζονται ορισμένα σφάλματα.

Στη συνέχεια, για κάθε σφάλμα που προέκυψε, πρέπει να παρακολουθήσουν γιατί συνέβη αυτό, όπου συνέβη, τι αλλαγές πρέπει να γίνουν για να το ξεπεράσουν, θα υπάρξουν αλλαγές στους κωδικούς άλλων ώστε να είναι συμβατό με τους προηγούμενους. Τέλος, για όλα αυτά τα σφάλματα, πρέπει να δημιουργηθεί μια αναφορά σφαλμάτων.

Η αποτυχία οφείλεται σε σφάλματα συστήματος λόγω της άγνοιας του προγραμματιστή βάσης δεδομένων στην αποτελεσματικότητα του κώδικα, της άγνοιας του δοκιμαστή σε αριθμό δοκιμαστικών περιπτώσεων κ.λπ.

Καθώς ο πελάτης διατηρεί πάντα την προθεσμία, οι εργαζόμενοι που συμμετέχουν στην επίτευξή τους συγκεντρώνονται μόνο στην τελική κυκλοφορία, ακόμη και αν πρέπει να θέσουν σε κίνδυνο τη συνολική ποιότητα.

Αν και αυτό φαίνεται να είναι πρόβλημα στο συντονισμό της εργασίας, Αυτό είναι στην πραγματικότητα η αποτυχία του πολιτισμού που υιοθετήθηκε.

Αυτό συμβαίνει λόγω της μεγάλης εξάρτησης από τις μη αυτόματες διαδικασίες. Το τρέξιμο στην ίδια ομάδα λόγω έλλειψης γνώσεων για διαφορετικό πεδίο έλλειψη πρόσβασης ή μπορεί να είναι έλλειψη ενδιαφέροντος αυξάνει το βάρος και τον πόνο μας.

Είναι καιρός να χρειαστεί να είμαστε ευέλικτοι. Μπορεί να είναι δύσκολο να είσαι ο κύριος όλων των διαδικασιών που εμπλέκονται σε ένα σύστημα, αλλά μπορούμε να είμαστε το jack of all, κυριαρχώντας μία από αυτές. Τότε μόνο μπορούμε να αυτοματοποιήσουμε το σύστημά μας ή να το κάνουμε αρκετά έξυπνο για ανάκτηση και όχι επαναφορά.

Τώρα, ίσως σκέφτεστε γιατί;

φροντιστήριο sql και pl sql

Επειδή, αυτό που κυριαρχείς εξαρτάται σε μεγάλο βαθμό από τους άλλους. Επομένως, για να μάθουμε για το σημείο εξάρτησης, πρέπει να κατανοήσουμε ολόκληρο το σύστημα.

Ας σκεφτούμε λοιπόν μια διαδικασία αλλαγής του πολιτισμού. Πριν από αυτό έχετε την απάντηση στις παρακάτω ερωτήσεις;

  • Πού αποτυγχάνει η τρέχουσα κουλτούρα σας;
  • Γιατί θέλετε να αλλάξετε τη διαδικασία;
  • Έχετε προσδιορίσει με σαφήνεια όλες τις απαιτούμενες αλλαγές;
  • Έχετε λάβει σχόλια και buy-in από όλους τους εμπλεκόμενους μετόχους;
  • Επαληθεύσατε την πειθαρχία της διαδικασίας, τα δεδομένα και το σύστημα μέτρησης για την αλλαγή;

Έτσι, τώρα που έχουμε την απάντηση σε όλους, σκεφτόμαστε μια επανάσταση στο σύστημά μας. Πώς θα πραγματοποιηθεί αυτή η επανάσταση; Αυτό μπορεί να επιτευχθεί μόνο όταν σκοτώσουμε αυτό που είμαστε τώρα. Πολύς χρόνος χάνεται στη μετεγκατάσταση κώδικα μεταξύ των ομάδων. Πρέπει να φέρουμε τη διαδικασία όπου μπορούμε να κάνουμε συνεχή ολοκλήρωση και συνεχή ανάπτυξη.

Αυτή η διαδικασία συνεχούς ολοκλήρωσης και ανάπτυξης το καθιστά πιο ευέλικτο. Φέρνοντας αυτήν την ευελιξία θεωρείται κουλτούρα DevOps.

Το DevOps είναι η πρακτική των μηχανικών λειτουργίας και ανάπτυξης που συμμετέχουν μαζί σε ολόκληρο τον κύκλο ζωής των υπηρεσιών, από το σχεδιασμό έως τη διαδικασία ανάπτυξης έως την υποστήριξη παραγωγής.

Δεν είναι εύκολο να αλλάξετε το σύστημα εργασίας με την πάροδο του χρόνου. Η επιτυχής μετάβαση είναι η ανακαίνιση του συστήματος και όχι η ανοικοδόμηση.

Τώρα ας δούμε πώς μπορούμε να το επιτύχουμε. Μπορεί να υπάρχουν δύο τρόποι προσέγγισης.

1) Πάνω προς τα κάτω

2) Κάτω προς τα πάνω

Βυθίζοντας σε βάθος αυτές τις τεχνικές, θα συνειδητοποιήσουμε ποια είναι η πιο κατάλληλη για τον οργανισμό μας.

Στην προσέγγιση από πάνω προς τα κάτω, μπορούμε να πάμε στην ανώτερη διοίκηση και να τους ζητήσουμε να κάνουν αλλαγές σε όλες τις ομάδες. Εάν η διεύθυνση είναι πεπεισμένη τότε, μπορούμε να αρχίσουμε να το επεξεργαζόμαστε.

Αλλά η πιθανότητα να λάβετε την απάντηση ως 'ΟΧΙ' είναι αρκετά υψηλή. Επειδή η αλλαγή του συστήματος μπορεί να οδηγήσει τον οργανισμό σε αστάθεια.

Πρέπει να εξετάσουν τη δομή της οργάνωσης, των εσόδων, του επιπέδου ενδιαφέροντος του πελάτη κ.λπ. Αλλά ο πιο σημαντικός παράγοντας που τους αποτρέπει από το να ξεφύγουν από το παλιό σύστημα είναι ότι δεν μπορούν να δουν το μεγάλη εικόνα του τι μπορεί να επιτευχθεί και πόσο ομαλά μπορεί να επιτευχθεί με το νεότερο.

Σε αυτήν την περίπτωση, μπορούμε να αναζητήσουμε τη δεύτερη προσέγγιση για να πάρουμε αυτήν τη μεγάλη εικόνα.

Η προσέγγιση από κάτω προς τα πάνω απαιτεί εθελοντισμό. Εδώ πρέπει να πάρουμε μια μικρή ομάδα και μια μικρή εργασία και να την εκτελέσουμε στο DevOps Model.

Εξετάζοντας την τεχνική πλευρά αυτού του μοντέλου, διαθέτουμε διάφορα σετ εξελιγμένων εργαλείων που κάνουν την εργασία πιο αποτελεσματική και γρήγορη. Όμως, τα εργαλεία από μόνα τους δεν είναι αρκετά ικανά για τη δημιουργία ενός συνεργατικού περιβάλλοντος που αναφέρεται ως DevOps.

Η δημιουργία ενός τέτοιου περιβάλλοντος απαιτεί από εσάς να σκεφτείτε έξω από το κουτί, π.χ. αξιολόγηση και επαναπροσδιορισμό του τρόπου με τον οποίο οι άνθρωποι σκέφτονται για τις ομάδες τους, την επιχείρηση και τους πελάτες.

Η συγκέντρωση ενός νέου συνόλου εργαλείων είναι απλούστερη από την αλλαγή της οργανωτικής κουλτούρας. Προωθώντας τους αντικοινωνικούς κύριους προγραμματιστές, επιτρέποντας την ενσωμάτωση αναποτελεσματικού κώδικα, αναπτύσσοντας κωδικούς που δεν είχαν δοκιμαστεί σωστά, βάζοντας ευθύνες ο ένας στον άλλο, θεωρώντας ότι η ομάδα επιχειρήσεων είναι ηλίθια δεν είναι οι βέλτιστες πρακτικές που ακολουθούμε για να επιτρέψουμε στην επιχείρηση και να δημιουργήσουμε αξία για τους πελάτες μας.

ορισμός διαδρομής κλάσης στο linux

Δεν είναι τα εργαλεία, τα άτομα που τα χρησιμοποιούν που καθιστούν τη διαδικασία πολύπλοκη. Το να πούμε σε αφηρημένο επίπεδο αντί να συλλέγουμε ιδέες και συμπεριφορές, το να είμαστε ανοιχτοί σε αυτές μας οδηγεί σε ένα φωτεινό μονοπάτι.

Ας ξεκινήσουμε με μια ομάδα 6 μελών και μια ιστορία 3 σημείων. Κατ 'αρχάς, πρέπει να σπάσουμε την ομάδα που ονομάζουμε προγραμματιστές, λειτουργίες, δοκιμαστές κ.λπ. Θεωρούμε όλα αυτά ως ένα, λένε «DevOps». Όταν λαμβάνουμε τις απαιτήσεις πρέπει να αναλύσουμε τις ζώνες κινδύνου. Έχοντας κατά νου τα βαθύτερα τμήματα της θάλασσας και του Hellip .. Αρχίζουμε να πλέουμε.

Τώρα, πρέπει να σκεφτείτε «ποιος είναι ο παράγοντας x αυτής της συνεχούς ολοκλήρωσης και συνεχούς ανάπτυξης που μειώνει την πιθανότητα αποτυχίας».

Με το βελτιωμένο όραμα και τη διαδικασία, μπορούμε να προσεγγίσουμε τη διοίκηση θέτοντας τη σαφή εικόνα των αποτελεσμάτων, όπως πόσο ομαλή ήταν η διαδικασία, πώς μειώθηκε ο κίνδυνος αποτυχίας, πώς ολοκληρώθηκε η εργασία πριν από το χρονοδιάγραμμα κ.λπ.

Τώρα, μπορούμε να απεικονίσουμε με σαφήνεια πώς βελτιστοποιήθηκε ολόκληρη η διαδικασία σε τεχνικό και πολιτιστικό έδαφος, έχοντας αναδρομή μετά από κάθε επανάληψη.

Η Edureka έχει επιμεληθεί ειδικά που σας βοηθά να αποκτήσετε γνώσεις γύρω από Puppet, Jenkins, Ansible, SaltStack, Chef μεταξύ άλλων.

Έχετε μια ερώτηση για εμάς; Αναφέρετέ τα στην ενότητα σχολίων και θα επικοινωνήσουμε μαζί σας.

Σχετικές αναρτήσεις: