Αξιοπιστία Λογισμικού

& Συστημάτων
Παναγιώτης Κατσαρός

Αν. Καθηγητής

Τμ. Πληροφορικής Α.Π.Θ.

katsaros@csd.auth.gr

url: http://depend.csd.auth.gr
Λογισμικό, συστήματα & αξιοπιστία

• Ένα σύστημα αποτελείται από συστατικά λογισμικού και υλικού

που προορίζονται να παρέχουν μία υπηρεσία.

• Κάθε σύστημα υπάρχει και λειτουργεί σ’ ένα συγκεκριμένο

περιβάλλον (π.χ. διάστημα).

• Τα συστήματα σχεδιάζονται, έτσι ώστε να ικανοποιούν ένα σύνολο

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

• Μία κρίσιμη απαίτηση για κάποια σύστήματα είναι το να

μπορούμε να τα εμπιστευτούμε (dependable) για το σκοπό που
κατασκευάζονται.
Αποτυχίες, λάθη και βλάβες
• Αποτυχία (failure) σ’ ένα σύστημα σε λειτουργία έχουμε όταν αυτό αποκλίνει
από την προδιαγεγραμμένη συμπεριφορά του.

• Η αιτία της εμφάνισης μιας αποτυχίας ονομάζεται λάθος (error). Λάθος

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

• Κάθε λάθος είναι αποτέλεσμα μιας βλάβης (fault) του συστήματος or fault.

… FailuresCausationFaultsActivationErrors
Propagation
Faults …
Causation
Failures

• Άρα ένα λάθος είναι απλά το σύμπτωμα μιας βλάβης, αν και μία βλάβη δεν
είναι απαραίτητο να προκαλέσει λάθος.

• Η ίδια βλάβη μπορεί να προκαλέσει πολλά λάθη και ομοίως ένα λάθος μπορεί
να οδηγήσει σε πολλαπλές αποτυχίες.
Availability Reliability Safety Confidentiality Integrity Maintainability
 Παράδειγμα βλάβης, λαθών και
αποτυχίας
• Σ’ ένα σύστημα λογισμικού, μία εσφαλμένη εντολή στο πρόγραμμα έστω ότι
ελαττώνει μία εσωτερική μεταβλητή, αντί να την αυξάνει.

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

Βλάβη → η εσφαλμένη εντολή

Λάθος → η μη έγκυρη τιμή της μεταβλητής

Αποτυχία → η συμπεριφορά που είναι συνέπεια του λάθους

• Αν η μεταβλητή δε διαβαστεί μετά από την εγγραφή της, δε θα σημειωθεί

αποτυχία.

• Αν η εσφαλμένη εντολή δεν δεν εκτελεστεί, τότε η βλάβη δεν οδηγεί σε λάθος.
 Ταξινόμηση βλαβών I

• Ως προς τη διάρκεια, οι βλάβες διακρίνονται σε παροδικές (transient) και

μόνιμες (permanet). Μία παροδική βλάβη τελικά εξαφανίζεται χωρίς
παρέμβαση.

• Η διάγνωση και ο χειρισμός των μόνιμων βλαβών είναι πιο εύκολος.

• Ένας ιδιαίτερα προβληματικός τύπος παροδικής βλάβης είναι η διαλείπουσα

(intermittent) βλάβη, που επαναλαμβάνεται και μάλιστα συχνά απρόβλεπτα.
 Ταξινόμηση βλαβών II

Ως προς την αιτία (cause), οι βλάβες διακρίνονται σε:

• Σχεδιαστικές βλάβες, που οφείλονται σε σχεδιαστικές αποτυχίες.

• Λειτουργικές βλάβες, που συμβαίνουν στη διάρκεια ζωής του

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

Ως προς το πώς συμπεριφέρεται ένα συστατικό με βλάβη έχουμε τις περιπτώσεις:

• Βλάβες κατάρρευσης (crash faults) - το συστατικό παύει να λειτουργεί ή δεν επιστρέφει ποτέ
σε έγκυρη κατάσταση

• Βλάβες παράλειψης (omission faults) - το συστατικό αποτυγχάνει τελείως στην εκτέλεση της
υπηρεσίας του

• Βλάβες χρονισμού (timing faults) - το συστατικό δεν ολοκληρώνει την εξυπηρέτηση έγκαιρα

• Βυζαντινές βλάβες (timing faults) - βλάβες με εντελώς τυχαία, μη αναμενόμενη συμπεριφορά

 Βλάβες λογισμικού
