Η πραγματικότητα ενός μηχανικού δικτύου (με χυλοπίτες και... αλάτι;)
Πρόσφατα, ενώ συζητούσα διάφορα περιστατικά με μηχανικούς, παρατήρησα ένα ενδιαφέρον μοτίβο.
Σε αυτές τις συζητήσεις, ανακύπτει πάντα το ζήτημα της «ριζικής αιτίας». Οι πιστοί αναγνώστες μάλλον ξέρουν ότι το έχω επί . Σε πολλούς οργανισμούς, η ανάλυση περιστατικών βασίζεται εξ ολοκλήρου σε αυτήν την έννοια. Χρησιμοποιούν διαφορετικές τεχνικές για τον εντοπισμό σχέσεων αιτίου-αποτελέσματος, όπως π.χ . Αυτές οι μέθοδοι υποθέτουν τη λεγόμενη «γραμμικότητα των γεγονότων» ως αδιαμφισβήτητο δόγμα.
Όταν αμφισβητείτε αυτήν την ιδέα και επισημαίνετε ότι η γραμμικότητα είναι καθησυχαστικά παραπλανητική σε πολύπλοκα συστήματα, γεννιέται μια συναρπαστική συζήτηση. Οι διαφωνούντες επιμένουν με πάθος ότι μόνο η γνώση της «ριζικής αιτίας» μας επιτρέπει να καταλάβουμε τι συμβαίνει.
Παρατήρησα ένα ενδιαφέρον μοτίβο: οι προγραμματιστές και οι προγραμματιστές αντιδρούν διαφορετικά σε αυτήν την ιδέα. Από την εμπειρία μου, οι προγραμματιστές είναι πιο πιθανό να υποστηρίξουν ότι η βασική αιτία έχει σημασία και ότι οι σχέσεις αιτίου-αποτελέσματος μπορούν πάντα να δημιουργηθούν σε γεγονότα. Από την άλλη πλευρά, οι DevOps συμφωνούν συχνότερα ότι ένας πολύπλοκος κόσμος δεν υπακούει πάντα στη γραμμικότητα.
Πάντα αναρωτιόμουν γιατί συμβαίνει αυτό; Τι κάνει οι προγραμματιστές να επικρίνουν την ιδέα «η βασική αιτία είναι ένας μύθος» έτσι; Σαν ένα ανοσοποιητικό σύστημα που αναγνωρίζει έναν ξένο παράγοντα. Γιατί αντιδρούν με αυτόν τον τρόπο, ενώ οι devops μάλλον κλίση σκεφτείτε αυτή την ιδέα;
Δεν είμαι απόλυτα σίγουρος, αλλά έχω κάποιες σκέψεις για αυτό. Σχετίζεται με τα διαφορετικά πλαίσια στα οποία αυτοί οι επαγγελματίες εκτελούν την καθημερινή τους εργασία.
Οι προγραμματιστές συχνά εργάζονται με ντετερμινιστικά εργαλεία. Φυσικά, μεταγλωττιστές, σύνδεσμοι, λειτουργικά συστήματα - όλα αυτά είναι πολύπλοκα συστήματα, αλλά είμαστε συνηθισμένοι στο γεγονός ότι δίνουν ένα ντετερμινιστικό αποτέλεσμα και τα φανταζόμαστε ως ντετερμινιστικά: εάν παρέχουμε τα ίδια δεδομένα εισόδου, τότε συνήθως περιμένουμε ίδια έξοδο από αυτά τα συστήματα. Και αν υπάρχει πρόβλημα με την έξοδο ("bug"), τότε οι προγραμματιστές το λύνουν αναλύοντας τα δεδομένα εισόδου (είτε από τον χρήστη είτε από ένα σύνολο εργαλείων κατά τη διαδικασία ανάπτυξης). Ψάχνουν για ένα "σφάλμα" και μετά αλλάζουν τα δεδομένα εισόδου. Αυτό διορθώνει το "bug".
Βασική υπόθεση ανάπτυξης λογισμικού: τα ίδια δεδομένα εισόδου παράγουν αξιόπιστα και ντετερμινιστικά την ίδια έξοδο.
Στην πραγματικότητα, ένα μη ντετερμινιστικό αποτέλεσμα θεωρείται από μόνο του σφάλμα: εάν το απροσδόκητο ή εσφαλμένο αποτέλεσμα δεν αναπαραχθεί, τότε οι προγραμματιστές τείνουν να επεκτείνουν την έρευνα σε άλλα μέρη της στοίβας (λειτουργικό σύστημα, δίκτυο, κ.λπ.), τα οποία επίσης συμπεριφέρονται λίγο πολύ ντετερμινιστικά, παράγοντας το ίδιο αποτέλεσμα με τα ίδια δεδομένα εισόδου... και αν δεν είναι, τότε αυτό εξακολουθεί να θεωρείται σφάλμα. Είναι τώρα ένα σφάλμα λειτουργικού συστήματος ή δικτύου.
Σε κάθε περίπτωση, ο ντετερμινισμός είναι μια βασική, σχεδόν δεδομένη υπόθεση για τους περισσότερους προγραμματιστές.
Αλλά για οποιονδήποτε άνθρωπο που ασχολείται με την ανάπτυξη που έχει αφιερώσει τη μέρα του στη συγκέντρωση υλικού ή στο να βρει ένα cloud API, η ιδέα ενός εντελώς ντετερμινιστικού κόσμου (εφόσον είναι ακόμη δυνατό να χαρτογραφηθούν όλες οι εισροές!) είναι στην καλύτερη περίπτωση μια φευγαλέα ιδέα. Ακόμα κι αν το βάλεις στην άκρη , έμπειροι μηχανικοί έχουν δει τα πιο περίεργα πράγματα σε αυτόν τον κόσμο. Το ξέρουν , για να μην αναφέρουμε τους εκατομμύρια άλλους παράγοντες στο περιβάλλον.
Έτσι, είναι ευκολότερο για τους έμπειρους μηχανικούς να αμφιβάλλουν ότι όλα τα περιστατικά έχουν μια μόνο βασική αιτία και τεχνικές όπως τα «Πέντε Γιατί» θα οδηγήσουν σωστά (και επαναλαμβανόμενα!) σε αυτή τη βασική αιτία. Στην πραγματικότητα, αυτό έρχεται σε αντίθεση με τη δική τους εμπειρία, όπου τα κομμάτια του παζλ δεν ταιριάζουν τόσο όμορφα στην πράξη. Επομένως, αποδέχονται αυτή την ιδέα πιο εύκολα.
Φυσικά, δεν λέω ότι οι προγραμματιστές είναι αφελείς, ηλίθιοι ή ανίκανοι να καταλάβουν πώς η γραμμικότητα μπορεί να είναι παραπλανητική.
Αλλά μου φαίνεται ότι μια κοινή αντίδραση από τους προγραμματιστές σε αυτές τις συζητήσεις συχνά έχει να κάνει με το γεγονός ότι η έννοια του ντετερμινισμού τους εξυπηρετεί καλά συνολικά στην καθημερινή εργασία. Δεν αντιμετωπίζουν μη-ντετερμινισμό τόσο συχνά όσο οι μηχανικοί πρέπει να πιάσουν τις γάτες του Σρέντινγκερ στην υποδομή τους.
Αυτό μπορεί να μην εξηγεί πλήρως τις παρατηρούμενες αντιδράσεις προγραμματιστή, αλλά είναι μια ισχυρή υπενθύμιση ότι οι αντιδράσεις μας είναι ένα πολύπλοκο μείγμα πολλών παραγόντων.
Είναι σημαντικό να θυμόμαστε αυτή την πολυπλοκότητα, είτε έχουμε να κάνουμε με ένα μεμονωμένο περιστατικό, είτε συνεργαζόμαστε σε έναν αγωγό παράδοσης λογισμικού είτε προσπαθούμε να κατανοήσουμε τον ευρύτερο κόσμο.
Πηγή: www.habr.com