Γιατί οι μηχανικοί δεν ενδιαφέρονται για την παρακολούθηση εφαρμογών;

Καλή Παρασκευή σε όλους! Φίλοι, σήμερα συνεχίζουμε τη σειρά εκδόσεων αφιερωμένη στο μάθημα "Πρακτικές και εργαλεία DevOps", γιατί τα μαθήματα στη νέα ομάδα για το μάθημα θα ξεκινήσουν στο τέλος της επόμενης εβδομάδας. Λοιπόν, ας ξεκινήσουμε!

Γιατί οι μηχανικοί δεν ενδιαφέρονται για την παρακολούθηση εφαρμογών;

Η παρακολούθηση είναι просто. Αυτό είναι ένα γνωστό γεγονός. Ανεβάστε το Nagios, εκτελέστε το NRPE στο απομακρυσμένο σύστημα, διαμορφώστε το Nagios στη θύρα NRPE TCP 5666 και έχετε παρακολούθηση.

Είναι τόσο εύκολο που δεν είναι ενδιαφέρον. Τώρα έχετε βασικές μετρήσεις για το χρόνο CPU, το υποσύστημα δίσκου, τη μνήμη RAM, που παρέχονται από προεπιλογή στο Nagios και στο NRPE. Αλλά αυτό δεν είναι στην πραγματικότητα «παρακολούθηση» ως τέτοιο. Αυτό είναι μόνο η αρχή.

(Συνήθως εγκαθιστούν τα PNP4Nagios, RRDtool και Thruk, ρυθμίζουν ειδοποιήσεις στο Slack και πηγαίνουν κατευθείαν στο nagiosexchange, αλλά ας το αφήσουμε αυτό προς το παρόν).

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

Είναι δύσκολη η παρακολούθηση;

Οποιοσδήποτε διακομιστής, είτε είναι Linux είτε Windows, εξ ορισμού θα εξυπηρετεί κάποιο σκοπό. Apache, Samba, Tomcat, αποθήκευση αρχείων, LDAP - όλες αυτές οι υπηρεσίες είναι λίγο πολύ μοναδικές από μία ή περισσότερες απόψεις. Το καθένα έχει τη δική του λειτουργία, τα δικά του χαρακτηριστικά. Υπάρχουν διάφοροι τρόποι λήψης μετρήσεων, KPI (βασικοί δείκτες απόδοσης), που σας ενδιαφέρουν όταν ο διακομιστής είναι υπό φόρτωση.

Γιατί οι μηχανικοί δεν ενδιαφέρονται για την παρακολούθηση εφαρμογών;
Συντάκτης της φωτογραφίας Λουκ Σάσερ επί Unsplash

(Μακάρι τα ταμπλό μου να ήταν μπλε νέον - αναστενάζοντας ονειρεμένα -... χμμ...)

Κάθε λογισμικό που παρέχει υπηρεσίες πρέπει να διαθέτει μηχανισμό συλλογής μετρήσεων. Το Apache έχει μια ενότητα mod-status, εμφανίζοντας τη σελίδα κατάστασης διακομιστή. Το Nginx έχει - stub_status. Η Tomcat διαθέτει JMX ή προσαρμοσμένες εφαρμογές ιστού που εμφανίζουν βασικές μετρήσεις. Η MySQL έχει μια εντολή "show global status" κ.λπ.
Γιατί λοιπόν οι προγραμματιστές δεν ενσωματώνουν παρόμοιους μηχανισμούς στις εφαρμογές που δημιουργούν;

Μόνο οι προγραμματιστές το κάνουν αυτό;