Σφάλµατα µε δείκτες και µνήµη Memory Leaks
Temporary values returned
Free the already freed ressource
NULL dereferencing
Exposure of private data to untrusted components
Ψευδονυµία (aliases) Need of Unique addresses
Σφάλµατα συγχρονισµού Deadlock
Race Condition
Livelock
Συνηθισµένα σφάλµατα που αναφέρονται σε Inconsistent sychronization
συγχρονισµό Incorrect lazy initialization of static field
Naked notify in method
Method spins on field
Σφάλµατα δεδοµένων και αριθµητικά σφάλµατα Unitialised memory
Value outside of domain
Buffer overflow/underflow
Arithmetic exceptions
Off by one
Enumerated data types
Wrong assumptions on operator procedure
Undefined order of side effects
String handling errors
Ευπάθειες ασφάλειας Buffer overflow - Execute malicious code
Gaining root privileges
Exploiting Heap/BSS Overflows
Dealing with volatile objects
Πλεονασµατικές λειτουργίες Redundant Assignment
Dead code
Redundant Conditionals
Σφάµατα σχετικά µε κληρονοµικότητα Virtual function is not overriden
Component of derived class shadows base class
Override both equals and Hashcode
Some other flaws
Άλλα σφάλµατα Data can be lost as a result of trancation
Compare strings as object references
Array index values
Διάγραμμα “ψαροκόκκαλο”

• Διάγραμμα αιτίας - αποτελέσματος, που απεικονίζει τις εξαιρέσεις που μπορεί να

προκύψουν σ’ ένα σύστημα λογισμικού.

• Στην κεφαλή αναγράφεται αυτό που θέλουμε να αποφύγουμε (exception failure) ενώ
στα πλευρικά μέρη έχουμε τις κατηγορίες των συμβάντων, που πρκαλούν την αποτυχία
και κάθε πλευρό αναφέρει παραδείγματα με συγκεκριμένες αιτίες.
Φερεγγυότητα (dependability)
Dependability

Readiness Continuity Absence Absence of Absence Ability to

for usage of service of catastrophic unauthorized of improper undergo
consequences on disclosure of system repairs and
the user(s) and information alterations evolutions
the environment

Availability Reliability Safety Confidentiality Integrity Maintainability

Authorized actions

Security
Absence of unauthorized access to, or handling of, system state
 Φερεγγυότητα (dependability)

• Ως αξιοπιστία (reliability) ορίζεται η πιθανότητα να λειτουργεί ένα

σύστημα ορθά μέχρι μία συγκεκριμένη χρονική στιγμή. Ένα μέτρο
αξιοπιστίας είναι το mean time between failures (MTBF).

• Ως διαθεσιμότητα (availability) ορίζεται η πιθανότητα να είναι ένα

σύστημα λειτουργικό σε μία δεδομένη στιγμή. Για ένα σύστημα, αυτό το
χατακτηριστικό εξαρτάται από το χρόνο που διαρκεί η αποκατάσταση
της υπηρεσίας του μετά από αποτυχία. Ο χρόνος αυτός μετριέται από
το mean time to repair (MTTR). Η διαθεσιμότητα ενός συστήματος
δίνεται από τον τύπο:

Availability = (MTBF) / (MTTR + MTBF)

• Για συστήματα που δεν αποτυγχάνουν ποτέ, η διαθεσιμότητα είναι ίση

με την αξιοπιστία.
 Μέσα φερεγγυότητας

… FailuresCausationFaultsActivationErrors
Propagation
Faults …
Causation
Failures

Availability Reliability Safety Confidentiality Integrity Maintainability

Fault Fault Fault Fault

Prevention Tolerance Removal Forecasting
 Μέσα φερεγγυότητας

• Αποφυγή βλαβών (Fault prevention) - το σύστημα σχεδιάζεται ώστε να ελαχιστοποιείται

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

• Ανοχή βλαβών (Fault tolerance) - το σύστημα είναι σε θέση να επιτελεί την λειτουργία
του σωστά ακόμη και στην περίπτωση εμφάνισης εσωτερικών βλαβών

• Απομάκρυνση βλαβών (Fault removal) - χρήση επαλήθευσης και δοκιμών για εντοπισμό
βλαβών, που επιτρέπουν την εφαρμογή κατάλληλων αλλαγών στο σύστημα.
Συμπεριλαμβάνονται τεχνικές unit testing, integration testing, regression testing, and
back-to-back testing. Η απομάκρυνση βλαβών κοστίζει περισσότερο από την αποφυγή.

• Πρόληψη βλαβών (Fault forecasting) - χρήση πληροφοριών παρατήρησης του

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

• Εντοπισμός λάθους (error detection) είναι η διαδικασία

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

• Περιορισμός επιπτώσεων (damage confinement) - για να

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

• Ανάκαμψη από λάθος (error recovery) - το λάθος και κυρίως οι

επιπτώσεις του απομακρύνονται αποκαθιστώντας το σύστημα
σε μία έγκυρη κατάσταση.

• Αποκατάσταση βλάβης (fault treatment) - επικεντρωνόμαστε

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

• Σ’ ένα σύστημα λογισμικού, συμβαίνει συχνά μία μόνο βλάβη να

προκαλεί πολλά διαδιδόμενα λάθη, που εκδηλώνονται
ανεξάρτητα.

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

• Η βλαβοανοχή λογισμικού εξαρτάται τόσο από τη λογική του

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

• Η βλαβοανοχή μπορεί να εφαρμοστεί επιλεκτικά στα συστατικά

