“Μου χάλασαν 460 μέρες uptime στο firewall”. Φίλος χτες, κατά τη διάρκεια δοκιμών προσπαθώντας να ξεπεράσει (route arround) το χθεσινό πρόβλημα.
Δεν χωρεί αμφιβολία πως το uptime είναι ένα καλό μέτρο σταθερότητας των συστημάτων που διαχειρίζεται (συντηρεί) ένας system administrator. Το να γίνεται όμως αυτοσκοπός (και μερικές φορές ένα είδος συναδελφικής “κόντρας”) είναι επικίνδυνο:
Συνήθως διαχειριζόμαστε πολλά συστήματα και μηχανές, όχι μόνο ένα-δύο. Τα συστήματα αυτά έχουν αλληλεξαρτήσεις μεταξύ τους, οι οποίες πολλές φορές δεν είναι ούτε καταγεγραμμένες, ούτε προφανείς.
Τα συστήματα που διαχειριζόμαστε εξελίσσονται (μεταλλάσσονται που λέει και ένας καθηγητής μου) με την προσθήκη νέων υποσυστημάτων που “πατάνε” στην παλαιότερη υποδομή. Και ναι, η ικανοποίηση είναι μεγάλη όταν μπορείς να επιτύχεις δραστικές αλλαγές στο σύστημα χωρίς να “κατεβάσεις” μηχάνημα (χωρίς να χαλάσεις το uptime δηλαδή).
Αλλά:
Στη διαδικασία αυτών των αλλαγών μεταβάλλονται κατά τρόπο μη προφανή δύο διαδικασίες:
- Διαδικασία παύσης όλου του συστήματος
- Διαδικασία έναρξης όλου του συστήματος
και επηρεάζεται εξίσου και η διαδικασία επανεκκίνησης τμημάτων ή όλου του συστήματος. Πολλές φορές το να έχουν κάποια μηχανήματα υψηλό uptime (πάνω από 6 μήνες κατά τη γνώμη μου) είναι περισσότερο πρόβλημα, παρά στοιχείο υπερηφάνειας:
Μπορεί στο μεσοδιάστημα να έχουν αλλάξει περισσότερους από ένα διαχειριστές, με ότι σημαίνει αυτό ως “χαμένη εμπειρία” για το σύστημα, ειδικά εάν ο παλαιότερος διαχειριστής έχει αλλάξει εργοδότη.
Υψηλό uptime σημαίνει πως τουλάχιστον kernel patches δεν έχουν εφαρμοστεί, με ότι σημαίνει το ρίσκο αυτό κατά περίπτωση. Ναι, ξέρω πως υπάρχουν λειτουργικά συστήματα στα οποία μπορείς να κάνεις upgrade τον kernel χωρίς reboot. Πόσοι δουλεύετε με τέτοια και πόσοι από αυτούς που όντως δουλεύετε με τέτοια κάνετε έτσι τα upgrades;
Πολλές φορές δεν μπορούμε να δουλεύουμε με καινούριες μηχανές. Μερικές φορές κρίσιμη υποδομή ενδέχεται αναγκαστικά να βρίσκεται σε μηχανήματα 10+ χρόνια παλιά. Με το πέρασμα του χρόνου το κάθε μηχάνημα αποκτά τα “χούγια” του (π.χ. ο διακόπτης πρέπει να πατηθεί “κάπως” για να δουλέψει) ενώ ακόμα και στο software που τρέχει το να κάνεις reboot μπορεί να σημαίνει πως κάποιες διαδικασίες πρέπει να τις κάνει υποχρεωτικά με το χέρι πριν το reboot, ή μετά το boot, κ.ο.κ.
Έτσι όταν τα πράγματα θα πάνε στραβά (γιατί θα πάνε) ο χρόνος ανάνηψης είναι τελικά μεγαλύτερος, γιατί την εμπειρία των ιδιαίτερων λεπτομερειών του κάθε συστήματος, υποσυστήματος, μηχανής και την μέθοδο επανεκκίνησης με όλα τα ιδιαίτερα χαρακτηριστικά της, θα πρέπει να την μάθει κανείς (και ελπίζω και να την καταγράψει) εκείνη ακριβώς τη στιγμή, με όλη την πίεση πάνω του.
Και μην ξεχνάμε: 99.999% uptime is for Wal-Mart. Γι’αυτό:
Downtime is not an option.
Ο αρχικός τίτλος του post ήταν: uptime (ή ποιος την έχει μεγαλύτερη)
Managing organized complexity 
Δεν θα μπορούσες να είσαι πιο σωστός! Σίγουρα το uptime δεν αποτελεί μέτρο σύγκρισης και σε καμία περίπτωση συναδελφική “κόντρα” (εκτός εάν απευθυνόμαστε σε δεκαπεντάχρονα σε φάση “ποιός την έχει μεγαλύτερη”). Επίσης θίγεις με τον καλύτερο τρόπο το θέμα της καταγραφής – τεκμηρίωσης (το δεύτερο το προσθέτω καταχρηστικά δεδομένου ότι συνέλαβα σωστά το νόημα της τελευταίας σου πρότασης) στο οποίο επίσης θεωρώ οτι υστερούμε είτε επειδή το κάνουμε με τον λάθος τρόπο, είτε επειδή δεν το κάνουμε καθόλου. Ελπίζω σε κάποιο μελλοντικό post δοθείσης της ευκαιρίας να θίξεις γενικότερα το θέμα του documentation.
Πόσο μα πόσο δίκιο έχεις!
Η αλήθεια είναι ότι πρέπει να δούμε το context στο οποίο λειτουργεί ένα σύστημα. Για παράδειγμα, ένα linux μηχάνημα το οποίο τρέχει έναν Apache ο οποίος έχει 5-6 στατικές σελίδες ενός εργαστηρίου στο πολυτεχνείο και το οποίο είναι πίσω από ένα καλά ρυθμισμένο firewall μπορεί να κάνει αρκετά καλά τη δουλειά του με σποραδικά updates στον Apache.
Αντιθέτως, ένας εμπορικός server που τρέχει ένα μεγάλο portal, ένας LDAP server ή ένας terminal server επιβάλλεται να τρέχει τις πιο τελευταίες εκδόσεις γιατί έχει αντίστοιχα υψηλότερες περιπτώσεις να δεχθεί επίθεση είτε εκ των έσω είτε εκ των έξω.
Είναι εξαιρετικά σημαντικό να γνωρίζουμε ότι “πάντα κάτι θα πάει στραβά αργά ή γρήγορα” και να λαμβάνουμε τα μέτρα μας. Ειδικά στο θέμα του πεπαλαιωμένου υλικού βλέπω τα workstation μηχανήματα στο εργαστήριο που έχουν κλείσει 5ετία και αρχίζουν και εμφανίζουν βλάβες σύμφωνα με το διάγραμμα της μπανιέρας ( http://en.wikipedia.org/wiki/Bathtub_curve ). Αυτό που προσωπικά κάνω είναι 1 με 2 χρόνια πριν (κάπου στην τριετία) να ζητάω επιμόνως ανταλλακτικά έτσι ώστε να υπάρχει το απαραίτητο stock (άντε βρες καινούργια π.χ. SDRAM ή RAMBUS μνήμη) καθώς και νέα μηχανήματα.
Εγώ πάλι έχω παρατηρήσει οτι πολλές φορές σ’έναν “μικρό” web server με 5-6 στατικές σελίδες σ’ένα εργαστήριο είναι πολύ εύκολο να είσαι current ή bleeding edge..
Αντίθετα όμως, σ’ένα εμπορικό, μεγάλο portal, με δεκάδες components και υποσυστήματα που αλληλέπιδρούν με δεκάδες άλλα (semi-documented στην καλύτερη περίπτωση), που έχει δωθεί σε “production” .. δεν κουνάς ούτε τρίχα! Το αφήνεις όπως είναι εις τους αιώνες των αιώνων.. (*1)
Και το πιο μικρό update που θα κάνεις, θα χαλάσει κάτι άλλο.. Στην καλύτερη περίπτωση, έχεις ένα playground copy, και μετά από δοκιμές κάνεις rollout κανένα critical update για remote vulnerability 1 μήνα αφού έχει ανακοινωθεί..
(*1) Να μη μιλήσουμε για περιπτώσεις που 6 μήνες αφού έχει στηθεί το portal δεν υπάρχει πλέον ο αρχικός developer να το συντηρήσει, εννοείται ότι δεν υπάρχει documentation και είσαι μόνος στον ωκεανό παλεύοντας με τα κύματα…