Ένα ορισμένο επίπεδο αδιαφορίας για την ενσωμάτωση μετρήσεων δεν περιορίζεται στους προγραμματιστές. Εργάστηκα σε εταιρείες όπου ανέπτυξαν εφαρμογές χρησιμοποιώντας Tomcat και δεν παρείχαν καμία από τις δικές τους μετρήσεις, κανένα αρχείο καταγραφής δραστηριότητας υπηρεσιών, εκτός από τα γενικά αρχεία καταγραφής σφαλμάτων Tomcat. Ορισμένοι προγραμματιστές δημιουργούν πολλά αρχεία καταγραφής που δεν σημαίνουν τίποτα για τον διαχειριστή του συστήματος που δεν έχει την τύχη να τα διαβάσει στις 3:15 το πρωί.

Γιατί οι μηχανικοί δεν ενδιαφέρονται για την παρακολούθηση εφαρμογών;
Συντάκτης της φωτογραφίας Τιμ Γκουβ επί Unsplash

Οι μηχανικοί συστημάτων που επιτρέπουν την κυκλοφορία τέτοιων προϊόντων πρέπει επίσης να φέρουν κάποια ευθύνη για την κατάσταση. Λίγοι μηχανικοί συστημάτων έχουν το χρόνο ή τη φροντίδα να προσπαθήσουν να εξάγουν σημαντικές μετρήσεις από αρχεία καταγραφής, χωρίς το πλαίσιο αυτών των μετρήσεων και τη δυνατότητα να τις ερμηνεύσουν υπό το πρίσμα της δραστηριότητας της εφαρμογής. Κάποιοι δεν καταλαβαίνουν πώς μπορούν να επωφεληθούν από αυτό, εκτός από τους δείκτες «κάτι είναι αυτή τη στιγμή (ή σύντομα θα είναι) λάθος».

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

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

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

Αυτό αναπτύσσει το πράγμα

Η νοοτροπία devops περιγράφει τη συνέργεια μεταξύ της σκέψης ανάπτυξης (dev) και επιχειρησιακών (ops). Κάθε εταιρεία που ισχυρίζεται ότι "κάνει devops" πρέπει:

  1. λέγοντας πράγματα που πιθανώς δεν κάνουν (αναφερόμενος στο μιμίδιο του The Princess Bride - "Δεν νομίζω ότι σημαίνει αυτό που νομίζεις ότι σημαίνει!")
  2. Ενθαρρύνετε μια στάση συνεχούς βελτίωσης του προϊόντος.

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

Αλλαγή αριστερά, ΑΡΙΣΤΕΡΑ, ΕΙΠΑ LEEEE-

Για μένα, μία από τις βασικές αρχές του Devops είναι το "shift left". Μετατόπιση αριστερά σε αυτό το πλαίσιο σημαίνει μετατόπιση της δυνατότητας (καμία ευθύνη, αλλά μόνο δυνατότητες) για να κάνετε πράγματα που συνήθως ενδιαφέρονται οι μηχανικοί συστημάτων, όπως η δημιουργία μετρήσεων απόδοσης, η πιο αποτελεσματική χρήση αρχείων καταγραφής κ.λπ., προς τα αριστερά στον κύκλο ζωής παράδοσης λογισμικού.

Γιατί οι μηχανικοί δεν ενδιαφέρονται για την παρακολούθηση εφαρμογών;
Συντάκτης της φωτογραφίας NESA από τους Makers επί Unsplash

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