εκείνα, που λόγω της πολυπλοκότητάς τους είναι πιο πιθανό να
έχουν λάθη.
 Εντοπισμός λάθους Ι

• Έλεγχοι με πλεονασμό (replication checks)

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

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

Fault
detector
Voting Output 1
Component 1
Component 1 Component

Component 1
Input Voting Output Input Voting Output 2
Component 2 Component 2
Component Component
Input
Switch
Output
Voting Output 3
Component 3 Component 3
Component
Component 2

Στο hardware, μία τέτοια προσέγγιση είναι η triple-modular redundancy

(TMR).

Στην αντίστοιχη λύση στο software, χρησιμοποιούνται διαφορετικές

υλοποιήσεις του ίδιου συστατικού που έχουν υλοποιηθεί ανεξάρτητα.
Αυτό λέγεται N-version programming.
 Εντοπισμός λάθους ΙΙ

• Έλεγχοι χρονισμού (timing checks)

Χρησιμοποιούνται για τον εντοπισμό βλαβών χρονισμού (timing

faults).

Εκκινείται ένα χρονομετρητής (timer), που πρόκειται να λήξει

τη στιγμή εκείνη που αναμένεται η ολοκλήρωση μιας
εξυπηρέτησης.

Αν η υπηρεσία ολοκληρώσει την επεξεργασία της πριν από την

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

Η χρήση χρονομετρητών είναι δύσκολη όταν υπάρχει μεγάλη

διασπορά στους χρόνους εξυπηρέτησης.
 Εντοπισμός λάθους ΙΙΙ

• Έλεγχοι χρόνου εκτέλεσης

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

Παράδειγμα: εύρωστες δομές δεδομένων, με ενσωματωμένο πλεονασμό

(checksum). Οι έλεγχοι πλεονασμού είναι για τον εντοπισμό ασυνεπειών.

Επίσης, κάποιες γλώσσες προγραμματισμού υποστηρίζουν έναν

μηχανισμό ελέγχου ισχυρισμών (assertions).

• Διαγνωστικοί έλεγχοι (diagnostic checks)

Έλεγχοι που συνήθως γίνονται στο παρασκήνιο για να διαπιστωθεί αν ένα

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

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

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

• Ο περιορισμός των επιπτώσεων μπορεί να υποβοηθείται από “τείχη

προστασίας (firewalls)” τέτοια ώστε να υπάρχει μία χαλαρή σύζευξη
με τα συστατικά έξω από το “τείχος” για να αποσυνδέονται εύκολα
τα συστατικά με βλάβη και να συνδέονται με ένα πλεονασματικό
σύνολο άλλων συστατικών χωρίς βλάβη. Αυτή η λύση έχει υψηλό
κόστος σε αποδοτικότητα και σε χρήση μνήμης.
 Ανάκαμψη από λάθος

Θα πρέπει το σύστημα να αποκατασταθεί σε μία έγκυρη κατάσταση.

Υπάρχουν δύο γενικές προσεγγίσεις.

• Ανάκαμψη με επιστροφή σε προηγούμενη έγκυρη κατάσταση

(backward error recovery). Αυτό απαιτεί την διατήρηση της κατάστασης
του συστήματος σε σημεία ελέγχου (checkpoints) στην πορεία του
χρόνου και σε περίπτωση λάθους την επιστροφή της κατάστασης του
συστήματος στην κατάσταση του τελευταίου σημείου ελέγχου. Μπορεί
να συνοδεύεται από υψηλό κόστος.

• Εμπρόσθια ανάκαμψη από λάθος (forward error recovery). Το σύστημα

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

Σ’ αυτή τη φάση απομονώνεται αρχικά και στη συνέχεια επιδιορθώνεται η βλάβη. Για τις
μόνιμες βλάβες απαιτείται αντικατάσταση του συστατικού με τη βλάβη. Αυτό απαιτεί ένα
εφεδρικό συστατικό σε αναμονή (standby component), δηλ. ένα συστατικό που η
κατάστασή του θα συγχρονίζεται με την κατάσταση του υπόλοιπου συστήματος. Τρεις
γενικοί τύποι συστατικών σε αναμονή:

• “Ψυχρή” αναμονή (cold standby) - Το συστατικό σε αναμονή δεν είναι λειτουργικό και
άρα πρέπει η κατάστασή του να αλλαχθεί όταν γίνει η αντικατάσταση, που μπορεί να
πάρει χρόνο.

• “Μετρίως θερμή” αναμονή (warm standby) - Στο εφεδρικό συστατικό διατηρείται το

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

• “Θερμή” αναμονή (hot standby) - Το εφεδρικό συστατικό είναι πλήρως ενεργό και
λειτουργεί πλεονασματικά ως προς το συστατικό που υποκαθιστά. Σε περίπτωση
λάθους η ανάκαμψη είναι πρακτικά στιγμιαία. Είναι όμως δύσκολος ο συγχρονισμός των
δύο συστατικών.