Projekt odporny na awarie wykrywa, izoluje, maskuje lub rekonfiguruje się wokół usterek, tak by operacja pozostawała w określonych granicach poprawności, pojemności, timingu i bezpieczeństwa — czasem na celowo zdegradowanym poziomie usługi.
Wymaganie musi definiować, które usterki, kombinacje i czasy trwania system powinien tolerować. Projekty mogą używać replikacji, głosowania, korekcji błędów, niezależnych ścieżek zasilania lub komunikacji, różnorodnych implementacji, uzgadniania stanu i łagodnej degradacji, wspierane przez monitorowanie i naprawę.
Najważniejsze punkty
Zdefiniuj poprawną usługęOkreśl funkcje niezbędne, dozwoloną degradację, założenia o usterkach, czas wykrycia, zachowanie odtwarzania i punkt, w którym bezpieczne wyłączenie jest lepsze niż kontynuacja.
Twórz niezależnośćOddzielaj repliki oraz wspierające zasilanie, sieci, tożsamości, administrację i lokalizacje tam, gdzie model zagrożeń tego wymaga; rozważ różnorodność przeciw wspólnym defektom.
Chroń stanKontroluj replikację, porządek, kworum, spójność, wykrywanie korupcji i reintegrację, tak by redundantne komponenty nie rozprzestrzeniały złych danych ani nie tworzyły konfliktujących działań.
Istotne ograniczenieSama redundancja nie jest odpornością na awarie. Awarie wspólnego trybu, współdzielone zależności, defekty projektowe, skorelowane ataki, wyczerpana pojemność i niepoprawne wykrywanie awarii mogą pokonać każdą replikę, a dodana złożoność może wprowadzać nowe usterki.