Σύντομα μιλώντας

  1. Οδηγήστε το άλογό σας στο νερό. Δείξτε στους προγραμματιστές πόσα προβλήματα μπορούν να αποφύγουν για τους εαυτούς τους, βοηθήστε τους να εντοπίσουν τα σωστά KPI και μετρήσεις για τις εφαρμογές τους, έτσι ώστε να υπάρχουν λιγότερες κραυγές από τον κάτοχο του προϊόντος που φωνάζει από τον ΚΟΤ. Φέρτε τα στο φως, απαλά και ήρεμα. Εάν αυτό δεν λειτουργήσει, τότε δωροδοκήστε, απειλήστε και παρακινήστε είτε αυτούς είτε τον ιδιοκτήτη του προϊόντος να εφαρμόσει τη λήψη αυτών των μετρήσεων από τις εφαρμογές όσο το δυνατόν γρηγορότερα και, στη συνέχεια, σχεδιάστε τα διαγράμματα. Αυτό θα είναι δύσκολο, καθώς δεν θα θεωρείται προτεραιότητα και ο οδικός χάρτης προϊόντων θα έχει πολλά έργα που παράγουν έσοδα σε εκκρεμότητα. Επομένως, θα χρειαστείτε μια επιχειρηματική υπόθεση για να δικαιολογήσετε τον χρόνο και τα έξοδα που δαπανήθηκαν για την εφαρμογή της παρακολούθησης στο προϊόν.
  2. Βοηθήστε τους μηχανικούς συστημάτων να κοιμούνται καλά. Δείξτε τους ότι η χρήση μιας λίστας ελέγχου "ας απελευθερώσουμε" για οποιοδήποτε προϊόν που κυκλοφορεί είναι καλό. Και το να βεβαιωθείτε ότι όλες οι εφαρμογές στην παραγωγή καλύπτονται με μετρήσεις, θα σας βοηθήσει να κοιμάστε καλύτερα τη νύχτα, επιτρέποντας στους προγραμματιστές να δουν τι πάει στραβά και πού. Ωστόσο, ο σωστός τρόπος για να εκνευρίσετε και να απογοητεύσετε οποιονδήποτε προγραμματιστή, ιδιοκτήτη προϊόντος ή CTO είναι να επιμείνετε και να αντισταθείτε. Αυτή η συμπεριφορά θα επηρεάσει την ημερομηνία κυκλοφορίας οποιουδήποτε προϊόντος εάν περιμένετε ξανά μέχρι την τελευταία στιγμή, επομένως μετακινήστε ξανά αριστερά και συμπεριλάβετε αυτά τα ζητήματα στο σχέδιο του έργου σας το συντομότερο δυνατό. Εάν είναι απαραίτητο, προχωρήστε σε συναντήσεις προϊόντων. Φορέστε ένα ψεύτικο μουστάκι και τσόχα ή κάτι τέτοιο, δεν θα αποτύχει ποτέ. Κοινοποιήστε τις ανησυχίες σας, δείξτε ξεκάθαρα οφέλη και ευαγγελίστε.
  3. Βεβαιωθείτε ότι τόσο η ανάπτυξη (dev) όσο και οι λειτουργίες (ops) κατανοούν το νόημα και τις συνέπειες των μετρήσεων προϊόντων που μετακινούνται στην κόκκινη ζώνη. Μην αφήνετε την Ops ως τον μοναδικό θεματοφύλακα της υγείας των προϊόντων, βεβαιωθείτε ότι συμμετέχουν και οι προγραμματιστές (#productsquads).
  4. Τα αρχεία καταγραφής είναι ένα υπέροχο πράγμα, αλλά και οι μετρήσεις. Συνδυάστε τα και μην αφήσετε τα κούτσουρα σας να γίνουν σκουπίδια σε μια τεράστια φλεγόμενη μπάλα αχρηστίας. Εξηγήστε και δείξτε στους προγραμματιστές γιατί κανείς άλλος δεν θα καταλάβει τα αρχεία καταγραφής τους, δείξτε τους πώς είναι να κοιτάτε άχρηστα αρχεία καταγραφής στις 3:15 το πρωί.

Γιατί οι μηχανικοί δεν ενδιαφέρονται για την παρακολούθηση εφαρμογών;
Συντάκτης της φωτογραφίας Μάρκο Χόρβατ επί Unsplash

Αυτό είναι όλο. Νέο υλικό θα κυκλοφορήσει την επόμενη εβδομάδα. Αν θέλετε να μάθετε περισσότερα για το μάθημα, σας προσκαλούμε Open Day, που θα πραγματοποιηθεί τη Δευτέρα. Και τώρα παραδοσιακά περιμένουμε τα σχόλιά σας.

Πηγή: www.habr.com

Προσθέστε ένα σχόλιο